https://www.mikrocontroller.net/api.php?action=feedcontributions&feedformat=atom&user=HehaMikrocontroller.net - Benutzerbeiträge [de]2026-04-11T03:54:16ZBenutzerbeiträgeMediaWiki 1.39.7https://www.mikrocontroller.net/index.php?title=Kondensator&diff=107597Kondensator2025-08-04T09:06:13Z<p>Heha: /* Flüssig-Elektrolyt */</p>
<hr />
<div>Ein '''Kondensator''' ist ein passives elektrisches Bauteil mit zwei Anschlüssen, welches elektrische Energie in einem elektrischen Feld in Form von Ladung speichert. Die charakteristische Größe, die den Kondensator beschreibt, ist die Kapazität C, gemessen in Farad (F). Ein Kondensator besteht aus zwei Flächen gut leitfähigen Materials, die voneinander isoliert sind. Das Isolationsmaterial ist ein Dielektrikum und verleiht dem Kondensator je nach Material stark unterschiedliche Eigenschaften.<br />
<br />
== Aufbau eines Kondensators ==<br />
Je größer die Fläche, je geringer der Abstand der Flächen und je höher die relative Permittivität \varepsilon_r - das Dielektrikum - desto höher ist die Kapazität des Bauteils. Der einfachste Kondensator besteht aus zwei voneinander isolierten Metallplatten, zwischen denen sich Luft als "Dielektrikum" befindet. Um die Fläche und damit die Kapazität zu vergrößern gibt es verschiedene Möglichkeiten:<br />
<br />
=== Wickelkondensator ===<br />
Die einfachste Methode die Flächen zu vergrößern ist es, zwei leitfähige Folien mit einem Isolationsmaterial dazwischen aufzuwickeln. Diese Methode wird für so ziemlich alle Kondensatortypen verwendet. Manchmal wird der Wickel nach der Herstellung flachgepresst, um das Volumen zu optimieren.<br />
<br />
=== Schichtkondensator ===<br />
Diese Aufbauart wird durch "stapeln" der unterschiedlichen Lagen erreicht. Verfahrenstechnisch ist dies oft wieder ein Wickel, jedoch meist auf bis zu 2 Meter durchmessenden Wickelrädern. Dieses ursprünglich von Siemens eingesetzte Verfahren wird auch aktuell noch verwendet, hauptsächlich für Folienkondensatoren bis in den mF-Bereich hinein. Nach dem Wickeln auf vieleckigen Rädern wird der Folienstapel geschnitten und auf die gewünschte Größe = Kapazität getrennt.<br />
<br />
=== Zusammenhang Baugröße, Spannung, Kapazität ===<br />
Abgesehen vom Einfluss des Dielektrikums geht das Bauvolumen grundsätzlich linear zur Kapazität und quadratisch(!) zur Spannungsfestigkeit. Denn zur Verdopplung der Kapazität verdoppelt man die Kondensatorfläche, entsprechend einer Parallelschaltung von Kondensatoren. Zur Verdopplung der Spannungsfestigkeit wird wie bei einer Reihenschaltung die Dicke des Dielektrikums verdoppelt, was mit einer Halbierung der Kapazität einhergeht: Bei gleicher Kapazität muss daher auch die Kondensatorfläche verdoppelt werden.<br />
<br />
Somit ist das Bauvolumen direkt proportional zum maximalen Energiegehalt des Kondensators.<br />
<br />
== Kondensatortypen ==<br />
(Vakuum-, Glimmer-, Gas- und Glaskondensatoren nicht berücksichtigt)<br />
=== Keramik-Kondensator ===<br />
Siehe auch den Artikel '''Keramikkondensator in [https://de.wikipedia.org/wiki/Keramikkondensator#Spannungsabh.C3.A4ngigkeit_der_Kapazit.C3.A4t Wikipedia]'''. Es gibt sie bedrahtet und in SMD. Bedrahtet gab es sie früher als Einschicht-Kapazität in Scheibenform, heutzutage nur noch als Vielschicht-Kondensator. Einschichtig nur für Spannungen im Kilovolt-Bereich.<br />
<br />
Kerkos sind sogenannte "Vielschicht-Kondensatoren" die aus mehreren hundert Lagen einer isolierenden Keramik (Titandioxid+Bariumtitanat), und einer elektrisch leitfähigen Metallisierung (Aluminium & Magnesiumsilikate) bestehen.<br />
Dieser Typ ist wie der Folienkondensator für höchste Frequenzen geeignet, hat eine sehr geringe Baugröße, eine gute Temperaturstabilität aber piezoelektrische Eigenschaften. Die Kapazität pro mm³ variiert je nach Dielektrikum Z5U, Y5V, X7R, C0 (in abnehmender Kapazitätsdichte) und ist sowohl abhängig von Temperatur als auch der angelegten Spannung.<br />
<br />
Keramik-Kondensatoren sind sehr preisgünstig und werden überall dort eingesetzt, wo andere Kondensatortypen keinen Vorteil bringen. Zudem lösen sie mehr und mehr Elektrolytkondensatoren ab, die ihrerseits mit hoher Kapazität punkten: Die Lebensdauer, besonders bei hoher Temperatur, ist höher.<br />
<br />
=== Folien-Kondensator ===<br />
Siehe auch den Artikel '''Folienkondensator in [https://de.wikipedia.org/wiki/Kunststoff-Folienkondensator Wikipedia]'''.<br />
<br />
Unterschiedliche Folienarten verleihen dem Kondensator stark unterschiedliche Eigenschaften wie z.B. temperatur- und alterungsbeständigkeit, Verlustfaktor, Isolationswiderstand, und die obere Grenzfrequenz, um nur die wichtigsten zu nennen. Die Dicke der Metallisierung hingegen entscheidet über den maximal zulässigen Rippelstrom / Impulsstromfestigkeit und darüber, ob sich ein Kondensator "selbst heilen" kann, oder nicht. Das Verfahren der "Selbstheilung" funktioniert nur bei Metallisierungen, da es darauf beruht, daß die im C gespeicherte Energie den Metallbelag beim Durchschlag durch die Isolation verdampfen kann. Ist die Energie zu gering, wird nur wenig Metall um den Durchschlag verdampft, und der Kurzschluß bleibt bestehen. Ist die Energie zu hoch, wird der Kondensator thermisch zerstört. Hat der C den richigen Energiegehalt, verdampft direkt um die Durchschlagstelle herum bis zu einigen mm der Metallisierung, und die Fehlstelle ist wieder isoliert. Im Übrigen ist eine Parallelsschaltung aus vielen,als selbstheilenden C's nicht unbedingt mehr "selbstheilend" da der Energieeintrag dann aus dem Gesamtverbund kommt, und oft zu hoch ist um nur eine kleine Fläche verdampfen zu lassen.<br />
Impulsstrom-feste Kondensatoren zeichnen sich durch hohe Schichtstärken der Metallisierung aus, oder verwenden statt der Metallbeschichtung direkt eine Metallfolie. Hier wäre normalerweise ein "selbstheilen" gleichbedeutend mit einem so hohen Energieeintrag, daß das Bauteil zerstört wird.<br />
<br />
Hier eine kleine Übersicht mit der Bitte um Vervollständigung.<br />
<br />
{| class="wikitable"<br />
| style="width:8em"| '''Folientyp''' || Poly-<br>propylen || Poly-<br>styren || Poly-<br>carbonat ||Poly-<br>ester|| Poly-<br>styrol || Poly-<br>ethylen-<br>naphthalat || Polytetra-<br>fluor-<br>ethylen || Poly-<br>phenylen-<br>sulfid || Metall-<br>Papier <br />
|-<br />
| '''Folien-'''<br>'''markenname''' || Hostalen || - || Makrofol, Makroflex || Mylar, Hostaphan || Styroflex || Kaladex|| Teflon|| Tedur, Ryton|| Papier<br />
|-<br />
| '''Abkürzung''' || PP || - || PC|| PET || PS|| PEN|| PTFE|| PPS|| - <br />
|-<br />
| '''Typ''' || (F)KP, MKP || -KS, MKS || KC, MKC || (F)KT, MKT || -KS, MKS || (F)KN, MKN|| -|| (F)KI, MKI|| MP <br />
|-<br />
| '''Temperatur-'''<br>'''festigkeit /°C''' || ca 105 || - || ca. 105 || 125..150 || - || 150 || -|| 150 || 85 <br />
|-<br />
| '''Toleranz'''<br>'''+/-%''' || 1 || 1 || -|| 1 || - || -|| -|| -|| 20 <br />
|-<br />
| '''Grenzfrequenz /kHz''' || 100 || 400 || -|| - || 1000 || -|| -|| -|| - <br />
|-<br />
| '''Selbstheilend''' || ja || - || -|| ja || - || -|| -|| -|| ja <br />
|-<br />
| '''Impuls-'''<br>'''belastbarkeit''' || + || + || || + || -- || -|| -|| -|| + <br />
|}<br />
(MK) = metallisierte Folie, (F) = Metallbeläge z.B. Metallfolie (K) = Metallfolie+Kunststofffolie<br />
<br />
Für die Anwendung in Kondensatornetzteilen ist die Anwendung des Selbstheilungseffekts '''erforderlich'''. Daher findet man an dieser Stelle faktisch keine Keramikkondensatoren.<br />
<br />
=== Elektrolyt-Kondensator ===<br />
Ein Elko unterscheidet sich hauptsächlich dadurch von anderen Kondensatoren, daß nur eine Elektrode aus einer Metallschicht besteht, die zweite aus einem festen, oder flüssigen Elektrolyten.<br />
<br />
Siehe auch den Artikel '''Elektrolytkondensator in [https://de.wikipedia.org/wiki/Elektrolytkondensator Wikipedia]'''.<br />
<br />
==== Fest-Elektrolyt ====<br />
Diese Bauteile bestehen aus Polymeren, Metalloxiden, Braunstein, ... und sind wie die Elkos immer gepolt.<br />
Als Metalloxide ist Tantal sehr, und Niob noch weniger verbreitet.<br />
Takos sind '''SEHR''' empfindlich gegenüber schnellen Spannungsanstiegen bzw. Überspannung und sollten nie ohne Vorwiderstand direkt an einer niederohmigen Quelle (Batterie) geladen/betrieben werden. Takos verbrennen im Fehlerfall mit einer Stichflamme, daher empfiehlt es sich eine deutlich höhere Spannungsfestigkeit zu wählen und - bei direktem Anschluß an eine niederohmige Quelle - zusätzlich ein Lade-Vorwiderstand einzubauen. Treten zusätzlich hohe Temperaturen auf, ist die Spannungsfestigkeit mindestens zu verdoppeln.<br />
Kondensatoren mit Niob statt Tantal sind weniger verbreitet, und noch sehr teuer. Ihr Vorteil ist z.B. die Unempfindlichkeit gegenüber schnellen Spannungsanstiegen, sie können direkt an jeder Quelle betrieben werden.<br />
<br />
==== Flüssig-Elektrolyt ====<br />
Diese Bauteile bestehen aus zwei Lagen '''sehr stark angeätzter''' Aluminiumfolie - zur Vergrößerung der Oberfläche - und einem flüssigen (seltener "einem festen") Elektrolyten. Die zweite Folie kontaktiert gleichzeitig den Elektrolyten. Der Elektrolyt ist häufig auf Alkoholen basierend, aus/mit Schwefelsäure oder Glykol.<br />
Die Alufolie wird nach den ätzen anodisch oxidiert. Die Eloxal-Schicht ist mechanisch belastbar, und stellt die '''einzige''' Isolation zwischen den beiden Anschlüssen dar. Die Oxidation der Alufolie wird je nach Hersteller bei ca. 140..165% der Nennspannung durchgeführt. Die Oxidschicht baut sich durch den Elektrolyten bei langer Lagerung stark ab, daher sinkt die Spannungsfestigkeit eines Elkos mit seinem Alter. Alte Bauteile können - sofern noch Elektrolyt enthalten ist - durch spannungsrichtiges Anschließen an eine Spannungsquelle und langsamen erhöhen der Spannung bis über die Nennspannung hinaus wieder "formiert" werden. Achtung, hier besteht die Gefahr eines Kurzschlusses zwischen den Anschlüssen, daher hochohmigen Vorwiderstand verwenden!<br />
Wird ein Elko verpolt betrieben, wird die Oxidschicht im Laufe der Zeit (Abhängig von Spannung und Temperatur) abgebaut, und der Kondensator schlägt durch.<br />
<br />
Dieser Typ von Kondensator ist Standard in Schaltnetzteilen, sowohl primärseitig als 400-V-Typ als auch sekundärseitig mit bspw. 6,3 V, je nach Ausgangsspannung. Wegen seines Bauvolumens herrscht Durchsteckmontage vor. Auch in Schaltungen der Audio- und Videotechnik, etwa Radios, CD-Spielern und Fernsehern, sowie auf PC-Mainboards für die Schaltregler für Prozessor-Kernspannungen, gibt es diese bei ansonsten durchgehender SMD-Bestückung fast immer nur als Durchsteckbauteil, scheint billiger zu sein. Ursache hierfür ist die zu geringe Hitzebeständigkeit von Elkos für den Reflow-Lötprozess; Elkos werden zuletzt mit einseitiger Hitze typischerweise mittels Schwall-Löten eingesetzt.<br />
<br />
=== Doppelschicht-Kondensatoren ===<br />
Siehe auch den Artikel '''Superkondensator in [https://de.wikipedia.org/wiki/Superkondensator Wikipedia]'''.<br />
<br />
Diese Bauteile werden unter Markennamen wie "Goldcap", "Ultracap" oder "Supercap" vertrieben, besitzen meist ein flüssiges Elektrolyt haben aber nicht besonders viel mit den o.g. "Elektrolytkondensatoren" gemeinsam. Dieser Kondensator besitzt Eigenschaften eines Kondensators und einer Batterie. Der "Kondensator" ist hier aus (im Gegensatz zum Elko) zwei Lagen einer einseitig metallisierten Aktivkohle, einem Separator, und einem Elektrolyten. <br />
Das verwendete Elektrolyt erfüllt unter definierten Betriebsbedingungen die Funktion eines zusätzlichen Dielektrikums, und trägt zusätzlich zur ohnehin schon sehr großen Fläche der Aktivkohle, durch seine extrem dünne Schichtdicke, zur sehr hohen Kapazität bei.<br />
Im Gegensatz zu einer Batterie kann der Doppelschichtkondensator Energie sehr schnell aufnehmen und abgeben, und altert dabei nur im geringen Maße. 500000 Lade-/Entladezyklen sind erreichbar, wenn die Spannung pro Zelle nicht überschritten wird. Normal sind hier 2,3..2,5V.<br />
<br />
== Anwendungen ==<br />
Hier wird für verschiedene Anwendungsfälle eine sinnvolle Lösung empfohlen.<br />
<br />
{| class="wikitable"<br />
| '''Anwendung''' || '''Beispiel''' || '''Empfohlener Typ''' ||'''Kommentar'''<br />
|-<br />
| Stromversorgung || Netzteil|| Elko||<br />
|- <br />
| Stromversorgung || Zwischenkreis|| Elkos, Folienkondensatoren||<br />
|-<br />
| Datenerhalt || || Doppelschichtkondensator ||<br />
|-<br />
| Energiespeicher|| digitale Schaltungen|| Kerko || z.B. 47nF pro IC bzw. Vcc-Anschluß<br />
|- <br />
| Hohe Impulsenergie x00ms || Impulsschweißgerät, (capacitive discharge)|| Elko (Folie)||<br />
|-<br />
| Impulsfeste Kondensatoren || Coils shrinker, Coilgun, Railgun|| Folie||MKT10 oder noch besser FKT1<br />
|-<br />
| NF-Filter|| PWM als DAC || Tako/Elko/Kerko ||<br />
|-<br />
| HF-Filter|| Beispiel || Styroflex-Folie ||<br />
|-<br />
| Audio || Kopplung || Folie ||<br />
|-<br />
| Vorwiderstand || Motorkondensator || MP oder Folie ||<br />
|-<br />
| Vorwiderstand || Kondensatornetzteil|| Kerko/Folie || Achtung, nur X2-Typen!<br />
|}<br />
<br />
== Mathematik zum Kondensator ==<br />
<br />
Die Größe eines Kondensators ist seine Kapazität (Formelzeichen ''C''), die als Ladung (Formelzeichen ''Q'') durch Spannung (Formelzeichen ''U'') definiert ist.<br />
<br />
<math>C=\frac{Q}{U}</math><br />
<br />
Die Einheit für die Kapazität ist Farad:<br />
<br />
<math> [C]=F=\frac{As}{V}</math><br />
<br />
=== Reihenschaltung ===<br />
<br />
Für eine Reihenschaltung von ''n'' Kondensatoren gilt:<br />
<br />
<math>\frac{1}{C_{ges}}=\frac{1}{C_1}+\frac{1}{C_2}+\dots+\frac{1}{C_n}</math><br />
<br />
<math>U_{ges}=U_1+U_2+\dots+U_n</math><br />
<br />
<math>I_{ges}=I_1=I_2=\dots=I_n</math><br />
<br />
===Parallelschaltung ===<br />
<br />
Für eine Parallelschaltung von ''n'' Kondensatoren gilt:<br />
<br />
<math>C_{ges}=C_1+C_2+\dots+C_n</math><br />
<br />
<math>U_{ges}=U_1=U_2=\dots=U_n</math><br />
<br />
<math>I_{ges}=I_1+I_2+\dots+I_n</math><br />
<br />
===Gespeicherte Energie ===<br />
<br />
Die in einem Kondensator gespeicherte Energie lässt sich durch die Formel<br />
<br />
<math> W=\frac{C}{2} \cdot U^2 = \frac{1}{2 \cdot C} \cdot Q^2 = \frac{U}{2} \cdot Q </math><br />
<br />
berechnen.<br />
<br />
== Praxis ==<br />
<br />
=== Polaritätszeichen ===<br />
<br />
Elektrolytkondensatoren (kurz Elkos) sind in der Regel gepolt, d. h. Gleichspannungspegel müssen in einer vorgeschriebenen Polarität angelegt werden, damit das Dielektrikum nicht zerstört wird. Bei Aluminium-Elkos wird dabei generell der Minuspol gekennzeichnet, bei kleinen Bauformen mit einem Strich, bei größeren Bauformen befinden sich u. U. auch noch Minuszeichen in diesem Strich eingebettet. Bei Tantal-Elkos hingegen wird immer der Pluspol gekennzeichnet, sowohl bei SMD als auch THT-Bauformen.<br />
<br />
[[Bild:SMD-Elkos.jpeg]]<br />
<br />
Die gezeigten Elkos haben folgende Werte (von links nach rechts):<br />
<br />
* 220 µF, Spannungsfestigkeit 6 V<br />
* 100 µF (<math>10 \cdot 10^7</math> pF), 16 V<br />
* 22 µF, 10 V<br />
* 1 µF, 35 V<br />
* 2,2 µF (<math>22 \cdot 10^5</math> pF), 10 V<br />
<br />
Die beim 100-µF-Kondensator zu findende Buchstabenschreibweise für die Spannungsfestigkeit ist wenig gebräuchlich, aber gelegentlich anzutreffen. Die Zuordnung ist:<br />
<br />
{| class="wikitable"<br />
| style="width:8em" | '''Buchstabe''' || e || g || j || A || C || D || E || V || H || J || K<br />
|-<br />
| '''Spannungs-'''<br>'''festigkeit /V''' || 2.5 || 4 || 6,3 || 10 || 16 || 20 || 25 || 35 || 50 || 63 || 80<br />
|}<br />
<br />
Die Spannungsfestigkeit kann auch durch eine zweistellige Kombination aus einer Ziffer und einem Buchstaben codiert sein:<br />
<br />
{| class="wikitable"<br />
| style="width:8em" | '''Kombination''' || 0G || 0L || 0J || 1A || 1C || 1E <br />
|-<br />
| '''Spannungs-'''<br>'''festigkeit /V''' || 4,0 || 5,5 || 6,3 || 10 || 16 || 20 <br />
|-<br />
|<br />
|-<br />
| '''Kombination''' || 1H || 1J || 1K || 2A || 2Q || 2B <br />
|-<br />
| '''Spannungs-'''<br>'''festigkeit /V''' || 50 || 63 || 80 || 100 || 110 || 125 <br />
|-<br />
|<br />
|-<br />
| '''Kombination''' || 2C || 2Z || 2D || 2P || 2E || 2F<br />
|- <br />
| '''Spannungs-'''<br>'''festigkeit /V''' || 160 || 180 || 200 || 220 || 250 || 315 <br />
|-<br />
|<br />
|-<br />
| '''Kombination''' || 2V || 2G || 2W || 2H || 2J || 3A<br />
|-<br />
| '''Spannungs-'''<br>'''festigkeit /V''' || 350 || 400 || 450 || 500 || 630 || 1000 <br />
|}<br />
<br />
{| class="wikitable"<br />
| '''Case Code''' (Bauform) || A || B || C || D <br />
|-<br />
| '''EIA Code''' || 3216 || 3528 || 6032 || 7343<br />
|-<br />
| '''Länge''' (mm) || 3,2 || 3,5 || 6,0 || 7,3 <br />
|-<br />
| '''Breite''' (mm) || 1,6 || 2,8 || 3,2 || 4,3 <br />
|-<br />
| '''Höhe''' (mm) || 1,6 || 1,9 || 2,5 || 2,8 <br />
|-<br />
| Maßtoleranz (mm) || 0,2 || 0,2 || 0,3 || 0,3 <br />
|}<br />
<br />
=== Siebkondensator ===<br />
<br />
Der Siebkondensator sitzt hinter einem Gleichrichter und hat die Aufgabe, aus einer gleichgerichteten, pulsierenden Spannung, eine annähernd konstante Gleichspannung mit nur wenig Welligkeit (engl. Ripple) zu machen. Er wird periodisch geladen und muss während der Ladepausen, wenn die Eingangssspannung vor dem Gleichrichter kleiner als die Ausgangsspannung ist, den Ausgang mit Strom versorgen. Man findet ihn in allen klassischen Netzteilen mit 50Hz Trafo. Als Daumenregel kann man sich merken, dass man pro 1A Ausgangsstrom ca. 10mF braucht, um eine Welligkeit von ca. 1Vpp zu erreichen.<br />
<br />
Einen Siebkondensator findet man auch am Ausgang von Schaltnetzteilen, seine Aufgabe ist dort die gleiche. Allerdings sind die Schaltfrequenzen deutlich höher, typisch 50-500kHz. Darum muss dieser Kondensator einen besonders kleinen, effektiven Innenwiderstand besitzen (engl. ESR, Equivalent Series Resistance).<br />
<br />
=== Entkoppelkondensator ===<br />
<br />
Der Entkoppelkondensator hat die Aufgabe, die Versorgungsspannung nahe an einem IC für hochfrequente Ströme zu puffern (entkoppeln, engl. decoupling). Schnelle Digital- und Analogschaltungen benötigen vor allem beim Umschalten sehr schnell viel Strom, in der Größenordnung von Nanosekunden bis Mikrosekunden, je nach IC Milliampere bis Ampere. Diese müssen mit möglichst geringem Widerstand und Induktivität geliefert werden. Ein Stromversorgungsnetz auf einer Platine kann das meist nur unzureichend, dazu sind die Leitungen meist zu lang und damit die Induktivität zu hoch. Ein nah am IC platzierter Kondensator liefert diesen Strom für kurze Zeit, ohne dass die Spannung nennenswert einbricht. Die Entkopplung der Stromversorgung geschieht meist mehrstufig, d.h. es werden Kondensatoren verschiedener Arten und Kapazitäten eingesetzt, siehe [[Stromversorgung für FPGAs]].<br />
<br />
Praktische Anwendung<br />
<br />
* '''Jeder''' Digitalschaltkreis benötigt einen 100nF Keramikkondensator nah (kleiner 20mm) an den Anschlüssen von VCC und GND. Je schneller der IC schalten kann, umso wichtiger ist er und umso näher muss er platziert werden. Ein "langsamer" IC wie ein AVR Mikrocontroller verkraftet 20mm, im Ausnahmefall auch mehr. Ein deutlich schnellerer IC wie moderne FPGAs, große CPUs, sehr schnelle ASICs etc. sind da anspruchsvoller, vor allem wenn die Schaltung stabil laufen soll. Dann muss man möglichst jeden Millimeter Leiterbahn zwischen Pin und Kondensator einsparen, soweit das mechanisch geht.<br />
* Für '''jedes''' Anschlusspaar von VCC und GND eines ICs muss ein Kondensator verwendet werden. Sparen geht hier oft schief!<br />
* Für die Verbindung der Entkoppelkondensatoren zur Masse- bzw. Versorgungsfläche sollte man möglichst je Kondensator ein VIA benutzen und nicht über ein VIA mehrere Kondensatoren verbinden. Dadurch wird die parasitäre Induktivität vermindert.<br />
* Schnelle Analogschaltkreise wie Operationsverstärker, [[Treiber]] etc. brauchen auch individuelle Entkoppelkondensatoren.<br />
* Pi mal Daumen gilt: Je größer der Kondensator, umso weiter kann er von dem Verbraucher weg sein, da er auf Grund seines Innenwiderstands (ESR, ESL) weniger HF-tauglich ist. Es ist somit nicht sinnvoll, einen 1000µF Elektrolytkondensator 10mm neben einen Digital-IC setzen zu wollen. Dort gehört der 100nF Keramikkondensator hin. Aber für die Stromversorgung von Motoren, Treibern und [[H-Brücken Übersicht|H-Brücken]] sind derartige großen Kondensatoren wichtig und sollten nicht zu weit entfernt sein.<br />
<br />
=== Koppelkondensator ===<br />
<br />
Koppelkondensatoren verbinden Verstärkerstufen. Dabei wird jedoch nur der Wechselanteil übertragen, kein Gleichanteil. Diese Kondensatoren müssen möglichst verzerrungsarm sein, vor allem im Audiobereich. Das wird durch die richtige Wahl des Dielektrikums erreicht.<br />
<br />
=== Forumsbeiträge ===<br />
<br />
* [http://www.mikrocontroller.net/topic/43762 Abblockkondensator: Kerko (Keramik) oder Folie?]<br />
* [http://www.mikrocontroller.net/topic/62576 Brennende Tantalkondensatoren]<br />
* [http://www.mikrocontroller.net/topic/108865#963281 Kodierung (Umwandlung)]<br />
* [http://www.mikrocontroller.net/topic/169958#1624840 Unterschied: Elektrolytkondensator vs. Tantalkondensator]<br />
* [http://www.mikrocontroller.net/topic/195563#1915294 Unterschied: C0G vs. Glimmer]<br />
* [http://www.mikrocontroller.net/topic/264347#2748845 Kurze Beschreibung verschiedener Folienkondensatoren]<br />
* [http://www.mikrocontroller.net/topic/108865#1356075 PC Tool zum Identifizieren von Kondensatoren]<br />
* [https://www.mikrocontroller.net/topic/436472#5164488 Kräftige Ladepumpe 12V?], wie Ladungspumpen effizient arbeiten<br />
* [https://www.mikrocontroller.net/topic/470224#5763932 MMLC Kondensatoren Bauform reduzieren]<br />
* [https://www.mikrocontroller.net/topic/440901#5264220 1F-Kondensator laden & entladen]<br />
<br />
== Weblinks ==<br />
<br />
* [http://my.execpc.com/~endlr/index.html CapSite 2009] - Introduction To Capacitors<br />
* [http://www.cde.com/catalogs/AEappGUIDE.pdf Aluminum Electrolytic Capacitor Application Guide] von CDE Cornell Dubilier<br />
* Sehr ausf&uuml;hrliche Artikel bei Wikipedia<br />
** [http://de.wikipedia.org/wiki/Elektrolytkondensator Elektrolytkondensator]<br />
** [http://de.wikipedia.org/wiki/Polymer-Elektrolytkondensator Polymer-Elkos]<br />
** [http://de.wikipedia.org/wiki/Aluminium-Elektrolytkondensator Al-(Polymer-)Elkos]<br />
** [http://de.wikipedia.org/wiki/Tantal-Elektrolytkondensator Niob- und Tantal-(Polymer-)Elkos]<br />
* Anwendungen<br />
** [http://www.radio-electronics.com/info/data/capacitor/capacitor_types.php Capacitor types and their uses] (engl.)<br />
** [http://www.planetanalog.com/features/showArticle.jhtml;jsessionid=23?articleID=199905522 Choosing and Using Bypass Capacitors] (dreiteilige Artikelserie) bei [http://www.planetanalog.com www.planetanalog.com]<br />
** [http://www.vagrearg.org/?p=decoupling Decoupling by Example]<br />
* Video-Tutorials<br />
** EEVblog #33 – Capacitor Tutorial [http://www.eevblog.com/2009/09/26/eevblog-33-1of2-capacitor-tutorial-electrolytic-tantalum-and-plastic-film/ Teil 1: Electrolytic, Tantalum, and Plastic Film] und [http://www.eevblog.com/2009/09/26/eevblog-33-2of2-capacitor-tutorial-ceramics-and-impedance/ Teil 2: Ceramics and impedance]<br />
* [http://www.maximintegrated.com/app-notes/index.mvp/id/5527 Tutorial] von Maxim, "Temperature and Voltage Variation of Ceramic Capacitors, or Why Your 4.7µF Capacitor Becomes a 0.33µF Capacitor", engl.<br />
* [http://www.wima.de/DE/characteristics.htm Vergleichstabelle] der Eigenschaften von Folien- und Keramikkondensatoren, WIMA<br />
* [http://portal.national.com/rap/Application/0,1570,28,00.html] Bob Pease: "Understand Capacitor Soakage to Optimize Analog Systems"<br />
* [http://www.youtube.com/watch?v=AP_FSyWGpoE Youtube-Video zum Thema Abblockkondensatoren (Deutsch)]<br />
* [http://www.lothar-miller.de/s9y/categories/14-Entkopplung Entkopplung] von ICs, von Lothar Miller<br />
<br />
[[Category:Bauteile]]<br />
[[Category:Grundlagen]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=Kondensator&diff=107596Kondensator2025-08-04T08:25:40Z<p>Heha: /* Folien-Kondensator */</p>
<hr />
<div>Ein '''Kondensator''' ist ein passives elektrisches Bauteil mit zwei Anschlüssen, welches elektrische Energie in einem elektrischen Feld in Form von Ladung speichert. Die charakteristische Größe, die den Kondensator beschreibt, ist die Kapazität C, gemessen in Farad (F). Ein Kondensator besteht aus zwei Flächen gut leitfähigen Materials, die voneinander isoliert sind. Das Isolationsmaterial ist ein Dielektrikum und verleiht dem Kondensator je nach Material stark unterschiedliche Eigenschaften.<br />
<br />
== Aufbau eines Kondensators ==<br />
Je größer die Fläche, je geringer der Abstand der Flächen und je höher die relative Permittivität \varepsilon_r - das Dielektrikum - desto höher ist die Kapazität des Bauteils. Der einfachste Kondensator besteht aus zwei voneinander isolierten Metallplatten, zwischen denen sich Luft als "Dielektrikum" befindet. Um die Fläche und damit die Kapazität zu vergrößern gibt es verschiedene Möglichkeiten:<br />
<br />
=== Wickelkondensator ===<br />
Die einfachste Methode die Flächen zu vergrößern ist es, zwei leitfähige Folien mit einem Isolationsmaterial dazwischen aufzuwickeln. Diese Methode wird für so ziemlich alle Kondensatortypen verwendet. Manchmal wird der Wickel nach der Herstellung flachgepresst, um das Volumen zu optimieren.<br />
<br />
=== Schichtkondensator ===<br />
Diese Aufbauart wird durch "stapeln" der unterschiedlichen Lagen erreicht. Verfahrenstechnisch ist dies oft wieder ein Wickel, jedoch meist auf bis zu 2 Meter durchmessenden Wickelrädern. Dieses ursprünglich von Siemens eingesetzte Verfahren wird auch aktuell noch verwendet, hauptsächlich für Folienkondensatoren bis in den mF-Bereich hinein. Nach dem Wickeln auf vieleckigen Rädern wird der Folienstapel geschnitten und auf die gewünschte Größe = Kapazität getrennt.<br />
<br />
=== Zusammenhang Baugröße, Spannung, Kapazität ===<br />
Abgesehen vom Einfluss des Dielektrikums geht das Bauvolumen grundsätzlich linear zur Kapazität und quadratisch(!) zur Spannungsfestigkeit. Denn zur Verdopplung der Kapazität verdoppelt man die Kondensatorfläche, entsprechend einer Parallelschaltung von Kondensatoren. Zur Verdopplung der Spannungsfestigkeit wird wie bei einer Reihenschaltung die Dicke des Dielektrikums verdoppelt, was mit einer Halbierung der Kapazität einhergeht: Bei gleicher Kapazität muss daher auch die Kondensatorfläche verdoppelt werden.<br />
<br />
Somit ist das Bauvolumen direkt proportional zum maximalen Energiegehalt des Kondensators.<br />
<br />
== Kondensatortypen ==<br />
(Vakuum-, Glimmer-, Gas- und Glaskondensatoren nicht berücksichtigt)<br />
=== Keramik-Kondensator ===<br />
Siehe auch den Artikel '''Keramikkondensator in [https://de.wikipedia.org/wiki/Keramikkondensator#Spannungsabh.C3.A4ngigkeit_der_Kapazit.C3.A4t Wikipedia]'''. Es gibt sie bedrahtet und in SMD. Bedrahtet gab es sie früher als Einschicht-Kapazität in Scheibenform, heutzutage nur noch als Vielschicht-Kondensator. Einschichtig nur für Spannungen im Kilovolt-Bereich.<br />
<br />
Kerkos sind sogenannte "Vielschicht-Kondensatoren" die aus mehreren hundert Lagen einer isolierenden Keramik (Titandioxid+Bariumtitanat), und einer elektrisch leitfähigen Metallisierung (Aluminium & Magnesiumsilikate) bestehen.<br />
Dieser Typ ist wie der Folienkondensator für höchste Frequenzen geeignet, hat eine sehr geringe Baugröße, eine gute Temperaturstabilität aber piezoelektrische Eigenschaften. Die Kapazität pro mm³ variiert je nach Dielektrikum Z5U, Y5V, X7R, C0 (in abnehmender Kapazitätsdichte) und ist sowohl abhängig von Temperatur als auch der angelegten Spannung.<br />
<br />
Keramik-Kondensatoren sind sehr preisgünstig und werden überall dort eingesetzt, wo andere Kondensatortypen keinen Vorteil bringen. Zudem lösen sie mehr und mehr Elektrolytkondensatoren ab, die ihrerseits mit hoher Kapazität punkten: Die Lebensdauer, besonders bei hoher Temperatur, ist höher.<br />
<br />
=== Folien-Kondensator ===<br />
Siehe auch den Artikel '''Folienkondensator in [https://de.wikipedia.org/wiki/Kunststoff-Folienkondensator Wikipedia]'''.<br />
<br />
Unterschiedliche Folienarten verleihen dem Kondensator stark unterschiedliche Eigenschaften wie z.B. temperatur- und alterungsbeständigkeit, Verlustfaktor, Isolationswiderstand, und die obere Grenzfrequenz, um nur die wichtigsten zu nennen. Die Dicke der Metallisierung hingegen entscheidet über den maximal zulässigen Rippelstrom / Impulsstromfestigkeit und darüber, ob sich ein Kondensator "selbst heilen" kann, oder nicht. Das Verfahren der "Selbstheilung" funktioniert nur bei Metallisierungen, da es darauf beruht, daß die im C gespeicherte Energie den Metallbelag beim Durchschlag durch die Isolation verdampfen kann. Ist die Energie zu gering, wird nur wenig Metall um den Durchschlag verdampft, und der Kurzschluß bleibt bestehen. Ist die Energie zu hoch, wird der Kondensator thermisch zerstört. Hat der C den richigen Energiegehalt, verdampft direkt um die Durchschlagstelle herum bis zu einigen mm der Metallisierung, und die Fehlstelle ist wieder isoliert. Im Übrigen ist eine Parallelsschaltung aus vielen,als selbstheilenden C's nicht unbedingt mehr "selbstheilend" da der Energieeintrag dann aus dem Gesamtverbund kommt, und oft zu hoch ist um nur eine kleine Fläche verdampfen zu lassen.<br />
Impulsstrom-feste Kondensatoren zeichnen sich durch hohe Schichtstärken der Metallisierung aus, oder verwenden statt der Metallbeschichtung direkt eine Metallfolie. Hier wäre normalerweise ein "selbstheilen" gleichbedeutend mit einem so hohen Energieeintrag, daß das Bauteil zerstört wird.<br />
<br />
Hier eine kleine Übersicht mit der Bitte um Vervollständigung.<br />
<br />
{| class="wikitable"<br />
| style="width:8em"| '''Folientyp''' || Poly-<br>propylen || Poly-<br>styren || Poly-<br>carbonat ||Poly-<br>ester|| Poly-<br>styrol || Poly-<br>ethylen-<br>naphthalat || Polytetra-<br>fluor-<br>ethylen || Poly-<br>phenylen-<br>sulfid || Metall-<br>Papier <br />
|-<br />
| '''Folien-'''<br>'''markenname''' || Hostalen || - || Makrofol, Makroflex || Mylar, Hostaphan || Styroflex || Kaladex|| Teflon|| Tedur, Ryton|| Papier<br />
|-<br />
| '''Abkürzung''' || PP || - || PC|| PET || PS|| PEN|| PTFE|| PPS|| - <br />
|-<br />
| '''Typ''' || (F)KP, MKP || -KS, MKS || KC, MKC || (F)KT, MKT || -KS, MKS || (F)KN, MKN|| -|| (F)KI, MKI|| MP <br />
|-<br />
| '''Temperatur-'''<br>'''festigkeit /°C''' || ca 105 || - || ca. 105 || 125..150 || - || 150 || -|| 150 || 85 <br />
|-<br />
| '''Toleranz'''<br>'''+/-%''' || 1 || 1 || -|| 1 || - || -|| -|| -|| 20 <br />
|-<br />
| '''Grenzfrequenz /kHz''' || 100 || 400 || -|| - || 1000 || -|| -|| -|| - <br />
|-<br />
| '''Selbstheilend''' || ja || - || -|| ja || - || -|| -|| -|| ja <br />
|-<br />
| '''Impuls-'''<br>'''belastbarkeit''' || + || + || || + || -- || -|| -|| -|| + <br />
|}<br />
(MK) = metallisierte Folie, (F) = Metallbeläge z.B. Metallfolie (K) = Metallfolie+Kunststofffolie<br />
<br />
Für die Anwendung in Kondensatornetzteilen ist die Anwendung des Selbstheilungseffekts '''erforderlich'''. Daher findet man an dieser Stelle faktisch keine Keramikkondensatoren.<br />
<br />
=== Elektrolyt-Kondensator ===<br />
Ein Elko unterscheidet sich hauptsächlich dadurch von anderen Kondensatoren, daß nur eine Elektrode aus einer Metallschicht besteht, die zweite aus einem festen, oder flüssigen Elektrolyten.<br />
<br />
Siehe auch den Artikel '''Elektrolytkondensator in [https://de.wikipedia.org/wiki/Elektrolytkondensator Wikipedia]'''.<br />
<br />
==== Fest-Elektrolyt ====<br />
Diese Bauteile bestehen aus Polymeren, Metalloxiden, Braunstein, ... und sind wie die Elkos immer gepolt.<br />
Als Metalloxide ist Tantal sehr, und Niob noch weniger verbreitet.<br />
Takos sind '''SEHR''' empfindlich gegenüber schnellen Spannungsanstiegen bzw. Überspannung und sollten nie ohne Vorwiderstand direkt an einer niederohmigen Quelle (Batterie) geladen/betrieben werden. Takos verbrennen im Fehlerfall mit einer Stichflamme, daher empfiehlt es sich eine deutlich höhere Spannungsfestigkeit zu wählen und - bei direktem Anschluß an eine niederohmige Quelle - zusätzlich ein Lade-Vorwiderstand einzubauen. Treten zusätzlich hohe Temperaturen auf, ist die Spannungsfestigkeit mindestens zu verdoppeln.<br />
Kondensatoren mit Niob statt Tantal sind weniger verbreitet, und noch sehr teuer. Ihr Vorteil ist z.B. die Unempfindlichkeit gegenüber schnellen Spannungsanstiegen, sie können direkt an jeder Quelle betrieben werden.<br />
<br />
==== Flüssig-Elektrolyt ====<br />
Diese Bauteile bestehen aus zwei Lagen '''sehr stark angeätzter''' Aluminiumfolie - zur Vergrößerung der Oberfläche - und einem flüssigen (seltener "einem festen") Elektrolyten. Die zweite Folie kontaktiert gleichzeitig den Elektrolyten. Der Elektrolyt ist häufig auf Alkoholen basierend, aus/mit Schwefelsäure oder Glykol.<br />
Die Alufolie wird nach den ätzen anodisch oxidiert. Die Eloxal-Schicht ist mechanisch belastbar, und stellt die '''einzige''' Isolation zwischen den beiden Anschlüssen dar. Die Oxidation der Alufolie wird je nach Hersteller bei ca. 140..165% der Nennspannung durchgeführt. Die Oxidschicht baut sich durch den Elektrolyten bei langer Lagerung stark ab, daher sinkt die Spannungsfestigkeit eines Elkos mit seinem Alter. Alte Bauteile können - sofern noch Elektrolyt enthalten ist - durch spannungsrichtiges Anschließen an eine Spannungsquelle und langsamen erhöhen der Spannung bis über die Nennspannung hinaus wieder "formiert" werden. Achtung, hier besteht die Gefahr eines Kurzschlusses zwischen den Anschlüssen, daher hochohmigen Vorwiderstand verwenden!<br />
Wird ein Elko verpolt betrieben, wird die Oxidschicht im Laufe der Zeit (Abhängig von Spannung und Temperatur) abgebaut, und der Kondensator schlägt durch.<br />
<br />
=== Doppelschicht-Kondensatoren ===<br />
Siehe auch den Artikel '''Superkondensator in [https://de.wikipedia.org/wiki/Superkondensator Wikipedia]'''.<br />
<br />
Diese Bauteile werden unter Markennamen wie "Goldcap", "Ultracap" oder "Supercap" vertrieben, besitzen meist ein flüssiges Elektrolyt haben aber nicht besonders viel mit den o.g. "Elektrolytkondensatoren" gemeinsam. Dieser Kondensator besitzt Eigenschaften eines Kondensators und einer Batterie. Der "Kondensator" ist hier aus (im Gegensatz zum Elko) zwei Lagen einer einseitig metallisierten Aktivkohle, einem Separator, und einem Elektrolyten. <br />
Das verwendete Elektrolyt erfüllt unter definierten Betriebsbedingungen die Funktion eines zusätzlichen Dielektrikums, und trägt zusätzlich zur ohnehin schon sehr großen Fläche der Aktivkohle, durch seine extrem dünne Schichtdicke, zur sehr hohen Kapazität bei.<br />
Im Gegensatz zu einer Batterie kann der Doppelschichtkondensator Energie sehr schnell aufnehmen und abgeben, und altert dabei nur im geringen Maße. 500000 Lade-/Entladezyklen sind erreichbar, wenn die Spannung pro Zelle nicht überschritten wird. Normal sind hier 2,3..2,5V.<br />
<br />
== Anwendungen ==<br />
Hier wird für verschiedene Anwendungsfälle eine sinnvolle Lösung empfohlen.<br />
<br />
{| class="wikitable"<br />
| '''Anwendung''' || '''Beispiel''' || '''Empfohlener Typ''' ||'''Kommentar'''<br />
|-<br />
| Stromversorgung || Netzteil|| Elko||<br />
|- <br />
| Stromversorgung || Zwischenkreis|| Elkos, Folienkondensatoren||<br />
|-<br />
| Datenerhalt || || Doppelschichtkondensator ||<br />
|-<br />
| Energiespeicher|| digitale Schaltungen|| Kerko || z.B. 47nF pro IC bzw. Vcc-Anschluß<br />
|- <br />
| Hohe Impulsenergie x00ms || Impulsschweißgerät, (capacitive discharge)|| Elko (Folie)||<br />
|-<br />
| Impulsfeste Kondensatoren || Coils shrinker, Coilgun, Railgun|| Folie||MKT10 oder noch besser FKT1<br />
|-<br />
| NF-Filter|| PWM als DAC || Tako/Elko/Kerko ||<br />
|-<br />
| HF-Filter|| Beispiel || Styroflex-Folie ||<br />
|-<br />
| Audio || Kopplung || Folie ||<br />
|-<br />
| Vorwiderstand || Motorkondensator || MP oder Folie ||<br />
|-<br />
| Vorwiderstand || Kondensatornetzteil|| Kerko/Folie || Achtung, nur X2-Typen!<br />
|}<br />
<br />
== Mathematik zum Kondensator ==<br />
<br />
Die Größe eines Kondensators ist seine Kapazität (Formelzeichen ''C''), die als Ladung (Formelzeichen ''Q'') durch Spannung (Formelzeichen ''U'') definiert ist.<br />
<br />
<math>C=\frac{Q}{U}</math><br />
<br />
Die Einheit für die Kapazität ist Farad:<br />
<br />
<math> [C]=F=\frac{As}{V}</math><br />
<br />
=== Reihenschaltung ===<br />
<br />
Für eine Reihenschaltung von ''n'' Kondensatoren gilt:<br />
<br />
<math>\frac{1}{C_{ges}}=\frac{1}{C_1}+\frac{1}{C_2}+\dots+\frac{1}{C_n}</math><br />
<br />
<math>U_{ges}=U_1+U_2+\dots+U_n</math><br />
<br />
<math>I_{ges}=I_1=I_2=\dots=I_n</math><br />
<br />
===Parallelschaltung ===<br />
<br />
Für eine Parallelschaltung von ''n'' Kondensatoren gilt:<br />
<br />
<math>C_{ges}=C_1+C_2+\dots+C_n</math><br />
<br />
<math>U_{ges}=U_1=U_2=\dots=U_n</math><br />
<br />
<math>I_{ges}=I_1+I_2+\dots+I_n</math><br />
<br />
===Gespeicherte Energie ===<br />
<br />
Die in einem Kondensator gespeicherte Energie lässt sich durch die Formel<br />
<br />
<math> W=\frac{C}{2} \cdot U^2 = \frac{1}{2 \cdot C} \cdot Q^2 = \frac{U}{2} \cdot Q </math><br />
<br />
berechnen.<br />
<br />
== Praxis ==<br />
<br />
=== Polaritätszeichen ===<br />
<br />
Elektrolytkondensatoren (kurz Elkos) sind in der Regel gepolt, d. h. Gleichspannungspegel müssen in einer vorgeschriebenen Polarität angelegt werden, damit das Dielektrikum nicht zerstört wird. Bei Aluminium-Elkos wird dabei generell der Minuspol gekennzeichnet, bei kleinen Bauformen mit einem Strich, bei größeren Bauformen befinden sich u. U. auch noch Minuszeichen in diesem Strich eingebettet. Bei Tantal-Elkos hingegen wird immer der Pluspol gekennzeichnet, sowohl bei SMD als auch THT-Bauformen.<br />
<br />
[[Bild:SMD-Elkos.jpeg]]<br />
<br />
Die gezeigten Elkos haben folgende Werte (von links nach rechts):<br />
<br />
* 220 µF, Spannungsfestigkeit 6 V<br />
* 100 µF (<math>10 \cdot 10^7</math> pF), 16 V<br />
* 22 µF, 10 V<br />
* 1 µF, 35 V<br />
* 2,2 µF (<math>22 \cdot 10^5</math> pF), 10 V<br />
<br />
Die beim 100-µF-Kondensator zu findende Buchstabenschreibweise für die Spannungsfestigkeit ist wenig gebräuchlich, aber gelegentlich anzutreffen. Die Zuordnung ist:<br />
<br />
{| class="wikitable"<br />
| style="width:8em" | '''Buchstabe''' || e || g || j || A || C || D || E || V || H || J || K<br />
|-<br />
| '''Spannungs-'''<br>'''festigkeit /V''' || 2.5 || 4 || 6,3 || 10 || 16 || 20 || 25 || 35 || 50 || 63 || 80<br />
|}<br />
<br />
Die Spannungsfestigkeit kann auch durch eine zweistellige Kombination aus einer Ziffer und einem Buchstaben codiert sein:<br />
<br />
{| class="wikitable"<br />
| style="width:8em" | '''Kombination''' || 0G || 0L || 0J || 1A || 1C || 1E <br />
|-<br />
| '''Spannungs-'''<br>'''festigkeit /V''' || 4,0 || 5,5 || 6,3 || 10 || 16 || 20 <br />
|-<br />
|<br />
|-<br />
| '''Kombination''' || 1H || 1J || 1K || 2A || 2Q || 2B <br />
|-<br />
| '''Spannungs-'''<br>'''festigkeit /V''' || 50 || 63 || 80 || 100 || 110 || 125 <br />
|-<br />
|<br />
|-<br />
| '''Kombination''' || 2C || 2Z || 2D || 2P || 2E || 2F<br />
|- <br />
| '''Spannungs-'''<br>'''festigkeit /V''' || 160 || 180 || 200 || 220 || 250 || 315 <br />
|-<br />
|<br />
|-<br />
| '''Kombination''' || 2V || 2G || 2W || 2H || 2J || 3A<br />
|-<br />
| '''Spannungs-'''<br>'''festigkeit /V''' || 350 || 400 || 450 || 500 || 630 || 1000 <br />
|}<br />
<br />
{| class="wikitable"<br />
| '''Case Code''' (Bauform) || A || B || C || D <br />
|-<br />
| '''EIA Code''' || 3216 || 3528 || 6032 || 7343<br />
|-<br />
| '''Länge''' (mm) || 3,2 || 3,5 || 6,0 || 7,3 <br />
|-<br />
| '''Breite''' (mm) || 1,6 || 2,8 || 3,2 || 4,3 <br />
|-<br />
| '''Höhe''' (mm) || 1,6 || 1,9 || 2,5 || 2,8 <br />
|-<br />
| Maßtoleranz (mm) || 0,2 || 0,2 || 0,3 || 0,3 <br />
|}<br />
<br />
=== Siebkondensator ===<br />
<br />
Der Siebkondensator sitzt hinter einem Gleichrichter und hat die Aufgabe, aus einer gleichgerichteten, pulsierenden Spannung, eine annähernd konstante Gleichspannung mit nur wenig Welligkeit (engl. Ripple) zu machen. Er wird periodisch geladen und muss während der Ladepausen, wenn die Eingangssspannung vor dem Gleichrichter kleiner als die Ausgangsspannung ist, den Ausgang mit Strom versorgen. Man findet ihn in allen klassischen Netzteilen mit 50Hz Trafo. Als Daumenregel kann man sich merken, dass man pro 1A Ausgangsstrom ca. 10mF braucht, um eine Welligkeit von ca. 1Vpp zu erreichen.<br />
<br />
Einen Siebkondensator findet man auch am Ausgang von Schaltnetzteilen, seine Aufgabe ist dort die gleiche. Allerdings sind die Schaltfrequenzen deutlich höher, typisch 50-500kHz. Darum muss dieser Kondensator einen besonders kleinen, effektiven Innenwiderstand besitzen (engl. ESR, Equivalent Series Resistance).<br />
<br />
=== Entkoppelkondensator ===<br />
<br />
Der Entkoppelkondensator hat die Aufgabe, die Versorgungsspannung nahe an einem IC für hochfrequente Ströme zu puffern (entkoppeln, engl. decoupling). Schnelle Digital- und Analogschaltungen benötigen vor allem beim Umschalten sehr schnell viel Strom, in der Größenordnung von Nanosekunden bis Mikrosekunden, je nach IC Milliampere bis Ampere. Diese müssen mit möglichst geringem Widerstand und Induktivität geliefert werden. Ein Stromversorgungsnetz auf einer Platine kann das meist nur unzureichend, dazu sind die Leitungen meist zu lang und damit die Induktivität zu hoch. Ein nah am IC platzierter Kondensator liefert diesen Strom für kurze Zeit, ohne dass die Spannung nennenswert einbricht. Die Entkopplung der Stromversorgung geschieht meist mehrstufig, d.h. es werden Kondensatoren verschiedener Arten und Kapazitäten eingesetzt, siehe [[Stromversorgung für FPGAs]].<br />
<br />
Praktische Anwendung<br />
<br />
* '''Jeder''' Digitalschaltkreis benötigt einen 100nF Keramikkondensator nah (kleiner 20mm) an den Anschlüssen von VCC und GND. Je schneller der IC schalten kann, umso wichtiger ist er und umso näher muss er platziert werden. Ein "langsamer" IC wie ein AVR Mikrocontroller verkraftet 20mm, im Ausnahmefall auch mehr. Ein deutlich schnellerer IC wie moderne FPGAs, große CPUs, sehr schnelle ASICs etc. sind da anspruchsvoller, vor allem wenn die Schaltung stabil laufen soll. Dann muss man möglichst jeden Millimeter Leiterbahn zwischen Pin und Kondensator einsparen, soweit das mechanisch geht.<br />
* Für '''jedes''' Anschlusspaar von VCC und GND eines ICs muss ein Kondensator verwendet werden. Sparen geht hier oft schief!<br />
* Für die Verbindung der Entkoppelkondensatoren zur Masse- bzw. Versorgungsfläche sollte man möglichst je Kondensator ein VIA benutzen und nicht über ein VIA mehrere Kondensatoren verbinden. Dadurch wird die parasitäre Induktivität vermindert.<br />
* Schnelle Analogschaltkreise wie Operationsverstärker, [[Treiber]] etc. brauchen auch individuelle Entkoppelkondensatoren.<br />
* Pi mal Daumen gilt: Je größer der Kondensator, umso weiter kann er von dem Verbraucher weg sein, da er auf Grund seines Innenwiderstands (ESR, ESL) weniger HF-tauglich ist. Es ist somit nicht sinnvoll, einen 1000µF Elektrolytkondensator 10mm neben einen Digital-IC setzen zu wollen. Dort gehört der 100nF Keramikkondensator hin. Aber für die Stromversorgung von Motoren, Treibern und [[H-Brücken Übersicht|H-Brücken]] sind derartige großen Kondensatoren wichtig und sollten nicht zu weit entfernt sein.<br />
<br />
=== Koppelkondensator ===<br />
<br />
Koppelkondensatoren verbinden Verstärkerstufen. Dabei wird jedoch nur der Wechselanteil übertragen, kein Gleichanteil. Diese Kondensatoren müssen möglichst verzerrungsarm sein, vor allem im Audiobereich. Das wird durch die richtige Wahl des Dielektrikums erreicht.<br />
<br />
=== Forumsbeiträge ===<br />
<br />
* [http://www.mikrocontroller.net/topic/43762 Abblockkondensator: Kerko (Keramik) oder Folie?]<br />
* [http://www.mikrocontroller.net/topic/62576 Brennende Tantalkondensatoren]<br />
* [http://www.mikrocontroller.net/topic/108865#963281 Kodierung (Umwandlung)]<br />
* [http://www.mikrocontroller.net/topic/169958#1624840 Unterschied: Elektrolytkondensator vs. Tantalkondensator]<br />
* [http://www.mikrocontroller.net/topic/195563#1915294 Unterschied: C0G vs. Glimmer]<br />
* [http://www.mikrocontroller.net/topic/264347#2748845 Kurze Beschreibung verschiedener Folienkondensatoren]<br />
* [http://www.mikrocontroller.net/topic/108865#1356075 PC Tool zum Identifizieren von Kondensatoren]<br />
* [https://www.mikrocontroller.net/topic/436472#5164488 Kräftige Ladepumpe 12V?], wie Ladungspumpen effizient arbeiten<br />
* [https://www.mikrocontroller.net/topic/470224#5763932 MMLC Kondensatoren Bauform reduzieren]<br />
* [https://www.mikrocontroller.net/topic/440901#5264220 1F-Kondensator laden & entladen]<br />
<br />
== Weblinks ==<br />
<br />
* [http://my.execpc.com/~endlr/index.html CapSite 2009] - Introduction To Capacitors<br />
* [http://www.cde.com/catalogs/AEappGUIDE.pdf Aluminum Electrolytic Capacitor Application Guide] von CDE Cornell Dubilier<br />
* Sehr ausf&uuml;hrliche Artikel bei Wikipedia<br />
** [http://de.wikipedia.org/wiki/Elektrolytkondensator Elektrolytkondensator]<br />
** [http://de.wikipedia.org/wiki/Polymer-Elektrolytkondensator Polymer-Elkos]<br />
** [http://de.wikipedia.org/wiki/Aluminium-Elektrolytkondensator Al-(Polymer-)Elkos]<br />
** [http://de.wikipedia.org/wiki/Tantal-Elektrolytkondensator Niob- und Tantal-(Polymer-)Elkos]<br />
* Anwendungen<br />
** [http://www.radio-electronics.com/info/data/capacitor/capacitor_types.php Capacitor types and their uses] (engl.)<br />
** [http://www.planetanalog.com/features/showArticle.jhtml;jsessionid=23?articleID=199905522 Choosing and Using Bypass Capacitors] (dreiteilige Artikelserie) bei [http://www.planetanalog.com www.planetanalog.com]<br />
** [http://www.vagrearg.org/?p=decoupling Decoupling by Example]<br />
* Video-Tutorials<br />
** EEVblog #33 – Capacitor Tutorial [http://www.eevblog.com/2009/09/26/eevblog-33-1of2-capacitor-tutorial-electrolytic-tantalum-and-plastic-film/ Teil 1: Electrolytic, Tantalum, and Plastic Film] und [http://www.eevblog.com/2009/09/26/eevblog-33-2of2-capacitor-tutorial-ceramics-and-impedance/ Teil 2: Ceramics and impedance]<br />
* [http://www.maximintegrated.com/app-notes/index.mvp/id/5527 Tutorial] von Maxim, "Temperature and Voltage Variation of Ceramic Capacitors, or Why Your 4.7µF Capacitor Becomes a 0.33µF Capacitor", engl.<br />
* [http://www.wima.de/DE/characteristics.htm Vergleichstabelle] der Eigenschaften von Folien- und Keramikkondensatoren, WIMA<br />
* [http://portal.national.com/rap/Application/0,1570,28,00.html] Bob Pease: "Understand Capacitor Soakage to Optimize Analog Systems"<br />
* [http://www.youtube.com/watch?v=AP_FSyWGpoE Youtube-Video zum Thema Abblockkondensatoren (Deutsch)]<br />
* [http://www.lothar-miller.de/s9y/categories/14-Entkopplung Entkopplung] von ICs, von Lothar Miller<br />
<br />
[[Category:Bauteile]]<br />
[[Category:Grundlagen]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=Kondensator&diff=107595Kondensator2025-08-04T08:22:31Z<p>Heha: Proportionalitätsbetrachtung</p>
<hr />
<div>Ein '''Kondensator''' ist ein passives elektrisches Bauteil mit zwei Anschlüssen, welches elektrische Energie in einem elektrischen Feld in Form von Ladung speichert. Die charakteristische Größe, die den Kondensator beschreibt, ist die Kapazität C, gemessen in Farad (F). Ein Kondensator besteht aus zwei Flächen gut leitfähigen Materials, die voneinander isoliert sind. Das Isolationsmaterial ist ein Dielektrikum und verleiht dem Kondensator je nach Material stark unterschiedliche Eigenschaften.<br />
<br />
== Aufbau eines Kondensators ==<br />
Je größer die Fläche, je geringer der Abstand der Flächen und je höher die relative Permittivität \varepsilon_r - das Dielektrikum - desto höher ist die Kapazität des Bauteils. Der einfachste Kondensator besteht aus zwei voneinander isolierten Metallplatten, zwischen denen sich Luft als "Dielektrikum" befindet. Um die Fläche und damit die Kapazität zu vergrößern gibt es verschiedene Möglichkeiten:<br />
<br />
=== Wickelkondensator ===<br />
Die einfachste Methode die Flächen zu vergrößern ist es, zwei leitfähige Folien mit einem Isolationsmaterial dazwischen aufzuwickeln. Diese Methode wird für so ziemlich alle Kondensatortypen verwendet. Manchmal wird der Wickel nach der Herstellung flachgepresst, um das Volumen zu optimieren.<br />
<br />
=== Schichtkondensator ===<br />
Diese Aufbauart wird durch "stapeln" der unterschiedlichen Lagen erreicht. Verfahrenstechnisch ist dies oft wieder ein Wickel, jedoch meist auf bis zu 2 Meter durchmessenden Wickelrädern. Dieses ursprünglich von Siemens eingesetzte Verfahren wird auch aktuell noch verwendet, hauptsächlich für Folienkondensatoren bis in den mF-Bereich hinein. Nach dem Wickeln auf vieleckigen Rädern wird der Folienstapel geschnitten und auf die gewünschte Größe = Kapazität getrennt.<br />
<br />
=== Zusammenhang Baugröße, Spannung, Kapazität ===<br />
Abgesehen vom Einfluss des Dielektrikums geht das Bauvolumen grundsätzlich linear zur Kapazität und quadratisch(!) zur Spannungsfestigkeit. Denn zur Verdopplung der Kapazität verdoppelt man die Kondensatorfläche, entsprechend einer Parallelschaltung von Kondensatoren. Zur Verdopplung der Spannungsfestigkeit wird wie bei einer Reihenschaltung die Dicke des Dielektrikums verdoppelt, was mit einer Halbierung der Kapazität einhergeht: Bei gleicher Kapazität muss daher auch die Kondensatorfläche verdoppelt werden.<br />
<br />
Somit ist das Bauvolumen direkt proportional zum maximalen Energiegehalt des Kondensators.<br />
<br />
== Kondensatortypen ==<br />
(Vakuum-, Glimmer-, Gas- und Glaskondensatoren nicht berücksichtigt)<br />
=== Keramik-Kondensator ===<br />
Siehe auch den Artikel '''Keramikkondensator in [https://de.wikipedia.org/wiki/Keramikkondensator#Spannungsabh.C3.A4ngigkeit_der_Kapazit.C3.A4t Wikipedia]'''. Es gibt sie bedrahtet und in SMD. Bedrahtet gab es sie früher als Einschicht-Kapazität in Scheibenform, heutzutage nur noch als Vielschicht-Kondensator. Einschichtig nur für Spannungen im Kilovolt-Bereich.<br />
<br />
Kerkos sind sogenannte "Vielschicht-Kondensatoren" die aus mehreren hundert Lagen einer isolierenden Keramik (Titandioxid+Bariumtitanat), und einer elektrisch leitfähigen Metallisierung (Aluminium & Magnesiumsilikate) bestehen.<br />
Dieser Typ ist wie der Folienkondensator für höchste Frequenzen geeignet, hat eine sehr geringe Baugröße, eine gute Temperaturstabilität aber piezoelektrische Eigenschaften. Die Kapazität pro mm³ variiert je nach Dielektrikum Z5U, Y5V, X7R, C0 (in abnehmender Kapazitätsdichte) und ist sowohl abhängig von Temperatur als auch der angelegten Spannung.<br />
<br />
Keramik-Kondensatoren sind sehr preisgünstig und werden überall dort eingesetzt, wo andere Kondensatortypen keinen Vorteil bringen. Zudem lösen sie mehr und mehr Elektrolytkondensatoren ab, die ihrerseits mit hoher Kapazität punkten: Die Lebensdauer, besonders bei hoher Temperatur, ist höher.<br />
<br />
=== Folien-Kondensator ===<br />
Siehe auch den Artikel '''Folienkondensator in [https://de.wikipedia.org/wiki/Kunststoff-Folienkondensator Wikipedia]'''.<br />
<br />
Unterschiedliche Folienarten verleihen dem Kondensator stark unterschiedliche Eigenschaften wie z.B. temperatur- und alterungsbeständigkeit, Verlustfaktor, Isolationswiderstand, und die obere Grenzfrequenz, um nur die wichtigsten zu nennen. Die Dicke der Metallisierung hingegen entscheidet über den maximal zulässigen Rippelstrom / Impulsstromfestigkeit und darüber, ob sich ein Kondensator "selbst heilen" kann, oder nicht. Das Verfahren der "Selbstheilung" funktioniert nur bei Metallisierungen, da es darauf beruht, daß die im C gespeicherte Energie den Metallbelag beim Durchschlag durch die Isolation verdampfen kann. Ist die Energie zu gering, wird nur wenig Metall um den Durchschlag verdampft, und der Kurzschluß bleibt bestehen. Ist die Energie zu hoch, wird der Kondensator thermisch zerstört. Hat der C den richigen Energiegehalt, verdampft direkt um die Durchschlagstelle herum bis zu einigen mm der Metallisierung, und die Fehlstelle ist wieder isoliert. Im Übrigen ist eine Parallelsschaltung aus vielen,als selbstheilenden C's nicht unbedingt mehr "selbstheilend" da der Energieeintrag dann aus dem Gesamtverbund kommt, und oft zu hoch ist um nur eine kleine Fläche verdampfen zu lassen.<br />
Impulsstrom-feste Kondensatoren zeichnen sich durch hohe Schichtstärken der Metallisierung aus, oder verwenden statt der Metallbeschichtung direkt eine Metallfolie. Hier wäre normalerweise ein "selbstheilen" gleichbedeutend mit einem so hohen Energieeintrag, daß das Bauteil zerstört wird.<br />
<br />
Hier eine kleine Übersicht mit der Bitte um Vervollständigung.<br />
<br />
{| class="wikitable"<br />
| style="width:8em"| '''Folientyp''' || Poly-<br>propylen || Poly-<br>styren || Poly-<br>carbonat ||Poly-<br>ester|| Poly-<br>styrol || Poly-<br>ethylen-<br>naphthalat || Polytetra-<br>fluor-<br>ethylen || Poly-<br>phenylen-<br>sulfid || Metall-<br>Papier <br />
|-<br />
| '''Folien-'''<br>'''markenname''' || Hostalen || - || Makrofol, Makroflex || Mylar, Hostaphan || Styroflex || Kaladex|| Teflon|| Tedur, Ryton|| Papier<br />
|-<br />
| '''Abkürzung''' || PP || - || PC|| PET || PS|| PEN|| PTFE|| PPS|| - <br />
|-<br />
| '''Typ''' || (F)KP, MKP || -KS, MKS || KC, MKC || (F)KT, MKT || -KS, MKS || (F)KN, MKN|| -|| (F)KI, MKI|| MP <br />
|-<br />
| '''Temperatur-'''<br>'''festigkeit /°C''' || ca 105 || - || ca. 105 || 125..150 || - || 150 || -|| 150 || 85 <br />
|-<br />
| '''Toleranz'''<br>'''+/-%''' || 1 || 1 || -|| 1 || - || -|| -|| -|| 20 <br />
|-<br />
| '''Grenzfrequenz /kHz''' || 100 || 400 || -|| - || 1000 || -|| -|| -|| - <br />
|-<br />
| '''Selbstheilend''' || ja || - || -|| ja || - || -|| -|| -|| ja <br />
|-<br />
| '''Impuls-'''<br>'''belastbarkeit''' || + || + || || + || -- || -|| -|| -|| + <br />
|}<br />
(MK) = metallisierte Folie, (F) = Metallbeläge z.B. Metallfolie (K) = Metallfolie+Kunststofffolie<br />
<br />
=== Elektrolyt-Kondensator ===<br />
Ein Elko unterscheidet sich hauptsächlich dadurch von anderen Kondensatoren, daß nur eine Elektrode aus einer Metallschicht besteht, die zweite aus einem festen, oder flüssigen Elektrolyten.<br />
<br />
Siehe auch den Artikel '''Elektrolytkondensator in [https://de.wikipedia.org/wiki/Elektrolytkondensator Wikipedia]'''.<br />
<br />
==== Fest-Elektrolyt ====<br />
Diese Bauteile bestehen aus Polymeren, Metalloxiden, Braunstein, ... und sind wie die Elkos immer gepolt.<br />
Als Metalloxide ist Tantal sehr, und Niob noch weniger verbreitet.<br />
Takos sind '''SEHR''' empfindlich gegenüber schnellen Spannungsanstiegen bzw. Überspannung und sollten nie ohne Vorwiderstand direkt an einer niederohmigen Quelle (Batterie) geladen/betrieben werden. Takos verbrennen im Fehlerfall mit einer Stichflamme, daher empfiehlt es sich eine deutlich höhere Spannungsfestigkeit zu wählen und - bei direktem Anschluß an eine niederohmige Quelle - zusätzlich ein Lade-Vorwiderstand einzubauen. Treten zusätzlich hohe Temperaturen auf, ist die Spannungsfestigkeit mindestens zu verdoppeln.<br />
Kondensatoren mit Niob statt Tantal sind weniger verbreitet, und noch sehr teuer. Ihr Vorteil ist z.B. die Unempfindlichkeit gegenüber schnellen Spannungsanstiegen, sie können direkt an jeder Quelle betrieben werden.<br />
<br />
==== Flüssig-Elektrolyt ====<br />
Diese Bauteile bestehen aus zwei Lagen '''sehr stark angeätzter''' Aluminiumfolie - zur Vergrößerung der Oberfläche - und einem flüssigen (seltener "einem festen") Elektrolyten. Die zweite Folie kontaktiert gleichzeitig den Elektrolyten. Der Elektrolyt ist häufig auf Alkoholen basierend, aus/mit Schwefelsäure oder Glykol.<br />
Die Alufolie wird nach den ätzen anodisch oxidiert. Die Eloxal-Schicht ist mechanisch belastbar, und stellt die '''einzige''' Isolation zwischen den beiden Anschlüssen dar. Die Oxidation der Alufolie wird je nach Hersteller bei ca. 140..165% der Nennspannung durchgeführt. Die Oxidschicht baut sich durch den Elektrolyten bei langer Lagerung stark ab, daher sinkt die Spannungsfestigkeit eines Elkos mit seinem Alter. Alte Bauteile können - sofern noch Elektrolyt enthalten ist - durch spannungsrichtiges Anschließen an eine Spannungsquelle und langsamen erhöhen der Spannung bis über die Nennspannung hinaus wieder "formiert" werden. Achtung, hier besteht die Gefahr eines Kurzschlusses zwischen den Anschlüssen, daher hochohmigen Vorwiderstand verwenden!<br />
Wird ein Elko verpolt betrieben, wird die Oxidschicht im Laufe der Zeit (Abhängig von Spannung und Temperatur) abgebaut, und der Kondensator schlägt durch.<br />
<br />
=== Doppelschicht-Kondensatoren ===<br />
Siehe auch den Artikel '''Superkondensator in [https://de.wikipedia.org/wiki/Superkondensator Wikipedia]'''.<br />
<br />
Diese Bauteile werden unter Markennamen wie "Goldcap", "Ultracap" oder "Supercap" vertrieben, besitzen meist ein flüssiges Elektrolyt haben aber nicht besonders viel mit den o.g. "Elektrolytkondensatoren" gemeinsam. Dieser Kondensator besitzt Eigenschaften eines Kondensators und einer Batterie. Der "Kondensator" ist hier aus (im Gegensatz zum Elko) zwei Lagen einer einseitig metallisierten Aktivkohle, einem Separator, und einem Elektrolyten. <br />
Das verwendete Elektrolyt erfüllt unter definierten Betriebsbedingungen die Funktion eines zusätzlichen Dielektrikums, und trägt zusätzlich zur ohnehin schon sehr großen Fläche der Aktivkohle, durch seine extrem dünne Schichtdicke, zur sehr hohen Kapazität bei.<br />
Im Gegensatz zu einer Batterie kann der Doppelschichtkondensator Energie sehr schnell aufnehmen und abgeben, und altert dabei nur im geringen Maße. 500000 Lade-/Entladezyklen sind erreichbar, wenn die Spannung pro Zelle nicht überschritten wird. Normal sind hier 2,3..2,5V.<br />
<br />
== Anwendungen ==<br />
Hier wird für verschiedene Anwendungsfälle eine sinnvolle Lösung empfohlen.<br />
<br />
{| class="wikitable"<br />
| '''Anwendung''' || '''Beispiel''' || '''Empfohlener Typ''' ||'''Kommentar'''<br />
|-<br />
| Stromversorgung || Netzteil|| Elko||<br />
|- <br />
| Stromversorgung || Zwischenkreis|| Elkos, Folienkondensatoren||<br />
|-<br />
| Datenerhalt || || Doppelschichtkondensator ||<br />
|-<br />
| Energiespeicher|| digitale Schaltungen|| Kerko || z.B. 47nF pro IC bzw. Vcc-Anschluß<br />
|- <br />
| Hohe Impulsenergie x00ms || Impulsschweißgerät, (capacitive discharge)|| Elko (Folie)||<br />
|-<br />
| Impulsfeste Kondensatoren || Coils shrinker, Coilgun, Railgun|| Folie||MKT10 oder noch besser FKT1<br />
|-<br />
| NF-Filter|| PWM als DAC || Tako/Elko/Kerko ||<br />
|-<br />
| HF-Filter|| Beispiel || Styroflex-Folie ||<br />
|-<br />
| Audio || Kopplung || Folie ||<br />
|-<br />
| Vorwiderstand || Motorkondensator || MP oder Folie ||<br />
|-<br />
| Vorwiderstand || Kondensatornetzteil|| Kerko/Folie || Achtung, nur X2-Typen!<br />
|}<br />
<br />
== Mathematik zum Kondensator ==<br />
<br />
Die Größe eines Kondensators ist seine Kapazität (Formelzeichen ''C''), die als Ladung (Formelzeichen ''Q'') durch Spannung (Formelzeichen ''U'') definiert ist.<br />
<br />
<math>C=\frac{Q}{U}</math><br />
<br />
Die Einheit für die Kapazität ist Farad:<br />
<br />
<math> [C]=F=\frac{As}{V}</math><br />
<br />
=== Reihenschaltung ===<br />
<br />
Für eine Reihenschaltung von ''n'' Kondensatoren gilt:<br />
<br />
<math>\frac{1}{C_{ges}}=\frac{1}{C_1}+\frac{1}{C_2}+\dots+\frac{1}{C_n}</math><br />
<br />
<math>U_{ges}=U_1+U_2+\dots+U_n</math><br />
<br />
<math>I_{ges}=I_1=I_2=\dots=I_n</math><br />
<br />
===Parallelschaltung ===<br />
<br />
Für eine Parallelschaltung von ''n'' Kondensatoren gilt:<br />
<br />
<math>C_{ges}=C_1+C_2+\dots+C_n</math><br />
<br />
<math>U_{ges}=U_1=U_2=\dots=U_n</math><br />
<br />
<math>I_{ges}=I_1+I_2+\dots+I_n</math><br />
<br />
===Gespeicherte Energie ===<br />
<br />
Die in einem Kondensator gespeicherte Energie lässt sich durch die Formel<br />
<br />
<math> W=\frac{C}{2} \cdot U^2 = \frac{1}{2 \cdot C} \cdot Q^2 = \frac{U}{2} \cdot Q </math><br />
<br />
berechnen.<br />
<br />
== Praxis ==<br />
<br />
=== Polaritätszeichen ===<br />
<br />
Elektrolytkondensatoren (kurz Elkos) sind in der Regel gepolt, d. h. Gleichspannungspegel müssen in einer vorgeschriebenen Polarität angelegt werden, damit das Dielektrikum nicht zerstört wird. Bei Aluminium-Elkos wird dabei generell der Minuspol gekennzeichnet, bei kleinen Bauformen mit einem Strich, bei größeren Bauformen befinden sich u. U. auch noch Minuszeichen in diesem Strich eingebettet. Bei Tantal-Elkos hingegen wird immer der Pluspol gekennzeichnet, sowohl bei SMD als auch THT-Bauformen.<br />
<br />
[[Bild:SMD-Elkos.jpeg]]<br />
<br />
Die gezeigten Elkos haben folgende Werte (von links nach rechts):<br />
<br />
* 220 µF, Spannungsfestigkeit 6 V<br />
* 100 µF (<math>10 \cdot 10^7</math> pF), 16 V<br />
* 22 µF, 10 V<br />
* 1 µF, 35 V<br />
* 2,2 µF (<math>22 \cdot 10^5</math> pF), 10 V<br />
<br />
Die beim 100-µF-Kondensator zu findende Buchstabenschreibweise für die Spannungsfestigkeit ist wenig gebräuchlich, aber gelegentlich anzutreffen. Die Zuordnung ist:<br />
<br />
{| class="wikitable"<br />
| style="width:8em" | '''Buchstabe''' || e || g || j || A || C || D || E || V || H || J || K<br />
|-<br />
| '''Spannungs-'''<br>'''festigkeit /V''' || 2.5 || 4 || 6,3 || 10 || 16 || 20 || 25 || 35 || 50 || 63 || 80<br />
|}<br />
<br />
Die Spannungsfestigkeit kann auch durch eine zweistellige Kombination aus einer Ziffer und einem Buchstaben codiert sein:<br />
<br />
{| class="wikitable"<br />
| style="width:8em" | '''Kombination''' || 0G || 0L || 0J || 1A || 1C || 1E <br />
|-<br />
| '''Spannungs-'''<br>'''festigkeit /V''' || 4,0 || 5,5 || 6,3 || 10 || 16 || 20 <br />
|-<br />
|<br />
|-<br />
| '''Kombination''' || 1H || 1J || 1K || 2A || 2Q || 2B <br />
|-<br />
| '''Spannungs-'''<br>'''festigkeit /V''' || 50 || 63 || 80 || 100 || 110 || 125 <br />
|-<br />
|<br />
|-<br />
| '''Kombination''' || 2C || 2Z || 2D || 2P || 2E || 2F<br />
|- <br />
| '''Spannungs-'''<br>'''festigkeit /V''' || 160 || 180 || 200 || 220 || 250 || 315 <br />
|-<br />
|<br />
|-<br />
| '''Kombination''' || 2V || 2G || 2W || 2H || 2J || 3A<br />
|-<br />
| '''Spannungs-'''<br>'''festigkeit /V''' || 350 || 400 || 450 || 500 || 630 || 1000 <br />
|}<br />
<br />
{| class="wikitable"<br />
| '''Case Code''' (Bauform) || A || B || C || D <br />
|-<br />
| '''EIA Code''' || 3216 || 3528 || 6032 || 7343<br />
|-<br />
| '''Länge''' (mm) || 3,2 || 3,5 || 6,0 || 7,3 <br />
|-<br />
| '''Breite''' (mm) || 1,6 || 2,8 || 3,2 || 4,3 <br />
|-<br />
| '''Höhe''' (mm) || 1,6 || 1,9 || 2,5 || 2,8 <br />
|-<br />
| Maßtoleranz (mm) || 0,2 || 0,2 || 0,3 || 0,3 <br />
|}<br />
<br />
=== Siebkondensator ===<br />
<br />
Der Siebkondensator sitzt hinter einem Gleichrichter und hat die Aufgabe, aus einer gleichgerichteten, pulsierenden Spannung, eine annähernd konstante Gleichspannung mit nur wenig Welligkeit (engl. Ripple) zu machen. Er wird periodisch geladen und muss während der Ladepausen, wenn die Eingangssspannung vor dem Gleichrichter kleiner als die Ausgangsspannung ist, den Ausgang mit Strom versorgen. Man findet ihn in allen klassischen Netzteilen mit 50Hz Trafo. Als Daumenregel kann man sich merken, dass man pro 1A Ausgangsstrom ca. 10mF braucht, um eine Welligkeit von ca. 1Vpp zu erreichen.<br />
<br />
Einen Siebkondensator findet man auch am Ausgang von Schaltnetzteilen, seine Aufgabe ist dort die gleiche. Allerdings sind die Schaltfrequenzen deutlich höher, typisch 50-500kHz. Darum muss dieser Kondensator einen besonders kleinen, effektiven Innenwiderstand besitzen (engl. ESR, Equivalent Series Resistance).<br />
<br />
=== Entkoppelkondensator ===<br />
<br />
Der Entkoppelkondensator hat die Aufgabe, die Versorgungsspannung nahe an einem IC für hochfrequente Ströme zu puffern (entkoppeln, engl. decoupling). Schnelle Digital- und Analogschaltungen benötigen vor allem beim Umschalten sehr schnell viel Strom, in der Größenordnung von Nanosekunden bis Mikrosekunden, je nach IC Milliampere bis Ampere. Diese müssen mit möglichst geringem Widerstand und Induktivität geliefert werden. Ein Stromversorgungsnetz auf einer Platine kann das meist nur unzureichend, dazu sind die Leitungen meist zu lang und damit die Induktivität zu hoch. Ein nah am IC platzierter Kondensator liefert diesen Strom für kurze Zeit, ohne dass die Spannung nennenswert einbricht. Die Entkopplung der Stromversorgung geschieht meist mehrstufig, d.h. es werden Kondensatoren verschiedener Arten und Kapazitäten eingesetzt, siehe [[Stromversorgung für FPGAs]].<br />
<br />
Praktische Anwendung<br />
<br />
* '''Jeder''' Digitalschaltkreis benötigt einen 100nF Keramikkondensator nah (kleiner 20mm) an den Anschlüssen von VCC und GND. Je schneller der IC schalten kann, umso wichtiger ist er und umso näher muss er platziert werden. Ein "langsamer" IC wie ein AVR Mikrocontroller verkraftet 20mm, im Ausnahmefall auch mehr. Ein deutlich schnellerer IC wie moderne FPGAs, große CPUs, sehr schnelle ASICs etc. sind da anspruchsvoller, vor allem wenn die Schaltung stabil laufen soll. Dann muss man möglichst jeden Millimeter Leiterbahn zwischen Pin und Kondensator einsparen, soweit das mechanisch geht.<br />
* Für '''jedes''' Anschlusspaar von VCC und GND eines ICs muss ein Kondensator verwendet werden. Sparen geht hier oft schief!<br />
* Für die Verbindung der Entkoppelkondensatoren zur Masse- bzw. Versorgungsfläche sollte man möglichst je Kondensator ein VIA benutzen und nicht über ein VIA mehrere Kondensatoren verbinden. Dadurch wird die parasitäre Induktivität vermindert.<br />
* Schnelle Analogschaltkreise wie Operationsverstärker, [[Treiber]] etc. brauchen auch individuelle Entkoppelkondensatoren.<br />
* Pi mal Daumen gilt: Je größer der Kondensator, umso weiter kann er von dem Verbraucher weg sein, da er auf Grund seines Innenwiderstands (ESR, ESL) weniger HF-tauglich ist. Es ist somit nicht sinnvoll, einen 1000µF Elektrolytkondensator 10mm neben einen Digital-IC setzen zu wollen. Dort gehört der 100nF Keramikkondensator hin. Aber für die Stromversorgung von Motoren, Treibern und [[H-Brücken Übersicht|H-Brücken]] sind derartige großen Kondensatoren wichtig und sollten nicht zu weit entfernt sein.<br />
<br />
=== Koppelkondensator ===<br />
<br />
Koppelkondensatoren verbinden Verstärkerstufen. Dabei wird jedoch nur der Wechselanteil übertragen, kein Gleichanteil. Diese Kondensatoren müssen möglichst verzerrungsarm sein, vor allem im Audiobereich. Das wird durch die richtige Wahl des Dielektrikums erreicht.<br />
<br />
=== Forumsbeiträge ===<br />
<br />
* [http://www.mikrocontroller.net/topic/43762 Abblockkondensator: Kerko (Keramik) oder Folie?]<br />
* [http://www.mikrocontroller.net/topic/62576 Brennende Tantalkondensatoren]<br />
* [http://www.mikrocontroller.net/topic/108865#963281 Kodierung (Umwandlung)]<br />
* [http://www.mikrocontroller.net/topic/169958#1624840 Unterschied: Elektrolytkondensator vs. Tantalkondensator]<br />
* [http://www.mikrocontroller.net/topic/195563#1915294 Unterschied: C0G vs. Glimmer]<br />
* [http://www.mikrocontroller.net/topic/264347#2748845 Kurze Beschreibung verschiedener Folienkondensatoren]<br />
* [http://www.mikrocontroller.net/topic/108865#1356075 PC Tool zum Identifizieren von Kondensatoren]<br />
* [https://www.mikrocontroller.net/topic/436472#5164488 Kräftige Ladepumpe 12V?], wie Ladungspumpen effizient arbeiten<br />
* [https://www.mikrocontroller.net/topic/470224#5763932 MMLC Kondensatoren Bauform reduzieren]<br />
* [https://www.mikrocontroller.net/topic/440901#5264220 1F-Kondensator laden & entladen]<br />
<br />
== Weblinks ==<br />
<br />
* [http://my.execpc.com/~endlr/index.html CapSite 2009] - Introduction To Capacitors<br />
* [http://www.cde.com/catalogs/AEappGUIDE.pdf Aluminum Electrolytic Capacitor Application Guide] von CDE Cornell Dubilier<br />
* Sehr ausf&uuml;hrliche Artikel bei Wikipedia<br />
** [http://de.wikipedia.org/wiki/Elektrolytkondensator Elektrolytkondensator]<br />
** [http://de.wikipedia.org/wiki/Polymer-Elektrolytkondensator Polymer-Elkos]<br />
** [http://de.wikipedia.org/wiki/Aluminium-Elektrolytkondensator Al-(Polymer-)Elkos]<br />
** [http://de.wikipedia.org/wiki/Tantal-Elektrolytkondensator Niob- und Tantal-(Polymer-)Elkos]<br />
* Anwendungen<br />
** [http://www.radio-electronics.com/info/data/capacitor/capacitor_types.php Capacitor types and their uses] (engl.)<br />
** [http://www.planetanalog.com/features/showArticle.jhtml;jsessionid=23?articleID=199905522 Choosing and Using Bypass Capacitors] (dreiteilige Artikelserie) bei [http://www.planetanalog.com www.planetanalog.com]<br />
** [http://www.vagrearg.org/?p=decoupling Decoupling by Example]<br />
* Video-Tutorials<br />
** EEVblog #33 – Capacitor Tutorial [http://www.eevblog.com/2009/09/26/eevblog-33-1of2-capacitor-tutorial-electrolytic-tantalum-and-plastic-film/ Teil 1: Electrolytic, Tantalum, and Plastic Film] und [http://www.eevblog.com/2009/09/26/eevblog-33-2of2-capacitor-tutorial-ceramics-and-impedance/ Teil 2: Ceramics and impedance]<br />
* [http://www.maximintegrated.com/app-notes/index.mvp/id/5527 Tutorial] von Maxim, "Temperature and Voltage Variation of Ceramic Capacitors, or Why Your 4.7µF Capacitor Becomes a 0.33µF Capacitor", engl.<br />
* [http://www.wima.de/DE/characteristics.htm Vergleichstabelle] der Eigenschaften von Folien- und Keramikkondensatoren, WIMA<br />
* [http://portal.national.com/rap/Application/0,1570,28,00.html] Bob Pease: "Understand Capacitor Soakage to Optimize Analog Systems"<br />
* [http://www.youtube.com/watch?v=AP_FSyWGpoE Youtube-Video zum Thema Abblockkondensatoren (Deutsch)]<br />
* [http://www.lothar-miller.de/s9y/categories/14-Entkopplung Entkopplung] von ICs, von Lothar Miller<br />
<br />
[[Category:Bauteile]]<br />
[[Category:Grundlagen]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=Kondensator&diff=107594Kondensator2025-08-04T08:14:45Z<p>Heha: /* Keramik-Kondensator */</p>
<hr />
<div>Ein '''Kondensator''' ist ein passives elektrisches Bauteil mit zwei Anschlüssen, welches elektrische Energie in einem elektrischen Feld in Form von Ladung speichert. Die charakteristische Größe, die den Kondensator beschreibt, ist die Kapazität C, gemessen in Farad (F). Ein Kondensator besteht aus zwei Flächen gut leitfähigen Materials, die voneinander isoliert sind. Das Isolationsmaterial ist ein Dielektrikum und verleiht dem Kondensator je nach Material stark unterschiedliche Eigenschaften.<br />
<br />
== Aufbau eines Kondensators ==<br />
Je größer die Fläche, je geringer der Abstand der Flächen und je höher die relative Permittivität \varepsilon_r - das Dielektrikum - desto höher ist die Kapazität des Bauteils. Der einfachste Kondensator besteht aus zwei voneinander isolierten Metallplatten, zwischen denen sich Luft als "Dielektrikum" befindet. Um die Fläche und damit die Kapazität zu vergrößern gibt es verschiedene Möglichkeiten:<br />
<br />
=== Wickelkondensator ===<br />
Die einfachste Methode die Flächen zu vergrößern ist es, zwei leitfähige Folien mit einem Isolationsmaterial dazwischen aufzuwickeln. Diese Methode wird für so ziemlich alle Kondensatortypen verwendet. Manchmal wird der Wickel nach der Herstellung flachgepresst, um das Volumen zu optimieren.<br />
<br />
=== Schichtkondensator ===<br />
Diese Aufbauart wird durch "stapeln" der unterschiedlichen Lagen erreicht. Verfahrenstechnisch ist dies oft wieder ein Wickel, jedoch meist auf bis zu 2 Meter durchmessenden Wickelrädern. Dieses ursprünglich von Siemens eingesetzte Verfahren wird auch aktuell noch verwendet, hauptsächlich für Folienkondensatoren bis in den mF-Bereich hinein. Nach dem Wickeln auf vieleckigen Rädern wird der Folienstapel geschnitten und auf die gewünschte Größe = Kapazität getrennt.<br />
<br />
== Kondensatortypen ==<br />
(Vakuum-, Glimmer-, Gas- und Glaskondensatoren nicht berücksichtigt)<br />
=== Keramik-Kondensator ===<br />
Siehe auch den Artikel '''Keramikkondensator in [https://de.wikipedia.org/wiki/Keramikkondensator#Spannungsabh.C3.A4ngigkeit_der_Kapazit.C3.A4t Wikipedia]'''. Es gibt sie bedrahtet und in SMD. Bedrahtet gab es sie früher als Einschicht-Kapazität in Scheibenform, heutzutage nur noch als Vielschicht-Kondensator. Einschichtig nur für Spannungen im Kilovolt-Bereich.<br />
<br />
Kerkos sind sogenannte "Vielschicht-Kondensatoren" die aus mehreren hundert Lagen einer isolierenden Keramik (Titandioxid+Bariumtitanat), und einer elektrisch leitfähigen Metallisierung (Aluminium & Magnesiumsilikate) bestehen.<br />
Dieser Typ ist wie der Folienkondensator für höchste Frequenzen geeignet, hat eine sehr geringe Baugröße, eine gute Temperaturstabilität aber piezoelektrische Eigenschaften. Die Kapazität pro mm³ variiert je nach Dielektrikum Z5U, Y5V, X7R, C0 (in abnehmender Kapazitätsdichte) und ist sowohl abhängig von Temperatur als auch der angelegten Spannung.<br />
<br />
Keramik-Kondensatoren sind sehr preisgünstig und werden überall dort eingesetzt, wo andere Kondensatortypen keinen Vorteil bringen. Zudem lösen sie mehr und mehr Elektrolytkondensatoren ab, die ihrerseits mit hoher Kapazität punkten: Die Lebensdauer, besonders bei hoher Temperatur, ist höher.<br />
<br />
=== Folien-Kondensator ===<br />
Siehe auch den Artikel '''Folienkondensator in [https://de.wikipedia.org/wiki/Kunststoff-Folienkondensator Wikipedia]'''.<br />
<br />
Unterschiedliche Folienarten verleihen dem Kondensator stark unterschiedliche Eigenschaften wie z.B. temperatur- und alterungsbeständigkeit, Verlustfaktor, Isolationswiderstand, und die obere Grenzfrequenz, um nur die wichtigsten zu nennen. Die Dicke der Metallisierung hingegen entscheidet über den maximal zulässigen Rippelstrom / Impulsstromfestigkeit und darüber, ob sich ein Kondensator "selbst heilen" kann, oder nicht. Das Verfahren der "Selbstheilung" funktioniert nur bei Metallisierungen, da es darauf beruht, daß die im C gespeicherte Energie den Metallbelag beim Durchschlag durch die Isolation verdampfen kann. Ist die Energie zu gering, wird nur wenig Metall um den Durchschlag verdampft, und der Kurzschluß bleibt bestehen. Ist die Energie zu hoch, wird der Kondensator thermisch zerstört. Hat der C den richigen Energiegehalt, verdampft direkt um die Durchschlagstelle herum bis zu einigen mm der Metallisierung, und die Fehlstelle ist wieder isoliert. Im Übrigen ist eine Parallelsschaltung aus vielen,als selbstheilenden C's nicht unbedingt mehr "selbstheilend" da der Energieeintrag dann aus dem Gesamtverbund kommt, und oft zu hoch ist um nur eine kleine Fläche verdampfen zu lassen.<br />
Impulsstrom-feste Kondensatoren zeichnen sich durch hohe Schichtstärken der Metallisierung aus, oder verwenden statt der Metallbeschichtung direkt eine Metallfolie. Hier wäre normalerweise ein "selbstheilen" gleichbedeutend mit einem so hohen Energieeintrag, daß das Bauteil zerstört wird.<br />
<br />
Hier eine kleine Übersicht mit der Bitte um Vervollständigung.<br />
<br />
{| class="wikitable"<br />
| style="width:8em"| '''Folientyp''' || Poly-<br>propylen || Poly-<br>styren || Poly-<br>carbonat ||Poly-<br>ester|| Poly-<br>styrol || Poly-<br>ethylen-<br>naphthalat || Polytetra-<br>fluor-<br>ethylen || Poly-<br>phenylen-<br>sulfid || Metall-<br>Papier <br />
|-<br />
| '''Folien-'''<br>'''markenname''' || Hostalen || - || Makrofol, Makroflex || Mylar, Hostaphan || Styroflex || Kaladex|| Teflon|| Tedur, Ryton|| Papier<br />
|-<br />
| '''Abkürzung''' || PP || - || PC|| PET || PS|| PEN|| PTFE|| PPS|| - <br />
|-<br />
| '''Typ''' || (F)KP, MKP || -KS, MKS || KC, MKC || (F)KT, MKT || -KS, MKS || (F)KN, MKN|| -|| (F)KI, MKI|| MP <br />
|-<br />
| '''Temperatur-'''<br>'''festigkeit /°C''' || ca 105 || - || ca. 105 || 125..150 || - || 150 || -|| 150 || 85 <br />
|-<br />
| '''Toleranz'''<br>'''+/-%''' || 1 || 1 || -|| 1 || - || -|| -|| -|| 20 <br />
|-<br />
| '''Grenzfrequenz /kHz''' || 100 || 400 || -|| - || 1000 || -|| -|| -|| - <br />
|-<br />
| '''Selbstheilend''' || ja || - || -|| ja || - || -|| -|| -|| ja <br />
|-<br />
| '''Impuls-'''<br>'''belastbarkeit''' || + || + || || + || -- || -|| -|| -|| + <br />
|}<br />
(MK) = metallisierte Folie, (F) = Metallbeläge z.B. Metallfolie (K) = Metallfolie+Kunststofffolie<br />
<br />
=== Elektrolyt-Kondensator ===<br />
Ein Elko unterscheidet sich hauptsächlich dadurch von anderen Kondensatoren, daß nur eine Elektrode aus einer Metallschicht besteht, die zweite aus einem festen, oder flüssigen Elektrolyten.<br />
<br />
Siehe auch den Artikel '''Elektrolytkondensator in [https://de.wikipedia.org/wiki/Elektrolytkondensator Wikipedia]'''.<br />
<br />
==== Fest-Elektrolyt ====<br />
Diese Bauteile bestehen aus Polymeren, Metalloxiden, Braunstein, ... und sind wie die Elkos immer gepolt.<br />
Als Metalloxide ist Tantal sehr, und Niob noch weniger verbreitet.<br />
Takos sind '''SEHR''' empfindlich gegenüber schnellen Spannungsanstiegen bzw. Überspannung und sollten nie ohne Vorwiderstand direkt an einer niederohmigen Quelle (Batterie) geladen/betrieben werden. Takos verbrennen im Fehlerfall mit einer Stichflamme, daher empfiehlt es sich eine deutlich höhere Spannungsfestigkeit zu wählen und - bei direktem Anschluß an eine niederohmige Quelle - zusätzlich ein Lade-Vorwiderstand einzubauen. Treten zusätzlich hohe Temperaturen auf, ist die Spannungsfestigkeit mindestens zu verdoppeln.<br />
Kondensatoren mit Niob statt Tantal sind weniger verbreitet, und noch sehr teuer. Ihr Vorteil ist z.B. die Unempfindlichkeit gegenüber schnellen Spannungsanstiegen, sie können direkt an jeder Quelle betrieben werden.<br />
<br />
==== Flüssig-Elektrolyt ====<br />
Diese Bauteile bestehen aus zwei Lagen '''sehr stark angeätzter''' Aluminiumfolie - zur Vergrößerung der Oberfläche - und einem flüssigen (seltener "einem festen") Elektrolyten. Die zweite Folie kontaktiert gleichzeitig den Elektrolyten. Der Elektrolyt ist häufig auf Alkoholen basierend, aus/mit Schwefelsäure oder Glykol.<br />
Die Alufolie wird nach den ätzen anodisch oxidiert. Die Eloxal-Schicht ist mechanisch belastbar, und stellt die '''einzige''' Isolation zwischen den beiden Anschlüssen dar. Die Oxidation der Alufolie wird je nach Hersteller bei ca. 140..165% der Nennspannung durchgeführt. Die Oxidschicht baut sich durch den Elektrolyten bei langer Lagerung stark ab, daher sinkt die Spannungsfestigkeit eines Elkos mit seinem Alter. Alte Bauteile können - sofern noch Elektrolyt enthalten ist - durch spannungsrichtiges Anschließen an eine Spannungsquelle und langsamen erhöhen der Spannung bis über die Nennspannung hinaus wieder "formiert" werden. Achtung, hier besteht die Gefahr eines Kurzschlusses zwischen den Anschlüssen, daher hochohmigen Vorwiderstand verwenden!<br />
Wird ein Elko verpolt betrieben, wird die Oxidschicht im Laufe der Zeit (Abhängig von Spannung und Temperatur) abgebaut, und der Kondensator schlägt durch.<br />
<br />
=== Doppelschicht-Kondensatoren ===<br />
Siehe auch den Artikel '''Superkondensator in [https://de.wikipedia.org/wiki/Superkondensator Wikipedia]'''.<br />
<br />
Diese Bauteile werden unter Markennamen wie "Goldcap", "Ultracap" oder "Supercap" vertrieben, besitzen meist ein flüssiges Elektrolyt haben aber nicht besonders viel mit den o.g. "Elektrolytkondensatoren" gemeinsam. Dieser Kondensator besitzt Eigenschaften eines Kondensators und einer Batterie. Der "Kondensator" ist hier aus (im Gegensatz zum Elko) zwei Lagen einer einseitig metallisierten Aktivkohle, einem Separator, und einem Elektrolyten. <br />
Das verwendete Elektrolyt erfüllt unter definierten Betriebsbedingungen die Funktion eines zusätzlichen Dielektrikums, und trägt zusätzlich zur ohnehin schon sehr großen Fläche der Aktivkohle, durch seine extrem dünne Schichtdicke, zur sehr hohen Kapazität bei.<br />
Im Gegensatz zu einer Batterie kann der Doppelschichtkondensator Energie sehr schnell aufnehmen und abgeben, und altert dabei nur im geringen Maße. 500000 Lade-/Entladezyklen sind erreichbar, wenn die Spannung pro Zelle nicht überschritten wird. Normal sind hier 2,3..2,5V.<br />
<br />
== Anwendungen ==<br />
Hier wird für verschiedene Anwendungsfälle eine sinnvolle Lösung empfohlen.<br />
<br />
{| class="wikitable"<br />
| '''Anwendung''' || '''Beispiel''' || '''Empfohlener Typ''' ||'''Kommentar'''<br />
|-<br />
| Stromversorgung || Netzteil|| Elko||<br />
|- <br />
| Stromversorgung || Zwischenkreis|| Elkos, Folienkondensatoren||<br />
|-<br />
| Datenerhalt || || Doppelschichtkondensator ||<br />
|-<br />
| Energiespeicher|| digitale Schaltungen|| Kerko || z.B. 47nF pro IC bzw. Vcc-Anschluß<br />
|- <br />
| Hohe Impulsenergie x00ms || Impulsschweißgerät, (capacitive discharge)|| Elko (Folie)||<br />
|-<br />
| Impulsfeste Kondensatoren || Coils shrinker, Coilgun, Railgun|| Folie||MKT10 oder noch besser FKT1<br />
|-<br />
| NF-Filter|| PWM als DAC || Tako/Elko/Kerko ||<br />
|-<br />
| HF-Filter|| Beispiel || Styroflex-Folie ||<br />
|-<br />
| Audio || Kopplung || Folie ||<br />
|-<br />
| Vorwiderstand || Motorkondensator || MP oder Folie ||<br />
|-<br />
| Vorwiderstand || Kondensatornetzteil|| Kerko/Folie || Achtung, nur X2-Typen!<br />
|}<br />
<br />
== Mathematik zum Kondensator ==<br />
<br />
Die Größe eines Kondensators ist seine Kapazität (Formelzeichen ''C''), die als Ladung (Formelzeichen ''Q'') durch Spannung (Formelzeichen ''U'') definiert ist.<br />
<br />
<math>C=\frac{Q}{U}</math><br />
<br />
Die Einheit für die Kapazität ist Farad:<br />
<br />
<math> [C]=F=\frac{As}{V}</math><br />
<br />
=== Reihenschaltung ===<br />
<br />
Für eine Reihenschaltung von ''n'' Kondensatoren gilt:<br />
<br />
<math>\frac{1}{C_{ges}}=\frac{1}{C_1}+\frac{1}{C_2}+\dots+\frac{1}{C_n}</math><br />
<br />
<math>U_{ges}=U_1+U_2+\dots+U_n</math><br />
<br />
<math>I_{ges}=I_1=I_2=\dots=I_n</math><br />
<br />
===Parallelschaltung ===<br />
<br />
Für eine Parallelschaltung von ''n'' Kondensatoren gilt:<br />
<br />
<math>C_{ges}=C_1+C_2+\dots+C_n</math><br />
<br />
<math>U_{ges}=U_1=U_2=\dots=U_n</math><br />
<br />
<math>I_{ges}=I_1+I_2+\dots+I_n</math><br />
<br />
===Gespeicherte Energie ===<br />
<br />
Die in einem Kondensator gespeicherte Energie lässt sich durch die Formel<br />
<br />
<math> W=\frac{C}{2} \cdot U^2 = \frac{1}{2 \cdot C} \cdot Q^2 = \frac{U}{2} \cdot Q </math><br />
<br />
berechnen.<br />
<br />
== Praxis ==<br />
<br />
=== Polaritätszeichen ===<br />
<br />
Elektrolytkondensatoren (kurz Elkos) sind in der Regel gepolt, d. h. Gleichspannungspegel müssen in einer vorgeschriebenen Polarität angelegt werden, damit das Dielektrikum nicht zerstört wird. Bei Aluminium-Elkos wird dabei generell der Minuspol gekennzeichnet, bei kleinen Bauformen mit einem Strich, bei größeren Bauformen befinden sich u. U. auch noch Minuszeichen in diesem Strich eingebettet. Bei Tantal-Elkos hingegen wird immer der Pluspol gekennzeichnet, sowohl bei SMD als auch THT-Bauformen.<br />
<br />
[[Bild:SMD-Elkos.jpeg]]<br />
<br />
Die gezeigten Elkos haben folgende Werte (von links nach rechts):<br />
<br />
* 220 µF, Spannungsfestigkeit 6 V<br />
* 100 µF (<math>10 \cdot 10^7</math> pF), 16 V<br />
* 22 µF, 10 V<br />
* 1 µF, 35 V<br />
* 2,2 µF (<math>22 \cdot 10^5</math> pF), 10 V<br />
<br />
Die beim 100-µF-Kondensator zu findende Buchstabenschreibweise für die Spannungsfestigkeit ist wenig gebräuchlich, aber gelegentlich anzutreffen. Die Zuordnung ist:<br />
<br />
{| class="wikitable"<br />
| style="width:8em" | '''Buchstabe''' || e || g || j || A || C || D || E || V || H || J || K<br />
|-<br />
| '''Spannungs-'''<br>'''festigkeit /V''' || 2.5 || 4 || 6,3 || 10 || 16 || 20 || 25 || 35 || 50 || 63 || 80<br />
|}<br />
<br />
Die Spannungsfestigkeit kann auch durch eine zweistellige Kombination aus einer Ziffer und einem Buchstaben codiert sein:<br />
<br />
{| class="wikitable"<br />
| style="width:8em" | '''Kombination''' || 0G || 0L || 0J || 1A || 1C || 1E <br />
|-<br />
| '''Spannungs-'''<br>'''festigkeit /V''' || 4,0 || 5,5 || 6,3 || 10 || 16 || 20 <br />
|-<br />
|<br />
|-<br />
| '''Kombination''' || 1H || 1J || 1K || 2A || 2Q || 2B <br />
|-<br />
| '''Spannungs-'''<br>'''festigkeit /V''' || 50 || 63 || 80 || 100 || 110 || 125 <br />
|-<br />
|<br />
|-<br />
| '''Kombination''' || 2C || 2Z || 2D || 2P || 2E || 2F<br />
|- <br />
| '''Spannungs-'''<br>'''festigkeit /V''' || 160 || 180 || 200 || 220 || 250 || 315 <br />
|-<br />
|<br />
|-<br />
| '''Kombination''' || 2V || 2G || 2W || 2H || 2J || 3A<br />
|-<br />
| '''Spannungs-'''<br>'''festigkeit /V''' || 350 || 400 || 450 || 500 || 630 || 1000 <br />
|}<br />
<br />
{| class="wikitable"<br />
| '''Case Code''' (Bauform) || A || B || C || D <br />
|-<br />
| '''EIA Code''' || 3216 || 3528 || 6032 || 7343<br />
|-<br />
| '''Länge''' (mm) || 3,2 || 3,5 || 6,0 || 7,3 <br />
|-<br />
| '''Breite''' (mm) || 1,6 || 2,8 || 3,2 || 4,3 <br />
|-<br />
| '''Höhe''' (mm) || 1,6 || 1,9 || 2,5 || 2,8 <br />
|-<br />
| Maßtoleranz (mm) || 0,2 || 0,2 || 0,3 || 0,3 <br />
|}<br />
<br />
=== Siebkondensator ===<br />
<br />
Der Siebkondensator sitzt hinter einem Gleichrichter und hat die Aufgabe, aus einer gleichgerichteten, pulsierenden Spannung, eine annähernd konstante Gleichspannung mit nur wenig Welligkeit (engl. Ripple) zu machen. Er wird periodisch geladen und muss während der Ladepausen, wenn die Eingangssspannung vor dem Gleichrichter kleiner als die Ausgangsspannung ist, den Ausgang mit Strom versorgen. Man findet ihn in allen klassischen Netzteilen mit 50Hz Trafo. Als Daumenregel kann man sich merken, dass man pro 1A Ausgangsstrom ca. 10mF braucht, um eine Welligkeit von ca. 1Vpp zu erreichen.<br />
<br />
Einen Siebkondensator findet man auch am Ausgang von Schaltnetzteilen, seine Aufgabe ist dort die gleiche. Allerdings sind die Schaltfrequenzen deutlich höher, typisch 50-500kHz. Darum muss dieser Kondensator einen besonders kleinen, effektiven Innenwiderstand besitzen (engl. ESR, Equivalent Series Resistance).<br />
<br />
=== Entkoppelkondensator ===<br />
<br />
Der Entkoppelkondensator hat die Aufgabe, die Versorgungsspannung nahe an einem IC für hochfrequente Ströme zu puffern (entkoppeln, engl. decoupling). Schnelle Digital- und Analogschaltungen benötigen vor allem beim Umschalten sehr schnell viel Strom, in der Größenordnung von Nanosekunden bis Mikrosekunden, je nach IC Milliampere bis Ampere. Diese müssen mit möglichst geringem Widerstand und Induktivität geliefert werden. Ein Stromversorgungsnetz auf einer Platine kann das meist nur unzureichend, dazu sind die Leitungen meist zu lang und damit die Induktivität zu hoch. Ein nah am IC platzierter Kondensator liefert diesen Strom für kurze Zeit, ohne dass die Spannung nennenswert einbricht. Die Entkopplung der Stromversorgung geschieht meist mehrstufig, d.h. es werden Kondensatoren verschiedener Arten und Kapazitäten eingesetzt, siehe [[Stromversorgung für FPGAs]].<br />
<br />
Praktische Anwendung<br />
<br />
* '''Jeder''' Digitalschaltkreis benötigt einen 100nF Keramikkondensator nah (kleiner 20mm) an den Anschlüssen von VCC und GND. Je schneller der IC schalten kann, umso wichtiger ist er und umso näher muss er platziert werden. Ein "langsamer" IC wie ein AVR Mikrocontroller verkraftet 20mm, im Ausnahmefall auch mehr. Ein deutlich schnellerer IC wie moderne FPGAs, große CPUs, sehr schnelle ASICs etc. sind da anspruchsvoller, vor allem wenn die Schaltung stabil laufen soll. Dann muss man möglichst jeden Millimeter Leiterbahn zwischen Pin und Kondensator einsparen, soweit das mechanisch geht.<br />
* Für '''jedes''' Anschlusspaar von VCC und GND eines ICs muss ein Kondensator verwendet werden. Sparen geht hier oft schief!<br />
* Für die Verbindung der Entkoppelkondensatoren zur Masse- bzw. Versorgungsfläche sollte man möglichst je Kondensator ein VIA benutzen und nicht über ein VIA mehrere Kondensatoren verbinden. Dadurch wird die parasitäre Induktivität vermindert.<br />
* Schnelle Analogschaltkreise wie Operationsverstärker, [[Treiber]] etc. brauchen auch individuelle Entkoppelkondensatoren.<br />
* Pi mal Daumen gilt: Je größer der Kondensator, umso weiter kann er von dem Verbraucher weg sein, da er auf Grund seines Innenwiderstands (ESR, ESL) weniger HF-tauglich ist. Es ist somit nicht sinnvoll, einen 1000µF Elektrolytkondensator 10mm neben einen Digital-IC setzen zu wollen. Dort gehört der 100nF Keramikkondensator hin. Aber für die Stromversorgung von Motoren, Treibern und [[H-Brücken Übersicht|H-Brücken]] sind derartige großen Kondensatoren wichtig und sollten nicht zu weit entfernt sein.<br />
<br />
=== Koppelkondensator ===<br />
<br />
Koppelkondensatoren verbinden Verstärkerstufen. Dabei wird jedoch nur der Wechselanteil übertragen, kein Gleichanteil. Diese Kondensatoren müssen möglichst verzerrungsarm sein, vor allem im Audiobereich. Das wird durch die richtige Wahl des Dielektrikums erreicht.<br />
<br />
=== Forumsbeiträge ===<br />
<br />
* [http://www.mikrocontroller.net/topic/43762 Abblockkondensator: Kerko (Keramik) oder Folie?]<br />
* [http://www.mikrocontroller.net/topic/62576 Brennende Tantalkondensatoren]<br />
* [http://www.mikrocontroller.net/topic/108865#963281 Kodierung (Umwandlung)]<br />
* [http://www.mikrocontroller.net/topic/169958#1624840 Unterschied: Elektrolytkondensator vs. Tantalkondensator]<br />
* [http://www.mikrocontroller.net/topic/195563#1915294 Unterschied: C0G vs. Glimmer]<br />
* [http://www.mikrocontroller.net/topic/264347#2748845 Kurze Beschreibung verschiedener Folienkondensatoren]<br />
* [http://www.mikrocontroller.net/topic/108865#1356075 PC Tool zum Identifizieren von Kondensatoren]<br />
* [https://www.mikrocontroller.net/topic/436472#5164488 Kräftige Ladepumpe 12V?], wie Ladungspumpen effizient arbeiten<br />
* [https://www.mikrocontroller.net/topic/470224#5763932 MMLC Kondensatoren Bauform reduzieren]<br />
* [https://www.mikrocontroller.net/topic/440901#5264220 1F-Kondensator laden & entladen]<br />
<br />
== Weblinks ==<br />
<br />
* [http://my.execpc.com/~endlr/index.html CapSite 2009] - Introduction To Capacitors<br />
* [http://www.cde.com/catalogs/AEappGUIDE.pdf Aluminum Electrolytic Capacitor Application Guide] von CDE Cornell Dubilier<br />
* Sehr ausf&uuml;hrliche Artikel bei Wikipedia<br />
** [http://de.wikipedia.org/wiki/Elektrolytkondensator Elektrolytkondensator]<br />
** [http://de.wikipedia.org/wiki/Polymer-Elektrolytkondensator Polymer-Elkos]<br />
** [http://de.wikipedia.org/wiki/Aluminium-Elektrolytkondensator Al-(Polymer-)Elkos]<br />
** [http://de.wikipedia.org/wiki/Tantal-Elektrolytkondensator Niob- und Tantal-(Polymer-)Elkos]<br />
* Anwendungen<br />
** [http://www.radio-electronics.com/info/data/capacitor/capacitor_types.php Capacitor types and their uses] (engl.)<br />
** [http://www.planetanalog.com/features/showArticle.jhtml;jsessionid=23?articleID=199905522 Choosing and Using Bypass Capacitors] (dreiteilige Artikelserie) bei [http://www.planetanalog.com www.planetanalog.com]<br />
** [http://www.vagrearg.org/?p=decoupling Decoupling by Example]<br />
* Video-Tutorials<br />
** EEVblog #33 – Capacitor Tutorial [http://www.eevblog.com/2009/09/26/eevblog-33-1of2-capacitor-tutorial-electrolytic-tantalum-and-plastic-film/ Teil 1: Electrolytic, Tantalum, and Plastic Film] und [http://www.eevblog.com/2009/09/26/eevblog-33-2of2-capacitor-tutorial-ceramics-and-impedance/ Teil 2: Ceramics and impedance]<br />
* [http://www.maximintegrated.com/app-notes/index.mvp/id/5527 Tutorial] von Maxim, "Temperature and Voltage Variation of Ceramic Capacitors, or Why Your 4.7µF Capacitor Becomes a 0.33µF Capacitor", engl.<br />
* [http://www.wima.de/DE/characteristics.htm Vergleichstabelle] der Eigenschaften von Folien- und Keramikkondensatoren, WIMA<br />
* [http://portal.national.com/rap/Application/0,1570,28,00.html] Bob Pease: "Understand Capacitor Soakage to Optimize Analog Systems"<br />
* [http://www.youtube.com/watch?v=AP_FSyWGpoE Youtube-Video zum Thema Abblockkondensatoren (Deutsch)]<br />
* [http://www.lothar-miller.de/s9y/categories/14-Entkopplung Entkopplung] von ICs, von Lothar Miller<br />
<br />
[[Category:Bauteile]]<br />
[[Category:Grundlagen]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=MOSFET-%C3%9Cbersicht&diff=107573MOSFET-Übersicht2025-06-26T09:31:43Z<p>Heha: Beim nächsten Mal R-Spalte in Ohm!</p>
<hr />
<div>Im Forum wird immer wieder gefragt, welchen Mosfet-Transistor man für ein Projekt einsetzen sollte. Und wo man die herbekommt. Deshalb soll hier eine Übersicht mit gängigen Mosfet-Transistoren und Bezugsquellen entstehen. Bezugsquellen sollten nach Möglichkeit solche sein, die auch für den privaten Bastler in Frage kommen.<br />
<br />
Der Thread zum Thema: http://www.mikrocontroller.net/topic/41588<br />
<br />
Siehe auch: [[Transistor-Übersicht]] - [[Dioden-Übersicht]] - [[Standardbauelemente]]<br />
<br />
== P-Kanal MOSFET==<br />
Alles selbstsperrend, sog. Anreicherungstypen. <br />
Bemerkung: sogenannte Verarmungstypen oder selbst leitende Mosfets sind in der P-Kanal Ausführung nicht für den <br />
Konsumermarkt erhältlich. Diese sind nur in integrierten Schaltungen zu finden. <br />
<br />
{| {{Tabelle}} border="1" class="wikitable sortable" id="pkanalmosfets"<br />
|- style="background-color:#eeeeee"<br />
! style="width:15%;" | Name<br />
! Gehäuse<br />
! Her<br>steller<br />
! <math>U_{GS(th)}</math> <br>/V<br />
! <math>U_{DS}</math><br>/V<br />
! <math>I_D</math><br>/A<br />
! <math>P</math><br>/W<br />
! <math>R_{DS,on}</math><br><math>m\Omega</math><br />
! Bemerkung<br />
! Lieferant<br />
! Preis<br>/€<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRLML2244 IRLML2244]<br />
| SOT-23<br />
| IRF<br />
| 1,1<br />
| 20<br />
| 4,3<br />
| 1,3<br />
| 54<br />
| -<br />
|[[Elektronikversender#TME_.28Transfer_Multisort_Elektronik.29|TME]],[[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Conrad|Con]],[[Elektronikversender#Farnell|Far]],[[Elektronikversender#Mouser|Mou]]<br />
| 0,10 <br />
|-<br />
| [http://www.mikrocontroller.net/part/BS250 BS250]<br />
| TO-92, SOT-23<br />
| Siliconix<br />
| 4,0<br />
| 60<br />
| 0,12<br />
| 0,35<br />
| 10000<br />
| -<br />
|[[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Buerklin|Bü]]<br />
| 0,32<br />
|-<br />
| [http://www.mikrocontroller.net/part/BSH205 BSH205]<br />
| SOT-23<br />
| Phi<br />
| 1,0<br />
| 12<br />
| 0,75<br />
| 0,4<br />
| 500<br />
| Qg = 3,8nC<br />
| [[Elektronikversender#csd-electronics|csd]] (a.A.)<br />
| 0,30<br />
|-<br />
| [http://www.mikrocontroller.net/part/SI2301 SI2301]<br />
| SOT-23<br />
| Vishay<br />
| 1,5<br />
| 20<br />
| 2,0<br />
| 0,7<br />
| 150<br />
| Qg =4,5nC<br />
| [[Elektronikversender#farnell|farnell]]<br />
| 0,30<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRLML6402 IRLML6402PBF]<br />
| SOT-23<br />
| IRF<br />
| 1,2<br />
| 20<br />
| 3,7<br />
| 1,3<br />
| 65<br />
| 2,5V LL<br />
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#csd-electronics|csd]],[[Elektronikversender#Buerklin|Bü]]<br />
| 0,15<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRLML6302 IRLML6302PBF]<br />
| SOT-23<br />
| IRF<br />
| 1,5<br />
| 20<br />
| 0,75<br />
| 0,54<br />
| 600<br />
| <br />
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#csd-electronics|csd]],[[Elektronikversender#Buerklin|Bü]]<br />
| 0,18<br />
|-<br />
| [http://www.mikrocontroller.net/part/BSS83P BSS83P]<br />
| SOT-23<br />
| Inf<br />
| 2,0<br />
| 60<br />
| 0,33<br />
| 0,36<br />
| 2000<br />
| nicht mit BSS83 (ohne P) verwechseln<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,11<br />
|-<br />
| [http://www.mikrocontroller.net/part/BSS84 BSS84]<br />
| SOT-23<br />
| Fairchild,NXP<br />
| 2,0<br />
| 50<br />
| 0,13<br />
| 0,35<br />
| 10000<br />
| -<br />
| [[Elektronikversender#Farnell|Fa]]<br />
| 0,28<br />
|-<br />
| [http://www.mikrocontroller.net/part/BSS110 BSS110]<br />
| TO-97, SOT-23<br />
| Phi<br />
| 3,0<br />
| 50<br />
| 0,17<br />
| 0,35<br />
| 10000<br />
| -<br />
| -<br />
| -<br />
|-<br />
| [http://www.mikrocontroller.net/part/PMV65XP PMV65XP]<br />
| SOT-23<br />
| Phi<br />
| 1,4<br />
| 20<br />
| 3,9<br />
| ?<br />
| 76<br />
| grosser ID für Bauform<br />
| [[Elektronikversender#Spoerle|Spo]], [[Elektronikversender#RS_Components|RS]]<br />
| 0,10<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF4905S IRF4905S]<br />
| D2Pack<br />
| IRF<br />
| 4,0<br />
| 55<br />
| 64<br />
| 3,8<br />
| 20<br />
| -<br />
| [[Elektronikversender#Reichelt|Rei]], [[Elektronikversender#Conrad|Con]]<br />
| 1,10<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF4905 IRF4905]<br />
| TO-220AB<br />
| IRF<br />
| 4,0<br />
| 55<br />
| 74<br />
| 200<br />
| 20<br />
| -<br />
|[[Elektronikversender#Reichelt|Rei]]<br />
| 0,93<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF5210 IRF5210]<br />
| TO-220AB<br />
| IRF<br />
| 10,0<br />
| 100<br />
| 40<br />
| 200<br />
| 60<br />
| -<br />
|[[Elektronikversender#Reichelt|Rei]]<br />
| 1,15<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF5210S IRF5210S]<br />
| D2Pack<br />
| IRF<br />
| 10,0<br />
| 100<br />
| 40<br />
| ?<br />
| 60<br />
| -<br />
|[[Elektronikversender#Reichelt|Rei]]<br />
| 1,25<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF7205 IRF7205]<br />
| SO-8<br />
| IRF<br />
| 3,0<br />
| 30<br />
| 4,6<br />
| 2,5<br />
| 70<br />
| ?<br />
|[[Elektronikversender#Reichelt|Rei]] <br />
| 0,34<br />
|-<br />
| [http://www.mikrocontroller.net/part/FDC604P FDC604P]<br />
| SuperSOT-6<br />
| Fairchild<br />
| 1,5<br />
| 20<br />
| 5,5<br />
| 0,8-1,6<br />
| 33<br />
| -<br />
| [[Elektronikversender#csd-electronics|csd]] (a.A.)<br />
| 0,70<br />
|-<br />
| [http://www.mikrocontroller.net/part/NDS0610 NDS0610]<br />
| SOT-23<br />
| Fairchild<br />
| 1,8<br />
| 60<br />
| 0,12<br />
| 0,36<br />
| 10000<br />
| -<br />
| [[Elektronikversender#csd-electronics|csd]]<br />
| 0,07<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF5305 IRF5305]<br />
| TO-220AB<br />
| IRF<br />
| 4,0<br />
| 55<br />
| 31<br />
| 110<br />
| 60<br />
| -<br />
|[[Elektronikversender#Reichelt|Rei]], [[Elektronikversender#CBoden|CBo]]<br />
| 1,00<br />
|-<br />
| [http://www.mikrocontroller.net/part/NDS352P NDS352P]<br />
| SOT-23<br />
| Fairchild<br />
| 4,5<br />
| 20<br />
| 0,85<br />
| 0,5<br />
| 500<br />
| -<br />
| [[Elektronikversender#Conrad|Con]]<br />
| 0,76<br />
|-<br />
| [http://www.mikrocontroller.net/part/BSP171 BSP171]<br />
| SOT-223<br />
| Siemens<br />
| 1,4<br />
| 60<br />
| 1,7<br />
| 1,8<br />
| 350<br />
| -<br />
| -<br />
| -<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRFD9014 IRFD9014]<br />
| HEXDIP, DIP4<br />
| IRF<br />
| 2,0<br />
| 60<br />
| 1,1<br />
| 1,3<br />
| 500<br />
| -<br />
| [[Elektronikversender#Conrad|Con]]<br />
| 0,65<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRFD9024 IRFD9024]<br />
| HEXDIP, DIP4<br />
| IRF<br />
| 2,0<br />
| 60<br />
| 1,6<br />
| 1,3<br />
| 280<br />
| -<br />
| [[Elektronikversender#Conrad|Con]],[[Elektronikversender#Reichelt|Rei]]<br />
| 0,50<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF7416 IRF7416]<br />
| SO-8<br />
| IRF<br />
| 1,0<br />
| 30<br />
| 10<br />
| 2,5<br />
| 20<br />
| -<br />
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Conrad|Con]]<br />
| 0,43<br />
|-<br />
| [http://www.mikrocontroller.net/part/SUP75P03 SUP75P03-007]<br />
| TO-220AB<br />
| Vishay<br />
| 3,0<br />
| 30<br />
| 75<br />
| 187<br />
| 7<br />
| -<br />
|<br />
| 2,30<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF7220 IRF7220]<br />
| SO-8<br />
| IRF<br />
| 0,6<br />
| 14<br />
| 11<br />
| 2,5<br />
| 8,2<br />
| 2,5V LL, Qg=84nC<br />
| [[Elektronikversender#Conrad|Con]], [[Elektronikversender#Reichelt|Rei]]<br />
| 0,58<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF7410 IRF7410]<br />
| SO-8<br />
| IRF<br />
| 0,4...0,9<br />
| 12<br />
| 16<br />
| 2,5<br />
| 7<br />
| 1,8V LL, Qg=91nC <br />
| [[Elektronikversender#Distrelec|Dis]], [[Elektronikversender#Reichelt|Rei]]<br />
| 0,85<br />
|-<br />
| AOC2413<br />
| MCSP<br />
| Alpha&Omega<br />
| 0,42<br />
| 8<br />
| 3,5<br />
| 0,55<br />
| 28<br />
| 1,2V LL, Qg=19nC <br />
| [[Elektronikversender#Digi-Key|Digikey]]<br />
|<br />
|-<br />
| [http://www.mikrocontroller.net/part/AOD403 AOD403]<br />
| D-Pak<br />
| Alpha&Omega<br />
| 1,5..3,5<br />
| 30<br />
| 70/12<br />
| 90<br />
| 8@10V<br />
| Evtl.Alt.zu IRF4905/S<br />
| Rei,[https://www.reichelt.de/mosfet-p-kanal-30-v-70-a-rds-on-0-0051-ohm-dpak-ao-d403-p166501.html?search=ao+d]<br />
| 0,62<br />
|}<br />
<br />
(Tabelle mit Click im Kopfbereich sortierbar; a.A. = Auf Anfrage, LL Logic Level, LIN Linearbetrieb möglich)<br />
<br />
== N-Kanal MOSFET==<br />
Alles selbstsperrend, also Anreicherungstypen. Statt MOS-Verarmungstypen auf sFET/jFET(s.u.) zurückgreifen!<br />
<br />
{| {{Tabelle}} class="wikitable sortable" id="nkanalmosfets"<br />
|- style="background-color:#eeeeee"<br />
! style="width:15%;" | Name<br />
! Gehäuse<br />
! Her<br>steller<br />
! <math>U_{GS(th)}</math> <br>/V<br />
! <math>U_{DS}</math><br>/V<br />
! <math>I_D</math><br>/A<br />
! <math>P</math><br>/W<br />
! <math>R_{DS,on}</math><br><math>m\Omega</math><br />
! Bemerkung<br />
! Lieferant<br />
! Preis<br>/€<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRLML6244 IRLML6244]<br />
| SOT-23<br />
| IRF<br />
| 0,5-1,1<br />
| 20<br />
| 6,3<br />
| 1,3<br />
| 21<br />
! <br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,13<br />
|-<br />
| SI2302DS<br />
| SOT-23<br />
| Vishay<br />
| 0,65-4,5<br />
| 20<br />
| 6<br />
| 1,25<br />
| 70<br />
| 2,5V LL, sehr billig<br />
| [[Elektronikversender#AliExpress|Ali]]<br />
| 0,01<br />
|-<br />
| IRFP4310Z <br />
| TO-247AC<br />
| irf<br />
| 2-4<br />
| 100<br />
| 120<br />
| 280<br />
| 4,8<br />
| <br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 1,80<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRFP450 IRFP450]<br />
| TO-247<br />
| irf<br />
| 2,0-4,0<br />
| 500<br />
| 14<br />
| 190<br />
| 400<br />
| <br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 1,20<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF530 IRF530]<br />
| TO-220<br />
| irf<br />
| 2,9<br />
| 100<br />
| 16<br />
| 94<br />
| 160<br />
| LIN<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,44<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRL3103 IRL3103]<br />
| TO-220AB<br />
| irf<br />
| 1,0<br />
| 30<br />
| 64<br />
| 94<br />
| 12<br />
| 4,5V LL, Qg=33nC (!)<br />
| [[Elektronikversender#Segor-electronics|Seg]]<br />
| 0,95<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF730A IRF730A]<br />
| TO-220AB<br />
| irf<br />
| 2,0-4,5<br />
| 400<br />
| 5,5<br />
| 74<br />
| 1000<br />
| Qg=22nC (!)<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,54<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRFP064 IRFP064]<br />
| TO-247AC<br />
| irf<br />
| 2,0<br />
| 60<br />
| 70<br />
| 300<br />
| 9<br />
| Qg=190 nC<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 1,65<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF3205 IRF3205]<br />
| TO-220AB<br />
| irf<br />
| 2,0<br />
| 55<br />
| 110<br />
| 200<br />
| 8<br />
|<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,69<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRL3803 IRL3803]<br />
| TO-220AB<br />
| irf<br />
| 1,0<br />
| 30<br />
| 140<br />
| 200<br />
| 6<br />
| 4,5V LL, Qg=140nC<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,96<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF540 IRF540]<br />
| TO-220AB<br />
| irf<br />
| 3<br />
| 100<br />
| 28<br />
| 150<br />
| 77<br />
| LIN<br />
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Kessler|Kes]]<br />
| 0,52<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF7401 IRF7401]<br />
| SO-8<br />
| irf<br />
| 2,7<br />
| 20<br />
| 8,7<br />
| 2,0<br />
| 22<br />
| 2,7V LL<br />
| [[Elektronikversender#Reichelt|Rei]], [[Elektronikversender#CBoden|CBo]]<br />
| 0,45<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF7403 IRF7403]<br />
| SO-8<br />
| irf<br />
| 4,85<br />
| 30<br />
| 8,5<br />
| 2,5<br />
| 22<br />
| 4,5V LL<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,42<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF7413 IRF7413]<br />
| SO-8<br />
| irf<br />
| 3,0<br />
| 30<br />
| 13,0<br />
| 2,5<br />
| 11<br />
| 4,5V LL<br />
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Kessler|Kes]]<br />
| 0,41<br />
|-<br />
| [http://www.mikrocontroller.net/part/BUZ11 BUZ11]<br />
| TO-220<br />
| ST<br />
| 4,0<br />
| 50<br />
| 33,0<br />
| 90,0<br />
| 30<br />
| LIN, SOA-Grenzen herstellerabhängig!<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,50<br />
|-<br />
| [http://www.mikrocontroller.net/part/BSS83 BSS83]<br />
| SOT143<br />
| NXP<br />
| 2,0<br />
| 10<br />
| 0,05<br />
| 0,23<br />
| 45000<br />
| nicht mit BSS83'''P''' verwechseln, Substratanschluss herausgeführt<br />
| [[Elektronikversender#RS_Components|RS]],[[Elektronikversender#TME_.28Transfer_Multisort_Elektronik.29|TME]]<br />
| 0,10<br />
|- <br />
| [http://www.mikrocontroller.net/part/BS170 BS170]<br />
| TO-92<br />
<br />
| gs<br />
| 2,0<br />
| 60<br />
| 0,3<br />
| 0,83<br />
| 5000<br />
| LIN<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,13<br />
|-<br />
| [http://www.mikrocontroller.net/part/BSN20 BSN20]<br />
| SOT-23<br />
| gs<br />
| 1,8<br />
| 50<br />
| 0,18<br />
| 0,35<br />
| 6000<br />
| 4,5V LL, LIN<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,092<br />
|-<br />
| [http://www.mikrocontroller.net/part/BSS138 BSS138]<br />
| SOT-23<br />
| div<br />
| 0,8-1,6<br />
| 50<br />
| 0,22<br />
| 0,36<br />
| 2000<br />
| 5V LL, LIN<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,06<br />
|-<br />
| [http://www.mikrocontroller.net/part/BSS123 BSS123]<br />
| SOT-23<br />
| div<br />
| 0,8-1,6<br />
| 100<br />
| 0,17<br />
| 0,36<br />
| 10000 @ 4,5V, <br />
| 4,5V LL, LIN<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,06<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRFP2907 IRFP2907]<br />
| TO-247AC<br />
| irf<br />
| 4,0<br />
| 75<br />
| 209<br />
| 470<br />
| 4,5<br />
|<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 2,70<br />
|-<br />
| [http://www.mikrocontroller.net/part/2N7000 2N7000]<br />
| TO-92<br />
| ON<br />
| 3,0<br />
| 60<br />
| 0,2<br />
| 0,35<br />
| 5000<br />
| 4,5V LL, LIN<br />
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Kessler|Kes]]<br />
| 0,13<br />
|-<br />
| [http://www.mikrocontroller.net/part/BS107 BS107]<br />
| TO-92<br />
| ON, Phi<br />
| 3,0<br />
| 200<br />
| 0,25<br />
| 0,35<br />
| 6400/14000<br />
| 2,6V LL; LIN<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,18<br />
|-<br />
| [http://www.mikrocontroller.net/part/BS108 BS108]<br />
| TO-92<br />
| ON, Phi<br />
| 2,0<br />
| 200<br />
| 0,25<br />
| 0,35<br />
| 8000<br />
| 2V LL; LIN<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,14<br />
|-<br />
| [http://www.mikrocontroller.net/part/BUK100 BUK100]<br />
| TO-220<br />
| Phi<br />
| 3,0<br />
| 50<br />
| 13,5<br />
| 40<br />
| 125<br />
| Überlast + <br>ESD-Schutz<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 1,40<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRL3705N IRL3705N]<br />
| TO-220AB<br />
| irf<br />
| 2,0<br />
| 55<br />
| 89<br />
| 170<br />
| 10<br />
| 4V LL, Qg=98nC<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 1,20<br />
|-<br />
| [http://www.mikrocontroller.net/part/BUZ72 BUZ72A]<br />
| TO-220<br />
| Infineon<br />
| 4,0<br />
| 100<br />
| 9,0<br />
| 40<br />
| 250<br />
| 5V LL, LIN<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,45<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRLZ34N IRLZ34N]<br />
| TO-220<br />
| irf<br />
| 2,5<br />
| 55<br />
| 30<br />
| 68<br />
| 35<br />
| 4V LL, LIN<br />
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Farnell|Far]],[[Elektronikversender#Conrad|Con]],[[Elektronikversender#CBoden|CBo]] <br />
| 0,39<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRLZ44N IRLZ44N]<br />
| TO-220<br />
| irf<br />
| 2<br />
| 55<br />
| 47<br />
| 110<br />
| 22<br />
| 4V LL, LIN<br />
| [[Elektronikversender#CBoden|CBo]] <br />
| 0,49<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRLML2502 IRLML2502]<br />
| SOT-23<br />
| irf<br />
| 1,2<br />
| 20<br />
| 4,2<br />
| 1<br />
| 45<br />
| 2,5V LL<br />
| [[Elektronikversender#csd-electronics|csd]] [[Elektronikversender#Reichelt|Rei (neu)]]<br />
| 0,17<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF1404 IRF1404]<br />
| TO-220AB<br />
| irf<br />
| 4,0<br />
| 40<br />
| 202<br />
| 333<br />
| 4<br />
| -<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 1,10<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRL1004 IRL1004]<br />
| TO-220<br />
| irf<br />
| 2,7<br />
| 40<br />
| 130<br />
| 200<br />
| 6,5<br />
| -<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 1,25<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRL530 IRL530]<br />
| TO220, D2Pack<br />
| irf<br />
| 2<br />
| 100<br />
| 15,0<br />
| 88<br />
| 160<br />
| <br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,57<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF830 IRF830]<br />
| TO220AB<br />
| irf<br />
| 2,0-4,5 <br />
| 500<br />
| 5,0<br />
| 74<br />
| 1400<br />
| LIN<br />
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Kessler|Kes]]<br />
| 0,57<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF840 IRF840]<br />
| TO220AB<br />
| irf<br />
| 2,0-4,0 <br />
| 500<br />
| 8,0<br />
| 125<br />
| 850<br />
| <br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,57<br />
|-<br />
| [http://www.mikrocontroller.net/part/FDC645N FDC645N]<br />
| SuperSOT-6<br />
| Fairchild<br />
| 1,5<br />
| 30<br />
| 5,5<br />
| 0,8/1,6<br />
| 30<br />
| -<br />
| [[Elektronikversender#csd-electronics|csd]] (a.A.), Far<br />
| 0,7<br />
|-<br />
| [http://www.mikrocontroller.net/part/BSP297 BSP297]<br />
| SOT-223<br />
| Siemens/Infineon<br />
| 0,8-2,4<br />
| 200<br />
| 0,65<br />
| 1,8<br />
| 6000<br />
| 200V <math>U_{DS}</math>, SMD und 4,5VLL, LIN (seltene Kombinaton)<br />
| [[Elektronikversender#Farnell|Far]], [[Elektronikversender#Schuricht|Schu]], [[Elektronikversender#RS_Components|RS]]<br />
| 0,56<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF7455 IRF7455]<br />
| SO-8<br />
| irf<br />
| 4,5<br />
| 30<br />
| 15<br />
| 2,5<br />
| 7,5<br />
| <br />
| [[Elektronikversender#Kessler|Kes]]<br />
| 1,04<br />
|-<br />
| [http://www.mikrocontroller.net/part/SI4442DY SI4442DY]<br />
| SO-8<br />
| vis<br />
| 2,5<br />
| 30<br />
| 22<br />
| 2,5<br />
| 5/4,5V<br />
| <br />
| [[Elektronikversender#Kessler|Kes]]<br />
| 1,64<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRLU2905 IRLU2905]<br />
| TO251, DPack<br />
| irf<br />
| 2,0<br />
| 55<br />
| 42<br />
| 110<br />
| 27<br />
| 4V LL<br />
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Farnell|Far]],[[Elektronikversender#CBoden|CBo]]<br />
| 0,54<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRFD014 IRFD014]<br />
| HEXDIP/DIP4<br />
| irf<br />
| 2,0-4,0<br />
| 60<br />
| 1,7<br />
| 1,3<br />
| 200<br />
| <br />
| [[Elektronikversender#Conrad|Con]],[[Elektronikversender#Reichelt|Rei]]<br />
| 0,52<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRFD024 IRFD024]<br />
| HEXDIP/DIP4<br />
| irf<br />
| 2,0-4,0<br />
| 60<br />
| 2,5<br />
| 1,3<br />
| 100<br />
| <br />
| [[Elektronikversender#Conrad|Con]],[[Elektronikversender#Reichelt|Rei]]<br />
| 0,54<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRLD024 IRLD024]<br />
| HEXDIP/DIP4<br />
| irf<br />
| 1,0-2,0<br />
| 60<br />
| 2,5<br />
| 1,3<br />
| 100<br />
| 4V LL<br />
| [[Elektronikversender#Conrad|Con]],[[Elektronikversender#Reichelt|Rei]]<br />
| 0,47<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRLU3717 IRLU3717]<br />
| I-Pak<br />
| irf<br />
| 2,0<br />
| 20<br />
| 120<br />
| 1,5/89<br />
| 4<br />
| 4,5V LL, Qg=21nC, <br />
| [[Elektronikversender#Conrad|Con]],[[Elektronikversender#Reichelt|Rei]]<br />
| 1,15<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRFP3703 IRFP3703]<br />
| TO-247AC<br />
| irf<br />
| 4,0<br />
| 30<br />
| 210<br />
| 230<br />
| 2,8<br />
| <br />
| [[Elektronikversender#Conrad|Con]]<br />
| 5,08<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF3710 IRF3710]<br />
| TO-220AB<br />
| irf<br />
| 4<br />
| 100<br />
| 57<br />
| 200<br />
| 23<br />
| <br />
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Conrad|Con]]<br />
| 0,83<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRLR7843 IRLR7843]<br />
| D-Pack<br />
| irf<br />
| 2,3<br />
| 30<br />
| 164<br />
| 140<br />
| 3,3<br />
| 4,5V LL, Qg: 34nC <br />
|<br />
| 0,70<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF1010N IRF1010N]<br />
| TO-220AB<br />
| irf<br />
| 4<br />
| 55<br />
| 85<br />
| 180<br />
| 11<br />
| <br />
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Farnell|Far]]<br />
| 1,99<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF1010Z IRF1010Z]<br />
| TO-220AB<br />
| irf<br />
| 4<br />
| 55<br />
| 75<br />
| 140<br />
| 7,5<br />
| <br />
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Conrad|Con]], [[Elektronikversender#Farnell|Far]]<br />
| 1,99<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRLIZ44N IRLIZ44N]<br />
| TO-220-Fullpak <br />
| irf<br />
| 1,0 - 2,0<br />
| 55<br />
| 30<br />
| 45<br />
| 25<br />
| 4V LL<br />
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Conrad|Con]]<br />
| 0,80<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRLU024N IRLU024N]<br />
| TO-251AA<br />
| irf<br />
| 1,0 - 2,0<br />
| 55<br />
| 17<br />
| 45<br />
| 80<br />
| 4V LL, Qg=15 nC (!)<br />
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Conrad|Con]]<br />
| 0,40<br />
|-<br />
| IRFZ48N<br />
| TO-220AB<br />
| irf<br />
| 3<br />
| 55<br />
| 64<br />
| 130<br />
| 14<br />
| <br />
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Conrad|Con]]<br />
| 0,60<br />
|-<br />
| [https://www.mikrocontroller.net/part/IRL2505 IRL2505]<br />
| TO-220AB<br />
| irf<br />
| 2,5<br />
| 55<br />
| 104<br />
| <br />
| 8<br />
| 4V LL<br />
| [[Elektronikversender#Farnell|Far]]<br />
| 3,99<br />
|-<br />
| [https://www.mikrocontroller.net/part/IRF7607 IRF7607]<br />
| Micro8<br />
| irf<br />
| 1,2<br />
| 20<br />
| 6,5<br />
| 1,8<br />
| 30<br />
| 2,5V LL<br />
| [[Elektronikversender#Conrad|Con]]<br />
| 1,89<br />
|-<br />
| [https://www.mikrocontroller.net/part/IRF3708 IRF3708]<br />
| TO-220AB<br />
| irf<br />
| 0,6 - 2<br />
| 30<br />
| 62<br />
| 87<br />
| 8<br />
| 2,8V LL<br />
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Conrad|Con]],[[Elektronikversender#CBoden|CBo]]<br />
| 0,69<br />
|-<br />
| [http://www.mikrocontroller.net/part/GF2304 GF2304]<br />
| SOT-23<br />
| gs<br />
| 1,0<br />
| 30<br />
| 2,5<br />
| 1,25<br />
| 135<br />
| Qg=3,7nC<br />
| [[Elektronikversender#Pollin_Electronic|Pol]]<br />
| 0,05<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRLR8743 IRLR8743]<br />
| I-Pak, D2Pack<br />
| IRF<br />
| 1,9<br />
| 30<br />
| 50<br />
| 68<br />
| 3,1<br />
| 4,5V LL, Qg=39nC<br />
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]] <br />
| 1,15<br />
|-<br />
| AOC2414<br />
| MCSP<br />
| Alpha&Omega<br />
| 0,52<br />
| 8<br />
| 4,5<br />
| 0,55<br />
| 19<br />
| 1,2V LL, Qg=21,5nC<br />
| Digikey <br />
|-<br />
| BSS131<br />
| SOT-23<br />
| Infineon<br />
| 0,8-1,8<br />
| 240<br />
| 0,4<br />
| 0,36<br />
| 14000<br />
|<br />
|<br />
|-<br />
|}<br />
<br />
(Tabelle mit Click im Kopfbereich sortierbar; a.A. Auf Anfrage, LL Logic Level, LIN Linearbetrieb möglich)<br />
<br />
== N-Kanal J-FET==<br />
<br />
{| {{Tabelle}} border="1" class="wikitable sortable" id="fetpaare"<br />
|- style="background-color:#eeeeee"<br />
! style="width:15%;" | Name<br />
! Gehäuse<br />
! Her<br>steller<br />
! <math>U_{GS(co)}</math> <br>/V<br />
! <math>U_{DS}</math><br>/V<br />
! <math>I_{D(max)}</math><br>/mA<br />
! Lieferant<br />
! Preis<br>/€<br />
|-<br />
| [http://www.mikrocontroller.net/part/BF245 BF245A]<br />
| TO-92<br />
| obsolet<br />
| -2,2<br />
| 30<br />
| 6,5<br />
| <br />
| 0,15 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/BF245 BF245B]<br />
| TO-92<br />
| obsolet<br />
| -3,8<br />
| 30<br />
| 15<br />
| <br />
| 0,15 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/BF245 BF245C]<br />
| TO-92<br />
| obsolet<br />
| -7,5<br />
| 30<br />
| 25<br />
| <br />
| 0,15 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/BF246 BF246A]<br />
| TO-92<br />
| obsolet<br />
| -4<br />
| 25<br />
| 80<br />
| <br />
| 0,15 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/BF246 BF246B]<br />
| TO-92<br />
| obsolet<br />
| -7<br />
| 25<br />
| 140<br />
| <br />
| 0,17 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/BF246 BF246C]<br />
| TO-92<br />
| obsolet<br />
| -12<br />
| 25<br />
| 250<br />
| ?<br />
| ?<br />
|-<br />
| [http://www.mikrocontroller.net/part/BF511 BF511]<br />
| SOT-23<br />
| diverse<br />
| -1,5<br />
| 20<br />
| 7<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,36 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/BFR30 BFR30]<br />
| SOT-23<br />
| diverse<br />
| -4<br />
| 25<br />
| 10<br />
| [[Elektronikversender#Kessler|Kes]]<br />
| 0,29 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/BFR31 BFR31]<br />
| SOT-23<br />
| diverse<br />
| -2<br />
| 25<br />
| 5<br />
| [[Elektronikversender#Kessler|Kes]]<br />
| 0,29 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/MMBF4416 MMBF4416]<br />
| SOT-23<br />
| Fairchild<br />
| -5,5<br />
| 15<br />
| 5<br />
| [[Elektronikversender#Conrad|Con]]<br />
| 0,52 €<br />
|}<br />
<br />
(Tabelle mit Click im Kopfbereich sortierbar)<br />
<br />
== FET-Paare ==<br />
<br />
{| {{Tabelle}} border="1" class="wikitable sortable" id="fetpaare"<br />
|- style="background-color:#eeeeee;writing-mode:sideways-lr;"<br />
! Bezeichnung<br />
! Package<br />
! Hersteller<br />
! U<sub>GS</sub>/V<br />
! U<sub>DS</sub>/V<br />
! I<sub>D</sub>/A<br />
! P/W<br />
! R<sub>DSon</sub>/mΩ<br />
! Bemerkung<br />
! Lieferant<br />
! Einzelpreis<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF7389 IRF7389]<br />
| SO-8<br />
| IRF<br />
| 3,0<br />
| 30<br />
| 7,3/-5,3<br />
| 2,0<br />
| 29/58<br />
| P+N<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,56 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF7501 IRF7501]<br />
| micro8<br />
| IRF<br />
| 2,7<br />
| 20<br />
| 2,4<br />
| ?<br />
| 135 @4,5V<sub>GS</sub><br />
| 2*N<br />
| [[Elektronikversender#Kessler|Kessler]], [[Elektronikversender#Conrad|Con]]<br />
| 1,64 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF7506 IRF7506]<br />
| micro8<br />
| IRF<br />
| 4,5<br />
| 30<br />
| 1,7<br />
| ?<br />
| 270 @10V<sub>GS</sub><br />
| 2*P<br />
| [[Elektronikversender#Kessler|Kessler]], [[Elektronikversender#Conrad|Con]]<br />
| 0,56 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF7103 IRF7103]<br />
| SO-8<br />
| IRF<br />
| 4,5<br />
| 50<br />
| 2,3<br />
| 2<br />
| 130 @10V<sub>GS</sub><br />
| 2*N<br />
|[[Elektronikversender#Reichelt|Rei]], [[Elektronikversender#Conrad|Con]]<br />
| 0,32 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF7104 IRF7104]<br />
| SO-8<br />
| IRF<br />
| 4,5<br />
| 20<br />
| 2,3<br />
| 2<br />
| 250 @10V<sub>GS</sub><br />
| 2*P<br />
|[[Elektronikversender#Reichelt|Rei]]<br />
| 0,32 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF7316 IRF7316]<br />
| SO-8<br />
| IRF<br />
| 4,5<br />
| 30<br />
| 4,9<br />
| ?<br />
| 58 @10V<sub>GS</sub><br />
| 2*P<br />
|[[Elektronikversender#Reichelt|Rei]]<br />
| 0,49 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRF7313 IRF7313]<br />
| SO-8<br />
| IRF<br />
| 4,5<br />
| 30<br />
| 6,5<br />
| ?<br />
| 46 @4.5V<sub>GS</sub><br />
| 2*N<br />
| [[Elektronikversender#Kessler|Kessler]], [[Elektronikversender#Conrad|Con]]<br />
| 0,66 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/FDD8424H FDD8424H]<br />
| Dual DPAK4L<br />
| Fairchild<br />
| <br />
| 40<br />
| 9/-6,5<br />
| 3<br />
| 24/54 @10V<sub>GS</sub> <br> 30/70 @4,5V<sub>GS</sub><br />
| P+N<br />
| [[Elektronikversender#Digi-Key|Digi-Key]] <br />
| 0,73 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/SUD50NP04-94 SUD50NP04-94]<br />
| TO252-4L DPAK4L<br />
| Vishay<br />
| 2<br />
| 40 <br />
| 8<br />
| 8?<br />
| 41/53 @10V<sub>GS</sub> <br> 45/72 @4,5V<sub>GS</sub><br />
| P+N<br />
| [[Elektronikversender#Farnell|Farnell]]<br />
| 0,56 €<br />
|-<br />
| IRF7309<br />
| SO-8<br />
| IRF<br />
| &nbsp;4,5 <br> -4,5<br />
| &nbsp;30 <br> -30 <br />
| &nbsp;4 <br> -3<br />
| 1,4<br />
| 50/100 @10V<sub>GS</sub> <br> 80/160 @4,5V<sub>GS</sub><br />
| P+N<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,38 €<br />
|-<br />
| IRF7307<br />
| SO-8<br />
| IRF<br />
| &nbsp;2 <br> -2,5<br />
| &nbsp;20 <br> -20 <br />
| &nbsp;5,2 <br> -4,3<br />
| 2<br />
| 50/90 @4,5V<sub>GS</sub> <br> 70/140 @2,7V<sub>GS</sub><br />
| P+N<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,47 €<br />
|-<br />
| IRF7343<br />
| SO-8<br />
| IRF<br />
| &nbsp;3 <br> -3,5<br />
| &nbsp;55 <br> -55 <br />
| &nbsp;4,7 <br> -3,4<br />
| 2<br />
| 43/95 @10V<sub>GS</sub> <br> 56/150 @4,5V<sub>GS</sub><br />
| P+N<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,47 €<br />
|-<br />
| IRF7319<br />
| SO-8<br />
| IRF<br />
| &nbsp;3 <br> -3,5<br />
| &nbsp;30 <br> -30 <br />
| &nbsp;6,5 <br> -4,9<br />
| 2<br />
| 23/42 @10V<sub>GS</sub> <br> 32/76 @4,5V<sub>GS</sub><br />
| P+N<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,50 €<br />
|-<br />
| IRF7314<br />
| SO-8<br />
| IRF<br />
| -2,0<br />
| -20 <br />
| -5,3<br />
| 2,0<br />
| 49 @-4,5V<sub>GS</sub> <br> 82 @-2,7V<sub>GS</sub><br />
| 2*P<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,45 €<br />
|-<br />
| IRF7314<br />
| SO-8<br />
| IRF<br />
| -2,0<br />
| -20 <br />
| -5,3<br />
| 2,0<br />
| 49 @-4,5V<sub>GS</sub> <br> 82 @-2,7V<sub>GS</sub><br />
| 2*P<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,45 €<br />
|-<br />
| IRF7304<br />
| SO-8<br />
| IRF<br />
| -2,5<br />
| -20<br />
| -4,3<br />
| 2,0<br />
| 90 @-4,5V<sub>GS</sub> <br> 140 @-2,7V<sub>GS</sub><br />
| 2*P<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,46 €<br />
|-<br />
| IRF7306<br />
| SO-8<br />
| IRF<br />
| -4,5<br />
| -30<br />
| -3,6<br />
| 2,0<br />
| 100 @-10V<sub>GS</sub> <br> 160 @-4,5V<sub>GS</sub><br />
| 2*P<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,47 €<br />
|-<br />
| IRF7342<br />
| SO-8<br />
| IRF<br />
| -3,5<br />
| -55<br />
| -3,4<br />
| 2,0<br />
| 95 @-10V<sub>GS</sub> <br> 150 @-4,5V<sub>GS</sub><br />
| 2*P<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,50 €<br />
|-<br />
| IRF7328<br />
| SO-8<br />
| IRF<br />
| -3,5<br />
| -30<br />
| -8,0<br />
| 2,0<br />
| 17 @-10V<sub>GS</sub> <br> 26,8 @-4,5V<sub>GS</sub><br />
| 2*P<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,80 €<br />
|-<br />
| IRF7324<br />
| SO-8<br />
| IRF<br />
| -1,5<br />
| -20<br />
| -9,0<br />
| 2,0<br />
| 18 @-4,5V<sub>GS</sub> <br> 26 @-2,5V<sub>GS</sub><br />
| 2*P<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,87 €<br />
|-<br />
| IRF7303<br />
| SO-8<br />
| IRF<br />
| 4,5<br />
| 30 <br />
| 4,9<br />
| 2,0<br />
| 50 @10V<sub>GS</sub> <br> 80 @4,5V<sub>GS</sub><br />
| 2*N<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,43 €<br />
|-<br />
| IRF7301<br />
| SO-8<br />
| IRF<br />
| 2<br />
| 20 <br />
| 5,2<br />
| 2,0<br />
| 50 @4,5V<sub>GS</sub> <br> 70 @2,7V<sub>GS</sub><br />
| 2*N<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,46 €<br />
|-<br />
| IRF7341<br />
| SO-8<br />
| IRF<br />
| 3<br />
| 55 <br />
| 4,7<br />
| 2,0<br />
| 43 @10V<sub>GS</sub> <br> 56 @4,5V<sub>GS</sub><br />
| 2*N<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,46 €<br />
|-<br />
| IRF7311<br />
| SO-8<br />
| IRF<br />
| 2<br />
| 20 <br />
| 6,6<br />
| 2,0<br />
| 23 @4,5V<sub>GS</sub> <br> 30 @2,7V<sub>GS</sub><br />
| 2*N<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,60 €<br />
|-<br />
| IRF7380<br />
| SO-8<br />
| IRF<br />
| 4,5<br />
| 80 <br />
| 3,6<br />
| 2,0<br />
| 61 @10V<sub>GS</sub><br />
| 2*N<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,57 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/IRFI4024H-117P IRFI4024H-117P]<br />
| TO-220-5<br />
| IRF<br />
| 2<br />
| 55<br />
| 11<br />
| 14<br />
| 50 @10V<sub>GS</sub><br />
| 2*N<br />
| [[Elektronikversender#Reichelt|Reichelt]]<br />
| 2,10 €<br />
|}<br />
<br />
(Tabelle mit Click im Kopfbereich sortierbar)<br />
<br />
== MOSFET-Treiber ==<br />
Nahezu alle MOSFET-Treiber haben eine der typischen Gatespannung von Leistungs-MOSFETs angepasste Speisespannung von 10..20 V. In der Regel werden sie mit 12 V betrieben. (Die Spannungsangabe in der Tabelle bezieht sich daher auf die <i>Brückenspeisespannung</i> und gilt nur für High-Side-Treiber.) Davon unabhängig kann die Schwellspannung für Logikeingänge TTL-kompatibel sein (für Mikrocontroller) oder bei der halben Speisespannung liegen (für konventionelle Schaltungen).<br />
<br />
* Detaillierte [[Treiber]]-Dimensionierung<br />
* Treiber-Typ:<br />
** Low = Low-Side-Treiber (ohne Potenzialversatzstufe)<br />
** High = High-Side-Treiber (<i>mit</i> Potenzialversatzstufe)<br />
** High + Low = beide Treiber mit <i>getrennten</i> Logikeingängen<br />
** Halbbrücke = beide Treiber mit <i>gemeinsamem</i> Logikeingang und eingebautem Totzeitgenerator<br />
** Vollbrücke = zwei Halbbrückentreiber<br />
<br />
{| {{Tabelle}} border="1" class="wikitable sortable" id="fettreiber"<br />
|- style="background-color:#eeeeee"<br />
! Bezeichnung<br />
! Treiber-Typ<br />
! Strom<br />
! Spannung<br />
! Logikeingang<br />
! Sockel<br />
! Lieferant / Datenblatt<br />
! Einzelpreis<br />
|-<br />
| [http://www.mikrocontroller.net/part/IR2101 IR2101]<br />
| High + Low<br />
| 130/270mA<br />
| 600V<br />
| 3,3V<br />
| DIL8/SO8<br />
| [[Elektronikversender#Conrad|Con]] <br />
| 2,30 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/IR2104 IR2104]<br />
| Halbbrücke<br />
| I<sub>H</sub> = 130 mA<br>I<sub>L</sub> = -270 mA<br />
| 600V<br />
| U<sub>L</sub> ≤ 0,8 V<br>U<sub>H</sub> ≥ 3 V<br />
| DIL8/SO8<br />
| [[Elektronikversender#Reichelt|Rei]]<br>[[Elektronikversender#Conrad|Con]]<br />
| 1,15 €<br>2,00 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/IR2110 IR2110]<br />
| High + Low<br />
| 2A<br />
| 500V<br />
| 3,3V<br />
| DIL14/SO16<br />
| [[Elektronikversender#Reichelt|Rei]]<br>[[Elektronikversender#Conrad|Con]] <br />
| 1,30 €<br>1,55 €<br />
|- <br />
| [http://www.mikrocontroller.net/part/IR2111 IR2111]<br />
| Halbbrücke<br />
| 200/430mA<br />
| 600V<br />
| 10-20V CMOS Eingang<br />
| DIL8/SO8, maximale Kriechwege<br />
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]<br />
| 1,10 €<br />
|- <br />
| [http://www.mikrocontroller.net/part/IR2112 IR2112]<br />
| High + Low<br />
| 200/420mA<br />
| 600V<br />
| 3,3V<br />
| DIL14/SO16<br />
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]] <br />
| 1,45 €<br />
|- <br />
| [http://www.mikrocontroller.net/part/IR2113 IR2113]<br />
| High + Low<br />
| 2A<br />
| 600V<br />
| 3,3V<br />
| DIL14/SO16<br />
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]] <br />
| 1,85 €<br />
|- <br />
| [http://www.mikrocontroller.net/part/IR2117 IR2117]<br />
| High<br />
| 200/420mA<br />
| 600V<br />
| 10-20V CMOS Eingang<br />
| DIL8/SO8, maximale Kriechwege<br />
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]] <br />
| 1,20 €<br />
|- <br />
| [http://www.mikrocontroller.net/part/IR2121 IR2121]<br />
| Low<br />
| 1A/2A<br />
| -<br />
| 2,5V<br />
| DIL8/SO8, Strombegrenzung<br />
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]<br />
| 2,15 €<br />
|- <br />
| [http://www.mikrocontroller.net/part/IR2125 IR2125]<br />
| High<br />
| 1A/2A<br />
| 500V<br />
| 2,5V<br />
| DIL8/SO8, Strombegrenzung, maximale Kriechwege<br />
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]] <br />
| 4,20 €<br />
|- <br />
| [http://www.mikrocontroller.net/part/IR2127 IR2127]<br />
| High<br />
| 200/420mA<br />
| ?<br />
| 3,3V<br />
| DIL8/SO8, maximale Kriechwege, Fehlerausgang<br />
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]] <br />
| 2,40 €<br />
|- <br />
| [http://www.mikrocontroller.net/part/IR2130 IR2130]<br />
| 3-Phase Bridge<br />
| 200/420mA<br />
| 600V<br />
| 2,5V<br />
| DIL28/SO28<br />
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]] <br />
| 2,50 €<br />
|- <br />
| [http://www.mikrocontroller.net/part/IR2151 IR2151]<br />
| Halbbrücke mit Oszillator<br />
| 100/210mA<br />
| 600V<br />
| ?<br />
| DIL8/SO8<br />
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]] <br />
| 2,50 €<br />
|- <br />
| [http://www.mikrocontroller.net/part/IR2153 IR2153]<br />
| Halbbrücke mit Oszillator<br />
| 100/210mA<br />
| 600V<br />
| n/a<br />
| DIL8/SO8<br />
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]<br />
| 1,20 €<br />
|- <br />
| [http://www.mikrocontroller.net/part/IR2155 IR2155]<br />
| Halbbrücke mit Oszillator<br />
| 210/420mA<br />
| 600V<br />
| n/a<br />
| DIL8/SO8<br />
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]<br />
| 3,50 €<br />
|- <br />
| [http://www.mikrocontroller.net/part/IR2181 IR2181]<br />
| High + Low<br />
| 1.4A/1.8A<br />
| 600V<br />
| 3,3V/5V<br />
| DIL8/SO8<br />
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]<br />
| 2,10 €<br />
|- <br />
| [http://www.mikrocontroller.net/part/IR2183 IR2183]<br />
| Halbbrücke<br />
| 1.4A/1.8A<br />
| 600V<br />
| 3,3V<br />
| DIL8/SO8<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 4,00 €<br />
|- <br />
| [http://www.mikrocontroller.net/part/IR2184 IR2184]<br />
| Halbbrücke<br />
| 1.4A/1.8A<br />
| 600V<br />
| 3,3V/5V<br />
| DIL8/SO8<br />
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]] <br />
| 3,20 €<br />
|- <br />
| [http://www.mikrocontroller.net/part/IR2136 IR2136]<br />
| 3 Phase Bridge<br />
| 120/250mA<br />
| 600V<br />
| 3,3V<br />
| DIP28/SOIC28,<br />
| [[Elektronikversender#Conrad|Con]]<br />
| 1,80 €<br />
|- <br />
| [http://www.mikrocontroller.net/part/ICL7667 ICL7667]<br />
| 2 x Low<br />
| ?<br />
| 4.5-15V, 7Ω<br />
| 3,3V<br />
| DIL8/SO8 <br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 2,00 €<br />
|- <br />
| [http://www.mikrocontroller.net/part/HIP4081A HIP4081A]<br />
| Vollbrücke<br />
| 2,5A<br />
| 80V<br />
| ?<br />
| DIP20/SOIC20<br />
| [[Elektronikversender#Farnell|Far]]<br />
| 8,00 €<br />
|- <br />
| [http://www.mikrocontroller.net/part/HIP4082 HIP4082]<br />
| Vollbrücke<br />
| 1,2A<br />
| 80V<br />
| ?<br />
| DIP16/SOIC16<br />
| [[Elektronikversender#Farnell|Far]] [[Elektronikversender#Farnell|Far]]<br />
| 6,20 €<br />
|- <br />
| [http://www.mikrocontroller.net/part/HIP4083 HIP4083]<br />
| 3 x High<br />
| 0,3A<br />
| 80V<br />
| ?<br />
| DIP16/SOIC16<br />
| [[Elektronikversender#Farnell|Far]]<br />
| 4,80 €<br />
<!-- ohne Preis und Lieferant<br />
|- <br />
| [http://www.mikrocontroller.net/part/HIP4084 HIP4084]<br />
| 4 Phase Bridge<br />
| 0,5A<br />
| 80V<br />
| ?<br />
| DIP28/SOIC28<br />
| <br />
| <br />
--><br />
|- <br />
| [http://www.mikrocontroller.net/part/HIP4086 HIP4086]<br />
| 3 Phase Bridge<br />
| 0.5A<br />
| 80V<br />
| ?<br />
| DIP24/SOIC24<br />
| [[Elektronikversender#Farnell|Far]]<br />
| 8,00 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/TC4451 TC4451/TC4452]<br />
| Low<br />
| 12A peak, 2,5A DC<br />
| ?<br />
| 4,5-18V<br />
| DIL8/SO8<br />
| [[Elektronikversender#Farnell|Far]]<br />
| 3,00 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/LM5104 LM5104]<br />
| Halbbrücke<br />
| 1,6/1,8A<br />
| 100V<br />
| 2,5V<br />
| SO8/LLP10 <br />
| [[Elektronikversender#RS_Components|RS]]<br />
| 3,20 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/MCP1407 MCP1407-E/P]<br />
| Low<br />
| 6A peak, 1,3A DC<br />
| 4,5-18V<br />
| 4,5-18V (VDD+0,3V)<br />
| DIL8/SO8<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 0,93 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/MCP1416 MCP1416]<br />
| Low<br />
| 1.5A peak<br />
| 4.5-18V<br />
| 3.3V - VDD+0.3V<br />
| SOT-23-5<br />
| [[Elektronikversender#TME_.28Transfer_Multisort_Elektronik.29|TME]]<br />
| 0,76 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/MAX626 MAX626]<br />
| 2 x Low, inverting<br />
| ?<br />
| ?<br />
| 4,5-18 V<br />
| DIL8/SO8<br />
| [[Elektronikversender#Reichelt|Rei]]<br />
| 3,40 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/NCP5106 NCP5106]<br />
| High + Low<br />
| 250/500mA<br />
| 600V<br />
| 2,3-20V<br />
| DIL8/SO8<br />
| [[Elektronikversender#Farnell|Far]]<br />
| 2,37 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/NCP5304 NCP5304]<br />
| High + Low<br />
| 250/500mA<br />
| 600V<br />
| 2,3-20V<br />
| DIL8/SO8<br />
| [[Elektronikversender#Farnell|Far]]<br />
| 2,02 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/FAN7380 FAN7380]<br />
| Halbbrücke<br />
| 90/180mA<br />
| 600V<br />
| 2,5-25V<br />
| SO8<br />
| [[Elektronikversender#Farnell|Far]]<br />
| 0,99 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/FAN7382 FAN7382]<br />
| High + Low<br />
| 350/650mA<br />
| 600V<br />
| 2,9-20V<br />
| DIL8/SO8/S014<br />
| [[Elektronikversender#Farnell|Far]]<br />
| 1,25 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/FAN7361 FAN7361]<br />
| Halbbrücke<br />
| 250/500mA<br />
| 600V<br />
| 3,6-25V<br />
| SO8<br />
| [[Elektronikversender#Farnell|Far]]<br />
| 1,18 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/FAN7362 FAN7362]<br />
| Halbbrücke<br />
| 250/500mA<br />
| 600V<br />
| 2,9-25V<br />
| SO8<br />
| [[Elektronikversender#Farnell|Far]]<br />
| 1,71 €<br />
|-<br />
| [http://www.mikrocontroller.net/part/FAN7842 FAN7842]<br />
| High + Low<br />
| 350/650mA<br />
| 200V<br />
| 2,9-25V<br />
| SO8<br />
| [[Elektronikversender#Farnell|Far]]<br />
| 1,05 €<br />
|}<br />
<br />
== Anmerkungen ==<br />
* U<sub>GS(th)</sub> - minimale Gatespannung, bei welcher der MOSFET zu leiten anfängt (100µA..1mA, nicht genormt). Zur vollständigen Durchschaltung bei maximalem Strom braucht es höhere Spannungen, siehe [https://www.mikrocontroller.net/articles/FET#Gate-Source_Threshold_Voltage Artikel FET].<br />
* Logic Level - FET schaltet bei niedrigen Gatespannungen von typisch 4,5V (z.&nbsp;B. CMOS Logikpegel) hinreichend durch. Normale MOSFETs brauchen hierfür typisch 10V.<br />
* U<sub>GS(co)</sub> - Gate Source Cut Off Spannung, bei welcher der Drainstrom I<sub>D</sub> eines JFETs praktisch Null ist. Die Messbedingung ist jedoch nicht genormt (0,5nA..200µA).<br />
* N-Kanal MOSFETs mit niedrigem R<sub>DS,On</sub> sind technologisch einfacher herzustellen als P-Kanal MOSFETs. Deshalb gibt es bei P-Kanal keine so große Auswahl und oft werden Schaltungen angestrebt, in denen ausschließlich N-Kanal MOSFETs verwendet werden. Es gibt spezielle Treiberbausteine, die über eine Ladungspumpe für entsprechend hohe Gatespannung auch für die High-Side N-Fets sorgen ("Bootstrap Circuits", siehe Artikel [[Treiber]]).<br />
* Bei der Dimensionierung ist zu beachten, dass die Stromangabe im allgemeinen für 25°C gilt. Geht man davon aus, dass der MOSFET mit maximal zulässigem Strom betrieben wird und mit passend dimensioniertem [[Kühlkörper]] ausgestattet ist, so beträgt die Sperrschichttemperatur bis zu 150°C, folglich gilt z.&nbsp;B. für den IRF540 nicht mehr 28A, sondern nur noch ca. 12-15A.<br />
* Restströme sind auch stark temperaturabhängig. Bei höherer Temperatur nehmen die Restströme exponentiell zu. So können bei 100°C durchaus 100 µA zwischen Source und Drain auch im gesperrten Zustand fließen. Bei 25°C ist dieser Reststrom meist bei 1µA spezifiziert. Real sind es meist weniger.<br />
* Der Gate-Charge-Wert Qg (s. Datenblatt) bestimmt, wie schnell das Gate beim Schalten umgeladen werden kann. Auch wenn MOSFETs stromlos den durchgeschalteten Zustand halten können, braucht man während des Umschaltvorganges einen Strom, der das Gate umlädt (ähnlich wie ein Kondensator). Je höher dieser Strom, um so schneller ist der Umschaltvorgang und um so geringer die Verlustleistung während dieser Phase. Leistungs-MOSFETs können bei höheren Frequenzen (>1KHz) oft nur mit höheren Gateströmen von 0,1A-2A sinnvoll geschaltet werden. Man kann das Gate also nicht direkt an einen Digitalpin anschließen. Man braucht einen [[MOSFET-Übersicht#MOSFET-Treiber | MOSFET-Treiber]]. Manche MOSFETs haben eine sehr geringe Total Gate Charge (z.&nbsp;B. 4-10nC). Diese können in gewissen Grenzen recht gut direkt an digitalen [[Ausgangsstufen Logik-ICs | Logikausgängen]] betrieben werden, ein praktisches Beispiel findet sich [http://www.mikrocontroller.net/topic/246449#2519459 hier]. Zur Abschätzung kann man sich merken: Wenn man das Gate eines MOSFETs mit einer Eingangskapazität von 1nF (~10nC) in 100ns auf 10V aufladen will, braucht man dazu 100mA.<br />
<br />
== Lieferantenübersicht ==<br />
* [[Elektronikversender]]<br />
* [[Elektronikversender#Reichelt|Rei]]<nowiki>chelt</nowiki><br />
* [[Elektronikversender#elpro-Darmstadt|el]]<nowiki>pro</nowiki><br />
* [[Elektronikversender#Conrad|Con]]<nowiki>rad</nowiki><br />
* [[Elektronikversender#Kessler|Kes]]<nowiki>sler</nowiki><br />
* [[Elektronikversender#csd-electronics|csd]]<nowiki>-electronics</nowiki><br />
* [[Elektronikversender#Farnell|Far]]<nowiki>nell</nowiki> (nur gewerbliche Kunden oder Studenten)<br />
* [[Elektronikversender#Schuricht|Schu]]<nowiki>richt</nowiki><br />
* [[Elektronikversender#RS_Components|RS]]<br />
* [[Elektronikversender#Spoerle|Spo]]<nowiki>erle</nowiki><br />
<br />
== Herstellerübersicht ==<br />
* [irf] [http://www.irf.com International Rectifier]<br />
* [Siliconix] [http://www.vishay.com/company/brands/siliconix/ Vishay Siliconix]<br />
* [st] [http://www.st.com/web/en/home.html STMicroelectronics]<br />
<br />
== IRF MOSFET-Codierung ==<br />
* IRF: Alle "Standardtransistoren", also TO-220-Gehäuse<br />
* IRFB: Hochspannungs-MosFETs<br />
* IRFD: MosFETs im Dip-4-Gehäuse<br />
* IRFI: MosFETs im isolierten TO-220-Gehäuse<br />
* IRFP: MosFETs im TO-247AC-Gehäuse<br />
* IRFR: MosFETs im D-Pak<br />
* IRFU: MosFETs im I-Pak<br />
* IRFZ: Also die die ich kenne liegen alle so bei 50-60V mit relativ niedrigem Rds(on), also so für mittlere Leistungen<br />
* IRG: Afaik sind das IGBTs<br />
* IRL: Logic-Level MosFETs<br />
* IRLD: Logic-Level MosFETs im Dip-4 Gehäuse<br />
* IRLI: Logic-Level MosFETs im isolierten TO-220-Gehäuse<br />
* IRLR: Logic-Level MosFETs im D-Pak<br />
* IRLU: Logic-Level MosFETs im I-Pak<br />
<br />
== Links ==<br />
* [[FET]]<br />
* [[IGBT]]<br />
* [[Treiber]]<br />
* [[H-Brücken Übersicht]]<br />
* [http://www.mikrocontroller.net/topic/280480#2960070 Forumsbeitrag]: Clevere MOSFET-Treiber mit kleinsten Trafos<br />
* [http://www.mikrocontroller.net/topic/283585#3004839 Forumsbeitrag]: Galvanisch getrennte Ansteuerung eines MOSFETs mittels Übertrager und 100% Tastverhältnis<br />
<br />
== Weblinks ==<br />
* [http://www.sprut.de/electronic/switch/nkanal/nkanal.html N-Kanal MOSFET leicht erklärt bei sprut.de]<br />
* [http://www.sprut.de/electronic/switch/pkanal/pkanal.html P-Kanal MOSFET leicht erklärt bei sprut.de]<br />
* [http://elektronik-kompendium.de/sites/bau/0510161.htm MOSFET im ElKo]<br />
* [http://elektronik-kompendium.de/public/schaerer/battoff.htm Abschaltverzögerung beim ElKo]<br />
* [http://elektronik-kompendium.de/sites/bau/0207011.htm FET beim ElKo]<br />
* [http://de.wikipedia.org/wiki/Mosfet MOSFET bei Wikipedia]<br />
* [https://assets.nexperia.com/documents/technical-note/TN00008.pdf Power MOSFET frequently asked questions and answers (TN00008 von nexperia)]<br />
<!-- * [http://www.irf.com/product-info/auto/autogdic.html IR21xx Familienvergleich] --><br />
<br />
== Parametrische Suche beim Hersteller ==<br />
* [http://www.infineon.com/cms/de/product/channel.html?channel=db3a304319c6f18c011a14e5341b25f1 Infineon]<br />
* [http://www.nxp.com/#/ps/ps=%5Bi%3D48014%5D%7Cpp%3D%5Bt%3Dpfp%2Ci%3D48014%5D NXP standard Mosfets]<br />
* [http://www.onsemi.com/PowerSolutions/parametrics.do?id=809&lctn=home ONsemi]<br />
* [http://www.diodes.com/zetex/?ztx=3.0/3-3-1@tcatid~7 Diodes (vormals Zetex)]<br />
* [http://www.irf.com/product-info/hexfet/ IRF]<br />
* [http://www.vishay.com/mosfets/ Vishay]<br />
<br />
[[Kategorie:Liste mit Bauteilen]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=Temperatursensor&diff=107522Temperatursensor2025-05-24T20:12:29Z<p>Heha: Ratiometrische Messung ohne weitere aktive Bauelemente möglich und üblich</p>
<hr />
<div>Will man mit einem [[Mikrocontroller]] Temperaturen messen, dann braucht man<br />
* einen [[Sensor]], der die Temperatur z.&nbsp;B. in eine Spannung oder einen Strom umsetzt<br />
* einen [[ADC | AD-Wandler]], der das Signal digitalisiert. Der kann auf dem Sensor oder dem Mikrocontroller integriert sein.<br />
<br />
Temperatursensoren gibt es nun in allen möglichen Varianten. Vom temperaturabhängigen [[Widerstand]] bis zum fertig abgeglichenen All-in-one-Bauteil mit digitalem Ausgang. Wie bei allen Sensoren sollte man auch hier genau hinschauen und [[Auflösung und Genauigkeit]] unterscheiden.<br />
<br />
== Analoge Temperatursensoren ==<br />
<br />
=== Pt100 ===<br />
<br />
Unter einem Pt100 versteht man einen Platinwiderstand, der bei 0°C einen Widerstand von 100Ω hat.<br />
Platinwiderstände sind temperaturabhängige Widerstände mit hoher Wiederholgenauigkeit und Konstanz[http://de.wikipedia.org/wiki/Konstante]. Wegen der relativ geringen Widerstandsänderung von nur ca. 0,4Ω pro Grad ist etwas mehr Schaltungsaufwand erforderlich als bei anderen Sensoren. Genauere Formeln zur Temperaturbestimmung gibt es u.a. bei [http://de.wikipedia.org/wiki/Pt100 Wikipedia]. Ein Schaltplan findet sich bei der [http://www.heise.de/ct/artikel/Sensibelchen-289608.html c't].<br />
<br />
Die Sensoren gibt es auch mit anderen Widerstandswerten, z.&nbsp;B. mit 1000&Omega; und heißen dann entsprechend Pt1000. Man setzt diese vor allem ''dann'' ein, wenn Eigenerwärmung oder Stromverbrauch eine Rolle spielt.<br />
<br />
Da bei der Entscheidung auf Pt100/Pt1000 Geld kaum eine Rolle spielt, entscheidet man sich für deren Auswertung häufig für fertige Schaltkreise mit passendem Verstärker und A/D-Wandler, wie dem MAX31865.<br />
Im Interesse einer präzisen Funktion sollte dieser dennoch am besten mit einer vom Mikrocontroller entkoppelten stabilisierten Spannung betrieben werden.<br />
Serienwiderstände in den I²C-Leitungen helfen, dass sich auch darüber weniger Störungen ausbreiten.<br />
<br />
Vorteil:<br />
* genormt<br />
* großer Meßbereich<br />
* hohe Linearität<br />
* hohe Wiederholgenauigkeit<br />
* einfach austauschbar<br />
<br />
Nachteil:<br />
* brauchen aufwändigere Auswerteschaltung<br />
<br />
Links:<br />
* [http://de.wikibooks.org/wiki/Linearisierung_von_resistiven_Sensoren/_Pt100 Wikibooks: Linearisierung von resistiven Sensoren - PT100]<br />
* [https://www.heise.de/ct/artikel/Sensibelchen-289608.html c't-Artikel: Mikrocontroller-Programmierung: Timer, Sensoren und Drehgeber (mit PT100 Schaltung)]<br />
* [http://www.maxim-ic.com/app-notes/index.mvp/id/3450 Maxim AN3450 Positive Analog Feedback Compensates PT100 Transducer]<br />
* [http://www.maxim-ic.com/app-notes/index.mvp/id/4875 Maxim AN4875 High-Accuracy Temperature Measurements Call for Platinum Resistance Temperature Detectors (PRTDs) and Precision Delta-Sigma ADCs]<br />
* [http://ww1.microchip.com/downloads/en/AppNotes/01154a.pdf Microchip AN1154 Precision RTD Instrumentation for Temperature Sensing]<br />
* [http://www.analog.com/static/imported-files/application_notes/AN709_0.pdf Analog Devices AN709 RTD Interfacing and Linearization Using an ADuC8xx MicroConverter]<br />
<br />
=== NTC/PTC ===<br />
<br />
NTC und PTC sind temperaturabhängige Widerstände.<br />
<br />
* NTC (engl. '''N'''egative '''T'''emperature '''C'''oefficient, Heißleiter), hat bei hohen Temperaturen seinen niedrigsten Widerstand, z.&nbsp;B. Silizium<br />
* PTC (engl. '''P'''ositive '''T'''emperature '''C'''oefficient, Kaltleiter), hat bei niedrigen Temperaturen seinen geringsten Widerstand, z.&nbsp;B. Glühlampe<br />
<br />
Um den Widerstandswert zu messen schaltet man sie mit einem normalen Widerstand oder einer [[Konstantstromquelle]] in Reihe zu einem [[Spannungsteiler]] und misst den Spannungsabfall.<br />
Eine Beispielschaltung findet sich [http://www.mathar.com/msp_thermo1.html hier].<br />
<br />
Aufgrund des geringen Preises, der geradezu gigantischen Steilheit und der Verfügbarkeit mit hohen Widerstandswerten werden NTCs faktisch überall in der Heim- und Konsumgüterelektronik eingesetzt:<br />
An der Heizungssteuerung (auch im Außenfühler), im Elektronik-Thermostatventil, in der Wetterstation (innen und außen), in der Gefriertruhe, im Auto, im Schaltschrank und in sämtlichen China-Schaltungen zur Temperaturregelung.<br />
<br />
Vorteil:<br />
* billig (z.B. [https://www.reichelt.de/index.html?ACTION=446&LA=446&SEARCH=kty81 KTY81-x] bei Reichelt 0,52-0,75 &euro; 2018-01-03)<br />
* Ein Vorwiderstand genügt für die direkte Anbindung an einen A/D-Wandler eines jeden modernen Mikrocontrollers. Dadurch ratiometrische Messung, keine Referenzspannung erforderlich. (Auflösung wird durch Bits des A/D-Wandlers bestimmt.)<br />
<br />
Nachteil:<br />
* müssen für höhere Genauigkeiten abgeglichen werden<br />
* brauchen A/D-Wandler<br />
* sind nichtlinear<br />
<br />
Beispiele:<br />
* KTY10-5<br />
* KTY13-6<br />
* KTY81-121<br />
* KTY81-122<br />
* KTY81-210<br />
<br />
Links:<br />
* [http://www.sprut.de/electronic/temeratur/temp.htm Temperaturabhängige Stromquelle und NTC/PTC inclusive Linearisierung]<br />
*[http://www.umnicom.de/Elektronik/Mikrokontroller/Atmel/AtFan/AtFan.html#2.2.2 Berechnung des Linearisierungswiderstandes für gewünschten Temperaturbereich] der fällt sonst immer vom Himmel<br />
* [http://www.mikrocontroller.net/topic/208587#2065880 KTY 10-5 Formelprobleme]<br />
* [http://www.mikrocontroller.net/topic/225563 Codesammlung: Beispiel mit 0,5°C Auflösung]<br />
* [http://preis-ing.de/extras/alle-berechnungen-im-schnellzugriff/automatisches-erzeugen-einer-ntc-tabelle/ Automatisches Erzeugen von C-Code zur NTC Auswertung] Aus den NTC Parametern und den Anforderungen wird ein schneller und schlanker C-Code generiert.<br />
<br />
=== LMx35 ===<br />
<br />
Eine IC-Familie, die pro Kelvin Temperaturänderung ihre Ausgangsspannung um 10&nbsp;mV ändert. Die ICs gibt es in verschiedenen Genauigkeiten und Temperaturbereichen mit den Bezeichnungen LM135(A), LM235(A) und LM335(A). Der günstigste ist der LM335 mit einem Temperaturbereich von −40 … +100°C.<br />
In verschiedenen Bauformen erhältlich. Beispielschaltungen finden sich im [http://www.national.com/ds.cgi/LM/LM135.pdf Datenblatt] und [http://www.suessbrich.info/elek/elektherm1.html hier]<br />
<br />
Vorteile:<br />
* hat auch ohne Kalibrierung eine Genauigkeit von einem Grad (bei 25°C)<br />
* relativ billig (LM335 bei Reichelt ab 0,76&nbsp;€)<br />
<br />
Nachteile:<br />
* benötigt A/D-Wandler<br />
* bei längerer Anschlussleitung störanfällig<br />
<br />
Links:<br />
* [http://www.schramm-software.de/tipps/temperaturmessung/analogsensoren.htm Test-Schaltungen und -Code zur Auswertung mit ADC (AVR-Assembler)]<br />
<br />
=== LM334 ===<br />
<br />
Ein IC ähnlich dem LM335 mit dem Unterschied, dass der durch das IC fließende Strom proportional von der Temperatur abhängt. Mit einer einfachen Schaltung aus nur zwei Widerständen kann man dann den Strom in einer Weise wandeln, dass pro Kelvin eine Spannungsänderung von 10mV ausgegeben wird. Da die Strom-Spannungswandlung auf der Platine (und damit nahe am AD-Wandler) stattfindet und die Übertragung des Messwerts durch einen Strom stattfindet, sind Störungen durch Netzbrummen etc. viel geringer als beim LM335<br />
<br />
Vorteile:<br />
<!-- * hat auch ohne Kalibrierung eine Genauigkeit von einem Grad (bei 25°C) <br />
Laut Datenblatt +-3°C<br />
--><br />
* relativ billig ([http://www.reichelt.de/?ARTICLE=10468 Reichelt 0,54 &euro;])<br />
<br />
Nachteile:<br />
* benötigt A/D-Wandler<br />
* Bereich 0°C-70°C<br />
<br />
Ähnliche ICs:<br />
* AD592 (Ausgangsstrom 1µA pro Kelvin, absolute Temperatur) [http://www.reichelt.de/?ARTICLE=3825 Reichelt: 3,75 €], Conrad 174912 8,50 &euro;<br />
* B511N (geistern im Osten aus DDR-Beständen noch herum) wie AD592 aber deutlich mehr Parameterstreuung.<br />
<br />
=== SMT160-30 ===<br />
<br />
Ist ein Zwischending zwischen Digital und Analog. Sein Ausgangssignal ist ein digitales PWM-Signal, zu dessen Messung man am besten den Input-Capture-Eingang eines Mikrocontrollers verwendet. Man kann ihn also wie einen analogen Sensor nur indirekt auslesen, anstatt über einen AD-Wandler hier über einen Timer.<br />
<br />
Vorteile:<br />
* Digitales PWM-Signal ist unempfindlich gegen Störeinflüsse<br />
* gibt es in SO8, TO18, TO92 und <b>TO220</b>, gut befestigbar, z.B am Kühlkörper<br />
* linear<br />
* kein Abgleich nötig<br />
<br />
Nachteile (viele):<br />
* benötigt Timer<br />
* jittert extrem, genaue Messungen nur über Mittelung / Filterung möglich<br />
* nicht nur das PWM-Verhältnis, sondern auch die Frequenz ist temp-abhängig (1-4kHz)<br />
* teuer (Farnell 10,90&euro; +16%, Conrad 9,xx&euro; , www.hy-line.de ??).<br />
* TO92 Gehäuse ist günstiger, dafür weniger genau<br />
<br />
Links:<br />
* http://www.hy-line.de/co/sensor-tec/hersteller/smartec/smt-160-30/index.html<br />
<br />
=== Thermoelement ===<br />
<br />
Ein Thermoelement besteht im einfachsten Fall aus zwei ungleichen Metallendrähten, die an einem Punkt miteinander verbunden sind und bei dem die Verbindungsstelle einer anderen Temperatur ausgesetzt ist als die offenen Enden der Drähte. An den offenen Enden der Drähten entsteht eine Spannung (Thermospannung). Dieser Effekt wurde 1821 von Thomas Seebeck entdeckt ([http://de.wikipedia.org/wiki/Seebeck-Effekt Seebeck-Effekt] bei Wikipedia). Eine weitere Anwendung ist der thermoelektrische Generator ("Thermogenerator").<br />
<br />
Der herausragende Vorteil eines Thermoelements (meistens „Typ K“) ist seine obere Grenztemperatur von über 1000 °C.<br />
Das Thermoelement degradiert durch Kristallveränderungen in der Schweiß- oder Pressverbindung oder durch Aufschmelzen.<br />
Mit Thermoelementdraht (2 Drähte unterschiedlicher Metalle) lassen sich Sensoren flugs mit Aderendhülse + Zange<br />
oder kleinem Schweißgerät problemspezifisch und sehr klein in der Abmessung herstellen.<br />
<br />
Ein Thermoelement ist selbst bei einfachen Digitalmultimetern mit Temperaturmessbereich beigefügt.<br />
<br />
Da Thermoelemente, genauso wie Pt100/Pt1000-Widerstandssensoren, eine hohe Verstärkung und einen hochauflösenden A/D-Wandler benötigen, setzt man auch hier gern fertige Schaltkreise ein, die gleich die Kaltstellenkompensation mitbringen.<br />
<br />
* MCP3421 18bit ADC 15SPS, I2C, auch mit andere Auflösungen erhältlich, Thermoelement kann direkt angeschlossen werden! (Reichelt : 2,10€)<br />
<br />
Vorteil:<br />
* über einen sehr weiten Temperaturbereich einsetzbar<br />
<br />
Nachteil:<br />
* die sehr geringen Temperaturspannungen im Mikrovoltbereich benötigen eine sehr gute Auswertelektronik (guter Analogteil + AD-Wandler). (aber: beachte MCP3421)<br />
<br />
* Misst nur Temperaturdifferenz<br />
<br />
Links:<br />
<!-- Der Link wird von NI umgebogen zur Homepage. Recherche nach dem Autor brachte nix hervor :-(<br />
* [http://digital.ni.com/worldwide/germany.nsf/web/all/7A4F02BAEFEC22AC802567F6003E0D6E Temperaturmessung mit Thermoelementen] - Eine Einführung von David Potter (deutsche Überarbeitung: G.Sinkovic) (inkl. Erläuterung der Kaltstellenkompensation) --><br />
* [http://www.sensorwell.at/fileadmin/templates/images/data_sheets/temperatur_messtechnik.pdf Warum Thermoelemente Relativtemperaturen messen! oder Was ist eine Kaltstelle?] - Technische Information von www.sensorwell.at (PDF, ca. 600kB)<br />
<br />
=== P-N-Übergang ===<br />
<br />
Nicht direkt ein ausgemachter Sensor, aber jede normale Siliziumdiode kann als Temperatursensor herhalten.<br />
Gängig ist dazu die Verwendung des P-N-Übergangs zwischen Basis und Emitter eines NPN-Transistors.<br />
Das Verbinden von B und C bewirkt eine Stromverstärkung und damit eine geringere Abhängigkeit der Spannung vom Strom.<br />
Siehe nächster Abschnitt.<br />
<br />
=== Im Mikrocontroller eingebauter Sensor ===<br />
<br />
Mikrocontroller mit A/D-Wandler bieten häufig einen eingebauten Temperatursensor an,<br />
der mittels Eingangsmultiplexer auf den Wandler gegeben werden kann.<br />
Die häufigste Implementierung dürfte einen in Durchlassrichtung arbeitenden P-N-Übergang benutzen.<br />
An diesem beträgt der Temperaturkoeffizient -2 mV/K.<br />
Ziemlich klein aber dafür hinreichend linear.<br />
Im AVR-Mikrocontroller sind Auflösungen im Zehntelgradbereich illusorisch,<br />
schon ganze Grad sind an der Grenze des Machbaren.<br />
Die Hauptanwendung dieses Sensors ist wohl eher die Überwachung einer<br />
leistungsintensiven Schaltung, bspw. mit Leistungstransistoren, <br />
mit einer hellen LED (Fahrradscheinwerfer!) oder mit zu ladenden Batterien.<br />
<br />
=== indirekte Messung über die Temperaturabhängigkeit der Schallgeschwindigkeit ===<br />
<br />
Acoustic Thermometry Measures Temperature To 0.1 Degree<br />
http://www.linear.com/solutions/1558<br />
AN131 http://www.linear.com/docs/39793 (PDF momentan nicht verfügbar) --><br />
http://www.mikrocontroller.net/topic/307557#new<br />
<br />
== Digitale Temperatursensoren ==<br />
<br />
=== AM2301 / DHT21 ===<br />
<br />
Low Cost One-Wire Sensoren<br />
<br />
* Relativ großer Sensor <br />
* Stromversorgung: DC 3.3 - 5.2 V<br />
* Ausgangssignal: 1-Draht-Bus - digitales Signal (One wire)<br />
* Sensorelement: Polymer Feuchtigkeits-Kondensator<br />
* Messbereich: <br />
** Luftfeuchtigkeit: 0 - 100% relative Luftfeuchte<br />
** Temperatur: -40 °C bis +80°C<br />
* Genauigkeit:<br />
** Luftfeuchtigkeit: +/- 3%<br />
** Temperatur: +/- 0,5°C<br />
* Auflösung:<br />
** Feuchtigkeit: 0,1 % RH<br />
** Temperatur: 0,1 °C<br />
<br />
Kleinere Version als DHT11 / DHT22 mit Drahtanschlüssen.<br />
DHT11 :<br />
* Genauigkeit:<br />
** Luftfeuchtigkeit: +/- 5%<br />
** Temperatur: +/- 2°C<br />
* Kosten: ca. 2,00 € (Ali) bis 8,00 € (eBay Deutschland)<br />
<br />
=== DS1621 ===<br />
<br />
Der DS1621 ist Temperatursensor und A/D-Wandler in einem. Er gibt seine Daten per [[I²C]]-[[Bus]] aus. Ein Schaltplan für einen elektronischen Thermometer mit diesem IC findet sich [http://www.myplace.nu/avr/thermo/ hier].<br />
<br />
Eine Library für den AVR: https://sourceforge.net/projects/ds1621avr/<br />
<br />
Vorteile:<br />
* bereits kalibriert<br />
* kein A/D-Wandler nötig<br />
* da I²C ein Bus ist, kann man mehrere DS1621 und andere I²C-Bausteine zusammen anschließen und braucht dafür trotzdem nur zwei I/O-Ports.<br />
* Messbereich -55°C to +125°C <br />
* Genauigkeit +-0,5°C<br />
* Auflösung besser 0,01°C, wenn man die beiden Zählerregister (Count-Remain und Count-per-C) auswertet<br />
<br />
Nachteile:<br />
* teuer (Segor 5,80&euro;; RS 3,95&euro;; Conrad 5,22&euro;)<br />
* obwohl die meisten Register [[Speicher#NVRAM | nichtflüchtig]] sind, kann man ihn nicht als Stand-Alone-Thermostat einsetzen, da er erst nach einem Start-Conversion-Befehl zu messen beginnt.<br />
<br />
Nachfolger:<br />
* DS1631, DS1631A (Auto-Start-> Stand-Alone-Thermostat), DS1731<br />
* weitere Stand-Alone-Thermostaten: DS1821, DS1629<br />
<br />
=== LM75 ===<br />
<br />
Der LM75 ist so ähnlich wie der DS1621, allerdings nur in SMD erhältlich und nicht so genau. Er ist aber öfters mal auf PC-Mainboards zu finden, so dass man beim Schlachten eines solchen günstig an einen Temperatursensor kommen kann. Eine Beispiel Schaltplan mit einem ATmega8 findet man [http://www.ucblog.de/2010/09/mikrocontroller-thermometer-schaltplan/ hier]<br />
<br />
Vorteile:<br />
* bereits kalibriert<br />
* kein A/D-Wandler nötig<br />
* I²C-Bus Ausgang<br />
* billiger als DS1621 (Reichelt 1,45 &euro;; RS 3V: 3,75&euro;; 5V: 2,72&euro;)<br />
* Auflösung +-0,5°C<br />
<br />
Nachteile:<br />
* nur im SMD-Gehäuse erhältlich<br />
* relativ ungenau (+-2°C), kann man jedoch kalibrieren / kompensieren<br />
<br />
Kompatible Typen:<br />
* AD7415ART<br />
* DS7505S+<br />
<br />
=== LM76 ===<br />
<br />
Der LM76 ähnlich dem LM75, bietet aber eine 8-fach höhere Auflösung und eine Genauigkeit von 0.5 bzw. 1°C.<br />
<br />
Vorteile:<br />
* höhere Auflösung<br />
* höhere Genauigkeit<br />
<br />
Nachteil:<br />
* schwerer zu beschaffen<br />
<br />
=== TMP175 / TMP75 ===<br />
<br />
Ähnelt dem LM75 stark! Temperatursensor von Texas Instruments.<br />
<br />
EDIT 11.03.2024 Link funktioniert nicht mehr, Repo nicht mehr da.<br />
Links:<br />
<br />
[https://github.com/ManuelSchneid3r/RaspberryPi/blob/master/sensors/src/tmp.c Linux Kommandozeilen Tool für den Zugriff]<br />
<br />
=== DS18S20 / DS18B20 ===<br />
<br />
Der DS18S20 (Nachfolger des DS1820) und DS18B20 sind scheinbar Temperatursensoren und A/D-Wandler in einem. Wenn man genauer hinschaut, stellt man fest, dass es sich um direktwandelnde Sensoren handelt. Die Temperatur wird ohne Umweg über eine analoge Zwischengröße (Spannung oder Strom) in ein digitales Signal überführt.<br />
<br />
Die Datenkommunikation erfolgt über ein 1-Wire-Interface, wodurch man am [[Mikrocontroller]] mit nur einem einzigen I/O-Pin auskommen kann. Außerdem beherrschen sie die parasitäre Stromversorgung, d.h., man braucht für Daten und Stromversorgung zusammen nur zwei Leitungen.<br />
<br />
Beim DS18B20 sind Auflösungen von 9, 10, 11 und 12 Bits konfigurierbar. Je kleiner die Auflösung, desto kürzer ist die Messzeit. Der DS18S20 hat eine feste Auflösung von 12 Bits, wobei die unteren 4 Bits aufwändiger auszuwerten sind als beim DS18B20. Der DS18S20 ist als Ersatz für den DS1820 gedacht. Der Hersteller empfiehlt den DS18B20 für Neuentwicklungen.<br />
<br />
Anwendungshinweise bei Problemen<br />
* An jeden Sensor einen 100 nF Keramikkondensator platzieren.<br />
* Pull Up Widerstand am One Wire Bus kleiner machen, statt 4,7kΩ nur 2,2kΩ oder 1kΩ.<br />
* Einen Widerstand von 10-100 Ohm in '''Reihe''' zum Mikrocontrollerausgang schalten, damit die Flanken flacher werden und Reflektionen unterdrückt werden, was vor allem bei längeren Leitungen >1m zum Problem werden kann.<br />
* Dünne Anschlussleitungen verwenden, damit wenig Wärme durch die Anschlussleitungen übertragen wird. z.B: 0.2mm Kupferlackdraht verwenden, zumindest für die letzten 5 cm.<br />
<br />
Vorteile:<br />
* bereits kalibriert<br />
* Genauigkeit +-0,5°C<br />
* 1-Wire-Ausgang<br />
<br />
Preise:<br />
* 2020: Reichelt: 1,60&euro; / CSD: 1,59&euro; / Conrad 5,08&euro;<br />
* 2022-10-05 DS18S20: Reichelt 18,50&euro; / Pollin 12,95&euro; / Conrad: 28,99 &euro;<br />
* 2022-10-05 DS18B20: Reichelt 3,80&euro; / Pollin 4,49 ; 7,90&euro; / Conrad: 7,99 &euro;<br />
<br />
Links:<br />
* [https://www.ramser-elektro.at/1wire-sensor-zu-0-10v-konverter Zweikanaliger DS18B20 auf 0-10V Messumformer]<br />
* [http://www.avr-projekte.de/ds18b20.htm Ein oder mehrere DS18B20 DS18S20 über Romcode einlesen. AVR-Assembler]<br />
* [http://pic-projekte.de/wiki/index.php?title=Ansteuerung_eines_DS18S20 Ansteuern eines DS18S20 in C (PIC)]<br />
* [http://pdfserv.maxim-ic.com/en/ds/DS18S20.pdf Datenblatt DS18S20] <br />
* [http://pdfserv.maxim-ic.com/en/ds/DS18B20.pdf Datenblatt DS18B20]<br />
* [http://www.maxim-ic.com/app-notes/index.mvp/id/4377 Vergleich DS18B20 <-> DS18S20]<br />
* [http://www.mikrocontroller.net/topic/6505 Code zur Ansteuerung (ASM ATTiny12)]<br />
* [http://www.mikrocontroller.net/topic/14792 Code zur Ansteuerung (AVR-GCC)]<br />
* [https://www.mikrocontroller.net/topic/494918 Fehlervermeidung]<br />
* [http://gandalf.arubi.uni-kl.de/avr_projects/tempsensor/ Code zur Ansteuerung mit CRC-Prüfung (AVR-GCC)]<br />
* [http://www.schramm-software.de/tipps/temperaturmessung/digitalsensoren.htm Code zur Ansteuerung mit CRC-Prüfung (AVR-Assembler)]<br />
* [http://chaokhun.kmitl.ac.th/~kswichit/avrthermo/avrthermo.html LED-Thermometer mit AT90S2313 (C)]<br />
* [http://www.mikrocontroller.net/forum/read-4-248219.html Webserver zur Ansteuerung von bis zu 63 Bausteinen]<br />
* [http://www.teslabs.com/openplayer/docs/docs/other/ds18b20_pre1.pdf PDF Anleitung zur Beschaltung und Programmierung (C)]<br />
* [http://www.digitemp.com/building.shtml Anleitung Sensorfühleraufbau (DigiTemp)]<br />
* [http://www.mikrocontroller.net/topic/14792 Forumsbeitrag]: Onewire + DS18x20 Ansteuerung in C<br />
* [http://www.mikrocontroller.net/topic/232156 Forumsbeitrag]: Timing der parasitären Versorgung<br />
* [https://www.mikrocontroller.net/topic/387139#4602608 Projekt]: Onewire + DS18x20 Bibliothek<br />
<br />
=== DS1822 ===<br />
<br />
Ähnlich wie DS18S20, aber weniger genau (+-2°) und in großen Stückzahlen billiger. Wegen der geringeren Verbreitung kommt der Preisvorteil aber bei Einzelstücken nicht beim Kunden an. So kostet er bei Reichelt mit 3,50&euro; mehr als der DS18S20.<br />
<br />
=== DS1921 / DS1922 ===<br />
<br />
Sind wie die DS1821 1-wire-Sensoren mit zusätzlicher Logging-Funktion.<br />
Im iButton-Gehäuse befindet sich eine Lithium-Zelle, eine RTC, CMOS-RAM und der Temp-Sensor. Nach umfangreicher Programmierung startet der Button seine Mission (Aufzeichnung des Temperaturverlaufs).<br />
Gibt es auch mit zusätzlicher Feuchtemessung (DS1923).<br />
<br />
=== TSic ===<br />
<br />
Die TSic Sensoren werden baugleich von 2 Herstellern angeboten:<br />
* IST AG ([http://www.ist-ag.com/en/products-services/temperature-sensors Homepage])<br />
* B+B Thermo-Technik ([https://shop.bb-sensors.com/Temperaturmesstechnik/Temperatursensoren/Digitaler-TSic-Temperatursensor-TO92.html Homepage])<br />
<br />
Die TSic Sensoren ([https://shop.bb-sensors.com/out/media/Datasheet_Digital_Semiconductor_temperatur_sensor_TSIC.pdf Datenblatt]) geben ihre Temperaturmessdaten automatisch in einem festen Intervall aus. Daher muss der Host nur warten bis die nächsten Messdaten rausgeschickt werden. Die TSic Sensoren die es im freien Handel gibt, geben ihre Messdaten alle 100ms (10Hz) aus. <br />
Zur Übertragung wird das [http://www.ist-ag.com/eh/ist-ag/resource.nsf/imgref/Download_ZACWireAppNotes.pdf/$FILE/ZACWireAppNotes.pdf ZACwire] Protokoll benutzt. Es handelt sich um eine einfach zwei Byte Übertragung per Manchester-Code. Diese zwei Byte repräsentieren den digital gewandelten Temperaturwert. Im Gegensatz zu Sensoren wie den DS18xxx von Dallas muss dieser Wert aber erst auf einen dezimalen Wert umgerechnet werden. <br />
Die Sensoren kommen mit 3 Pins aus (VCC, GND, Dout).<br />
<br />
Vorteile:<br />
* Bereits kalibriert<br />
* Verschiedene Genauigkeiten lieferbar<br />
* Sehr einfaches Kommunikationsprotokoll<br />
* Geringer Stromverbrauch<br />
* Hochgenau: bis zu +/- 0.1°C (TSic 50x)<br />
<br />
Nachteil:<br />
* Recht teuer (Reichelt: 4,70&euro; für den TSic206)<br />
* Nur ein Sensor an einem I/O nutzbar (Kein Bussystem)<br />
<br />
Achtung! <br />
Die TSic Sensoren gibt es auch als Version mit analog Ausgang. Bei der Typenbezeichnung gibt die 3. Stelle an ob es sich um die analog- oder Digitalversion handelt (1 = analog, 6 = digital). <br />
Der TSic201 ist also analog, wärend der TSic206 ein digitaler ist.<br />
<br />
Links:<br />
<br />
* [http://www.mikrocontroller.net/topic/283615#3025721 ZACwire Protokoll im Logic Analyzer]<br />
* [http://www.mikrocontroller.net/topic/159774?goto=3157908#3157908 C-Code, (ohne Interrupt und ohne Timer) Sensor wird eingeschaltet->gelesen->ausgeschaltet]<br />
* [http://www.avr-projekte.de/zacwireasm.htm Zacwire Protokoll, AVR-Assembler]<br />
* [http://www.loetstelle.net/projekte2/tsic306/tsic306.php GCC AtMega8 Interruptgesteuerte Statemachine für TSIC206/306]<br />
* [http://www.mikrocontroller.net/topic/45573#347765 Ansatz zum Empfang der Daten]<br />
* [http://www.mikrocontroller.net/topic/225554# Beispiel mit Strobe ohne Interrupt]<br />
* [http://www.mikrocontroller.net/topic/82087 Diskussion mit Beispielcode (MSP430, AVR, PIC) blockierend]<br />
* [http://www.mikrocontroller.net/topic/144424#1367539 C++ Interrupt]<br />
* [http://www.mikrocontroller.net/topic/88847 noch mehr C, problematisch Interrupt]<br />
* [http://www.mikrocontroller.net/topic/151791#1426974 C für ATmega8]<br />
* [http://www.mikrocontroller.net/topic/159149#1510455 auch problematisch]<br />
* [http://www.mikrocontroller.net/topic/188462#1837622 fertiger Code zum Einlesen des Zacwire-Protokolls für PIC in ASM]<br />
* [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=55103 RN: Bascom]<br />
* [http://www.avr-projekte.de/tinyclock.htm TSIC206 Thermometer mit Uhr und Kalender. Komplette Bauanleitung mit ASM Quellcode für AT-Tiny2313]<br />
* [http://www.andeanelectronic.com/?Supporte___Arduino_con_TSic306%2CTSic506_y_TSic716 TSIC Routinen für Arduino von Andean Electronic aus Peru - Quelltext Dokumentation in Englisch]<br />
<br />
=== SHT3x ===<br />
<br />
Von [http://www.sensirion.com Sensirion] die aktuellen Versionen (2020) der Temperatur/Feuchte Sensoren<br />
<br />
Vorteile:<br />
* I2C<br />
* Tempertur: +-0.3°C (SHT30) - +-0.1°C (SHT35)<br />
* Temperaturbereich von -40 – +90°C<br />
* Feuchtigkeit mit einer Genauigkeit von +-3 (SHT30) - 1.5%RH (SHT35)<br />
<br />
Nachteile:<br />
* nur als SMD-Package, gibt aber diverse Breakout-Boards zum Beispiel bei Adafruit oder Tindie [https://www.tindie.com/products/closedcube/sht35-d-digital-humidity-temperature-sensor/]<br />
<br />
=== SHT1x/SHT7x (End of Life) ===<br />
<br />
Der SHT1x/SHT7x (SHT10, SHT11, SHT15, STH71, SHT75) sind kombinierte Temperatur- und Feuchtesensoren von [http://www.sensirion.com Sensirion]. Sie unterscheiden sich in Bauform und Genauigkeit.<br />
<br />
Vorteile:<br />
* digitale Schnittstelle mit einfacher [[I²C]]-''ähnlicher'' Ansteuerung<br />
* keine Kalibrierung notwendig<br />
* Beispielcode (C, MC51) auf der Sensirion-Seite verfügbar (relativ leicht portierbar)<br />
* interne Heizelemente (Funktionsprüfung, "raue" Umgebung)<br />
* Spannungsmonitor ("Battery fail")<br />
* sehr hohe Genauigkeit<br />
<br />
Nachteile:<br />
* kann nicht am [[I²C]] Bus betrieben werden, theoretisch gleiche Clockleitung möglich, fixe Adresse<br />
* relativ teuer (Farnell 18,60&euro;)(SHT11 bei CSD 14€)<br />
<br />
[http://www.sensirion.com/de/produkte/feuchte-und-temperatur/ Übersicht] der Temperatur- und Feuchtigkeitssensoren von Sensirion.<br />
<br />
=== SHT21 (End of Life) ===<br />
<br />
[http://www.sensirion.com Sensirion] bietet auch den SHT21 Feuchtigkeits- und Temperatursensor an, welcher wesentlich genauer ist.<br />
<br />
Vorteile:<br />
* I2C digital, PWM and SDM/analog Volt Ausgabe<br />
* Maximal 5 Messungen/s @ 14bit<br />
* Temperaturbereich von -40 – +125°C<br />
* Feuchtigkeit mit einer Genauigkeit von +-2%RH<br />
* Günstig (3-4€ Farnell/RS 2014)<br />
<br />
Nachteile:<br />
* nur als SMD-Package<br />
<br />
Application Notes und Datenblätter findet man [http://www.sensirion.com/en/products/humidity-temperature/humidity-sensor-sht2x/ hier].<br />
<br />
=== ADT7310 / ADT7xxx-Familie von AD ===<br />
<br />
Der [http://www.analog.com/en/sensors/digital-temperature-sensors/adt7310/products/product.html ADT7310] von [http://www.analog.com/ Analog Devices] besitzt eine Auflösung von 16 Bit und eine Genauigkeit von ±0.5°C im Bereich von −40°C bis +105°C.<br />
<br />
Vorteile:<br />
* Ansteuerung per [[SPI]] ADT73xx oder [[I2C]] ADT74xx<br />
* keine Kalibrierung notwendig<br />
* hohe [[Auflösung und Genauigkeit]]: 16 Bit<br />
** ADT7x02 2,00°<br />
** ADT7x01 1,00°<br />
** ADT7x10 0,40 / 0,50°<br />
** ADT7x20 0,20 / 0,25°<br />
* auch für automotive / als Die lieferbar<br />
* programmierbarer [[Interrupt]]ausgang für Unter- und Übertemperatur<br />
* relativ günstig (ca. 3-8€ bei Digi-Key, Stand 12/2011)<br />
<br />
Nachteile:<br />
* TBD<br />
<br />
NB: ONsemi hat auch Temperatursensoren mit der Bezeichnung ADT7xxx, verwendet aber ein anderes Namensschema<br />
<br />
=== TSYS01 / G-NICO-018 von Measurement Specialties Inc. ===<br />
* sehr hohe [[Auflösung und Genauigkeit]]: 0,10° @ -5°C … +50°C 16/24 Bit<br />
* Gehäuse 16-VQFN Exposed Pad<br />
* SPI / I2C über Pin auswählbar<br />
* Preis: 8,60 (4,40 @1k) bei Digikey<br />
kleiner Nachteil: der Sensor liefert den ADC-Wert und die Kompensationskonstanten (5 Polynom-Koeffizienten), mit denen im µC die Temperatur berechnet werden muss.<br />
<br />
=== SE95 ===<br />
<br />
Der [http://www.nxp.com/documents/data_sheet/SE95.pdf SE95] von NXP hat 13 Bit Auflösung, Genauigkeit ±2°C im Messbereich von -55°C bis +125°C, I²C, Gehäuse SO8 und TSSOP8. Einzelstück-Preis bei Segor 1,50€ (2012/I)<br />
<br />
=== Bosch Sensortec BMP085 / BMP180 ===<br />
Die BMP085 (bzw. der verbesserte, aber Pin- und Software-komapatible Nachfolger BMP180) sind eigentlich Luftdrucksensoren, die jedoch auch einen Temperatursensor mitbringen. Der Anschluss erfolgt über I2C.<br />
<br />
Vorteile:<br />
* Wenig Stromverbrauch (5µA bei 1 Messung/s)<br />
* Liefern Luftdruck gleich mit<br />
* Absolute Genauigkeit (+-1°C typ. über kompletten Temperaturbereich). Relative Genauigkeit ist im Datenblatt nicht spezifiziert, gemessen gegen einen SHT11 ca. +-0.1°C. <br />
* Auflösung: 0.1°C mit Herstellercode, mehr ist möglich (16Bit)<br />
* Fertige Platinen für wenig Geld verfügbar (ca. 1,70€ inkl. Versand aus China)<br />
<br />
Nachteile:<br />
* Sehr aufwändige Linearisierung (Kalibrationskoeffizienten sind im Sensor gespeichert, müssen aber vom Host-µC verrechnet werden. Code ist im Datenblatt)<br />
* Nur als SMD<br />
* Bei Reichelt und Conrad nicht erhältlich. <br />
<br />
<br />
Preis: Ebay 1,70€ (mit Platine, China), Aliexpress 1,10€ (nackter Chip, China, mind. 10 Stück sonst auch ca. 1,70€)<br />
<br />
=== Bosch Sensortec BME280 / BME680 ===<br />
* I2C-Sensor für Temperatur, Luftfeuchtigkeit, Luftdruck (BME680 = BME280 + Luftgüte)<br />
<br />
<br />
Vorteile:<br />
* Breakout-Board BME280 Aliexpress ~2,20€, BME680 Watterott 15,95€<br />
* Bosch-eigene Bibliotheken für gängige Mikrocontroller, Android und RaspberryPi<br />
* Arduino-Bibliotheken von Adafruit, Sparkfun und Watterott<br />
* Minimaler Platzbedarf<br />
* SMT ermöglicht doppelseite Platine mit BME280/BME680 auf Frontseite und restlicher Elektronik auf Rückseite<br />
<br />
Nachteile<br />
* Ball-Grid-Array Reflow, manuelles Löten nur mit Breakout-Board oder Vias möglich<br />
<br />
<br />
Bibliotheken/Datenblätter/Herstellerinformation:<br />
* BME280: https://www.bosch-sensortec.com/bst/products/all_products/bme280<br />
* BME680: https://www.bosch-sensortec.com/bst/products/all_products/bme680<br />
<br />
<br />
Projekte/Code<br />
* [ASM] [https://www.mikrocontroller.net/topic/506743#6473604 BME280 mit OLED Display am ATmega808]<br />
* [ASM] [https://www.mikrocontroller.net/topic/506743#6495985 BME280 mit OLED Display am ATtiny85]<br />
<br />
<br />
Preis: BME280 / BME680 Reichelt 5,20€ / 9,45€, Conrad 8,33€ / xxx, Aliexpress ~2,50€ / ~15,-€<br />
<br />
=== HDC1080 ===<br />
Der HDC1080 von Texas Instruments kombiniert einen digitalen Luftfeuchtesensor mit Temperaturmessung. Der Anschluss erfolgt über IC2.<br />
<br />
Merkmale:<br />
* geringe Stromaufnahme (1,3 µA bei 1 Messung/s)<br />
* gleichzeitige Luftfeuchtemessung möglich<br />
* Spannungsversorgung: 2,7 bis 5,5 V<br />
* Genauigkeit: +/-0,2 °C typ. (im Temperaturbereich zwischen 5 bis 60 °C)<br />
* Auflösung Temperatur: 11/14 bit wählbar<br />
* Maximale Dauer einer Messung: 6,5 ms<br />
* eingebautes Heizelement (gegen Feuchtigkeitskondensation, per Konfigurationsregister einschaltbar)<br />
* Herstellerseitig kalibriert<br />
* einfache Umrechnung<br />
* Gehäuse: SMD 6-Pin PWSON (3x3 mm)<br />
<br />
Erhältich als Pmod (''PmodHygro'' von Digilentic) und in Breakoutboards zahlreicher anderer Hersteller.<br />
<br />
<br />
=== ScioSense ENS21x ===<br />
<br />
Vom deutsch-holländischen Hersteller [http://www.sciosense.com ScioSense] werden mit der [https://www.sciosense.com/ens21x-family-of-high-performance-digital-temperature-and-humidity-sensors/ ENS21x Familie] kombinierte hochpräzise Feuchte- und Temperatursensoren mit I²C Interface angeboten. Dabei gibt es je nach Anforderung unterschiedliche Genauigkeitsklassen, die sich im Produktname klassifizieren<br />
<br />
<br />
Merkmale:<br />
<br />
* Stromaufnahme für RH und T Messung bei ~6.6µA @ 1Hz<br />
* Spannungsbereich 1.7V....4.7V<br />
* Temperaturbereich -40..125°C, relative Feuchte 0..100% rH<br />
* Genauigkeit Temperatur +/- 0.1°C, 0.8%RH (ENS215) ...2.0%RH (ENS210)<br />
* kontinuierliche Messung Feuchte und Temperatur möglich; Sensoren sind fertig kalibriert<br />
* Ausgabedaten sind fertig aufbereitet, keine externe Kompensation o.ä. nötig<br />
* QFN4 package (2.0 x 2.0 x 0.75mm3)<br />
* GitHub/Arduino Integration mit Beispielcode<br />
<br />
Erhältlich bei Mouse und Digikey, ebenso EVKit<br />
<br />
<br />
Nenben den Temperatur/Feuchtesensoren sind auch hochpräzise barometrische Drucksensensoren ([https://www.sciosense.com/ens220-barometric-pressure-and-temperature-sensor/ ENS220]) sowie MOX-Gassensoren für Luftqualitätsbestimmung ([https://www.sciosense.com/ens16x-digital-metal-oxide-multi-gas-sensor-family/ ENS16x]) erhältlich, sowie weiter Kombinationen mit Partikel oder Flowsensoren.<br />
<br />
<br />
== Preisübersicht ==<br />
<br />
{| class="wikitable"<br />
|+ '''Preisübersicht 11/2012 teilw. Update 10/2024'''<br />
|-<br />
! Bauteil || Segor || RS-Components || Conrad || Farnell || Reichelt || DigiKey || Mouser<br />
|-<br />
| AD592 || 21,40 || 5,74 || 6,43 || 5,90 || 3,95 || 4,61<br />
|-<br />
| ADT7310 || - || - || - || 4,56 || - || 3,02<br />
|-<br />
| ADT7410 || - || 3,35 || - || 2,71 || - || 3,02<br />
|-<br />
| DS1621 || 7,60 || 5,29 || 5,08 || 5,65 || - || 4,54<br />
|-<br />
| DS1629 || 8,70 || 8,68 || - || 5,00 || 6,50 || 7,65<br />
|-<br />
| DS1631 || 8,00 || 2,91 || - || 3,11 || - || 3,94<br />
|-<br />
| DS1731 || - || - || - || 9,79 || - || 3,81<br />
|-<br />
| DS1821 || 5,90 || 5,27 || 6,27 || - || - || 5,05<br />
|-<br />
| DS18B20 || 2,50 || 3,06 || - || 3,26 || 3,20 || 3,93<br />
|-<br />
| DS1921 || - || 26,15 || - || - || - || 21,13<br />
|-<br />
| DS1922 || - || 62,00 || - || - || - || 43,11<br />
|-<br />
| DS1923 || - || 97,96 || - || - || - || 80,30<br />
|-<br />
| KTY81/121 || - || - || - || 0,79 || 0,59 || 0,85<br />
|-<br />
| LM75 || 1,50 || 0,68 || 3,64 || 0,81 || 1,45 || 0,82<br />
|-<br />
| LM76 || - || 2,83 || - || 3,02 || - || 2,39<br />
|-<br />
| LM135 || 10,10 || 10,28 || - || 8,95 || 7,95 || 10,26<br />
|-<br />
| LM235 || - || - || - || 1,80 || 1,40 || 1,26<br />
|-<br />
| LM334 || 0,90 || 0,72 || 1,67 || 1,01 || 0,49 || 0,74<br />
|-<br />
| LM335 || 1,30 || 0,56 || 1,92 || 0,55 || 0,71 || 0,80<br />
|-<br />
| PT100 || 3,80 || 3,99 || 4,00 || 9,79 || 4,27 || 0,68<br />
|-<br />
| SE95 || 1,50 || 0,63 || - || 1,45 || - || 1,00<br />
|-<br />
| SHT11 || 26,00 || 24,38 || 33,20 || 25,65 || - || 36,76<br />
|-<br />
| SHT15 || - || 27,69 || 36,30 || 28,72 || - || -<br />
|-<br />
| SHT21 || 29,50 || 18,10 || - || 21,16 || - || -<br />
|-<br />
| SHT71 || 25,40 || 29,06 || 36,89 || 30,88 || - || -<br />
|-<br />
| SHT75 || - || 33,77 || 42,48 || 35,52 || - || -<br />
|-<br />
| SMT160-30 || - || 9,28 || 8,14 || 12,38 || - || -<br />
|-<br />
| TMP75 || - || 0,80 || - || 0,85 || - || 1,37<br />
|-<br />
| TSic206 || - || - || 5,84 || - || 4,20 || -<br />
|-<br />
| ENS210 || - || - || - || - || - || 2,55 || 2,74<br />
|}<br />
<br />
== Siehe auch ==<br />
<br />
* [https://www.mikrocontroller.net/forum/mikrocontroller-elektronik?filter=temperatur* Beiträge im Forum]<br />
* [[Feuchtesensor]]<br />
<br />
[[Kategorie:Sensorik]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR-GCC-Tutorial&diff=107266AVR-GCC-Tutorial2025-01-28T08:58:41Z<p>Heha: Von-Neumannisierung umsortiert</p>
<hr />
<div>Dieses Tutorial soll den Einstieg in die Programmierung von Atmel [[AVR]]-Mikrocontrollern in der Programmiersprache [[C]] mit dem freien C-Compiler [[avr-gcc]] aus der [http://gcc.gnu.org/ GNU Compiler Collection] (GCC) erleichtern.<br />
<br />
Vorausgesetzt werden Grundkenntnisse der Programmiersprache C. Diese Kenntnisse kann man sich online erarbeiten, z. B. mit dem [http://www.schellong.de/c.htm C Tutorial von Helmut Schellong] ([[C|Liste von C-Tutorials]]). Nicht erforderlich sind Vorkenntnisse in der Programmierung von Mikrocontrollern.<br />
<br />
= Vorwort =<br />
<br />
In diesem Text wird häufig auf die Standardbibliothek avr-libc verwiesen, für die es eine [http://www.nongnu.org/avr-libc/user-manual/index.html Online-Dokumentation] gibt, in der sich auch viele nützliche Informationen zum Compiler und zur Programmierung von AVR-Controllern finden. Beim Paket [[WinAVR]] gehört die avr-libc Dokumentation zum Lieferumfang und wird mitinstalliert.<br />
<br />
Der Compiler und die Standardbibliothek avr-libc werden ständig weiterentwickelt. Einige Unterschiede, die sich im Verlauf der Entwicklung ergeben haben, werden hier und im Artikel [[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen]] zwar angesprochen, Anfängern und Umsteigern sei jedoch empfohlen, eine aktuelle Versionen zu nutzen.<br />
<br />
Das ursprüngliche Tutorial stammt von Christian Schifferle, viele neue Abschnitte und aktuelle Anpassungen von Martin Thomas.<br />
<br />
Dieses Tutorial ist in [[Media:AVR-GCC-Tutorial.pdf|PDF-Form]] erhältlich (zur Zeit nur eine sehr veraltete Version).<br />
<br />
== Weiterführende Kapitel ==<br />
<br />
Um dieses riesige Tutorial etwas überschaubarer zu gestalten, wurden einige Kapitel ausgelagert, die nicht unmittelbar mit den Grundlagen von avr-gcc in Verbindung stehen. All diese Seiten gehören zur [[:Kategorie:avr-gcc Tutorial]].<br />
<br />
;UART: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der UART|Der UART]]''<br />
<br />
;ADC: → Hauptartikel: ''[[AVR-GCC-Tutorial/Analoge Ein- und Ausgabe|Analoge Ein- und Ausgabe (ADC)]]''<br />
<br />
;Timer: → Hauptartikel: ''[[AVR-GCC-Tutorial/Die Timer und Zähler des AVR|Die Timer und Zähler des AVR]]''<br />
<br />
;LCD: → Hauptartikel: ''[[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Ansteuerung]]''<br />
<br />
;Watchdog: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der Watchdog|Der Watchdog]]''<br />
<br />
;Assembler: → Hauptartikel: ''[[AVR-GCC-Tutorial/Assembler und Inline-Assembler|Assembler und Inline-Assembler]]''<br />
<br />
;alte Quellen anpassen: → Hauptartikel: ''[[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen anpassen]]''<br />
<br />
;Makefiles: → Hauptartikel: ''[[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]]'' sowie als Alternative für sehr kleine Projekte → Hauptartikel: ''[[C ohne Makefile]]''<br />
<br />
= Benötigte Werkzeuge =<br />
<br />
Um eigene Programme für AVRs mittels einer AVR-Toolchain zu erstellen wird folgende Hard- und Software benötigt:<br />
<br />
* Eine AVR-Toolchain bestehend aus avr-gcc, den avr-Binutils (Assembler, Linker, etc) und einer Standard-C Bibliothek. Üblich ist die AVR-LibC, die auch quasi in allen avr-gcc Distributionen enthalten ist.<br />
<br />
Hardware wird keine benötigt – bis auf einen PC natürlich, auf dem der Compiler ablaufen kann. Selbst ohne AVR-Hardware kann man also bereits C-Programme für AVRs schreiben, compiliern und sich das Look-and-Feel von avr-gcc sowie von IDEs wie [[Atmel Studio]], Eclipse oder leichtgewichtigeren Entwicklungsumbgebungen anschauen. Selbst das Debuggen und Simulieren ist mithilfe entsprechender Tools wie Debugger und Simulator in gewissen Grenzen möglich.<br />
<br />
Um Programme für AVRs mittels einer AVR-Toolchain zu testen, wird folgende Hard- und Software benötigt:<br />
<br />
* Platine oder Versuchsaufbau für die Aufnahme eines AVR-Controllers, der vom avr-gcc Compiler unterstützt wird.<ref>Für eine Liste der unterstützten COntroller siehe die Dokumentation des Compilers oder [http://www.nongnu.org/avr-libc/user-manual/index.html#supported_devices AVR-Libc: Supported Devices].</ref> Dieses Testboard kann durchaus auch selbst gelötet oder auf einem Steckbrett aufgebaut werden. Einige Registerbeschreibungen dieses Tutorials beziehen sich auf den inzwischen veralteten AT90S2313. Der weitaus größte Teil des Textes ist aber für alle Controller der AVR-Familie gültig. <br />
<br />
:Brauchbare Testplattformen sind auch das [[STK500]] und der [[AVR Butterfly]] von Atmel. Weitere Infos findet man in den Artikeln [[AVR#Starterkits|AVR Starterkits]] und [[AVR-Tutorial: Equipment]].<br />
<br />
* Programmiersoftware und -[[AVR In System Programmer |hardware]] z. B. PonyProg (siehe auch: [[Pony-Prog Tutorial]]) oder [[AVRDUDE]] mit [[STK200]]-Dongle oder die von Atmel verfügbare Hard- und Software ([[STK500]], Atmel AVRISP, [[AVR-Studio]]).<br />
<br />
* Nicht unbedingt erforderlich, aber zur Simulation und zum Debuggen unter MS-Windows recht nützlich: [[AVR-Studio]].<br />
<br />
* Wer unter Windows und Linux gleichermassen entwickeln will, der sollte sich die [http://www.eclipse.org/ IDE Eclipse for C/C++ Developers] und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] ansehen. Beide sind unter Windows und Linux einfach zu installieren, siehe auch [[AVR Eclipse]]. Ebenfalls unter Linux und Windows verfügbar ist die Entwicklungsumgebung [http://www.codeblocks.org/ Code::Blocks]<ref>Aktuelle, stabile Versionen sind als Nightly Builds regelmäßig im [http://forums.codeblocks.org/ Forum] verfügbar.</ref>. Innerhalb dieser Entwicklungsumgebung können ohne die Installation zusätzlicher Plugins "AVR-Projekte" angelegt werden. Für Linux gibt es auch noch das [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=25220 KontrollerLab].<br />
<br />
= Was tun, wenn's nicht klappt? =<br />
<br />
* Herausfinden, ob es tatsächlich ein avr(-gcc) spezifisches Problem ist oder nur die eigenen C-Kenntnisse einer Auffrischung bedürfen. Allgemeine C-Fragen kann man eventuell "beim freundlichen Programmierer zwei Büro-, Zimmer- oder Haustüren weiter" loswerden. Ansonsten: [[C]]-Buch (gibt's auch "gratis" online) lesen.<br />
<br />
* Die [[AVR Checkliste]] durcharbeiten.<br />
<br />
* Die '''[http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc]''' lesen, vor allem (aber nicht nur) den Abschnitt Related Pages/'''Frequently Asked Questions''' = Oft gestellte Fragen (und Antworten dazu). Z.Zt leider nur in englischer Sprache verfügbar.<br />
<br />
* Den Artikel [[AVR-GCC]] in diesem Wiki lesen.<br />
<br />
* Das [http://www.mikrocontroller.net/forum/gcc GCC-Forum auf www.mikrocontroller.net] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das avr-gcc-Forum bei [http://www.avrfreaks.net AVRfreaks] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das [http://lists.gnu.org/archive/html/avr-gcc-list/ Archiv der avr-gcc Mailing-Liste] nach vergleichbaren Problemen absuchen.<br />
<br />
* Nach Beispielcode suchen. Vor allem im ''Projects''-Bereich von [http://www.avrfreaks.net AVRfreaks] (anmelden).<br />
<br />
* Google oder yahoo befragen schadet nie.<br />
<br />
* Bei Problemen mit der Ansteuerung interner AVR-Funktionen mit C-Code: das Datenblatt des Controllers lesen (ganz und am Besten zweimal). Datenblätter sind auf den [http://www.atmel.com Atmel Webseiten] als pdf-Dateien verfügbar. Das komplette Datenblatt (complete) und nicht die Kurzfassung (summary) verwenden.<br />
<br />
* Die Beispielprogramme im [[AVR-Tutorial]] sind zwar in AVR-Assembler verfasst, Erläuterungen und Vorgehensweisen sind aber auch auf C-Programme übertragbar.<br />
<br />
* Einen Beitrag in eines der Foren oder eine Mail an die Mailing-Liste schreiben. Dabei möglichst viel Information geben: Controller, Compilerversion, genutzte Bibliotheken, Ausschnitte aus dem Quellcode oder besser ein [http://www.mikrocontroller.net/topic/72767#598986 Testprojekt] mit allen notwendigen Dateien, um das Problem nachzuvollziehen, sowie genaue Fehlermeldungen bzw. Beschreibung des Fehlverhaltens. Bei Ansteuerung externer Geräte die Beschaltung beschreiben oder skizzieren (z. B. mit [http://www.tech-chat.de/ Andys ASCII Circuit]). Siehe dazu auch: '''[http://www.tty1.net/smart-questions_de.html "Wie man Fragen richtig stellt"]'''.<br />
<br />
= Erzeugen von Maschinencode =<br />
<br />
Aus dem C-Quellcode erzeugt der avr-gcc Compiler (zusammen mit Hilfsprogrammen wie z.&nbsp;B. Präprozessor, Assembler und Linker) Maschinencode für den AVR-Controller. Üblicherweise liegt dieser Code dann im Intel Hex-Format vor ("Hex-Datei"). Die Programmiersoftware (z.&nbsp;B. [[AVRDUDE]], PonyProg oder AVRStudio/STK500-plugin) liest diese Datei ein und überträgt die enthaltene Information (den Maschinencode) in den Speicher des Controllers. Im Prinzip sind also "nur" der avr-gcc-Compiler (und wenige Hilfsprogramme) mit den "richtigen" Optionen aufzurufen, um aus C-Code eine "Hex-Datei" zu erzeugen. Grundsätzlich stehen dazu drei verschiedene Ansätze zur Verfügung:<br />
<br />
* Die Verwendung einer integrierten Entwicklungsumgebung (IDE = '''I'''ntegrated '''D'''evelopment '''E'''nvironment), bei der alle Einstellungen z.&nbsp;B. in Dialogboxen durchgeführt werden können. Unter Anderem kann AVRStudio ab Version 4.12 (kostenlos auf [http://www.atmel.com/ atmel.com]) zusammen mit WinAVR als integrierte Entwicklungsumgebung für den Compiler avr-gcc genutzt werden (dazu müssen AVRStudio und WinAVR auf dem Rechner installiert sein). Weitere IDEs (ohne Anspruch auf Vollständigkeit): [http://www.eclipse.org/ Eclipse for C/C++ Developers] (d.h. inkl. CDT) und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] (für diverse Plattformen, u.a. Linux und MS Windows, IDE und Plugin kostenlos), [http://sourceforge.net/projects/kontrollerlab KontrollerLab] (Linux/KDE, kostenlos). [http://www.atmanecl.com/EnglishSite/SoftwareEnglish.htm AtmanAvr] (MS Windows, relativ günstig), KamAVR (MS-Windows, kostenlos, wird augenscheinlich nicht mehr weiterentwickelt), [http://www.amctools.com/vmlab.htm VMLab] (MS Windows, ab Version 3.12 ebenfalls kostenlos). Integrierte Entwicklungsumgebungen unterscheiden sich stark in Ihrer Bedienung und stehen auch nicht für alle Plattformen zur Verfügung, auf denen der Compiler ausführbar ist (z.&nbsp;B. AVRStudio nur für MS-Windows). Zur Anwendung des avr-gcc Compilers mit IDEs sei hier auf deren Dokumentation verwiesen. <br />
<br />
* Die Nutzung des Programms make mit passenden Makefiles. In den folgenden Abschnitten wird die Generierung von Maschinencode für einen AVR ("hex-Datei") aus C-Quellcode ("c-Dateien") anhand von "make" und den "Makefiles" näher erläutert. Viele der darin beschriebenen Optionen findet man auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio (AVRStudio generiert ein makefile in einem Unterverzeichnis des Projektverzeichnisses). <br />
<br />
* Das Generieren des Programms ohne IDE und ohne Makefile. In diesem Fall muss die Quellcodedatei durch eine vorgefertigte Kommandofolge an den Compiler übergeben werden. Der Artikel [[C ohne Makefile]] zeigt, wie das funktioniert. Diese Vorgehensweise empfiehlt sich jedoch nur für kleine Programme, die nicht auf verschiedene Quellcodedateien verteilt sind.<br />
<br />
Beim Wechsel vom makefile-Ansatz nach WinAVR-Vorlage zu AVRStudio ist darauf zu achten, dass AVRStudio (Stand: AVRStudio Version 4.13) bei einem neuen Projekt die Optimierungsoption (vgl. Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|AVR-GCC-Tutorial/Exkurs: Makefiles]], typisch: -Os) nicht einstellt und die mathematische Bibliothek der avr-libc (libm.a, Linker-Option -lm) nicht einbindet. (Hinweis: Bei Version 4.16 wird beides bereits gesetzt). Beides ist Standard bei Verwendung von makefiles nach WinAVR-Vorlage und sollte daher auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio "manuell" eingestellt werden, um auch mit AVRStudio kompakten Code zu erzeugen.<br />
<br />
= Einführungsbeispiel =<br />
<br />
Zum Einstieg ein kleines Beispiel, an dem die Nutzung des Compilers und der Hilfsprogramme (der sogenannten ''Toolchain'') demonstriert wird. Detaillierte Erläuterungen folgen in den weiteren Abschnitten dieses Tutorials.<br />
<br />
Das Programm soll auf einem AVR Mikrocontroller einige Ausgänge ein- und andere ausschalten. Das Beispiel ist für einen ATmega16 programmiert ([http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf Datenblatt]), kann aber sinngemäß für andere Controller der AVR-Familie modifiziert werden. <br />
<br />
Ein kurzes Wort zur Hardware: Bei diesem Programm werden alle Pins von PORTB auf Ausgang gesetzt, und einige davon werden auf HIGH andere auf LOW gesetzt. Das kann je nach angeschlossener Hardware an diesen Pins kritisch sein. Am ungefährlichsten ist es, wenn nichts an den Pins angeschlossen ist und man die Funktion des Programmes durch eine Spannungsmessung mit einem Multimeter kontrolliert. Die Spannung wird dabei zwischen GND-Pin und den einzelnen Pins von PORTB gemessen.<br />
<br />
Zunächst der Quellcode der Anwendung, der in einer Text-Datei mit dem Namen ''main.c'' abgespeichert wird.<br />
<br />
<syntaxhighlight lang="c"><br />
/* Alle Zeichen zwischen Schrägstrich-Stern <br />
und Stern-Schrägstrich sind Kommentare */<br />
<br />
// Zeilenkommentare sind ebenfalls möglich<br />
// alle auf die beiden Schrägstriche folgenden<br />
// Zeichen einer Zeile sind Kommentar<br />
<br />
#include <avr/io.h> // (1)<br />
<br />
int main (void) { // (2)<br />
<br />
DDRB = 0xFF; // (3)<br />
PORTB = 0x03; // (4)<br />
<br />
while(1) { // (5)<br />
/* "leere" Schleife*/ // (6)<br />
} // (7)<br />
<br />
/* wird nie erreicht */<br />
return 0; // (8)<br />
}<br />
</syntaxhighlight><br />
<br />
# In dieser Zeile wird eine sogenannte Header-Datei eingebunden. In <code>avr/io.h</code> sind die Registernamen definiert, die im späteren Verlauf genutzt werden. Auch unter Windows wird ein&nbsp;<code>/</code> zur Kennzeichnung von Unterverzeichnissen in Include-Dateinamen verwendet und kein&nbsp;<code>\</code>.<br />
# Hier beginnt das eigentliche Programm. Jedes C-Programm beginnt mit den Anweisungen in der Funktion <code>main</code>.<br />
# Die Anschlüsse eines AVR (Pins) werden zu Blöcken zusammengefasst, einen solchen Block bezeichnet man als Port. Beim ATmega16 hat jeder Port 8 Anschlüsse, bei kleineren AVRs können einem Port auch weniger als 8 Anschlüsse zugeordnet sein. Da per Definition (Datenblatt) alle gesetzten Bits in einem Datenrichtungsregister den entsprechenden Anschluss auf Ausgang schalten, werden mit DDRB=0xff alle Anschlüsse des Ports B als Ausgänge eingestellt.<br />
# Die den ersten beiden Bits des Ports zugeordneten Anschlüsse (PB0 und PB1) werden 1, alle anderen Anschlüsse des Ports B (PB2-PB7) zu 0. Aktivierte Ausgänge (logisch 1 oder "high") liegen auf Betriebsspannung (VCC, meist 5 Volt), nicht aktivierte Ausgänge führen 0 Volt (GND, Bezugspotential). Es ist sinnvoll, sich möglichst frühzeitig eine alternative Schreibweise beizubringen, die wegen der leichteren Überprüfbarkeit und Portierbarkeit oft im weiteren Tutorial und in Forenbeiträgen benutzt wird. Die Zuordnung sieht in diesem Fall so aus, Näheres dazu im Artikel [[Bitmanipulation]]:<syntaxhighlight lang="c">PORTB = (1<<PB1) | (1<<PB0);</syntaxhighlight><br />
# ist der Beginn der sogenannte ''Hauptschleife'' (main-loop). Dies ist eine Endlosschleife, welche kontinuierlich wiederkehrende Befehle enthält.<br />
# In diesem Beispiel ist die Hauptschleife leer. Der Controller durchläuft die Schleife immer wieder, ohne dass etwas passiert. Eine solche Schleife ist notwendig, da es auf dem Controller kein Betriebssystem gibt, das nach Beendigung des Programmes die Kontrolle übernehmen könnte. Ohne diese Schleife kehrt das Programm aus <code>main</code> zurück, alle Interrupts werden deaktiviert und eine Endlosschleife betreten.<br />
# Ende der Hauptschleife und Sprung zur passenden, öffnenden Klammer, also zu 5.<br />
# ist das Programmende. Die Zeile ist nur aus Gründen der C-Kompatibilität enthalten: <syntaxhighlight lang="c">int main(void)</syntaxhighlight> besagt, dass die Funktion einen int-Wert zurückgibt. Die Anweisung wird aber nicht erreicht, da das Programm die Hauptschleife nie verlässt.<br />
<br />
Um diesen Quellcode in ein lauffähiges Programm zu übersetzen, wird hier ein Makefile genutzt. Das verwendete Makefile findet sich auf der Seite [[Beispiel Makefile]] und basiert auf der Vorlage, die in WinAVR mitgeliefert wird und wurde bereits angepasst (Controllertyp ATmega16). Man kann das Makefile bearbeiten und an andere Controller anpassen oder sich mit dem Programm MFile menügesteuert ein Makefile "zusammenklicken". Das Makefile speichert man unter dem Namen <code>Makefile</code> (ohne Endung) im selben Verzeichnis, in dem auch die Datei <code>main.c</code> mit dem Programmcode abgelegt ist. Detailliertere Erklärungen zur Funktion von Makefiles finden sich im Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|Exkurs: Makefiles]].<br />
<br />
<pre><br />
D:\beispiel>dir<br />
<br />
Verzeichnis von D:\beispiel<br />
<br />
28.11.2006 22:53 <DIR> .<br />
28.11.2006 22:53 <DIR> ..<br />
28.11.2006 20:06 118 main.c<br />
28.11.2006 20:03 16.810 Makefile<br />
2 Datei(en) 16.928 Bytes<br />
</pre><br />
<br />
Nun gibt man ''make all'' ein. Falls das mit WinAVR installierte Programmers Notepad genutzt wird, gibt es dazu einen Menüpunkt im Tools Menü. Sind alle Einstellungen korrekt, entsteht eine Datei <code>main.hex</code>, in welcher der Code für den AVR enthalten ist. <br />
<pre><br />
D:\beispiel>make all<br />
<br />
-------- begin --------<br />
avr-gcc (GCC) 3.4.6<br />
Copyright (C) 2006 Free Software Foundation, Inc.<br />
This is free software; see the source for copying conditions. There is NO<br />
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.<br />
<br />
Compiling C: main.c<br />
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -f<br />
unsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef<br />
-Wa,-adhlns=obj/main.lst -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c -<br />
o obj/main.o<br />
<br />
Linking: main.elf<br />
avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -funs<br />
igned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -W<br />
a,-adhlns=obj/main.o -std=gnu99 -Wundef -MD -MP -MF .dep/main.elf.d obj/main.o<br />
--output main.elf -Wl,-Map=main.map,--cref -lm<br />
<br />
Creating load file for Flash: main.hex<br />
avr-objcopy -O ihex -R .eeprom main.elf main.hex<br />
</pre><br />
<br />
Der Inhalt der hex-Datei kann nun zum Controller übertragen werden. Dies kann z.&nbsp;B. über In-System-Programming ([[ISP]]) erfolgen, das im [[AVR-Tutorial: Equipment]] beschrieben ist. Makefiles nach der WinAVR/MFile-Vorlage sind für die Nutzung des Programms [[AVRDUDE]] vorbereitet. Wenn man den Typ und Anschluss des Programmiergerätes richtig eingestellt hat, kann mit ''make program'' die Übertragung mittels AVRDUDE gestartet werden. Jede andere Software, die hex-Dateien lesen und zu einem AVR übertragen kann<ref>z.&nbsp;B. [[Pony-Prog_Tutorial|Ponyprog]], yapp, AVRStudio</ref>, kann natürlich ebenfalls genutzt werden.<br />
<br />
Startet man nun den Controller (Reset-Taster oder Stromzufuhr aus/an), werden vom Programm die Anschlüsse PB0 und PB1 auf 1 gesetzt. Man kann mit einem Messgerät nun an diesem Anschluss die Betriebsspannung messen oder eine [[LED]] leuchten lassen (Anode an den Pin, Vorwiderstand nicht vergessen). An den Anschlüssen PB2-PB7 misst man 0 Volt. Eine mit der Anode mit einem dieser Anschlüsse verbundene LED leuchtet nicht.<br />
<br />
= Ganzzahlige Datentypen (Integer) =<br />
<br />
Bei der Programmierung von Mikrokontrollern ist die Definition einiger ganzzahliger Datentypen sinnvoll, an denen eindeutig die Bit-Länge abgelesen werden kann.<br />
<br />
Standardisierte Datentypen werden in der Header-Datei <code>stdint.h</code> definiert, die folgendermaßen eingebunden werden kann:<br />
<syntaxhighlight lang="c">#include <stdint.h></syntaxhighlight><br />
<br />
{| {{Tabelle}}<br />
|+ '''int-Typen aus <code>stdint.h</code> (C99)'''<br/>&nbsp;<br />
|- bgcolor="#d0d0ff"<br />
!colspan="5"| Vorzeichenbehaftete int-Typen<br />
|- bgcolor="#e8e8ff"<br />
! Typname || Bit-Breite ||colspan="2"| Wertebereich<br />
|align="center| '''C-Entsprechung''' (avr-gcc)<br />
|-<br />
|<code>int8_t</code> ||align="right"| 8 || −128 ⋯ 127 || −2<sup>7</sup> ⋯ 2<sup>7</sup>−1 || <code>signed char</code><br />
|-<br />
|<code>int16_t</code> ||align="right"| 16 || −32768 ⋯ 32767 || −2<sup>15</sup> ⋯ 2<sup>15</sup>−1 || <code>signed short</code>, <code>signed int</code><br />
|-<br />
|<code>int32_t</code> ||align="right"| 32 || −2147483648 ⋯ 2147483647 || −2<sup>31</sup> ⋯ 2<sup>31</sup>−1 || <code>signed long</code><br />
|-<br />
|<code>int64_t</code> ||align="right"| 64 || −9223372036854775808 ⋯ 9223372036854775807 || −2<sup>63</sup> ⋯ 2<sup>63</sup>−1 || <code>signed long long</code><br />
|- bgcolor="#d0d0ff"<br />
!colspan="5"| Vorzeichenlose int-Typen<br />
|- bgcolor="#e8e8ff"<br />
! Typname || Bit-Breite ||colspan="2"| Wertebereich<br />
|align="center| '''C-Entsprechung''' (avr-gcc)<br />
|-<br />
|<code>uint8_t</code> ||align="right"| 8 || 0 ⋯ 255 || 0 ⋯ 2<sup>8</sup>−1 || <code>unsigned char</code><br />
|-<br />
|<code>uint16_t</code> ||align="right"| 16 || 0 ⋯ 65535 || 0 ⋯ 2<sup>16</sup>−1 || <code>unsigned short</code>, <code>unsigned int</code><br />
|-<br />
|<code>uint32_t</code> ||align="right"| 32 || 0 ⋯ 4294967295 || 0 ⋯ 2<sup>32</sup>−1 || <code>unsigned long</code><br />
|-<br />
|<code>uint64_t</code> ||align="right"| 64 || 0 ⋯ 18446744073709551615 || 0 ⋯ 2<sup>64</sup>−1 || <code>unsigned long long</code><br />
|}<br />
<br />
Neben den Typen gibt es auch Makros für die Bereichsgrenzen wie <code>INT8_MIN</code> oder <code>UINT16_MAX</code>. Siehe dazu auch: [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html Dokumentation der avr-libc: Standard Integer Types].<br />
<br />
= Grundsätzlicher Programmaufbau eines µC-Programms =<br />
<br />
Wir unterscheiden zwischen 2 verschiedenen Methoden, um ein<br />
Mikrocontroller-Programm zu schreiben, und zwar völlig unabhängig davon, in<br />
welcher Programmiersprache das Programm geschrieben wird.<br />
<br />
== Sequentieller Programmablauf ==<br />
<br />
[[Image:Sequentielle Programme.gif|left]]<br />
Bei dieser Programmiertechnik wird eine Endlosschleife programmiert, welche im<br />
Wesentlichen immer den gleichen Aufbau hat. Es wird hier nach dem sogenannten EVA-Prinzip gehandelt. EVA steht für "Eingabe, Verarbeitung, Ausgabe".<br />
{{Absatz}}<br />
<br />
== Interruptgesteuerter Programmablauf ==<br />
<br />
[[Image:Interrupt Programme.gif|left]]<br />
Bei dieser Methode werden beim Programmstart zuerst die gewünschten Interruptquellen aktiviert und dann in eine Endlosschleife gegangen, in welcher Dinge erledigt werden können, welche nicht zeitkritisch sind. Wenn ein Interrupt ausgelöst wird, so wird automatisch die zugeordnete Interruptfunktion ausgeführt.<br />
{{Absatz}}<br />
<br />
= Zugriff auf Register =<br />
<br />
Die AVR-Controller verfügen über eine Vielzahl von Registern. Die meisten<br />
davon sind sogenannte Schreib-/Leseregister. Das heißt, das Programm kann die<br />
Inhalte der Register sowohl auslesen als auch beschreiben.<br />
<br />
Register haben einen besonderen Stellenwert bei den AVR Controllern. Sie dienen dem Zugriff auf die Ports und die Schnittstellen des Controllers. Wir unterscheiden zwischen 8-Bit und 16-Bit Registern. Vorerst behandeln wir die 8-Bit Register.<br />
<br />
Einzelne Register sind bei allen AVRs vorhanden, andere wiederum nur bei bestimmten Typen. So sind beispielsweise die Register, welche für den Zugriff auf den UART notwendig sind, selbstverständlich nur bei denjenigen Modellen vorhanden, welche über einen integrierten Hardware UART bzw. USART verfügen.<br />
<br />
Die Namen der Register sind in den Headerdateien zu den entsprechenden AVR-Typen definiert. Dazu muss man den Namen der controllerspezifischen Headerdatei nicht kennen. Es reicht aus, die allgemeine Headerdatei ''avr/io.h'' einzubinden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
</syntaxhighlight><br />
<br />
Ist im Makefile der MCU-Typ z.&nbsp;B. mit dem Inhalt atmega8 definiert (und wird somit per -mmcu=atmega8 an den Compiler übergeben), wird beim Einlesen der io.h-Datei implizit ("automatisch") auch die iom8.h-Datei mit den Register-Definitionen für den ATmega8 eingelesen.<br />
<br />
<!-- Wohl besser als Anhang - spaeter... --><br />
Intern wird diese "Automatik" wie folgt realisiert: Der Controllertyp wird dem Compiler als Parameter übergeben (vgl. ''avr-gcc -c -mmcu=atmega16 [...]'' im Einführungsbeispiel). Wird ein Makefile nach der WinAVR/mfile-Vorlage verwendet, setzt man die Variable ''MCU'', der Inhalt dieser Variable wird dann an passender Stelle für die Compilerparameter verwendet. Der Compiler definiert intern eine dem mmcu-Parameter zugeordnete "Variable" (genauer: ein Makro) mit dem Namen des Controllers, vorangestelltem ''__AVR_'' und angehängten Unterstrichen (z.&nbsp;B. wird bei ''-mmcu=atmega16'' das Makro ''__AVR_ATmega16__'' definiert). Beim Einbinden der Header-Datei ''avr/io.h'' wird geprüft, ob das jeweilige Makro definiert ist und die zum Controller passende Definitionsdatei eingelesen. Zur Veranschaulichung einige Ausschnitte aus einem Makefile:<br />
<br />
<pre><br />
[...]<br />
# MCU Type ("name") setzen:<br />
MCU = atmega16<br />
[...]<br />
<br />
[...]<br />
## Verwendung des Inhalts von MCU (hier atmega16) fuer die <br />
## Compiler- und Assembler-Parameter<br />
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)<br />
ALL_CPPFLAGS = -mmcu=$(MCU) -I. -x c++ $(CPPFLAGS) $(GENDEPFLAGS)<br />
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)<br />
[...]<br />
<br />
[...]<br />
## Aufruf des Compilers:<br />
## mit den Parametern ($(ALL_CFLAGS) ist -mmcu=$(MCU)[...] = -mmcu=atmega16[...]<br />
$(OBJDIR)/%.o : %.c<br />
@echo<br />
@echo $(MSG_COMPILING) $<<br />
$(CC) -c $(ALL_CFLAGS) $< -o $@ <br />
[...]<br />
</pre><br />
<br />
Da --mmcu=atmega16 übergeben wurde, wird __AVR_ATmega16__ definiert und kann in avr/io.h zur Fallunterscheidung genutzt werden:<br />
<br />
<syntaxhighlight lang="c"><br />
// avr/io.h <br />
// (bei WinAVR-Standardinstallation in C:\WinAVR\avr\include\avr)<br />
[...]<br />
#if defined (__AVR_AT94K__)<br />
# include <avr/ioat94k.h><br />
// [...]<br />
#elif defined (__AVR_ATmega16__)<br />
// da __AVR_ATmega16__ definiert ist, wird avr/iom16.h eingebunden:<br />
# include <avr/iom16.h><br />
// [...]<br />
#else<br />
# if !defined(__COMPILING_AVR_LIBC__)<br />
# warning "device type not defined"<br />
# endif<br />
#endif<br />
</syntaxhighlight><br />
<br />
Die Beispiele in den folgenden Abschnitten demonstrieren den Zugriff auf Register anhand der Register für I/O-Ports (PORTx, DDRx, PINx), die Vorgehensweise ist jedoch für alle Register (z.&nbsp;B. die des UART, ADC, SPI) analog.<br />
<br />
== Schreiben in Register ==<br />
<br />
Zum Schreiben kann man Register einfach wie eine Variable setzen.<ref>In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Schreibzugriff über die Funktion outp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt, outp() ist nicht mehr erforderlich.</ref><br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
/* Setzt das Richtungsregister des Ports A auf 0xff <br />
(alle Pins als Ausgang, vgl. Abschnitt Zugriff auf Ports): */<br />
DDRA = 0xff; <br />
<br />
/* Setzt PortA auf 0x03, Bit 0 und 1 "high", restliche "low": */<br />
PORTA = 0x03; <br />
<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binär 00011111 = Hexadezimal 1F<br />
DDRB = 0x1F; /* direkte Zuweisung - unübersichtlich */<br />
<br />
/* Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit<br />
aber übersichtlicher und selbsterklärend: */<br />
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);<br />
<br />
while (1);<br />
}<br />
</syntaxhighlight><br />
<br />
Die ausführliche Schreibweise sollte bevorzugt verwendet werden, da dadurch die Zuweisungen selbsterklärend sind und somit der Code leichter nachvollzogen werden kann. Atmel verwendet sie auch bei Beispielen in Datenblätten und in den allermeisten Quellcodes zu Application-Notes. Mehr zu der Schreibweise mit "|" und "<<" findet man unter [[Bitmanipulation]].<br />
<br />
Der gcc C-Compiler unterstützt ab Version 4.3.0 Konstanten im Binärformat, z.&nbsp;B. DDRB&nbsp;=&nbsp;0b00011111. Diese Schreibweise ist jedoch nur in GNU-C verfügbar und nicht in ISO-C definiert. Man sollte sie daher nicht verwenden, wenn Code mit anderen ausgetauscht oder mit anderen Compilern bzw. älteren Versionen des gcc genutzt werden soll.<br />
<br />
== Verändern von Registerinhalten ==<br />
<br />
Einzelne Bits setzt und löscht man "Standard-C-konform" mittels logischer (Bit-) Operationen. <br />
<br />
<syntaxhighlight lang="c"><br />
x |= (1 << Bitnummer); // Hiermit wird ein Bit in x gesetzt<br />
x &= ~(1 << Bitnummer); // Hiermit wird ein Bit in x geloescht<br />
</syntaxhighlight><br />
<br />
Es wird jeweils nur der Zustand des angegebenen Bits geändert, der vorherige Zustand der anderen Bits bleibt erhalten. <br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
#define MEINBIT 2<br />
...<br />
PORTA |= (1 << MEINBIT); /* setzt Bit 2 an PortA auf 1 */<br />
PORTA &= ~(1 << MEINBIT); /* loescht Bit 2 an PortA */<br />
</syntaxhighlight><br />
<br />
Mit dieser Methode lassen sich auch mehrere Bits eines Registers gleichzeitig setzen und löschen.<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
DDRA &= ~( (1<<PA0) | (1<<PA3) ); /* PA0 und PA3 als Eingaenge */<br />
PORTA |= ( (1<<PA0) | (1<<PA3) ); /* Interne Pull-Up fuer beide einschalten */<br />
</syntaxhighlight><br />
<br />
Bei bestimmten AVR Registern mit Bits, die durch Beschreiben mit einer logischen 1 gelöscht werden, muss eine absolute Zuweisung benutzt werden. Ein ODER löscht in diesen Registern ALLE gesetzten Bits!<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
TIFR2 = (1<<OCF2A); // Nur Bit OCF2A löschen<br />
</syntaxhighlight><br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind nicht mehr erforderlich.<br />
<br />
Siehe auch:<br />
* [[Bitmanipulation]]<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
<br />
== Lesen aus Registern ==<br />
<br />
Zum Lesen kann man auf Register einfach wie auf eine Variable zugreifen. In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Lesezugriff über die Funktion inp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt und inp() ist nicht mehr erforderlich.<br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdint.h><br />
<br />
uint8_t foo;<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
/* kopiert den Status der Eingabepins an PortB <br />
in die Variable foo: */<br />
foo = PINB; <br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Die Abfrage der Zustände von Bits erfolgt durch Einlesen des gesamten Registerinhalts und ausblenden der Bits deren Zustand nicht von Interesse ist. Einige Beispiele zum Prüfen ob Bits gesetzt oder gelöscht sind:<br />
<br />
<syntaxhighlight lang="c"><br />
#define MEINBIT0 0 <br />
#define MEINBIT2 2<br />
<br />
uint8_t i;<br />
<br />
extern test1();<br />
<br />
// Funkion test1 aufrufen, wenn Bit 0 in Register PINA gesetzt (1) ist<br />
i = PINA; // Inhalt in Arbeitsvariable<br />
i = i & 0x01; // alle Bits bis auf Bit 0 ausblenden (bitweise und)<br />
// falls das Bit gesetzt war, hat i den Inhalt 1<br />
if ( i != 0 ) { // Ergebnis ungleich 0 (wahr)? <br />
test1(); // dann muss Bit 0 in i gesetzt sein -> Funktion aufrufen<br />
}<br />
// verkürzt:<br />
if ( ( PINA & 0x01 ) != 0 ) {<br />
test1();<br />
}<br />
// nochmals verkürzt:<br />
if ( PINA & 0x01 ) {<br />
test1();<br />
}<br />
// mit definierter Bitnummer:<br />
if ( PINA & ( 1 << MEINBIT0 ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und/oder Bit 2 gesetzt ist. (Bit 0 und 2 also Wert 5) <br />
// (Bedenke: Bit 0 hat Wert 1, Bit 1 hat Wert 2 und Bit 2 hat Wert 4)<br />
if ( PINA & 0x05 ) {<br />
test1(); // Vergleich <> 0 (wahr), also mindestens eines der Bits gesetzt<br />
}<br />
// mit definierten Bitnummern:<br />
if ( PINA & ( ( 1 << MEINBIT0 ) | ( 1 << MEINBIT2 ) ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und Bit 2 gesetzt sind<br />
if ( ( PINA & 0x05 ) == 0x05 ) { // nur wahr, wenn beide Bits gesetzt<br />
test1();<br />
}<br />
<br />
// Funktion test2() aufrufen, wenn Bit 0 gelöscht (0) ist<br />
i = PINA; // einlesen in temporäre Variable<br />
i = i & 0x01; // maskieren von Bit 0<br />
if ( i == 0 ) { // Vergleich ist wahr, wenn Bit 0 nicht gesetzt ist<br />
test2();<br />
}<br />
// analog mit not-Operator<br />
if ( !i ) {<br />
test2();<br />
}<br />
// nochmals verkürzt:<br />
if ( !( PINA & 0x01 ) ) {<br />
test2();<br />
}<br />
</syntaxhighlight><br />
<br />
== Warten auf einen bestimmten Zustand ==<br />
<br />
Es gibt in der Bibliothek avr-libc Funktionen, die warten, bis ein bestimmter Zustand eines Bits erreicht ist. Es ist allerdings normalerweise eine eher unschöne Programmiertechnik, da in diesen Funktionen "blockierend" gewartet wird. Der Programmablauf bleibt also an dieser Stelle stehen, bis das maskierte Ereignis erfolgt ist. Setzt man den [[Watchdog]] ein, muss man darauf achten, dass dieser auch noch getriggert wird (Zurücksetzen des Watchdogtimers). <br />
<br />
Die Funktion '''loop_until_bit_is_set''' wartet in einer Schleife, bis das definierte Bit gesetzt ist. Wenn das Bit beim Aufruf der Funktion bereits gesetzt ist, wird die Funktion sofort wieder verlassen. Das niederwertigste Bit hat die Bitnummer 0. <br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 2 (das dritte Bit) in Register PINA gesetzt (1) ist */<br />
<br />
#define WARTEPIN PINA<br />
#define WARTEBIT PA2<br />
<br />
// mit der avr-libc Funktion:<br />
loop_until_bit_is_set(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// _nicht_ ungleich 0 (also 0) ist.<br />
while ( !(WARTEPIN & (1 << WARTEBIT)) ) {}<br />
...<br />
</syntaxhighlight><br />
<br />
<br />
Die Funktion '''loop_until_bit_is_clear''' wartet in einer Schleife, bis das definierte Bit gelöscht ist. Wenn das Bit beim Aufruf der Funktion bereits gelöscht ist, wird die Funktion sofort wieder verlassen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 4 (das fuenfte Bit) in Register PINB geloescht (0) ist */<br />
#define WARTEPIN PINB<br />
#define WARTEBIT PB4<br />
<br />
// avr-libc-Funktion:<br />
loop_until_bit_is_clear(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// gesetzt (1) ist <br />
while ( WARTEPIN & (1<<WARTEBIT) ) {}<br />
...<br />
</syntaxhighlight><br />
<br />
Universeller und auch auf andere Plattformen besser übertragbar ist die Verwendung von C-Standardoperationen.<br />
<br />
Siehe auch: <br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
* [[Bitmanipulation]]<br />
<br />
== 16-Bit Register (ADC, ICR1, OCR1x, TCNT1, UBRR) ==<br />
<br />
Einige der Portregister in den AVR-Controllern sind 16 Bit breit. Im Datenblatt sind diese Register üblicherweise mit dem Suffix "L" (Low-Byte) und "H" (High-Byte) versehen. Die avr-libc definiert zusätzlich die meisten dieser Variablen die Bezeichnung ohne "L" oder "H". Auf diese Register kann dann direkt zugegriffen werden. Dies ist zum Beispiel der Fall für Register wie ADC oder TCNT1.<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
uint16_t foo;<br />
<br />
/* setzt die Wort-Variable foo auf den Wert der letzten AD-Wandlung */<br />
foo = ADC; <br />
</syntaxhighlight><br />
<br />
Bei anderen Registern, wie zum Beispiel Baudraten-Register, liegen High- und Low-Teil nicht direkt nebeneinander im SFR-Bereich, so dass ein 16-Bit Zugriff nicht möglich ist und der Zugriff zusammengebastelt werden muss:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
...<br />
uint16_t baud = F_CPU / (UART_BAUD_RATE * 16L) -1;<br />
<br />
UBRRH = (uint8_t) (baud >> 8);<br />
UBRRL = (uint8_t) baud;<br />
...<br />
</syntaxhighlight><br />
<br />
Bei einigen AVR-Typen wie ATmega8 oder ATmega16 teilen sich UBRRH und UCSRC die gleiche Speicher-Adresse. Damit der AVR trotzdem zwischen den beiden Registern unterscheiden kann, bestimmt das Bit7 (URSEL), welches Register tatsächlich beschrieben werden soll. ''1000 0011'' (0x83) adressiert demnach UCSRC und übergibt den Wert ''3''. Und ''0000 0011'' (0x3) adressiert UBRRH und übergibt ebenfalls den Wert ''3''. <br />
<br />
Speziell bei den 16-Bit-Timern und auch beim ADC ist es bei allen Zugriffen auf Datenregister erforderlich, dass diese Daten synchronisiert sind. Wenn z.&nbsp;B. bei einem 16-Bit-Timer das High-Byte des Zählregisters gelesen wurde und vor dem Lesezugriff auf das Low-Byte ein Überlauf des Low-Bytes stattfindet, erhält man einen völlig unsinnigen Wert. Auch die Compare-Register müssen synchron geschrieben werden, da es ansonsten zu unerwünschten Compare-Ereignissen kommen kann. <br />
<br />
Beim ADC besteht das Problem darin, dass zwischen den Zugriffen auf die beiden Teilregister eine Wandlung beendet werden kann und der ADC ein neues Ergebnis in ADCL und ADCH schreiben will, wodurch High- und Low-Byte nicht zusammenpassen.<br />
<br />
Um diese Datenmüllproduktion zu verhindern, gibt es in beiden Fällen eine Synchronisation, die jeweils durch den Zugriff auf das Low-Byte ausgelöst wird:<br />
* Bei den Timer-Registern (das gilt für alle TCNT-, OCR- und ICR-Register bei den 16-Bit-Timern) wird bei einem ''Lesezugriff'' auf das Low-Byte automatisch das High-Byte in ein temporäres Register, das ansonsten nach außen nicht sichtbar ist, geschoben. Greift man nun ''anschließend'' auf das High-Byte zu, dann wird eben dieses temporäre Register gelesen.<br />
* Bei einem ''Schreibzugriff'' auf eines der genannten Register wird das High-Byte in besagtem temporären Register zwischengespeichert und erst beim Schreiben des Low-Bytes werden ''beide'' gleichzeitig in das eigentliche Register übernommen.<br />
<br />
Das bedeutet für die Reihenfolge:<br />
* Lesezugriff: Erst Low-Byte, dann High-Byte<br />
* Schreibzugriff: Erst High-Byte, dann Low-Byte<br />
<br />
Des weiteren ist zu beachten, dass es für all diese 16-Bit-Register nur ein einziges temporäres Register gibt, so dass das Auftreten eines Interrupts, in dessen Handler ein solches Register manipuliert wird, bei einem durch ihn unterbrochenen Zugriff i.d.R. zu Datenmüll führt. 16-Bit-Zugriffe sind generell nicht atomar! Wenn mit Interrupts gearbeitet wird, kann es erforderlich sein, vor einem solchen Zugriff auf ein 16-Bit-Register die Interrupt-Bearbeitung zu deaktivieren.<br />
<br />
Beim ADC-Datenregister ADCH/ADCL ist die Synchronisierung anders gelöst. Hier wird beim Lesezugriff (ADCH/ADCL sind logischerweise read-only) auf das Low-Byte ADCL beide Teilregister für Zugriffe seitens des ADC so lange gesperrt, bis das High-Byte ADCH ausgelesen wurde. Dadurch kann der ADC nach einem Zugriff auf ADCL keinen neuen Wert in ADCH/ADCL ablegen, bis ADCH gelesen wurde. Ergebnisse von Wandlungen, die zwischen einem Zugriff auf ADCL und ADCH beendet werden, gehen verloren!<br />
<br />
Nach einem Zugriff auf ADCL muss grundsätzlich ADCH gelesen werden!<br />
<br />
In beiden Fällen – also sowohl bei den Timern als auch beim ADC – werden vom C-Compiler 16-Bit Pseudo-Register zur Verfügung gestellt (z.&nbsp;B. TCNT1H/TCNT1L → TCNT1, ADCH/ADCL → ADC bzw. ADCW), bei deren Verwendung der Compiler automatisch die richtige Zugriffsreihenfolge regelt. In C-Programmen sollten grundsätzlich diese 16-Bit-Register verwendet werden! Sollte trotzdem ein Zugriff auf ein Teilregister erforderlich sein, sind obige Angaben zu berücksichtigen.<br />
<br />
Es ist darauf zu achten, dass auch ein Zugriff auf die 16-Bit-Register vom Compiler in zwei 8-Bit-Zugriffe aufgeteilt wird und dementsprechend genauso nicht-atomar ist wie die Einzelzugriffe. Auch hier gilt, dass u.U. die Interrupt-Bearbeitung gesperrt werden muss, um Datenmüll zu vermeiden.<br />
<br />
Beim ADC gibt es für den Fall, dass eine Auflösung von 8 Bit ausreicht, die Möglichkeit, das Ergebnis "linksbündig" in ADCH/ADCL auszurichten, so dass die relevanten 8 MSB in ADCH stehen. In diesem Fall muss bzw. sollte nur ADCH ausgelesen werden.<br />
<br />
ADC und ADCW sind unterschiedliche Bezeichner für das selbe Registerpaar. Üblicherweise kann man in C-Programmen ADC verwenden, was analog zu den anderen 16-Bit-Registern benannt ist. ADCW (ADC Word) existiert nur deshalb, weil die Headerdateien auch für Assembler vorgesehen sind und es bereits einen Assembler-Befehl namens ''adc'' gibt. <br />
<br />
Im Umgang mit 16-Bit Registern siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Related Pages/Frequently Asked Questions/Nr. 8<br />
* Datenblatt Abschnitt ''Accessing 16-bit Registers''<br />
<br />
== IO-Register als Parameter und Variablen ==<br />
<br />
Um Register als Parameter für eigene Funktionen übergeben zu können, muss man sie als einen volatile uint8_t Pointer übergeben. Zum Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <util/delay.h><br />
<br />
uint8_t key_pressed (volatile uint8_t *inputreg, uint8_t inputbit)<br />
{<br />
static uint8_t last_state = 0;<br />
<br />
if (last_state == (*inputreg & (1<<inputbit)))<br />
return 0; /* keine Änderung */<br />
<br />
/* Wenn doch, warten bis etwaiges Prellen vorbei ist: */<br />
_delay_ms(20);<br />
<br />
/* Zustand für nächsten Aufruf merken: */<br />
last_state = *inputreg & (1<<inputbit);<br />
<br />
/* und den entprellten Tastendruck zurückgeben: */<br />
return *inputreg & (1<<inputbit);<br />
}<br />
<br />
/* Beispiel für einen Funktionsaufruf: */<br />
<br />
void foo (void)<br />
{<br />
uint8_t i = key_pressed (&PINB, PB1);<br />
}<br />
</syntaxhighlight><br />
<br />
Ein Aufruf der Funktion mit call by value würde Folgendes bewirken: Beim Funktionseintritt wird nur eine Kopie des momentanen Portzustandes angefertigt, die sich unabhängig vom tatsächlichen Zustand das Ports nicht mehr ändert, womit die Funktion wirkungslos wäre. Die Übergabe eines Zeigers wäre die Lösung, wenn der Compiler nicht optimieren würde. Denn dadurch wird im Programm nicht von der Hardware gelesen, sondern wieder nur von einem Abbild im Speicher. Das Ergebnis wäre das gleiche wie oben. Mit dem Schlüsselwort volatile sagt man nun dem Compiler, dass die entsprechende Variable entweder durch andere Softwareroutinen (Interrupts) oder durch die Hardware verändert werden kann.<br />
<br />
Siehe auch: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass avr-libc FAQ: "How do I pass an IO port as a parameter to a function?"]<br />
<br />
= Zugriff auf IO-Ports =<br />
<br />
Jeder AVR implementiert eine unterschiedliche Menge an GPIO-Registern<br />
(GPIO - General Purpose Input/Output). Diese Register dienen dazu:<br />
* einzustellen welche der Anschlüsse ("Beinchen") des Controllers als Ein- oder Ausgänge dienen<br />
* bei Ausgängen deren Zustand festzulegen<br />
* bei Eingängen deren Zustand zu erfassen<br />
<br />
Mittels GPIO werden digitale Zustände gesetzt und erfasst, d.h. die Spannung an einem Ausgang wird ein- oder ausgeschaltet und an einem Eingang wird erfasst, ob die anliegende Spannung über oder unter einem bestimmten Schwellwert liegt. Im Datenblatt Abschnitt Electrical Characteristics/DC Characteristics finden sich die Spannungswerte (V_OL, V_OH für Ausgänge, V_IL, V_IH für Eingänge).<br />
<br />
Die Verarbeitung von analogen Eingangswerten und die Ausgabe von Analogwerten wird in Kapitel [[AVR-GCC-Tutorial#Analoge_Ein-_und_Ausgabe|Analoge Ein- und Ausgabe]] behandelt.<br />
<br />
Die physischen Ein- und Ausgänge werden bei AVR-Controllern zu logischen Ports gruppiert.<br />
<br />
Alle Ports werden über Register gesteuert. Dazu sind jedem Port 3 Register zugeordnet:<br />
<br />
{| class="wikitable"<br />
|- <br />
! width="10%"| DDRx<br />
| Datenrichtungsregister für Port'''x'''. <br />
'''x''' entspricht '''A''', '''B''', ''' C''' usw. je nach gewünschtem Port. Bit im Register gesetzt (1) für Ausgang, Bit gelöscht (0) für Eingang.<br />
|- <br />
! PINx<br />
| Eingangsadresse für Port'''x'''. <br />
Zustand des Ports. Die Bits in PINx entsprechen dem Zustand der als Eingang definierten Portpins. Bit 1 wenn Pin "high", Bit 0 wenn Portpin low.<br />
|-<br />
! PORTx<br />
| Datenregister für Port'''x'''. <br />
Dieses Register wird verwendet, um die Ausgänge eines Ports anzusteuern. Bei Pins, die mittels DDRx auf Eingang geschaltet wurden, können über PORTx<br />
die internen Pull-Up Widerstände aktiviert oder deaktiviert werden (1 = aktiv).<br />
|}<br />
<br />
Die folgenden Beispiele gehen von einem AVR aus, der sowohl Port A als auch Port B besitzt. Sie müssen für andere AVRs (zum Beispiel ATmega8/48/88/168) entsprechend angepasst werden.<br />
<br />
== Datenrichtung bestimmen ==<br />
<br />
Zuerst muss die Datenrichtung der verwendeten Pins bestimmt werden. Um dies zu erreichen, wird das Datenrichtungsregister des entsprechenden Ports beschrieben.<br />
<br />
Für jeden Pin, der als Ausgang verwendet werden soll, muss dabei das<br />
entsprechende Bit auf dem Port gesetzt werden. Soll der Pin als Eingang<br />
verwendet werden, muss das entsprechende Bit gelöscht sein.<br />
<br />
Beispiel:<br />
Angenommen am Port B sollen die Pins 0 bis 4 als Ausgänge definiert werden, die noch verbleibenden Pins 5 bis 7 sollen als Eingänge fungieren. Dazu ist es daher notwendig, im für das Port B zuständigen Datenrichtungsregister DDRB folgende Bitkonfiguration einzutragen<br />
<br />
+---+---+---+---+---+---+---+---+<br />
| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |<br />
+---+---+---+---+---+---+---+---+<br />
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br />
<br />
In C liest sich das dann so:<br />
<br />
<syntaxhighlight lang="c"><br />
// in io.h wird u.a. DDRB definiert:<br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binaer 00011111 = Hexadezimal 1F<br />
// direkte Zuweisung - standardkonform */<br />
DDRB = 0x1F; /* <br />
<br />
// Uebersichtliche Alternative - Binaerschreibweise, aber kein ISO-C<br />
DDRB = 0b00011111;<br />
<br />
// Ausfuehrliche Schreibweise: identische Funktionalitaet, mehr Tipparbeit<br />
// aber uebersichtlicher und selbsterklaerend:<br />
DDRB |= (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4); <br />
</syntaxhighlight><br />
<br />
Die Pins 5 bis 7 werden (da 0) als Eingänge geschaltet. Weitere Beispiele:<br />
<br />
<syntaxhighlight lang="c"><br />
// Alle Pins des Ports B als Ausgang definieren:<br />
DDRB = 0xff; <br />
// Pin0 wieder auf Eingang und andere im urspruenglichen Zustand belassen:<br />
DDRB &= ~(1 << DDB0);<br />
// Pin 3 und 4 auf Eingang und andere im urspruenglichen Zustand belassen:<br />
DDRB &= ~((1 << DDB3) | (1 << DDB4));<br />
// Pin 0 und 3 wieder auf Ausgang und andere im ursprünglichen Zustand belassen:<br />
DDRB |= (1 << DDB0) | (1 << DDB3);<br />
// Alle Pins auf Eingang:<br />
DDRB = 0x00;<br />
</syntaxhighlight><br />
<br />
== Vordefinierte Bitnummern für I/O-Register ==<br />
<br />
Die Bitnummern (z.&nbsp;B. PCx, PINCx und DDCx für den Port C) sind in den io*.h-Dateien der avr-libc definiert und dienen lediglich der besseren Lesbarkeit. Man muss diese Definitionen nicht verwenden oder kann auch einfach "immer" PAx, PBx, PCx usw. nutzen, auch wenn der Zugriff auf Bits in DDRx- oder PINx-Registern erfolgt. Für den Compiler sind die Ausdrücke (1<<PC7), (1<<DDC7) und (1<<PINC7) identisch zu (1<<7) (genauer: der Präprozessor ersetzt die Ausdrücke (1<<PC7),... zu (1<<7)). Ein Ausschnitt der Definitionen für Port C eines ATmega32 aus der iom32.h-Datei zur Verdeutlichung (analog für die weiteren Ports):<br />
<br />
<syntaxhighlight lang="c"><br />
...<br />
/* PORTC */<br />
#define PC7 7<br />
#define PC6 6<br />
#define PC5 5<br />
#define PC4 4<br />
#define PC3 3<br />
#define PC2 2<br />
#define PC1 1<br />
#define PC0 0<br />
<br />
/* DDRC */<br />
#define DDC7 7<br />
#define DDC6 6<br />
#define DDC5 5<br />
#define DDC4 4<br />
#define DDC3 3<br />
#define DDC2 2<br />
#define DDC1 1<br />
#define DDC0 0<br />
<br />
/* PINC */<br />
#define PINC7 7<br />
#define PINC6 6<br />
#define PINC5 5<br />
#define PINC4 4<br />
#define PINC3 3<br />
#define PINC2 2<br />
#define PINC1 1<br />
#define PINC0 0<br />
</syntaxhighlight><br />
<br />
<br />
== Digitale Signale ==<br />
<br />
Am einfachsten ist es, digitale Signale mit dem Mikrocontroller zu erfassen bzw. auszugeben.<br />
<br />
== Ausgänge ==<br />
Will man als Ausgang definierte Pins (entsprechende DDRx-Bits = 1) auf Logisch 1 setzen, setzt man die entsprechenden Bits im Portregister.<br />
<br />
Mit dem Befehl<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB = 0x04; /* besser PORTB=(1<<PB2) */<br />
<br />
// Uebersichtliche Alternative - Binaerschreibweise<br />
PORTB = 0b00000100; /* direkte Zuweisung - uebersichtlich */<br />
<br />
</syntaxhighlight><br />
wird also der Ausgang an Pin PB2 gesetzt (Beachte, dass die Bits immer ''von 0 an'' gezählt werden, das niederwertigste Bit ist also Bitnummer 0 und nicht etwa Bitnummer 1).<br />
<br />
Man beachte, dass bei der Zuweisung mittels '''=''' immer alle Pins gleichzeitig angegeben werden. Man sollte also, wenn nur bestimmte Ausgänge geschaltet werden sollen, zuerst den aktuellen Wert des Ports einlesen und das Bit des gewünschten Ports in diesen Wert einfließen lassen. Will man also nur den dritten Pin (Bit Nr. 2) an Port B auf "high" setzen und den Status der anderen Ausgänge unverändert lassen, nutze man diese Form:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB = PORTB | 0x04; /* besser: PORTB = PORTB | ( 1<<PB2 ) */<br />
/* vereinfacht durch Nutzung des |= Operators : */<br />
PORTB |= (1<<PB2);<br />
<br />
/* auch mehrere "gleichzeitig": */<br />
PORTB |= (1<<PB4) | (1<<PB5); /* Pins PB4 und PB5 "high" */<br />
</syntaxhighlight><br />
<br />
"Ausschalten", also Ausgänge auf "low" setzen, erfolgt analog:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB &= ~(1<<PB2); /* loescht Bit 2 in PORTB und setzt damit Pin PB2 auf low */ <br />
PORTB &= ~( (1<<PB4) | (1<<PB5) ); /* Pin PB4 und Pin PB5 "low" */<br />
</syntaxhighlight><br />
Siehe auch [[Bitmanipulation]]<br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind in aktuellen Versionen der avr-libc nicht mehr enthalten und auch nicht mehr erforderlich.<br />
<br />
''Falls der Anfangszustand von Ausgängen kritisch ist, muss die Reihenfolge beachtet werden, mit der die Datenrichtung (DDRx) eingestellt und der Ausgabewert (PORTx) gesetzt wird:''<br />
<br />
Für Ausgangspins, die mit Anfangswert "high" initialisiert werden sollen:<br />
* zuerst die Bits im PORTx-Register setzen<br />
* anschließend die Datenrichtung auf Ausgang stellen<br />
<br />
Daraus ergibt sich die Abfolge für einen Pin, der bisher als Eingang mit abgeschaltetem Pull-Up konfiguriert war:<br />
* setze PORTx: interner Pull-Up aktiv<br />
* setze DDRx: Ausgang ("high")<br />
<br />
Bei der Reihenfolge erst DDRx und dann PORTx kann es zu einem kurzen "low-Puls" kommen, der auch externe Pull-Up-Widerstände "überstimmt". Die (ungünstige) Abfolge: Eingang -> setze DDRx: Ausgang (auf "low", da PORTx nach Reset 0) -> setze PORTx: Ausgang auf high. Vergleiche dazu auch das Datenblatt Abschnitt ''Configuring the Pin''.<br />
<br />
== Eingänge (Wie kommen Signale in den &micro;C) ==<br />
<br />
Die digitalen Eingangssignale können auf verschiedene Arten zu unserer Logik gelangen.<br />
<br />
=== Signalkopplung ===<br />
<br />
Am einfachsten ist es, wenn die Signale direkt aus einer anderen digitalen Schaltung übernommen werden können. Hat der Ausgang der entsprechenden Schaltung TTL-Pegel dann können wir sogar direkt den Ausgang der Schaltung mit einem Eingangspin von unserem Controller verbinden.<br />
<br />
Hat der Ausgang der anderen Schaltung keinen TTL-Pegel so müssen wir den Pegel über entsprechende Hardware (z.&nbsp;B. Optokoppler, [[Widerstand#Spannungsteiler|Spannungsteiler]], "Levelshifter" aka [[Pegelwandler]]) anpassen.<br />
<br />
Die Masse der beiden Schaltungen muss selbstverständlich miteinander verbunden werden. Der Software selber ist es natürlich letztendlich egal, wie das Signal eingespeist wird. Wir können ja ohnehin lediglich prüfen, ob an einem Pin unseres Controllers eine logische 1 (Spannung größer ca. 0,7*Vcc) oder eine logische 0 (Spannung kleiner ca. 0,2*Vcc) anliegt. Detaillierte Informationen darüber, ab welcher Spannung ein Eingang als 0 ("low") bzw. 1 ("high") erkannt wird, liefert die Tabelle DC Characteristics im Datenblatt des genutzten Controllers.<br />
<br />
{| class="wikitable" style="text-align:center; width:20em"<br />
|+ '''Logikpegel'''<br />
|-<br />
! VCC [V]<br />
! Low [V]<br />
! High [V]<br />
|-<br />
! 5<br />
| 1,0 || 3,5<br />
|-<br />
! 3,3<br />
| 0,66 || 2,3<br />
|-<br />
! 1,8<br />
| 0,36 || 1,26 <br />
|}<br />
<br />
Die Abfrage der Zustände der Portpins erfolgt direkt über den Registernamen.<br />
<br />
{{Warnung|Dabei ist wichtig, zur Abfrage der Eingänge ''nicht'' etwa Portregister '''PORTx''' zu verwenden, sondern Eingangsregister '''PINx'''. Ansonsten liest man nicht den Zustand der Eingänge, sondern den Status der internen Pull-Up-Widerstände. Die Abfrage der Pinzustände über PORTx statt PINx ist ein häufiger Fehler beim AVR-"Erstkontakt".}}<br />
<br />
Will man also die aktuellen Signalzustände von Port D abfragen und in eine Variable namens bPortD abspeichern, schreibt man folgende Befehlszeilen:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdint.h><br />
...<br />
uint8_t bPortD;<br />
...<br />
bPortD = PIND;<br />
...<br />
</syntaxhighlight><br />
<br />
Mit den C-Bitoperationen kann man den Status der Bits abfragen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
/* Fuehre Aktion aus, wenn Bit Nr. 1 (das "zweite" Bit) in PINC gesetzt (1) ist */<br />
if ( PINC & (1<<PINC1) ) {<br />
/* Aktion */<br />
}<br />
<br />
/* Fuehre Aktion aus, wenn Bit Nr. 2 (das "dritte" Bit) in PINB geloescht (0) ist */<br />
if ( !(PINB & (1<<PINB2)) ) {<br />
/* Aktion */<br />
}<br />
...<br />
</syntaxhighlight><br />
Siehe auch [[Bitmanipulation#Bits_prüfen]]<br />
<br />
=== Interne Pull-Up Widerstände ===<br />
<br />
Portpins für Ein- und Ausgänge (GPIO) eines AVR verfügen über zuschaltbare interne Pull-Up Widerstände (nominal mehrere 10kOhm, z.&nbsp;B. ATmega16 20-50kOhm). Diese können in vielen Fällen statt externer Widerstände genutzt werden.<br />
<br />
Die internen Pull-Up Widerstände von Vcc zu den einzelnen Portpins werden über das Register ''' PORTx''' aktiviert bzw. deaktiviert, wenn ein Pin als ''' Eingang''' geschaltet ist.<br />
<br />
Wird der Wert des entsprechenden Portpins auf 1 gesetzt, so ist der Pull-Up Widerstand aktiviert. Bei einem Wert von 0 ist der Pull-Up Widerstand nicht aktiv. Man sollte jeweils entweder den internen oder einen externen Pull-Up Widerstand verwenden, aber nicht beide zusammen.<br />
<br />
Im Beispiel werden alle Pins des Ports D als Eingänge geschaltet und alle Pull-Up Widerstände aktiviert. Weiterhin wird Pin PC7 als Eingang geschaltet und dessen interner Pull-Up Widerstand aktiviert, ohne die Einstellungen für die anderen Portpins (PC0-PC6) zu verändern.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
DDRD = 0x00; /* alle Pins von Port D als Eingang */<br />
PORTD = 0xff; /* interne Pull-Ups an allen Port-Pins aktivieren */<br />
...<br />
DDRC &= ~(1<<PC7); /* Pin PC7 als Eingang */<br />
PORTC |= (1<<PC7); /* internen Pull-Up an PC7 aktivieren */<br />
</syntaxhighlight><br />
<br />
=== Taster und Schalter ===<br />
<br />
Der Anschluss mechanischer Kontakte an den Mikrocontroller, ist zwischen zwei unterschiedliche Methoden zu unterscheiden: ''Active Low'' und ''Active High''.<br />
<br />
<gallery widths="300" heights="300" caption="Anschluss mechanischer Kontakte an einen µC"><br />
Image:Active Low.gif|'''Active Low:''' Bei dieser Methode wird der Kontakt zwischen den Eingangspin des Controllers und Masse geschaltet. Damit bei offenem Schalter der Controller kein undefiniertes Signal bekommt, wird zwischen die Versorgungsspannung und den Eingangspin ein sogenannter '''Pull-Up''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffnetem Schalter auf logisch 1 zu ziehen.<br />
Image:Active High.gif|'''Active High:''' Hier wird der Kontakt zwischen die Versorgungsspannung und den Eingangspin geschaltet. Damit bei offener Schalterstellung kein undefiniertes Signal am Controller ansteht, wird zwischen den Eingangspin und die Masse ein '''Pull-Down''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffneter Schalterstellung auf logisch 0 zu halten. <br />
</gallery><br />
<br />
Der Widerstandswert von Pull-Up- und Pull-Down-Widerständen ist an sich nicht kritisch. Wird er allerdings zu hoch gewählt, ist die Wirkung eventuell nicht gegeben. Als üblicher Wert haben sich 10 kOhm eingebürgert. Die AVRs verfügen an den meisten Pins über zuschaltbare interne Pull-Up Widerstände (vgl. Abschnitt [[AVR-GCC-Tutorial#Interne Pull-Up Widerstände|Interne Pull-Up Widerstände]]), welche insbesondere wie hier bei Tastern und ähnlichen Bauteilen (z.&nbsp;B. Drehgebern) statt externer Bauteile verwendet werden können. Interne Pull-Down-Widerstand sind nicht verfügbar und müssen daher in Form zusätzlicher Bauteile in die Schaltung eingefügt werden.<br />
<br />
==== Taster entprellen ====<br />
<br />
Siehe: ''[[Entprellung#Warteschleifen-Verfahren|Entprellung: Warteschleifen-Verfahren]]<br />
<br />
= Warteschleifen (delay.h) =<br />
<br />
Der Programmablauf kann verschiedene Arten von Wartefunktionen erfordern:<br />
<br />
* Warten im Sinn von Zeitvertrödeln<br />
* Warten auf einen bestimmten Zustand an den I/O-Pins<br />
* Warten auf einen bestimmten Zeitpunkt (siehe Timer)<br />
* Warten auf einen bestimmten Zählerstand (siehe Counter)<br />
<br />
Der einfachste Fall, das Zeitvertrödeln, kann in vielen Fällen und mit großer Genauigkeit anhand der avr-libc Bibliotheksfunktionen _delay_ms() und _delay_us() erledigt werden. Die Bibliotheksfunktionen sind einfachen Zählschleifen (Warteschleifen) vorzuziehen, da leere Zählschleifen ohne besondere Vorkehrungen sonst bei eingeschalteter Optimierung vom avr-gcc-Compiler wegoptimiert werden. Weiterhin sind die Bibliotheksfunktionen bereits darauf vorbereitet, die in F_CPU definierte Taktfrequenz zu verwenden. Außerdem sind die Funktionen der Bibliothek wirklich getestet.<br />
<br />
Einfach!? Schon, aber während gewartet wird, macht der µC nichts anderes mehr (abgesehen von möglicherweise auftretenden Interrupts, falls welche aktiviert sind). Die Wartefunktion blockiert den Programmablauf. Möchte man einerseits warten, um z.&nbsp;B. eine LED blinken zu lassen und gleichzeitig andere Aktionen ausführen z.&nbsp;B. weitere LED bedienen, sollten die Timer/Counter des AVR verwendet werden, siehe Artikel [[Multitasking]].<br />
<br />
Die Bibliotheksfunktionen funktionieren allerdings nur dann korrekt, wenn sie mit zur Übersetzungszeit (beim Compilieren) bekannten konstanten Werten aufgerufen werden. Der Quellcode muss mit eingeschalteter Optimierung übersetzt werden, sonst wird sehr viel Maschinencode erzeugt, und die Wartezeiten stimmen nicht mehr mit dem Parameter überein.<br />
<br />
Eine weitere Einschränkung liegt darin, daß sie möglicherweise länger warten, als erwartet, nämlich in dem Fall, daß Interrupts auftreten und die _delay...()-Funktion unterbrechen. Genau genommen warten diese nämlich nicht eine bestimmte Zeit, sondern verbrauchen eine bestimmte Anzahl von Prozessortakten. Die wiederum ist so bemessen, daß ohne Unterbrechung durch Interrupts die gewünschte Wartezeit erreicht wird.<br />
Wird das Warten aber durch eine oder mehrere ISR unterbrochen, die zusammen 1% Prozessorzeit verbrauchen, dann dauert das Warten etwa 1% länger. Bei 50% Last durch die ISR dauert das Warten doppelt solange wie gewünscht, bei 90% zehnmal solange...<br />
<br />
Abhängig von der Version der Bibliothek verhalten sich die Bibliotheksfunktionen etwas unterschiedlich.<br />
<br />
== avr-libc Versionen bis 1.6 ==<br />
<br />
Die Wartezeit der Funktion _delay_ms() ist auf 262,14ms/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 13,1ms warten. Die Wartezeit der Funktion _delay_us() ist auf 768us/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 38,4µs warten. Längere Wartezeiten müssen dann über einen mehrfachen Aufruf in einer Schleife gelöst werden.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.&nbsp;B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h> /* in älteren avr-libc Versionen <avr/delay.h> */ <br />
<br />
/*<br />
lange, variable Verzögerungszeit, Einheit in Millisekunden<br />
<br />
Die maximale Zeit pro Funktionsaufruf ist begrenzt auf <br />
262.14 ms / F_CPU in MHz (im Beispiel: <br />
262.1 / 3.6864 = max. 71 ms) <br />
<br />
Daher wird die kleine Warteschleife mehrfach aufgerufen,<br />
um auf eine längere Wartezeit zu kommen. Die zusätzliche <br />
Prüfung der Schleifenbedingung lässt die Wartezeit geringfügig<br />
ungenau werden (macht hier vielleicht 2-3ms aus).<br />
*/<br />
<br />
void long_delay(uint16_t ms)<br />
{<br />
for(; ms>0; ms--) _delay_ms(1);<br />
}<br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) // Endlosschleife<br />
{ <br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.&nbsp;B. angeschlossene LED<br />
long_delay(1000); // Eine Sekunde warten...<br />
}<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
== avr-libc Versionen ab 1.7 ==<br />
<br />
_delay_ms() kann mit einem Argument bis 6553,5 ms (= 6,5535 Sekunden) benutzt werden. Es ist nicht möglich, eine Variable als Argument zu übergeben. Wird die früher gültige Grenze von 262,14 ms/F_CPU (in MHz) überschritten, so arbeitet _delay_ms() einfach etwas ungenauer und zählt nur noch mit einer Auflösung von 1/10 ms. Eine Verzögerung von 1000,10 ms ließe sich nicht mehr von einer von 1000,19 ms unterscheiden. Ein Verlust, der sich im Allgemeinen verschmerzen lässt. Dem Programmierer wird keine Rückmeldung gegeben, dass die Funktion ggf. gröber arbeitet, d.h. wenn es darauf ankommt, bitte den Parameter wie bisher geschickt wählen.<br />
<br />
Die Funktion _delay_us() wurde ebenfalls erweitert. Wenn deren maximal als genau behandelbares Argument überschritten wird, benutzt diese intern _delay_ms(). Damit gelten in diesem Fall die _delay_ms() Einschränkungen.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus, avr-libc ab Version 1.6<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h><br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) { // Endlosschleife<br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED<br />
_delay_ms(1000); // Eine Sekunde +/-1/10000 Sekunde warten...<br />
// funktioniert nicht mit Bibliotheken vor 1.6<br />
<br />
}<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
Die _delay_ms() und die _delay_us aus '''avr-libc 1.7.0''' sind fehlerhaft. _delay_ms () läuft 4x schneller als erwartet. Abhilfe ist eine korrigierte Includedatei: [http://www.mikrocontroller.net/topic/196738#1943039]<br />
<br />
= Programmieren mit Interrupts =<br />
<br />
<div style="float:right; margin:2em;"><br />
[[Image:Interrupt Programme.gif]]<br />
</div><br />
Nachdem wir nun alles Wissenswerte für die serielle Programmerstellung<br />
gelernt haben nehmen wir jetzt ein völlig anderes Thema in Angriff, nämlich<br />
die Programmierung unter Zuhilfenahme der Interrupts des AVR.<br />
<br />
Tritt ein Interrupt auf, unterbricht (engl. interrupts) der Controller die Verarbeitung des Hauptprogramms und verzweigt zu einer Interruptroutine. Das Hauptprogramm wird also beim Eintreffen eines Interrupts unterbrochen, die Interruptroutine ausgeführt und danach erst wieder das Hauptprogramm an der Unterbrechungsstelle fortgesetzt (vgl. die Abbildung).<br />
<br />
Um Interrupts verarbeiten zu können, ist folgendes zu beachten:<br />
<br />
* Für jede aktivierte Interruptquelle ist eine Funktion zu programmieren, in der die beim Auftreten des jeweiligen Interrupts erforderlichen Verarbeitungsschritte enthalten sind. Für diese Funktion existieren verschiedene Bezeichnungen. Üblich sind die englischen Begriffe Interrupt-Handler oder Interrupt-Service-Routinen (ISR), man findet aber auch die Bezeichnungen Interruptverarbeitungs- oder -behandlungsroutine oder auch kurz Interruptroutine. Zum Beispiel wird üblicherweise in der ISR zur Verarbeitung des Empfangsinterrupts eines UARTs (UART-RX Interrupt) das empfangene Zeichen in einen Zwischenspeicher (FIFO-Buffer) kopiert, dessen Inhalt später von anderen Programmteilen geleert wird. Sofern der Zwischenspeicher ausreichend groß ist, geht also kein Zeichen verloren, auch wenn im Hauptprogramm zeitintensive Operationen durchgeführt werden.<br />
* Die benötigten Interrupts sind in den jeweiligen Funktionsbausteinen einzuschalten. Dies erfolgt über das jeweilige Aktivierungsbit (Interrupt Enable) in einem der Hardwareregister (z.B. RX(Complete)Interrupt Enable eines UARTs)<br />
* Sämtliche Interrupts werden über einen weiteren globalen Schalter aktiviert und deaktiviert. Zur Verarbeitung der Interrupts ist dieser Schalter zu aktivieren (sei(), siehe unten).<br />
<br />
Alle Punkte sind zu beachten. Fehlt z.B. die globale Aktivierung, werden Interruptroutinen auch dann nicht aufgerufen, wenn sie im Funktionsbaustein eingeschaltet sind und eine Behandlungsroutine verhanden ist.<br />
<br />
Siehe auch<br />
<br />
* [http://www.mikrocontroller.net/forum/read-1-235092.html#new Ausführlicher Thread im Forum]<br />
* Artikel [[Interrupt]]<br />
* Artikel [[Multitasking]]<br />
{{Clear}}<br />
<br />
== Anforderungen an Interrupt-Routinen ==<br />
<br />
Um unliebsamen Überraschungen vorzubeugen, sollten einige Grundregeln bei der Implementierung der Interruptroutinen beachtet werden. Interruptroutinen sollten möglichst kurz und schnell abarbeitbar sein, daraus folgt:<br />
<br />
* Keine umfangreichen Berechnungen innerhalb der Interruptroutine. (*)<br />
* Keine langen Programmschleifen.<br />
* Obwohl es möglich ist, während der Abarbeitung einer Interruptroutine andere oder sogar den gleichen Interrupt wieder zuzulassen, wird davon ohne genaue Kenntnis der internen Abläufe dringend abgeraten.<br />
<br />
Interruptroutinen (ISRs) sollten also möglichst kurz sein und keine Schleifen mit vielen Durchläufen enthalten. Längere Operationen können meist in einen "Interrupt-Teil" in einer ISR und einen "Arbeitsteil" im Hauptprogramm aufgetrennt werden. Z.B. Speichern des Zustands aller Eingänge im EEPROM in bestimmten Zeitabständen: ISR-Teil: Zeitvergleich (Timer,RTC) mit Logzeit/-intervall. Bei Übereinstimmung ein globales Flag setzen (volatile bei Flag-Deklaration nicht vergessen, s.u.). Dann im Hauptprogramm prüfen, ob das Flag gesetzt ist. Wenn ja: die Daten im EEPROM ablegen und Flag löschen.<br />
<br />
(*)<br />
Hinweis: <br />
Es gibt allerdings die seltene Situation, dass man gerade eingelesene<br />
ADC-Werte sofort verarbeiten muss. Besonders dann, wenn man mehrere Werte sehr<br />
schnell hintereinander bekommt. Dann bleibt einem nichts anderes übrig, als die<br />
Werte noch in der ISR zu verarbeiten. Kommt aber sehr selten vor und sollte<br />
durch geeignete Wahl des Systemtaktes bzw. Auswahl des Controllers vermieden werden!<br />
<br />
== Interrupt-Quellen ==<br />
<br />
Die folgenden Ereignisse können einen Interrupt auf einem AVR AT90S2313 auslösen, wobei die Reihenfolge der Auflistung auch die Priorität der Interrupts aufzeigt.<br />
<br />
* Reset<br />
* Externer Interrupt 0<br />
* Externer Interrupt 1<br />
* Timer/Counter 1 Capture Ereignis<br />
* Timer/Counter 1 Compare Match<br />
* Timer/Counter 1 Überlauf<br />
* Timer/Counter 0 Überlauf<br />
* UART Zeichen empfangen<br />
* UART Datenregister leer<br />
* UART Zeichen gesendet<br />
* Analoger Komparator<br />
<br />
Die Anzahl der möglichen Interruptquellen variiert zwischen den verschiedenen Microcontroller-Typen. Im Zweifel hilft ein Blick ins Datenblatt ("Interrupt Vectors").<br />
<br />
== Register ==<br />
<br />
Der AT90S2313 verfügt über 2 Register die mit den<br />
Interrupts zusammenhängen.<br />
<br />
{| class="wikitable"<br />
|- <br />
!width="10%"| GIMSK<br />
| '''G'''eneral '''I'''nterrupt '''M'''a'''sk''' Register.<br /><br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit <br />
| 7 || 6|| 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INT1''' || '''INT0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INT1''' (External '''Int'''errupt Request '''1''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT1'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
'''INT0''' (External '''Int'''errupt Request '''0''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT0'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
|- <br />
! GIFR<br />
| '''G'''eneral '''I'''nterrupt '''F'''lag '''R'''egister.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INTF1''' || '''INTF0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INTF1''' (External '''Int'''errupt Flag '''1''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT1'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
<br />
'''INTF0''' (External '''Int'''errupt Flag '''0''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT0'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
|- <br />
! MCUCR<br />
| '''MCU''' '''C'''ontrol '''R'''egister.<br />
<br />
Das MCU Control Register enthält Kontrollbits für allgemeine MCU-Funktionen.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''-'''|| '''-'''|| '''SE'''|| '''SM'''|| '''ISC11'''|| '''ISC10'''|| '''ISC01'''|| '''ISC00'''<br />
|- <br />
! R/W<br />
| R || R || R/W || R/W || R/W || R/W || R/W || R/W<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
<br />
|}<br />
<br />
'''SE''' ('''S'''leep '''E'''nable)<br />
:Dieses Bit muss gesetzt sein, um den Controller mit dem '''SLEEP'''-Befehl in den Schlafzustand versetzen zu können.<br />
:Um den Schlafmodus nicht irrtümlich einzuschalten, wird empfohlen, das Bit erst unmittelbar vor Ausführung des '''SLEEP'''-Befehls zu setzen.<br />
<br />
'''SM''' ('''S'''leep '''M'''ode)<br />
:Dieses Bit bestimmt über den Schlafmodus.<br />
:Ist das Bit gelöscht, so wird der '''Idle'''-Modus ausgeführt. Ist das Bit gesetzt, so wird der '''Power-Down'''-Modus ausgeführt. (für andere AVR Controller siehe Abschnitt "Sleep-Mode")<br />
<br />
'''ISC11''', '''ISC10''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''1''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT1'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
!width="10%"| ISC11 ||width="10%"| ISC10 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT1''' erzeugt einen Interrupt.<br />
<br />
Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|}<br />
<br />
'''ISC01''', '''ISC00''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''0''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT0'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
!width="10%"| ISC01 ||width="10%"| ISC00 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT0''' erzeugt einen Interrupt.<br />
<br />
Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|}<br />
<br />
|}<br />
<br />
== Allgemeines über die Interrupt-Abarbeitung ==<br />
<br />
Wenn ein Interrupt eintrifft, wird automatisch das '''Global Interrupt Enable''' Bit im Status Register '''SREG''' gelöscht und alle weiteren Interrupts unterbunden. Dieses wird automatisch wieder gesetzt, wenn die Interruptroutine beendet wird. Wenn in der Zwischenzeit weitere Interrupts eintreffen, werden die zugehörigen Interrupt-Bits gesetzt und die Interrupts bei Beendigung der laufenden Interrupt-Routine in der Reihenfolge ihrer Priorität ausgeführt. Dies kann<br />
eigentlich nur dann zu Problemen führen, wenn ein hoch priorisierter Interrupt ständig und in kurzer Folge auftritt. Dieser sperrt dann möglicherweise alle anderen Interrupts mit niedrigerer Priorität. Dies ist einer der Gründe, weshalb die Interrupt-Routinen sehr kurz gehalten werden sollen. Es ist möglich das GIE-Bit in der ISR zu setzen und so schon wieder weitere Interrupts zuzulassen - allerdings sollte man damit vorsichtig sein und genau wissen was man damit macht. Kritisch wird es vor allem wenn der gleiche Interrupt noch einmal kommt, bevor die ISR abgearbeitet ist. <br />
<br />
<!-- === Das Status-Register ===<br />
<br />
Es gilt auch zu beachten, dass das Status-Register während der Abarbeitung einer Interruptroutine nicht automatisch gesichert wird. Falls notwendig, muss dies vom Programmierer selber vorgesehen werden. --><br />
<br />
== Interrupts mit avr-gcc ==<br />
<br />
<!-- ''Anmerkung eines Nutzers: Ich habe mir das Thema hier angearbeitet und hatte am Anfang starke Probleme: Jeder Interrupt muss nochmals einzeln aktiviert werden. Es reicht nicht nur per ''sei()'' die Interrupts global zu aktiveren.'' - mthomas: Hoffentlich duch die modifizerte Einleitung etwas offensichtlicher erläutert. Ansonsten bitte per Eintrag auf die Diskussionseite nochmals melden) --> <br />
<!-- Selbstverständlich können alle interruptspezifischen Registerzugriffe wie gewohnt über I/O-Adressierung vorgenommen werden. Etwas einfacher geht es jedoch, wenn wir die vom Compiler zur Verfügung gestellten Mittel einsetzen.--><br />
Funktionen zur Interrupt-Verarbeitung werden in den Includedateien ''interrupt.h'' der avr-libc zur Verfügung gestellt (bei älterem Quellcode zusätzlich ''signal.h'').<br />
<br />
<syntaxhighlight lang="c"><br />
// fuer sei(), cli() und ISR():<br />
#include <avr/interrupt.h><br />
</syntaxhighlight><br />
<br />
Das Makro '''sei()''' schaltet die Interrupts ein. Eigentlich wird nichts anderes gemacht, als das '''Global Interrupt Enable''' Bit im Status Register gesetzt.<br />
<br />
<syntaxhighlight lang="c"><br />
sei();<br />
</syntaxhighlight><br />
<br />
Das Makro '''cli()''' schaltet die Interrupts aus, oder anders gesagt, das '''Global Interrupt Enable''' Bit im Status Register wird gelöscht.<br />
<br />
<syntaxhighlight lang="c"><br />
cli();<br />
</syntaxhighlight><br />
<br />
Oft steht man vor der Aufgabe, dass eine Codesequenz nicht unterbrochen werden darf. Es liegt dann nahe, zu Beginn dieser Sequenz ein cli() und am Ende ein sei() einzufügen. Dies ist jedoch ungünstig, wenn die Interrupts vor Aufruf der Sequenz deaktiviert waren und danach auch weiterhin deaktiviert bleiben sollen. Ein sei() würde ungeachtet des vorherigen Zustands die Interrupts aktivieren, was zu unerwünschten Seiteneffekten führen kann. Die aus dem folgenden Beispiel ersichtliche Vorgehensweise ist in solchen Fällen vorzuziehen:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <inttypes.h><br />
<br />
//...<br />
<br />
void NichtUnterbrechenBitte(void)<br />
{<br />
uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister<br />
<br />
tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) sichern<br />
cli(); // Interrupts global deaktivieren<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
/* Beispiel Anfang<br />
JTAG-Interface eines ATmega16 per Software deaktivieren <br />
und damit die JTAG-Pins an PORTC für "general I/O" nutzbar machen<br />
ohne die JTAG-Fuse-Bit zu aendern. Dazu ist eine "timed sequence"<br />
einzuhalten (vgl Datenblatt ATmega16, Stand 10/04, S. 229): <br />
Das JTD-Bit muss zweimal innerhalb von 4 Taktzyklen geschrieben <br />
werden. Ein Interrupt zwischen den beiden Schreibzugriffen wuerde <br />
die erforderliche Sequenz "brechen", das JTAG-Interface bliebe<br />
weiterhin aktiv und die IO-Pins weiterhin für JTAG reserviert. */<br />
<br />
MCUCSR |= (1<<JTD);<br />
MCUCSR |= (1<<JTD); // 2 mal in Folge ,vgl. Datenblatt fuer mehr Information<br />
<br />
/* Beispiel Ende */<br />
<br />
SREG = tmp_sreg; // Status-Register wieder herstellen <br />
// somit auch das I-Flag auf gesicherten Zustand setzen<br />
}<br />
<br />
void NichtSoGut(void)<br />
{<br />
cli();<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
sei();<br />
}<br />
<br />
<br />
int main(void)<br />
{<br />
//...<br />
<br />
cli(); <br />
// Interrupts global deaktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// auch nach Aufruf der Funktion deaktiviert<br />
<br />
sei();<br />
// Interrupts global aktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// weiterhin aktiviert<br />
//...<br />
<br />
/* Verdeutlichung der unguenstigen Vorgehensweise mit cli/sei: */<br />
cli(); <br />
// Interrupts jetzt global deaktiviert <br />
<br />
NichtSoGut();<br />
// nach Aufruf der Funktion sind Interrupts global aktiviert <br />
// dies ist mglw. ungewollt!<br />
//...<br />
<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
<!-- mt: besser so nicht(?), lieber "datenblattkonform"<br />
<br />
<font face="Courier New">'''timer_enable_int (unsigned char ints);<br /><br />
'''</font>Schaltet Timerbezogene Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle<br />
Timerinterrupts ausgeschaltet, ansonsten muss in '''ints''' angegeben werden,<br />
welche Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">timer_enable_int (1 << TOIE1));<br /><br />
</font>'''Achtung: Wenn ein Timerinterrupt eingeschaltet wird während ein<br />
anderer Timerinterrupt bereits läuft, dann müssen beide Bits angegeben werden<br />
sonst wird der andere Timerinterrupt versehentlich ausgeschaltet.<br />
<br />
<font face="Courier New">'''enable_external_int (unsigned char ints);<br /><br />
'''</font>Schaltet die externen Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle externen<br />
Interrrups ausgeschaltet, ansonsten muss in '''ints''' angegeben werden, welche<br />
Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">enable_external_int ((1<<br />
</font>'''Schaltet die externen Interrupts 0 und 1 ein.<br />
<br />
Nachdem nun die Interrupts aktiviert sind, braucht es selbstverständlich noch den auszuführenden Code, der ablaufen soll, wenn ein Interrupt eintrifft.<br />
--><br />
Zu den aktivierten Interrupts ist eine Funktion zu programmieren, deren Code aufgerufen wird, wenn der betreffende Interrupt auftritt (Interrupt-Handler, Interrupt-Service-Routine). Dazu existiert die Definition (ein Makro) '''ISR'''.<br />
<br />
=== ISR ===<br />
<br />
(''ISR()'' ersetzt bei neueren Versionen der avr-libc ''SIGNAL()''. SIGNAL sollte nicht mehr genutzt werden, zur Portierung von SIGNAL nach ISR siehe den [[AVR-GCC-Tutorial#Anhang|Anhang]].)<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
//...<br />
ISR(Vectorname) /* vormals: SIGNAL(siglabel) dabei Vectorname != siglabel ! */<br />
{<br />
/* Interrupt Code */<br />
}<br />
</syntaxhighlight><br />
<br />
Mit ''ISR'' wird eine Funktion für die Bearbeitung eines Interrupts eingeleitet. Als Argument muss dabei die Benennung des entsprechenden Interruptvektors angegeben werden. Diese sind in den jeweiligen Includedateien IOxxxx.h zu finden. Die Bezeichnung entspricht dem Namen aus dem Datenblatt, bei dem die Leerzeichen durch Unterstriche ersetzt sind und ein ''_vect'' angehängt ist.<br />
<br />
Als Beispiel ein Ausschnitt aus der Datei für den ATmega8 (bei WinAVR Standardinstallation in C:\WinAVR\avr\include\avr\iom8.h) in der neben den aktuellen Namen für ''ISR'' (*_vect) noch die Bezeichnungen für das inzwischen nicht mehr aktuelle ''SIGNAL'' (SIG_*) enthalten sind.<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
/* $Id: iom8.h,v 1.13 2005/10/30 22:11:23 joerg_wunsch Exp $ */<br />
<br />
/* avr/iom8.h - definitions for ATmega8 */<br />
//...<br />
<br />
/* Interrupt vectors */<br />
<br />
/* External Interrupt Request 0 */<br />
#define INT0_vect _VECTOR(1)<br />
#define SIG_INTERRUPT0 _VECTOR(1)<br />
<br />
/* External Interrupt Request 1 */<br />
#define INT1_vect _VECTOR(2)<br />
#define SIG_INTERRUPT1 _VECTOR(2)<br />
<br />
/* Timer/Counter2 Compare Match */<br />
#define TIMER2_COMP_vect _VECTOR(3)<br />
#define SIG_OUTPUT_COMPARE2 _VECTOR(3)<br />
<br />
/* Timer/Counter2 Overflow */<br />
#define TIMER2_OVF_vect _VECTOR(4)<br />
#define SIG_OVERFLOW2 _VECTOR(4)<br />
<br />
/* Timer/Counter1 Capture Event */<br />
#define TIMER1_CAPT_vect _VECTOR(5)<br />
#define SIG_INPUT_CAPTURE1 _VECTOR(5)<br />
<br />
/* Timer/Counter1 Compare Match A */<br />
#define TIMER1_COMPA_vect _VECTOR(6)<br />
#define SIG_OUTPUT_COMPARE1A _VECTOR(6)<br />
<br />
/* Timer/Counter1 Compare Match B */<br />
#define TIMER1_COMPB_vect _VECTOR(7)<br />
#define SIG_OUTPUT_COMPARE1B _VECTOR(7)<br />
<br />
//...<br />
</syntaxhighlight><br />
<br />
<!--Vor Nutzung von SIGNAL muss ebenfalls die Header-Datei signal.h eingebunden werden.--> <br />
Mögliche Funktionsrümpfe für Interruptfunktionen sind zum Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
/* veraltet: #include <avr/signal.h> */<br />
<br />
ISR(INT0_vect) /* veraltet: SIGNAL(SIG_INTERRUPT0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(TIMER0_OVF_vect) /* veraltet: SIGNAL(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(USART_RXC_vect) /* veraltet: SIGNAL(SIG_UART_RECV) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
// und so weiter und so fort...<br />
</syntaxhighlight><br />
<br />
Auf die korrekte Schreibweise der Vektorbezeichnung ist zu achten. Der gcc-Compiler prüft erst ab Version 4.x, ob ein Signal/Interrupt der angegebenen Bezeichnung tatsächlich in der Includedatei definiert ist und gibt andernfalls eine Warnung aus. Bei WinAVR (ab 2/2005) wurde die Überprüfung auch in den mitgelieferten Compiler der Version 3.x integriert. Aus dem gcc-Quellcode Version 3.x selbst erstellte Compiler enthalten die Prüfung nicht (vgl. [[AVR-GCC]]). <br />
<br />
Während der Ausführung der Funktion sind alle weiteren Interrupts automatisch gesperrt. Beim Verlassen der Funktion werden die Interrupts wieder zugelassen.<br />
<br />
Sollte während der Abarbeitung der Interruptroutine ein weiterer Interrupt (gleiche oder andere Interruptquelle) auftreten, so wird das entsprechende Bit im zugeordneten Interrupt Flag Register gesetzt und die entsprechende Interruptroutine automatisch nach dem Beenden der aktuellen Funktion aufgerufen.<br />
<br />
Ein Problem ergibt sich eigentlich nur dann, wenn während der Abarbeitung der aktuellen Interruptroutine mehrere gleichartige Interrupts auftreten. Die entsprechende Interruptroutine wird im Nachhinein zwar aufgerufen jedoch wissen wir nicht, ob nun der entsprechende Interrupt einmal, zweimal oder gar noch öfter aufgetreten ist. Deshalb soll hier noch einmal betont werden, dass Interruptroutinen so schnell wie nur irgend möglich wieder verlassen werden sollten.<br />
<br />
=== Unterbrechbare Interruptroutinen ===<br />
<br />
"Faustregel": im Zweifel '''ISR'''. Die nachfolgend beschriebene Methode nur dann verwenden, wenn man sich über die unterschiedliche Funktionsweise im Klaren ist.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
<br />
ISR(XXX,ISR_NOBLOCK) /* veraltet: INTERRUPT(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt-Code */<br />
}<br />
</syntaxhighlight><br />
<br />
Hierbei steht XXX für den oben beschriebenen Namen des Vektors (also z.&nbsp;B. ''TIMER0_OVF_vect''). Der Unterschied im Vergleich zu einer herkömmlichen ISR ist, dass hier beim Aufrufen der Funktion das '''Global Enable Interrupt''' Bit durch Einfügen einer SEI-Anweisung direkt wieder gesetzt und somit alle Interrupts zugelassen werden &ndash; auch XXX-Interrupts. <br />
<br />
Bei unsachgemässer Handhabung kann dies zu erheblichen Problemen durch Rekursion wie einem Stack-Overflow oder anderen unerwarteten Effekten führen und sollte wirklich nur dann eingesetzt werden, wenn man sich sicher ist, das Ganze auch im Griff zu haben.<br />
<br />
Insbesondere sollte möglichst am ISR-Anfang die auslösende IRQ-Quelle deaktiviert und erst am Ende der ISR wieder aktiviert werden. Robuster als die Verwendung einer NOBLOCK-ISR ist daher folgender ISR-Aufbau:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
<br />
ISR (XXX) <br />
{<br />
// Implementiere die ISR ohne zunaechst weitere IRQs zuzulassen<br />
<br />
<<Deaktiviere die XXX-IRQ>><br />
<br />
// Erlaube alle Interrupts (ausser XXX)<br />
sei();<br />
<br />
//... Code ...<br />
<br />
// IRQs global deaktivieren um die XXX-IRQ wieder gefahrlos <br />
// aktivieren zu koennen<br />
cli();<br />
<br />
<<Aktiviere die XXX-IRQ>><br />
}<br />
</syntaxhighlight><br />
Auf diese Weise kann sich die XXX-IRQ nicht selbst unterbrechen, was zu einer Art Endlosschleife führen würde.<br />
<br />
Siehe auch: Hinweise in [[AVR-GCC]]<br />
<br />
siehe dazu: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html<br />
<br />
== Datenaustausch mit Interrupt-Routinen ==<br />
<br />
Variablen, die sowohl in Interrupt-Routinen (ISR = Interrupt Service Routine(s)) als auch vom übrigen Programmcode geschrieben oder gelesen werden, müssen mit einem '''volatile''' deklariert werden. Damit wird dem Compiler mitgeteilt, dass der Inhalt der Variablen vor jedem Lesezugriff aus dem Speicher gelesen und nach jedem Schreibzugriff in den Speicher geschrieben wird. Ansonsten könnte der Compiler den Code so optimieren, dass der Wert der Variablen nur in Prozessorregistern zwischengespeichert wird, die nichts von der Änderung woanders mitbekommen.<br />
<br />
Zur Veranschaulichung ein Codefragment für eine Tastenentprellung mit Erkennung einer "lange gedrückten" Taste.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <stdint.h><br />
//...<br />
<br />
// Schwellwerte<br />
// Entprellung: <br />
#define CNTDEBOUNCE 10<br />
// "lange gedrueckt:"<br />
#define CNTREPEAT 200<br />
<br />
// hier z.&nbsp;B. Taste an Pin2 PortA "active low" = 0 wenn gedrueckt<br />
#define KEY_PIN PINA<br />
#define KEY_PINNO PA2<br />
<br />
// beachte: volatile! <br />
volatile uint8_t gKeyCounter;<br />
<br />
// Timer-Compare Interrupt ISR, wird z.B. alle 10ms ausgefuehrt<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
// hier wird gKeyCounter veraendert. Die übrigen<br />
// Programmteile müssen diese Aenderung "sehen":<br />
// volatile -> aktuellen Wert immer in den Speicher schreiben<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
}<br />
else {<br />
gKeyCounter = 0;<br />
}<br />
}<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
//...<br />
/* hier: Initialisierung der Ports und des Timer-Interrupts */<br />
//... <br />
// hier wird auf gKeyCounter zugegriffen. Dazu muss der in der<br />
// ISR geschriebene Wert bekannt sein:<br />
// volatile -> aktuellen Wert immer aus dem Speicher lesen<br />
if ( gKeyCounter > CNTDEBOUNCE ) { // Taste mind. 10*10 ms "prellfrei"<br />
if (gKeyCounter == CNTREPEAT) {<br />
/* hier: Code fuer "Taste lange gedrueckt" */<br />
}<br />
else {<br />
/* hier: Code fuer "Taste kurz gedrueckt" */<br />
}<br />
}<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Wird innerhalb einer ISR mehrfach auf eine mit volatile deklarierte Variable zugegriffen, wirkt sich dies ungünstig auf die Verarbeitungsgeschwindigkeit aus, da bei jedem Zugriff mit dem Speicherinhalt abgeglichen wird. Da bei AVR-Controllern ''innerhalb'' einer ISR keine Unterbrechungen zu erwarten sind, bietet es sich an, einen Zwischenspeicher in Form einer lokalen Variable zu verwenden, deren Inhalt zu Beginn und am Ende mit dem der volatile Variable synchronisiert wird. Lokale Variable werden bei eingeschalteter Optimierung mit hoher Wahrscheinlichkeit in Prozessorregistern verwaltet und der Zugriff darauf ist daher nur mit wenigen internen Operationen verbunden. Die ISR aus dem vorherigen Beispiel lässt sich so optimieren:<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter; // Uebernahme in lokale Arbeitsvariable<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (tmp_kc < CNTREPEAT) {<br />
tmp_kc++;<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc; // Zurueckschreiben<br />
}<br />
//...<br />
</syntaxhighlight><br />
<br />
Zum Vergleich die Disassemblies (Ausschnitte der "lss-Dateien", compiliert für ATmega162) im Anschluss. Man erkennt den viermaligen Zugriff auf die Speicheraddresse von ''gKeyCounter'' (hier 0x032A) in der ISR ohne "Cache"-Variable und den zweimaligen Zugriff in der Variante mit Zwischenspeicher. Im Beispiel ist der Vorteil gering, bei komplexeren Routinen kann die Zwischenspeicherung in lokalen Variablen jedoch zu deutlicheren Verbesserungen führen.<br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
876: ca 99 sbic 0x19, 2 ; 25<br />
878: 0a c0 rjmp .+20 ; 0x88e <__vector_13+0x24><br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
87a: 80 91 2a 03 lds r24, 0x032A<br />
87e: 88 3c cpi r24, 0xC8 ; 200 <br />
880: 40 f4 brcc .+16 ; 0x892 <__vector_13+0x28><br />
882: 80 91 2a 03 lds r24, 0x032A<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 02 c0 rjmp .+4 ; 0x892 <__vector_13+0x28><br />
}<br />
else {<br />
gKeyCounter = 0;<br />
88e: 10 92 2a 03 sts 0x032A, r1<br />
892: 8f 91 pop r24<br />
894: 0f 90 pop r0<br />
896: 0f be out 0x3f, r0 ; 63<br />
898: 0f 90 pop r0<br />
89a: 1f 90 pop r1<br />
89c: 18 95 reti<br />
</pre><br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter;<br />
876: 80 91 2a 03 lds r24, 0x032A<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
87a: ca 9b sbis 0x19, 2 ; 25<br />
87c: 02 c0 rjmp .+4 ; 0x882 <__vector_13+0x18><br />
87e: 80 e0 ldi r24, 0x00 ; 0<br />
880: 03 c0 rjmp .+6 ; 0x888 <__vector_13+0x1e><br />
if (tmp_kc < CNTREPEAT) {<br />
882: 88 3c cpi r24, 0xC8 ; 200<br />
884: 08 f4 brcc .+2 ; 0x888 <__vector_13+0x1e><br />
tmp_kc++;<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc;<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 8f 91 pop r24<br />
88e: 0f 90 pop r0<br />
890: 0f be out 0x3f, r0 ; 63<br />
892: 0f 90 pop r0<br />
894: 1f 90 pop r1<br />
896: 18 95 reti<br />
</pre><br />
<br />
=== volatile und Pointer ===<br />
<br />
Bei '''volatile''' in Verbindung mit Pointern ist zu beachten, ob der Pointer selbst oder die Variable, auf die der Pointer zeigt, '''volatile''' ist.<br />
<br />
<syntaxhighlight lang="c"><br />
volatile uint8_t *a; // das Ziel von a ist volatile<br />
<br />
uint8_t *volatile a; // a selbst ist volatile<br />
</syntaxhighlight><br />
<br />
Falls der Pointer volatile ist (zweiter Fall im Beispiel), ist zu beachten, dass der Wert des Pointers, also eine Speicheradresse, intern in mehr als einem Byte verwaltet wird. Lese- und Schreibzugriffe im Hauptprogramm (außerhalb von Interrupt-Routinen) sind daher so zu implementieren, dass alle Teilbytes der Adresse konsistent bleiben, vgl. dazu den folgenden Abschnitt.<br />
<br />
=== Variablen größer 1 Byte ===<br />
<br />
Bei Variablen größer ein Byte, auf die in Interrupt-Routinen und im Hauptprogramm zugegriffen wird, muss darauf geachtet werden, dass die Zugriffe auf die einzelnen Bytes außerhalb der ISR nicht durch einen Interrupt unterbrochen werden. (Allgemeinplatz: AVRs sind 8-bit Controller). Zur Veranschaulichung ein Codefragment:<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
volatile uint16_t gMyCounter16bit;<br />
//...<br />
ISR(...)<br />
{<br />
//...<br />
gMyCounter16Bit++;<br />
//...<br />
}<br />
<br />
int main(void)<br />
{<br />
uint16_t tmpCnt;<br />
//...<br />
// nicht gut: Mglw. hier ein Fehler, wenn ein Byte von MyCounter <br />
// schon in tmpCnt kopiert ist aber vor dem Kopieren des zweiten Bytes <br />
// ein Interrupt auftritt, der den Inhalt von MyCounter verändert.<br />
tmpCnt = gMyCounter16bit; <br />
<br />
<br />
// besser: Änderungen "außerhalb" verhindern -> alle "Teilbytes"<br />
// bleiben konsistent<br />
cli(); // Interrupts deaktivieren<br />
tmpCnt = gMyCounter16Bit;<br />
sei(); // wieder aktivieren<br />
<br />
// oder: vorheriger Status des globalen Interrupt-Flags bleibt erhalten<br />
uint8_t sreg_tmp;<br />
sreg_tmp = SREG; /* Sichern */<br />
cli()<br />
tmpCnt = gMyCounter16Bit;<br />
SREG = sreg_tmp; /* Wiederherstellen */<br />
<br />
// oder: mehrfach lesen, bis man konsistente Daten hat<br />
uint16_t count1 = gMyCounter16Bit;<br />
uint16_t count2 = gMyCounter16Bit;<br />
while (count1 != count2) {<br />
count1 = count2;<br />
count2 = gMyCounter16Bit;<br />
}<br />
tmpCnt = count1;<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Die avr-libc bietet ab Version 1.6.0(?) einige Hilfsfunktionen/Makros, mit der im Beispiel oben gezeigten Funktionalität, die zusätzlich auch sogenannte [http://en.wikipedia.org/wiki/Memory_barrier memory barriers] beinhalten. Diese stehen nach #include <util/atomic.h> zur Verfügung.<br />
<syntaxhighlight lang="c"><br />
//...<br />
#include <util/atomic.h><br />
//...<br />
<br />
// analog zu cli, Zugriff, sei:<br />
ATOMIC_BLOCK(ATOMIC_FORCEON) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
// oder:<br />
<br />
// analog zu Sicherung des SREG, cli, Zugriff und Zurückschreiben des SREG:<br />
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
//...<br />
</syntaxhighlight><br />
<br />
* siehe auch [http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Dokumentation der avr-libc zu atomic.h]<br />
<br />
== Interrupt-Routinen und Registerzugriffe ==<br />
<br />
Falls Register sowohl im Hauptprogramm als auch in Interrupt-Routinen verändert werden, ist darauf zu achten, dass diese Zugriffe sich nicht überlappen. Nur wenige Anweisungen lassen sich in sogenannte "atomare" Zugriffe übersetzen, die nicht von Interrupt-Routinen unterbrochen werden können. <br />
<br />
Zur Veranschaulichung eine Anweisung, bei der ein Bit und im Anschluss drei Bits in einem Register gesetzt werden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
int main(void)<br />
{<br />
//...<br />
PORTA |= (1<<PA0);<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Der Compiler übersetzt diese Anweisungen für einen ATmega128 bei Optimierungsstufe "S" nach:<br />
<br />
<div class="code"><pre><br />
...<br />
PORTA |= (1<<PA0);<br />
d2: d8 9a sbi 0x1b, 0 ; 27 (a)<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
d4: 8b b3 in r24, 0x1b ; 27 (b)<br />
d6: 8c 61 ori r24, 0x1C ; 28 (c)<br />
d8: 8b bb out 0x1b, r24 ; 27 (d)<br />
...<br />
</pre></div><br />
<br />
Das Setzen des einzelnen Bits wird bei eingeschalteter Optimierung für Register im unteren Speicherbereich in eine einzige Assembler-Anweisung (sbi) übersetzt und ist nicht anfällig für Unterbrechungen durch Interrupts. Die Anweisung zum Setzen von drei Bits wird jedoch in drei abhängige Assembler-Anweisungen übersetzt und bietet damit zwei "Angriffspunkte" für Unterbrechungen. Eine Interrupt-Routine könnte nach dem Laden des Ausgangszustands in den Zwischenspeicher (hier Register 24) den Wert des Registers ändern, z.&nbsp;B. ein Bit löschen. Damit würde der Zwischenspeicher nicht mehr mit dem tatsächlichen Zustand übereinstimmen aber dennoch nach der Bitoperation (hier ori) in das Register zurückgeschrieben. <br />
<br />
Beispiel: PORTA sei anfangs 0b00000000. Die erste Anweisung (a) setzt Bit 0 auf '''1''', PORTA ist danach 0b0000000'''1'''. Nun wird im ersten Teil der zweiten Anweisung der Portzustand in ein Register eingelesen (b). Unmittelbar darauf (vor (c)) "feuert" ein Interrupt, in dessen Interrupt-Routine Bit 0 von PORTA gelöscht wird. Nach Verlassen der Interrupt-Routine hat PORTA den Wert 0b00000000. In den beiden noch folgenden Anweisungen des Hauptprogramms wird nun der zwischengespeicherte "alte" Zustand 0b00000001 mit 0b00011100 logisch-'''ODER'''-verknüft (c) und das Ergebnis 0b00011101 in PortA geschrieben (d). Obwohl zwischenzeitlich Bit 0 gelöscht wurde, ist es nach (d) wieder gesetzt. <br />
<br />
Lösungsmöglichkeiten:<br />
* Register ohne besondere Vorkehrungen nicht in Interruptroutinen ''und'' im Hauptprogramm verändern.<br />
* Interrupts vor Veränderungen in Registern, die auch in ISRs verändert werden, deaktivieren ("cli").<br />
* Bits einzeln löschen oder setzen. sbi und cbi können nicht unterbrochen werden. Vorsicht: nur Register im unteren Speicherbereich sind mittels sbi/cbi ansprechbar. Der Compiler kann nur für diese sbi/cbi-Anweisungen generieren. Für Register außerhalb dieses Adressbereichs ("Memory-Mapped"-Register) werden auch zur Manipulation einzelner Bits abhängige Anweisungen erzeugt (lds,...,sts).<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Frequently asked Questions/Fragen Nr. 1 und 8. (Stand: avr-libc Vers. 1.0.4)<br />
<br />
== Interruptflags löschen ==<br />
<br />
Beim Löschen von Interruptflags haben AVRs eine Besonderheit, die auch im Datenblatt beschrieben ist: Es wird zum Löschen eine 1 in das betreffende Bit geschrieben. <br />
<br />
Hinweis:<br /><br />
Bei Registern mit mehreren Interrupt-Flag-Bits (wie die Timer Interrupt Flag Register) '''nicht''' die übliche bitweise VerODERung nehmen, sondern eine direkte Zuweisung machen. Da sonst weitere Flags, als nur das gewünschte, ebenfalls gelöscht werden könnten.<br /><br />
([http://www.mikrocontroller.net/topic/171148#1640133 Erklärung]).<br />
<br />
== Was macht das Hauptprogramm? ==<br />
<br />
Im einfachsten (Ausnahme-)Fall gar nichts mehr. Es ist also durchaus denkbar, ein Programm zu schreiben, welches in der main-Funktion lediglich noch die Interrupts aktiviert und dann in einer Endlosschleife verharrt. Sämtliche Funktionen werden dann in den ISRs abgearbeitet. Diese Vorgehensweise ist jedoch bei den <i>meisten</i> Anwendungen schlecht: man verschenkt eine Verarbeitungsebene und hat außerdem möglicherweise Probleme durch Interruptroutinen, die zu viel Verarbeitungszeit benötigen.<br />
<br />
Für <i>wenige</i> Anwendungen ist diese Vorgehensweise jedoch perfekt: Die Hauptschleife verkommt zu <tt>for(;;) sleep_cpu();</tt> — siehe nächster Abschnitt „Sleep“. Weiterer Vorteil: ISRs brauchen keine(!) Register retten, ein Fall für <tt>ISR(<i>name</i>,ISR_NAKED){ … reti();}</tt>. <i>So</i> können Mikrocontroller für batteriebetriebene Geräte, etwa Fernbedienungen, maximal Energie sparen.<br />
<br />
Normalerweise wird man in den Interruptroutinen nur die bei Auftreten des jeweiligen Interruptereignisses unbedingt notwendigen Operationen ausführen lassen. Alle weniger kritischen Aufgaben werden dann im Hauptprogramm abgearbeitet.<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Interrupts and Signals<br />
<br />
= Sleep-Modes =<br />
<br />
AVR Controller verfügen über eine Reihe von sogenannten [[Sleep Mode |''Sleep-Modes'']] ("Schlaf-Modi"). Diese ermöglichen es, Teile des Controllers abzuschalten. Zum Einen kann damit besonders bei Batteriebetrieb Strom gespart werden, zum Anderen können Komponenten des Controllers deaktiviert werden, die die Genauigkeit des Analog-Digital-Wandlers bzw. des Analog-Comparators negativ beeinflussen. Der Controller wird durch Interrupts aus dem Schlaf geweckt. Welche Interrupts den jeweiligen Schlafmodus beenden, ist einer Tabelle im Datenblatt des jeweiligen Controllers zu entnehmen.<br />
Die Funktionen (eigentlich Makros) der avr-libc stehen nach Einbinden der header-Datei ''sleep.h'' zur Verfügung.<br />
<br />
;set_sleep_mode (uint8_t mode): Setzt den Schlafmodus, der bei Aufruf von sleep() aktiviert wird. In sleep.h sind einige Konstanten definiert (z.&nbsp;B. SLEEP_MODE_PWR_DOWN). Die definierten Modi werden jedoch nicht alle von sämtlichten AVR-Controllern unterstützt.<br />
;sleep_enable(): Aktiviert den gesetzten Schlafmodus, versetzt den Controller aber noch nicht in den Schlafmodus<br />
;sleep_cpu(): Versetzt den Controller in den Schlafmodus .sleep_cpu wird im Prinzip durch die Assembler-Anweisung ''sleep'' ersetzt.<br />
;sleep_disable(): Deaktiviert den gesetzten Schlafmodus<br />
;sleep_mode(): Versetzt den Controller in den mit set_sleep_mode gewählten Schlafmodus. Das Makro entspricht sleep_enable()+sleep_cpu()+sleep_disable(), beinhaltet also nicht die Aktivierung von Interrupts (besser nicht benutzen).<br />
<br />
Bei Anwendung von sleep_cpu() müssen Interrupts also bereits freigeben sein (sei()), da der Controller sonst nicht mehr "aufwachen" kann. sleep_mode() ist nicht geeignet für die Verwendung in ISR Interrupt-Service-Routinen, da bei deren Abarbeitung Interrupts global deaktiviert sind und somit auch die möglichen "Aufwachinterrupts". Abhilfe: stattdessen sleep_enable(), sei(), sleep_cpu(), sleep_disable() und evtl. cli() verwenden (vgl. Dokumentation der avr-libc).<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/sleep.h><br />
<br />
int main(void)<br />
{<br />
...<br />
<br />
while (1) {<br />
...<br />
set_sleep_mode(SLEEP_MODE_PWR_DOWN);<br />
sleep_mode();<br />
<br />
// Code hier wird erst nach Auftreten eines entsprechenden<br />
// "Aufwach-Interrupts" verarbeitet<br />
...<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
In älteren Versionenen der avr-libc wurden nicht alle AVR-Controller durch die sleep-Funktionen richtig angesteuert. Mit avr-libc 1.2.0 wurde die Anzahl der unterstützten Typen jedoch deutlich erweitert. Bei nicht-unterstützten Typen erreicht man die gewünschte Funktionalität durch direkte "[[Bitmanipulation]]" der entsprechenden Register (vgl. Datenblatt) und Aufruf des Sleep-Befehls via Inline-Assembler oder sleep_cpu():<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
// Sleep-Mode "Power-Save" beim ATmega169 "manuell" aktivieren<br />
SMCR = (3<<SM0) | (1<<SE);<br />
asm volatile ("sleep"::); // alternativ sleep_cpu() aus sleep.h<br />
...<br />
</syntaxhighlight><br />
<br />
== Sleep-Modi ==<br />
Die vielen Prozessoren aus der AVR-Familie unterstützen unterschiedliche Sleep-Modi, gefächert nach Vorhandensein von Funktionsblöcken im Controller. Konkrete und verläßliche Auskunft über die tatsächlichen Gegebenheiten finden sich wie immer in den jeweiligen Datenblättern. Die Modi unterscheiden sich darin, welche Funktionsbereiche zum Energiesparen abgeschaltet werden. Davon hängt auch ab, mit welchen Mitteln der Prozessor aus der jeweiligen Schlaftiefe wieder aufgeweckt werden kann.<br />
<br />
;Idle Mode (SLEEP_MODE_IDLE): Die CPU kann durch SPI, USART, Analog Comperator, ADC, TWI, Timer, Watchdog und irgendeinen anderen Interrupt wieder aufgeweckt werden.<br />
<br />
;ADC Noise Reduction Mode (SLEEP_MODE_ADC): In diesem Modus liegt das Hauptaugenmerk darauf, die CPU soweit stillzulegen, dass der ADC möglichst keine Störungen aus dem inneren der CPU auffangen kann, die das Meßergebnis negativ beeinflussen können. Das Aufwachen aus diesem Modus kann ausgelöst werden durch den ADC, externe Interrupts, TWI, Timer und Watchdog.<br />
<br />
;Power-Down Mode (SLEEP_MODE_PWR_DOWN): In diesem Modus wird ein externer Oszillator (Quarz, Quarzoszillator), wenn vorhanden. gestoppt. Geweckt werden kann die CPU durch einen externen Level-Interrupt, TWI, Watchdog, Brown-Out-Reset.<br />
<br />
;Power-Save-Mode (SLEEP_MODE_PWR_SAVE): Power-Save ist identisch zu Power-Down mit einer Ausnahme: Ist der Timer 2 auf die Verwendung eines externen Taktes konfiguriert, so läuft dieser Timer auch im Power-Save weiter und kann die CPU mit einem Interrupt aufwecken.<br />
<br />
;Standby-Mode (SLEEP_MODE_STANDBY, SLEEP_MODE_EXT_STANDBY): Voraussetzung für den Standby-Modus ist die Verwendung eines Quarzes oder eines Quarzoszillators, also einer externen Taktquelle. Ansonsten ist dieser Modus identisch zum Power-Down Modus. Vorteil dieses Modus' ist eine kürzere Aufwachzeit.<br />
<br />
;Abschalten des Brownout Detect (BOD) während der Sleep-Phase (nur P-Typen): Zur Stromersparnis bieten die P-Typen die Möglichkeit den BOD während der Sleep-Phase abzuschalten. Bei einem Atmega88PA beispielsweise, kann dadurch der Stromverbrauch im SLEEP_MODE_PWR_SAVE mit Timer2 im Asynchronmodus mit Uhrenquarz und periodischer Selbstaufweckung um ca. 50% gesenkt werden.<br />
Das Einschalten dieser Funktion geschieht in einer Timed Sequence.<br />
<br />
<syntaxhighlight lang="c"><br />
unsigned char temp0 = MCUCR;<br />
unsigned char temp1 = MCUCR;<br />
temp0 |= (1 << BODS) | (1 << BODSE);<br />
temp1 |= (1 << BODS);<br />
MCUCR = temp0;<br />
MCUCR = temp1;<br />
sleep_cpu();<br />
</syntaxhighlight><br />
<br />
Hierbei ist unbedingt zu beachten, dass das BODS-Bit 3 Takte nach dem Setzen wieder gelöscht wird. Daher muss der Aufruf des Sleep unmittelbar nach dem Setzen erfolgen und das BODS-Bit muss jedes Mal vor einem Sleep Aufruf erneut gesetzt werden.<br />
<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Power Management and Sleep-Modes<br />
* [http://www.mikrocontroller.net/topic/96369#832712 Forenbeitrag] zur "Nichtverwendung" von sleep_mode in ISRs.<br />
<br />
= Zeiger =<br />
Zeiger (engl. ''Pointer'') sind Variablen, die die Adresse von Daten oder Funktionen enthalten und belegen 16 Bits. Die Größe hängt mit dem adressierbaren Speicherbereich zusammen und der GCC reserviert dann den entsprechenden Platz.<br />
Ggf. ist es also günstiger, Indizes auf Arrays (Listen) zu verwenden, so dass der GCC für die Zeigerarithmetik den erforderlichen RAM nur temporär benötigt.<br />
<br />
Siehe auch: [[Zeiger]]<br />
<br />
= Speicherzugriffe =<br />
<br />
Atmel AVR-Controller verfügen typisch über drei Speicher:<br />
<br />
* [[RAM]]: Im RAM (genauer statisches RAM/SRAM) wird vom gcc-Compiler Platz für Variablen reserviert. Auch der Stack befindet sich im RAM. Dieser Speicher ist "flüchtig", d.h. der Inhalt der Variablen geht beim Ausschalten oder einem Zusammenbruch der Spannungsversorgung verloren. Das bedeutet im Umkehrschluss auch, dass der RAM-Inhalt nach RESET vom Pin oder vom Watchdog erhalten bleibt! Der C-Startupcode löscht jedoch den RAM, d.h. setzt alle Bits auf 0. Dadurch erscheinen „normal definierte“ Variablen als 0. Auch Gleitkommazahlen, die schlauerweise so definiert sind, dass eine +0.0 aus lauter Nullbits besteht. Von der Löschung ausschließen kann man RAM-Variablen mit <tt>__attribute__((section(".noinit")))</tt>.<br />
<br />
* Programmspeicher: Ausgeführt als FLASH-Speicher, seitenweise wiederbeschreibbar. Darin ist das Anwendungsprogramm abgelegt.<br />
<br />
* [[EEPROM]]: Nichtflüchtiger Speicher, d.h. der einmal geschriebene Inhalt bleibt auch ohne Stromversorgung erhalten. Byte-weise schreib/lesbar. Im EEPROM werden typischerweise gerätespezifische Werte wie z.&nbsp;B. Kalibrierungswerte von Sensoren abgelegt.<br />
<br />
Einige AVRs besitzen keinen RAM-Speicher, lediglich die Register können als "Arbeitsvariablen"<br />
genutzt werden. Da die Anwendung des avr-gcc auf solch "kleinen" Controllern ohnehin selten sinnvoll ist und auch nur bei einigen RAM-losen Typen nach [http://lightner.net/avr/ATtinyAvrGcc.html "Bastelarbeiten"] möglich ist, werden diese Controller hier nicht weiter berücksichtigt. Auch EEPROM-Speicher ist nicht auf allen Typen verfügbar. Generell sollten die nachfolgenden Erläuterungen auf alle ATmega-Controller und die größeren AT90-Typen übertragbar sein. Für die Typen ATtiny2313, ATtiny26 und viele weitere der "ATtiny-Reihe" gelten die Ausführungen ebenfalls.<br />
<br />
Siehe auch:<br />
* [[Binäre Daten zum Programm hinzufügen]]<br />
== RAM ==<br />
<br />
Die Verwaltung des RAM-Speichers erfolgt durch den Compiler, im Regelfall ist beim Zugriff auf Variablen im RAM nichts Besonderes zu beachten. Die Erläuterungen in jedem brauchbaren C-Buch gelten auch für den vom avr-gcc-Compiler erzeugten Code.<br />
<br />
Um Speicher dynamisch (während der Laufzeit) zu reservieren, kann '''malloc()''' verwendet werden. malloc(size) "alloziert" (~reserviert) einen gewissen Speicherblock mit '''size''' Bytes. Ist kein Platz für den neuen Block, wird NULL (0) zurückgegeben.<br />
<br />
Wird der angelegte Block zu klein (groß), kann die Größe mit realloc() verändert werden. Den allozierten Speicherbereich kann man mit free() wieder freigeben. Wenn das Freigeben eines Blocks vergessen wird spricht man von einem "Speicherleck" (memory leak).<br />
<br />
malloc() legt Speicherblöcke im '''Heap''' an, belegt man zuviel Platz, dann wächst der Heap zu weit nach oben und überschreibt den Stack, und der Controller kommt in Teufels Küche. Das kann leider nicht nur passieren wenn man insgesamt zu viel Speicher anfordert, sondern auch wenn man Blöcke unterschiedlicher Größe in ungünstiger Reihenfolge alloziert/freigibt (siehe Artikel [[Heap-Fragmentierung]]). Aus diesem Grund sollte man malloc() auf Mikrocontrollern sehr sparsam (am besten gar nicht) verwenden.<br />
<br />
Beispiel zur Verwendung von malloc():<br />
<syntaxhighlight lang="c"><br />
#include <stdlib.h><br />
<br />
void foo(void) {<br />
// neuen speicherbereich anlegen,<br />
// platz für 10 uint16<br />
uint16_t* pBuffer = malloc(10 * sizeof(uint16_t));<br />
<br />
// darauf zugreifen, als wärs ein gewohnter Buffer<br />
pBuffer[2] = 5;<br />
<br />
// Speicher (unbedingt!) wieder freigeben<br />
free(pBuffer);<br />
}<br />
</syntaxhighlight><br />
<br />
Wenn (wie in obigem Beispiel) dynamischer Speicher nur für die Dauer einer Funktion benötigt und am Ende wieder freigegeben wird, bietet es sich an, statt malloc() '''alloca()''' zu verwenden. Der Unterschied zu malloc() ist, dass der Speicher auf dem Stack reserviert wird, und beim Verlassen der Funktion automatisch wieder freigegeben wird. Es kann somit kein Speicherleck und keine Fragmentierung entstehen.<br />
<br />
siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/malloc.html AVR Libc Home Page]: Memory Areas and Using malloc()<br />
* [https://www.mikrocontroller.net/topic/479027#5934443 Forumsbeitrag]: RAM Verbrauch auch von lokalen variablen ermitteln<br />
<br />
== Flash mit PROGMEM und pgm_read ==<br />
<br />
→ [http://nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html avr-libc: Doku zu avr/pgmspace.h]<br />
<br />
Ein Zugriff auf Konstanten im Programmspeicher ist mittels avr-gcc erst ab Version 4.7 "transparent" möglich. Um Daten aus dem Flash zu lesen, muss die AVR-Instruktion LPM (''Load from Program Memory'') erzeugt werden, bei Controllern mit mehr als 64kiB Flash auch ELPM.<br />
<br />
Dazu gibt es das AVR-spezifische GCC-Attribut <tt>progmem</tt>, mit dem eine Variablendeklaration im ''static storage''<ref>Variablen der Speicherklasse ''static storage'' haben eine unbegrenzte Lebensdauer. Beispiel für solche Variablen sind globale Variablen, aber auch static-Variablen innerhalb einer Funktion gehören dazu. Beispiele für Variablen, die nicht ''static storage'' sind: auto-Variablen ("normale" lokale Variablen), register-Variablen, durch malloc geschaffene Objekte, etc.</ref> markiert werden kann:<br />
<syntaxhighlight lang="c"><br />
const int value __attribute__((progmem)) = 1;<br />
</syntaxhighlight><br />
<br />
Effekt ist, dass die so markierte Variable nicht im RAM sondern im Flash angelegt wird. Wird durch "normalen" C-Code auf solch eine Variable zugegriffen, wird jedoch aus der gleichen Adresse aus dem RAM gelesen und nicht aus dem Flash! Das ist ein Fehler, den der Compiler aber nicht anzeigt!<br />
<br />
<syntaxhighlight lang="c"><br />
int test = value; // Fehler! PROGMEM Konstanten müssen mit den pgm_read-Funktionen gelesen werden!<br />
</syntaxhighlight><br />
<br />
Zum Lesen aus dem Flash stellt die avr-libc daher zahlreiche Makros zur Verfügung. Zudem wird das Makro <tt>PROGMEM</tt> definiert, das etwas Tipparbeit spart:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
const int value PROGMEM = 1;<br />
</syntaxhighlight><br />
<br />
<tt>progmem</tt> funktioniert im Wesentlichen wie ein Section-Attribut, das die Daten in der Section <tt>.progmem.data</tt> ablegt. Im Gegensatz zum Section-Attribut werden jedoch noch weitere Prüfungen unternommen, ab avr-gcc 4.6 etwa muss die entsprechende Variable <tt>const</tt> sein.<br />
<br />
=== Integer und float ===<br />
<br />
Zum Lesen von Skalaren stellt die avr-libc folgende Makros zu Verfügung, die jeweils ein Argument erhalten: Die 16-Bit Adresse des zu lesenden Wertes<ref>Damit ist der mögliche Speicherbereich für Flash-Konstanten auf 64kiB begrenzt. Einige pgmspace-Funktionen ermöglichen den Lesezugriff auf den gesamten Flash-Speicher, intern via Assembler-Anweisung ELPM. Die Initialisierungswerte des Speicherinhalts jenseits der 64kiB-Marke müssen dann jedoch auf anderem Weg angelegt werden, d.h. nicht per PROGMEM. Evtl. eigene Section und Linker-Optionen. Alt und nicht ganz korrekt: Die avr-libc pgmspace-Funktionen unterstützen nur die unteren 64kiB Flash bei Controllern mit mehr als 64kiB.</ref><br />
<br />
:{| {{Tabelle}}<br />
|+ Übersicht der <tt>pgm_read</tt> Funktionen aus<br/>dem Header <tt>avr/pgmspace.h</tt> der avr-libc<br />
|-<br />
! Gelesener Wert || <tt>pgm_read_xxx</tt> || Anzahl Bytes<br />
|-<br />
| <tt>uint8_t</tt> || <tt>pgm_read_byte</tt> || 1<br />
|-<br />
| <tt>uint16_t</tt> || <tt>pgm_read_word</tt> || 2<br />
|-<br />
| <tt>uint32_t</tt> || <tt>pgm_read_dword</tt> || 4<br />
|-<br />
| <tt>float</tt> || <tt>pgm_read_float</tt><ref>ab avr-libc 1.7.0</ref> || 4<br />
|}<br />
<br />
Soll ein Zeiger gelesen werden, so verwendet man <tt>pgm_read_word</tt> und castet das Ergebnis zum gewünschten Zeiger-Typ.<br />
<br />
;Beispiele:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
/* Byte */<br />
const uint8_t aByte PROGMEM = 123;<br />
<br />
/* int-Array */<br />
const int anArray[] PROGMEM = { 18, 3 ,70 };<br />
<br />
void foo (void)<br />
{<br />
/* Zeiger */<br />
static const uint8_t* const aPointer PROGMEM = &aByte;<br />
<br />
uint8_t a = pgm_read_byte (&aByte);<br />
int a2 = (int) pgm_read_word (&anArray[2]);<br />
const uint8_t* p = (const uint8_t*) pgm_read_word (&aPointer);<br />
}<br />
</syntaxhighlight><br />
<br />
=== Blöcke ===<br />
<br />
In den Flash-Funktionen der avr-libc sind keine der pgm_read_xxxx Nomenklatur folgenden Funktionen, die Speicherblöcke auslesen oder vergleichen. Die enstprechende Funktionen sind Varianten von <tt>memcpy</tt>, <tt>memcmp</tt> und heißt <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, usw. Für weitere Funktionen und deren Prototypen siehe die Dokumentation der avr-libc.<br />
<br />
=== Strings ===<br />
<br />
Strings sind in C nichts anderes als eine Abfolge von Zeichen und einem <tt>'\0'</tt> als Stringende. Der prinzipielle Weg ist daher identisch zum Lesen von Bytes, wobei auf die [[FAQ#Wie funktioniert String-Verarbeitung in C?|Besonderheiten von Strings]] wie 0-Terminierung geachtet werden muss.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
size_t my_string_length (const char *addr)<br />
{<br />
size_t length = 0;<br />
<br />
while (pgm_read_byte (addr++))<br />
{<br />
length++;<br />
}<br />
return length;<br />
}<br />
</syntaxhighlight><br />
<br />
Zur Unterstützung des Programmierers steht das Repertoire der str-Funktionen auch in jeweils eine Variante zur Verfügung, die mit dem Flash-Speicher arbeiten kann. Die Funktionsnamen tragen den Suffix <tt>_P</tt>. Darüber hinaus gibt es das Makro <tt>PSTR</tt>, das ein String-Literal im Flash-Speicher ablegt und die Adresse des Strings liefert:<br />
<br />
Die nachfolgende Funktion liefert 0 zurück, wenn string_im_ram gleich "Hallo Welt" ist. Mit strcmp (String Compare) können wir zwei Strings vergleichen. Der Rückgabewert kann hierbei folgende Werte haben:<br><br />
0 die Strings sind gleich<br />
>0 das erste ungleiche Zeichen in string_im_ram ist größer als in "Hallo Welt"<br />
<0 das erste ungleiche Zeichen in string_im_ram ist kleiner als in "Hallo Welt"<br />
<br><br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
int foo (const char *string_im_ram)<br />
{<br />
return strcmp_P (string_im_ram, PSTR ("Hallo Welt"));<br />
}<br />
</syntaxhighlight><br />
<br />
Zu beachten ist, dass <tt>PSTR</tt> nur innerhalb von Funktionen verwendet werden kann.<br />
<br />
; Array aus Strings:<br />
<br />
Arrays aus Strings im Flash-Speicher werden in zwei Schritten angelegt:<br />
<br />
# Zuerst die einzelnen Elemente des Arrays und<br />
# im Anschluss ein Array, in dem die Startaddressen der Strings abgelegt werden.<br />
<br />
Zum Auslesen wird zuerst die Adresse des gewünschten Elements aus dem Array im Flash-Speicher gelesen, die im Anschluss dazu genutzt wird, um auf das Element (den String) selbst zuzugreifen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
static const char str1[] PROGMEM = "Hund";<br />
static const char str2[] PROGMEM = "Katze";<br />
static const char str3[] PROGMEM = "Maus";<br />
<br />
const char * const array[] PROGMEM = <br />
{<br />
str1, str2, str3<br />
};<br />
<br />
// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]<br />
void read_string (char *buf, size_t i)<br />
{<br />
// Lese die Adresse des i-ten Strings aus array[]<br />
const char *parray = (const char*) pgm_read_ptr (&array[i]);<br />
<br />
// Kopiere den Inhalt der Zeichenkette vom Flash ins RAM<br />
strcpy_P (buf, parray);<br />
}<br />
</syntaxhighlight><br />
<br />
Eine weitere Möglichkeit ist, die Strings in einem 2-dimensionalen char-Array abzulegen anstatt deren Adresse in einem 1-dimensionalen Adress-Array zu speichern.<br />
<br />
Vorteil ist, dass der Code einfacher wird. Nachteil ist, dass bei unterschiedlich langen Strings Speicherplatz verschwendet wird, weil sich die Array-Dimension and der Länge des längsten Strings orientieret. Bei in etwa gleich langen Strings kann es aber sogar Speicherplatz sparen, denn es die Adressen der einzelnen Strings müssen nicht abgespeichert werden.<ref>In unserem Hund-Katze-Maus Beispiel belegt die erste Variante 22 Bytes Daten und 18 Bytes Code, die zweite Variante mit 2-dimensionalem Array belegt 18 Bytes Daten und 20 Bytes Code. Gemessen wurde mit avr-gcc 4.8 -Os für ATmega8.</ref><br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
// Die "6" ist 1 plus die Länge des längsten Strings ("Katze")<br />
const char array[][6] PROGMEM = <br />
{<br />
"Hund", "Katze", "Maus"<br />
};<br />
<br />
// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]<br />
void read_string (char *buf, size_t i)<br />
{<br />
// Kopiere den Inhalt der i-ten Zeichenkette vom Flash ins RAM<br />
strcpy_P (buf, array[i]);<br />
}<br />
</syntaxhighlight><br />
<br />
Siehe dazu auch die avr-libc FAQ: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_rom_array How do I put an array of strings completely in ROM?]<br />
<br />
=== Warum so kompliziert? ===<br />
<br />
Zu dem Thema, warum die Verabeitung von Werten aus dem Flash-Speicher so kompliziert ist, sei hier nur kurz erläutert: Die Harvard-Architektur des AVR weist getrennte Adressräume für Programm (Flash) und Datenspeicher (RAM) auf. Der C-Standard sieht keine unterschiedlichen Adressräume vor.<br />
<br />
Hat man zum Beispiel eine Funktion string_an_uart (const char* s) und übergibt an diese Funktion die Adresse einer Zeichenkette, dann weiß die Funktion nicht, ob die Adresse in den Flash-Speicher oder das RAM zeigt. Weder aus dem Pointer-Wert, also dem Zahlenwert, noch aus dem "const" kann auf den Ort der Ablage geschlossen werden.<br />
<br />
Einige AVR-Compiler bilden die Harvard-Architektur ab, indem sie in einen Pointer nicht nur die Adresse speichern, sondern auch den Ablageort wie ''Flash'' oder ''RAM''. In einem Aufruf einer Funktion wird dann bei Pointer-Parametern neben der Adresse auch der Speicherbereich, auf den der Pointer zeigt, übergeben.<br />
<br />
Dies hat jedoch auch Nachteile, denn bei jedem Zugriff über einen Zeiger muss zur ''Laufzeit'' entschieden werden, wie der Zugriff auszuführen ist und entsprechend länglicher und langsamer wird der erzeugte Code.<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitte Modules/Program Space String Utilities und Abschnitt Modules/Bootloader Support Utilities<br />
<br />
=== Von-Neumannisierung „zu Fuß“ ===<br />
<br />
„Wenn der Prophet nicht zum Berg geht, muss der Berg zum Propheten kommen“.<br />
<br />
Bei Mikrocontrollern mit weniger als 64 KiB Gesamtspeicher ist das mit dem <tt>__flash</tt> oder <tt>PROGMEM</tt> nicht nur lästig sondern erfordert eine Vielzahl von Bibliotheksfunktionen (hier: die auf _P enden) die alle fast dasselbe machen.<br />
<br />
Neuere PIC-Mikrocontroller, AVR xMega3 sowie einige wenige ATtiny verfügen bereits über eine Von-Neumannisierung von RAM und Flash in Hardware, nur bei den gängigen AVRs „will der Prophet nicht zum Berg“, da geht das nicht.<br />
<br />
Eine alternative Lösung zu den in der <tt>avr-libc</tt> implementierten mit den <i>zwei</i> (mit EEPROM sogar <i>drei</i>) Zeiger<i>typen</i> ist die manuelle Von-Neumannisierung zu <i>einem</i> Zeiger. Hier behilft man sich mit einem Satz aus Inline-Funktionen und Makros, die je nach Bit 15 des Zeigers RAM oder Flash lesen. So setzen die Makros <tt>F(x)</tt> (x als String-Konstante) bzw, <tt>FP(x)</tt> (x als Flash-Adresse) das Bit 15 der Adresse. Die darauf ausgerichtete Bibliotheksfunktion (bspw. ein selbst geschriebener <tt>printf()</tt>-Ersatz) verarbeitet dann den Formatstring aus RAM oder Flash und kommt auch mit <tt>"%s"</tt>-Substitutionen problemlos zurecht. Dreh- und Angelpunkt ist diese Funktion:<br />
<br />
<syntaxhighlight lang="c++"><br />
// Von-Neumannisiertes Speicherlesen (RAM oder Flash je nach Bit 15 der Adresse)<br />
inline byte read_byte(const void*addr) {<br />
byte result; asm(<br />
" sbrc %B1,7 \n"<br />
" lpm %0,%a1 \n"<br />
" sbrs %B1,7 \n"<br />
" ld %0,%a1 \n"<br />
:"=r"(result):"z"(addr));<br />
return result;<br />
}<br />
</syntaxhighlight><br />
<br />
Mit dem Bit 14 lässt sich nach demselben Strickmuster auch EEPROM linearisieren. Dann sollte die <tt>inline</tt>-Funktion aus einem <tt>rcall</tt> bestehen um fortwährendes Inlining zu vermeiden. Siehe auch: avr-gcc beim Thema <i>clobbered registers</i> und <tt>push</tt>-Orgien auf die Sprünge helfen.<br />
<br />
=== Datenzugriff jenseits 64 KiB ===<br />
<br />
Die Zeiger beim <tt>avr-gcc</tt> sind stets 16 Bit breit, können somit also nur 64 KiB Datenspeicher adressieren. Darauf sind auch alle Funktion der libc ausgelegt, welche auf _P enden. Funktionszeiger können beim AVR bis zu 128 KiB Programmspeicher adressieren, weil Funktionsadressen immer 16-Bit-<u>Worte</u> adressieren und nicht Bytes. Der Zugriff auf den RAM ist mit maximal 16 KiB (extern maximal 64 KiB) durch 16-Bit-Zeiger nicht begrenzt.<br />
<br />
Schlauerweise sortiert <tt>avr-gcc</tt> Flash-Konstanten und -Tabellen <i>so</i> um, dass sie an den Anfang des Flash-Speichers, gleich nach der Interrupt-Tabelle, zu liegen kommen. Somit kommt man auch auf Controllern mit mehr als 64 KByte Flash im Normalfall ohne „lange“ Zeiger aus.<br />
<br />
<small>Auf Controllern mit mehr als 128 KiB Flash bekommen alle Funktionen <i>jenseits</i> 128 KiB ein <b>Trampolin</b> (Sprungbefehl aus 4 Byte) im dem Adressbereich <i>vor</i> 128 KiB. Damit genügt für alle Funktionszeiger 16 Bit. Wird kein Zeiger benötigt, kann der Optimierer das jeweilige Trampolin entfernen.</small><br />
<br />
Um (dennoch) Zugriff jenseits von 64 KiB zu bewerkstelligen gibt es mehrere Möglichkeiten:<br />
<br />
* Address-Spaces wie <tt>__flash1</tt> oder <tt>__memx</tt>, siehe Abschnitt "[[#Jenseits von flash|Jenseits von __flash]]".<br />
* Die Funktionen bzw. Makros <tt>pgm_read_xxx_far</tt> der AVR-Libc ab Version 1.8.0, wie im folgenden beschrieben. Dafür gibt es die Funktion pgm_get_far_address(), um 32-Bit Pointer eines Objekts zu erhalten<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/pgmspace.h><br />
<br />
//===================================================================<br />
// Define an additional section, which will be placed after all others<br />
//--------------------------------------------------------------------<br />
#define FAR_SECTION __attribute__((__section__(".far_section")))<br />
//--------------------------------------------------------------------<br />
<br />
//====================================================================<br />
// Just an example<br />
//====================================================================<br />
<br />
const char MyString[] FAR_SECTION = "Hier liegt mein FAR-Teststring!";<br />
const char MyBmp64[] FAR_SECTION = {0xAA,0xBB,0xCC,0xDD,0xEE,0xFF,0x00};<br />
<br />
int main(void) {<br />
uint32_t ptr = pgm_get_far_address(MyString);<br />
char MyChar;<br />
DDRC = 0xFF;<br />
do {<br />
MyChar = pgm_read_byte_far(ptr++);<br />
PORTC = MyChar;<br />
} while(MyChar);<br />
}<br />
</syntaxhighlight><br />
<br />
D.h. man muss<br />
* Die Definition der neuen Section <tt>FAR_SECTION</tt> einfügen<br />
* Die konstanten Daten mit dieser Section kennzeichnen<br />
<br />
Dem Linker muss man über diese Section nichts mitteilen, er fügt diese automatisch nach allen bestehenden sections im Flash ein. Der Zugriff auf diese Variablen kann nur mittels direkter Pointerarithmetik erfolgen, eine Indizierung von Arrays mit variablem Index ist nicht möglich. Dabei muss die Größe des Datentyps immer manuell berücksichtigt werden, denn der Pointer ist immer ein Bytepointer!<br />
<br />
<syntaxhighlight lang="c"><br />
int n=3;<br />
MyChar = pgm_read_byte_far(pgm_get_far_address(MyBmp64)+n*sizeof(char));<br />
</syntaxhighlight><br />
<br />
Dabei gibt es einige praktische Probleme.<br />
* Beim recht alten AVR-Studio 4.18 wird die Größe des belegten FLASH-Speichers nicht korrekt angezeigt, die Daten landen aber im HEX-File.<br />
* beim moderneren Atmelstudio 6.2 sieht man in der Consolenausgabe die richtige Größe, welche von avr-size ermittelt wurde, diese wird aber dann in der 2. Ausgabe durch Atmelstudio falsch dargestellt<br />
* Die Arduino-IDE rechnet richtig, siehe dieser [https://www.mikrocontroller.net/topic/511511?goto=6568945#6568945 Forumsbeitrag].<br />
<br />
== Flash mit __flash und Embedded-C ==<br />
<br />
Ab Version 4.7 unterstützt avr-gcc ''Adress-Spaces'' gemäß dem Embedded-C Dokument ISO/IEC TR18037. Der geläufigste Adress-Space ist <tt>__flash</tt>, der im Gegensatz zu <tt>progmem</tt> kein GCC-Attribut ist, sondern ein Qualifier und damit syntaktisch ähnlich verwendet wird wie <tt>const</tt> oder <tt>volatile</tt>.<br />
<br />
GCC kennt keine eigene Option zum Aktivieren von Embedded-C, es wird als GNU-C Erweiterung behandelt. Daher müssen C-Module, die Address-Spaces verwenden, mit <tt>-std=gnu99</tt> o.ä. compiliert werden.<br />
<br />
<syntaxhighlight lang="c"><br />
static const __flash int value = 10;<br />
<br />
int get_value (void)<br />
{<br />
return value;<br />
}<br />
</syntaxhighlight><br />
<br />
# Im Gegensatz zu <tt>progmem</tt> sind keine speziellen Bibliotheksfunktionen oder -makros für den Zugriff mehr notwendig: Der Code zum Lesen der Variable ist "normales" C.<br />
# Die Variable wird im richtigen Speicherbereich (Flash) angelegt.<br />
# <tt>__flash</tt> ist nur zusammen mit read-only Objekten oder Zeigern, d.h. nur zusammen mit <tt>const</tt>, erlaubt.<br />
# Zugriffe wie im obigen Beispiel können (weg)optimiert werden. Das Beispiel entspricht einem "<tt>return 10</tt>". Es besteht keine Notwendigkeit, für <tt>value</tt> überhaupt Flash-Speicher zu reservieren.<br />
<br />
Auch Zeiger-Indirektionen sind problemlos möglich. Zu beachten ist, dass <tt>__flash</tt> auf der richtigen Seite des "<tt>*</tt>" in der Zeigerdeklaration bzw. -definition steht:<br />
* '''Rechts vom <tt>*</tt>:''' Der Zeiger selbst liegt im Flash<br />
* '''Links vom <tt>*</tt>:''' Der Zeiger enthält eine Flash-Adresse<br />
<br />
<syntaxhighlight lang="c"><br />
// val ist eine Variable im Flash<br />
const __flash int val = 42;<br />
<br />
// pval liegt auch im Flash und enthält die Adresse von val<br />
const __flash int* const __flash pval = &val;<br />
<br />
int get_val (void)<br />
{<br />
// liest den Wert von val über die in pval abgelegte Adresse<br />
return *pval;<br />
}<br />
</syntaxhighlight><br />
<br />
=== Blöcke ===<br />
<br />
Um Speicherbereiche vom Flash in den RAM zu kopieren, gibt es zwei Möglichkeiten: Zum einen können wie bei <tt>progmem</tt> beschreiben die Funktionen der avr-libc wie <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, <tt>movmem_P</tt>, etc. verwendet werden:<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
// Eine Datenstruktur<br />
typedef struct<br />
{<br />
int id;<br />
char buf[10];<br />
} data_t;<br />
<br />
extern void uart_send (const void*, size_t);<br />
<br />
void send_data (const __flash data_t *pdata)<br />
{<br />
// buf wird auf dem Stack angelegt<br />
data_t buf;<br />
<br />
// Kopiere Daten vom Flash nach buf ins RAM<br />
memcpy_P (&buf, pdata, sizeof (data_t));<br />
<br />
// Sende die Daten in buf<br />
uart_send (&buf, sizeof (data_t));<br />
}<br />
</syntaxhighlight><br />
<br />
Zum anderen kann eine Struktur auch über direktes Kopieren ins RAM geladen werden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdlib.h><br />
<br />
// Eine Datenstruktur<br />
typedef struct<br />
{<br />
int id;<br />
char buf[10];<br />
} data_t;<br />
<br />
extern void uart_send (const void*, size_t);<br />
<br />
void send_data (const __flash data_t *pdata)<br />
{<br />
// Kopiere Daten ins RAM. buf wird auf dem Stack angelegt<br />
const data_t buf = *pdata;<br />
<br />
// Verwendet die Daten in buf<br />
uart_send (&buf, sizeof (data_t));<br />
}<br />
</syntaxhighlight><br />
<br />
=== Strings ===<br />
<br />
Natürlich können auch Strings im Flash abgelegt werden und auch mit Funktionen wie <tt>strcpy_P</tt> aus der avr-libc verarbeitet werden. Zudem ist es möglich, Flash-Zeiger mit der Adresse eines String-Literals zu initialisieren:<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
#define FSTR(X) ((const __flash char[]) { X } )<br />
<br />
const __flash char * const __flash array[] = <br />
{<br />
FSTR ("Hund"), FSTR ("Katze"), FSTR ("Maus")<br />
};<br />
<br />
size_t get_len (uint8_t tier)<br />
{<br />
return strlen_P (array[tier]);<br />
}<br />
</syntaxhighlight><br />
<br />
Leider sieht der Embedded-C Draft nicht vor, String-Literale direkt in einem anderen Adress-Space als ''generic'' anzulegen, so dass hier der Umweg über <tt>FSTR</tt> genommen werden muss. Dieses Konstrukt ist nur ausserhalb von Funktionen möglich und kann daher nicht als Ersatz für <tt>PSTR</tt> aus der avr-libc dienen.<br />
<br />
Soll <tt>array</tt> ein 2-dimensonales Array sein anstatt ein 1-dimensionales Array von Zeigern, dann geht das ohne große Verrenkungen:<br />
<br />
<syntaxhighlight lang="c"><br />
// Die 6 ergibt sich aus 1 plus der Länge des längsten Strings "Katze"<br />
const __flash char array[][6] = <br />
{<br />
"Hund", "Katze", "Maus"<br />
};<br />
</syntaxhighlight><br />
<br />
Weiters besteht die Möglichkeit, <tt>array</tt> analog anzulegen, wie man es mit <tt>PROGMEM</tt> machen würde: Jeder String wird explizit angelegt und seine Adresse bei der Initialisierung von <tt>array</tt> verwendet. Dies entspricht dem ersten Beispiel eines 1-dimensionalen Zeigerarrays:<br />
<br />
<syntaxhighlight lang="c"><br />
static const __flash char strHund[] = "Hund";<br />
static const __flash char strKatze[] = "Katze";<br />
static const __flash char strMaus[] = "Maus";<br />
<br />
const __flash char * const __flash array[] = <br />
{<br />
strHund, strKatze, strMaus<br />
};<br />
</syntaxhighlight><br />
<br />
=== Casts ===<br />
<br />
Embedded C fordert, dass zwei Adress-Spaces entweder disjunkt sind – d.h. sie enthalten keine gemeinsamen Adressen – oder aber ein Space komplett im anderen enthalten ist, also eine Teilmengen-Beziehung besteht. Die Adress-Spaces von avr-gcc sind so implementiert, dass jeder Space Teilmenge jedes anderes ist. Zwar haben Spaces wie RAM und Flash physikalisch keinen Speicherbereich gemein, allerdings ermöglicht diese Implementierung das Casten von Zeigern zu unterschiedlichen Adress-Spaces<ref>Im Gegensatz zu einem Attribute wie <tt>progmem</tt> ist ein (Adress Space) Qualifier Teil des Zeiger-Typs.</ref>: <br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdbool.h><br />
<br />
char read_char (const char *address, bool data_in_flash)<br />
{<br />
if (data_in_flash)<br />
return *(const __flash char*) address;<br />
else<br />
return *address;<br />
}<br />
</syntaxhighlight><br />
<br />
Der Cast selbst erzeugt keinen zusätzlichen Code, da eine RAM-Adresse und eine Flash-Adresse die gleiche Binärdarstellung haben. Allerdings wird über den nach <tt>__flash</tt> gecasteten Zeiger anders zugegriffen, nämlich per LPM.<br />
<br />
=== Jenseits von __flash ===<br />
<br />
Ausser <tt>__flash</tt> gibt es auch folgende Address-Spaces:<br />
<br />
==== <tt>__flash</tt>''N'' ====<br />
<br />
<tt>__flash</tt>''N'' mit ''N'' = 1..5 sind fünf weitere Spaces, die analog zu <tt>__flash</tt> funktionieren und deren Zeiger ebenfalls 16 Bit breit sind. avr-gcc erwartet, dass die zugehörigen Daten, welche in die Section <tt>.progmem</tt>''N''<tt>.data</tt> abgelegt werden, so lokatiert sind, dass das high-Byte der Adresse (Bits 16..23) gerade ''N'' ist.<br />
<br />
Weil Daten- und Code-Layout höchst projektspezifisch sind, werden diese Sections im Standard Linker-Skript nicht beschrieben. Um funktionsfähigen Code zu erhalten, muss daher ein eigenes Linker-Skript zur Verfügung gestellt werden, das diese Sections beschreibt, oder es kann eine Erweiterung des Standard Skripts bereitgestellt werden falls dies möglich ist.<br />
<br />
;Beispiel: Eine Applikation, die <tt>__flash2</tt> verwendet. Die zugehörende Section <tt>.progmem2.data</tt> wird hinter <tt>.text</tt> angeordnet aber vor den Initializern für <tt>.data</tt>. Dazu wird beim Linken das ld-Skript Fragment per <tt>-Tflash12.ld</tt> angegeben, welches dann an der gewünschten Stelle in das default Skript eingefügt wird:<br />
:{| <!-- Tabelle bitte für korrekte Einrückung belassen --><br />
|-<br />
|<pre><br />
SECTIONS<br />
{<br />
.flash2 :<br />
{<br />
. = MAX (ABSOLUTE(0x20000), .);<br />
PROVIDE (__flash2_start = .);<br />
. = ALIGN(2);<br />
*(.flash2.text*)<br />
*(.progmem2.data*)<br />
PROVIDE (__flash2_end = .);<br />
<br />
ASSERT (__flash2_start == __flash2_end || __flash2_start >= ABSOLUTE(0x20000),<br />
"__flash2 data in .progmem2.data below 0x20000");<br />
ASSERT (__flash2_start == __flash2_end || __flash2_end <= ABSOLUTE(0x30000),<br />
"__flash2 data in .progmem2.data exceeds 0x30000");<br />
}<br />
}<br />
INSERT AFTER .text<br />
</pre><br />
|}<br />
<br />
==== <tt>__memx</tt> ====<br />
<br />
Dieser Address-Space implementiert 3-Byte Zeiger und unterstützt Lesen über 64KiB-Segmentgrenzen hinweg. Das MSB (Bit 23) gibt dabei an, ob der <tt>__memx</tt>-Zeiger eine Flash-Adresse enthält (Bit23 = 0) oder eine RAM-Adresse (Bit23 = 1), was folgenden Code erlaubt:<br />
<br />
<syntaxhighlight lang="c"><br />
const __memx int a_flash = 42;<br />
const int a_ram = 100;<br />
<br />
int get_a (const __memx int* pa)<br />
{<br />
return *pa;<br />
}<br />
<br />
int main (void)<br />
{<br />
return get_a (&a_flash) + get_a (&a_ram);<br />
}</syntaxhighlight><br />
<br />
Dies bedeutet, dass erst zur ''Laufzeit'' entschieden werden kann, ob <tt>get_a</tt> die Daten aus dem RAM oder aus dem Flash lesen soll, was <tt>__memx</tt> im Vergleich zu den anderen Address-Spaces langsamer macht. Ausserdem ist zu beachten, dass <tt>__memx</tt>-Zeiger zwar 24-Bit Zeiger sind, die zugrundeliegende Adress-Arithmetik jedoch gemäß dem C-Standard erfolgt, also als 16-Bit Arithmetik. Bestehende Funktion der avr-libc wie z.B. printf_P funktionieren damit ebensowenig wie printf! Wenn man <tt>__memx</tt> verwenden will, braucht man dafür eigene Funktionen.<br />
<br />
=== __flash, progmem und Portierbarkeit ===<br />
<br />
Da ab er aktuellen Compilerversion 4.7 sowohl <tt>__flash</tt> als auch <tt>PROGMEM</tt> und die <tt>pgm_read</tt>-Funktionen zur Verfügung stehen, ergibt sich die Frage, welche Variante "besser" ist und wie zwischen ihnen hin- und her zu portieren ist.<br />
<br />
Zunächst sei erwähnt, dass <tt>__flash</tt> kein Ersatz für <tt>PROGMEM</tt> ist, sondern lediglich eine Alternative dazu. Das "alte" progmem wird weiterhin mir gleicher Semantik unterstützt, so dass alter Code ohne Änderungen mit den neueren Compilerversionen übersetzbar bleibt.<br />
<br />
Von der Codegüte her dürften sich keine großen Unterschiede ergeben. Es ist nicht zu erwarten, dass die eine oder die andere Variante wesentlich besseren oder schlechteren Code erzeugt — von einer Ausnahme abgesehen: Der Wert beim Zugriff ist zur Compilezeit bekannt und kann daher eliminiert werden.<br />
<syntaxhighlight lang="c"><br />
static const __flash char x[] = { 'A', 'V', 'R' };<br />
<br />
char foo (void)<br />
{<br />
return x[2];<br />
}<br />
</syntaxhighlight><br />
Dies wird übersetzt wie "<tt>return 'R';</tt>", und das Array <tt>x[]</tt> kann komplett wegoptimiert werden und entfallen.<br />
<br />
==== progmem → __flash ====<br />
<br />
Portierung in diese Richtung bedeutet, alten Code anzupassen. Zwingend ist die Portierung nicht, da <tt>progmem</tt> weiterhin unterstützt wird.<br />
Allerdings ist eine Quelle mit <tt>__flash</tt> besser lesbar, denn der Code wird von den <tt>pgm_read</tt>-Funktionen befreit, die vor allem bei Mehrfach-Indirektion den Code ziemlich verunstalten und unleserlich machen können.<br />
Weiterer Vorteil von <tt>_flash</tt> ist, daß eine striktere Typprüfung erfolgen kann.<br />
<br />
Eine Portierung wird man in zwei Schritten vornehmen:<br />
<br />
;1. Definitionen von Flash-Variablen werden angepasst:<br />
<br />
Vorher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
static const char hund[] PROGMEM = "Hund";<br />
static const char katze[] PROGMEM = "Katze";<br />
static const char maus[] PROGMEM = "Maus";<br />
<br />
const char * const tier[] PROGMEM = <br />
{<br />
hund, katze, maus<br />
};<br />
</syntaxhighlight><br />
|}<br />
<br />
Nachher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
static const __flash char hund[] = "Hund";<br />
static const __flash char katze[] = "Katze";<br />
static const __flash char maus[] = "Maus";<br />
<br />
const __flash char * const __flash tier[] = <br />
{<br />
hund, katze, maus<br />
};<br />
</syntaxhighlight><br />
|}<br />
<br />
Der Header <tt>avr/pgmspace.h</tt> wird nicht mehr benötigt. Im Gegensatz zu <tt>progmem</tt> müssen Qualifier immer links von der definierten Variablen stehen; bei Attributen wie <tt>progmem</tt> ist das mehr oder weniger egal.<br />
<br />
Nachdem diese Anpassung erfolgreich abgeschlossen ist, folgt Schritt<br />
<br />
; 2. Der Code wird von <tt>pgm_read</tt>-Aufrufen bereinigt:<br />
<br />
Vorher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
extern const char *tier[];<br />
<br />
char first_letter (uint8_t i)<br />
{<br />
const char* ptier = (const char*) pgm_read_word (&tier[i]);<br />
return (char) pgm_read_byte (&ptier[0]);<br />
}<br />
</syntaxhighlight><br />
|}<br />
<br />
Nachher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <stdint.h><br />
<br />
extern const __flash char * const __flash tier[];<br />
<br />
char first_letter (uint8_t i)<br />
{<br />
return tier[i][0];<br />
}<br />
</syntaxhighlight><br />
|}<br />
<br />
== Dateien direkt im Flash einbinden ==<br />
<br />
Wenn man größere Dateien direkt im Programm einbinden will, ohne sie vorher in C Quelltext umzuwandeln, muss man das mit dem Linker machen. Wie das geht steht hier.<br />
<br />
* [http://www.atmel.com/webdoc/avrlibcreferencemanual/FAQ_1faq_binarydata.html Atmel, avr gcc Dokumentation]<br />
* [http://nongnu.org/avr-libc/user-manual/FAQ.html#faq_binarydata Nongnu avr gcc Dokumentation]<br />
<br />
Wie man das dann praktisch umsetzt, sieht man in diesem Beitrag.<br />
<br />
* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056910 Forumsbeitrag]: Binärdateien mittels Linker einbinden<br />
* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056947 Forumsbeitrag]: Ein kleines Tool zum Umwandeln von Binärdateien in C-Quelltext.<br />
<br />
== Flash in der Anwendung schreiben ==<br />
<br />
Bei AVRs mit "self-programming"-Option – auch bekannt als [[Bootloader]]-Support – können Teile des Flash-Speichers vom Anwendungsprogramm beschrieben werden. Dies ist nur möglich, wenn die Schreibfunktion in einem besonderen Speicherbereich, der Boot-Section des Programmspeichers/Flash, abgelegt ist.<br />
<br />
Bei einigen kleinen AVRs gibt es keine gesonderte Boot-Section, bei diesen kann der Flashspeicher von jeder Stelle des Programms geschrieben werden. Für Details sei hier auf das jeweilige Controller-Datenblatt und die Erläuterungen zum Modul boot.h der avr-libc verwiesen. Es existieren auch Application-Notes dazu bei atmel.com, die auf avr-gcc-Code übertragbar sind.<br />
<br />
Siehe auch: <br />
* Forumsbeitrag [http://www.mikrocontroller.net/topic/163632#1561622 Daten in Programmspeicher speichern]<br />
<br />
== EEPROM ==<br />
<br />
Möchte man Werte aus einem Programm heraus so speichern, dass sie auch nach dem Abschalten der Versorgungsspannung noch erhalten bleiben und nach dem Wiederherstellen der Versorgungsspannung bei erneutem Programmstart wieder zur Verfügung stehen, dann benutzt man das EEPROM.<br />
<br />
Schreib- und Lesezugriffe auf den EEPROM-Speicher erfolgen über die im Modul eeprom.h der avr-libc definierten Funktionen. Mit diesen Funktionen können einzelne Bytes, Datenworte (16 Bit), Fließkommawerte (32 Bit, single-precision, float) und Datenblöcke geschrieben und gelesen werden.<br />
<br />
Diese Funktionen kümmern sich auch um diverse Details, die bei der Benutzung des EEPROMs normalerweise notwendig sind:<br />
* EEPROM-Operationen sind im Vergleich relativ langsam. Man muss daher darauf achten, dass eine vorhergehende Operation abgeschlossen ist, ehe die nächste Operation mit dem EEPROM gestartet wird. Die in der avr-libc implementierten Funktionen aus eeprom.h berücksichtigten dies. Soll beim Aufruf einer EEPROM-Funktion sichergestellt werden, dass diese nicht intern in einer Warteschleife auf den Abschluss der vorherigen Operation wartet, kann vorher per eeprom_is_ready testen, ob der Zugriff auf den EEPROM-Speicher sofort möglich ist.<br />
* Es ist darauf zu achten, dass die EEPROM-Funktionen nicht durch einen Interrupt unterbrochen werden. Einige Phasen des Zugriffs sind zeitkritisch und müssen in einer definierten bzw. begrenzten Anzahl von Takten durchgeführt werden. Durch einen unterbrechenden Interrupt würde diese Restriktion nicht mehr eingehalten. Auch dieses Detail wird von den avr-libc Funktionen berücksichtigt, so dass man sich als C-Programmierer nicht darum kümmern muss. Innerhalb der Funktionen werden Interrupts vor der "EEPROM-Sequenz" global deaktiviert und im Anschluss, falls vorher auch schon eingeschaltet, wieder aktiviert.<br />
<br />
Man beachte, dass der EEPROM-Speicher nur eine begrenzte Anzahl von Schreibzugriffen zulässt. Beschreibt man eine EEPROM-Zelle öfter als die im Datenblatt zugesicherte Anzahl (typisch 100.000), wird die Funktion der Zelle nicht mehr garantiert. Dies gilt für jede einzelne Zelle. <br />
<br />
Bei geschickter Programmierung (z.&nbsp;B. Ring-Puffer), bei der die zu beschreibenden Zellen regelmäßig gewechselt werden, kann man eine deutlich höhere Anzahl an Schreibzugriffen, bezogen auf den gesamten EEPROM-Speicher, erreichen. Auf jeden Fall sollte man aber eine Abschätzung über die zu erwartende Lebensdauer des EEPROM durchführen. Wird ein Wert im EEPROM im Durchschnitt nur einmal pro Woche verändert, wird die garantierte Anzahl der Schreibzyklen innerhalb der voraussichtlichen Verwendungszeit des Controllers sicherlich nicht erreicht werden. Welcher Controller ist schon 100000 / 52 = 1923 Jahre im Einsatz? In diesem Fall lohnt es sich daher nicht, erweiterte Programmfunktionen zu implementieren, mit denen die Anzahl der Schreibzugriffe minimiert wird.<br />
<br />
Eine weitere Möglichkeit, Schreibzyklen einzusparen, besteht in der Vorabprüfung, ob der zu speichernde Wert im EEPROM bereits enthalten ist und nur veränderte Werte zu schreiben. In aktuelleren Versionen der avr-libc sind bereits Funktionen enthalten, die solche Prüfungen enthalten (eeprom_update_*).<br />
<br />
Eine dritte Möglichkeit speichert alle Daten zunächst im RAM, wo sie beliebig oft beschrieben werden können. Nur beim Ausschalten oder beim Ausfall der Stromversorgung werden die Daten in den EEPROM geschrieben. Wie man das richtig macht sieht man im Artikel [[Speicher#EEPROM Schreibzugriffe minimieren | Speicher]].<br />
<br />
Lesezugriffe können beliebig oft durchgeführt werden. Sie unterliegen keinen Einschränkungen in Bezug auf deren Anzahl. <br />
<br />
=== EEMEM ===<br />
Um eine Variable im EEPROM anzulegen, stellt die avr-libc das Makro EEMEM zur Verfügung:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdint.h><br />
#include <avr/eeprom.h><br />
<br />
/* Byte */<br />
uint8_t eeFooByte EEMEM = 123;<br />
<br />
/* Wort */<br />
uint16_t eeFooWord EEMEM = 12345;<br />
<br />
/* float */<br />
float eeFooFloat EEMEM;<br />
<br />
/* Byte-Array */<br />
uint8_t eeFooByteArray1[] EEMEM = { 18, 3, 70 };<br />
uint8_t eeFooByteArray2[] EEMEM = { 30, 7, 79 };<br />
<br />
/* 16-bit unsigned short feld */<br />
uint16_t eeFooWordArray1[4] EEMEM;<br />
</syntaxhighlight><br />
<br />
Die grundsätzliche Vorgehensweise ist identisch zur Verwendung von PROGMEM. Auch hier erzeugt man sich spezielle attributierte Variablen (EEMEM erledigt das), die vom Compiler/Linker nicht wie normale Variablen behandelt werden. Compiler/Linker kümmern sich zwar darum, dass diesen Variablen eine Adresse zugewiesen wird, diese Adresse ist dann aber die Adresse der 'Variablen' im EEPROM. Um die dort gespeicherten Werte zu lesen bzw. zu schreiben, übergibt man diese Adresse an spezielle Funktionen, die die entsprechenden Werte aus dem EEPROM holen bzw. das EEPROM neu beschreiben.<br />
<br />
Die mittels EEMEM erzeugten 'Variablen' sind also mehr als Platzhalter zu verstehen, denn als echte Variablen. Es geht nur darum, im C-Programm symbolische Namen zur Verfügung zu haben, anstatt mit echten EEPROM-Adressen hantieren zu müssen, etwas, das grundsätzlich aber auch genauso gut möglich ist. Nur muss man sich in diesem Fall dann selbst darum kümmern, dass mehrere 'Variablen' ohne Überschneidung im EEPROM angeordnet werden.<br />
<br />
=== Bytes lesen/schreiben ===<br />
<br />
Die avr-libc Funktion zum Lesen eines Bytes heißt eeprom_read_byte. Parameter ist die Adresse des Bytes im EEPROM. Geschrieben wird über die Funktion eeprom_write_byte mit den Parametern Adresse und Inhalt. Anwendungsbeispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#define EEPROM_DEF 0xFF<br />
<br />
void eeprom_example (void)<br />
{<br />
uint8_t myByte;<br />
<br />
// myByte lesen (Wert = 123)<br />
myByte = eeprom_read_byte (&eeFooByte);<br />
<br />
// der Wert 99 wird im EEPROM an die Adresse der<br />
// Variablen eeFooByte geschrieben<br />
myByte = 99;<br />
eeprom_write_byte(&eeFooByte, myByte); // schreiben<br />
<br />
myByte = eeprom_read_byte (&eeFooByteArray1[1]); <br />
// myByte hat nun den Wert 3<br />
<br />
// Beispiel fuer eeprom_update_byte: die EEPROM-Zelle wird nur<br />
// dann beschrieben, wenn deren Inhalt sich vom Parameterwert<br />
// unterscheidet. In diesem Beispiel erfolgt also kein Schreib-<br />
// zugriff, da die Werte gleich sind.<br />
eeprom_update_byte(&eeFooByte, myByte);<br />
<br />
<br />
// Beispiel zur "Sicherung" gegen leeres EEPROM nach "Chip Erase"<br />
// (z. B. wenn die .eep-Datei nach Programmierung einer neuen Version<br />
// des Programms nicht in den EEPROM uebertragen wurde und EESAVE<br />
// deaktiviert ist (unprogrammed/1)<br />
// <br />
// Vorsicht: wenn EESAVE "programmed" ist, hilft diese Sicherung nicht<br />
// weiter, da die Speicheraddressen in einem neuen/erweiterten Programm<br />
// moeglicherweise verschoben wurden. An der Stelle &eeFooByte steht<br />
// dann u.U. der Wert einer anderen Variable aus einer "alten" Version.<br />
<br />
uint8_t fooByteDefault = 222;<br />
if ((myByte = eeprom_read_byte (&eeFooByte)) == EEPROM_DEF)<br />
{<br />
myByte = fooByteDefault;<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
=== Wort lesen/schreiben ===<br />
<br />
Schreiben und Lesen von Datenworten erfolgt analog zur Vorgehensweise bei Bytes:<br />
<br />
<syntaxhighlight lang="c"><br />
// lesen<br />
uint16_t myWord = eeprom_read_word (&eeFooWord);<br />
<br />
// schreiben<br />
eeprom_write_word (&eeFooWord, 2222);<br />
</syntaxhighlight><br />
<br />
=== Block lesen/schreiben ===<br />
<br />
Lesen und Schreiben von Datenblöcken erfolgt über die Funktionen <code>eeprom_read_block()</code> bzw. <code>eeprom_write_block()</code>. Die Funktionen erwarten drei Parameter: die Adresse der Quell- bzw. Zieldaten im RAM, die EEPROM-Adresse und die Länge des Datenblocks in Bytes als <code>size_t</code>.<br />
<syntaxhighlight lang="c"><br />
uint8_t myByteBuffer[3];<br />
uint16_t myWordBuffer[4];<br />
<br />
void eeprom_block_example (void)<br />
{<br />
/* Datenblock aus EEPROM lesen */<br />
<br />
/* liest 3 Bytes ab der von eeFooByteArray1 definierten EEPROM-Adresse<br />
in das RAM-Array myByteBuffer */<br />
eeprom_read_block (myByteBuffer, eeFooByteArray1, 3);<br />
<br />
/* dito mit etwas Absicherung betr. der Länge */<br />
eeprom_read_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));<br />
<br />
/* und nun mit 16-Bit Array */<br />
eeprom_read_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));<br />
<br />
/* Datenblock in EEPROM schreiben */<br />
eeprom_write_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));<br />
eeprom_write_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));<br />
}<br />
</syntaxhighlight><br />
<br />
=== Fließkommawerte lesen/schreiben ===<br />
<br />
In der avr-libc stehen auch EEPROM-Funktionen für Variablen des Typs float (Fließkommazahlen mit "einfacher" Genauigkeit) zur Verfügung.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/eeprom.h><br />
<br />
float eeFloat EEMEM = 12.34f;<br />
<br />
float void eeprom_float_example(float value)<br />
{<br />
/* float in EEPROM schreiben */<br />
eeprom_write_float(&eeFloat, value);<br />
<br />
/* float aus EEPROM lesen */<br />
return eeprom_read_float(&eeFloat);<br />
}</syntaxhighlight><br />
<br />
=== EEPROM-Speicherabbild in .eep-Datei ===<br />
<br />
Mit den zum Compiler gehörenden Werkzeugen kann der aus den Variablendeklarationen abgeleitete EEPROM-Inhalt in eine Datei geschrieben werden. Die übliche Dateiendung ist .eep, Daten im Intel Hex-Format. Damit können Standardwerte für den EEPROM-Inhalt im Quellcode definiert werden. <br />
<br />
Makefiles nach WinAVR/MFile-Vorlage enthalten bereits die notwendigen Einstellungen, siehe dazu die Erläuterungen im [[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]].<br />
<br />
Der Inhalt der eep-Datei muss ebenfalls zum Mikrocontroller übertragen werden, wenn die Initialisierungswerte aus der Deklaration vom Programm erwartet werden. Ansonsten enthält der EEPROM-Speicher nach der Übertragung des Programmers mittels ISP abhängig von der Einstellung der EESAVE-Fuse<ref>vgl. Datenblatt Abschnitt Fuse Bits</ref> nicht die korrekten Werte:<br />
; EESAVE = 0 (programmed): Die Daten im EEPROM bleiben erhalten. Werden sie nicht neu geschrieben, so enthält das EEPROM evtl. Daten, die nicht mehr zum Programm passen.<br />
; EESAVE = 1 (unprogrammed): Beim Programmieren werden die Daten im EEPROM gelöscht, also auf 0xff gesetzt.<br />
<br />
Als Sicherung kann man im Programm nochmals die Standardwerte vorhalten, beim Lesen auf 0xFF prüfen und gegebenenfalls einen Standardwert nutzen. Das geht natürlich nur, wenn 0xFF selbst nicht als Datenwert vorkommen kann.<br />
<syntaxhighlight lang="c"><br />
#define DUTY_CYCLE_DEFAULT 0x80<br />
<br />
uint8_t eeDutyCycle EEMEM; // Platzhalter für EEPROM<br />
uint8_t DutyCycle; // die echte Variable<br />
<br />
<br />
int main(void)<br />
{<br />
DutyCycle = eeprom_read_byte( &eeDutyCycle );<br />
if( DutyCycle == 0xFF ) // das allererste mal. Im EEPROM steht noch kein gültiger Wert<br />
{<br />
DutyCycle = DUTY_CYCLE_DEFAULT;<br />
eeprom_writeByte( &eeDutyCycle, DutyCycle );<br />
}<br />
<br />
...<br />
</syntaxhighlight><br />
<br />
=== Direkter Zugriff auf EEPROM-Adressen ===<br />
<br />
Will man direkt auf bestimmte EEPROM Adressen zugreifen, dann sind folgende IAR-kompatiblen Makros <tt>_EEGET</tt> und <tt>_EEPUT</tt> hilfreich, um sich die Typecasts zu ersparen.<br />
<br />
;Hinweis: Die nachfolgend gezeigten Makros und Zugriffe auf absolute Adressen sind in Normalfall nicht nötig und nur auf sehr wenige, spezielle Fälle beschränkt! Im Normalfall sollte man auf absolute Adressen möglichst nicht zugreifen und den Compiler seine Arbeit machen lassen, der verwaltet die Variablen und deren Adressen meist besser als der Programmierer. Der Zugriff auf Variablen im EEPROM sollte immer über ihren Namen erfolgen.<br />
<br />
Verwendung:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/eeprom.h><br />
<br />
_EEPUT (0x20, 128); // Byte-Wert 128 an Adresse 0x20 schreiben<br />
...<br />
uint8_t val = _EEGET (0x20); // EEPROM-Wert von Adresse 0x20 lesen<br />
</syntaxhighlight><br />
<br />
=== Was steckt dahinter? - EEPROM-Register ===<br />
Auch wenn es normalerweise keinen Grund gibt, in C selbst an den Steuerregistern herumzuschrauben - die eeprom Funktionen erledigen das alles zuverlässig - der Vollständigkeit halber der registermässige technische Unterbau.<br />
Um das EEPROM anzusteuern, sind drei Register von Bedeutung:<br />
;EEAR: Hier werden die Adressen eingetragen zum Schreiben oder Lesen. Dieses Register unterteilt sich nochmal in EEARH und EEARL, da in einem 8-Bit-Register keine 512 Adressen adressiert werden können.<br />
;EEDR: Hier werden die Daten eingetragen, die geschrieben werden sollen, bzw. es enthält die gelesenen Daten.<br />
;EECR: Ist das Kontrollregister für das EEPROM<br />
<br />
Das EECR steuert den Zugriff auf das EEPROM und ist wie folgt aufgebaut:<br />
<br />
:{| class="wikitable" style="text-align:center"<br />
|+ '''Aufbau des EECR-Registers'''<br />
|-<br />
!Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|-<br />
! Name<br />
| - || - || - ||- || EERIE || EEMWE || EEWE || EERE<br />
|-<br />
! Read/Write<br />
| R || R || R || R || R/W || R/W || R/W || R/W<br />
|-<br />
!Init Value<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''Bedeutung der Bits'''<br />
<br />
;Bit 4-7: nicht belegt<br />
<br />
;Bit 3 (EERIE): ''EEPROM Ready Interrupt Enable'': Wenn das Bit gesetzt ist und globale Interrupts erlaubt sind in Register SREG (Bit 7), wird ein Interrupt ausgelöst nach Beendigung des Schreibzyklus (EEPROM Ready Interrupt). Ist einer der beiden Bits 0, wird kein Interrupt ausgelöst.<br />
<br />
;Bit 2 EEMWE): ''EEPROM Master Write Enable'': Dieses Bit bestimmt, dass, wenn EEWE = 1 gesetzt wird (innerhalb von 4 Taktzyklen), das EEPROM beschrieben wird mit den Daten in EEDR bei Adresse EEAR. Wenn EEMWE = 0 ist und EEWE = 1 gesetzt wird, hat das keine Auswirkungen. Der Schreibvorgang wird dann nicht ausgelöst. Nach 4 Taktzyklen wird das Bit EEMWE automatisch wieder auf 0 gesetzt. Dieses Bit löst den Schreibvorgang nicht aus, es dient sozusagen als Sicherungsbit für EEWE.<br />
<br />
;Bit 1 (EEWE): ''EEPROM Write Enable'': Dieses Bit löst den Schreibvorgang aus, wenn es auf 1 gesetzt wird, sofern vorher EEMWE gesetzt wurde und seitdem nicht mehr als 4 Taktzyklen vergangen sind. Wenn der Schreibvorgang abgeschlossen ist, wird dieses Bit automatisch wieder auf 0 gesetzt und, sofern EERIE gesetzt ist, ein Interrupt ausgelöst. Ein Schreibvorgang sieht typischerweise wie folgt aus:<br />
:# EEPROM-Bereitschaft abwarten (EEWE=0) <br />
:# Adresse übergeben an EEAR<br />
:# Daten übergeben an EEDR<br />
:# Schreibvorgang auslösen in EECR mit Bit EEMWE=1 und EEWE=1<br />
:# (Optional) Warten, bis Schreibvorgang abgeschlossen ist<br />
<br />
;Bit 0 EERE: ''EEPROM Read Enable'': Wird dieses Bit auf 1 gesetzt wird das EEPROM an der Adresse in EEAR ausgelesen und die Daten in EEDR gespeichert. Das EEPROM kann nicht ausgelesen werden, wenn bereits eine Schreiboperation gestartet wurde. Es ist daher zu empfehlen, die Bereitschaft vorher zu prüfen. Das EEPROM ist lesebereit, wenn das Bit EEWE=0 ist. Ist der Lesevorgang abgeschlossen, wird das Bit wieder auf 0 gesetzt, und das EEPROM ist für neue Lese- und Schreibbefehle wieder bereit. Ein typischer Lesevorgang kann wie folgt aufgebaut sein:<br />
:# Bereitschaft zum Lesen prüfen (EEWE=0)<br />
:# Adresse übergeben an EEAR<br />
:# Lesezyklus auslösen mit EERE = 1<br />
:# Warten, bis Lesevorgang abgeschlossen EERE = 0<br />
:# Daten abholen aus EEDR<br />
<br />
= Die Nutzung von sprintf und printf =<br />
<br />
Um komfortabel, d.h. formatiert, Ausgaben auf ein Display oder die serielle Schnittstelle zu tätigen, bieten sich '''sprintf''' oder '''printf''' an. Alle *printf-Varianten sind jedoch ziemlich speicherintensiv und der Einsatz in einem Mikrocontroller mit knappem Speicher muss sorgsam abgewogen werden.<br />
<br />
Bei '''sprintf''' wird die Ausgabe zunächst in einem Puffer vorbereitet und anschließend mit einfachen Funktionen zeichenweise ausgegeben. Es liegt in der Verantwortung des Programmierers, genügend Platz im Puffer für die erwarteten Zeichen bereitzuhalten.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdio.h><br />
#include <stdint.h><br />
<br />
// ...<br />
// nicht dargestellt: Implementierung von uart_puts (vgl. Abschnitt UART)<br />
// ...<br />
<br />
uint16_t counter;<br />
<br />
// Ausgabe eines unsigned Integerwertes<br />
void uart_puti( uint16_t value )<br />
{<br />
uint8_t puffer[20];<br />
<br />
sprintf( puffer, "Zählerstand: %u", value );<br />
uart_puts( puffer );<br />
}<br />
<br />
int main()<br />
{<br />
counter = 5;<br />
<br />
uart_puti( counter );<br />
uart_puti( 42 );<br />
}<br />
</syntaxhighlight><br />
<br />
Eine weitere elegante Möglichkeit besteht darin, den STREAM stdout (Standardausgabe) auf eine eigene Ausgabefunktion umzuleiten. Dazu wird dem Ausgabemechanismus der C-Bibliothek eine neue Ausgabefunktion bekannt gemacht, deren Aufgabe es ist, ein einzelnes Zeichen auszugeben. Wohin die Ausgabe dann tatsächlich stattfindet, ist Sache der Ausgabefunktion. Im Beispiel unten wird auf UART ausgegeben. Alle anderen, höheren Funktionen wie z.&nbsp;B. '''printf''', greifen letztendlich auf diese primitive Ausgabefunktion zurück. <br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdio.h><br />
<br />
void uart_init(void);<br />
<br />
// a. Deklaration der primitiven Ausgabefunktion<br />
int uart_putchar(char c, FILE *stream);<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 1)<br />
static FILE mystdout = FDEV_SETUP_STREAM( uart_putchar, NULL, _FDEV_SETUP_WRITE );<br />
<br />
// c. Definition der Ausgabefunktion<br />
int uart_putchar( char c, FILE *stream )<br />
{<br />
if( c == '\n' )<br />
uart_putchar( '\r', stream );<br />
<br />
loop_until_bit_is_set( UCSRA, UDRE );<br />
UDR = c;<br />
return 0;<br />
}<br />
<br />
void uart_init(void)<br />
{<br />
/* hier µC spezifischen Code zur Initialisierung */<br />
/* des UART einfügen... s.o. im AVR-GCC-Tutorial */<br />
<br />
// Beispiel: <br />
//<br />
// myAVR Board 1.5 mit externem Quarz Q1 3,6864 MHz<br />
// 9600 Baud 8N1<br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
// Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt)<br />
#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)<br />
<br />
UCSRB |= (1<<TXEN) | (1<<RXEN); // UART TX und RX einschalten<br />
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1 <br />
<br />
UBRRH = (uint8_t)( UART_UBRR_CALC( UART_BAUD_RATE, F_CPU ) >> 8 );<br />
UBRRL = (uint8_t)UART_UBRR_CALC( UART_BAUD_RATE, F_CPU );<br />
}<br />
<br />
int main(void)<br />
{<br />
int16_t antwort = 42;<br />
uart_init();<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 2)<br />
stdout = &mystdout;<br />
<br />
// Anwendung<br />
printf( "Die Antwort ist %d.\n", antwort );<br />
return 0;<br />
}<br />
<br />
// Quelle: avr-libc-user-manual-1.4.3.pdf, S.74<br />
// + Ergänzungen<br />
</syntaxhighlight><br />
<br />
<br />
Sollen Fließkommazahlen ausgegeben werden, muss im Makefile eine andere (größere) Version der [[FAQ#Aktivieren_der_Floating_Point_Version_von_sprintf_beim_WinAVR_mit_AVR-Studio|printflib]] eingebunden werden.<br />
<br />
= Anmerkungen =<br />
<references/><br />
<br />
= TODO =<br />
* Aktualisierung Register- und Bitbeschreibungen an aktuelle AVR<br />
* "naked"-Funktionen [http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html][http://arduino.stackexchange.com/questions/8758/arduino-interruption-on-pin-change]<br />
<br />
[[Kategorie:avr-gcc Tutorial| ]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR-GCC-Tutorial&diff=107265AVR-GCC-Tutorial2025-01-28T08:38:09Z<p>Heha: /* Von-Neumannisierung „zu Fuß“ */</p>
<hr />
<div>Dieses Tutorial soll den Einstieg in die Programmierung von Atmel [[AVR]]-Mikrocontrollern in der Programmiersprache [[C]] mit dem freien C-Compiler [[avr-gcc]] aus der [http://gcc.gnu.org/ GNU Compiler Collection] (GCC) erleichtern.<br />
<br />
Vorausgesetzt werden Grundkenntnisse der Programmiersprache C. Diese Kenntnisse kann man sich online erarbeiten, z. B. mit dem [http://www.schellong.de/c.htm C Tutorial von Helmut Schellong] ([[C|Liste von C-Tutorials]]). Nicht erforderlich sind Vorkenntnisse in der Programmierung von Mikrocontrollern.<br />
<br />
= Vorwort =<br />
<br />
In diesem Text wird häufig auf die Standardbibliothek avr-libc verwiesen, für die es eine [http://www.nongnu.org/avr-libc/user-manual/index.html Online-Dokumentation] gibt, in der sich auch viele nützliche Informationen zum Compiler und zur Programmierung von AVR-Controllern finden. Beim Paket [[WinAVR]] gehört die avr-libc Dokumentation zum Lieferumfang und wird mitinstalliert.<br />
<br />
Der Compiler und die Standardbibliothek avr-libc werden ständig weiterentwickelt. Einige Unterschiede, die sich im Verlauf der Entwicklung ergeben haben, werden hier und im Artikel [[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen]] zwar angesprochen, Anfängern und Umsteigern sei jedoch empfohlen, eine aktuelle Versionen zu nutzen.<br />
<br />
Das ursprüngliche Tutorial stammt von Christian Schifferle, viele neue Abschnitte und aktuelle Anpassungen von Martin Thomas.<br />
<br />
Dieses Tutorial ist in [[Media:AVR-GCC-Tutorial.pdf|PDF-Form]] erhältlich (zur Zeit nur eine sehr veraltete Version).<br />
<br />
== Weiterführende Kapitel ==<br />
<br />
Um dieses riesige Tutorial etwas überschaubarer zu gestalten, wurden einige Kapitel ausgelagert, die nicht unmittelbar mit den Grundlagen von avr-gcc in Verbindung stehen. All diese Seiten gehören zur [[:Kategorie:avr-gcc Tutorial]].<br />
<br />
;UART: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der UART|Der UART]]''<br />
<br />
;ADC: → Hauptartikel: ''[[AVR-GCC-Tutorial/Analoge Ein- und Ausgabe|Analoge Ein- und Ausgabe (ADC)]]''<br />
<br />
;Timer: → Hauptartikel: ''[[AVR-GCC-Tutorial/Die Timer und Zähler des AVR|Die Timer und Zähler des AVR]]''<br />
<br />
;LCD: → Hauptartikel: ''[[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Ansteuerung]]''<br />
<br />
;Watchdog: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der Watchdog|Der Watchdog]]''<br />
<br />
;Assembler: → Hauptartikel: ''[[AVR-GCC-Tutorial/Assembler und Inline-Assembler|Assembler und Inline-Assembler]]''<br />
<br />
;alte Quellen anpassen: → Hauptartikel: ''[[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen anpassen]]''<br />
<br />
;Makefiles: → Hauptartikel: ''[[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]]'' sowie als Alternative für sehr kleine Projekte → Hauptartikel: ''[[C ohne Makefile]]''<br />
<br />
= Benötigte Werkzeuge =<br />
<br />
Um eigene Programme für AVRs mittels einer AVR-Toolchain zu erstellen wird folgende Hard- und Software benötigt:<br />
<br />
* Eine AVR-Toolchain bestehend aus avr-gcc, den avr-Binutils (Assembler, Linker, etc) und einer Standard-C Bibliothek. Üblich ist die AVR-LibC, die auch quasi in allen avr-gcc Distributionen enthalten ist.<br />
<br />
Hardware wird keine benötigt – bis auf einen PC natürlich, auf dem der Compiler ablaufen kann. Selbst ohne AVR-Hardware kann man also bereits C-Programme für AVRs schreiben, compiliern und sich das Look-and-Feel von avr-gcc sowie von IDEs wie [[Atmel Studio]], Eclipse oder leichtgewichtigeren Entwicklungsumbgebungen anschauen. Selbst das Debuggen und Simulieren ist mithilfe entsprechender Tools wie Debugger und Simulator in gewissen Grenzen möglich.<br />
<br />
Um Programme für AVRs mittels einer AVR-Toolchain zu testen, wird folgende Hard- und Software benötigt:<br />
<br />
* Platine oder Versuchsaufbau für die Aufnahme eines AVR-Controllers, der vom avr-gcc Compiler unterstützt wird.<ref>Für eine Liste der unterstützten COntroller siehe die Dokumentation des Compilers oder [http://www.nongnu.org/avr-libc/user-manual/index.html#supported_devices AVR-Libc: Supported Devices].</ref> Dieses Testboard kann durchaus auch selbst gelötet oder auf einem Steckbrett aufgebaut werden. Einige Registerbeschreibungen dieses Tutorials beziehen sich auf den inzwischen veralteten AT90S2313. Der weitaus größte Teil des Textes ist aber für alle Controller der AVR-Familie gültig. <br />
<br />
:Brauchbare Testplattformen sind auch das [[STK500]] und der [[AVR Butterfly]] von Atmel. Weitere Infos findet man in den Artikeln [[AVR#Starterkits|AVR Starterkits]] und [[AVR-Tutorial: Equipment]].<br />
<br />
* Programmiersoftware und -[[AVR In System Programmer |hardware]] z. B. PonyProg (siehe auch: [[Pony-Prog Tutorial]]) oder [[AVRDUDE]] mit [[STK200]]-Dongle oder die von Atmel verfügbare Hard- und Software ([[STK500]], Atmel AVRISP, [[AVR-Studio]]).<br />
<br />
* Nicht unbedingt erforderlich, aber zur Simulation und zum Debuggen unter MS-Windows recht nützlich: [[AVR-Studio]].<br />
<br />
* Wer unter Windows und Linux gleichermassen entwickeln will, der sollte sich die [http://www.eclipse.org/ IDE Eclipse for C/C++ Developers] und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] ansehen. Beide sind unter Windows und Linux einfach zu installieren, siehe auch [[AVR Eclipse]]. Ebenfalls unter Linux und Windows verfügbar ist die Entwicklungsumgebung [http://www.codeblocks.org/ Code::Blocks]<ref>Aktuelle, stabile Versionen sind als Nightly Builds regelmäßig im [http://forums.codeblocks.org/ Forum] verfügbar.</ref>. Innerhalb dieser Entwicklungsumgebung können ohne die Installation zusätzlicher Plugins "AVR-Projekte" angelegt werden. Für Linux gibt es auch noch das [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=25220 KontrollerLab].<br />
<br />
= Was tun, wenn's nicht klappt? =<br />
<br />
* Herausfinden, ob es tatsächlich ein avr(-gcc) spezifisches Problem ist oder nur die eigenen C-Kenntnisse einer Auffrischung bedürfen. Allgemeine C-Fragen kann man eventuell "beim freundlichen Programmierer zwei Büro-, Zimmer- oder Haustüren weiter" loswerden. Ansonsten: [[C]]-Buch (gibt's auch "gratis" online) lesen.<br />
<br />
* Die [[AVR Checkliste]] durcharbeiten.<br />
<br />
* Die '''[http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc]''' lesen, vor allem (aber nicht nur) den Abschnitt Related Pages/'''Frequently Asked Questions''' = Oft gestellte Fragen (und Antworten dazu). Z.Zt leider nur in englischer Sprache verfügbar.<br />
<br />
* Den Artikel [[AVR-GCC]] in diesem Wiki lesen.<br />
<br />
* Das [http://www.mikrocontroller.net/forum/gcc GCC-Forum auf www.mikrocontroller.net] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das avr-gcc-Forum bei [http://www.avrfreaks.net AVRfreaks] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das [http://lists.gnu.org/archive/html/avr-gcc-list/ Archiv der avr-gcc Mailing-Liste] nach vergleichbaren Problemen absuchen.<br />
<br />
* Nach Beispielcode suchen. Vor allem im ''Projects''-Bereich von [http://www.avrfreaks.net AVRfreaks] (anmelden).<br />
<br />
* Google oder yahoo befragen schadet nie.<br />
<br />
* Bei Problemen mit der Ansteuerung interner AVR-Funktionen mit C-Code: das Datenblatt des Controllers lesen (ganz und am Besten zweimal). Datenblätter sind auf den [http://www.atmel.com Atmel Webseiten] als pdf-Dateien verfügbar. Das komplette Datenblatt (complete) und nicht die Kurzfassung (summary) verwenden.<br />
<br />
* Die Beispielprogramme im [[AVR-Tutorial]] sind zwar in AVR-Assembler verfasst, Erläuterungen und Vorgehensweisen sind aber auch auf C-Programme übertragbar.<br />
<br />
* Einen Beitrag in eines der Foren oder eine Mail an die Mailing-Liste schreiben. Dabei möglichst viel Information geben: Controller, Compilerversion, genutzte Bibliotheken, Ausschnitte aus dem Quellcode oder besser ein [http://www.mikrocontroller.net/topic/72767#598986 Testprojekt] mit allen notwendigen Dateien, um das Problem nachzuvollziehen, sowie genaue Fehlermeldungen bzw. Beschreibung des Fehlverhaltens. Bei Ansteuerung externer Geräte die Beschaltung beschreiben oder skizzieren (z. B. mit [http://www.tech-chat.de/ Andys ASCII Circuit]). Siehe dazu auch: '''[http://www.tty1.net/smart-questions_de.html "Wie man Fragen richtig stellt"]'''.<br />
<br />
= Erzeugen von Maschinencode =<br />
<br />
Aus dem C-Quellcode erzeugt der avr-gcc Compiler (zusammen mit Hilfsprogrammen wie z.&nbsp;B. Präprozessor, Assembler und Linker) Maschinencode für den AVR-Controller. Üblicherweise liegt dieser Code dann im Intel Hex-Format vor ("Hex-Datei"). Die Programmiersoftware (z.&nbsp;B. [[AVRDUDE]], PonyProg oder AVRStudio/STK500-plugin) liest diese Datei ein und überträgt die enthaltene Information (den Maschinencode) in den Speicher des Controllers. Im Prinzip sind also "nur" der avr-gcc-Compiler (und wenige Hilfsprogramme) mit den "richtigen" Optionen aufzurufen, um aus C-Code eine "Hex-Datei" zu erzeugen. Grundsätzlich stehen dazu drei verschiedene Ansätze zur Verfügung:<br />
<br />
* Die Verwendung einer integrierten Entwicklungsumgebung (IDE = '''I'''ntegrated '''D'''evelopment '''E'''nvironment), bei der alle Einstellungen z.&nbsp;B. in Dialogboxen durchgeführt werden können. Unter Anderem kann AVRStudio ab Version 4.12 (kostenlos auf [http://www.atmel.com/ atmel.com]) zusammen mit WinAVR als integrierte Entwicklungsumgebung für den Compiler avr-gcc genutzt werden (dazu müssen AVRStudio und WinAVR auf dem Rechner installiert sein). Weitere IDEs (ohne Anspruch auf Vollständigkeit): [http://www.eclipse.org/ Eclipse for C/C++ Developers] (d.h. inkl. CDT) und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] (für diverse Plattformen, u.a. Linux und MS Windows, IDE und Plugin kostenlos), [http://sourceforge.net/projects/kontrollerlab KontrollerLab] (Linux/KDE, kostenlos). [http://www.atmanecl.com/EnglishSite/SoftwareEnglish.htm AtmanAvr] (MS Windows, relativ günstig), KamAVR (MS-Windows, kostenlos, wird augenscheinlich nicht mehr weiterentwickelt), [http://www.amctools.com/vmlab.htm VMLab] (MS Windows, ab Version 3.12 ebenfalls kostenlos). Integrierte Entwicklungsumgebungen unterscheiden sich stark in Ihrer Bedienung und stehen auch nicht für alle Plattformen zur Verfügung, auf denen der Compiler ausführbar ist (z.&nbsp;B. AVRStudio nur für MS-Windows). Zur Anwendung des avr-gcc Compilers mit IDEs sei hier auf deren Dokumentation verwiesen. <br />
<br />
* Die Nutzung des Programms make mit passenden Makefiles. In den folgenden Abschnitten wird die Generierung von Maschinencode für einen AVR ("hex-Datei") aus C-Quellcode ("c-Dateien") anhand von "make" und den "Makefiles" näher erläutert. Viele der darin beschriebenen Optionen findet man auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio (AVRStudio generiert ein makefile in einem Unterverzeichnis des Projektverzeichnisses). <br />
<br />
* Das Generieren des Programms ohne IDE und ohne Makefile. In diesem Fall muss die Quellcodedatei durch eine vorgefertigte Kommandofolge an den Compiler übergeben werden. Der Artikel [[C ohne Makefile]] zeigt, wie das funktioniert. Diese Vorgehensweise empfiehlt sich jedoch nur für kleine Programme, die nicht auf verschiedene Quellcodedateien verteilt sind.<br />
<br />
Beim Wechsel vom makefile-Ansatz nach WinAVR-Vorlage zu AVRStudio ist darauf zu achten, dass AVRStudio (Stand: AVRStudio Version 4.13) bei einem neuen Projekt die Optimierungsoption (vgl. Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|AVR-GCC-Tutorial/Exkurs: Makefiles]], typisch: -Os) nicht einstellt und die mathematische Bibliothek der avr-libc (libm.a, Linker-Option -lm) nicht einbindet. (Hinweis: Bei Version 4.16 wird beides bereits gesetzt). Beides ist Standard bei Verwendung von makefiles nach WinAVR-Vorlage und sollte daher auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio "manuell" eingestellt werden, um auch mit AVRStudio kompakten Code zu erzeugen.<br />
<br />
= Einführungsbeispiel =<br />
<br />
Zum Einstieg ein kleines Beispiel, an dem die Nutzung des Compilers und der Hilfsprogramme (der sogenannten ''Toolchain'') demonstriert wird. Detaillierte Erläuterungen folgen in den weiteren Abschnitten dieses Tutorials.<br />
<br />
Das Programm soll auf einem AVR Mikrocontroller einige Ausgänge ein- und andere ausschalten. Das Beispiel ist für einen ATmega16 programmiert ([http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf Datenblatt]), kann aber sinngemäß für andere Controller der AVR-Familie modifiziert werden. <br />
<br />
Ein kurzes Wort zur Hardware: Bei diesem Programm werden alle Pins von PORTB auf Ausgang gesetzt, und einige davon werden auf HIGH andere auf LOW gesetzt. Das kann je nach angeschlossener Hardware an diesen Pins kritisch sein. Am ungefährlichsten ist es, wenn nichts an den Pins angeschlossen ist und man die Funktion des Programmes durch eine Spannungsmessung mit einem Multimeter kontrolliert. Die Spannung wird dabei zwischen GND-Pin und den einzelnen Pins von PORTB gemessen.<br />
<br />
Zunächst der Quellcode der Anwendung, der in einer Text-Datei mit dem Namen ''main.c'' abgespeichert wird.<br />
<br />
<syntaxhighlight lang="c"><br />
/* Alle Zeichen zwischen Schrägstrich-Stern <br />
und Stern-Schrägstrich sind Kommentare */<br />
<br />
// Zeilenkommentare sind ebenfalls möglich<br />
// alle auf die beiden Schrägstriche folgenden<br />
// Zeichen einer Zeile sind Kommentar<br />
<br />
#include <avr/io.h> // (1)<br />
<br />
int main (void) { // (2)<br />
<br />
DDRB = 0xFF; // (3)<br />
PORTB = 0x03; // (4)<br />
<br />
while(1) { // (5)<br />
/* "leere" Schleife*/ // (6)<br />
} // (7)<br />
<br />
/* wird nie erreicht */<br />
return 0; // (8)<br />
}<br />
</syntaxhighlight><br />
<br />
# In dieser Zeile wird eine sogenannte Header-Datei eingebunden. In <code>avr/io.h</code> sind die Registernamen definiert, die im späteren Verlauf genutzt werden. Auch unter Windows wird ein&nbsp;<code>/</code> zur Kennzeichnung von Unterverzeichnissen in Include-Dateinamen verwendet und kein&nbsp;<code>\</code>.<br />
# Hier beginnt das eigentliche Programm. Jedes C-Programm beginnt mit den Anweisungen in der Funktion <code>main</code>.<br />
# Die Anschlüsse eines AVR (Pins) werden zu Blöcken zusammengefasst, einen solchen Block bezeichnet man als Port. Beim ATmega16 hat jeder Port 8 Anschlüsse, bei kleineren AVRs können einem Port auch weniger als 8 Anschlüsse zugeordnet sein. Da per Definition (Datenblatt) alle gesetzten Bits in einem Datenrichtungsregister den entsprechenden Anschluss auf Ausgang schalten, werden mit DDRB=0xff alle Anschlüsse des Ports B als Ausgänge eingestellt.<br />
# Die den ersten beiden Bits des Ports zugeordneten Anschlüsse (PB0 und PB1) werden 1, alle anderen Anschlüsse des Ports B (PB2-PB7) zu 0. Aktivierte Ausgänge (logisch 1 oder "high") liegen auf Betriebsspannung (VCC, meist 5 Volt), nicht aktivierte Ausgänge führen 0 Volt (GND, Bezugspotential). Es ist sinnvoll, sich möglichst frühzeitig eine alternative Schreibweise beizubringen, die wegen der leichteren Überprüfbarkeit und Portierbarkeit oft im weiteren Tutorial und in Forenbeiträgen benutzt wird. Die Zuordnung sieht in diesem Fall so aus, Näheres dazu im Artikel [[Bitmanipulation]]:<syntaxhighlight lang="c">PORTB = (1<<PB1) | (1<<PB0);</syntaxhighlight><br />
# ist der Beginn der sogenannte ''Hauptschleife'' (main-loop). Dies ist eine Endlosschleife, welche kontinuierlich wiederkehrende Befehle enthält.<br />
# In diesem Beispiel ist die Hauptschleife leer. Der Controller durchläuft die Schleife immer wieder, ohne dass etwas passiert. Eine solche Schleife ist notwendig, da es auf dem Controller kein Betriebssystem gibt, das nach Beendigung des Programmes die Kontrolle übernehmen könnte. Ohne diese Schleife kehrt das Programm aus <code>main</code> zurück, alle Interrupts werden deaktiviert und eine Endlosschleife betreten.<br />
# Ende der Hauptschleife und Sprung zur passenden, öffnenden Klammer, also zu 5.<br />
# ist das Programmende. Die Zeile ist nur aus Gründen der C-Kompatibilität enthalten: <syntaxhighlight lang="c">int main(void)</syntaxhighlight> besagt, dass die Funktion einen int-Wert zurückgibt. Die Anweisung wird aber nicht erreicht, da das Programm die Hauptschleife nie verlässt.<br />
<br />
Um diesen Quellcode in ein lauffähiges Programm zu übersetzen, wird hier ein Makefile genutzt. Das verwendete Makefile findet sich auf der Seite [[Beispiel Makefile]] und basiert auf der Vorlage, die in WinAVR mitgeliefert wird und wurde bereits angepasst (Controllertyp ATmega16). Man kann das Makefile bearbeiten und an andere Controller anpassen oder sich mit dem Programm MFile menügesteuert ein Makefile "zusammenklicken". Das Makefile speichert man unter dem Namen <code>Makefile</code> (ohne Endung) im selben Verzeichnis, in dem auch die Datei <code>main.c</code> mit dem Programmcode abgelegt ist. Detailliertere Erklärungen zur Funktion von Makefiles finden sich im Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|Exkurs: Makefiles]].<br />
<br />
<pre><br />
D:\beispiel>dir<br />
<br />
Verzeichnis von D:\beispiel<br />
<br />
28.11.2006 22:53 <DIR> .<br />
28.11.2006 22:53 <DIR> ..<br />
28.11.2006 20:06 118 main.c<br />
28.11.2006 20:03 16.810 Makefile<br />
2 Datei(en) 16.928 Bytes<br />
</pre><br />
<br />
Nun gibt man ''make all'' ein. Falls das mit WinAVR installierte Programmers Notepad genutzt wird, gibt es dazu einen Menüpunkt im Tools Menü. Sind alle Einstellungen korrekt, entsteht eine Datei <code>main.hex</code>, in welcher der Code für den AVR enthalten ist. <br />
<pre><br />
D:\beispiel>make all<br />
<br />
-------- begin --------<br />
avr-gcc (GCC) 3.4.6<br />
Copyright (C) 2006 Free Software Foundation, Inc.<br />
This is free software; see the source for copying conditions. There is NO<br />
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.<br />
<br />
Compiling C: main.c<br />
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -f<br />
unsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef<br />
-Wa,-adhlns=obj/main.lst -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c -<br />
o obj/main.o<br />
<br />
Linking: main.elf<br />
avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -funs<br />
igned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -W<br />
a,-adhlns=obj/main.o -std=gnu99 -Wundef -MD -MP -MF .dep/main.elf.d obj/main.o<br />
--output main.elf -Wl,-Map=main.map,--cref -lm<br />
<br />
Creating load file for Flash: main.hex<br />
avr-objcopy -O ihex -R .eeprom main.elf main.hex<br />
</pre><br />
<br />
Der Inhalt der hex-Datei kann nun zum Controller übertragen werden. Dies kann z.&nbsp;B. über In-System-Programming ([[ISP]]) erfolgen, das im [[AVR-Tutorial: Equipment]] beschrieben ist. Makefiles nach der WinAVR/MFile-Vorlage sind für die Nutzung des Programms [[AVRDUDE]] vorbereitet. Wenn man den Typ und Anschluss des Programmiergerätes richtig eingestellt hat, kann mit ''make program'' die Übertragung mittels AVRDUDE gestartet werden. Jede andere Software, die hex-Dateien lesen und zu einem AVR übertragen kann<ref>z.&nbsp;B. [[Pony-Prog_Tutorial|Ponyprog]], yapp, AVRStudio</ref>, kann natürlich ebenfalls genutzt werden.<br />
<br />
Startet man nun den Controller (Reset-Taster oder Stromzufuhr aus/an), werden vom Programm die Anschlüsse PB0 und PB1 auf 1 gesetzt. Man kann mit einem Messgerät nun an diesem Anschluss die Betriebsspannung messen oder eine [[LED]] leuchten lassen (Anode an den Pin, Vorwiderstand nicht vergessen). An den Anschlüssen PB2-PB7 misst man 0 Volt. Eine mit der Anode mit einem dieser Anschlüsse verbundene LED leuchtet nicht.<br />
<br />
= Ganzzahlige Datentypen (Integer) =<br />
<br />
Bei der Programmierung von Mikrokontrollern ist die Definition einiger ganzzahliger Datentypen sinnvoll, an denen eindeutig die Bit-Länge abgelesen werden kann.<br />
<br />
Standardisierte Datentypen werden in der Header-Datei <code>stdint.h</code> definiert, die folgendermaßen eingebunden werden kann:<br />
<syntaxhighlight lang="c">#include <stdint.h></syntaxhighlight><br />
<br />
{| {{Tabelle}}<br />
|+ '''int-Typen aus <code>stdint.h</code> (C99)'''<br/>&nbsp;<br />
|- bgcolor="#d0d0ff"<br />
!colspan="5"| Vorzeichenbehaftete int-Typen<br />
|- bgcolor="#e8e8ff"<br />
! Typname || Bit-Breite ||colspan="2"| Wertebereich<br />
|align="center| '''C-Entsprechung''' (avr-gcc)<br />
|-<br />
|<code>int8_t</code> ||align="right"| 8 || −128 ⋯ 127 || −2<sup>7</sup> ⋯ 2<sup>7</sup>−1 || <code>signed char</code><br />
|-<br />
|<code>int16_t</code> ||align="right"| 16 || −32768 ⋯ 32767 || −2<sup>15</sup> ⋯ 2<sup>15</sup>−1 || <code>signed short</code>, <code>signed int</code><br />
|-<br />
|<code>int32_t</code> ||align="right"| 32 || −2147483648 ⋯ 2147483647 || −2<sup>31</sup> ⋯ 2<sup>31</sup>−1 || <code>signed long</code><br />
|-<br />
|<code>int64_t</code> ||align="right"| 64 || −9223372036854775808 ⋯ 9223372036854775807 || −2<sup>63</sup> ⋯ 2<sup>63</sup>−1 || <code>signed long long</code><br />
|- bgcolor="#d0d0ff"<br />
!colspan="5"| Vorzeichenlose int-Typen<br />
|- bgcolor="#e8e8ff"<br />
! Typname || Bit-Breite ||colspan="2"| Wertebereich<br />
|align="center| '''C-Entsprechung''' (avr-gcc)<br />
|-<br />
|<code>uint8_t</code> ||align="right"| 8 || 0 ⋯ 255 || 0 ⋯ 2<sup>8</sup>−1 || <code>unsigned char</code><br />
|-<br />
|<code>uint16_t</code> ||align="right"| 16 || 0 ⋯ 65535 || 0 ⋯ 2<sup>16</sup>−1 || <code>unsigned short</code>, <code>unsigned int</code><br />
|-<br />
|<code>uint32_t</code> ||align="right"| 32 || 0 ⋯ 4294967295 || 0 ⋯ 2<sup>32</sup>−1 || <code>unsigned long</code><br />
|-<br />
|<code>uint64_t</code> ||align="right"| 64 || 0 ⋯ 18446744073709551615 || 0 ⋯ 2<sup>64</sup>−1 || <code>unsigned long long</code><br />
|}<br />
<br />
Neben den Typen gibt es auch Makros für die Bereichsgrenzen wie <code>INT8_MIN</code> oder <code>UINT16_MAX</code>. Siehe dazu auch: [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html Dokumentation der avr-libc: Standard Integer Types].<br />
<br />
= Grundsätzlicher Programmaufbau eines µC-Programms =<br />
<br />
Wir unterscheiden zwischen 2 verschiedenen Methoden, um ein<br />
Mikrocontroller-Programm zu schreiben, und zwar völlig unabhängig davon, in<br />
welcher Programmiersprache das Programm geschrieben wird.<br />
<br />
== Sequentieller Programmablauf ==<br />
<br />
[[Image:Sequentielle Programme.gif|left]]<br />
Bei dieser Programmiertechnik wird eine Endlosschleife programmiert, welche im<br />
Wesentlichen immer den gleichen Aufbau hat. Es wird hier nach dem sogenannten EVA-Prinzip gehandelt. EVA steht für "Eingabe, Verarbeitung, Ausgabe".<br />
{{Absatz}}<br />
<br />
== Interruptgesteuerter Programmablauf ==<br />
<br />
[[Image:Interrupt Programme.gif|left]]<br />
Bei dieser Methode werden beim Programmstart zuerst die gewünschten Interruptquellen aktiviert und dann in eine Endlosschleife gegangen, in welcher Dinge erledigt werden können, welche nicht zeitkritisch sind. Wenn ein Interrupt ausgelöst wird, so wird automatisch die zugeordnete Interruptfunktion ausgeführt.<br />
{{Absatz}}<br />
<br />
= Zugriff auf Register =<br />
<br />
Die AVR-Controller verfügen über eine Vielzahl von Registern. Die meisten<br />
davon sind sogenannte Schreib-/Leseregister. Das heißt, das Programm kann die<br />
Inhalte der Register sowohl auslesen als auch beschreiben.<br />
<br />
Register haben einen besonderen Stellenwert bei den AVR Controllern. Sie dienen dem Zugriff auf die Ports und die Schnittstellen des Controllers. Wir unterscheiden zwischen 8-Bit und 16-Bit Registern. Vorerst behandeln wir die 8-Bit Register.<br />
<br />
Einzelne Register sind bei allen AVRs vorhanden, andere wiederum nur bei bestimmten Typen. So sind beispielsweise die Register, welche für den Zugriff auf den UART notwendig sind, selbstverständlich nur bei denjenigen Modellen vorhanden, welche über einen integrierten Hardware UART bzw. USART verfügen.<br />
<br />
Die Namen der Register sind in den Headerdateien zu den entsprechenden AVR-Typen definiert. Dazu muss man den Namen der controllerspezifischen Headerdatei nicht kennen. Es reicht aus, die allgemeine Headerdatei ''avr/io.h'' einzubinden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
</syntaxhighlight><br />
<br />
Ist im Makefile der MCU-Typ z.&nbsp;B. mit dem Inhalt atmega8 definiert (und wird somit per -mmcu=atmega8 an den Compiler übergeben), wird beim Einlesen der io.h-Datei implizit ("automatisch") auch die iom8.h-Datei mit den Register-Definitionen für den ATmega8 eingelesen.<br />
<br />
<!-- Wohl besser als Anhang - spaeter... --><br />
Intern wird diese "Automatik" wie folgt realisiert: Der Controllertyp wird dem Compiler als Parameter übergeben (vgl. ''avr-gcc -c -mmcu=atmega16 [...]'' im Einführungsbeispiel). Wird ein Makefile nach der WinAVR/mfile-Vorlage verwendet, setzt man die Variable ''MCU'', der Inhalt dieser Variable wird dann an passender Stelle für die Compilerparameter verwendet. Der Compiler definiert intern eine dem mmcu-Parameter zugeordnete "Variable" (genauer: ein Makro) mit dem Namen des Controllers, vorangestelltem ''__AVR_'' und angehängten Unterstrichen (z.&nbsp;B. wird bei ''-mmcu=atmega16'' das Makro ''__AVR_ATmega16__'' definiert). Beim Einbinden der Header-Datei ''avr/io.h'' wird geprüft, ob das jeweilige Makro definiert ist und die zum Controller passende Definitionsdatei eingelesen. Zur Veranschaulichung einige Ausschnitte aus einem Makefile:<br />
<br />
<pre><br />
[...]<br />
# MCU Type ("name") setzen:<br />
MCU = atmega16<br />
[...]<br />
<br />
[...]<br />
## Verwendung des Inhalts von MCU (hier atmega16) fuer die <br />
## Compiler- und Assembler-Parameter<br />
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)<br />
ALL_CPPFLAGS = -mmcu=$(MCU) -I. -x c++ $(CPPFLAGS) $(GENDEPFLAGS)<br />
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)<br />
[...]<br />
<br />
[...]<br />
## Aufruf des Compilers:<br />
## mit den Parametern ($(ALL_CFLAGS) ist -mmcu=$(MCU)[...] = -mmcu=atmega16[...]<br />
$(OBJDIR)/%.o : %.c<br />
@echo<br />
@echo $(MSG_COMPILING) $<<br />
$(CC) -c $(ALL_CFLAGS) $< -o $@ <br />
[...]<br />
</pre><br />
<br />
Da --mmcu=atmega16 übergeben wurde, wird __AVR_ATmega16__ definiert und kann in avr/io.h zur Fallunterscheidung genutzt werden:<br />
<br />
<syntaxhighlight lang="c"><br />
// avr/io.h <br />
// (bei WinAVR-Standardinstallation in C:\WinAVR\avr\include\avr)<br />
[...]<br />
#if defined (__AVR_AT94K__)<br />
# include <avr/ioat94k.h><br />
// [...]<br />
#elif defined (__AVR_ATmega16__)<br />
// da __AVR_ATmega16__ definiert ist, wird avr/iom16.h eingebunden:<br />
# include <avr/iom16.h><br />
// [...]<br />
#else<br />
# if !defined(__COMPILING_AVR_LIBC__)<br />
# warning "device type not defined"<br />
# endif<br />
#endif<br />
</syntaxhighlight><br />
<br />
Die Beispiele in den folgenden Abschnitten demonstrieren den Zugriff auf Register anhand der Register für I/O-Ports (PORTx, DDRx, PINx), die Vorgehensweise ist jedoch für alle Register (z.&nbsp;B. die des UART, ADC, SPI) analog.<br />
<br />
== Schreiben in Register ==<br />
<br />
Zum Schreiben kann man Register einfach wie eine Variable setzen.<ref>In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Schreibzugriff über die Funktion outp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt, outp() ist nicht mehr erforderlich.</ref><br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
/* Setzt das Richtungsregister des Ports A auf 0xff <br />
(alle Pins als Ausgang, vgl. Abschnitt Zugriff auf Ports): */<br />
DDRA = 0xff; <br />
<br />
/* Setzt PortA auf 0x03, Bit 0 und 1 "high", restliche "low": */<br />
PORTA = 0x03; <br />
<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binär 00011111 = Hexadezimal 1F<br />
DDRB = 0x1F; /* direkte Zuweisung - unübersichtlich */<br />
<br />
/* Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit<br />
aber übersichtlicher und selbsterklärend: */<br />
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);<br />
<br />
while (1);<br />
}<br />
</syntaxhighlight><br />
<br />
Die ausführliche Schreibweise sollte bevorzugt verwendet werden, da dadurch die Zuweisungen selbsterklärend sind und somit der Code leichter nachvollzogen werden kann. Atmel verwendet sie auch bei Beispielen in Datenblätten und in den allermeisten Quellcodes zu Application-Notes. Mehr zu der Schreibweise mit "|" und "<<" findet man unter [[Bitmanipulation]].<br />
<br />
Der gcc C-Compiler unterstützt ab Version 4.3.0 Konstanten im Binärformat, z.&nbsp;B. DDRB&nbsp;=&nbsp;0b00011111. Diese Schreibweise ist jedoch nur in GNU-C verfügbar und nicht in ISO-C definiert. Man sollte sie daher nicht verwenden, wenn Code mit anderen ausgetauscht oder mit anderen Compilern bzw. älteren Versionen des gcc genutzt werden soll.<br />
<br />
== Verändern von Registerinhalten ==<br />
<br />
Einzelne Bits setzt und löscht man "Standard-C-konform" mittels logischer (Bit-) Operationen. <br />
<br />
<syntaxhighlight lang="c"><br />
x |= (1 << Bitnummer); // Hiermit wird ein Bit in x gesetzt<br />
x &= ~(1 << Bitnummer); // Hiermit wird ein Bit in x geloescht<br />
</syntaxhighlight><br />
<br />
Es wird jeweils nur der Zustand des angegebenen Bits geändert, der vorherige Zustand der anderen Bits bleibt erhalten. <br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
#define MEINBIT 2<br />
...<br />
PORTA |= (1 << MEINBIT); /* setzt Bit 2 an PortA auf 1 */<br />
PORTA &= ~(1 << MEINBIT); /* loescht Bit 2 an PortA */<br />
</syntaxhighlight><br />
<br />
Mit dieser Methode lassen sich auch mehrere Bits eines Registers gleichzeitig setzen und löschen.<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
DDRA &= ~( (1<<PA0) | (1<<PA3) ); /* PA0 und PA3 als Eingaenge */<br />
PORTA |= ( (1<<PA0) | (1<<PA3) ); /* Interne Pull-Up fuer beide einschalten */<br />
</syntaxhighlight><br />
<br />
Bei bestimmten AVR Registern mit Bits, die durch Beschreiben mit einer logischen 1 gelöscht werden, muss eine absolute Zuweisung benutzt werden. Ein ODER löscht in diesen Registern ALLE gesetzten Bits!<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
TIFR2 = (1<<OCF2A); // Nur Bit OCF2A löschen<br />
</syntaxhighlight><br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind nicht mehr erforderlich.<br />
<br />
Siehe auch:<br />
* [[Bitmanipulation]]<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
<br />
== Lesen aus Registern ==<br />
<br />
Zum Lesen kann man auf Register einfach wie auf eine Variable zugreifen. In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Lesezugriff über die Funktion inp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt und inp() ist nicht mehr erforderlich.<br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdint.h><br />
<br />
uint8_t foo;<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
/* kopiert den Status der Eingabepins an PortB <br />
in die Variable foo: */<br />
foo = PINB; <br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Die Abfrage der Zustände von Bits erfolgt durch Einlesen des gesamten Registerinhalts und ausblenden der Bits deren Zustand nicht von Interesse ist. Einige Beispiele zum Prüfen ob Bits gesetzt oder gelöscht sind:<br />
<br />
<syntaxhighlight lang="c"><br />
#define MEINBIT0 0 <br />
#define MEINBIT2 2<br />
<br />
uint8_t i;<br />
<br />
extern test1();<br />
<br />
// Funkion test1 aufrufen, wenn Bit 0 in Register PINA gesetzt (1) ist<br />
i = PINA; // Inhalt in Arbeitsvariable<br />
i = i & 0x01; // alle Bits bis auf Bit 0 ausblenden (bitweise und)<br />
// falls das Bit gesetzt war, hat i den Inhalt 1<br />
if ( i != 0 ) { // Ergebnis ungleich 0 (wahr)? <br />
test1(); // dann muss Bit 0 in i gesetzt sein -> Funktion aufrufen<br />
}<br />
// verkürzt:<br />
if ( ( PINA & 0x01 ) != 0 ) {<br />
test1();<br />
}<br />
// nochmals verkürzt:<br />
if ( PINA & 0x01 ) {<br />
test1();<br />
}<br />
// mit definierter Bitnummer:<br />
if ( PINA & ( 1 << MEINBIT0 ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und/oder Bit 2 gesetzt ist. (Bit 0 und 2 also Wert 5) <br />
// (Bedenke: Bit 0 hat Wert 1, Bit 1 hat Wert 2 und Bit 2 hat Wert 4)<br />
if ( PINA & 0x05 ) {<br />
test1(); // Vergleich <> 0 (wahr), also mindestens eines der Bits gesetzt<br />
}<br />
// mit definierten Bitnummern:<br />
if ( PINA & ( ( 1 << MEINBIT0 ) | ( 1 << MEINBIT2 ) ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und Bit 2 gesetzt sind<br />
if ( ( PINA & 0x05 ) == 0x05 ) { // nur wahr, wenn beide Bits gesetzt<br />
test1();<br />
}<br />
<br />
// Funktion test2() aufrufen, wenn Bit 0 gelöscht (0) ist<br />
i = PINA; // einlesen in temporäre Variable<br />
i = i & 0x01; // maskieren von Bit 0<br />
if ( i == 0 ) { // Vergleich ist wahr, wenn Bit 0 nicht gesetzt ist<br />
test2();<br />
}<br />
// analog mit not-Operator<br />
if ( !i ) {<br />
test2();<br />
}<br />
// nochmals verkürzt:<br />
if ( !( PINA & 0x01 ) ) {<br />
test2();<br />
}<br />
</syntaxhighlight><br />
<br />
== Warten auf einen bestimmten Zustand ==<br />
<br />
Es gibt in der Bibliothek avr-libc Funktionen, die warten, bis ein bestimmter Zustand eines Bits erreicht ist. Es ist allerdings normalerweise eine eher unschöne Programmiertechnik, da in diesen Funktionen "blockierend" gewartet wird. Der Programmablauf bleibt also an dieser Stelle stehen, bis das maskierte Ereignis erfolgt ist. Setzt man den [[Watchdog]] ein, muss man darauf achten, dass dieser auch noch getriggert wird (Zurücksetzen des Watchdogtimers). <br />
<br />
Die Funktion '''loop_until_bit_is_set''' wartet in einer Schleife, bis das definierte Bit gesetzt ist. Wenn das Bit beim Aufruf der Funktion bereits gesetzt ist, wird die Funktion sofort wieder verlassen. Das niederwertigste Bit hat die Bitnummer 0. <br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 2 (das dritte Bit) in Register PINA gesetzt (1) ist */<br />
<br />
#define WARTEPIN PINA<br />
#define WARTEBIT PA2<br />
<br />
// mit der avr-libc Funktion:<br />
loop_until_bit_is_set(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// _nicht_ ungleich 0 (also 0) ist.<br />
while ( !(WARTEPIN & (1 << WARTEBIT)) ) {}<br />
...<br />
</syntaxhighlight><br />
<br />
<br />
Die Funktion '''loop_until_bit_is_clear''' wartet in einer Schleife, bis das definierte Bit gelöscht ist. Wenn das Bit beim Aufruf der Funktion bereits gelöscht ist, wird die Funktion sofort wieder verlassen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 4 (das fuenfte Bit) in Register PINB geloescht (0) ist */<br />
#define WARTEPIN PINB<br />
#define WARTEBIT PB4<br />
<br />
// avr-libc-Funktion:<br />
loop_until_bit_is_clear(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// gesetzt (1) ist <br />
while ( WARTEPIN & (1<<WARTEBIT) ) {}<br />
...<br />
</syntaxhighlight><br />
<br />
Universeller und auch auf andere Plattformen besser übertragbar ist die Verwendung von C-Standardoperationen.<br />
<br />
Siehe auch: <br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
* [[Bitmanipulation]]<br />
<br />
== 16-Bit Register (ADC, ICR1, OCR1x, TCNT1, UBRR) ==<br />
<br />
Einige der Portregister in den AVR-Controllern sind 16 Bit breit. Im Datenblatt sind diese Register üblicherweise mit dem Suffix "L" (Low-Byte) und "H" (High-Byte) versehen. Die avr-libc definiert zusätzlich die meisten dieser Variablen die Bezeichnung ohne "L" oder "H". Auf diese Register kann dann direkt zugegriffen werden. Dies ist zum Beispiel der Fall für Register wie ADC oder TCNT1.<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
uint16_t foo;<br />
<br />
/* setzt die Wort-Variable foo auf den Wert der letzten AD-Wandlung */<br />
foo = ADC; <br />
</syntaxhighlight><br />
<br />
Bei anderen Registern, wie zum Beispiel Baudraten-Register, liegen High- und Low-Teil nicht direkt nebeneinander im SFR-Bereich, so dass ein 16-Bit Zugriff nicht möglich ist und der Zugriff zusammengebastelt werden muss:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
...<br />
uint16_t baud = F_CPU / (UART_BAUD_RATE * 16L) -1;<br />
<br />
UBRRH = (uint8_t) (baud >> 8);<br />
UBRRL = (uint8_t) baud;<br />
...<br />
</syntaxhighlight><br />
<br />
Bei einigen AVR-Typen wie ATmega8 oder ATmega16 teilen sich UBRRH und UCSRC die gleiche Speicher-Adresse. Damit der AVR trotzdem zwischen den beiden Registern unterscheiden kann, bestimmt das Bit7 (URSEL), welches Register tatsächlich beschrieben werden soll. ''1000 0011'' (0x83) adressiert demnach UCSRC und übergibt den Wert ''3''. Und ''0000 0011'' (0x3) adressiert UBRRH und übergibt ebenfalls den Wert ''3''. <br />
<br />
Speziell bei den 16-Bit-Timern und auch beim ADC ist es bei allen Zugriffen auf Datenregister erforderlich, dass diese Daten synchronisiert sind. Wenn z.&nbsp;B. bei einem 16-Bit-Timer das High-Byte des Zählregisters gelesen wurde und vor dem Lesezugriff auf das Low-Byte ein Überlauf des Low-Bytes stattfindet, erhält man einen völlig unsinnigen Wert. Auch die Compare-Register müssen synchron geschrieben werden, da es ansonsten zu unerwünschten Compare-Ereignissen kommen kann. <br />
<br />
Beim ADC besteht das Problem darin, dass zwischen den Zugriffen auf die beiden Teilregister eine Wandlung beendet werden kann und der ADC ein neues Ergebnis in ADCL und ADCH schreiben will, wodurch High- und Low-Byte nicht zusammenpassen.<br />
<br />
Um diese Datenmüllproduktion zu verhindern, gibt es in beiden Fällen eine Synchronisation, die jeweils durch den Zugriff auf das Low-Byte ausgelöst wird:<br />
* Bei den Timer-Registern (das gilt für alle TCNT-, OCR- und ICR-Register bei den 16-Bit-Timern) wird bei einem ''Lesezugriff'' auf das Low-Byte automatisch das High-Byte in ein temporäres Register, das ansonsten nach außen nicht sichtbar ist, geschoben. Greift man nun ''anschließend'' auf das High-Byte zu, dann wird eben dieses temporäre Register gelesen.<br />
* Bei einem ''Schreibzugriff'' auf eines der genannten Register wird das High-Byte in besagtem temporären Register zwischengespeichert und erst beim Schreiben des Low-Bytes werden ''beide'' gleichzeitig in das eigentliche Register übernommen.<br />
<br />
Das bedeutet für die Reihenfolge:<br />
* Lesezugriff: Erst Low-Byte, dann High-Byte<br />
* Schreibzugriff: Erst High-Byte, dann Low-Byte<br />
<br />
Des weiteren ist zu beachten, dass es für all diese 16-Bit-Register nur ein einziges temporäres Register gibt, so dass das Auftreten eines Interrupts, in dessen Handler ein solches Register manipuliert wird, bei einem durch ihn unterbrochenen Zugriff i.d.R. zu Datenmüll führt. 16-Bit-Zugriffe sind generell nicht atomar! Wenn mit Interrupts gearbeitet wird, kann es erforderlich sein, vor einem solchen Zugriff auf ein 16-Bit-Register die Interrupt-Bearbeitung zu deaktivieren.<br />
<br />
Beim ADC-Datenregister ADCH/ADCL ist die Synchronisierung anders gelöst. Hier wird beim Lesezugriff (ADCH/ADCL sind logischerweise read-only) auf das Low-Byte ADCL beide Teilregister für Zugriffe seitens des ADC so lange gesperrt, bis das High-Byte ADCH ausgelesen wurde. Dadurch kann der ADC nach einem Zugriff auf ADCL keinen neuen Wert in ADCH/ADCL ablegen, bis ADCH gelesen wurde. Ergebnisse von Wandlungen, die zwischen einem Zugriff auf ADCL und ADCH beendet werden, gehen verloren!<br />
<br />
Nach einem Zugriff auf ADCL muss grundsätzlich ADCH gelesen werden!<br />
<br />
In beiden Fällen – also sowohl bei den Timern als auch beim ADC – werden vom C-Compiler 16-Bit Pseudo-Register zur Verfügung gestellt (z.&nbsp;B. TCNT1H/TCNT1L → TCNT1, ADCH/ADCL → ADC bzw. ADCW), bei deren Verwendung der Compiler automatisch die richtige Zugriffsreihenfolge regelt. In C-Programmen sollten grundsätzlich diese 16-Bit-Register verwendet werden! Sollte trotzdem ein Zugriff auf ein Teilregister erforderlich sein, sind obige Angaben zu berücksichtigen.<br />
<br />
Es ist darauf zu achten, dass auch ein Zugriff auf die 16-Bit-Register vom Compiler in zwei 8-Bit-Zugriffe aufgeteilt wird und dementsprechend genauso nicht-atomar ist wie die Einzelzugriffe. Auch hier gilt, dass u.U. die Interrupt-Bearbeitung gesperrt werden muss, um Datenmüll zu vermeiden.<br />
<br />
Beim ADC gibt es für den Fall, dass eine Auflösung von 8 Bit ausreicht, die Möglichkeit, das Ergebnis "linksbündig" in ADCH/ADCL auszurichten, so dass die relevanten 8 MSB in ADCH stehen. In diesem Fall muss bzw. sollte nur ADCH ausgelesen werden.<br />
<br />
ADC und ADCW sind unterschiedliche Bezeichner für das selbe Registerpaar. Üblicherweise kann man in C-Programmen ADC verwenden, was analog zu den anderen 16-Bit-Registern benannt ist. ADCW (ADC Word) existiert nur deshalb, weil die Headerdateien auch für Assembler vorgesehen sind und es bereits einen Assembler-Befehl namens ''adc'' gibt. <br />
<br />
Im Umgang mit 16-Bit Registern siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Related Pages/Frequently Asked Questions/Nr. 8<br />
* Datenblatt Abschnitt ''Accessing 16-bit Registers''<br />
<br />
== IO-Register als Parameter und Variablen ==<br />
<br />
Um Register als Parameter für eigene Funktionen übergeben zu können, muss man sie als einen volatile uint8_t Pointer übergeben. Zum Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <util/delay.h><br />
<br />
uint8_t key_pressed (volatile uint8_t *inputreg, uint8_t inputbit)<br />
{<br />
static uint8_t last_state = 0;<br />
<br />
if (last_state == (*inputreg & (1<<inputbit)))<br />
return 0; /* keine Änderung */<br />
<br />
/* Wenn doch, warten bis etwaiges Prellen vorbei ist: */<br />
_delay_ms(20);<br />
<br />
/* Zustand für nächsten Aufruf merken: */<br />
last_state = *inputreg & (1<<inputbit);<br />
<br />
/* und den entprellten Tastendruck zurückgeben: */<br />
return *inputreg & (1<<inputbit);<br />
}<br />
<br />
/* Beispiel für einen Funktionsaufruf: */<br />
<br />
void foo (void)<br />
{<br />
uint8_t i = key_pressed (&PINB, PB1);<br />
}<br />
</syntaxhighlight><br />
<br />
Ein Aufruf der Funktion mit call by value würde Folgendes bewirken: Beim Funktionseintritt wird nur eine Kopie des momentanen Portzustandes angefertigt, die sich unabhängig vom tatsächlichen Zustand das Ports nicht mehr ändert, womit die Funktion wirkungslos wäre. Die Übergabe eines Zeigers wäre die Lösung, wenn der Compiler nicht optimieren würde. Denn dadurch wird im Programm nicht von der Hardware gelesen, sondern wieder nur von einem Abbild im Speicher. Das Ergebnis wäre das gleiche wie oben. Mit dem Schlüsselwort volatile sagt man nun dem Compiler, dass die entsprechende Variable entweder durch andere Softwareroutinen (Interrupts) oder durch die Hardware verändert werden kann.<br />
<br />
Siehe auch: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass avr-libc FAQ: "How do I pass an IO port as a parameter to a function?"]<br />
<br />
= Zugriff auf IO-Ports =<br />
<br />
Jeder AVR implementiert eine unterschiedliche Menge an GPIO-Registern<br />
(GPIO - General Purpose Input/Output). Diese Register dienen dazu:<br />
* einzustellen welche der Anschlüsse ("Beinchen") des Controllers als Ein- oder Ausgänge dienen<br />
* bei Ausgängen deren Zustand festzulegen<br />
* bei Eingängen deren Zustand zu erfassen<br />
<br />
Mittels GPIO werden digitale Zustände gesetzt und erfasst, d.h. die Spannung an einem Ausgang wird ein- oder ausgeschaltet und an einem Eingang wird erfasst, ob die anliegende Spannung über oder unter einem bestimmten Schwellwert liegt. Im Datenblatt Abschnitt Electrical Characteristics/DC Characteristics finden sich die Spannungswerte (V_OL, V_OH für Ausgänge, V_IL, V_IH für Eingänge).<br />
<br />
Die Verarbeitung von analogen Eingangswerten und die Ausgabe von Analogwerten wird in Kapitel [[AVR-GCC-Tutorial#Analoge_Ein-_und_Ausgabe|Analoge Ein- und Ausgabe]] behandelt.<br />
<br />
Die physischen Ein- und Ausgänge werden bei AVR-Controllern zu logischen Ports gruppiert.<br />
<br />
Alle Ports werden über Register gesteuert. Dazu sind jedem Port 3 Register zugeordnet:<br />
<br />
{| class="wikitable"<br />
|- <br />
! width="10%"| DDRx<br />
| Datenrichtungsregister für Port'''x'''. <br />
'''x''' entspricht '''A''', '''B''', ''' C''' usw. je nach gewünschtem Port. Bit im Register gesetzt (1) für Ausgang, Bit gelöscht (0) für Eingang.<br />
|- <br />
! PINx<br />
| Eingangsadresse für Port'''x'''. <br />
Zustand des Ports. Die Bits in PINx entsprechen dem Zustand der als Eingang definierten Portpins. Bit 1 wenn Pin "high", Bit 0 wenn Portpin low.<br />
|-<br />
! PORTx<br />
| Datenregister für Port'''x'''. <br />
Dieses Register wird verwendet, um die Ausgänge eines Ports anzusteuern. Bei Pins, die mittels DDRx auf Eingang geschaltet wurden, können über PORTx<br />
die internen Pull-Up Widerstände aktiviert oder deaktiviert werden (1 = aktiv).<br />
|}<br />
<br />
Die folgenden Beispiele gehen von einem AVR aus, der sowohl Port A als auch Port B besitzt. Sie müssen für andere AVRs (zum Beispiel ATmega8/48/88/168) entsprechend angepasst werden.<br />
<br />
== Datenrichtung bestimmen ==<br />
<br />
Zuerst muss die Datenrichtung der verwendeten Pins bestimmt werden. Um dies zu erreichen, wird das Datenrichtungsregister des entsprechenden Ports beschrieben.<br />
<br />
Für jeden Pin, der als Ausgang verwendet werden soll, muss dabei das<br />
entsprechende Bit auf dem Port gesetzt werden. Soll der Pin als Eingang<br />
verwendet werden, muss das entsprechende Bit gelöscht sein.<br />
<br />
Beispiel:<br />
Angenommen am Port B sollen die Pins 0 bis 4 als Ausgänge definiert werden, die noch verbleibenden Pins 5 bis 7 sollen als Eingänge fungieren. Dazu ist es daher notwendig, im für das Port B zuständigen Datenrichtungsregister DDRB folgende Bitkonfiguration einzutragen<br />
<br />
+---+---+---+---+---+---+---+---+<br />
| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |<br />
+---+---+---+---+---+---+---+---+<br />
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br />
<br />
In C liest sich das dann so:<br />
<br />
<syntaxhighlight lang="c"><br />
// in io.h wird u.a. DDRB definiert:<br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binaer 00011111 = Hexadezimal 1F<br />
// direkte Zuweisung - standardkonform */<br />
DDRB = 0x1F; /* <br />
<br />
// Uebersichtliche Alternative - Binaerschreibweise, aber kein ISO-C<br />
DDRB = 0b00011111;<br />
<br />
// Ausfuehrliche Schreibweise: identische Funktionalitaet, mehr Tipparbeit<br />
// aber uebersichtlicher und selbsterklaerend:<br />
DDRB |= (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4); <br />
</syntaxhighlight><br />
<br />
Die Pins 5 bis 7 werden (da 0) als Eingänge geschaltet. Weitere Beispiele:<br />
<br />
<syntaxhighlight lang="c"><br />
// Alle Pins des Ports B als Ausgang definieren:<br />
DDRB = 0xff; <br />
// Pin0 wieder auf Eingang und andere im urspruenglichen Zustand belassen:<br />
DDRB &= ~(1 << DDB0);<br />
// Pin 3 und 4 auf Eingang und andere im urspruenglichen Zustand belassen:<br />
DDRB &= ~((1 << DDB3) | (1 << DDB4));<br />
// Pin 0 und 3 wieder auf Ausgang und andere im ursprünglichen Zustand belassen:<br />
DDRB |= (1 << DDB0) | (1 << DDB3);<br />
// Alle Pins auf Eingang:<br />
DDRB = 0x00;<br />
</syntaxhighlight><br />
<br />
== Vordefinierte Bitnummern für I/O-Register ==<br />
<br />
Die Bitnummern (z.&nbsp;B. PCx, PINCx und DDCx für den Port C) sind in den io*.h-Dateien der avr-libc definiert und dienen lediglich der besseren Lesbarkeit. Man muss diese Definitionen nicht verwenden oder kann auch einfach "immer" PAx, PBx, PCx usw. nutzen, auch wenn der Zugriff auf Bits in DDRx- oder PINx-Registern erfolgt. Für den Compiler sind die Ausdrücke (1<<PC7), (1<<DDC7) und (1<<PINC7) identisch zu (1<<7) (genauer: der Präprozessor ersetzt die Ausdrücke (1<<PC7),... zu (1<<7)). Ein Ausschnitt der Definitionen für Port C eines ATmega32 aus der iom32.h-Datei zur Verdeutlichung (analog für die weiteren Ports):<br />
<br />
<syntaxhighlight lang="c"><br />
...<br />
/* PORTC */<br />
#define PC7 7<br />
#define PC6 6<br />
#define PC5 5<br />
#define PC4 4<br />
#define PC3 3<br />
#define PC2 2<br />
#define PC1 1<br />
#define PC0 0<br />
<br />
/* DDRC */<br />
#define DDC7 7<br />
#define DDC6 6<br />
#define DDC5 5<br />
#define DDC4 4<br />
#define DDC3 3<br />
#define DDC2 2<br />
#define DDC1 1<br />
#define DDC0 0<br />
<br />
/* PINC */<br />
#define PINC7 7<br />
#define PINC6 6<br />
#define PINC5 5<br />
#define PINC4 4<br />
#define PINC3 3<br />
#define PINC2 2<br />
#define PINC1 1<br />
#define PINC0 0<br />
</syntaxhighlight><br />
<br />
<br />
== Digitale Signale ==<br />
<br />
Am einfachsten ist es, digitale Signale mit dem Mikrocontroller zu erfassen bzw. auszugeben.<br />
<br />
== Ausgänge ==<br />
Will man als Ausgang definierte Pins (entsprechende DDRx-Bits = 1) auf Logisch 1 setzen, setzt man die entsprechenden Bits im Portregister.<br />
<br />
Mit dem Befehl<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB = 0x04; /* besser PORTB=(1<<PB2) */<br />
<br />
// Uebersichtliche Alternative - Binaerschreibweise<br />
PORTB = 0b00000100; /* direkte Zuweisung - uebersichtlich */<br />
<br />
</syntaxhighlight><br />
wird also der Ausgang an Pin PB2 gesetzt (Beachte, dass die Bits immer ''von 0 an'' gezählt werden, das niederwertigste Bit ist also Bitnummer 0 und nicht etwa Bitnummer 1).<br />
<br />
Man beachte, dass bei der Zuweisung mittels '''=''' immer alle Pins gleichzeitig angegeben werden. Man sollte also, wenn nur bestimmte Ausgänge geschaltet werden sollen, zuerst den aktuellen Wert des Ports einlesen und das Bit des gewünschten Ports in diesen Wert einfließen lassen. Will man also nur den dritten Pin (Bit Nr. 2) an Port B auf "high" setzen und den Status der anderen Ausgänge unverändert lassen, nutze man diese Form:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB = PORTB | 0x04; /* besser: PORTB = PORTB | ( 1<<PB2 ) */<br />
/* vereinfacht durch Nutzung des |= Operators : */<br />
PORTB |= (1<<PB2);<br />
<br />
/* auch mehrere "gleichzeitig": */<br />
PORTB |= (1<<PB4) | (1<<PB5); /* Pins PB4 und PB5 "high" */<br />
</syntaxhighlight><br />
<br />
"Ausschalten", also Ausgänge auf "low" setzen, erfolgt analog:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB &= ~(1<<PB2); /* loescht Bit 2 in PORTB und setzt damit Pin PB2 auf low */ <br />
PORTB &= ~( (1<<PB4) | (1<<PB5) ); /* Pin PB4 und Pin PB5 "low" */<br />
</syntaxhighlight><br />
Siehe auch [[Bitmanipulation]]<br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind in aktuellen Versionen der avr-libc nicht mehr enthalten und auch nicht mehr erforderlich.<br />
<br />
''Falls der Anfangszustand von Ausgängen kritisch ist, muss die Reihenfolge beachtet werden, mit der die Datenrichtung (DDRx) eingestellt und der Ausgabewert (PORTx) gesetzt wird:''<br />
<br />
Für Ausgangspins, die mit Anfangswert "high" initialisiert werden sollen:<br />
* zuerst die Bits im PORTx-Register setzen<br />
* anschließend die Datenrichtung auf Ausgang stellen<br />
<br />
Daraus ergibt sich die Abfolge für einen Pin, der bisher als Eingang mit abgeschaltetem Pull-Up konfiguriert war:<br />
* setze PORTx: interner Pull-Up aktiv<br />
* setze DDRx: Ausgang ("high")<br />
<br />
Bei der Reihenfolge erst DDRx und dann PORTx kann es zu einem kurzen "low-Puls" kommen, der auch externe Pull-Up-Widerstände "überstimmt". Die (ungünstige) Abfolge: Eingang -> setze DDRx: Ausgang (auf "low", da PORTx nach Reset 0) -> setze PORTx: Ausgang auf high. Vergleiche dazu auch das Datenblatt Abschnitt ''Configuring the Pin''.<br />
<br />
== Eingänge (Wie kommen Signale in den &micro;C) ==<br />
<br />
Die digitalen Eingangssignale können auf verschiedene Arten zu unserer Logik gelangen.<br />
<br />
=== Signalkopplung ===<br />
<br />
Am einfachsten ist es, wenn die Signale direkt aus einer anderen digitalen Schaltung übernommen werden können. Hat der Ausgang der entsprechenden Schaltung TTL-Pegel dann können wir sogar direkt den Ausgang der Schaltung mit einem Eingangspin von unserem Controller verbinden.<br />
<br />
Hat der Ausgang der anderen Schaltung keinen TTL-Pegel so müssen wir den Pegel über entsprechende Hardware (z.&nbsp;B. Optokoppler, [[Widerstand#Spannungsteiler|Spannungsteiler]], "Levelshifter" aka [[Pegelwandler]]) anpassen.<br />
<br />
Die Masse der beiden Schaltungen muss selbstverständlich miteinander verbunden werden. Der Software selber ist es natürlich letztendlich egal, wie das Signal eingespeist wird. Wir können ja ohnehin lediglich prüfen, ob an einem Pin unseres Controllers eine logische 1 (Spannung größer ca. 0,7*Vcc) oder eine logische 0 (Spannung kleiner ca. 0,2*Vcc) anliegt. Detaillierte Informationen darüber, ab welcher Spannung ein Eingang als 0 ("low") bzw. 1 ("high") erkannt wird, liefert die Tabelle DC Characteristics im Datenblatt des genutzten Controllers.<br />
<br />
{| class="wikitable" style="text-align:center; width:20em"<br />
|+ '''Logikpegel'''<br />
|-<br />
! VCC [V]<br />
! Low [V]<br />
! High [V]<br />
|-<br />
! 5<br />
| 1,0 || 3,5<br />
|-<br />
! 3,3<br />
| 0,66 || 2,3<br />
|-<br />
! 1,8<br />
| 0,36 || 1,26 <br />
|}<br />
<br />
Die Abfrage der Zustände der Portpins erfolgt direkt über den Registernamen.<br />
<br />
{{Warnung|Dabei ist wichtig, zur Abfrage der Eingänge ''nicht'' etwa Portregister '''PORTx''' zu verwenden, sondern Eingangsregister '''PINx'''. Ansonsten liest man nicht den Zustand der Eingänge, sondern den Status der internen Pull-Up-Widerstände. Die Abfrage der Pinzustände über PORTx statt PINx ist ein häufiger Fehler beim AVR-"Erstkontakt".}}<br />
<br />
Will man also die aktuellen Signalzustände von Port D abfragen und in eine Variable namens bPortD abspeichern, schreibt man folgende Befehlszeilen:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdint.h><br />
...<br />
uint8_t bPortD;<br />
...<br />
bPortD = PIND;<br />
...<br />
</syntaxhighlight><br />
<br />
Mit den C-Bitoperationen kann man den Status der Bits abfragen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
/* Fuehre Aktion aus, wenn Bit Nr. 1 (das "zweite" Bit) in PINC gesetzt (1) ist */<br />
if ( PINC & (1<<PINC1) ) {<br />
/* Aktion */<br />
}<br />
<br />
/* Fuehre Aktion aus, wenn Bit Nr. 2 (das "dritte" Bit) in PINB geloescht (0) ist */<br />
if ( !(PINB & (1<<PINB2)) ) {<br />
/* Aktion */<br />
}<br />
...<br />
</syntaxhighlight><br />
Siehe auch [[Bitmanipulation#Bits_prüfen]]<br />
<br />
=== Interne Pull-Up Widerstände ===<br />
<br />
Portpins für Ein- und Ausgänge (GPIO) eines AVR verfügen über zuschaltbare interne Pull-Up Widerstände (nominal mehrere 10kOhm, z.&nbsp;B. ATmega16 20-50kOhm). Diese können in vielen Fällen statt externer Widerstände genutzt werden.<br />
<br />
Die internen Pull-Up Widerstände von Vcc zu den einzelnen Portpins werden über das Register ''' PORTx''' aktiviert bzw. deaktiviert, wenn ein Pin als ''' Eingang''' geschaltet ist.<br />
<br />
Wird der Wert des entsprechenden Portpins auf 1 gesetzt, so ist der Pull-Up Widerstand aktiviert. Bei einem Wert von 0 ist der Pull-Up Widerstand nicht aktiv. Man sollte jeweils entweder den internen oder einen externen Pull-Up Widerstand verwenden, aber nicht beide zusammen.<br />
<br />
Im Beispiel werden alle Pins des Ports D als Eingänge geschaltet und alle Pull-Up Widerstände aktiviert. Weiterhin wird Pin PC7 als Eingang geschaltet und dessen interner Pull-Up Widerstand aktiviert, ohne die Einstellungen für die anderen Portpins (PC0-PC6) zu verändern.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
DDRD = 0x00; /* alle Pins von Port D als Eingang */<br />
PORTD = 0xff; /* interne Pull-Ups an allen Port-Pins aktivieren */<br />
...<br />
DDRC &= ~(1<<PC7); /* Pin PC7 als Eingang */<br />
PORTC |= (1<<PC7); /* internen Pull-Up an PC7 aktivieren */<br />
</syntaxhighlight><br />
<br />
=== Taster und Schalter ===<br />
<br />
Der Anschluss mechanischer Kontakte an den Mikrocontroller, ist zwischen zwei unterschiedliche Methoden zu unterscheiden: ''Active Low'' und ''Active High''.<br />
<br />
<gallery widths="300" heights="300" caption="Anschluss mechanischer Kontakte an einen µC"><br />
Image:Active Low.gif|'''Active Low:''' Bei dieser Methode wird der Kontakt zwischen den Eingangspin des Controllers und Masse geschaltet. Damit bei offenem Schalter der Controller kein undefiniertes Signal bekommt, wird zwischen die Versorgungsspannung und den Eingangspin ein sogenannter '''Pull-Up''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffnetem Schalter auf logisch 1 zu ziehen.<br />
Image:Active High.gif|'''Active High:''' Hier wird der Kontakt zwischen die Versorgungsspannung und den Eingangspin geschaltet. Damit bei offener Schalterstellung kein undefiniertes Signal am Controller ansteht, wird zwischen den Eingangspin und die Masse ein '''Pull-Down''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffneter Schalterstellung auf logisch 0 zu halten. <br />
</gallery><br />
<br />
Der Widerstandswert von Pull-Up- und Pull-Down-Widerständen ist an sich nicht kritisch. Wird er allerdings zu hoch gewählt, ist die Wirkung eventuell nicht gegeben. Als üblicher Wert haben sich 10 kOhm eingebürgert. Die AVRs verfügen an den meisten Pins über zuschaltbare interne Pull-Up Widerstände (vgl. Abschnitt [[AVR-GCC-Tutorial#Interne Pull-Up Widerstände|Interne Pull-Up Widerstände]]), welche insbesondere wie hier bei Tastern und ähnlichen Bauteilen (z.&nbsp;B. Drehgebern) statt externer Bauteile verwendet werden können. Interne Pull-Down-Widerstand sind nicht verfügbar und müssen daher in Form zusätzlicher Bauteile in die Schaltung eingefügt werden.<br />
<br />
==== Taster entprellen ====<br />
<br />
Siehe: ''[[Entprellung#Warteschleifen-Verfahren|Entprellung: Warteschleifen-Verfahren]]<br />
<br />
= Warteschleifen (delay.h) =<br />
<br />
Der Programmablauf kann verschiedene Arten von Wartefunktionen erfordern:<br />
<br />
* Warten im Sinn von Zeitvertrödeln<br />
* Warten auf einen bestimmten Zustand an den I/O-Pins<br />
* Warten auf einen bestimmten Zeitpunkt (siehe Timer)<br />
* Warten auf einen bestimmten Zählerstand (siehe Counter)<br />
<br />
Der einfachste Fall, das Zeitvertrödeln, kann in vielen Fällen und mit großer Genauigkeit anhand der avr-libc Bibliotheksfunktionen _delay_ms() und _delay_us() erledigt werden. Die Bibliotheksfunktionen sind einfachen Zählschleifen (Warteschleifen) vorzuziehen, da leere Zählschleifen ohne besondere Vorkehrungen sonst bei eingeschalteter Optimierung vom avr-gcc-Compiler wegoptimiert werden. Weiterhin sind die Bibliotheksfunktionen bereits darauf vorbereitet, die in F_CPU definierte Taktfrequenz zu verwenden. Außerdem sind die Funktionen der Bibliothek wirklich getestet.<br />
<br />
Einfach!? Schon, aber während gewartet wird, macht der µC nichts anderes mehr (abgesehen von möglicherweise auftretenden Interrupts, falls welche aktiviert sind). Die Wartefunktion blockiert den Programmablauf. Möchte man einerseits warten, um z.&nbsp;B. eine LED blinken zu lassen und gleichzeitig andere Aktionen ausführen z.&nbsp;B. weitere LED bedienen, sollten die Timer/Counter des AVR verwendet werden, siehe Artikel [[Multitasking]].<br />
<br />
Die Bibliotheksfunktionen funktionieren allerdings nur dann korrekt, wenn sie mit zur Übersetzungszeit (beim Compilieren) bekannten konstanten Werten aufgerufen werden. Der Quellcode muss mit eingeschalteter Optimierung übersetzt werden, sonst wird sehr viel Maschinencode erzeugt, und die Wartezeiten stimmen nicht mehr mit dem Parameter überein.<br />
<br />
Eine weitere Einschränkung liegt darin, daß sie möglicherweise länger warten, als erwartet, nämlich in dem Fall, daß Interrupts auftreten und die _delay...()-Funktion unterbrechen. Genau genommen warten diese nämlich nicht eine bestimmte Zeit, sondern verbrauchen eine bestimmte Anzahl von Prozessortakten. Die wiederum ist so bemessen, daß ohne Unterbrechung durch Interrupts die gewünschte Wartezeit erreicht wird.<br />
Wird das Warten aber durch eine oder mehrere ISR unterbrochen, die zusammen 1% Prozessorzeit verbrauchen, dann dauert das Warten etwa 1% länger. Bei 50% Last durch die ISR dauert das Warten doppelt solange wie gewünscht, bei 90% zehnmal solange...<br />
<br />
Abhängig von der Version der Bibliothek verhalten sich die Bibliotheksfunktionen etwas unterschiedlich.<br />
<br />
== avr-libc Versionen bis 1.6 ==<br />
<br />
Die Wartezeit der Funktion _delay_ms() ist auf 262,14ms/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 13,1ms warten. Die Wartezeit der Funktion _delay_us() ist auf 768us/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 38,4µs warten. Längere Wartezeiten müssen dann über einen mehrfachen Aufruf in einer Schleife gelöst werden.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.&nbsp;B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h> /* in älteren avr-libc Versionen <avr/delay.h> */ <br />
<br />
/*<br />
lange, variable Verzögerungszeit, Einheit in Millisekunden<br />
<br />
Die maximale Zeit pro Funktionsaufruf ist begrenzt auf <br />
262.14 ms / F_CPU in MHz (im Beispiel: <br />
262.1 / 3.6864 = max. 71 ms) <br />
<br />
Daher wird die kleine Warteschleife mehrfach aufgerufen,<br />
um auf eine längere Wartezeit zu kommen. Die zusätzliche <br />
Prüfung der Schleifenbedingung lässt die Wartezeit geringfügig<br />
ungenau werden (macht hier vielleicht 2-3ms aus).<br />
*/<br />
<br />
void long_delay(uint16_t ms)<br />
{<br />
for(; ms>0; ms--) _delay_ms(1);<br />
}<br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) // Endlosschleife<br />
{ <br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.&nbsp;B. angeschlossene LED<br />
long_delay(1000); // Eine Sekunde warten...<br />
}<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
== avr-libc Versionen ab 1.7 ==<br />
<br />
_delay_ms() kann mit einem Argument bis 6553,5 ms (= 6,5535 Sekunden) benutzt werden. Es ist nicht möglich, eine Variable als Argument zu übergeben. Wird die früher gültige Grenze von 262,14 ms/F_CPU (in MHz) überschritten, so arbeitet _delay_ms() einfach etwas ungenauer und zählt nur noch mit einer Auflösung von 1/10 ms. Eine Verzögerung von 1000,10 ms ließe sich nicht mehr von einer von 1000,19 ms unterscheiden. Ein Verlust, der sich im Allgemeinen verschmerzen lässt. Dem Programmierer wird keine Rückmeldung gegeben, dass die Funktion ggf. gröber arbeitet, d.h. wenn es darauf ankommt, bitte den Parameter wie bisher geschickt wählen.<br />
<br />
Die Funktion _delay_us() wurde ebenfalls erweitert. Wenn deren maximal als genau behandelbares Argument überschritten wird, benutzt diese intern _delay_ms(). Damit gelten in diesem Fall die _delay_ms() Einschränkungen.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus, avr-libc ab Version 1.6<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h><br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) { // Endlosschleife<br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED<br />
_delay_ms(1000); // Eine Sekunde +/-1/10000 Sekunde warten...<br />
// funktioniert nicht mit Bibliotheken vor 1.6<br />
<br />
}<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
Die _delay_ms() und die _delay_us aus '''avr-libc 1.7.0''' sind fehlerhaft. _delay_ms () läuft 4x schneller als erwartet. Abhilfe ist eine korrigierte Includedatei: [http://www.mikrocontroller.net/topic/196738#1943039]<br />
<br />
= Programmieren mit Interrupts =<br />
<br />
<div style="float:right; margin:2em;"><br />
[[Image:Interrupt Programme.gif]]<br />
</div><br />
Nachdem wir nun alles Wissenswerte für die serielle Programmerstellung<br />
gelernt haben nehmen wir jetzt ein völlig anderes Thema in Angriff, nämlich<br />
die Programmierung unter Zuhilfenahme der Interrupts des AVR.<br />
<br />
Tritt ein Interrupt auf, unterbricht (engl. interrupts) der Controller die Verarbeitung des Hauptprogramms und verzweigt zu einer Interruptroutine. Das Hauptprogramm wird also beim Eintreffen eines Interrupts unterbrochen, die Interruptroutine ausgeführt und danach erst wieder das Hauptprogramm an der Unterbrechungsstelle fortgesetzt (vgl. die Abbildung).<br />
<br />
Um Interrupts verarbeiten zu können, ist folgendes zu beachten:<br />
<br />
* Für jede aktivierte Interruptquelle ist eine Funktion zu programmieren, in der die beim Auftreten des jeweiligen Interrupts erforderlichen Verarbeitungsschritte enthalten sind. Für diese Funktion existieren verschiedene Bezeichnungen. Üblich sind die englischen Begriffe Interrupt-Handler oder Interrupt-Service-Routinen (ISR), man findet aber auch die Bezeichnungen Interruptverarbeitungs- oder -behandlungsroutine oder auch kurz Interruptroutine. Zum Beispiel wird üblicherweise in der ISR zur Verarbeitung des Empfangsinterrupts eines UARTs (UART-RX Interrupt) das empfangene Zeichen in einen Zwischenspeicher (FIFO-Buffer) kopiert, dessen Inhalt später von anderen Programmteilen geleert wird. Sofern der Zwischenspeicher ausreichend groß ist, geht also kein Zeichen verloren, auch wenn im Hauptprogramm zeitintensive Operationen durchgeführt werden.<br />
* Die benötigten Interrupts sind in den jeweiligen Funktionsbausteinen einzuschalten. Dies erfolgt über das jeweilige Aktivierungsbit (Interrupt Enable) in einem der Hardwareregister (z.B. RX(Complete)Interrupt Enable eines UARTs)<br />
* Sämtliche Interrupts werden über einen weiteren globalen Schalter aktiviert und deaktiviert. Zur Verarbeitung der Interrupts ist dieser Schalter zu aktivieren (sei(), siehe unten).<br />
<br />
Alle Punkte sind zu beachten. Fehlt z.B. die globale Aktivierung, werden Interruptroutinen auch dann nicht aufgerufen, wenn sie im Funktionsbaustein eingeschaltet sind und eine Behandlungsroutine verhanden ist.<br />
<br />
Siehe auch<br />
<br />
* [http://www.mikrocontroller.net/forum/read-1-235092.html#new Ausführlicher Thread im Forum]<br />
* Artikel [[Interrupt]]<br />
* Artikel [[Multitasking]]<br />
{{Clear}}<br />
<br />
== Anforderungen an Interrupt-Routinen ==<br />
<br />
Um unliebsamen Überraschungen vorzubeugen, sollten einige Grundregeln bei der Implementierung der Interruptroutinen beachtet werden. Interruptroutinen sollten möglichst kurz und schnell abarbeitbar sein, daraus folgt:<br />
<br />
* Keine umfangreichen Berechnungen innerhalb der Interruptroutine. (*)<br />
* Keine langen Programmschleifen.<br />
* Obwohl es möglich ist, während der Abarbeitung einer Interruptroutine andere oder sogar den gleichen Interrupt wieder zuzulassen, wird davon ohne genaue Kenntnis der internen Abläufe dringend abgeraten.<br />
<br />
Interruptroutinen (ISRs) sollten also möglichst kurz sein und keine Schleifen mit vielen Durchläufen enthalten. Längere Operationen können meist in einen "Interrupt-Teil" in einer ISR und einen "Arbeitsteil" im Hauptprogramm aufgetrennt werden. Z.B. Speichern des Zustands aller Eingänge im EEPROM in bestimmten Zeitabständen: ISR-Teil: Zeitvergleich (Timer,RTC) mit Logzeit/-intervall. Bei Übereinstimmung ein globales Flag setzen (volatile bei Flag-Deklaration nicht vergessen, s.u.). Dann im Hauptprogramm prüfen, ob das Flag gesetzt ist. Wenn ja: die Daten im EEPROM ablegen und Flag löschen.<br />
<br />
(*)<br />
Hinweis: <br />
Es gibt allerdings die seltene Situation, dass man gerade eingelesene<br />
ADC-Werte sofort verarbeiten muss. Besonders dann, wenn man mehrere Werte sehr<br />
schnell hintereinander bekommt. Dann bleibt einem nichts anderes übrig, als die<br />
Werte noch in der ISR zu verarbeiten. Kommt aber sehr selten vor und sollte<br />
durch geeignete Wahl des Systemtaktes bzw. Auswahl des Controllers vermieden werden!<br />
<br />
== Interrupt-Quellen ==<br />
<br />
Die folgenden Ereignisse können einen Interrupt auf einem AVR AT90S2313 auslösen, wobei die Reihenfolge der Auflistung auch die Priorität der Interrupts aufzeigt.<br />
<br />
* Reset<br />
* Externer Interrupt 0<br />
* Externer Interrupt 1<br />
* Timer/Counter 1 Capture Ereignis<br />
* Timer/Counter 1 Compare Match<br />
* Timer/Counter 1 Überlauf<br />
* Timer/Counter 0 Überlauf<br />
* UART Zeichen empfangen<br />
* UART Datenregister leer<br />
* UART Zeichen gesendet<br />
* Analoger Komparator<br />
<br />
Die Anzahl der möglichen Interruptquellen variiert zwischen den verschiedenen Microcontroller-Typen. Im Zweifel hilft ein Blick ins Datenblatt ("Interrupt Vectors").<br />
<br />
== Register ==<br />
<br />
Der AT90S2313 verfügt über 2 Register die mit den<br />
Interrupts zusammenhängen.<br />
<br />
{| class="wikitable"<br />
|- <br />
!width="10%"| GIMSK<br />
| '''G'''eneral '''I'''nterrupt '''M'''a'''sk''' Register.<br /><br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit <br />
| 7 || 6|| 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INT1''' || '''INT0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INT1''' (External '''Int'''errupt Request '''1''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT1'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
'''INT0''' (External '''Int'''errupt Request '''0''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT0'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
|- <br />
! GIFR<br />
| '''G'''eneral '''I'''nterrupt '''F'''lag '''R'''egister.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INTF1''' || '''INTF0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INTF1''' (External '''Int'''errupt Flag '''1''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT1'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
<br />
'''INTF0''' (External '''Int'''errupt Flag '''0''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT0'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
|- <br />
! MCUCR<br />
| '''MCU''' '''C'''ontrol '''R'''egister.<br />
<br />
Das MCU Control Register enthält Kontrollbits für allgemeine MCU-Funktionen.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''-'''|| '''-'''|| '''SE'''|| '''SM'''|| '''ISC11'''|| '''ISC10'''|| '''ISC01'''|| '''ISC00'''<br />
|- <br />
! R/W<br />
| R || R || R/W || R/W || R/W || R/W || R/W || R/W<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
<br />
|}<br />
<br />
'''SE''' ('''S'''leep '''E'''nable)<br />
:Dieses Bit muss gesetzt sein, um den Controller mit dem '''SLEEP'''-Befehl in den Schlafzustand versetzen zu können.<br />
:Um den Schlafmodus nicht irrtümlich einzuschalten, wird empfohlen, das Bit erst unmittelbar vor Ausführung des '''SLEEP'''-Befehls zu setzen.<br />
<br />
'''SM''' ('''S'''leep '''M'''ode)<br />
:Dieses Bit bestimmt über den Schlafmodus.<br />
:Ist das Bit gelöscht, so wird der '''Idle'''-Modus ausgeführt. Ist das Bit gesetzt, so wird der '''Power-Down'''-Modus ausgeführt. (für andere AVR Controller siehe Abschnitt "Sleep-Mode")<br />
<br />
'''ISC11''', '''ISC10''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''1''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT1'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
!width="10%"| ISC11 ||width="10%"| ISC10 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT1''' erzeugt einen Interrupt.<br />
<br />
Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|}<br />
<br />
'''ISC01''', '''ISC00''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''0''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT0'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
!width="10%"| ISC01 ||width="10%"| ISC00 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT0''' erzeugt einen Interrupt.<br />
<br />
Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|}<br />
<br />
|}<br />
<br />
== Allgemeines über die Interrupt-Abarbeitung ==<br />
<br />
Wenn ein Interrupt eintrifft, wird automatisch das '''Global Interrupt Enable''' Bit im Status Register '''SREG''' gelöscht und alle weiteren Interrupts unterbunden. Dieses wird automatisch wieder gesetzt, wenn die Interruptroutine beendet wird. Wenn in der Zwischenzeit weitere Interrupts eintreffen, werden die zugehörigen Interrupt-Bits gesetzt und die Interrupts bei Beendigung der laufenden Interrupt-Routine in der Reihenfolge ihrer Priorität ausgeführt. Dies kann<br />
eigentlich nur dann zu Problemen führen, wenn ein hoch priorisierter Interrupt ständig und in kurzer Folge auftritt. Dieser sperrt dann möglicherweise alle anderen Interrupts mit niedrigerer Priorität. Dies ist einer der Gründe, weshalb die Interrupt-Routinen sehr kurz gehalten werden sollen. Es ist möglich das GIE-Bit in der ISR zu setzen und so schon wieder weitere Interrupts zuzulassen - allerdings sollte man damit vorsichtig sein und genau wissen was man damit macht. Kritisch wird es vor allem wenn der gleiche Interrupt noch einmal kommt, bevor die ISR abgearbeitet ist. <br />
<br />
<!-- === Das Status-Register ===<br />
<br />
Es gilt auch zu beachten, dass das Status-Register während der Abarbeitung einer Interruptroutine nicht automatisch gesichert wird. Falls notwendig, muss dies vom Programmierer selber vorgesehen werden. --><br />
<br />
== Interrupts mit avr-gcc ==<br />
<br />
<!-- ''Anmerkung eines Nutzers: Ich habe mir das Thema hier angearbeitet und hatte am Anfang starke Probleme: Jeder Interrupt muss nochmals einzeln aktiviert werden. Es reicht nicht nur per ''sei()'' die Interrupts global zu aktiveren.'' - mthomas: Hoffentlich duch die modifizerte Einleitung etwas offensichtlicher erläutert. Ansonsten bitte per Eintrag auf die Diskussionseite nochmals melden) --> <br />
<!-- Selbstverständlich können alle interruptspezifischen Registerzugriffe wie gewohnt über I/O-Adressierung vorgenommen werden. Etwas einfacher geht es jedoch, wenn wir die vom Compiler zur Verfügung gestellten Mittel einsetzen.--><br />
Funktionen zur Interrupt-Verarbeitung werden in den Includedateien ''interrupt.h'' der avr-libc zur Verfügung gestellt (bei älterem Quellcode zusätzlich ''signal.h'').<br />
<br />
<syntaxhighlight lang="c"><br />
// fuer sei(), cli() und ISR():<br />
#include <avr/interrupt.h><br />
</syntaxhighlight><br />
<br />
Das Makro '''sei()''' schaltet die Interrupts ein. Eigentlich wird nichts anderes gemacht, als das '''Global Interrupt Enable''' Bit im Status Register gesetzt.<br />
<br />
<syntaxhighlight lang="c"><br />
sei();<br />
</syntaxhighlight><br />
<br />
Das Makro '''cli()''' schaltet die Interrupts aus, oder anders gesagt, das '''Global Interrupt Enable''' Bit im Status Register wird gelöscht.<br />
<br />
<syntaxhighlight lang="c"><br />
cli();<br />
</syntaxhighlight><br />
<br />
Oft steht man vor der Aufgabe, dass eine Codesequenz nicht unterbrochen werden darf. Es liegt dann nahe, zu Beginn dieser Sequenz ein cli() und am Ende ein sei() einzufügen. Dies ist jedoch ungünstig, wenn die Interrupts vor Aufruf der Sequenz deaktiviert waren und danach auch weiterhin deaktiviert bleiben sollen. Ein sei() würde ungeachtet des vorherigen Zustands die Interrupts aktivieren, was zu unerwünschten Seiteneffekten führen kann. Die aus dem folgenden Beispiel ersichtliche Vorgehensweise ist in solchen Fällen vorzuziehen:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <inttypes.h><br />
<br />
//...<br />
<br />
void NichtUnterbrechenBitte(void)<br />
{<br />
uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister<br />
<br />
tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) sichern<br />
cli(); // Interrupts global deaktivieren<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
/* Beispiel Anfang<br />
JTAG-Interface eines ATmega16 per Software deaktivieren <br />
und damit die JTAG-Pins an PORTC für "general I/O" nutzbar machen<br />
ohne die JTAG-Fuse-Bit zu aendern. Dazu ist eine "timed sequence"<br />
einzuhalten (vgl Datenblatt ATmega16, Stand 10/04, S. 229): <br />
Das JTD-Bit muss zweimal innerhalb von 4 Taktzyklen geschrieben <br />
werden. Ein Interrupt zwischen den beiden Schreibzugriffen wuerde <br />
die erforderliche Sequenz "brechen", das JTAG-Interface bliebe<br />
weiterhin aktiv und die IO-Pins weiterhin für JTAG reserviert. */<br />
<br />
MCUCSR |= (1<<JTD);<br />
MCUCSR |= (1<<JTD); // 2 mal in Folge ,vgl. Datenblatt fuer mehr Information<br />
<br />
/* Beispiel Ende */<br />
<br />
SREG = tmp_sreg; // Status-Register wieder herstellen <br />
// somit auch das I-Flag auf gesicherten Zustand setzen<br />
}<br />
<br />
void NichtSoGut(void)<br />
{<br />
cli();<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
sei();<br />
}<br />
<br />
<br />
int main(void)<br />
{<br />
//...<br />
<br />
cli(); <br />
// Interrupts global deaktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// auch nach Aufruf der Funktion deaktiviert<br />
<br />
sei();<br />
// Interrupts global aktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// weiterhin aktiviert<br />
//...<br />
<br />
/* Verdeutlichung der unguenstigen Vorgehensweise mit cli/sei: */<br />
cli(); <br />
// Interrupts jetzt global deaktiviert <br />
<br />
NichtSoGut();<br />
// nach Aufruf der Funktion sind Interrupts global aktiviert <br />
// dies ist mglw. ungewollt!<br />
//...<br />
<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
<!-- mt: besser so nicht(?), lieber "datenblattkonform"<br />
<br />
<font face="Courier New">'''timer_enable_int (unsigned char ints);<br /><br />
'''</font>Schaltet Timerbezogene Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle<br />
Timerinterrupts ausgeschaltet, ansonsten muss in '''ints''' angegeben werden,<br />
welche Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">timer_enable_int (1 << TOIE1));<br /><br />
</font>'''Achtung: Wenn ein Timerinterrupt eingeschaltet wird während ein<br />
anderer Timerinterrupt bereits läuft, dann müssen beide Bits angegeben werden<br />
sonst wird der andere Timerinterrupt versehentlich ausgeschaltet.<br />
<br />
<font face="Courier New">'''enable_external_int (unsigned char ints);<br /><br />
'''</font>Schaltet die externen Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle externen<br />
Interrrups ausgeschaltet, ansonsten muss in '''ints''' angegeben werden, welche<br />
Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">enable_external_int ((1<<br />
</font>'''Schaltet die externen Interrupts 0 und 1 ein.<br />
<br />
Nachdem nun die Interrupts aktiviert sind, braucht es selbstverständlich noch den auszuführenden Code, der ablaufen soll, wenn ein Interrupt eintrifft.<br />
--><br />
Zu den aktivierten Interrupts ist eine Funktion zu programmieren, deren Code aufgerufen wird, wenn der betreffende Interrupt auftritt (Interrupt-Handler, Interrupt-Service-Routine). Dazu existiert die Definition (ein Makro) '''ISR'''.<br />
<br />
=== ISR ===<br />
<br />
(''ISR()'' ersetzt bei neueren Versionen der avr-libc ''SIGNAL()''. SIGNAL sollte nicht mehr genutzt werden, zur Portierung von SIGNAL nach ISR siehe den [[AVR-GCC-Tutorial#Anhang|Anhang]].)<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
//...<br />
ISR(Vectorname) /* vormals: SIGNAL(siglabel) dabei Vectorname != siglabel ! */<br />
{<br />
/* Interrupt Code */<br />
}<br />
</syntaxhighlight><br />
<br />
Mit ''ISR'' wird eine Funktion für die Bearbeitung eines Interrupts eingeleitet. Als Argument muss dabei die Benennung des entsprechenden Interruptvektors angegeben werden. Diese sind in den jeweiligen Includedateien IOxxxx.h zu finden. Die Bezeichnung entspricht dem Namen aus dem Datenblatt, bei dem die Leerzeichen durch Unterstriche ersetzt sind und ein ''_vect'' angehängt ist.<br />
<br />
Als Beispiel ein Ausschnitt aus der Datei für den ATmega8 (bei WinAVR Standardinstallation in C:\WinAVR\avr\include\avr\iom8.h) in der neben den aktuellen Namen für ''ISR'' (*_vect) noch die Bezeichnungen für das inzwischen nicht mehr aktuelle ''SIGNAL'' (SIG_*) enthalten sind.<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
/* $Id: iom8.h,v 1.13 2005/10/30 22:11:23 joerg_wunsch Exp $ */<br />
<br />
/* avr/iom8.h - definitions for ATmega8 */<br />
//...<br />
<br />
/* Interrupt vectors */<br />
<br />
/* External Interrupt Request 0 */<br />
#define INT0_vect _VECTOR(1)<br />
#define SIG_INTERRUPT0 _VECTOR(1)<br />
<br />
/* External Interrupt Request 1 */<br />
#define INT1_vect _VECTOR(2)<br />
#define SIG_INTERRUPT1 _VECTOR(2)<br />
<br />
/* Timer/Counter2 Compare Match */<br />
#define TIMER2_COMP_vect _VECTOR(3)<br />
#define SIG_OUTPUT_COMPARE2 _VECTOR(3)<br />
<br />
/* Timer/Counter2 Overflow */<br />
#define TIMER2_OVF_vect _VECTOR(4)<br />
#define SIG_OVERFLOW2 _VECTOR(4)<br />
<br />
/* Timer/Counter1 Capture Event */<br />
#define TIMER1_CAPT_vect _VECTOR(5)<br />
#define SIG_INPUT_CAPTURE1 _VECTOR(5)<br />
<br />
/* Timer/Counter1 Compare Match A */<br />
#define TIMER1_COMPA_vect _VECTOR(6)<br />
#define SIG_OUTPUT_COMPARE1A _VECTOR(6)<br />
<br />
/* Timer/Counter1 Compare Match B */<br />
#define TIMER1_COMPB_vect _VECTOR(7)<br />
#define SIG_OUTPUT_COMPARE1B _VECTOR(7)<br />
<br />
//...<br />
</syntaxhighlight><br />
<br />
<!--Vor Nutzung von SIGNAL muss ebenfalls die Header-Datei signal.h eingebunden werden.--> <br />
Mögliche Funktionsrümpfe für Interruptfunktionen sind zum Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
/* veraltet: #include <avr/signal.h> */<br />
<br />
ISR(INT0_vect) /* veraltet: SIGNAL(SIG_INTERRUPT0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(TIMER0_OVF_vect) /* veraltet: SIGNAL(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(USART_RXC_vect) /* veraltet: SIGNAL(SIG_UART_RECV) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
// und so weiter und so fort...<br />
</syntaxhighlight><br />
<br />
Auf die korrekte Schreibweise der Vektorbezeichnung ist zu achten. Der gcc-Compiler prüft erst ab Version 4.x, ob ein Signal/Interrupt der angegebenen Bezeichnung tatsächlich in der Includedatei definiert ist und gibt andernfalls eine Warnung aus. Bei WinAVR (ab 2/2005) wurde die Überprüfung auch in den mitgelieferten Compiler der Version 3.x integriert. Aus dem gcc-Quellcode Version 3.x selbst erstellte Compiler enthalten die Prüfung nicht (vgl. [[AVR-GCC]]). <br />
<br />
Während der Ausführung der Funktion sind alle weiteren Interrupts automatisch gesperrt. Beim Verlassen der Funktion werden die Interrupts wieder zugelassen.<br />
<br />
Sollte während der Abarbeitung der Interruptroutine ein weiterer Interrupt (gleiche oder andere Interruptquelle) auftreten, so wird das entsprechende Bit im zugeordneten Interrupt Flag Register gesetzt und die entsprechende Interruptroutine automatisch nach dem Beenden der aktuellen Funktion aufgerufen.<br />
<br />
Ein Problem ergibt sich eigentlich nur dann, wenn während der Abarbeitung der aktuellen Interruptroutine mehrere gleichartige Interrupts auftreten. Die entsprechende Interruptroutine wird im Nachhinein zwar aufgerufen jedoch wissen wir nicht, ob nun der entsprechende Interrupt einmal, zweimal oder gar noch öfter aufgetreten ist. Deshalb soll hier noch einmal betont werden, dass Interruptroutinen so schnell wie nur irgend möglich wieder verlassen werden sollten.<br />
<br />
=== Unterbrechbare Interruptroutinen ===<br />
<br />
"Faustregel": im Zweifel '''ISR'''. Die nachfolgend beschriebene Methode nur dann verwenden, wenn man sich über die unterschiedliche Funktionsweise im Klaren ist.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
<br />
ISR(XXX,ISR_NOBLOCK) /* veraltet: INTERRUPT(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt-Code */<br />
}<br />
</syntaxhighlight><br />
<br />
Hierbei steht XXX für den oben beschriebenen Namen des Vektors (also z.&nbsp;B. ''TIMER0_OVF_vect''). Der Unterschied im Vergleich zu einer herkömmlichen ISR ist, dass hier beim Aufrufen der Funktion das '''Global Enable Interrupt''' Bit durch Einfügen einer SEI-Anweisung direkt wieder gesetzt und somit alle Interrupts zugelassen werden &ndash; auch XXX-Interrupts. <br />
<br />
Bei unsachgemässer Handhabung kann dies zu erheblichen Problemen durch Rekursion wie einem Stack-Overflow oder anderen unerwarteten Effekten führen und sollte wirklich nur dann eingesetzt werden, wenn man sich sicher ist, das Ganze auch im Griff zu haben.<br />
<br />
Insbesondere sollte möglichst am ISR-Anfang die auslösende IRQ-Quelle deaktiviert und erst am Ende der ISR wieder aktiviert werden. Robuster als die Verwendung einer NOBLOCK-ISR ist daher folgender ISR-Aufbau:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
<br />
ISR (XXX) <br />
{<br />
// Implementiere die ISR ohne zunaechst weitere IRQs zuzulassen<br />
<br />
<<Deaktiviere die XXX-IRQ>><br />
<br />
// Erlaube alle Interrupts (ausser XXX)<br />
sei();<br />
<br />
//... Code ...<br />
<br />
// IRQs global deaktivieren um die XXX-IRQ wieder gefahrlos <br />
// aktivieren zu koennen<br />
cli();<br />
<br />
<<Aktiviere die XXX-IRQ>><br />
}<br />
</syntaxhighlight><br />
Auf diese Weise kann sich die XXX-IRQ nicht selbst unterbrechen, was zu einer Art Endlosschleife führen würde.<br />
<br />
Siehe auch: Hinweise in [[AVR-GCC]]<br />
<br />
siehe dazu: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html<br />
<br />
== Datenaustausch mit Interrupt-Routinen ==<br />
<br />
Variablen, die sowohl in Interrupt-Routinen (ISR = Interrupt Service Routine(s)) als auch vom übrigen Programmcode geschrieben oder gelesen werden, müssen mit einem '''volatile''' deklariert werden. Damit wird dem Compiler mitgeteilt, dass der Inhalt der Variablen vor jedem Lesezugriff aus dem Speicher gelesen und nach jedem Schreibzugriff in den Speicher geschrieben wird. Ansonsten könnte der Compiler den Code so optimieren, dass der Wert der Variablen nur in Prozessorregistern zwischengespeichert wird, die nichts von der Änderung woanders mitbekommen.<br />
<br />
Zur Veranschaulichung ein Codefragment für eine Tastenentprellung mit Erkennung einer "lange gedrückten" Taste.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <stdint.h><br />
//...<br />
<br />
// Schwellwerte<br />
// Entprellung: <br />
#define CNTDEBOUNCE 10<br />
// "lange gedrueckt:"<br />
#define CNTREPEAT 200<br />
<br />
// hier z.&nbsp;B. Taste an Pin2 PortA "active low" = 0 wenn gedrueckt<br />
#define KEY_PIN PINA<br />
#define KEY_PINNO PA2<br />
<br />
// beachte: volatile! <br />
volatile uint8_t gKeyCounter;<br />
<br />
// Timer-Compare Interrupt ISR, wird z.B. alle 10ms ausgefuehrt<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
// hier wird gKeyCounter veraendert. Die übrigen<br />
// Programmteile müssen diese Aenderung "sehen":<br />
// volatile -> aktuellen Wert immer in den Speicher schreiben<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
}<br />
else {<br />
gKeyCounter = 0;<br />
}<br />
}<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
//...<br />
/* hier: Initialisierung der Ports und des Timer-Interrupts */<br />
//... <br />
// hier wird auf gKeyCounter zugegriffen. Dazu muss der in der<br />
// ISR geschriebene Wert bekannt sein:<br />
// volatile -> aktuellen Wert immer aus dem Speicher lesen<br />
if ( gKeyCounter > CNTDEBOUNCE ) { // Taste mind. 10*10 ms "prellfrei"<br />
if (gKeyCounter == CNTREPEAT) {<br />
/* hier: Code fuer "Taste lange gedrueckt" */<br />
}<br />
else {<br />
/* hier: Code fuer "Taste kurz gedrueckt" */<br />
}<br />
}<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Wird innerhalb einer ISR mehrfach auf eine mit volatile deklarierte Variable zugegriffen, wirkt sich dies ungünstig auf die Verarbeitungsgeschwindigkeit aus, da bei jedem Zugriff mit dem Speicherinhalt abgeglichen wird. Da bei AVR-Controllern ''innerhalb'' einer ISR keine Unterbrechungen zu erwarten sind, bietet es sich an, einen Zwischenspeicher in Form einer lokalen Variable zu verwenden, deren Inhalt zu Beginn und am Ende mit dem der volatile Variable synchronisiert wird. Lokale Variable werden bei eingeschalteter Optimierung mit hoher Wahrscheinlichkeit in Prozessorregistern verwaltet und der Zugriff darauf ist daher nur mit wenigen internen Operationen verbunden. Die ISR aus dem vorherigen Beispiel lässt sich so optimieren:<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter; // Uebernahme in lokale Arbeitsvariable<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (tmp_kc < CNTREPEAT) {<br />
tmp_kc++;<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc; // Zurueckschreiben<br />
}<br />
//...<br />
</syntaxhighlight><br />
<br />
Zum Vergleich die Disassemblies (Ausschnitte der "lss-Dateien", compiliert für ATmega162) im Anschluss. Man erkennt den viermaligen Zugriff auf die Speicheraddresse von ''gKeyCounter'' (hier 0x032A) in der ISR ohne "Cache"-Variable und den zweimaligen Zugriff in der Variante mit Zwischenspeicher. Im Beispiel ist der Vorteil gering, bei komplexeren Routinen kann die Zwischenspeicherung in lokalen Variablen jedoch zu deutlicheren Verbesserungen führen.<br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
876: ca 99 sbic 0x19, 2 ; 25<br />
878: 0a c0 rjmp .+20 ; 0x88e <__vector_13+0x24><br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
87a: 80 91 2a 03 lds r24, 0x032A<br />
87e: 88 3c cpi r24, 0xC8 ; 200 <br />
880: 40 f4 brcc .+16 ; 0x892 <__vector_13+0x28><br />
882: 80 91 2a 03 lds r24, 0x032A<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 02 c0 rjmp .+4 ; 0x892 <__vector_13+0x28><br />
}<br />
else {<br />
gKeyCounter = 0;<br />
88e: 10 92 2a 03 sts 0x032A, r1<br />
892: 8f 91 pop r24<br />
894: 0f 90 pop r0<br />
896: 0f be out 0x3f, r0 ; 63<br />
898: 0f 90 pop r0<br />
89a: 1f 90 pop r1<br />
89c: 18 95 reti<br />
</pre><br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter;<br />
876: 80 91 2a 03 lds r24, 0x032A<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
87a: ca 9b sbis 0x19, 2 ; 25<br />
87c: 02 c0 rjmp .+4 ; 0x882 <__vector_13+0x18><br />
87e: 80 e0 ldi r24, 0x00 ; 0<br />
880: 03 c0 rjmp .+6 ; 0x888 <__vector_13+0x1e><br />
if (tmp_kc < CNTREPEAT) {<br />
882: 88 3c cpi r24, 0xC8 ; 200<br />
884: 08 f4 brcc .+2 ; 0x888 <__vector_13+0x1e><br />
tmp_kc++;<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc;<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 8f 91 pop r24<br />
88e: 0f 90 pop r0<br />
890: 0f be out 0x3f, r0 ; 63<br />
892: 0f 90 pop r0<br />
894: 1f 90 pop r1<br />
896: 18 95 reti<br />
</pre><br />
<br />
=== volatile und Pointer ===<br />
<br />
Bei '''volatile''' in Verbindung mit Pointern ist zu beachten, ob der Pointer selbst oder die Variable, auf die der Pointer zeigt, '''volatile''' ist.<br />
<br />
<syntaxhighlight lang="c"><br />
volatile uint8_t *a; // das Ziel von a ist volatile<br />
<br />
uint8_t *volatile a; // a selbst ist volatile<br />
</syntaxhighlight><br />
<br />
Falls der Pointer volatile ist (zweiter Fall im Beispiel), ist zu beachten, dass der Wert des Pointers, also eine Speicheradresse, intern in mehr als einem Byte verwaltet wird. Lese- und Schreibzugriffe im Hauptprogramm (außerhalb von Interrupt-Routinen) sind daher so zu implementieren, dass alle Teilbytes der Adresse konsistent bleiben, vgl. dazu den folgenden Abschnitt.<br />
<br />
=== Variablen größer 1 Byte ===<br />
<br />
Bei Variablen größer ein Byte, auf die in Interrupt-Routinen und im Hauptprogramm zugegriffen wird, muss darauf geachtet werden, dass die Zugriffe auf die einzelnen Bytes außerhalb der ISR nicht durch einen Interrupt unterbrochen werden. (Allgemeinplatz: AVRs sind 8-bit Controller). Zur Veranschaulichung ein Codefragment:<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
volatile uint16_t gMyCounter16bit;<br />
//...<br />
ISR(...)<br />
{<br />
//...<br />
gMyCounter16Bit++;<br />
//...<br />
}<br />
<br />
int main(void)<br />
{<br />
uint16_t tmpCnt;<br />
//...<br />
// nicht gut: Mglw. hier ein Fehler, wenn ein Byte von MyCounter <br />
// schon in tmpCnt kopiert ist aber vor dem Kopieren des zweiten Bytes <br />
// ein Interrupt auftritt, der den Inhalt von MyCounter verändert.<br />
tmpCnt = gMyCounter16bit; <br />
<br />
<br />
// besser: Änderungen "außerhalb" verhindern -> alle "Teilbytes"<br />
// bleiben konsistent<br />
cli(); // Interrupts deaktivieren<br />
tmpCnt = gMyCounter16Bit;<br />
sei(); // wieder aktivieren<br />
<br />
// oder: vorheriger Status des globalen Interrupt-Flags bleibt erhalten<br />
uint8_t sreg_tmp;<br />
sreg_tmp = SREG; /* Sichern */<br />
cli()<br />
tmpCnt = gMyCounter16Bit;<br />
SREG = sreg_tmp; /* Wiederherstellen */<br />
<br />
// oder: mehrfach lesen, bis man konsistente Daten hat<br />
uint16_t count1 = gMyCounter16Bit;<br />
uint16_t count2 = gMyCounter16Bit;<br />
while (count1 != count2) {<br />
count1 = count2;<br />
count2 = gMyCounter16Bit;<br />
}<br />
tmpCnt = count1;<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Die avr-libc bietet ab Version 1.6.0(?) einige Hilfsfunktionen/Makros, mit der im Beispiel oben gezeigten Funktionalität, die zusätzlich auch sogenannte [http://en.wikipedia.org/wiki/Memory_barrier memory barriers] beinhalten. Diese stehen nach #include <util/atomic.h> zur Verfügung.<br />
<syntaxhighlight lang="c"><br />
//...<br />
#include <util/atomic.h><br />
//...<br />
<br />
// analog zu cli, Zugriff, sei:<br />
ATOMIC_BLOCK(ATOMIC_FORCEON) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
// oder:<br />
<br />
// analog zu Sicherung des SREG, cli, Zugriff und Zurückschreiben des SREG:<br />
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
//...<br />
</syntaxhighlight><br />
<br />
* siehe auch [http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Dokumentation der avr-libc zu atomic.h]<br />
<br />
== Interrupt-Routinen und Registerzugriffe ==<br />
<br />
Falls Register sowohl im Hauptprogramm als auch in Interrupt-Routinen verändert werden, ist darauf zu achten, dass diese Zugriffe sich nicht überlappen. Nur wenige Anweisungen lassen sich in sogenannte "atomare" Zugriffe übersetzen, die nicht von Interrupt-Routinen unterbrochen werden können. <br />
<br />
Zur Veranschaulichung eine Anweisung, bei der ein Bit und im Anschluss drei Bits in einem Register gesetzt werden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
int main(void)<br />
{<br />
//...<br />
PORTA |= (1<<PA0);<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Der Compiler übersetzt diese Anweisungen für einen ATmega128 bei Optimierungsstufe "S" nach:<br />
<br />
<div class="code"><pre><br />
...<br />
PORTA |= (1<<PA0);<br />
d2: d8 9a sbi 0x1b, 0 ; 27 (a)<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
d4: 8b b3 in r24, 0x1b ; 27 (b)<br />
d6: 8c 61 ori r24, 0x1C ; 28 (c)<br />
d8: 8b bb out 0x1b, r24 ; 27 (d)<br />
...<br />
</pre></div><br />
<br />
Das Setzen des einzelnen Bits wird bei eingeschalteter Optimierung für Register im unteren Speicherbereich in eine einzige Assembler-Anweisung (sbi) übersetzt und ist nicht anfällig für Unterbrechungen durch Interrupts. Die Anweisung zum Setzen von drei Bits wird jedoch in drei abhängige Assembler-Anweisungen übersetzt und bietet damit zwei "Angriffspunkte" für Unterbrechungen. Eine Interrupt-Routine könnte nach dem Laden des Ausgangszustands in den Zwischenspeicher (hier Register 24) den Wert des Registers ändern, z.&nbsp;B. ein Bit löschen. Damit würde der Zwischenspeicher nicht mehr mit dem tatsächlichen Zustand übereinstimmen aber dennoch nach der Bitoperation (hier ori) in das Register zurückgeschrieben. <br />
<br />
Beispiel: PORTA sei anfangs 0b00000000. Die erste Anweisung (a) setzt Bit 0 auf '''1''', PORTA ist danach 0b0000000'''1'''. Nun wird im ersten Teil der zweiten Anweisung der Portzustand in ein Register eingelesen (b). Unmittelbar darauf (vor (c)) "feuert" ein Interrupt, in dessen Interrupt-Routine Bit 0 von PORTA gelöscht wird. Nach Verlassen der Interrupt-Routine hat PORTA den Wert 0b00000000. In den beiden noch folgenden Anweisungen des Hauptprogramms wird nun der zwischengespeicherte "alte" Zustand 0b00000001 mit 0b00011100 logisch-'''ODER'''-verknüft (c) und das Ergebnis 0b00011101 in PortA geschrieben (d). Obwohl zwischenzeitlich Bit 0 gelöscht wurde, ist es nach (d) wieder gesetzt. <br />
<br />
Lösungsmöglichkeiten:<br />
* Register ohne besondere Vorkehrungen nicht in Interruptroutinen ''und'' im Hauptprogramm verändern.<br />
* Interrupts vor Veränderungen in Registern, die auch in ISRs verändert werden, deaktivieren ("cli").<br />
* Bits einzeln löschen oder setzen. sbi und cbi können nicht unterbrochen werden. Vorsicht: nur Register im unteren Speicherbereich sind mittels sbi/cbi ansprechbar. Der Compiler kann nur für diese sbi/cbi-Anweisungen generieren. Für Register außerhalb dieses Adressbereichs ("Memory-Mapped"-Register) werden auch zur Manipulation einzelner Bits abhängige Anweisungen erzeugt (lds,...,sts).<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Frequently asked Questions/Fragen Nr. 1 und 8. (Stand: avr-libc Vers. 1.0.4)<br />
<br />
== Interruptflags löschen ==<br />
<br />
Beim Löschen von Interruptflags haben AVRs eine Besonderheit, die auch im Datenblatt beschrieben ist: Es wird zum Löschen eine 1 in das betreffende Bit geschrieben. <br />
<br />
Hinweis:<br /><br />
Bei Registern mit mehreren Interrupt-Flag-Bits (wie die Timer Interrupt Flag Register) '''nicht''' die übliche bitweise VerODERung nehmen, sondern eine direkte Zuweisung machen. Da sonst weitere Flags, als nur das gewünschte, ebenfalls gelöscht werden könnten.<br /><br />
([http://www.mikrocontroller.net/topic/171148#1640133 Erklärung]).<br />
<br />
== Was macht das Hauptprogramm? ==<br />
<br />
Im einfachsten (Ausnahme-)Fall gar nichts mehr. Es ist also durchaus denkbar, ein Programm zu schreiben, welches in der main-Funktion lediglich noch die Interrupts aktiviert und dann in einer Endlosschleife verharrt. Sämtliche Funktionen werden dann in den ISRs abgearbeitet. Diese Vorgehensweise ist jedoch bei den <i>meisten</i> Anwendungen schlecht: man verschenkt eine Verarbeitungsebene und hat außerdem möglicherweise Probleme durch Interruptroutinen, die zu viel Verarbeitungszeit benötigen.<br />
<br />
Für <i>wenige</i> Anwendungen ist diese Vorgehensweise jedoch perfekt: Die Hauptschleife verkommt zu <tt>for(;;) sleep_cpu();</tt> — siehe nächster Abschnitt „Sleep“. Weiterer Vorteil: ISRs brauchen keine(!) Register retten, ein Fall für <tt>ISR(<i>name</i>,ISR_NAKED){ … reti();}</tt>. <i>So</i> können Mikrocontroller für batteriebetriebene Geräte, etwa Fernbedienungen, maximal Energie sparen.<br />
<br />
Normalerweise wird man in den Interruptroutinen nur die bei Auftreten des jeweiligen Interruptereignisses unbedingt notwendigen Operationen ausführen lassen. Alle weniger kritischen Aufgaben werden dann im Hauptprogramm abgearbeitet.<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Interrupts and Signals<br />
<br />
= Sleep-Modes =<br />
<br />
AVR Controller verfügen über eine Reihe von sogenannten [[Sleep Mode |''Sleep-Modes'']] ("Schlaf-Modi"). Diese ermöglichen es, Teile des Controllers abzuschalten. Zum Einen kann damit besonders bei Batteriebetrieb Strom gespart werden, zum Anderen können Komponenten des Controllers deaktiviert werden, die die Genauigkeit des Analog-Digital-Wandlers bzw. des Analog-Comparators negativ beeinflussen. Der Controller wird durch Interrupts aus dem Schlaf geweckt. Welche Interrupts den jeweiligen Schlafmodus beenden, ist einer Tabelle im Datenblatt des jeweiligen Controllers zu entnehmen.<br />
Die Funktionen (eigentlich Makros) der avr-libc stehen nach Einbinden der header-Datei ''sleep.h'' zur Verfügung.<br />
<br />
;set_sleep_mode (uint8_t mode): Setzt den Schlafmodus, der bei Aufruf von sleep() aktiviert wird. In sleep.h sind einige Konstanten definiert (z.&nbsp;B. SLEEP_MODE_PWR_DOWN). Die definierten Modi werden jedoch nicht alle von sämtlichten AVR-Controllern unterstützt.<br />
;sleep_enable(): Aktiviert den gesetzten Schlafmodus, versetzt den Controller aber noch nicht in den Schlafmodus<br />
;sleep_cpu(): Versetzt den Controller in den Schlafmodus .sleep_cpu wird im Prinzip durch die Assembler-Anweisung ''sleep'' ersetzt.<br />
;sleep_disable(): Deaktiviert den gesetzten Schlafmodus<br />
;sleep_mode(): Versetzt den Controller in den mit set_sleep_mode gewählten Schlafmodus. Das Makro entspricht sleep_enable()+sleep_cpu()+sleep_disable(), beinhaltet also nicht die Aktivierung von Interrupts (besser nicht benutzen).<br />
<br />
Bei Anwendung von sleep_cpu() müssen Interrupts also bereits freigeben sein (sei()), da der Controller sonst nicht mehr "aufwachen" kann. sleep_mode() ist nicht geeignet für die Verwendung in ISR Interrupt-Service-Routinen, da bei deren Abarbeitung Interrupts global deaktiviert sind und somit auch die möglichen "Aufwachinterrupts". Abhilfe: stattdessen sleep_enable(), sei(), sleep_cpu(), sleep_disable() und evtl. cli() verwenden (vgl. Dokumentation der avr-libc).<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/sleep.h><br />
<br />
int main(void)<br />
{<br />
...<br />
<br />
while (1) {<br />
...<br />
set_sleep_mode(SLEEP_MODE_PWR_DOWN);<br />
sleep_mode();<br />
<br />
// Code hier wird erst nach Auftreten eines entsprechenden<br />
// "Aufwach-Interrupts" verarbeitet<br />
...<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
In älteren Versionenen der avr-libc wurden nicht alle AVR-Controller durch die sleep-Funktionen richtig angesteuert. Mit avr-libc 1.2.0 wurde die Anzahl der unterstützten Typen jedoch deutlich erweitert. Bei nicht-unterstützten Typen erreicht man die gewünschte Funktionalität durch direkte "[[Bitmanipulation]]" der entsprechenden Register (vgl. Datenblatt) und Aufruf des Sleep-Befehls via Inline-Assembler oder sleep_cpu():<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
// Sleep-Mode "Power-Save" beim ATmega169 "manuell" aktivieren<br />
SMCR = (3<<SM0) | (1<<SE);<br />
asm volatile ("sleep"::); // alternativ sleep_cpu() aus sleep.h<br />
...<br />
</syntaxhighlight><br />
<br />
== Sleep-Modi ==<br />
Die vielen Prozessoren aus der AVR-Familie unterstützen unterschiedliche Sleep-Modi, gefächert nach Vorhandensein von Funktionsblöcken im Controller. Konkrete und verläßliche Auskunft über die tatsächlichen Gegebenheiten finden sich wie immer in den jeweiligen Datenblättern. Die Modi unterscheiden sich darin, welche Funktionsbereiche zum Energiesparen abgeschaltet werden. Davon hängt auch ab, mit welchen Mitteln der Prozessor aus der jeweiligen Schlaftiefe wieder aufgeweckt werden kann.<br />
<br />
;Idle Mode (SLEEP_MODE_IDLE): Die CPU kann durch SPI, USART, Analog Comperator, ADC, TWI, Timer, Watchdog und irgendeinen anderen Interrupt wieder aufgeweckt werden.<br />
<br />
;ADC Noise Reduction Mode (SLEEP_MODE_ADC): In diesem Modus liegt das Hauptaugenmerk darauf, die CPU soweit stillzulegen, dass der ADC möglichst keine Störungen aus dem inneren der CPU auffangen kann, die das Meßergebnis negativ beeinflussen können. Das Aufwachen aus diesem Modus kann ausgelöst werden durch den ADC, externe Interrupts, TWI, Timer und Watchdog.<br />
<br />
;Power-Down Mode (SLEEP_MODE_PWR_DOWN): In diesem Modus wird ein externer Oszillator (Quarz, Quarzoszillator), wenn vorhanden. gestoppt. Geweckt werden kann die CPU durch einen externen Level-Interrupt, TWI, Watchdog, Brown-Out-Reset.<br />
<br />
;Power-Save-Mode (SLEEP_MODE_PWR_SAVE): Power-Save ist identisch zu Power-Down mit einer Ausnahme: Ist der Timer 2 auf die Verwendung eines externen Taktes konfiguriert, so läuft dieser Timer auch im Power-Save weiter und kann die CPU mit einem Interrupt aufwecken.<br />
<br />
;Standby-Mode (SLEEP_MODE_STANDBY, SLEEP_MODE_EXT_STANDBY): Voraussetzung für den Standby-Modus ist die Verwendung eines Quarzes oder eines Quarzoszillators, also einer externen Taktquelle. Ansonsten ist dieser Modus identisch zum Power-Down Modus. Vorteil dieses Modus' ist eine kürzere Aufwachzeit.<br />
<br />
;Abschalten des Brownout Detect (BOD) während der Sleep-Phase (nur P-Typen): Zur Stromersparnis bieten die P-Typen die Möglichkeit den BOD während der Sleep-Phase abzuschalten. Bei einem Atmega88PA beispielsweise, kann dadurch der Stromverbrauch im SLEEP_MODE_PWR_SAVE mit Timer2 im Asynchronmodus mit Uhrenquarz und periodischer Selbstaufweckung um ca. 50% gesenkt werden.<br />
Das Einschalten dieser Funktion geschieht in einer Timed Sequence.<br />
<br />
<syntaxhighlight lang="c"><br />
unsigned char temp0 = MCUCR;<br />
unsigned char temp1 = MCUCR;<br />
temp0 |= (1 << BODS) | (1 << BODSE);<br />
temp1 |= (1 << BODS);<br />
MCUCR = temp0;<br />
MCUCR = temp1;<br />
sleep_cpu();<br />
</syntaxhighlight><br />
<br />
Hierbei ist unbedingt zu beachten, dass das BODS-Bit 3 Takte nach dem Setzen wieder gelöscht wird. Daher muss der Aufruf des Sleep unmittelbar nach dem Setzen erfolgen und das BODS-Bit muss jedes Mal vor einem Sleep Aufruf erneut gesetzt werden.<br />
<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Power Management and Sleep-Modes<br />
* [http://www.mikrocontroller.net/topic/96369#832712 Forenbeitrag] zur "Nichtverwendung" von sleep_mode in ISRs.<br />
<br />
= Zeiger =<br />
Zeiger (engl. ''Pointer'') sind Variablen, die die Adresse von Daten oder Funktionen enthalten und belegen 16 Bits. Die Größe hängt mit dem adressierbaren Speicherbereich zusammen und der GCC reserviert dann den entsprechenden Platz.<br />
Ggf. ist es also günstiger, Indizes auf Arrays (Listen) zu verwenden, so dass der GCC für die Zeigerarithmetik den erforderlichen RAM nur temporär benötigt.<br />
<br />
Siehe auch: [[Zeiger]]<br />
<br />
= Speicherzugriffe =<br />
<br />
Atmel AVR-Controller verfügen typisch über drei Speicher:<br />
<br />
* [[RAM]]: Im RAM (genauer statisches RAM/SRAM) wird vom gcc-Compiler Platz für Variablen reserviert. Auch der Stack befindet sich im RAM. Dieser Speicher ist "flüchtig", d.h. der Inhalt der Variablen geht beim Ausschalten oder einem Zusammenbruch der Spannungsversorgung verloren. Das bedeutet im Umkehrschluss auch, dass der RAM-Inhalt nach RESET vom Pin oder vom Watchdog erhalten bleibt! Der C-Startupcode löscht jedoch den RAM, d.h. setzt alle Bits auf 0. Dadurch erscheinen „normal definierte“ Variablen als 0. Auch Gleitkommazahlen, die schlauerweise so definiert sind, dass eine +0.0 aus lauter Nullbits besteht. Von der Löschung ausschließen kann man RAM-Variablen mit <tt>__attribute__((section(".noinit")))</tt>.<br />
<br />
* Programmspeicher: Ausgeführt als FLASH-Speicher, seitenweise wiederbeschreibbar. Darin ist das Anwendungsprogramm abgelegt.<br />
<br />
* [[EEPROM]]: Nichtflüchtiger Speicher, d.h. der einmal geschriebene Inhalt bleibt auch ohne Stromversorgung erhalten. Byte-weise schreib/lesbar. Im EEPROM werden typischerweise gerätespezifische Werte wie z.&nbsp;B. Kalibrierungswerte von Sensoren abgelegt.<br />
<br />
Einige AVRs besitzen keinen RAM-Speicher, lediglich die Register können als "Arbeitsvariablen"<br />
genutzt werden. Da die Anwendung des avr-gcc auf solch "kleinen" Controllern ohnehin selten sinnvoll ist und auch nur bei einigen RAM-losen Typen nach [http://lightner.net/avr/ATtinyAvrGcc.html "Bastelarbeiten"] möglich ist, werden diese Controller hier nicht weiter berücksichtigt. Auch EEPROM-Speicher ist nicht auf allen Typen verfügbar. Generell sollten die nachfolgenden Erläuterungen auf alle ATmega-Controller und die größeren AT90-Typen übertragbar sein. Für die Typen ATtiny2313, ATtiny26 und viele weitere der "ATtiny-Reihe" gelten die Ausführungen ebenfalls.<br />
<br />
Siehe auch:<br />
* [[Binäre Daten zum Programm hinzufügen]]<br />
== RAM ==<br />
<br />
Die Verwaltung des RAM-Speichers erfolgt durch den Compiler, im Regelfall ist beim Zugriff auf Variablen im RAM nichts Besonderes zu beachten. Die Erläuterungen in jedem brauchbaren C-Buch gelten auch für den vom avr-gcc-Compiler erzeugten Code.<br />
<br />
Um Speicher dynamisch (während der Laufzeit) zu reservieren, kann '''malloc()''' verwendet werden. malloc(size) "alloziert" (~reserviert) einen gewissen Speicherblock mit '''size''' Bytes. Ist kein Platz für den neuen Block, wird NULL (0) zurückgegeben.<br />
<br />
Wird der angelegte Block zu klein (groß), kann die Größe mit realloc() verändert werden. Den allozierten Speicherbereich kann man mit free() wieder freigeben. Wenn das Freigeben eines Blocks vergessen wird spricht man von einem "Speicherleck" (memory leak).<br />
<br />
malloc() legt Speicherblöcke im '''Heap''' an, belegt man zuviel Platz, dann wächst der Heap zu weit nach oben und überschreibt den Stack, und der Controller kommt in Teufels Küche. Das kann leider nicht nur passieren wenn man insgesamt zu viel Speicher anfordert, sondern auch wenn man Blöcke unterschiedlicher Größe in ungünstiger Reihenfolge alloziert/freigibt (siehe Artikel [[Heap-Fragmentierung]]). Aus diesem Grund sollte man malloc() auf Mikrocontrollern sehr sparsam (am besten gar nicht) verwenden.<br />
<br />
Beispiel zur Verwendung von malloc():<br />
<syntaxhighlight lang="c"><br />
#include <stdlib.h><br />
<br />
void foo(void) {<br />
// neuen speicherbereich anlegen,<br />
// platz für 10 uint16<br />
uint16_t* pBuffer = malloc(10 * sizeof(uint16_t));<br />
<br />
// darauf zugreifen, als wärs ein gewohnter Buffer<br />
pBuffer[2] = 5;<br />
<br />
// Speicher (unbedingt!) wieder freigeben<br />
free(pBuffer);<br />
}<br />
</syntaxhighlight><br />
<br />
Wenn (wie in obigem Beispiel) dynamischer Speicher nur für die Dauer einer Funktion benötigt und am Ende wieder freigegeben wird, bietet es sich an, statt malloc() '''alloca()''' zu verwenden. Der Unterschied zu malloc() ist, dass der Speicher auf dem Stack reserviert wird, und beim Verlassen der Funktion automatisch wieder freigegeben wird. Es kann somit kein Speicherleck und keine Fragmentierung entstehen.<br />
<br />
siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/malloc.html AVR Libc Home Page]: Memory Areas and Using malloc()<br />
* [https://www.mikrocontroller.net/topic/479027#5934443 Forumsbeitrag]: RAM Verbrauch auch von lokalen variablen ermitteln<br />
<br />
== Flash mit PROGMEM und pgm_read ==<br />
<br />
→ [http://nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html avr-libc: Doku zu avr/pgmspace.h]<br />
<br />
Ein Zugriff auf Konstanten im Programmspeicher ist mittels avr-gcc erst ab Version 4.7 "transparent" möglich. Um Daten aus dem Flash zu lesen, muss die AVR-Instruktion LPM (''Load from Program Memory'') erzeugt werden, bei Controllern mit mehr als 64kiB Flash auch ELPM.<br />
<br />
Dazu gibt es das AVR-spezifische GCC-Attribut <tt>progmem</tt>, mit dem eine Variablendeklaration im ''static storage''<ref>Variablen der Speicherklasse ''static storage'' haben eine unbegrenzte Lebensdauer. Beispiel für solche Variablen sind globale Variablen, aber auch static-Variablen innerhalb einer Funktion gehören dazu. Beispiele für Variablen, die nicht ''static storage'' sind: auto-Variablen ("normale" lokale Variablen), register-Variablen, durch malloc geschaffene Objekte, etc.</ref> markiert werden kann:<br />
<syntaxhighlight lang="c"><br />
const int value __attribute__((progmem)) = 1;<br />
</syntaxhighlight><br />
<br />
Effekt ist, dass die so markierte Variable nicht im RAM sondern im Flash angelegt wird. Wird durch "normalen" C-Code auf solch eine Variable zugegriffen, wird jedoch aus der gleichen Adresse aus dem RAM gelesen und nicht aus dem Flash! Das ist ein Fehler, den der Compiler aber nicht anzeigt!<br />
<br />
<syntaxhighlight lang="c"><br />
int test = value; // Fehler! PROGMEM Konstanten müssen mit den pgm_read-Funktionen gelesen werden!<br />
</syntaxhighlight><br />
<br />
Zum Lesen aus dem Flash stellt die avr-libc daher zahlreiche Makros zur Verfügung. Zudem wird das Makro <tt>PROGMEM</tt> definiert, das etwas Tipparbeit spart:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
const int value PROGMEM = 1;<br />
</syntaxhighlight><br />
<br />
<tt>progmem</tt> funktioniert im Wesentlichen wie ein Section-Attribut, das die Daten in der Section <tt>.progmem.data</tt> ablegt. Im Gegensatz zum Section-Attribut werden jedoch noch weitere Prüfungen unternommen, ab avr-gcc 4.6 etwa muss die entsprechende Variable <tt>const</tt> sein.<br />
<br />
=== Integer und float ===<br />
<br />
Zum Lesen von Skalaren stellt die avr-libc folgende Makros zu Verfügung, die jeweils ein Argument erhalten: Die 16-Bit Adresse des zu lesenden Wertes<ref>Damit ist der mögliche Speicherbereich für Flash-Konstanten auf 64kiB begrenzt. Einige pgmspace-Funktionen ermöglichen den Lesezugriff auf den gesamten Flash-Speicher, intern via Assembler-Anweisung ELPM. Die Initialisierungswerte des Speicherinhalts jenseits der 64kiB-Marke müssen dann jedoch auf anderem Weg angelegt werden, d.h. nicht per PROGMEM. Evtl. eigene Section und Linker-Optionen. Alt und nicht ganz korrekt: Die avr-libc pgmspace-Funktionen unterstützen nur die unteren 64kiB Flash bei Controllern mit mehr als 64kiB.</ref><br />
<br />
:{| {{Tabelle}}<br />
|+ Übersicht der <tt>pgm_read</tt> Funktionen aus<br/>dem Header <tt>avr/pgmspace.h</tt> der avr-libc<br />
|-<br />
! Gelesener Wert || <tt>pgm_read_xxx</tt> || Anzahl Bytes<br />
|-<br />
| <tt>uint8_t</tt> || <tt>pgm_read_byte</tt> || 1<br />
|-<br />
| <tt>uint16_t</tt> || <tt>pgm_read_word</tt> || 2<br />
|-<br />
| <tt>uint32_t</tt> || <tt>pgm_read_dword</tt> || 4<br />
|-<br />
| <tt>float</tt> || <tt>pgm_read_float</tt><ref>ab avr-libc 1.7.0</ref> || 4<br />
|}<br />
<br />
Soll ein Zeiger gelesen werden, so verwendet man <tt>pgm_read_word</tt> und castet das Ergebnis zum gewünschten Zeiger-Typ.<br />
<br />
;Beispiele:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
/* Byte */<br />
const uint8_t aByte PROGMEM = 123;<br />
<br />
/* int-Array */<br />
const int anArray[] PROGMEM = { 18, 3 ,70 };<br />
<br />
void foo (void)<br />
{<br />
/* Zeiger */<br />
static const uint8_t* const aPointer PROGMEM = &aByte;<br />
<br />
uint8_t a = pgm_read_byte (&aByte);<br />
int a2 = (int) pgm_read_word (&anArray[2]);<br />
const uint8_t* p = (const uint8_t*) pgm_read_word (&aPointer);<br />
}<br />
</syntaxhighlight><br />
<br />
=== Blöcke ===<br />
<br />
In den Flash-Funktionen der avr-libc sind keine der pgm_read_xxxx Nomenklatur folgenden Funktionen, die Speicherblöcke auslesen oder vergleichen. Die enstprechende Funktionen sind Varianten von <tt>memcpy</tt>, <tt>memcmp</tt> und heißt <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, usw. Für weitere Funktionen und deren Prototypen siehe die Dokumentation der avr-libc.<br />
<br />
=== Strings ===<br />
<br />
Strings sind in C nichts anderes als eine Abfolge von Zeichen und einem <tt>'\0'</tt> als Stringende. Der prinzipielle Weg ist daher identisch zum Lesen von Bytes, wobei auf die [[FAQ#Wie funktioniert String-Verarbeitung in C?|Besonderheiten von Strings]] wie 0-Terminierung geachtet werden muss.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
size_t my_string_length (const char *addr)<br />
{<br />
size_t length = 0;<br />
<br />
while (pgm_read_byte (addr++))<br />
{<br />
length++;<br />
}<br />
return length;<br />
}<br />
</syntaxhighlight><br />
<br />
Zur Unterstützung des Programmierers steht das Repertoire der str-Funktionen auch in jeweils eine Variante zur Verfügung, die mit dem Flash-Speicher arbeiten kann. Die Funktionsnamen tragen den Suffix <tt>_P</tt>. Darüber hinaus gibt es das Makro <tt>PSTR</tt>, das ein String-Literal im Flash-Speicher ablegt und die Adresse des Strings liefert:<br />
<br />
Die nachfolgende Funktion liefert 0 zurück, wenn string_im_ram gleich "Hallo Welt" ist. Mit strcmp (String Compare) können wir zwei Strings vergleichen. Der Rückgabewert kann hierbei folgende Werte haben:<br><br />
0 die Strings sind gleich<br />
>0 das erste ungleiche Zeichen in string_im_ram ist größer als in "Hallo Welt"<br />
<0 das erste ungleiche Zeichen in string_im_ram ist kleiner als in "Hallo Welt"<br />
<br><br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
int foo (const char *string_im_ram)<br />
{<br />
return strcmp_P (string_im_ram, PSTR ("Hallo Welt"));<br />
}<br />
</syntaxhighlight><br />
<br />
Zu beachten ist, dass <tt>PSTR</tt> nur innerhalb von Funktionen verwendet werden kann.<br />
<br />
; Array aus Strings:<br />
<br />
Arrays aus Strings im Flash-Speicher werden in zwei Schritten angelegt:<br />
<br />
# Zuerst die einzelnen Elemente des Arrays und<br />
# im Anschluss ein Array, in dem die Startaddressen der Strings abgelegt werden.<br />
<br />
Zum Auslesen wird zuerst die Adresse des gewünschten Elements aus dem Array im Flash-Speicher gelesen, die im Anschluss dazu genutzt wird, um auf das Element (den String) selbst zuzugreifen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
static const char str1[] PROGMEM = "Hund";<br />
static const char str2[] PROGMEM = "Katze";<br />
static const char str3[] PROGMEM = "Maus";<br />
<br />
const char * const array[] PROGMEM = <br />
{<br />
str1, str2, str3<br />
};<br />
<br />
// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]<br />
void read_string (char *buf, size_t i)<br />
{<br />
// Lese die Adresse des i-ten Strings aus array[]<br />
const char *parray = (const char*) pgm_read_ptr (&array[i]);<br />
<br />
// Kopiere den Inhalt der Zeichenkette vom Flash ins RAM<br />
strcpy_P (buf, parray);<br />
}<br />
</syntaxhighlight><br />
<br />
Eine weitere Möglichkeit ist, die Strings in einem 2-dimensionalen char-Array abzulegen anstatt deren Adresse in einem 1-dimensionalen Adress-Array zu speichern.<br />
<br />
Vorteil ist, dass der Code einfacher wird. Nachteil ist, dass bei unterschiedlich langen Strings Speicherplatz verschwendet wird, weil sich die Array-Dimension and der Länge des längsten Strings orientieret. Bei in etwa gleich langen Strings kann es aber sogar Speicherplatz sparen, denn es die Adressen der einzelnen Strings müssen nicht abgespeichert werden.<ref>In unserem Hund-Katze-Maus Beispiel belegt die erste Variante 22 Bytes Daten und 18 Bytes Code, die zweite Variante mit 2-dimensionalem Array belegt 18 Bytes Daten und 20 Bytes Code. Gemessen wurde mit avr-gcc 4.8 -Os für ATmega8.</ref><br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
// Die "6" ist 1 plus die Länge des längsten Strings ("Katze")<br />
const char array[][6] PROGMEM = <br />
{<br />
"Hund", "Katze", "Maus"<br />
};<br />
<br />
// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]<br />
void read_string (char *buf, size_t i)<br />
{<br />
// Kopiere den Inhalt der i-ten Zeichenkette vom Flash ins RAM<br />
strcpy_P (buf, array[i]);<br />
}<br />
</syntaxhighlight><br />
<br />
Siehe dazu auch die avr-libc FAQ: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_rom_array How do I put an array of strings completely in ROM?]<br />
<br />
=== Warum so kompliziert? ===<br />
<br />
Zu dem Thema, warum die Verabeitung von Werten aus dem Flash-Speicher so kompliziert ist, sei hier nur kurz erläutert: Die Harvard-Architektur des AVR weist getrennte Adressräume für Programm (Flash) und Datenspeicher (RAM) auf. Der C-Standard sieht keine unterschiedlichen Adressräume vor.<br />
<br />
Hat man zum Beispiel eine Funktion string_an_uart (const char* s) und übergibt an diese Funktion die Adresse einer Zeichenkette, dann weiß die Funktion nicht, ob die Adresse in den Flash-Speicher oder das RAM zeigt. Weder aus dem Pointer-Wert, also dem Zahlenwert, noch aus dem "const" kann auf den Ort der Ablage geschlossen werden.<br />
<br />
Einige AVR-Compiler bilden die Harvard-Architektur ab, indem sie in einen Pointer nicht nur die Adresse speichern, sondern auch den Ablageort wie ''Flash'' oder ''RAM''. In einem Aufruf einer Funktion wird dann bei Pointer-Parametern neben der Adresse auch der Speicherbereich, auf den der Pointer zeigt, übergeben.<br />
<br />
Dies hat jedoch auch Nachteile, denn bei jedem Zugriff über einen Zeiger muss zur ''Laufzeit'' entschieden werden, wie der Zugriff auszuführen ist und entsprechend länglicher und langsamer wird der erzeugte Code.<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitte Modules/Program Space String Utilities und Abschnitt Modules/Bootloader Support Utilities<br />
<br />
=== Datenzugriff jenseits 64 KiB ===<br />
<br />
Die Zeiger beim <tt>avr-gcc</tt> sind stets 16 Bit breit, können somit also nur 64 KiB Datenspeicher adressieren. Darauf sind auch alle Funktion der libc ausgelegt, welche auf _P enden. Funktionszeiger können beim AVR bis zu 128 KiB Programmspeicher adressieren, weil Funktionsadressen immer 16-Bit-<u>Worte</u> adressieren und nicht Bytes. Der Zugriff auf den RAM ist mit maximal 16 KiB (extern maximal 64 KiB) durch 16-Bit-Zeiger nicht begrenzt.<br />
<br />
Schlauerweise sortiert <tt>avr-gcc</tt> Flash-Konstanten und -Tabellen <i>so</i> um, dass sie an den Anfang des Flash-Speichers, gleich nach der Interrupt-Tabelle, zu liegen kommen. Somit kommt man auch auf Controllern mit mehr als 64 KByte Flash im Normalfall keine Adresse jenseits 64 KiByte erforderlich.<br />
<br />
<small>Auf Controllern mit mehr als 128 KiB Flash bekommen alle Funktionen <i>jenseits</i> 128 KiB ein <b>Trampolin</b> (Sprungbefehl aus 4 Byte) im dem Adressbereich <i>vor</i> 128 KiB. Damit genügt für alle Funktionszeiger 16 Bit. Wird kein Zeiger benötigt, kann der Optimierer das jeweilige Trampolin entfernen.</small><br />
<br />
Um (dennoch) Zugriff jenseits von 64 KiB zu bewerkstelligen gibt es mehrere Möglichkeiten:<br />
<br />
* Address-Spaces wie <tt>__flash1</tt> oder <tt>__memx</tt>, siehe Abschnitt "[[#Jenseits von flash|Jenseits von __flash]]".<br />
* Die Funktionen bzw. Makros <tt>pgm_read_xxx_far</tt> der AVR-Libc ab Version 1.8.0, wie im folgenden beschrieben. Dafür gibt es die Funktion pgm_get_far_address(), um 32-Bit Pointer eines Objekts zu erhalten<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/pgmspace.h><br />
<br />
//===================================================================<br />
// Define an additional section, which will be placed after all others<br />
//--------------------------------------------------------------------<br />
#define FAR_SECTION __attribute__((__section__(".far_section")))<br />
//--------------------------------------------------------------------<br />
<br />
//====================================================================<br />
// Just an example<br />
//====================================================================<br />
<br />
const char MyString[] FAR_SECTION = "Hier liegt mein FAR-Teststring!";<br />
const char MyBmp64[] FAR_SECTION = {0xAA,0xBB,0xCC,0xDD,0xEE,0xFF,0x00};<br />
<br />
int main(void) {<br />
uint32_t ptr = pgm_get_far_address(MyString);<br />
char MyChar;<br />
DDRC = 0xFF;<br />
do {<br />
MyChar = pgm_read_byte_far(ptr++);<br />
PORTC = MyChar;<br />
} while(MyChar);<br />
}<br />
</syntaxhighlight><br />
<br />
D.h. man muss<br />
* Die Definition der neuen Section <tt>FAR_SECTION</tt> einfügen<br />
* Die konstanten Daten mit dieser Section kennzeichnen<br />
<br />
Dem Linker muss man über diese Section nichts mitteilen, er fügt diese automatisch nach allen bestehenden sections im Flash ein. Der Zugriff auf diese Variablen kann nur mittels direkter Pointerarithmetik erfolgen, eine Indizierung von Arrays mit variablem Index ist nicht möglich. Dabei muss die Größe des Datentyps immer manuell berücksichtigt werden, denn der Pointer ist immer ein Bytepointer!<br />
<br />
<syntaxhighlight lang="c"><br />
int n=3;<br />
MyChar = pgm_read_byte_far(pgm_get_far_address(MyBmp64)+n*sizeof(char));<br />
</syntaxhighlight><br />
<br />
Dabei gibt es einige praktische Probleme.<br />
* Beim recht alten AVR-Studio 4.18 wird die Größe des belegten FLASH-Speichers nicht korrekt angezeigt, die Daten landen aber im HEX-File.<br />
* beim moderneren Atmelstudio 6.2 sieht man in der Consolenausgabe die richtige Größe, welche von avr-size ermittelt wurde, diese wird aber dann in der 2. Ausgabe durch Atmelstudio falsch dargestellt<br />
* Die Arduino-IDE rechnet richtig, siehe dieser [https://www.mikrocontroller.net/topic/511511?goto=6568945#6568945 Forumsbeitrag].<br />
<br />
== Flash mit __flash und Embedded-C ==<br />
<br />
Ab Version 4.7 unterstützt avr-gcc ''Adress-Spaces'' gemäß dem Embedded-C Dokument ISO/IEC TR18037. Der geläufigste Adress-Space ist <tt>__flash</tt>, der im Gegensatz zu <tt>progmem</tt> kein GCC-Attribut ist, sondern ein Qualifier und damit syntaktisch ähnlich verwendet wird wie <tt>const</tt> oder <tt>volatile</tt>.<br />
<br />
GCC kennt keine eigene Option zum Aktivieren von Embedded-C, es wird als GNU-C Erweiterung behandelt. Daher müssen C-Module, die Address-Spaces verwenden, mit <tt>-std=gnu99</tt> o.ä. compiliert werden.<br />
<br />
<syntaxhighlight lang="c"><br />
static const __flash int value = 10;<br />
<br />
int get_value (void)<br />
{<br />
return value;<br />
}<br />
</syntaxhighlight><br />
<br />
# Im Gegensatz zu <tt>progmem</tt> sind keine speziellen Bibliotheksfunktionen oder -makros für den Zugriff mehr notwendig: Der Code zum Lesen der Variable ist "normales" C.<br />
# Die Variable wird im richtigen Speicherbereich (Flash) angelegt.<br />
# <tt>__flash</tt> ist nur zusammen mit read-only Objekten oder Zeigern, d.h. nur zusammen mit <tt>const</tt>, erlaubt.<br />
# Zugriffe wie im obigen Beispiel können (weg)optimiert werden. Das Beispiel entspricht einem "<tt>return 10</tt>". Es besteht keine Notwendigkeit, für <tt>value</tt> überhaupt Flash-Speicher zu reservieren.<br />
<br />
Auch Zeiger-Indirektionen sind problemlos möglich. Zu beachten ist, dass <tt>__flash</tt> auf der richtigen Seite des "<tt>*</tt>" in der Zeigerdeklaration bzw. -definition steht:<br />
* '''Rechts vom <tt>*</tt>:''' Der Zeiger selbst liegt im Flash<br />
* '''Links vom <tt>*</tt>:''' Der Zeiger enthält eine Flash-Adresse<br />
<br />
<syntaxhighlight lang="c"><br />
// val ist eine Variable im Flash<br />
const __flash int val = 42;<br />
<br />
// pval liegt auch im Flash und enthält die Adresse von val<br />
const __flash int* const __flash pval = &val;<br />
<br />
int get_val (void)<br />
{<br />
// liest den Wert von val über die in pval abgelegte Adresse<br />
return *pval;<br />
}<br />
</syntaxhighlight><br />
<br />
=== Blöcke ===<br />
<br />
Um Speicherbereiche vom Flash in den RAM zu kopieren, gibt es zwei Möglichkeiten: Zum einen können wie bei <tt>progmem</tt> beschreiben die Funktionen der avr-libc wie <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, <tt>movmem_P</tt>, etc. verwendet werden:<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
// Eine Datenstruktur<br />
typedef struct<br />
{<br />
int id;<br />
char buf[10];<br />
} data_t;<br />
<br />
extern void uart_send (const void*, size_t);<br />
<br />
void send_data (const __flash data_t *pdata)<br />
{<br />
// buf wird auf dem Stack angelegt<br />
data_t buf;<br />
<br />
// Kopiere Daten vom Flash nach buf ins RAM<br />
memcpy_P (&buf, pdata, sizeof (data_t));<br />
<br />
// Sende die Daten in buf<br />
uart_send (&buf, sizeof (data_t));<br />
}<br />
</syntaxhighlight><br />
<br />
Zum anderen kann eine Struktur auch über direktes Kopieren ins RAM geladen werden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdlib.h><br />
<br />
// Eine Datenstruktur<br />
typedef struct<br />
{<br />
int id;<br />
char buf[10];<br />
} data_t;<br />
<br />
extern void uart_send (const void*, size_t);<br />
<br />
void send_data (const __flash data_t *pdata)<br />
{<br />
// Kopiere Daten ins RAM. buf wird auf dem Stack angelegt<br />
const data_t buf = *pdata;<br />
<br />
// Verwendet die Daten in buf<br />
uart_send (&buf, sizeof (data_t));<br />
}<br />
</syntaxhighlight><br />
<br />
=== Strings ===<br />
<br />
Natürlich können auch Strings im Flash abgelegt werden und auch mit Funktionen wie <tt>strcpy_P</tt> aus der avr-libc verarbeitet werden. Zudem ist es möglich, Flash-Zeiger mit der Adresse eines String-Literals zu initialisieren:<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
#define FSTR(X) ((const __flash char[]) { X } )<br />
<br />
const __flash char * const __flash array[] = <br />
{<br />
FSTR ("Hund"), FSTR ("Katze"), FSTR ("Maus")<br />
};<br />
<br />
size_t get_len (uint8_t tier)<br />
{<br />
return strlen_P (array[tier]);<br />
}<br />
</syntaxhighlight><br />
<br />
Leider sieht der Embedded-C Draft nicht vor, String-Literale direkt in einem anderen Adress-Space als ''generic'' anzulegen, so dass hier der Umweg über <tt>FSTR</tt> genommen werden muss. Dieses Konstrukt ist nur ausserhalb von Funktionen möglich und kann daher nicht als Ersatz für <tt>PSTR</tt> aus der avr-libc dienen.<br />
<br />
Soll <tt>array</tt> ein 2-dimensonales Array sein anstatt ein 1-dimensionales Array von Zeigern, dann geht das ohne große Verrenkungen:<br />
<br />
<syntaxhighlight lang="c"><br />
// Die 6 ergibt sich aus 1 plus der Länge des längsten Strings "Katze"<br />
const __flash char array[][6] = <br />
{<br />
"Hund", "Katze", "Maus"<br />
};<br />
</syntaxhighlight><br />
<br />
Weiters besteht die Möglichkeit, <tt>array</tt> analog anzulegen, wie man es mit <tt>PROGMEM</tt> machen würde: Jeder String wird explizit angelegt und seine Adresse bei der Initialisierung von <tt>array</tt> verwendet. Dies entspricht dem ersten Beispiel eines 1-dimensionalen Zeigerarrays:<br />
<br />
<syntaxhighlight lang="c"><br />
static const __flash char strHund[] = "Hund";<br />
static const __flash char strKatze[] = "Katze";<br />
static const __flash char strMaus[] = "Maus";<br />
<br />
const __flash char * const __flash array[] = <br />
{<br />
strHund, strKatze, strMaus<br />
};<br />
</syntaxhighlight><br />
<br />
=== Casts ===<br />
<br />
Embedded C fordert, dass zwei Adress-Spaces entweder disjunkt sind – d.h. sie enthalten keine gemeinsamen Adressen – oder aber ein Space komplett im anderen enthalten ist, also eine Teilmengen-Beziehung besteht. Die Adress-Spaces von avr-gcc sind so implementiert, dass jeder Space Teilmenge jedes anderes ist. Zwar haben Spaces wie RAM und Flash physikalisch keinen Speicherbereich gemein, allerdings ermöglicht diese Implementierung das Casten von Zeigern zu unterschiedlichen Adress-Spaces<ref>Im Gegensatz zu einem Attribute wie <tt>progmem</tt> ist ein (Adress Space) Qualifier Teil des Zeiger-Typs.</ref>: <br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdbool.h><br />
<br />
char read_char (const char *address, bool data_in_flash)<br />
{<br />
if (data_in_flash)<br />
return *(const __flash char*) address;<br />
else<br />
return *address;<br />
}<br />
</syntaxhighlight><br />
<br />
Der Cast selbst erzeugt keinen zusätzlichen Code, da eine RAM-Adresse und eine Flash-Adresse die gleiche Binärdarstellung haben. Allerdings wird über den nach <tt>__flash</tt> gecasteten Zeiger anders zugegriffen, nämlich per LPM.<br />
<br />
=== Jenseits von __flash ===<br />
<br />
Ausser <tt>__flash</tt> gibt es auch folgende Address-Spaces:<br />
<br />
==== <tt>__flash</tt>''N'' ====<br />
<br />
<tt>__flash</tt>''N'' mit ''N'' = 1..5 sind fünf weitere Spaces, die analog zu <tt>__flash</tt> funktionieren und deren Zeiger ebenfalls 16 Bit breit sind. avr-gcc erwartet, dass die zugehörigen Daten, welche in die Section <tt>.progmem</tt>''N''<tt>.data</tt> abgelegt werden, so lokatiert sind, dass das high-Byte der Adresse (Bits 16..23) gerade ''N'' ist.<br />
<br />
Weil Daten- und Code-Layout höchst projektspezifisch sind, werden diese Sections im Standard Linker-Skript nicht beschrieben. Um funktionsfähigen Code zu erhalten, muss daher ein eigenes Linker-Skript zur Verfügung gestellt werden, das diese Sections beschreibt, oder es kann eine Erweiterung des Standard Skripts bereitgestellt werden falls dies möglich ist.<br />
<br />
;Beispiel: Eine Applikation, die <tt>__flash2</tt> verwendet. Die zugehörende Section <tt>.progmem2.data</tt> wird hinter <tt>.text</tt> angeordnet aber vor den Initializern für <tt>.data</tt>. Dazu wird beim Linken das ld-Skript Fragment per <tt>-Tflash12.ld</tt> angegeben, welches dann an der gewünschten Stelle in das default Skript eingefügt wird:<br />
:{| <!-- Tabelle bitte für korrekte Einrückung belassen --><br />
|-<br />
|<pre><br />
SECTIONS<br />
{<br />
.flash2 :<br />
{<br />
. = MAX (ABSOLUTE(0x20000), .);<br />
PROVIDE (__flash2_start = .);<br />
. = ALIGN(2);<br />
*(.flash2.text*)<br />
*(.progmem2.data*)<br />
PROVIDE (__flash2_end = .);<br />
<br />
ASSERT (__flash2_start == __flash2_end || __flash2_start >= ABSOLUTE(0x20000),<br />
"__flash2 data in .progmem2.data below 0x20000");<br />
ASSERT (__flash2_start == __flash2_end || __flash2_end <= ABSOLUTE(0x30000),<br />
"__flash2 data in .progmem2.data exceeds 0x30000");<br />
}<br />
}<br />
INSERT AFTER .text<br />
</pre><br />
|}<br />
<br />
==== <tt>__memx</tt> ====<br />
<br />
Dieser Address-Space implementiert 3-Byte Zeiger und unterstützt Lesen über 64KiB-Segmentgrenzen hinweg. Das MSB (Bit 23) gibt dabei an, ob der <tt>__memx</tt>-Zeiger eine Flash-Adresse enthält (Bit23 = 0) oder eine RAM-Adresse (Bit23 = 1), was folgenden Code erlaubt:<br />
<br />
<syntaxhighlight lang="c"><br />
const __memx int a_flash = 42;<br />
const int a_ram = 100;<br />
<br />
int get_a (const __memx int* pa)<br />
{<br />
return *pa;<br />
}<br />
<br />
int main (void)<br />
{<br />
return get_a (&a_flash) + get_a (&a_ram);<br />
}</syntaxhighlight><br />
<br />
Dies bedeutet, dass erst zur ''Laufzeit'' entschieden werden kann, ob <tt>get_a</tt> die Daten aus dem RAM oder aus dem Flash lesen soll, was <tt>__memx</tt> im Vergleich zu den anderen Address-Spaces langsamer macht. Ausserdem ist zu beachten, dass <tt>__memx</tt>-Zeiger zwar 24-Bit Zeiger sind, die zugrundeliegende Adress-Arithmetik jedoch gemäß dem C-Standard erfolgt, also als 16-Bit Arithmetik. Bestehende Funktion der avr-libc wie z.B. printf_P funktionieren damit ebensowenig wie printf! Wenn man <tt>__memx</tt> verwenden will, braucht man dafür eigene Funktionen.<br />
<br />
=== __flash, progmem und Portierbarkeit ===<br />
<br />
Da ab er aktuellen Compilerversion 4.7 sowohl <tt>__flash</tt> als auch <tt>PROGMEM</tt> und die <tt>pgm_read</tt>-Funktionen zur Verfügung stehen, ergibt sich die Frage, welche Variante "besser" ist und wie zwischen ihnen hin- und her zu portieren ist.<br />
<br />
Zunächst sei erwähnt, dass <tt>__flash</tt> kein Ersatz für <tt>PROGMEM</tt> ist, sondern lediglich eine Alternative dazu. Das "alte" progmem wird weiterhin mir gleicher Semantik unterstützt, so dass alter Code ohne Änderungen mit den neueren Compilerversionen übersetzbar bleibt.<br />
<br />
Von der Codegüte her dürften sich keine großen Unterschiede ergeben. Es ist nicht zu erwarten, dass die eine oder die andere Variante wesentlich besseren oder schlechteren Code erzeugt — von einer Ausnahme abgesehen: Der Wert beim Zugriff ist zur Compilezeit bekannt und kann daher eliminiert werden.<br />
<syntaxhighlight lang="c"><br />
static const __flash char x[] = { 'A', 'V', 'R' };<br />
<br />
char foo (void)<br />
{<br />
return x[2];<br />
}<br />
</syntaxhighlight><br />
Dies wird übersetzt wie "<tt>return 'R';</tt>", und das Array <tt>x[]</tt> kann komplett wegoptimiert werden und entfallen.<br />
<br />
==== progmem → __flash ====<br />
<br />
Portierung in diese Richtung bedeutet, alten Code anzupassen. Zwingend ist die Portierung nicht, da <tt>progmem</tt> weiterhin unterstützt wird.<br />
Allerdings ist eine Quelle mit <tt>__flash</tt> besser lesbar, denn der Code wird von den <tt>pgm_read</tt>-Funktionen befreit, die vor allem bei Mehrfach-Indirektion den Code ziemlich verunstalten und unleserlich machen können.<br />
Weiterer Vorteil von <tt>_flash</tt> ist, daß eine striktere Typprüfung erfolgen kann.<br />
<br />
Eine Portierung wird man in zwei Schritten vornehmen:<br />
<br />
;1. Definitionen von Flash-Variablen werden angepasst:<br />
<br />
Vorher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
static const char hund[] PROGMEM = "Hund";<br />
static const char katze[] PROGMEM = "Katze";<br />
static const char maus[] PROGMEM = "Maus";<br />
<br />
const char * const tier[] PROGMEM = <br />
{<br />
hund, katze, maus<br />
};<br />
</syntaxhighlight><br />
|}<br />
<br />
Nachher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
static const __flash char hund[] = "Hund";<br />
static const __flash char katze[] = "Katze";<br />
static const __flash char maus[] = "Maus";<br />
<br />
const __flash char * const __flash tier[] = <br />
{<br />
hund, katze, maus<br />
};<br />
</syntaxhighlight><br />
|}<br />
<br />
Der Header <tt>avr/pgmspace.h</tt> wird nicht mehr benötigt. Im Gegensatz zu <tt>progmem</tt> müssen Qualifier immer links von der definierten Variablen stehen; bei Attributen wie <tt>progmem</tt> ist das mehr oder weniger egal.<br />
<br />
Nachdem diese Anpassung erfolgreich abgeschlossen ist, folgt Schritt<br />
<br />
; 2. Der Code wird von <tt>pgm_read</tt>-Aufrufen bereinigt:<br />
<br />
Vorher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
extern const char *tier[];<br />
<br />
char first_letter (uint8_t i)<br />
{<br />
const char* ptier = (const char*) pgm_read_word (&tier[i]);<br />
return (char) pgm_read_byte (&ptier[0]);<br />
}<br />
</syntaxhighlight><br />
|}<br />
<br />
Nachher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <stdint.h><br />
<br />
extern const __flash char * const __flash tier[];<br />
<br />
char first_letter (uint8_t i)<br />
{<br />
return tier[i][0];<br />
}<br />
</syntaxhighlight><br />
|}<br />
<br />
=== Von-Neumannisierung „zu Fuß“ ===<br />
<br />
„Wenn der Prophet nicht zum Berg geht, muss der Berg zum Propheten kommen“.<br />
<br />
Bei Mikrocontrollern mit weniger als 64 KiB Gesamtspeicher ist das mit dem <tt>__flash</tt> oder <tt>PROGMEM</tt> nicht nur lästig sondern erfordert eine Vielzahl von Bibliotheksfunktionen (hier: die auf _P enden) die alle fast dasselbe machen.<br />
<br />
Neuere PIC-Mikrocontroller, AVR xMega3 sowie einige wenige ATtiny verfügen bereits über eine Von-Neumannisierung von RAM und Flash in Hardware, nur bei den gängigen AVRs „will der Prophet nicht zum Berg“, da geht das nicht.<br />
<br />
Hier behilft man sich mit einem Satz aus Inline-Funktionen und Makros, die je nach Bit 15 des Zeigers RAM oder Flash lesen. So setzen die Makros <tt>F(x)</tt> (x als String-Konstante) bzw, <tt>FP(x)</tt> (x als Flash-Adresse) das Bit 15 der Adresse. Die darauf ausgerichtete Bibliotheksfunktion (bspw. ein selbst geschriebener <tt>printf()</tt>-Ersatz) verarbeitet dann den Formatstring aus RAM oder Flash und kommt auch mit <tt>"%s"</tt>-Substitutionen problemlos zurecht. Etwa damit:<br />
<br />
<syntaxhighlight lang="c++"><br />
// Von-Neumannisiertes Speicherlesen (RAM oder Flash je nach Bit 15 der Adresse)<br />
inline byte read_byte(const void*addr) {<br />
byte result; asm(<br />
" sbrc %B1,7 \n"<br />
" lpm %0,%a1 \n"<br />
" sbrs %B1,7 \n"<br />
" ld %0,%a1 \n"<br />
:"=r"(result):"z"(addr));<br />
return result;<br />
}<br />
</syntaxhighlight><br />
<br />
== Dateien direkt im Flash einbinden ==<br />
<br />
Wenn man größere Dateien direkt im Programm einbinden will, ohne sie vorher in C Quelltext umzuwandeln, muss man das mit dem Linker machen. Wie das geht steht hier.<br />
<br />
* [http://www.atmel.com/webdoc/avrlibcreferencemanual/FAQ_1faq_binarydata.html Atmel, avr gcc Dokumentation]<br />
* [http://nongnu.org/avr-libc/user-manual/FAQ.html#faq_binarydata Nongnu avr gcc Dokumentation]<br />
<br />
Wie man das dann praktisch umsetzt, sieht man in diesem Beitrag.<br />
<br />
* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056910 Forumsbeitrag]: Binärdateien mittels Linker einbinden<br />
* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056947 Forumsbeitrag]: Ein kleines Tool zum Umwandeln von Binärdateien in C-Quelltext.<br />
<br />
== Flash in der Anwendung schreiben ==<br />
<br />
Bei AVRs mit "self-programming"-Option – auch bekannt als [[Bootloader]]-Support – können Teile des Flash-Speichers vom Anwendungsprogramm beschrieben werden. Dies ist nur möglich, wenn die Schreibfunktion in einem besonderen Speicherbereich, der Boot-Section des Programmspeichers/Flash, abgelegt ist.<br />
<br />
Bei einigen kleinen AVRs gibt es keine gesonderte Boot-Section, bei diesen kann der Flashspeicher von jeder Stelle des Programms geschrieben werden. Für Details sei hier auf das jeweilige Controller-Datenblatt und die Erläuterungen zum Modul boot.h der avr-libc verwiesen. Es existieren auch Application-Notes dazu bei atmel.com, die auf avr-gcc-Code übertragbar sind.<br />
<br />
Siehe auch: <br />
* Forumsbeitrag [http://www.mikrocontroller.net/topic/163632#1561622 Daten in Programmspeicher speichern]<br />
<br />
== EEPROM ==<br />
<br />
Möchte man Werte aus einem Programm heraus so speichern, dass sie auch nach dem Abschalten der Versorgungsspannung noch erhalten bleiben und nach dem Wiederherstellen der Versorgungsspannung bei erneutem Programmstart wieder zur Verfügung stehen, dann benutzt man das EEPROM.<br />
<br />
Schreib- und Lesezugriffe auf den EEPROM-Speicher erfolgen über die im Modul eeprom.h der avr-libc definierten Funktionen. Mit diesen Funktionen können einzelne Bytes, Datenworte (16 Bit), Fließkommawerte (32 Bit, single-precision, float) und Datenblöcke geschrieben und gelesen werden.<br />
<br />
Diese Funktionen kümmern sich auch um diverse Details, die bei der Benutzung des EEPROMs normalerweise notwendig sind:<br />
* EEPROM-Operationen sind im Vergleich relativ langsam. Man muss daher darauf achten, dass eine vorhergehende Operation abgeschlossen ist, ehe die nächste Operation mit dem EEPROM gestartet wird. Die in der avr-libc implementierten Funktionen aus eeprom.h berücksichtigten dies. Soll beim Aufruf einer EEPROM-Funktion sichergestellt werden, dass diese nicht intern in einer Warteschleife auf den Abschluss der vorherigen Operation wartet, kann vorher per eeprom_is_ready testen, ob der Zugriff auf den EEPROM-Speicher sofort möglich ist.<br />
* Es ist darauf zu achten, dass die EEPROM-Funktionen nicht durch einen Interrupt unterbrochen werden. Einige Phasen des Zugriffs sind zeitkritisch und müssen in einer definierten bzw. begrenzten Anzahl von Takten durchgeführt werden. Durch einen unterbrechenden Interrupt würde diese Restriktion nicht mehr eingehalten. Auch dieses Detail wird von den avr-libc Funktionen berücksichtigt, so dass man sich als C-Programmierer nicht darum kümmern muss. Innerhalb der Funktionen werden Interrupts vor der "EEPROM-Sequenz" global deaktiviert und im Anschluss, falls vorher auch schon eingeschaltet, wieder aktiviert.<br />
<br />
Man beachte, dass der EEPROM-Speicher nur eine begrenzte Anzahl von Schreibzugriffen zulässt. Beschreibt man eine EEPROM-Zelle öfter als die im Datenblatt zugesicherte Anzahl (typisch 100.000), wird die Funktion der Zelle nicht mehr garantiert. Dies gilt für jede einzelne Zelle. <br />
<br />
Bei geschickter Programmierung (z.&nbsp;B. Ring-Puffer), bei der die zu beschreibenden Zellen regelmäßig gewechselt werden, kann man eine deutlich höhere Anzahl an Schreibzugriffen, bezogen auf den gesamten EEPROM-Speicher, erreichen. Auf jeden Fall sollte man aber eine Abschätzung über die zu erwartende Lebensdauer des EEPROM durchführen. Wird ein Wert im EEPROM im Durchschnitt nur einmal pro Woche verändert, wird die garantierte Anzahl der Schreibzyklen innerhalb der voraussichtlichen Verwendungszeit des Controllers sicherlich nicht erreicht werden. Welcher Controller ist schon 100000 / 52 = 1923 Jahre im Einsatz? In diesem Fall lohnt es sich daher nicht, erweiterte Programmfunktionen zu implementieren, mit denen die Anzahl der Schreibzugriffe minimiert wird.<br />
<br />
Eine weitere Möglichkeit, Schreibzyklen einzusparen, besteht in der Vorabprüfung, ob der zu speichernde Wert im EEPROM bereits enthalten ist und nur veränderte Werte zu schreiben. In aktuelleren Versionen der avr-libc sind bereits Funktionen enthalten, die solche Prüfungen enthalten (eeprom_update_*).<br />
<br />
Eine dritte Möglichkeit speichert alle Daten zunächst im RAM, wo sie beliebig oft beschrieben werden können. Nur beim Ausschalten oder beim Ausfall der Stromversorgung werden die Daten in den EEPROM geschrieben. Wie man das richtig macht sieht man im Artikel [[Speicher#EEPROM Schreibzugriffe minimieren | Speicher]].<br />
<br />
Lesezugriffe können beliebig oft durchgeführt werden. Sie unterliegen keinen Einschränkungen in Bezug auf deren Anzahl. <br />
<br />
=== EEMEM ===<br />
Um eine Variable im EEPROM anzulegen, stellt die avr-libc das Makro EEMEM zur Verfügung:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdint.h><br />
#include <avr/eeprom.h><br />
<br />
/* Byte */<br />
uint8_t eeFooByte EEMEM = 123;<br />
<br />
/* Wort */<br />
uint16_t eeFooWord EEMEM = 12345;<br />
<br />
/* float */<br />
float eeFooFloat EEMEM;<br />
<br />
/* Byte-Array */<br />
uint8_t eeFooByteArray1[] EEMEM = { 18, 3, 70 };<br />
uint8_t eeFooByteArray2[] EEMEM = { 30, 7, 79 };<br />
<br />
/* 16-bit unsigned short feld */<br />
uint16_t eeFooWordArray1[4] EEMEM;<br />
</syntaxhighlight><br />
<br />
Die grundsätzliche Vorgehensweise ist identisch zur Verwendung von PROGMEM. Auch hier erzeugt man sich spezielle attributierte Variablen (EEMEM erledigt das), die vom Compiler/Linker nicht wie normale Variablen behandelt werden. Compiler/Linker kümmern sich zwar darum, dass diesen Variablen eine Adresse zugewiesen wird, diese Adresse ist dann aber die Adresse der 'Variablen' im EEPROM. Um die dort gespeicherten Werte zu lesen bzw. zu schreiben, übergibt man diese Adresse an spezielle Funktionen, die die entsprechenden Werte aus dem EEPROM holen bzw. das EEPROM neu beschreiben.<br />
<br />
Die mittels EEMEM erzeugten 'Variablen' sind also mehr als Platzhalter zu verstehen, denn als echte Variablen. Es geht nur darum, im C-Programm symbolische Namen zur Verfügung zu haben, anstatt mit echten EEPROM-Adressen hantieren zu müssen, etwas, das grundsätzlich aber auch genauso gut möglich ist. Nur muss man sich in diesem Fall dann selbst darum kümmern, dass mehrere 'Variablen' ohne Überschneidung im EEPROM angeordnet werden.<br />
<br />
=== Bytes lesen/schreiben ===<br />
<br />
Die avr-libc Funktion zum Lesen eines Bytes heißt eeprom_read_byte. Parameter ist die Adresse des Bytes im EEPROM. Geschrieben wird über die Funktion eeprom_write_byte mit den Parametern Adresse und Inhalt. Anwendungsbeispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#define EEPROM_DEF 0xFF<br />
<br />
void eeprom_example (void)<br />
{<br />
uint8_t myByte;<br />
<br />
// myByte lesen (Wert = 123)<br />
myByte = eeprom_read_byte (&eeFooByte);<br />
<br />
// der Wert 99 wird im EEPROM an die Adresse der<br />
// Variablen eeFooByte geschrieben<br />
myByte = 99;<br />
eeprom_write_byte(&eeFooByte, myByte); // schreiben<br />
<br />
myByte = eeprom_read_byte (&eeFooByteArray1[1]); <br />
// myByte hat nun den Wert 3<br />
<br />
// Beispiel fuer eeprom_update_byte: die EEPROM-Zelle wird nur<br />
// dann beschrieben, wenn deren Inhalt sich vom Parameterwert<br />
// unterscheidet. In diesem Beispiel erfolgt also kein Schreib-<br />
// zugriff, da die Werte gleich sind.<br />
eeprom_update_byte(&eeFooByte, myByte);<br />
<br />
<br />
// Beispiel zur "Sicherung" gegen leeres EEPROM nach "Chip Erase"<br />
// (z. B. wenn die .eep-Datei nach Programmierung einer neuen Version<br />
// des Programms nicht in den EEPROM uebertragen wurde und EESAVE<br />
// deaktiviert ist (unprogrammed/1)<br />
// <br />
// Vorsicht: wenn EESAVE "programmed" ist, hilft diese Sicherung nicht<br />
// weiter, da die Speicheraddressen in einem neuen/erweiterten Programm<br />
// moeglicherweise verschoben wurden. An der Stelle &eeFooByte steht<br />
// dann u.U. der Wert einer anderen Variable aus einer "alten" Version.<br />
<br />
uint8_t fooByteDefault = 222;<br />
if ((myByte = eeprom_read_byte (&eeFooByte)) == EEPROM_DEF)<br />
{<br />
myByte = fooByteDefault;<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
=== Wort lesen/schreiben ===<br />
<br />
Schreiben und Lesen von Datenworten erfolgt analog zur Vorgehensweise bei Bytes:<br />
<br />
<syntaxhighlight lang="c"><br />
// lesen<br />
uint16_t myWord = eeprom_read_word (&eeFooWord);<br />
<br />
// schreiben<br />
eeprom_write_word (&eeFooWord, 2222);<br />
</syntaxhighlight><br />
<br />
=== Block lesen/schreiben ===<br />
<br />
Lesen und Schreiben von Datenblöcken erfolgt über die Funktionen <code>eeprom_read_block()</code> bzw. <code>eeprom_write_block()</code>. Die Funktionen erwarten drei Parameter: die Adresse der Quell- bzw. Zieldaten im RAM, die EEPROM-Adresse und die Länge des Datenblocks in Bytes als <code>size_t</code>.<br />
<syntaxhighlight lang="c"><br />
uint8_t myByteBuffer[3];<br />
uint16_t myWordBuffer[4];<br />
<br />
void eeprom_block_example (void)<br />
{<br />
/* Datenblock aus EEPROM lesen */<br />
<br />
/* liest 3 Bytes ab der von eeFooByteArray1 definierten EEPROM-Adresse<br />
in das RAM-Array myByteBuffer */<br />
eeprom_read_block (myByteBuffer, eeFooByteArray1, 3);<br />
<br />
/* dito mit etwas Absicherung betr. der Länge */<br />
eeprom_read_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));<br />
<br />
/* und nun mit 16-Bit Array */<br />
eeprom_read_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));<br />
<br />
/* Datenblock in EEPROM schreiben */<br />
eeprom_write_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));<br />
eeprom_write_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));<br />
}<br />
</syntaxhighlight><br />
<br />
=== Fließkommawerte lesen/schreiben ===<br />
<br />
In der avr-libc stehen auch EEPROM-Funktionen für Variablen des Typs float (Fließkommazahlen mit "einfacher" Genauigkeit) zur Verfügung.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/eeprom.h><br />
<br />
float eeFloat EEMEM = 12.34f;<br />
<br />
float void eeprom_float_example(float value)<br />
{<br />
/* float in EEPROM schreiben */<br />
eeprom_write_float(&eeFloat, value);<br />
<br />
/* float aus EEPROM lesen */<br />
return eeprom_read_float(&eeFloat);<br />
}</syntaxhighlight><br />
<br />
=== EEPROM-Speicherabbild in .eep-Datei ===<br />
<br />
Mit den zum Compiler gehörenden Werkzeugen kann der aus den Variablendeklarationen abgeleitete EEPROM-Inhalt in eine Datei geschrieben werden. Die übliche Dateiendung ist .eep, Daten im Intel Hex-Format. Damit können Standardwerte für den EEPROM-Inhalt im Quellcode definiert werden. <br />
<br />
Makefiles nach WinAVR/MFile-Vorlage enthalten bereits die notwendigen Einstellungen, siehe dazu die Erläuterungen im [[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]].<br />
<br />
Der Inhalt der eep-Datei muss ebenfalls zum Mikrocontroller übertragen werden, wenn die Initialisierungswerte aus der Deklaration vom Programm erwartet werden. Ansonsten enthält der EEPROM-Speicher nach der Übertragung des Programmers mittels ISP abhängig von der Einstellung der EESAVE-Fuse<ref>vgl. Datenblatt Abschnitt Fuse Bits</ref> nicht die korrekten Werte:<br />
; EESAVE = 0 (programmed): Die Daten im EEPROM bleiben erhalten. Werden sie nicht neu geschrieben, so enthält das EEPROM evtl. Daten, die nicht mehr zum Programm passen.<br />
; EESAVE = 1 (unprogrammed): Beim Programmieren werden die Daten im EEPROM gelöscht, also auf 0xff gesetzt.<br />
<br />
Als Sicherung kann man im Programm nochmals die Standardwerte vorhalten, beim Lesen auf 0xFF prüfen und gegebenenfalls einen Standardwert nutzen. Das geht natürlich nur, wenn 0xFF selbst nicht als Datenwert vorkommen kann.<br />
<syntaxhighlight lang="c"><br />
#define DUTY_CYCLE_DEFAULT 0x80<br />
<br />
uint8_t eeDutyCycle EEMEM; // Platzhalter für EEPROM<br />
uint8_t DutyCycle; // die echte Variable<br />
<br />
<br />
int main(void)<br />
{<br />
DutyCycle = eeprom_read_byte( &eeDutyCycle );<br />
if( DutyCycle == 0xFF ) // das allererste mal. Im EEPROM steht noch kein gültiger Wert<br />
{<br />
DutyCycle = DUTY_CYCLE_DEFAULT;<br />
eeprom_writeByte( &eeDutyCycle, DutyCycle );<br />
}<br />
<br />
...<br />
</syntaxhighlight><br />
<br />
=== Direkter Zugriff auf EEPROM-Adressen ===<br />
<br />
Will man direkt auf bestimmte EEPROM Adressen zugreifen, dann sind folgende IAR-kompatiblen Makros <tt>_EEGET</tt> und <tt>_EEPUT</tt> hilfreich, um sich die Typecasts zu ersparen.<br />
<br />
;Hinweis: Die nachfolgend gezeigten Makros und Zugriffe auf absolute Adressen sind in Normalfall nicht nötig und nur auf sehr wenige, spezielle Fälle beschränkt! Im Normalfall sollte man auf absolute Adressen möglichst nicht zugreifen und den Compiler seine Arbeit machen lassen, der verwaltet die Variablen und deren Adressen meist besser als der Programmierer. Der Zugriff auf Variablen im EEPROM sollte immer über ihren Namen erfolgen.<br />
<br />
Verwendung:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/eeprom.h><br />
<br />
_EEPUT (0x20, 128); // Byte-Wert 128 an Adresse 0x20 schreiben<br />
...<br />
uint8_t val = _EEGET (0x20); // EEPROM-Wert von Adresse 0x20 lesen<br />
</syntaxhighlight><br />
<br />
=== Was steckt dahinter? - EEPROM-Register ===<br />
Auch wenn es normalerweise keinen Grund gibt, in C selbst an den Steuerregistern herumzuschrauben - die eeprom Funktionen erledigen das alles zuverlässig - der Vollständigkeit halber der registermässige technische Unterbau.<br />
Um das EEPROM anzusteuern, sind drei Register von Bedeutung:<br />
;EEAR: Hier werden die Adressen eingetragen zum Schreiben oder Lesen. Dieses Register unterteilt sich nochmal in EEARH und EEARL, da in einem 8-Bit-Register keine 512 Adressen adressiert werden können.<br />
;EEDR: Hier werden die Daten eingetragen, die geschrieben werden sollen, bzw. es enthält die gelesenen Daten.<br />
;EECR: Ist das Kontrollregister für das EEPROM<br />
<br />
Das EECR steuert den Zugriff auf das EEPROM und ist wie folgt aufgebaut:<br />
<br />
:{| class="wikitable" style="text-align:center"<br />
|+ '''Aufbau des EECR-Registers'''<br />
|-<br />
!Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|-<br />
! Name<br />
| - || - || - ||- || EERIE || EEMWE || EEWE || EERE<br />
|-<br />
! Read/Write<br />
| R || R || R || R || R/W || R/W || R/W || R/W<br />
|-<br />
!Init Value<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''Bedeutung der Bits'''<br />
<br />
;Bit 4-7: nicht belegt<br />
<br />
;Bit 3 (EERIE): ''EEPROM Ready Interrupt Enable'': Wenn das Bit gesetzt ist und globale Interrupts erlaubt sind in Register SREG (Bit 7), wird ein Interrupt ausgelöst nach Beendigung des Schreibzyklus (EEPROM Ready Interrupt). Ist einer der beiden Bits 0, wird kein Interrupt ausgelöst.<br />
<br />
;Bit 2 EEMWE): ''EEPROM Master Write Enable'': Dieses Bit bestimmt, dass, wenn EEWE = 1 gesetzt wird (innerhalb von 4 Taktzyklen), das EEPROM beschrieben wird mit den Daten in EEDR bei Adresse EEAR. Wenn EEMWE = 0 ist und EEWE = 1 gesetzt wird, hat das keine Auswirkungen. Der Schreibvorgang wird dann nicht ausgelöst. Nach 4 Taktzyklen wird das Bit EEMWE automatisch wieder auf 0 gesetzt. Dieses Bit löst den Schreibvorgang nicht aus, es dient sozusagen als Sicherungsbit für EEWE.<br />
<br />
;Bit 1 (EEWE): ''EEPROM Write Enable'': Dieses Bit löst den Schreibvorgang aus, wenn es auf 1 gesetzt wird, sofern vorher EEMWE gesetzt wurde und seitdem nicht mehr als 4 Taktzyklen vergangen sind. Wenn der Schreibvorgang abgeschlossen ist, wird dieses Bit automatisch wieder auf 0 gesetzt und, sofern EERIE gesetzt ist, ein Interrupt ausgelöst. Ein Schreibvorgang sieht typischerweise wie folgt aus:<br />
:# EEPROM-Bereitschaft abwarten (EEWE=0) <br />
:# Adresse übergeben an EEAR<br />
:# Daten übergeben an EEDR<br />
:# Schreibvorgang auslösen in EECR mit Bit EEMWE=1 und EEWE=1<br />
:# (Optional) Warten, bis Schreibvorgang abgeschlossen ist<br />
<br />
;Bit 0 EERE: ''EEPROM Read Enable'': Wird dieses Bit auf 1 gesetzt wird das EEPROM an der Adresse in EEAR ausgelesen und die Daten in EEDR gespeichert. Das EEPROM kann nicht ausgelesen werden, wenn bereits eine Schreiboperation gestartet wurde. Es ist daher zu empfehlen, die Bereitschaft vorher zu prüfen. Das EEPROM ist lesebereit, wenn das Bit EEWE=0 ist. Ist der Lesevorgang abgeschlossen, wird das Bit wieder auf 0 gesetzt, und das EEPROM ist für neue Lese- und Schreibbefehle wieder bereit. Ein typischer Lesevorgang kann wie folgt aufgebaut sein:<br />
:# Bereitschaft zum Lesen prüfen (EEWE=0)<br />
:# Adresse übergeben an EEAR<br />
:# Lesezyklus auslösen mit EERE = 1<br />
:# Warten, bis Lesevorgang abgeschlossen EERE = 0<br />
:# Daten abholen aus EEDR<br />
<br />
= Die Nutzung von sprintf und printf =<br />
<br />
Um komfortabel, d.h. formatiert, Ausgaben auf ein Display oder die serielle Schnittstelle zu tätigen, bieten sich '''sprintf''' oder '''printf''' an. Alle *printf-Varianten sind jedoch ziemlich speicherintensiv und der Einsatz in einem Mikrocontroller mit knappem Speicher muss sorgsam abgewogen werden.<br />
<br />
Bei '''sprintf''' wird die Ausgabe zunächst in einem Puffer vorbereitet und anschließend mit einfachen Funktionen zeichenweise ausgegeben. Es liegt in der Verantwortung des Programmierers, genügend Platz im Puffer für die erwarteten Zeichen bereitzuhalten.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdio.h><br />
#include <stdint.h><br />
<br />
// ...<br />
// nicht dargestellt: Implementierung von uart_puts (vgl. Abschnitt UART)<br />
// ...<br />
<br />
uint16_t counter;<br />
<br />
// Ausgabe eines unsigned Integerwertes<br />
void uart_puti( uint16_t value )<br />
{<br />
uint8_t puffer[20];<br />
<br />
sprintf( puffer, "Zählerstand: %u", value );<br />
uart_puts( puffer );<br />
}<br />
<br />
int main()<br />
{<br />
counter = 5;<br />
<br />
uart_puti( counter );<br />
uart_puti( 42 );<br />
}<br />
</syntaxhighlight><br />
<br />
Eine weitere elegante Möglichkeit besteht darin, den STREAM stdout (Standardausgabe) auf eine eigene Ausgabefunktion umzuleiten. Dazu wird dem Ausgabemechanismus der C-Bibliothek eine neue Ausgabefunktion bekannt gemacht, deren Aufgabe es ist, ein einzelnes Zeichen auszugeben. Wohin die Ausgabe dann tatsächlich stattfindet, ist Sache der Ausgabefunktion. Im Beispiel unten wird auf UART ausgegeben. Alle anderen, höheren Funktionen wie z.&nbsp;B. '''printf''', greifen letztendlich auf diese primitive Ausgabefunktion zurück. <br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdio.h><br />
<br />
void uart_init(void);<br />
<br />
// a. Deklaration der primitiven Ausgabefunktion<br />
int uart_putchar(char c, FILE *stream);<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 1)<br />
static FILE mystdout = FDEV_SETUP_STREAM( uart_putchar, NULL, _FDEV_SETUP_WRITE );<br />
<br />
// c. Definition der Ausgabefunktion<br />
int uart_putchar( char c, FILE *stream )<br />
{<br />
if( c == '\n' )<br />
uart_putchar( '\r', stream );<br />
<br />
loop_until_bit_is_set( UCSRA, UDRE );<br />
UDR = c;<br />
return 0;<br />
}<br />
<br />
void uart_init(void)<br />
{<br />
/* hier µC spezifischen Code zur Initialisierung */<br />
/* des UART einfügen... s.o. im AVR-GCC-Tutorial */<br />
<br />
// Beispiel: <br />
//<br />
// myAVR Board 1.5 mit externem Quarz Q1 3,6864 MHz<br />
// 9600 Baud 8N1<br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
// Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt)<br />
#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)<br />
<br />
UCSRB |= (1<<TXEN) | (1<<RXEN); // UART TX und RX einschalten<br />
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1 <br />
<br />
UBRRH = (uint8_t)( UART_UBRR_CALC( UART_BAUD_RATE, F_CPU ) >> 8 );<br />
UBRRL = (uint8_t)UART_UBRR_CALC( UART_BAUD_RATE, F_CPU );<br />
}<br />
<br />
int main(void)<br />
{<br />
int16_t antwort = 42;<br />
uart_init();<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 2)<br />
stdout = &mystdout;<br />
<br />
// Anwendung<br />
printf( "Die Antwort ist %d.\n", antwort );<br />
return 0;<br />
}<br />
<br />
// Quelle: avr-libc-user-manual-1.4.3.pdf, S.74<br />
// + Ergänzungen<br />
</syntaxhighlight><br />
<br />
<br />
Sollen Fließkommazahlen ausgegeben werden, muss im Makefile eine andere (größere) Version der [[FAQ#Aktivieren_der_Floating_Point_Version_von_sprintf_beim_WinAVR_mit_AVR-Studio|printflib]] eingebunden werden.<br />
<br />
= Anmerkungen =<br />
<references/><br />
<br />
= TODO =<br />
* Aktualisierung Register- und Bitbeschreibungen an aktuelle AVR<br />
* "naked"-Funktionen [http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html][http://arduino.stackexchange.com/questions/8758/arduino-interruption-on-pin-change]<br />
<br />
[[Kategorie:avr-gcc Tutorial| ]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR-GCC-Tutorial&diff=107264AVR-GCC-Tutorial2025-01-28T08:32:46Z<p>Heha: /* Von-Neumannisierung „zu Fuß“ */</p>
<hr />
<div>Dieses Tutorial soll den Einstieg in die Programmierung von Atmel [[AVR]]-Mikrocontrollern in der Programmiersprache [[C]] mit dem freien C-Compiler [[avr-gcc]] aus der [http://gcc.gnu.org/ GNU Compiler Collection] (GCC) erleichtern.<br />
<br />
Vorausgesetzt werden Grundkenntnisse der Programmiersprache C. Diese Kenntnisse kann man sich online erarbeiten, z. B. mit dem [http://www.schellong.de/c.htm C Tutorial von Helmut Schellong] ([[C|Liste von C-Tutorials]]). Nicht erforderlich sind Vorkenntnisse in der Programmierung von Mikrocontrollern.<br />
<br />
= Vorwort =<br />
<br />
In diesem Text wird häufig auf die Standardbibliothek avr-libc verwiesen, für die es eine [http://www.nongnu.org/avr-libc/user-manual/index.html Online-Dokumentation] gibt, in der sich auch viele nützliche Informationen zum Compiler und zur Programmierung von AVR-Controllern finden. Beim Paket [[WinAVR]] gehört die avr-libc Dokumentation zum Lieferumfang und wird mitinstalliert.<br />
<br />
Der Compiler und die Standardbibliothek avr-libc werden ständig weiterentwickelt. Einige Unterschiede, die sich im Verlauf der Entwicklung ergeben haben, werden hier und im Artikel [[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen]] zwar angesprochen, Anfängern und Umsteigern sei jedoch empfohlen, eine aktuelle Versionen zu nutzen.<br />
<br />
Das ursprüngliche Tutorial stammt von Christian Schifferle, viele neue Abschnitte und aktuelle Anpassungen von Martin Thomas.<br />
<br />
Dieses Tutorial ist in [[Media:AVR-GCC-Tutorial.pdf|PDF-Form]] erhältlich (zur Zeit nur eine sehr veraltete Version).<br />
<br />
== Weiterführende Kapitel ==<br />
<br />
Um dieses riesige Tutorial etwas überschaubarer zu gestalten, wurden einige Kapitel ausgelagert, die nicht unmittelbar mit den Grundlagen von avr-gcc in Verbindung stehen. All diese Seiten gehören zur [[:Kategorie:avr-gcc Tutorial]].<br />
<br />
;UART: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der UART|Der UART]]''<br />
<br />
;ADC: → Hauptartikel: ''[[AVR-GCC-Tutorial/Analoge Ein- und Ausgabe|Analoge Ein- und Ausgabe (ADC)]]''<br />
<br />
;Timer: → Hauptartikel: ''[[AVR-GCC-Tutorial/Die Timer und Zähler des AVR|Die Timer und Zähler des AVR]]''<br />
<br />
;LCD: → Hauptartikel: ''[[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Ansteuerung]]''<br />
<br />
;Watchdog: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der Watchdog|Der Watchdog]]''<br />
<br />
;Assembler: → Hauptartikel: ''[[AVR-GCC-Tutorial/Assembler und Inline-Assembler|Assembler und Inline-Assembler]]''<br />
<br />
;alte Quellen anpassen: → Hauptartikel: ''[[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen anpassen]]''<br />
<br />
;Makefiles: → Hauptartikel: ''[[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]]'' sowie als Alternative für sehr kleine Projekte → Hauptartikel: ''[[C ohne Makefile]]''<br />
<br />
= Benötigte Werkzeuge =<br />
<br />
Um eigene Programme für AVRs mittels einer AVR-Toolchain zu erstellen wird folgende Hard- und Software benötigt:<br />
<br />
* Eine AVR-Toolchain bestehend aus avr-gcc, den avr-Binutils (Assembler, Linker, etc) und einer Standard-C Bibliothek. Üblich ist die AVR-LibC, die auch quasi in allen avr-gcc Distributionen enthalten ist.<br />
<br />
Hardware wird keine benötigt – bis auf einen PC natürlich, auf dem der Compiler ablaufen kann. Selbst ohne AVR-Hardware kann man also bereits C-Programme für AVRs schreiben, compiliern und sich das Look-and-Feel von avr-gcc sowie von IDEs wie [[Atmel Studio]], Eclipse oder leichtgewichtigeren Entwicklungsumbgebungen anschauen. Selbst das Debuggen und Simulieren ist mithilfe entsprechender Tools wie Debugger und Simulator in gewissen Grenzen möglich.<br />
<br />
Um Programme für AVRs mittels einer AVR-Toolchain zu testen, wird folgende Hard- und Software benötigt:<br />
<br />
* Platine oder Versuchsaufbau für die Aufnahme eines AVR-Controllers, der vom avr-gcc Compiler unterstützt wird.<ref>Für eine Liste der unterstützten COntroller siehe die Dokumentation des Compilers oder [http://www.nongnu.org/avr-libc/user-manual/index.html#supported_devices AVR-Libc: Supported Devices].</ref> Dieses Testboard kann durchaus auch selbst gelötet oder auf einem Steckbrett aufgebaut werden. Einige Registerbeschreibungen dieses Tutorials beziehen sich auf den inzwischen veralteten AT90S2313. Der weitaus größte Teil des Textes ist aber für alle Controller der AVR-Familie gültig. <br />
<br />
:Brauchbare Testplattformen sind auch das [[STK500]] und der [[AVR Butterfly]] von Atmel. Weitere Infos findet man in den Artikeln [[AVR#Starterkits|AVR Starterkits]] und [[AVR-Tutorial: Equipment]].<br />
<br />
* Programmiersoftware und -[[AVR In System Programmer |hardware]] z. B. PonyProg (siehe auch: [[Pony-Prog Tutorial]]) oder [[AVRDUDE]] mit [[STK200]]-Dongle oder die von Atmel verfügbare Hard- und Software ([[STK500]], Atmel AVRISP, [[AVR-Studio]]).<br />
<br />
* Nicht unbedingt erforderlich, aber zur Simulation und zum Debuggen unter MS-Windows recht nützlich: [[AVR-Studio]].<br />
<br />
* Wer unter Windows und Linux gleichermassen entwickeln will, der sollte sich die [http://www.eclipse.org/ IDE Eclipse for C/C++ Developers] und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] ansehen. Beide sind unter Windows und Linux einfach zu installieren, siehe auch [[AVR Eclipse]]. Ebenfalls unter Linux und Windows verfügbar ist die Entwicklungsumgebung [http://www.codeblocks.org/ Code::Blocks]<ref>Aktuelle, stabile Versionen sind als Nightly Builds regelmäßig im [http://forums.codeblocks.org/ Forum] verfügbar.</ref>. Innerhalb dieser Entwicklungsumgebung können ohne die Installation zusätzlicher Plugins "AVR-Projekte" angelegt werden. Für Linux gibt es auch noch das [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=25220 KontrollerLab].<br />
<br />
= Was tun, wenn's nicht klappt? =<br />
<br />
* Herausfinden, ob es tatsächlich ein avr(-gcc) spezifisches Problem ist oder nur die eigenen C-Kenntnisse einer Auffrischung bedürfen. Allgemeine C-Fragen kann man eventuell "beim freundlichen Programmierer zwei Büro-, Zimmer- oder Haustüren weiter" loswerden. Ansonsten: [[C]]-Buch (gibt's auch "gratis" online) lesen.<br />
<br />
* Die [[AVR Checkliste]] durcharbeiten.<br />
<br />
* Die '''[http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc]''' lesen, vor allem (aber nicht nur) den Abschnitt Related Pages/'''Frequently Asked Questions''' = Oft gestellte Fragen (und Antworten dazu). Z.Zt leider nur in englischer Sprache verfügbar.<br />
<br />
* Den Artikel [[AVR-GCC]] in diesem Wiki lesen.<br />
<br />
* Das [http://www.mikrocontroller.net/forum/gcc GCC-Forum auf www.mikrocontroller.net] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das avr-gcc-Forum bei [http://www.avrfreaks.net AVRfreaks] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das [http://lists.gnu.org/archive/html/avr-gcc-list/ Archiv der avr-gcc Mailing-Liste] nach vergleichbaren Problemen absuchen.<br />
<br />
* Nach Beispielcode suchen. Vor allem im ''Projects''-Bereich von [http://www.avrfreaks.net AVRfreaks] (anmelden).<br />
<br />
* Google oder yahoo befragen schadet nie.<br />
<br />
* Bei Problemen mit der Ansteuerung interner AVR-Funktionen mit C-Code: das Datenblatt des Controllers lesen (ganz und am Besten zweimal). Datenblätter sind auf den [http://www.atmel.com Atmel Webseiten] als pdf-Dateien verfügbar. Das komplette Datenblatt (complete) und nicht die Kurzfassung (summary) verwenden.<br />
<br />
* Die Beispielprogramme im [[AVR-Tutorial]] sind zwar in AVR-Assembler verfasst, Erläuterungen und Vorgehensweisen sind aber auch auf C-Programme übertragbar.<br />
<br />
* Einen Beitrag in eines der Foren oder eine Mail an die Mailing-Liste schreiben. Dabei möglichst viel Information geben: Controller, Compilerversion, genutzte Bibliotheken, Ausschnitte aus dem Quellcode oder besser ein [http://www.mikrocontroller.net/topic/72767#598986 Testprojekt] mit allen notwendigen Dateien, um das Problem nachzuvollziehen, sowie genaue Fehlermeldungen bzw. Beschreibung des Fehlverhaltens. Bei Ansteuerung externer Geräte die Beschaltung beschreiben oder skizzieren (z. B. mit [http://www.tech-chat.de/ Andys ASCII Circuit]). Siehe dazu auch: '''[http://www.tty1.net/smart-questions_de.html "Wie man Fragen richtig stellt"]'''.<br />
<br />
= Erzeugen von Maschinencode =<br />
<br />
Aus dem C-Quellcode erzeugt der avr-gcc Compiler (zusammen mit Hilfsprogrammen wie z.&nbsp;B. Präprozessor, Assembler und Linker) Maschinencode für den AVR-Controller. Üblicherweise liegt dieser Code dann im Intel Hex-Format vor ("Hex-Datei"). Die Programmiersoftware (z.&nbsp;B. [[AVRDUDE]], PonyProg oder AVRStudio/STK500-plugin) liest diese Datei ein und überträgt die enthaltene Information (den Maschinencode) in den Speicher des Controllers. Im Prinzip sind also "nur" der avr-gcc-Compiler (und wenige Hilfsprogramme) mit den "richtigen" Optionen aufzurufen, um aus C-Code eine "Hex-Datei" zu erzeugen. Grundsätzlich stehen dazu drei verschiedene Ansätze zur Verfügung:<br />
<br />
* Die Verwendung einer integrierten Entwicklungsumgebung (IDE = '''I'''ntegrated '''D'''evelopment '''E'''nvironment), bei der alle Einstellungen z.&nbsp;B. in Dialogboxen durchgeführt werden können. Unter Anderem kann AVRStudio ab Version 4.12 (kostenlos auf [http://www.atmel.com/ atmel.com]) zusammen mit WinAVR als integrierte Entwicklungsumgebung für den Compiler avr-gcc genutzt werden (dazu müssen AVRStudio und WinAVR auf dem Rechner installiert sein). Weitere IDEs (ohne Anspruch auf Vollständigkeit): [http://www.eclipse.org/ Eclipse for C/C++ Developers] (d.h. inkl. CDT) und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] (für diverse Plattformen, u.a. Linux und MS Windows, IDE und Plugin kostenlos), [http://sourceforge.net/projects/kontrollerlab KontrollerLab] (Linux/KDE, kostenlos). [http://www.atmanecl.com/EnglishSite/SoftwareEnglish.htm AtmanAvr] (MS Windows, relativ günstig), KamAVR (MS-Windows, kostenlos, wird augenscheinlich nicht mehr weiterentwickelt), [http://www.amctools.com/vmlab.htm VMLab] (MS Windows, ab Version 3.12 ebenfalls kostenlos). Integrierte Entwicklungsumgebungen unterscheiden sich stark in Ihrer Bedienung und stehen auch nicht für alle Plattformen zur Verfügung, auf denen der Compiler ausführbar ist (z.&nbsp;B. AVRStudio nur für MS-Windows). Zur Anwendung des avr-gcc Compilers mit IDEs sei hier auf deren Dokumentation verwiesen. <br />
<br />
* Die Nutzung des Programms make mit passenden Makefiles. In den folgenden Abschnitten wird die Generierung von Maschinencode für einen AVR ("hex-Datei") aus C-Quellcode ("c-Dateien") anhand von "make" und den "Makefiles" näher erläutert. Viele der darin beschriebenen Optionen findet man auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio (AVRStudio generiert ein makefile in einem Unterverzeichnis des Projektverzeichnisses). <br />
<br />
* Das Generieren des Programms ohne IDE und ohne Makefile. In diesem Fall muss die Quellcodedatei durch eine vorgefertigte Kommandofolge an den Compiler übergeben werden. Der Artikel [[C ohne Makefile]] zeigt, wie das funktioniert. Diese Vorgehensweise empfiehlt sich jedoch nur für kleine Programme, die nicht auf verschiedene Quellcodedateien verteilt sind.<br />
<br />
Beim Wechsel vom makefile-Ansatz nach WinAVR-Vorlage zu AVRStudio ist darauf zu achten, dass AVRStudio (Stand: AVRStudio Version 4.13) bei einem neuen Projekt die Optimierungsoption (vgl. Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|AVR-GCC-Tutorial/Exkurs: Makefiles]], typisch: -Os) nicht einstellt und die mathematische Bibliothek der avr-libc (libm.a, Linker-Option -lm) nicht einbindet. (Hinweis: Bei Version 4.16 wird beides bereits gesetzt). Beides ist Standard bei Verwendung von makefiles nach WinAVR-Vorlage und sollte daher auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio "manuell" eingestellt werden, um auch mit AVRStudio kompakten Code zu erzeugen.<br />
<br />
= Einführungsbeispiel =<br />
<br />
Zum Einstieg ein kleines Beispiel, an dem die Nutzung des Compilers und der Hilfsprogramme (der sogenannten ''Toolchain'') demonstriert wird. Detaillierte Erläuterungen folgen in den weiteren Abschnitten dieses Tutorials.<br />
<br />
Das Programm soll auf einem AVR Mikrocontroller einige Ausgänge ein- und andere ausschalten. Das Beispiel ist für einen ATmega16 programmiert ([http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf Datenblatt]), kann aber sinngemäß für andere Controller der AVR-Familie modifiziert werden. <br />
<br />
Ein kurzes Wort zur Hardware: Bei diesem Programm werden alle Pins von PORTB auf Ausgang gesetzt, und einige davon werden auf HIGH andere auf LOW gesetzt. Das kann je nach angeschlossener Hardware an diesen Pins kritisch sein. Am ungefährlichsten ist es, wenn nichts an den Pins angeschlossen ist und man die Funktion des Programmes durch eine Spannungsmessung mit einem Multimeter kontrolliert. Die Spannung wird dabei zwischen GND-Pin und den einzelnen Pins von PORTB gemessen.<br />
<br />
Zunächst der Quellcode der Anwendung, der in einer Text-Datei mit dem Namen ''main.c'' abgespeichert wird.<br />
<br />
<syntaxhighlight lang="c"><br />
/* Alle Zeichen zwischen Schrägstrich-Stern <br />
und Stern-Schrägstrich sind Kommentare */<br />
<br />
// Zeilenkommentare sind ebenfalls möglich<br />
// alle auf die beiden Schrägstriche folgenden<br />
// Zeichen einer Zeile sind Kommentar<br />
<br />
#include <avr/io.h> // (1)<br />
<br />
int main (void) { // (2)<br />
<br />
DDRB = 0xFF; // (3)<br />
PORTB = 0x03; // (4)<br />
<br />
while(1) { // (5)<br />
/* "leere" Schleife*/ // (6)<br />
} // (7)<br />
<br />
/* wird nie erreicht */<br />
return 0; // (8)<br />
}<br />
</syntaxhighlight><br />
<br />
# In dieser Zeile wird eine sogenannte Header-Datei eingebunden. In <code>avr/io.h</code> sind die Registernamen definiert, die im späteren Verlauf genutzt werden. Auch unter Windows wird ein&nbsp;<code>/</code> zur Kennzeichnung von Unterverzeichnissen in Include-Dateinamen verwendet und kein&nbsp;<code>\</code>.<br />
# Hier beginnt das eigentliche Programm. Jedes C-Programm beginnt mit den Anweisungen in der Funktion <code>main</code>.<br />
# Die Anschlüsse eines AVR (Pins) werden zu Blöcken zusammengefasst, einen solchen Block bezeichnet man als Port. Beim ATmega16 hat jeder Port 8 Anschlüsse, bei kleineren AVRs können einem Port auch weniger als 8 Anschlüsse zugeordnet sein. Da per Definition (Datenblatt) alle gesetzten Bits in einem Datenrichtungsregister den entsprechenden Anschluss auf Ausgang schalten, werden mit DDRB=0xff alle Anschlüsse des Ports B als Ausgänge eingestellt.<br />
# Die den ersten beiden Bits des Ports zugeordneten Anschlüsse (PB0 und PB1) werden 1, alle anderen Anschlüsse des Ports B (PB2-PB7) zu 0. Aktivierte Ausgänge (logisch 1 oder "high") liegen auf Betriebsspannung (VCC, meist 5 Volt), nicht aktivierte Ausgänge führen 0 Volt (GND, Bezugspotential). Es ist sinnvoll, sich möglichst frühzeitig eine alternative Schreibweise beizubringen, die wegen der leichteren Überprüfbarkeit und Portierbarkeit oft im weiteren Tutorial und in Forenbeiträgen benutzt wird. Die Zuordnung sieht in diesem Fall so aus, Näheres dazu im Artikel [[Bitmanipulation]]:<syntaxhighlight lang="c">PORTB = (1<<PB1) | (1<<PB0);</syntaxhighlight><br />
# ist der Beginn der sogenannte ''Hauptschleife'' (main-loop). Dies ist eine Endlosschleife, welche kontinuierlich wiederkehrende Befehle enthält.<br />
# In diesem Beispiel ist die Hauptschleife leer. Der Controller durchläuft die Schleife immer wieder, ohne dass etwas passiert. Eine solche Schleife ist notwendig, da es auf dem Controller kein Betriebssystem gibt, das nach Beendigung des Programmes die Kontrolle übernehmen könnte. Ohne diese Schleife kehrt das Programm aus <code>main</code> zurück, alle Interrupts werden deaktiviert und eine Endlosschleife betreten.<br />
# Ende der Hauptschleife und Sprung zur passenden, öffnenden Klammer, also zu 5.<br />
# ist das Programmende. Die Zeile ist nur aus Gründen der C-Kompatibilität enthalten: <syntaxhighlight lang="c">int main(void)</syntaxhighlight> besagt, dass die Funktion einen int-Wert zurückgibt. Die Anweisung wird aber nicht erreicht, da das Programm die Hauptschleife nie verlässt.<br />
<br />
Um diesen Quellcode in ein lauffähiges Programm zu übersetzen, wird hier ein Makefile genutzt. Das verwendete Makefile findet sich auf der Seite [[Beispiel Makefile]] und basiert auf der Vorlage, die in WinAVR mitgeliefert wird und wurde bereits angepasst (Controllertyp ATmega16). Man kann das Makefile bearbeiten und an andere Controller anpassen oder sich mit dem Programm MFile menügesteuert ein Makefile "zusammenklicken". Das Makefile speichert man unter dem Namen <code>Makefile</code> (ohne Endung) im selben Verzeichnis, in dem auch die Datei <code>main.c</code> mit dem Programmcode abgelegt ist. Detailliertere Erklärungen zur Funktion von Makefiles finden sich im Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|Exkurs: Makefiles]].<br />
<br />
<pre><br />
D:\beispiel>dir<br />
<br />
Verzeichnis von D:\beispiel<br />
<br />
28.11.2006 22:53 <DIR> .<br />
28.11.2006 22:53 <DIR> ..<br />
28.11.2006 20:06 118 main.c<br />
28.11.2006 20:03 16.810 Makefile<br />
2 Datei(en) 16.928 Bytes<br />
</pre><br />
<br />
Nun gibt man ''make all'' ein. Falls das mit WinAVR installierte Programmers Notepad genutzt wird, gibt es dazu einen Menüpunkt im Tools Menü. Sind alle Einstellungen korrekt, entsteht eine Datei <code>main.hex</code>, in welcher der Code für den AVR enthalten ist. <br />
<pre><br />
D:\beispiel>make all<br />
<br />
-------- begin --------<br />
avr-gcc (GCC) 3.4.6<br />
Copyright (C) 2006 Free Software Foundation, Inc.<br />
This is free software; see the source for copying conditions. There is NO<br />
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.<br />
<br />
Compiling C: main.c<br />
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -f<br />
unsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef<br />
-Wa,-adhlns=obj/main.lst -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c -<br />
o obj/main.o<br />
<br />
Linking: main.elf<br />
avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -funs<br />
igned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -W<br />
a,-adhlns=obj/main.o -std=gnu99 -Wundef -MD -MP -MF .dep/main.elf.d obj/main.o<br />
--output main.elf -Wl,-Map=main.map,--cref -lm<br />
<br />
Creating load file for Flash: main.hex<br />
avr-objcopy -O ihex -R .eeprom main.elf main.hex<br />
</pre><br />
<br />
Der Inhalt der hex-Datei kann nun zum Controller übertragen werden. Dies kann z.&nbsp;B. über In-System-Programming ([[ISP]]) erfolgen, das im [[AVR-Tutorial: Equipment]] beschrieben ist. Makefiles nach der WinAVR/MFile-Vorlage sind für die Nutzung des Programms [[AVRDUDE]] vorbereitet. Wenn man den Typ und Anschluss des Programmiergerätes richtig eingestellt hat, kann mit ''make program'' die Übertragung mittels AVRDUDE gestartet werden. Jede andere Software, die hex-Dateien lesen und zu einem AVR übertragen kann<ref>z.&nbsp;B. [[Pony-Prog_Tutorial|Ponyprog]], yapp, AVRStudio</ref>, kann natürlich ebenfalls genutzt werden.<br />
<br />
Startet man nun den Controller (Reset-Taster oder Stromzufuhr aus/an), werden vom Programm die Anschlüsse PB0 und PB1 auf 1 gesetzt. Man kann mit einem Messgerät nun an diesem Anschluss die Betriebsspannung messen oder eine [[LED]] leuchten lassen (Anode an den Pin, Vorwiderstand nicht vergessen). An den Anschlüssen PB2-PB7 misst man 0 Volt. Eine mit der Anode mit einem dieser Anschlüsse verbundene LED leuchtet nicht.<br />
<br />
= Ganzzahlige Datentypen (Integer) =<br />
<br />
Bei der Programmierung von Mikrokontrollern ist die Definition einiger ganzzahliger Datentypen sinnvoll, an denen eindeutig die Bit-Länge abgelesen werden kann.<br />
<br />
Standardisierte Datentypen werden in der Header-Datei <code>stdint.h</code> definiert, die folgendermaßen eingebunden werden kann:<br />
<syntaxhighlight lang="c">#include <stdint.h></syntaxhighlight><br />
<br />
{| {{Tabelle}}<br />
|+ '''int-Typen aus <code>stdint.h</code> (C99)'''<br/>&nbsp;<br />
|- bgcolor="#d0d0ff"<br />
!colspan="5"| Vorzeichenbehaftete int-Typen<br />
|- bgcolor="#e8e8ff"<br />
! Typname || Bit-Breite ||colspan="2"| Wertebereich<br />
|align="center| '''C-Entsprechung''' (avr-gcc)<br />
|-<br />
|<code>int8_t</code> ||align="right"| 8 || −128 ⋯ 127 || −2<sup>7</sup> ⋯ 2<sup>7</sup>−1 || <code>signed char</code><br />
|-<br />
|<code>int16_t</code> ||align="right"| 16 || −32768 ⋯ 32767 || −2<sup>15</sup> ⋯ 2<sup>15</sup>−1 || <code>signed short</code>, <code>signed int</code><br />
|-<br />
|<code>int32_t</code> ||align="right"| 32 || −2147483648 ⋯ 2147483647 || −2<sup>31</sup> ⋯ 2<sup>31</sup>−1 || <code>signed long</code><br />
|-<br />
|<code>int64_t</code> ||align="right"| 64 || −9223372036854775808 ⋯ 9223372036854775807 || −2<sup>63</sup> ⋯ 2<sup>63</sup>−1 || <code>signed long long</code><br />
|- bgcolor="#d0d0ff"<br />
!colspan="5"| Vorzeichenlose int-Typen<br />
|- bgcolor="#e8e8ff"<br />
! Typname || Bit-Breite ||colspan="2"| Wertebereich<br />
|align="center| '''C-Entsprechung''' (avr-gcc)<br />
|-<br />
|<code>uint8_t</code> ||align="right"| 8 || 0 ⋯ 255 || 0 ⋯ 2<sup>8</sup>−1 || <code>unsigned char</code><br />
|-<br />
|<code>uint16_t</code> ||align="right"| 16 || 0 ⋯ 65535 || 0 ⋯ 2<sup>16</sup>−1 || <code>unsigned short</code>, <code>unsigned int</code><br />
|-<br />
|<code>uint32_t</code> ||align="right"| 32 || 0 ⋯ 4294967295 || 0 ⋯ 2<sup>32</sup>−1 || <code>unsigned long</code><br />
|-<br />
|<code>uint64_t</code> ||align="right"| 64 || 0 ⋯ 18446744073709551615 || 0 ⋯ 2<sup>64</sup>−1 || <code>unsigned long long</code><br />
|}<br />
<br />
Neben den Typen gibt es auch Makros für die Bereichsgrenzen wie <code>INT8_MIN</code> oder <code>UINT16_MAX</code>. Siehe dazu auch: [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html Dokumentation der avr-libc: Standard Integer Types].<br />
<br />
= Grundsätzlicher Programmaufbau eines µC-Programms =<br />
<br />
Wir unterscheiden zwischen 2 verschiedenen Methoden, um ein<br />
Mikrocontroller-Programm zu schreiben, und zwar völlig unabhängig davon, in<br />
welcher Programmiersprache das Programm geschrieben wird.<br />
<br />
== Sequentieller Programmablauf ==<br />
<br />
[[Image:Sequentielle Programme.gif|left]]<br />
Bei dieser Programmiertechnik wird eine Endlosschleife programmiert, welche im<br />
Wesentlichen immer den gleichen Aufbau hat. Es wird hier nach dem sogenannten EVA-Prinzip gehandelt. EVA steht für "Eingabe, Verarbeitung, Ausgabe".<br />
{{Absatz}}<br />
<br />
== Interruptgesteuerter Programmablauf ==<br />
<br />
[[Image:Interrupt Programme.gif|left]]<br />
Bei dieser Methode werden beim Programmstart zuerst die gewünschten Interruptquellen aktiviert und dann in eine Endlosschleife gegangen, in welcher Dinge erledigt werden können, welche nicht zeitkritisch sind. Wenn ein Interrupt ausgelöst wird, so wird automatisch die zugeordnete Interruptfunktion ausgeführt.<br />
{{Absatz}}<br />
<br />
= Zugriff auf Register =<br />
<br />
Die AVR-Controller verfügen über eine Vielzahl von Registern. Die meisten<br />
davon sind sogenannte Schreib-/Leseregister. Das heißt, das Programm kann die<br />
Inhalte der Register sowohl auslesen als auch beschreiben.<br />
<br />
Register haben einen besonderen Stellenwert bei den AVR Controllern. Sie dienen dem Zugriff auf die Ports und die Schnittstellen des Controllers. Wir unterscheiden zwischen 8-Bit und 16-Bit Registern. Vorerst behandeln wir die 8-Bit Register.<br />
<br />
Einzelne Register sind bei allen AVRs vorhanden, andere wiederum nur bei bestimmten Typen. So sind beispielsweise die Register, welche für den Zugriff auf den UART notwendig sind, selbstverständlich nur bei denjenigen Modellen vorhanden, welche über einen integrierten Hardware UART bzw. USART verfügen.<br />
<br />
Die Namen der Register sind in den Headerdateien zu den entsprechenden AVR-Typen definiert. Dazu muss man den Namen der controllerspezifischen Headerdatei nicht kennen. Es reicht aus, die allgemeine Headerdatei ''avr/io.h'' einzubinden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
</syntaxhighlight><br />
<br />
Ist im Makefile der MCU-Typ z.&nbsp;B. mit dem Inhalt atmega8 definiert (und wird somit per -mmcu=atmega8 an den Compiler übergeben), wird beim Einlesen der io.h-Datei implizit ("automatisch") auch die iom8.h-Datei mit den Register-Definitionen für den ATmega8 eingelesen.<br />
<br />
<!-- Wohl besser als Anhang - spaeter... --><br />
Intern wird diese "Automatik" wie folgt realisiert: Der Controllertyp wird dem Compiler als Parameter übergeben (vgl. ''avr-gcc -c -mmcu=atmega16 [...]'' im Einführungsbeispiel). Wird ein Makefile nach der WinAVR/mfile-Vorlage verwendet, setzt man die Variable ''MCU'', der Inhalt dieser Variable wird dann an passender Stelle für die Compilerparameter verwendet. Der Compiler definiert intern eine dem mmcu-Parameter zugeordnete "Variable" (genauer: ein Makro) mit dem Namen des Controllers, vorangestelltem ''__AVR_'' und angehängten Unterstrichen (z.&nbsp;B. wird bei ''-mmcu=atmega16'' das Makro ''__AVR_ATmega16__'' definiert). Beim Einbinden der Header-Datei ''avr/io.h'' wird geprüft, ob das jeweilige Makro definiert ist und die zum Controller passende Definitionsdatei eingelesen. Zur Veranschaulichung einige Ausschnitte aus einem Makefile:<br />
<br />
<pre><br />
[...]<br />
# MCU Type ("name") setzen:<br />
MCU = atmega16<br />
[...]<br />
<br />
[...]<br />
## Verwendung des Inhalts von MCU (hier atmega16) fuer die <br />
## Compiler- und Assembler-Parameter<br />
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)<br />
ALL_CPPFLAGS = -mmcu=$(MCU) -I. -x c++ $(CPPFLAGS) $(GENDEPFLAGS)<br />
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)<br />
[...]<br />
<br />
[...]<br />
## Aufruf des Compilers:<br />
## mit den Parametern ($(ALL_CFLAGS) ist -mmcu=$(MCU)[...] = -mmcu=atmega16[...]<br />
$(OBJDIR)/%.o : %.c<br />
@echo<br />
@echo $(MSG_COMPILING) $<<br />
$(CC) -c $(ALL_CFLAGS) $< -o $@ <br />
[...]<br />
</pre><br />
<br />
Da --mmcu=atmega16 übergeben wurde, wird __AVR_ATmega16__ definiert und kann in avr/io.h zur Fallunterscheidung genutzt werden:<br />
<br />
<syntaxhighlight lang="c"><br />
// avr/io.h <br />
// (bei WinAVR-Standardinstallation in C:\WinAVR\avr\include\avr)<br />
[...]<br />
#if defined (__AVR_AT94K__)<br />
# include <avr/ioat94k.h><br />
// [...]<br />
#elif defined (__AVR_ATmega16__)<br />
// da __AVR_ATmega16__ definiert ist, wird avr/iom16.h eingebunden:<br />
# include <avr/iom16.h><br />
// [...]<br />
#else<br />
# if !defined(__COMPILING_AVR_LIBC__)<br />
# warning "device type not defined"<br />
# endif<br />
#endif<br />
</syntaxhighlight><br />
<br />
Die Beispiele in den folgenden Abschnitten demonstrieren den Zugriff auf Register anhand der Register für I/O-Ports (PORTx, DDRx, PINx), die Vorgehensweise ist jedoch für alle Register (z.&nbsp;B. die des UART, ADC, SPI) analog.<br />
<br />
== Schreiben in Register ==<br />
<br />
Zum Schreiben kann man Register einfach wie eine Variable setzen.<ref>In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Schreibzugriff über die Funktion outp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt, outp() ist nicht mehr erforderlich.</ref><br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
/* Setzt das Richtungsregister des Ports A auf 0xff <br />
(alle Pins als Ausgang, vgl. Abschnitt Zugriff auf Ports): */<br />
DDRA = 0xff; <br />
<br />
/* Setzt PortA auf 0x03, Bit 0 und 1 "high", restliche "low": */<br />
PORTA = 0x03; <br />
<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binär 00011111 = Hexadezimal 1F<br />
DDRB = 0x1F; /* direkte Zuweisung - unübersichtlich */<br />
<br />
/* Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit<br />
aber übersichtlicher und selbsterklärend: */<br />
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);<br />
<br />
while (1);<br />
}<br />
</syntaxhighlight><br />
<br />
Die ausführliche Schreibweise sollte bevorzugt verwendet werden, da dadurch die Zuweisungen selbsterklärend sind und somit der Code leichter nachvollzogen werden kann. Atmel verwendet sie auch bei Beispielen in Datenblätten und in den allermeisten Quellcodes zu Application-Notes. Mehr zu der Schreibweise mit "|" und "<<" findet man unter [[Bitmanipulation]].<br />
<br />
Der gcc C-Compiler unterstützt ab Version 4.3.0 Konstanten im Binärformat, z.&nbsp;B. DDRB&nbsp;=&nbsp;0b00011111. Diese Schreibweise ist jedoch nur in GNU-C verfügbar und nicht in ISO-C definiert. Man sollte sie daher nicht verwenden, wenn Code mit anderen ausgetauscht oder mit anderen Compilern bzw. älteren Versionen des gcc genutzt werden soll.<br />
<br />
== Verändern von Registerinhalten ==<br />
<br />
Einzelne Bits setzt und löscht man "Standard-C-konform" mittels logischer (Bit-) Operationen. <br />
<br />
<syntaxhighlight lang="c"><br />
x |= (1 << Bitnummer); // Hiermit wird ein Bit in x gesetzt<br />
x &= ~(1 << Bitnummer); // Hiermit wird ein Bit in x geloescht<br />
</syntaxhighlight><br />
<br />
Es wird jeweils nur der Zustand des angegebenen Bits geändert, der vorherige Zustand der anderen Bits bleibt erhalten. <br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
#define MEINBIT 2<br />
...<br />
PORTA |= (1 << MEINBIT); /* setzt Bit 2 an PortA auf 1 */<br />
PORTA &= ~(1 << MEINBIT); /* loescht Bit 2 an PortA */<br />
</syntaxhighlight><br />
<br />
Mit dieser Methode lassen sich auch mehrere Bits eines Registers gleichzeitig setzen und löschen.<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
DDRA &= ~( (1<<PA0) | (1<<PA3) ); /* PA0 und PA3 als Eingaenge */<br />
PORTA |= ( (1<<PA0) | (1<<PA3) ); /* Interne Pull-Up fuer beide einschalten */<br />
</syntaxhighlight><br />
<br />
Bei bestimmten AVR Registern mit Bits, die durch Beschreiben mit einer logischen 1 gelöscht werden, muss eine absolute Zuweisung benutzt werden. Ein ODER löscht in diesen Registern ALLE gesetzten Bits!<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
TIFR2 = (1<<OCF2A); // Nur Bit OCF2A löschen<br />
</syntaxhighlight><br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind nicht mehr erforderlich.<br />
<br />
Siehe auch:<br />
* [[Bitmanipulation]]<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
<br />
== Lesen aus Registern ==<br />
<br />
Zum Lesen kann man auf Register einfach wie auf eine Variable zugreifen. In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Lesezugriff über die Funktion inp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt und inp() ist nicht mehr erforderlich.<br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdint.h><br />
<br />
uint8_t foo;<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
/* kopiert den Status der Eingabepins an PortB <br />
in die Variable foo: */<br />
foo = PINB; <br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Die Abfrage der Zustände von Bits erfolgt durch Einlesen des gesamten Registerinhalts und ausblenden der Bits deren Zustand nicht von Interesse ist. Einige Beispiele zum Prüfen ob Bits gesetzt oder gelöscht sind:<br />
<br />
<syntaxhighlight lang="c"><br />
#define MEINBIT0 0 <br />
#define MEINBIT2 2<br />
<br />
uint8_t i;<br />
<br />
extern test1();<br />
<br />
// Funkion test1 aufrufen, wenn Bit 0 in Register PINA gesetzt (1) ist<br />
i = PINA; // Inhalt in Arbeitsvariable<br />
i = i & 0x01; // alle Bits bis auf Bit 0 ausblenden (bitweise und)<br />
// falls das Bit gesetzt war, hat i den Inhalt 1<br />
if ( i != 0 ) { // Ergebnis ungleich 0 (wahr)? <br />
test1(); // dann muss Bit 0 in i gesetzt sein -> Funktion aufrufen<br />
}<br />
// verkürzt:<br />
if ( ( PINA & 0x01 ) != 0 ) {<br />
test1();<br />
}<br />
// nochmals verkürzt:<br />
if ( PINA & 0x01 ) {<br />
test1();<br />
}<br />
// mit definierter Bitnummer:<br />
if ( PINA & ( 1 << MEINBIT0 ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und/oder Bit 2 gesetzt ist. (Bit 0 und 2 also Wert 5) <br />
// (Bedenke: Bit 0 hat Wert 1, Bit 1 hat Wert 2 und Bit 2 hat Wert 4)<br />
if ( PINA & 0x05 ) {<br />
test1(); // Vergleich <> 0 (wahr), also mindestens eines der Bits gesetzt<br />
}<br />
// mit definierten Bitnummern:<br />
if ( PINA & ( ( 1 << MEINBIT0 ) | ( 1 << MEINBIT2 ) ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und Bit 2 gesetzt sind<br />
if ( ( PINA & 0x05 ) == 0x05 ) { // nur wahr, wenn beide Bits gesetzt<br />
test1();<br />
}<br />
<br />
// Funktion test2() aufrufen, wenn Bit 0 gelöscht (0) ist<br />
i = PINA; // einlesen in temporäre Variable<br />
i = i & 0x01; // maskieren von Bit 0<br />
if ( i == 0 ) { // Vergleich ist wahr, wenn Bit 0 nicht gesetzt ist<br />
test2();<br />
}<br />
// analog mit not-Operator<br />
if ( !i ) {<br />
test2();<br />
}<br />
// nochmals verkürzt:<br />
if ( !( PINA & 0x01 ) ) {<br />
test2();<br />
}<br />
</syntaxhighlight><br />
<br />
== Warten auf einen bestimmten Zustand ==<br />
<br />
Es gibt in der Bibliothek avr-libc Funktionen, die warten, bis ein bestimmter Zustand eines Bits erreicht ist. Es ist allerdings normalerweise eine eher unschöne Programmiertechnik, da in diesen Funktionen "blockierend" gewartet wird. Der Programmablauf bleibt also an dieser Stelle stehen, bis das maskierte Ereignis erfolgt ist. Setzt man den [[Watchdog]] ein, muss man darauf achten, dass dieser auch noch getriggert wird (Zurücksetzen des Watchdogtimers). <br />
<br />
Die Funktion '''loop_until_bit_is_set''' wartet in einer Schleife, bis das definierte Bit gesetzt ist. Wenn das Bit beim Aufruf der Funktion bereits gesetzt ist, wird die Funktion sofort wieder verlassen. Das niederwertigste Bit hat die Bitnummer 0. <br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 2 (das dritte Bit) in Register PINA gesetzt (1) ist */<br />
<br />
#define WARTEPIN PINA<br />
#define WARTEBIT PA2<br />
<br />
// mit der avr-libc Funktion:<br />
loop_until_bit_is_set(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// _nicht_ ungleich 0 (also 0) ist.<br />
while ( !(WARTEPIN & (1 << WARTEBIT)) ) {}<br />
...<br />
</syntaxhighlight><br />
<br />
<br />
Die Funktion '''loop_until_bit_is_clear''' wartet in einer Schleife, bis das definierte Bit gelöscht ist. Wenn das Bit beim Aufruf der Funktion bereits gelöscht ist, wird die Funktion sofort wieder verlassen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 4 (das fuenfte Bit) in Register PINB geloescht (0) ist */<br />
#define WARTEPIN PINB<br />
#define WARTEBIT PB4<br />
<br />
// avr-libc-Funktion:<br />
loop_until_bit_is_clear(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// gesetzt (1) ist <br />
while ( WARTEPIN & (1<<WARTEBIT) ) {}<br />
...<br />
</syntaxhighlight><br />
<br />
Universeller und auch auf andere Plattformen besser übertragbar ist die Verwendung von C-Standardoperationen.<br />
<br />
Siehe auch: <br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
* [[Bitmanipulation]]<br />
<br />
== 16-Bit Register (ADC, ICR1, OCR1x, TCNT1, UBRR) ==<br />
<br />
Einige der Portregister in den AVR-Controllern sind 16 Bit breit. Im Datenblatt sind diese Register üblicherweise mit dem Suffix "L" (Low-Byte) und "H" (High-Byte) versehen. Die avr-libc definiert zusätzlich die meisten dieser Variablen die Bezeichnung ohne "L" oder "H". Auf diese Register kann dann direkt zugegriffen werden. Dies ist zum Beispiel der Fall für Register wie ADC oder TCNT1.<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
uint16_t foo;<br />
<br />
/* setzt die Wort-Variable foo auf den Wert der letzten AD-Wandlung */<br />
foo = ADC; <br />
</syntaxhighlight><br />
<br />
Bei anderen Registern, wie zum Beispiel Baudraten-Register, liegen High- und Low-Teil nicht direkt nebeneinander im SFR-Bereich, so dass ein 16-Bit Zugriff nicht möglich ist und der Zugriff zusammengebastelt werden muss:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
...<br />
uint16_t baud = F_CPU / (UART_BAUD_RATE * 16L) -1;<br />
<br />
UBRRH = (uint8_t) (baud >> 8);<br />
UBRRL = (uint8_t) baud;<br />
...<br />
</syntaxhighlight><br />
<br />
Bei einigen AVR-Typen wie ATmega8 oder ATmega16 teilen sich UBRRH und UCSRC die gleiche Speicher-Adresse. Damit der AVR trotzdem zwischen den beiden Registern unterscheiden kann, bestimmt das Bit7 (URSEL), welches Register tatsächlich beschrieben werden soll. ''1000 0011'' (0x83) adressiert demnach UCSRC und übergibt den Wert ''3''. Und ''0000 0011'' (0x3) adressiert UBRRH und übergibt ebenfalls den Wert ''3''. <br />
<br />
Speziell bei den 16-Bit-Timern und auch beim ADC ist es bei allen Zugriffen auf Datenregister erforderlich, dass diese Daten synchronisiert sind. Wenn z.&nbsp;B. bei einem 16-Bit-Timer das High-Byte des Zählregisters gelesen wurde und vor dem Lesezugriff auf das Low-Byte ein Überlauf des Low-Bytes stattfindet, erhält man einen völlig unsinnigen Wert. Auch die Compare-Register müssen synchron geschrieben werden, da es ansonsten zu unerwünschten Compare-Ereignissen kommen kann. <br />
<br />
Beim ADC besteht das Problem darin, dass zwischen den Zugriffen auf die beiden Teilregister eine Wandlung beendet werden kann und der ADC ein neues Ergebnis in ADCL und ADCH schreiben will, wodurch High- und Low-Byte nicht zusammenpassen.<br />
<br />
Um diese Datenmüllproduktion zu verhindern, gibt es in beiden Fällen eine Synchronisation, die jeweils durch den Zugriff auf das Low-Byte ausgelöst wird:<br />
* Bei den Timer-Registern (das gilt für alle TCNT-, OCR- und ICR-Register bei den 16-Bit-Timern) wird bei einem ''Lesezugriff'' auf das Low-Byte automatisch das High-Byte in ein temporäres Register, das ansonsten nach außen nicht sichtbar ist, geschoben. Greift man nun ''anschließend'' auf das High-Byte zu, dann wird eben dieses temporäre Register gelesen.<br />
* Bei einem ''Schreibzugriff'' auf eines der genannten Register wird das High-Byte in besagtem temporären Register zwischengespeichert und erst beim Schreiben des Low-Bytes werden ''beide'' gleichzeitig in das eigentliche Register übernommen.<br />
<br />
Das bedeutet für die Reihenfolge:<br />
* Lesezugriff: Erst Low-Byte, dann High-Byte<br />
* Schreibzugriff: Erst High-Byte, dann Low-Byte<br />
<br />
Des weiteren ist zu beachten, dass es für all diese 16-Bit-Register nur ein einziges temporäres Register gibt, so dass das Auftreten eines Interrupts, in dessen Handler ein solches Register manipuliert wird, bei einem durch ihn unterbrochenen Zugriff i.d.R. zu Datenmüll führt. 16-Bit-Zugriffe sind generell nicht atomar! Wenn mit Interrupts gearbeitet wird, kann es erforderlich sein, vor einem solchen Zugriff auf ein 16-Bit-Register die Interrupt-Bearbeitung zu deaktivieren.<br />
<br />
Beim ADC-Datenregister ADCH/ADCL ist die Synchronisierung anders gelöst. Hier wird beim Lesezugriff (ADCH/ADCL sind logischerweise read-only) auf das Low-Byte ADCL beide Teilregister für Zugriffe seitens des ADC so lange gesperrt, bis das High-Byte ADCH ausgelesen wurde. Dadurch kann der ADC nach einem Zugriff auf ADCL keinen neuen Wert in ADCH/ADCL ablegen, bis ADCH gelesen wurde. Ergebnisse von Wandlungen, die zwischen einem Zugriff auf ADCL und ADCH beendet werden, gehen verloren!<br />
<br />
Nach einem Zugriff auf ADCL muss grundsätzlich ADCH gelesen werden!<br />
<br />
In beiden Fällen – also sowohl bei den Timern als auch beim ADC – werden vom C-Compiler 16-Bit Pseudo-Register zur Verfügung gestellt (z.&nbsp;B. TCNT1H/TCNT1L → TCNT1, ADCH/ADCL → ADC bzw. ADCW), bei deren Verwendung der Compiler automatisch die richtige Zugriffsreihenfolge regelt. In C-Programmen sollten grundsätzlich diese 16-Bit-Register verwendet werden! Sollte trotzdem ein Zugriff auf ein Teilregister erforderlich sein, sind obige Angaben zu berücksichtigen.<br />
<br />
Es ist darauf zu achten, dass auch ein Zugriff auf die 16-Bit-Register vom Compiler in zwei 8-Bit-Zugriffe aufgeteilt wird und dementsprechend genauso nicht-atomar ist wie die Einzelzugriffe. Auch hier gilt, dass u.U. die Interrupt-Bearbeitung gesperrt werden muss, um Datenmüll zu vermeiden.<br />
<br />
Beim ADC gibt es für den Fall, dass eine Auflösung von 8 Bit ausreicht, die Möglichkeit, das Ergebnis "linksbündig" in ADCH/ADCL auszurichten, so dass die relevanten 8 MSB in ADCH stehen. In diesem Fall muss bzw. sollte nur ADCH ausgelesen werden.<br />
<br />
ADC und ADCW sind unterschiedliche Bezeichner für das selbe Registerpaar. Üblicherweise kann man in C-Programmen ADC verwenden, was analog zu den anderen 16-Bit-Registern benannt ist. ADCW (ADC Word) existiert nur deshalb, weil die Headerdateien auch für Assembler vorgesehen sind und es bereits einen Assembler-Befehl namens ''adc'' gibt. <br />
<br />
Im Umgang mit 16-Bit Registern siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Related Pages/Frequently Asked Questions/Nr. 8<br />
* Datenblatt Abschnitt ''Accessing 16-bit Registers''<br />
<br />
== IO-Register als Parameter und Variablen ==<br />
<br />
Um Register als Parameter für eigene Funktionen übergeben zu können, muss man sie als einen volatile uint8_t Pointer übergeben. Zum Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <util/delay.h><br />
<br />
uint8_t key_pressed (volatile uint8_t *inputreg, uint8_t inputbit)<br />
{<br />
static uint8_t last_state = 0;<br />
<br />
if (last_state == (*inputreg & (1<<inputbit)))<br />
return 0; /* keine Änderung */<br />
<br />
/* Wenn doch, warten bis etwaiges Prellen vorbei ist: */<br />
_delay_ms(20);<br />
<br />
/* Zustand für nächsten Aufruf merken: */<br />
last_state = *inputreg & (1<<inputbit);<br />
<br />
/* und den entprellten Tastendruck zurückgeben: */<br />
return *inputreg & (1<<inputbit);<br />
}<br />
<br />
/* Beispiel für einen Funktionsaufruf: */<br />
<br />
void foo (void)<br />
{<br />
uint8_t i = key_pressed (&PINB, PB1);<br />
}<br />
</syntaxhighlight><br />
<br />
Ein Aufruf der Funktion mit call by value würde Folgendes bewirken: Beim Funktionseintritt wird nur eine Kopie des momentanen Portzustandes angefertigt, die sich unabhängig vom tatsächlichen Zustand das Ports nicht mehr ändert, womit die Funktion wirkungslos wäre. Die Übergabe eines Zeigers wäre die Lösung, wenn der Compiler nicht optimieren würde. Denn dadurch wird im Programm nicht von der Hardware gelesen, sondern wieder nur von einem Abbild im Speicher. Das Ergebnis wäre das gleiche wie oben. Mit dem Schlüsselwort volatile sagt man nun dem Compiler, dass die entsprechende Variable entweder durch andere Softwareroutinen (Interrupts) oder durch die Hardware verändert werden kann.<br />
<br />
Siehe auch: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass avr-libc FAQ: "How do I pass an IO port as a parameter to a function?"]<br />
<br />
= Zugriff auf IO-Ports =<br />
<br />
Jeder AVR implementiert eine unterschiedliche Menge an GPIO-Registern<br />
(GPIO - General Purpose Input/Output). Diese Register dienen dazu:<br />
* einzustellen welche der Anschlüsse ("Beinchen") des Controllers als Ein- oder Ausgänge dienen<br />
* bei Ausgängen deren Zustand festzulegen<br />
* bei Eingängen deren Zustand zu erfassen<br />
<br />
Mittels GPIO werden digitale Zustände gesetzt und erfasst, d.h. die Spannung an einem Ausgang wird ein- oder ausgeschaltet und an einem Eingang wird erfasst, ob die anliegende Spannung über oder unter einem bestimmten Schwellwert liegt. Im Datenblatt Abschnitt Electrical Characteristics/DC Characteristics finden sich die Spannungswerte (V_OL, V_OH für Ausgänge, V_IL, V_IH für Eingänge).<br />
<br />
Die Verarbeitung von analogen Eingangswerten und die Ausgabe von Analogwerten wird in Kapitel [[AVR-GCC-Tutorial#Analoge_Ein-_und_Ausgabe|Analoge Ein- und Ausgabe]] behandelt.<br />
<br />
Die physischen Ein- und Ausgänge werden bei AVR-Controllern zu logischen Ports gruppiert.<br />
<br />
Alle Ports werden über Register gesteuert. Dazu sind jedem Port 3 Register zugeordnet:<br />
<br />
{| class="wikitable"<br />
|- <br />
! width="10%"| DDRx<br />
| Datenrichtungsregister für Port'''x'''. <br />
'''x''' entspricht '''A''', '''B''', ''' C''' usw. je nach gewünschtem Port. Bit im Register gesetzt (1) für Ausgang, Bit gelöscht (0) für Eingang.<br />
|- <br />
! PINx<br />
| Eingangsadresse für Port'''x'''. <br />
Zustand des Ports. Die Bits in PINx entsprechen dem Zustand der als Eingang definierten Portpins. Bit 1 wenn Pin "high", Bit 0 wenn Portpin low.<br />
|-<br />
! PORTx<br />
| Datenregister für Port'''x'''. <br />
Dieses Register wird verwendet, um die Ausgänge eines Ports anzusteuern. Bei Pins, die mittels DDRx auf Eingang geschaltet wurden, können über PORTx<br />
die internen Pull-Up Widerstände aktiviert oder deaktiviert werden (1 = aktiv).<br />
|}<br />
<br />
Die folgenden Beispiele gehen von einem AVR aus, der sowohl Port A als auch Port B besitzt. Sie müssen für andere AVRs (zum Beispiel ATmega8/48/88/168) entsprechend angepasst werden.<br />
<br />
== Datenrichtung bestimmen ==<br />
<br />
Zuerst muss die Datenrichtung der verwendeten Pins bestimmt werden. Um dies zu erreichen, wird das Datenrichtungsregister des entsprechenden Ports beschrieben.<br />
<br />
Für jeden Pin, der als Ausgang verwendet werden soll, muss dabei das<br />
entsprechende Bit auf dem Port gesetzt werden. Soll der Pin als Eingang<br />
verwendet werden, muss das entsprechende Bit gelöscht sein.<br />
<br />
Beispiel:<br />
Angenommen am Port B sollen die Pins 0 bis 4 als Ausgänge definiert werden, die noch verbleibenden Pins 5 bis 7 sollen als Eingänge fungieren. Dazu ist es daher notwendig, im für das Port B zuständigen Datenrichtungsregister DDRB folgende Bitkonfiguration einzutragen<br />
<br />
+---+---+---+---+---+---+---+---+<br />
| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |<br />
+---+---+---+---+---+---+---+---+<br />
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br />
<br />
In C liest sich das dann so:<br />
<br />
<syntaxhighlight lang="c"><br />
// in io.h wird u.a. DDRB definiert:<br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binaer 00011111 = Hexadezimal 1F<br />
// direkte Zuweisung - standardkonform */<br />
DDRB = 0x1F; /* <br />
<br />
// Uebersichtliche Alternative - Binaerschreibweise, aber kein ISO-C<br />
DDRB = 0b00011111;<br />
<br />
// Ausfuehrliche Schreibweise: identische Funktionalitaet, mehr Tipparbeit<br />
// aber uebersichtlicher und selbsterklaerend:<br />
DDRB |= (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4); <br />
</syntaxhighlight><br />
<br />
Die Pins 5 bis 7 werden (da 0) als Eingänge geschaltet. Weitere Beispiele:<br />
<br />
<syntaxhighlight lang="c"><br />
// Alle Pins des Ports B als Ausgang definieren:<br />
DDRB = 0xff; <br />
// Pin0 wieder auf Eingang und andere im urspruenglichen Zustand belassen:<br />
DDRB &= ~(1 << DDB0);<br />
// Pin 3 und 4 auf Eingang und andere im urspruenglichen Zustand belassen:<br />
DDRB &= ~((1 << DDB3) | (1 << DDB4));<br />
// Pin 0 und 3 wieder auf Ausgang und andere im ursprünglichen Zustand belassen:<br />
DDRB |= (1 << DDB0) | (1 << DDB3);<br />
// Alle Pins auf Eingang:<br />
DDRB = 0x00;<br />
</syntaxhighlight><br />
<br />
== Vordefinierte Bitnummern für I/O-Register ==<br />
<br />
Die Bitnummern (z.&nbsp;B. PCx, PINCx und DDCx für den Port C) sind in den io*.h-Dateien der avr-libc definiert und dienen lediglich der besseren Lesbarkeit. Man muss diese Definitionen nicht verwenden oder kann auch einfach "immer" PAx, PBx, PCx usw. nutzen, auch wenn der Zugriff auf Bits in DDRx- oder PINx-Registern erfolgt. Für den Compiler sind die Ausdrücke (1<<PC7), (1<<DDC7) und (1<<PINC7) identisch zu (1<<7) (genauer: der Präprozessor ersetzt die Ausdrücke (1<<PC7),... zu (1<<7)). Ein Ausschnitt der Definitionen für Port C eines ATmega32 aus der iom32.h-Datei zur Verdeutlichung (analog für die weiteren Ports):<br />
<br />
<syntaxhighlight lang="c"><br />
...<br />
/* PORTC */<br />
#define PC7 7<br />
#define PC6 6<br />
#define PC5 5<br />
#define PC4 4<br />
#define PC3 3<br />
#define PC2 2<br />
#define PC1 1<br />
#define PC0 0<br />
<br />
/* DDRC */<br />
#define DDC7 7<br />
#define DDC6 6<br />
#define DDC5 5<br />
#define DDC4 4<br />
#define DDC3 3<br />
#define DDC2 2<br />
#define DDC1 1<br />
#define DDC0 0<br />
<br />
/* PINC */<br />
#define PINC7 7<br />
#define PINC6 6<br />
#define PINC5 5<br />
#define PINC4 4<br />
#define PINC3 3<br />
#define PINC2 2<br />
#define PINC1 1<br />
#define PINC0 0<br />
</syntaxhighlight><br />
<br />
<br />
== Digitale Signale ==<br />
<br />
Am einfachsten ist es, digitale Signale mit dem Mikrocontroller zu erfassen bzw. auszugeben.<br />
<br />
== Ausgänge ==<br />
Will man als Ausgang definierte Pins (entsprechende DDRx-Bits = 1) auf Logisch 1 setzen, setzt man die entsprechenden Bits im Portregister.<br />
<br />
Mit dem Befehl<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB = 0x04; /* besser PORTB=(1<<PB2) */<br />
<br />
// Uebersichtliche Alternative - Binaerschreibweise<br />
PORTB = 0b00000100; /* direkte Zuweisung - uebersichtlich */<br />
<br />
</syntaxhighlight><br />
wird also der Ausgang an Pin PB2 gesetzt (Beachte, dass die Bits immer ''von 0 an'' gezählt werden, das niederwertigste Bit ist also Bitnummer 0 und nicht etwa Bitnummer 1).<br />
<br />
Man beachte, dass bei der Zuweisung mittels '''=''' immer alle Pins gleichzeitig angegeben werden. Man sollte also, wenn nur bestimmte Ausgänge geschaltet werden sollen, zuerst den aktuellen Wert des Ports einlesen und das Bit des gewünschten Ports in diesen Wert einfließen lassen. Will man also nur den dritten Pin (Bit Nr. 2) an Port B auf "high" setzen und den Status der anderen Ausgänge unverändert lassen, nutze man diese Form:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB = PORTB | 0x04; /* besser: PORTB = PORTB | ( 1<<PB2 ) */<br />
/* vereinfacht durch Nutzung des |= Operators : */<br />
PORTB |= (1<<PB2);<br />
<br />
/* auch mehrere "gleichzeitig": */<br />
PORTB |= (1<<PB4) | (1<<PB5); /* Pins PB4 und PB5 "high" */<br />
</syntaxhighlight><br />
<br />
"Ausschalten", also Ausgänge auf "low" setzen, erfolgt analog:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB &= ~(1<<PB2); /* loescht Bit 2 in PORTB und setzt damit Pin PB2 auf low */ <br />
PORTB &= ~( (1<<PB4) | (1<<PB5) ); /* Pin PB4 und Pin PB5 "low" */<br />
</syntaxhighlight><br />
Siehe auch [[Bitmanipulation]]<br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind in aktuellen Versionen der avr-libc nicht mehr enthalten und auch nicht mehr erforderlich.<br />
<br />
''Falls der Anfangszustand von Ausgängen kritisch ist, muss die Reihenfolge beachtet werden, mit der die Datenrichtung (DDRx) eingestellt und der Ausgabewert (PORTx) gesetzt wird:''<br />
<br />
Für Ausgangspins, die mit Anfangswert "high" initialisiert werden sollen:<br />
* zuerst die Bits im PORTx-Register setzen<br />
* anschließend die Datenrichtung auf Ausgang stellen<br />
<br />
Daraus ergibt sich die Abfolge für einen Pin, der bisher als Eingang mit abgeschaltetem Pull-Up konfiguriert war:<br />
* setze PORTx: interner Pull-Up aktiv<br />
* setze DDRx: Ausgang ("high")<br />
<br />
Bei der Reihenfolge erst DDRx und dann PORTx kann es zu einem kurzen "low-Puls" kommen, der auch externe Pull-Up-Widerstände "überstimmt". Die (ungünstige) Abfolge: Eingang -> setze DDRx: Ausgang (auf "low", da PORTx nach Reset 0) -> setze PORTx: Ausgang auf high. Vergleiche dazu auch das Datenblatt Abschnitt ''Configuring the Pin''.<br />
<br />
== Eingänge (Wie kommen Signale in den &micro;C) ==<br />
<br />
Die digitalen Eingangssignale können auf verschiedene Arten zu unserer Logik gelangen.<br />
<br />
=== Signalkopplung ===<br />
<br />
Am einfachsten ist es, wenn die Signale direkt aus einer anderen digitalen Schaltung übernommen werden können. Hat der Ausgang der entsprechenden Schaltung TTL-Pegel dann können wir sogar direkt den Ausgang der Schaltung mit einem Eingangspin von unserem Controller verbinden.<br />
<br />
Hat der Ausgang der anderen Schaltung keinen TTL-Pegel so müssen wir den Pegel über entsprechende Hardware (z.&nbsp;B. Optokoppler, [[Widerstand#Spannungsteiler|Spannungsteiler]], "Levelshifter" aka [[Pegelwandler]]) anpassen.<br />
<br />
Die Masse der beiden Schaltungen muss selbstverständlich miteinander verbunden werden. Der Software selber ist es natürlich letztendlich egal, wie das Signal eingespeist wird. Wir können ja ohnehin lediglich prüfen, ob an einem Pin unseres Controllers eine logische 1 (Spannung größer ca. 0,7*Vcc) oder eine logische 0 (Spannung kleiner ca. 0,2*Vcc) anliegt. Detaillierte Informationen darüber, ab welcher Spannung ein Eingang als 0 ("low") bzw. 1 ("high") erkannt wird, liefert die Tabelle DC Characteristics im Datenblatt des genutzten Controllers.<br />
<br />
{| class="wikitable" style="text-align:center; width:20em"<br />
|+ '''Logikpegel'''<br />
|-<br />
! VCC [V]<br />
! Low [V]<br />
! High [V]<br />
|-<br />
! 5<br />
| 1,0 || 3,5<br />
|-<br />
! 3,3<br />
| 0,66 || 2,3<br />
|-<br />
! 1,8<br />
| 0,36 || 1,26 <br />
|}<br />
<br />
Die Abfrage der Zustände der Portpins erfolgt direkt über den Registernamen.<br />
<br />
{{Warnung|Dabei ist wichtig, zur Abfrage der Eingänge ''nicht'' etwa Portregister '''PORTx''' zu verwenden, sondern Eingangsregister '''PINx'''. Ansonsten liest man nicht den Zustand der Eingänge, sondern den Status der internen Pull-Up-Widerstände. Die Abfrage der Pinzustände über PORTx statt PINx ist ein häufiger Fehler beim AVR-"Erstkontakt".}}<br />
<br />
Will man also die aktuellen Signalzustände von Port D abfragen und in eine Variable namens bPortD abspeichern, schreibt man folgende Befehlszeilen:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdint.h><br />
...<br />
uint8_t bPortD;<br />
...<br />
bPortD = PIND;<br />
...<br />
</syntaxhighlight><br />
<br />
Mit den C-Bitoperationen kann man den Status der Bits abfragen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
/* Fuehre Aktion aus, wenn Bit Nr. 1 (das "zweite" Bit) in PINC gesetzt (1) ist */<br />
if ( PINC & (1<<PINC1) ) {<br />
/* Aktion */<br />
}<br />
<br />
/* Fuehre Aktion aus, wenn Bit Nr. 2 (das "dritte" Bit) in PINB geloescht (0) ist */<br />
if ( !(PINB & (1<<PINB2)) ) {<br />
/* Aktion */<br />
}<br />
...<br />
</syntaxhighlight><br />
Siehe auch [[Bitmanipulation#Bits_prüfen]]<br />
<br />
=== Interne Pull-Up Widerstände ===<br />
<br />
Portpins für Ein- und Ausgänge (GPIO) eines AVR verfügen über zuschaltbare interne Pull-Up Widerstände (nominal mehrere 10kOhm, z.&nbsp;B. ATmega16 20-50kOhm). Diese können in vielen Fällen statt externer Widerstände genutzt werden.<br />
<br />
Die internen Pull-Up Widerstände von Vcc zu den einzelnen Portpins werden über das Register ''' PORTx''' aktiviert bzw. deaktiviert, wenn ein Pin als ''' Eingang''' geschaltet ist.<br />
<br />
Wird der Wert des entsprechenden Portpins auf 1 gesetzt, so ist der Pull-Up Widerstand aktiviert. Bei einem Wert von 0 ist der Pull-Up Widerstand nicht aktiv. Man sollte jeweils entweder den internen oder einen externen Pull-Up Widerstand verwenden, aber nicht beide zusammen.<br />
<br />
Im Beispiel werden alle Pins des Ports D als Eingänge geschaltet und alle Pull-Up Widerstände aktiviert. Weiterhin wird Pin PC7 als Eingang geschaltet und dessen interner Pull-Up Widerstand aktiviert, ohne die Einstellungen für die anderen Portpins (PC0-PC6) zu verändern.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
DDRD = 0x00; /* alle Pins von Port D als Eingang */<br />
PORTD = 0xff; /* interne Pull-Ups an allen Port-Pins aktivieren */<br />
...<br />
DDRC &= ~(1<<PC7); /* Pin PC7 als Eingang */<br />
PORTC |= (1<<PC7); /* internen Pull-Up an PC7 aktivieren */<br />
</syntaxhighlight><br />
<br />
=== Taster und Schalter ===<br />
<br />
Der Anschluss mechanischer Kontakte an den Mikrocontroller, ist zwischen zwei unterschiedliche Methoden zu unterscheiden: ''Active Low'' und ''Active High''.<br />
<br />
<gallery widths="300" heights="300" caption="Anschluss mechanischer Kontakte an einen µC"><br />
Image:Active Low.gif|'''Active Low:''' Bei dieser Methode wird der Kontakt zwischen den Eingangspin des Controllers und Masse geschaltet. Damit bei offenem Schalter der Controller kein undefiniertes Signal bekommt, wird zwischen die Versorgungsspannung und den Eingangspin ein sogenannter '''Pull-Up''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffnetem Schalter auf logisch 1 zu ziehen.<br />
Image:Active High.gif|'''Active High:''' Hier wird der Kontakt zwischen die Versorgungsspannung und den Eingangspin geschaltet. Damit bei offener Schalterstellung kein undefiniertes Signal am Controller ansteht, wird zwischen den Eingangspin und die Masse ein '''Pull-Down''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffneter Schalterstellung auf logisch 0 zu halten. <br />
</gallery><br />
<br />
Der Widerstandswert von Pull-Up- und Pull-Down-Widerständen ist an sich nicht kritisch. Wird er allerdings zu hoch gewählt, ist die Wirkung eventuell nicht gegeben. Als üblicher Wert haben sich 10 kOhm eingebürgert. Die AVRs verfügen an den meisten Pins über zuschaltbare interne Pull-Up Widerstände (vgl. Abschnitt [[AVR-GCC-Tutorial#Interne Pull-Up Widerstände|Interne Pull-Up Widerstände]]), welche insbesondere wie hier bei Tastern und ähnlichen Bauteilen (z.&nbsp;B. Drehgebern) statt externer Bauteile verwendet werden können. Interne Pull-Down-Widerstand sind nicht verfügbar und müssen daher in Form zusätzlicher Bauteile in die Schaltung eingefügt werden.<br />
<br />
==== Taster entprellen ====<br />
<br />
Siehe: ''[[Entprellung#Warteschleifen-Verfahren|Entprellung: Warteschleifen-Verfahren]]<br />
<br />
= Warteschleifen (delay.h) =<br />
<br />
Der Programmablauf kann verschiedene Arten von Wartefunktionen erfordern:<br />
<br />
* Warten im Sinn von Zeitvertrödeln<br />
* Warten auf einen bestimmten Zustand an den I/O-Pins<br />
* Warten auf einen bestimmten Zeitpunkt (siehe Timer)<br />
* Warten auf einen bestimmten Zählerstand (siehe Counter)<br />
<br />
Der einfachste Fall, das Zeitvertrödeln, kann in vielen Fällen und mit großer Genauigkeit anhand der avr-libc Bibliotheksfunktionen _delay_ms() und _delay_us() erledigt werden. Die Bibliotheksfunktionen sind einfachen Zählschleifen (Warteschleifen) vorzuziehen, da leere Zählschleifen ohne besondere Vorkehrungen sonst bei eingeschalteter Optimierung vom avr-gcc-Compiler wegoptimiert werden. Weiterhin sind die Bibliotheksfunktionen bereits darauf vorbereitet, die in F_CPU definierte Taktfrequenz zu verwenden. Außerdem sind die Funktionen der Bibliothek wirklich getestet.<br />
<br />
Einfach!? Schon, aber während gewartet wird, macht der µC nichts anderes mehr (abgesehen von möglicherweise auftretenden Interrupts, falls welche aktiviert sind). Die Wartefunktion blockiert den Programmablauf. Möchte man einerseits warten, um z.&nbsp;B. eine LED blinken zu lassen und gleichzeitig andere Aktionen ausführen z.&nbsp;B. weitere LED bedienen, sollten die Timer/Counter des AVR verwendet werden, siehe Artikel [[Multitasking]].<br />
<br />
Die Bibliotheksfunktionen funktionieren allerdings nur dann korrekt, wenn sie mit zur Übersetzungszeit (beim Compilieren) bekannten konstanten Werten aufgerufen werden. Der Quellcode muss mit eingeschalteter Optimierung übersetzt werden, sonst wird sehr viel Maschinencode erzeugt, und die Wartezeiten stimmen nicht mehr mit dem Parameter überein.<br />
<br />
Eine weitere Einschränkung liegt darin, daß sie möglicherweise länger warten, als erwartet, nämlich in dem Fall, daß Interrupts auftreten und die _delay...()-Funktion unterbrechen. Genau genommen warten diese nämlich nicht eine bestimmte Zeit, sondern verbrauchen eine bestimmte Anzahl von Prozessortakten. Die wiederum ist so bemessen, daß ohne Unterbrechung durch Interrupts die gewünschte Wartezeit erreicht wird.<br />
Wird das Warten aber durch eine oder mehrere ISR unterbrochen, die zusammen 1% Prozessorzeit verbrauchen, dann dauert das Warten etwa 1% länger. Bei 50% Last durch die ISR dauert das Warten doppelt solange wie gewünscht, bei 90% zehnmal solange...<br />
<br />
Abhängig von der Version der Bibliothek verhalten sich die Bibliotheksfunktionen etwas unterschiedlich.<br />
<br />
== avr-libc Versionen bis 1.6 ==<br />
<br />
Die Wartezeit der Funktion _delay_ms() ist auf 262,14ms/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 13,1ms warten. Die Wartezeit der Funktion _delay_us() ist auf 768us/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 38,4µs warten. Längere Wartezeiten müssen dann über einen mehrfachen Aufruf in einer Schleife gelöst werden.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.&nbsp;B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h> /* in älteren avr-libc Versionen <avr/delay.h> */ <br />
<br />
/*<br />
lange, variable Verzögerungszeit, Einheit in Millisekunden<br />
<br />
Die maximale Zeit pro Funktionsaufruf ist begrenzt auf <br />
262.14 ms / F_CPU in MHz (im Beispiel: <br />
262.1 / 3.6864 = max. 71 ms) <br />
<br />
Daher wird die kleine Warteschleife mehrfach aufgerufen,<br />
um auf eine längere Wartezeit zu kommen. Die zusätzliche <br />
Prüfung der Schleifenbedingung lässt die Wartezeit geringfügig<br />
ungenau werden (macht hier vielleicht 2-3ms aus).<br />
*/<br />
<br />
void long_delay(uint16_t ms)<br />
{<br />
for(; ms>0; ms--) _delay_ms(1);<br />
}<br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) // Endlosschleife<br />
{ <br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.&nbsp;B. angeschlossene LED<br />
long_delay(1000); // Eine Sekunde warten...<br />
}<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
== avr-libc Versionen ab 1.7 ==<br />
<br />
_delay_ms() kann mit einem Argument bis 6553,5 ms (= 6,5535 Sekunden) benutzt werden. Es ist nicht möglich, eine Variable als Argument zu übergeben. Wird die früher gültige Grenze von 262,14 ms/F_CPU (in MHz) überschritten, so arbeitet _delay_ms() einfach etwas ungenauer und zählt nur noch mit einer Auflösung von 1/10 ms. Eine Verzögerung von 1000,10 ms ließe sich nicht mehr von einer von 1000,19 ms unterscheiden. Ein Verlust, der sich im Allgemeinen verschmerzen lässt. Dem Programmierer wird keine Rückmeldung gegeben, dass die Funktion ggf. gröber arbeitet, d.h. wenn es darauf ankommt, bitte den Parameter wie bisher geschickt wählen.<br />
<br />
Die Funktion _delay_us() wurde ebenfalls erweitert. Wenn deren maximal als genau behandelbares Argument überschritten wird, benutzt diese intern _delay_ms(). Damit gelten in diesem Fall die _delay_ms() Einschränkungen.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus, avr-libc ab Version 1.6<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h><br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) { // Endlosschleife<br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED<br />
_delay_ms(1000); // Eine Sekunde +/-1/10000 Sekunde warten...<br />
// funktioniert nicht mit Bibliotheken vor 1.6<br />
<br />
}<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
Die _delay_ms() und die _delay_us aus '''avr-libc 1.7.0''' sind fehlerhaft. _delay_ms () läuft 4x schneller als erwartet. Abhilfe ist eine korrigierte Includedatei: [http://www.mikrocontroller.net/topic/196738#1943039]<br />
<br />
= Programmieren mit Interrupts =<br />
<br />
<div style="float:right; margin:2em;"><br />
[[Image:Interrupt Programme.gif]]<br />
</div><br />
Nachdem wir nun alles Wissenswerte für die serielle Programmerstellung<br />
gelernt haben nehmen wir jetzt ein völlig anderes Thema in Angriff, nämlich<br />
die Programmierung unter Zuhilfenahme der Interrupts des AVR.<br />
<br />
Tritt ein Interrupt auf, unterbricht (engl. interrupts) der Controller die Verarbeitung des Hauptprogramms und verzweigt zu einer Interruptroutine. Das Hauptprogramm wird also beim Eintreffen eines Interrupts unterbrochen, die Interruptroutine ausgeführt und danach erst wieder das Hauptprogramm an der Unterbrechungsstelle fortgesetzt (vgl. die Abbildung).<br />
<br />
Um Interrupts verarbeiten zu können, ist folgendes zu beachten:<br />
<br />
* Für jede aktivierte Interruptquelle ist eine Funktion zu programmieren, in der die beim Auftreten des jeweiligen Interrupts erforderlichen Verarbeitungsschritte enthalten sind. Für diese Funktion existieren verschiedene Bezeichnungen. Üblich sind die englischen Begriffe Interrupt-Handler oder Interrupt-Service-Routinen (ISR), man findet aber auch die Bezeichnungen Interruptverarbeitungs- oder -behandlungsroutine oder auch kurz Interruptroutine. Zum Beispiel wird üblicherweise in der ISR zur Verarbeitung des Empfangsinterrupts eines UARTs (UART-RX Interrupt) das empfangene Zeichen in einen Zwischenspeicher (FIFO-Buffer) kopiert, dessen Inhalt später von anderen Programmteilen geleert wird. Sofern der Zwischenspeicher ausreichend groß ist, geht also kein Zeichen verloren, auch wenn im Hauptprogramm zeitintensive Operationen durchgeführt werden.<br />
* Die benötigten Interrupts sind in den jeweiligen Funktionsbausteinen einzuschalten. Dies erfolgt über das jeweilige Aktivierungsbit (Interrupt Enable) in einem der Hardwareregister (z.B. RX(Complete)Interrupt Enable eines UARTs)<br />
* Sämtliche Interrupts werden über einen weiteren globalen Schalter aktiviert und deaktiviert. Zur Verarbeitung der Interrupts ist dieser Schalter zu aktivieren (sei(), siehe unten).<br />
<br />
Alle Punkte sind zu beachten. Fehlt z.B. die globale Aktivierung, werden Interruptroutinen auch dann nicht aufgerufen, wenn sie im Funktionsbaustein eingeschaltet sind und eine Behandlungsroutine verhanden ist.<br />
<br />
Siehe auch<br />
<br />
* [http://www.mikrocontroller.net/forum/read-1-235092.html#new Ausführlicher Thread im Forum]<br />
* Artikel [[Interrupt]]<br />
* Artikel [[Multitasking]]<br />
{{Clear}}<br />
<br />
== Anforderungen an Interrupt-Routinen ==<br />
<br />
Um unliebsamen Überraschungen vorzubeugen, sollten einige Grundregeln bei der Implementierung der Interruptroutinen beachtet werden. Interruptroutinen sollten möglichst kurz und schnell abarbeitbar sein, daraus folgt:<br />
<br />
* Keine umfangreichen Berechnungen innerhalb der Interruptroutine. (*)<br />
* Keine langen Programmschleifen.<br />
* Obwohl es möglich ist, während der Abarbeitung einer Interruptroutine andere oder sogar den gleichen Interrupt wieder zuzulassen, wird davon ohne genaue Kenntnis der internen Abläufe dringend abgeraten.<br />
<br />
Interruptroutinen (ISRs) sollten also möglichst kurz sein und keine Schleifen mit vielen Durchläufen enthalten. Längere Operationen können meist in einen "Interrupt-Teil" in einer ISR und einen "Arbeitsteil" im Hauptprogramm aufgetrennt werden. Z.B. Speichern des Zustands aller Eingänge im EEPROM in bestimmten Zeitabständen: ISR-Teil: Zeitvergleich (Timer,RTC) mit Logzeit/-intervall. Bei Übereinstimmung ein globales Flag setzen (volatile bei Flag-Deklaration nicht vergessen, s.u.). Dann im Hauptprogramm prüfen, ob das Flag gesetzt ist. Wenn ja: die Daten im EEPROM ablegen und Flag löschen.<br />
<br />
(*)<br />
Hinweis: <br />
Es gibt allerdings die seltene Situation, dass man gerade eingelesene<br />
ADC-Werte sofort verarbeiten muss. Besonders dann, wenn man mehrere Werte sehr<br />
schnell hintereinander bekommt. Dann bleibt einem nichts anderes übrig, als die<br />
Werte noch in der ISR zu verarbeiten. Kommt aber sehr selten vor und sollte<br />
durch geeignete Wahl des Systemtaktes bzw. Auswahl des Controllers vermieden werden!<br />
<br />
== Interrupt-Quellen ==<br />
<br />
Die folgenden Ereignisse können einen Interrupt auf einem AVR AT90S2313 auslösen, wobei die Reihenfolge der Auflistung auch die Priorität der Interrupts aufzeigt.<br />
<br />
* Reset<br />
* Externer Interrupt 0<br />
* Externer Interrupt 1<br />
* Timer/Counter 1 Capture Ereignis<br />
* Timer/Counter 1 Compare Match<br />
* Timer/Counter 1 Überlauf<br />
* Timer/Counter 0 Überlauf<br />
* UART Zeichen empfangen<br />
* UART Datenregister leer<br />
* UART Zeichen gesendet<br />
* Analoger Komparator<br />
<br />
Die Anzahl der möglichen Interruptquellen variiert zwischen den verschiedenen Microcontroller-Typen. Im Zweifel hilft ein Blick ins Datenblatt ("Interrupt Vectors").<br />
<br />
== Register ==<br />
<br />
Der AT90S2313 verfügt über 2 Register die mit den<br />
Interrupts zusammenhängen.<br />
<br />
{| class="wikitable"<br />
|- <br />
!width="10%"| GIMSK<br />
| '''G'''eneral '''I'''nterrupt '''M'''a'''sk''' Register.<br /><br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit <br />
| 7 || 6|| 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INT1''' || '''INT0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INT1''' (External '''Int'''errupt Request '''1''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT1'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
'''INT0''' (External '''Int'''errupt Request '''0''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT0'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
|- <br />
! GIFR<br />
| '''G'''eneral '''I'''nterrupt '''F'''lag '''R'''egister.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INTF1''' || '''INTF0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INTF1''' (External '''Int'''errupt Flag '''1''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT1'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
<br />
'''INTF0''' (External '''Int'''errupt Flag '''0''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT0'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
|- <br />
! MCUCR<br />
| '''MCU''' '''C'''ontrol '''R'''egister.<br />
<br />
Das MCU Control Register enthält Kontrollbits für allgemeine MCU-Funktionen.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''-'''|| '''-'''|| '''SE'''|| '''SM'''|| '''ISC11'''|| '''ISC10'''|| '''ISC01'''|| '''ISC00'''<br />
|- <br />
! R/W<br />
| R || R || R/W || R/W || R/W || R/W || R/W || R/W<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
<br />
|}<br />
<br />
'''SE''' ('''S'''leep '''E'''nable)<br />
:Dieses Bit muss gesetzt sein, um den Controller mit dem '''SLEEP'''-Befehl in den Schlafzustand versetzen zu können.<br />
:Um den Schlafmodus nicht irrtümlich einzuschalten, wird empfohlen, das Bit erst unmittelbar vor Ausführung des '''SLEEP'''-Befehls zu setzen.<br />
<br />
'''SM''' ('''S'''leep '''M'''ode)<br />
:Dieses Bit bestimmt über den Schlafmodus.<br />
:Ist das Bit gelöscht, so wird der '''Idle'''-Modus ausgeführt. Ist das Bit gesetzt, so wird der '''Power-Down'''-Modus ausgeführt. (für andere AVR Controller siehe Abschnitt "Sleep-Mode")<br />
<br />
'''ISC11''', '''ISC10''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''1''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT1'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
!width="10%"| ISC11 ||width="10%"| ISC10 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT1''' erzeugt einen Interrupt.<br />
<br />
Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|}<br />
<br />
'''ISC01''', '''ISC00''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''0''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT0'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
!width="10%"| ISC01 ||width="10%"| ISC00 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT0''' erzeugt einen Interrupt.<br />
<br />
Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|}<br />
<br />
|}<br />
<br />
== Allgemeines über die Interrupt-Abarbeitung ==<br />
<br />
Wenn ein Interrupt eintrifft, wird automatisch das '''Global Interrupt Enable''' Bit im Status Register '''SREG''' gelöscht und alle weiteren Interrupts unterbunden. Dieses wird automatisch wieder gesetzt, wenn die Interruptroutine beendet wird. Wenn in der Zwischenzeit weitere Interrupts eintreffen, werden die zugehörigen Interrupt-Bits gesetzt und die Interrupts bei Beendigung der laufenden Interrupt-Routine in der Reihenfolge ihrer Priorität ausgeführt. Dies kann<br />
eigentlich nur dann zu Problemen führen, wenn ein hoch priorisierter Interrupt ständig und in kurzer Folge auftritt. Dieser sperrt dann möglicherweise alle anderen Interrupts mit niedrigerer Priorität. Dies ist einer der Gründe, weshalb die Interrupt-Routinen sehr kurz gehalten werden sollen. Es ist möglich das GIE-Bit in der ISR zu setzen und so schon wieder weitere Interrupts zuzulassen - allerdings sollte man damit vorsichtig sein und genau wissen was man damit macht. Kritisch wird es vor allem wenn der gleiche Interrupt noch einmal kommt, bevor die ISR abgearbeitet ist. <br />
<br />
<!-- === Das Status-Register ===<br />
<br />
Es gilt auch zu beachten, dass das Status-Register während der Abarbeitung einer Interruptroutine nicht automatisch gesichert wird. Falls notwendig, muss dies vom Programmierer selber vorgesehen werden. --><br />
<br />
== Interrupts mit avr-gcc ==<br />
<br />
<!-- ''Anmerkung eines Nutzers: Ich habe mir das Thema hier angearbeitet und hatte am Anfang starke Probleme: Jeder Interrupt muss nochmals einzeln aktiviert werden. Es reicht nicht nur per ''sei()'' die Interrupts global zu aktiveren.'' - mthomas: Hoffentlich duch die modifizerte Einleitung etwas offensichtlicher erläutert. Ansonsten bitte per Eintrag auf die Diskussionseite nochmals melden) --> <br />
<!-- Selbstverständlich können alle interruptspezifischen Registerzugriffe wie gewohnt über I/O-Adressierung vorgenommen werden. Etwas einfacher geht es jedoch, wenn wir die vom Compiler zur Verfügung gestellten Mittel einsetzen.--><br />
Funktionen zur Interrupt-Verarbeitung werden in den Includedateien ''interrupt.h'' der avr-libc zur Verfügung gestellt (bei älterem Quellcode zusätzlich ''signal.h'').<br />
<br />
<syntaxhighlight lang="c"><br />
// fuer sei(), cli() und ISR():<br />
#include <avr/interrupt.h><br />
</syntaxhighlight><br />
<br />
Das Makro '''sei()''' schaltet die Interrupts ein. Eigentlich wird nichts anderes gemacht, als das '''Global Interrupt Enable''' Bit im Status Register gesetzt.<br />
<br />
<syntaxhighlight lang="c"><br />
sei();<br />
</syntaxhighlight><br />
<br />
Das Makro '''cli()''' schaltet die Interrupts aus, oder anders gesagt, das '''Global Interrupt Enable''' Bit im Status Register wird gelöscht.<br />
<br />
<syntaxhighlight lang="c"><br />
cli();<br />
</syntaxhighlight><br />
<br />
Oft steht man vor der Aufgabe, dass eine Codesequenz nicht unterbrochen werden darf. Es liegt dann nahe, zu Beginn dieser Sequenz ein cli() und am Ende ein sei() einzufügen. Dies ist jedoch ungünstig, wenn die Interrupts vor Aufruf der Sequenz deaktiviert waren und danach auch weiterhin deaktiviert bleiben sollen. Ein sei() würde ungeachtet des vorherigen Zustands die Interrupts aktivieren, was zu unerwünschten Seiteneffekten führen kann. Die aus dem folgenden Beispiel ersichtliche Vorgehensweise ist in solchen Fällen vorzuziehen:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <inttypes.h><br />
<br />
//...<br />
<br />
void NichtUnterbrechenBitte(void)<br />
{<br />
uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister<br />
<br />
tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) sichern<br />
cli(); // Interrupts global deaktivieren<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
/* Beispiel Anfang<br />
JTAG-Interface eines ATmega16 per Software deaktivieren <br />
und damit die JTAG-Pins an PORTC für "general I/O" nutzbar machen<br />
ohne die JTAG-Fuse-Bit zu aendern. Dazu ist eine "timed sequence"<br />
einzuhalten (vgl Datenblatt ATmega16, Stand 10/04, S. 229): <br />
Das JTD-Bit muss zweimal innerhalb von 4 Taktzyklen geschrieben <br />
werden. Ein Interrupt zwischen den beiden Schreibzugriffen wuerde <br />
die erforderliche Sequenz "brechen", das JTAG-Interface bliebe<br />
weiterhin aktiv und die IO-Pins weiterhin für JTAG reserviert. */<br />
<br />
MCUCSR |= (1<<JTD);<br />
MCUCSR |= (1<<JTD); // 2 mal in Folge ,vgl. Datenblatt fuer mehr Information<br />
<br />
/* Beispiel Ende */<br />
<br />
SREG = tmp_sreg; // Status-Register wieder herstellen <br />
// somit auch das I-Flag auf gesicherten Zustand setzen<br />
}<br />
<br />
void NichtSoGut(void)<br />
{<br />
cli();<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
sei();<br />
}<br />
<br />
<br />
int main(void)<br />
{<br />
//...<br />
<br />
cli(); <br />
// Interrupts global deaktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// auch nach Aufruf der Funktion deaktiviert<br />
<br />
sei();<br />
// Interrupts global aktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// weiterhin aktiviert<br />
//...<br />
<br />
/* Verdeutlichung der unguenstigen Vorgehensweise mit cli/sei: */<br />
cli(); <br />
// Interrupts jetzt global deaktiviert <br />
<br />
NichtSoGut();<br />
// nach Aufruf der Funktion sind Interrupts global aktiviert <br />
// dies ist mglw. ungewollt!<br />
//...<br />
<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
<!-- mt: besser so nicht(?), lieber "datenblattkonform"<br />
<br />
<font face="Courier New">'''timer_enable_int (unsigned char ints);<br /><br />
'''</font>Schaltet Timerbezogene Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle<br />
Timerinterrupts ausgeschaltet, ansonsten muss in '''ints''' angegeben werden,<br />
welche Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">timer_enable_int (1 << TOIE1));<br /><br />
</font>'''Achtung: Wenn ein Timerinterrupt eingeschaltet wird während ein<br />
anderer Timerinterrupt bereits läuft, dann müssen beide Bits angegeben werden<br />
sonst wird der andere Timerinterrupt versehentlich ausgeschaltet.<br />
<br />
<font face="Courier New">'''enable_external_int (unsigned char ints);<br /><br />
'''</font>Schaltet die externen Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle externen<br />
Interrrups ausgeschaltet, ansonsten muss in '''ints''' angegeben werden, welche<br />
Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">enable_external_int ((1<<br />
</font>'''Schaltet die externen Interrupts 0 und 1 ein.<br />
<br />
Nachdem nun die Interrupts aktiviert sind, braucht es selbstverständlich noch den auszuführenden Code, der ablaufen soll, wenn ein Interrupt eintrifft.<br />
--><br />
Zu den aktivierten Interrupts ist eine Funktion zu programmieren, deren Code aufgerufen wird, wenn der betreffende Interrupt auftritt (Interrupt-Handler, Interrupt-Service-Routine). Dazu existiert die Definition (ein Makro) '''ISR'''.<br />
<br />
=== ISR ===<br />
<br />
(''ISR()'' ersetzt bei neueren Versionen der avr-libc ''SIGNAL()''. SIGNAL sollte nicht mehr genutzt werden, zur Portierung von SIGNAL nach ISR siehe den [[AVR-GCC-Tutorial#Anhang|Anhang]].)<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
//...<br />
ISR(Vectorname) /* vormals: SIGNAL(siglabel) dabei Vectorname != siglabel ! */<br />
{<br />
/* Interrupt Code */<br />
}<br />
</syntaxhighlight><br />
<br />
Mit ''ISR'' wird eine Funktion für die Bearbeitung eines Interrupts eingeleitet. Als Argument muss dabei die Benennung des entsprechenden Interruptvektors angegeben werden. Diese sind in den jeweiligen Includedateien IOxxxx.h zu finden. Die Bezeichnung entspricht dem Namen aus dem Datenblatt, bei dem die Leerzeichen durch Unterstriche ersetzt sind und ein ''_vect'' angehängt ist.<br />
<br />
Als Beispiel ein Ausschnitt aus der Datei für den ATmega8 (bei WinAVR Standardinstallation in C:\WinAVR\avr\include\avr\iom8.h) in der neben den aktuellen Namen für ''ISR'' (*_vect) noch die Bezeichnungen für das inzwischen nicht mehr aktuelle ''SIGNAL'' (SIG_*) enthalten sind.<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
/* $Id: iom8.h,v 1.13 2005/10/30 22:11:23 joerg_wunsch Exp $ */<br />
<br />
/* avr/iom8.h - definitions for ATmega8 */<br />
//...<br />
<br />
/* Interrupt vectors */<br />
<br />
/* External Interrupt Request 0 */<br />
#define INT0_vect _VECTOR(1)<br />
#define SIG_INTERRUPT0 _VECTOR(1)<br />
<br />
/* External Interrupt Request 1 */<br />
#define INT1_vect _VECTOR(2)<br />
#define SIG_INTERRUPT1 _VECTOR(2)<br />
<br />
/* Timer/Counter2 Compare Match */<br />
#define TIMER2_COMP_vect _VECTOR(3)<br />
#define SIG_OUTPUT_COMPARE2 _VECTOR(3)<br />
<br />
/* Timer/Counter2 Overflow */<br />
#define TIMER2_OVF_vect _VECTOR(4)<br />
#define SIG_OVERFLOW2 _VECTOR(4)<br />
<br />
/* Timer/Counter1 Capture Event */<br />
#define TIMER1_CAPT_vect _VECTOR(5)<br />
#define SIG_INPUT_CAPTURE1 _VECTOR(5)<br />
<br />
/* Timer/Counter1 Compare Match A */<br />
#define TIMER1_COMPA_vect _VECTOR(6)<br />
#define SIG_OUTPUT_COMPARE1A _VECTOR(6)<br />
<br />
/* Timer/Counter1 Compare Match B */<br />
#define TIMER1_COMPB_vect _VECTOR(7)<br />
#define SIG_OUTPUT_COMPARE1B _VECTOR(7)<br />
<br />
//...<br />
</syntaxhighlight><br />
<br />
<!--Vor Nutzung von SIGNAL muss ebenfalls die Header-Datei signal.h eingebunden werden.--> <br />
Mögliche Funktionsrümpfe für Interruptfunktionen sind zum Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
/* veraltet: #include <avr/signal.h> */<br />
<br />
ISR(INT0_vect) /* veraltet: SIGNAL(SIG_INTERRUPT0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(TIMER0_OVF_vect) /* veraltet: SIGNAL(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(USART_RXC_vect) /* veraltet: SIGNAL(SIG_UART_RECV) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
// und so weiter und so fort...<br />
</syntaxhighlight><br />
<br />
Auf die korrekte Schreibweise der Vektorbezeichnung ist zu achten. Der gcc-Compiler prüft erst ab Version 4.x, ob ein Signal/Interrupt der angegebenen Bezeichnung tatsächlich in der Includedatei definiert ist und gibt andernfalls eine Warnung aus. Bei WinAVR (ab 2/2005) wurde die Überprüfung auch in den mitgelieferten Compiler der Version 3.x integriert. Aus dem gcc-Quellcode Version 3.x selbst erstellte Compiler enthalten die Prüfung nicht (vgl. [[AVR-GCC]]). <br />
<br />
Während der Ausführung der Funktion sind alle weiteren Interrupts automatisch gesperrt. Beim Verlassen der Funktion werden die Interrupts wieder zugelassen.<br />
<br />
Sollte während der Abarbeitung der Interruptroutine ein weiterer Interrupt (gleiche oder andere Interruptquelle) auftreten, so wird das entsprechende Bit im zugeordneten Interrupt Flag Register gesetzt und die entsprechende Interruptroutine automatisch nach dem Beenden der aktuellen Funktion aufgerufen.<br />
<br />
Ein Problem ergibt sich eigentlich nur dann, wenn während der Abarbeitung der aktuellen Interruptroutine mehrere gleichartige Interrupts auftreten. Die entsprechende Interruptroutine wird im Nachhinein zwar aufgerufen jedoch wissen wir nicht, ob nun der entsprechende Interrupt einmal, zweimal oder gar noch öfter aufgetreten ist. Deshalb soll hier noch einmal betont werden, dass Interruptroutinen so schnell wie nur irgend möglich wieder verlassen werden sollten.<br />
<br />
=== Unterbrechbare Interruptroutinen ===<br />
<br />
"Faustregel": im Zweifel '''ISR'''. Die nachfolgend beschriebene Methode nur dann verwenden, wenn man sich über die unterschiedliche Funktionsweise im Klaren ist.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
<br />
ISR(XXX,ISR_NOBLOCK) /* veraltet: INTERRUPT(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt-Code */<br />
}<br />
</syntaxhighlight><br />
<br />
Hierbei steht XXX für den oben beschriebenen Namen des Vektors (also z.&nbsp;B. ''TIMER0_OVF_vect''). Der Unterschied im Vergleich zu einer herkömmlichen ISR ist, dass hier beim Aufrufen der Funktion das '''Global Enable Interrupt''' Bit durch Einfügen einer SEI-Anweisung direkt wieder gesetzt und somit alle Interrupts zugelassen werden &ndash; auch XXX-Interrupts. <br />
<br />
Bei unsachgemässer Handhabung kann dies zu erheblichen Problemen durch Rekursion wie einem Stack-Overflow oder anderen unerwarteten Effekten führen und sollte wirklich nur dann eingesetzt werden, wenn man sich sicher ist, das Ganze auch im Griff zu haben.<br />
<br />
Insbesondere sollte möglichst am ISR-Anfang die auslösende IRQ-Quelle deaktiviert und erst am Ende der ISR wieder aktiviert werden. Robuster als die Verwendung einer NOBLOCK-ISR ist daher folgender ISR-Aufbau:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
<br />
ISR (XXX) <br />
{<br />
// Implementiere die ISR ohne zunaechst weitere IRQs zuzulassen<br />
<br />
<<Deaktiviere die XXX-IRQ>><br />
<br />
// Erlaube alle Interrupts (ausser XXX)<br />
sei();<br />
<br />
//... Code ...<br />
<br />
// IRQs global deaktivieren um die XXX-IRQ wieder gefahrlos <br />
// aktivieren zu koennen<br />
cli();<br />
<br />
<<Aktiviere die XXX-IRQ>><br />
}<br />
</syntaxhighlight><br />
Auf diese Weise kann sich die XXX-IRQ nicht selbst unterbrechen, was zu einer Art Endlosschleife führen würde.<br />
<br />
Siehe auch: Hinweise in [[AVR-GCC]]<br />
<br />
siehe dazu: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html<br />
<br />
== Datenaustausch mit Interrupt-Routinen ==<br />
<br />
Variablen, die sowohl in Interrupt-Routinen (ISR = Interrupt Service Routine(s)) als auch vom übrigen Programmcode geschrieben oder gelesen werden, müssen mit einem '''volatile''' deklariert werden. Damit wird dem Compiler mitgeteilt, dass der Inhalt der Variablen vor jedem Lesezugriff aus dem Speicher gelesen und nach jedem Schreibzugriff in den Speicher geschrieben wird. Ansonsten könnte der Compiler den Code so optimieren, dass der Wert der Variablen nur in Prozessorregistern zwischengespeichert wird, die nichts von der Änderung woanders mitbekommen.<br />
<br />
Zur Veranschaulichung ein Codefragment für eine Tastenentprellung mit Erkennung einer "lange gedrückten" Taste.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <stdint.h><br />
//...<br />
<br />
// Schwellwerte<br />
// Entprellung: <br />
#define CNTDEBOUNCE 10<br />
// "lange gedrueckt:"<br />
#define CNTREPEAT 200<br />
<br />
// hier z.&nbsp;B. Taste an Pin2 PortA "active low" = 0 wenn gedrueckt<br />
#define KEY_PIN PINA<br />
#define KEY_PINNO PA2<br />
<br />
// beachte: volatile! <br />
volatile uint8_t gKeyCounter;<br />
<br />
// Timer-Compare Interrupt ISR, wird z.B. alle 10ms ausgefuehrt<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
// hier wird gKeyCounter veraendert. Die übrigen<br />
// Programmteile müssen diese Aenderung "sehen":<br />
// volatile -> aktuellen Wert immer in den Speicher schreiben<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
}<br />
else {<br />
gKeyCounter = 0;<br />
}<br />
}<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
//...<br />
/* hier: Initialisierung der Ports und des Timer-Interrupts */<br />
//... <br />
// hier wird auf gKeyCounter zugegriffen. Dazu muss der in der<br />
// ISR geschriebene Wert bekannt sein:<br />
// volatile -> aktuellen Wert immer aus dem Speicher lesen<br />
if ( gKeyCounter > CNTDEBOUNCE ) { // Taste mind. 10*10 ms "prellfrei"<br />
if (gKeyCounter == CNTREPEAT) {<br />
/* hier: Code fuer "Taste lange gedrueckt" */<br />
}<br />
else {<br />
/* hier: Code fuer "Taste kurz gedrueckt" */<br />
}<br />
}<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Wird innerhalb einer ISR mehrfach auf eine mit volatile deklarierte Variable zugegriffen, wirkt sich dies ungünstig auf die Verarbeitungsgeschwindigkeit aus, da bei jedem Zugriff mit dem Speicherinhalt abgeglichen wird. Da bei AVR-Controllern ''innerhalb'' einer ISR keine Unterbrechungen zu erwarten sind, bietet es sich an, einen Zwischenspeicher in Form einer lokalen Variable zu verwenden, deren Inhalt zu Beginn und am Ende mit dem der volatile Variable synchronisiert wird. Lokale Variable werden bei eingeschalteter Optimierung mit hoher Wahrscheinlichkeit in Prozessorregistern verwaltet und der Zugriff darauf ist daher nur mit wenigen internen Operationen verbunden. Die ISR aus dem vorherigen Beispiel lässt sich so optimieren:<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter; // Uebernahme in lokale Arbeitsvariable<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (tmp_kc < CNTREPEAT) {<br />
tmp_kc++;<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc; // Zurueckschreiben<br />
}<br />
//...<br />
</syntaxhighlight><br />
<br />
Zum Vergleich die Disassemblies (Ausschnitte der "lss-Dateien", compiliert für ATmega162) im Anschluss. Man erkennt den viermaligen Zugriff auf die Speicheraddresse von ''gKeyCounter'' (hier 0x032A) in der ISR ohne "Cache"-Variable und den zweimaligen Zugriff in der Variante mit Zwischenspeicher. Im Beispiel ist der Vorteil gering, bei komplexeren Routinen kann die Zwischenspeicherung in lokalen Variablen jedoch zu deutlicheren Verbesserungen führen.<br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
876: ca 99 sbic 0x19, 2 ; 25<br />
878: 0a c0 rjmp .+20 ; 0x88e <__vector_13+0x24><br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
87a: 80 91 2a 03 lds r24, 0x032A<br />
87e: 88 3c cpi r24, 0xC8 ; 200 <br />
880: 40 f4 brcc .+16 ; 0x892 <__vector_13+0x28><br />
882: 80 91 2a 03 lds r24, 0x032A<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 02 c0 rjmp .+4 ; 0x892 <__vector_13+0x28><br />
}<br />
else {<br />
gKeyCounter = 0;<br />
88e: 10 92 2a 03 sts 0x032A, r1<br />
892: 8f 91 pop r24<br />
894: 0f 90 pop r0<br />
896: 0f be out 0x3f, r0 ; 63<br />
898: 0f 90 pop r0<br />
89a: 1f 90 pop r1<br />
89c: 18 95 reti<br />
</pre><br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter;<br />
876: 80 91 2a 03 lds r24, 0x032A<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
87a: ca 9b sbis 0x19, 2 ; 25<br />
87c: 02 c0 rjmp .+4 ; 0x882 <__vector_13+0x18><br />
87e: 80 e0 ldi r24, 0x00 ; 0<br />
880: 03 c0 rjmp .+6 ; 0x888 <__vector_13+0x1e><br />
if (tmp_kc < CNTREPEAT) {<br />
882: 88 3c cpi r24, 0xC8 ; 200<br />
884: 08 f4 brcc .+2 ; 0x888 <__vector_13+0x1e><br />
tmp_kc++;<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc;<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 8f 91 pop r24<br />
88e: 0f 90 pop r0<br />
890: 0f be out 0x3f, r0 ; 63<br />
892: 0f 90 pop r0<br />
894: 1f 90 pop r1<br />
896: 18 95 reti<br />
</pre><br />
<br />
=== volatile und Pointer ===<br />
<br />
Bei '''volatile''' in Verbindung mit Pointern ist zu beachten, ob der Pointer selbst oder die Variable, auf die der Pointer zeigt, '''volatile''' ist.<br />
<br />
<syntaxhighlight lang="c"><br />
volatile uint8_t *a; // das Ziel von a ist volatile<br />
<br />
uint8_t *volatile a; // a selbst ist volatile<br />
</syntaxhighlight><br />
<br />
Falls der Pointer volatile ist (zweiter Fall im Beispiel), ist zu beachten, dass der Wert des Pointers, also eine Speicheradresse, intern in mehr als einem Byte verwaltet wird. Lese- und Schreibzugriffe im Hauptprogramm (außerhalb von Interrupt-Routinen) sind daher so zu implementieren, dass alle Teilbytes der Adresse konsistent bleiben, vgl. dazu den folgenden Abschnitt.<br />
<br />
=== Variablen größer 1 Byte ===<br />
<br />
Bei Variablen größer ein Byte, auf die in Interrupt-Routinen und im Hauptprogramm zugegriffen wird, muss darauf geachtet werden, dass die Zugriffe auf die einzelnen Bytes außerhalb der ISR nicht durch einen Interrupt unterbrochen werden. (Allgemeinplatz: AVRs sind 8-bit Controller). Zur Veranschaulichung ein Codefragment:<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
volatile uint16_t gMyCounter16bit;<br />
//...<br />
ISR(...)<br />
{<br />
//...<br />
gMyCounter16Bit++;<br />
//...<br />
}<br />
<br />
int main(void)<br />
{<br />
uint16_t tmpCnt;<br />
//...<br />
// nicht gut: Mglw. hier ein Fehler, wenn ein Byte von MyCounter <br />
// schon in tmpCnt kopiert ist aber vor dem Kopieren des zweiten Bytes <br />
// ein Interrupt auftritt, der den Inhalt von MyCounter verändert.<br />
tmpCnt = gMyCounter16bit; <br />
<br />
<br />
// besser: Änderungen "außerhalb" verhindern -> alle "Teilbytes"<br />
// bleiben konsistent<br />
cli(); // Interrupts deaktivieren<br />
tmpCnt = gMyCounter16Bit;<br />
sei(); // wieder aktivieren<br />
<br />
// oder: vorheriger Status des globalen Interrupt-Flags bleibt erhalten<br />
uint8_t sreg_tmp;<br />
sreg_tmp = SREG; /* Sichern */<br />
cli()<br />
tmpCnt = gMyCounter16Bit;<br />
SREG = sreg_tmp; /* Wiederherstellen */<br />
<br />
// oder: mehrfach lesen, bis man konsistente Daten hat<br />
uint16_t count1 = gMyCounter16Bit;<br />
uint16_t count2 = gMyCounter16Bit;<br />
while (count1 != count2) {<br />
count1 = count2;<br />
count2 = gMyCounter16Bit;<br />
}<br />
tmpCnt = count1;<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Die avr-libc bietet ab Version 1.6.0(?) einige Hilfsfunktionen/Makros, mit der im Beispiel oben gezeigten Funktionalität, die zusätzlich auch sogenannte [http://en.wikipedia.org/wiki/Memory_barrier memory barriers] beinhalten. Diese stehen nach #include <util/atomic.h> zur Verfügung.<br />
<syntaxhighlight lang="c"><br />
//...<br />
#include <util/atomic.h><br />
//...<br />
<br />
// analog zu cli, Zugriff, sei:<br />
ATOMIC_BLOCK(ATOMIC_FORCEON) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
// oder:<br />
<br />
// analog zu Sicherung des SREG, cli, Zugriff und Zurückschreiben des SREG:<br />
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
//...<br />
</syntaxhighlight><br />
<br />
* siehe auch [http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Dokumentation der avr-libc zu atomic.h]<br />
<br />
== Interrupt-Routinen und Registerzugriffe ==<br />
<br />
Falls Register sowohl im Hauptprogramm als auch in Interrupt-Routinen verändert werden, ist darauf zu achten, dass diese Zugriffe sich nicht überlappen. Nur wenige Anweisungen lassen sich in sogenannte "atomare" Zugriffe übersetzen, die nicht von Interrupt-Routinen unterbrochen werden können. <br />
<br />
Zur Veranschaulichung eine Anweisung, bei der ein Bit und im Anschluss drei Bits in einem Register gesetzt werden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
int main(void)<br />
{<br />
//...<br />
PORTA |= (1<<PA0);<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Der Compiler übersetzt diese Anweisungen für einen ATmega128 bei Optimierungsstufe "S" nach:<br />
<br />
<div class="code"><pre><br />
...<br />
PORTA |= (1<<PA0);<br />
d2: d8 9a sbi 0x1b, 0 ; 27 (a)<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
d4: 8b b3 in r24, 0x1b ; 27 (b)<br />
d6: 8c 61 ori r24, 0x1C ; 28 (c)<br />
d8: 8b bb out 0x1b, r24 ; 27 (d)<br />
...<br />
</pre></div><br />
<br />
Das Setzen des einzelnen Bits wird bei eingeschalteter Optimierung für Register im unteren Speicherbereich in eine einzige Assembler-Anweisung (sbi) übersetzt und ist nicht anfällig für Unterbrechungen durch Interrupts. Die Anweisung zum Setzen von drei Bits wird jedoch in drei abhängige Assembler-Anweisungen übersetzt und bietet damit zwei "Angriffspunkte" für Unterbrechungen. Eine Interrupt-Routine könnte nach dem Laden des Ausgangszustands in den Zwischenspeicher (hier Register 24) den Wert des Registers ändern, z.&nbsp;B. ein Bit löschen. Damit würde der Zwischenspeicher nicht mehr mit dem tatsächlichen Zustand übereinstimmen aber dennoch nach der Bitoperation (hier ori) in das Register zurückgeschrieben. <br />
<br />
Beispiel: PORTA sei anfangs 0b00000000. Die erste Anweisung (a) setzt Bit 0 auf '''1''', PORTA ist danach 0b0000000'''1'''. Nun wird im ersten Teil der zweiten Anweisung der Portzustand in ein Register eingelesen (b). Unmittelbar darauf (vor (c)) "feuert" ein Interrupt, in dessen Interrupt-Routine Bit 0 von PORTA gelöscht wird. Nach Verlassen der Interrupt-Routine hat PORTA den Wert 0b00000000. In den beiden noch folgenden Anweisungen des Hauptprogramms wird nun der zwischengespeicherte "alte" Zustand 0b00000001 mit 0b00011100 logisch-'''ODER'''-verknüft (c) und das Ergebnis 0b00011101 in PortA geschrieben (d). Obwohl zwischenzeitlich Bit 0 gelöscht wurde, ist es nach (d) wieder gesetzt. <br />
<br />
Lösungsmöglichkeiten:<br />
* Register ohne besondere Vorkehrungen nicht in Interruptroutinen ''und'' im Hauptprogramm verändern.<br />
* Interrupts vor Veränderungen in Registern, die auch in ISRs verändert werden, deaktivieren ("cli").<br />
* Bits einzeln löschen oder setzen. sbi und cbi können nicht unterbrochen werden. Vorsicht: nur Register im unteren Speicherbereich sind mittels sbi/cbi ansprechbar. Der Compiler kann nur für diese sbi/cbi-Anweisungen generieren. Für Register außerhalb dieses Adressbereichs ("Memory-Mapped"-Register) werden auch zur Manipulation einzelner Bits abhängige Anweisungen erzeugt (lds,...,sts).<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Frequently asked Questions/Fragen Nr. 1 und 8. (Stand: avr-libc Vers. 1.0.4)<br />
<br />
== Interruptflags löschen ==<br />
<br />
Beim Löschen von Interruptflags haben AVRs eine Besonderheit, die auch im Datenblatt beschrieben ist: Es wird zum Löschen eine 1 in das betreffende Bit geschrieben. <br />
<br />
Hinweis:<br /><br />
Bei Registern mit mehreren Interrupt-Flag-Bits (wie die Timer Interrupt Flag Register) '''nicht''' die übliche bitweise VerODERung nehmen, sondern eine direkte Zuweisung machen. Da sonst weitere Flags, als nur das gewünschte, ebenfalls gelöscht werden könnten.<br /><br />
([http://www.mikrocontroller.net/topic/171148#1640133 Erklärung]).<br />
<br />
== Was macht das Hauptprogramm? ==<br />
<br />
Im einfachsten (Ausnahme-)Fall gar nichts mehr. Es ist also durchaus denkbar, ein Programm zu schreiben, welches in der main-Funktion lediglich noch die Interrupts aktiviert und dann in einer Endlosschleife verharrt. Sämtliche Funktionen werden dann in den ISRs abgearbeitet. Diese Vorgehensweise ist jedoch bei den <i>meisten</i> Anwendungen schlecht: man verschenkt eine Verarbeitungsebene und hat außerdem möglicherweise Probleme durch Interruptroutinen, die zu viel Verarbeitungszeit benötigen.<br />
<br />
Für <i>wenige</i> Anwendungen ist diese Vorgehensweise jedoch perfekt: Die Hauptschleife verkommt zu <tt>for(;;) sleep_cpu();</tt> — siehe nächster Abschnitt „Sleep“. Weiterer Vorteil: ISRs brauchen keine(!) Register retten, ein Fall für <tt>ISR(<i>name</i>,ISR_NAKED){ … reti();}</tt>. <i>So</i> können Mikrocontroller für batteriebetriebene Geräte, etwa Fernbedienungen, maximal Energie sparen.<br />
<br />
Normalerweise wird man in den Interruptroutinen nur die bei Auftreten des jeweiligen Interruptereignisses unbedingt notwendigen Operationen ausführen lassen. Alle weniger kritischen Aufgaben werden dann im Hauptprogramm abgearbeitet.<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Interrupts and Signals<br />
<br />
= Sleep-Modes =<br />
<br />
AVR Controller verfügen über eine Reihe von sogenannten [[Sleep Mode |''Sleep-Modes'']] ("Schlaf-Modi"). Diese ermöglichen es, Teile des Controllers abzuschalten. Zum Einen kann damit besonders bei Batteriebetrieb Strom gespart werden, zum Anderen können Komponenten des Controllers deaktiviert werden, die die Genauigkeit des Analog-Digital-Wandlers bzw. des Analog-Comparators negativ beeinflussen. Der Controller wird durch Interrupts aus dem Schlaf geweckt. Welche Interrupts den jeweiligen Schlafmodus beenden, ist einer Tabelle im Datenblatt des jeweiligen Controllers zu entnehmen.<br />
Die Funktionen (eigentlich Makros) der avr-libc stehen nach Einbinden der header-Datei ''sleep.h'' zur Verfügung.<br />
<br />
;set_sleep_mode (uint8_t mode): Setzt den Schlafmodus, der bei Aufruf von sleep() aktiviert wird. In sleep.h sind einige Konstanten definiert (z.&nbsp;B. SLEEP_MODE_PWR_DOWN). Die definierten Modi werden jedoch nicht alle von sämtlichten AVR-Controllern unterstützt.<br />
;sleep_enable(): Aktiviert den gesetzten Schlafmodus, versetzt den Controller aber noch nicht in den Schlafmodus<br />
;sleep_cpu(): Versetzt den Controller in den Schlafmodus .sleep_cpu wird im Prinzip durch die Assembler-Anweisung ''sleep'' ersetzt.<br />
;sleep_disable(): Deaktiviert den gesetzten Schlafmodus<br />
;sleep_mode(): Versetzt den Controller in den mit set_sleep_mode gewählten Schlafmodus. Das Makro entspricht sleep_enable()+sleep_cpu()+sleep_disable(), beinhaltet also nicht die Aktivierung von Interrupts (besser nicht benutzen).<br />
<br />
Bei Anwendung von sleep_cpu() müssen Interrupts also bereits freigeben sein (sei()), da der Controller sonst nicht mehr "aufwachen" kann. sleep_mode() ist nicht geeignet für die Verwendung in ISR Interrupt-Service-Routinen, da bei deren Abarbeitung Interrupts global deaktiviert sind und somit auch die möglichen "Aufwachinterrupts". Abhilfe: stattdessen sleep_enable(), sei(), sleep_cpu(), sleep_disable() und evtl. cli() verwenden (vgl. Dokumentation der avr-libc).<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/sleep.h><br />
<br />
int main(void)<br />
{<br />
...<br />
<br />
while (1) {<br />
...<br />
set_sleep_mode(SLEEP_MODE_PWR_DOWN);<br />
sleep_mode();<br />
<br />
// Code hier wird erst nach Auftreten eines entsprechenden<br />
// "Aufwach-Interrupts" verarbeitet<br />
...<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
In älteren Versionenen der avr-libc wurden nicht alle AVR-Controller durch die sleep-Funktionen richtig angesteuert. Mit avr-libc 1.2.0 wurde die Anzahl der unterstützten Typen jedoch deutlich erweitert. Bei nicht-unterstützten Typen erreicht man die gewünschte Funktionalität durch direkte "[[Bitmanipulation]]" der entsprechenden Register (vgl. Datenblatt) und Aufruf des Sleep-Befehls via Inline-Assembler oder sleep_cpu():<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
// Sleep-Mode "Power-Save" beim ATmega169 "manuell" aktivieren<br />
SMCR = (3<<SM0) | (1<<SE);<br />
asm volatile ("sleep"::); // alternativ sleep_cpu() aus sleep.h<br />
...<br />
</syntaxhighlight><br />
<br />
== Sleep-Modi ==<br />
Die vielen Prozessoren aus der AVR-Familie unterstützen unterschiedliche Sleep-Modi, gefächert nach Vorhandensein von Funktionsblöcken im Controller. Konkrete und verläßliche Auskunft über die tatsächlichen Gegebenheiten finden sich wie immer in den jeweiligen Datenblättern. Die Modi unterscheiden sich darin, welche Funktionsbereiche zum Energiesparen abgeschaltet werden. Davon hängt auch ab, mit welchen Mitteln der Prozessor aus der jeweiligen Schlaftiefe wieder aufgeweckt werden kann.<br />
<br />
;Idle Mode (SLEEP_MODE_IDLE): Die CPU kann durch SPI, USART, Analog Comperator, ADC, TWI, Timer, Watchdog und irgendeinen anderen Interrupt wieder aufgeweckt werden.<br />
<br />
;ADC Noise Reduction Mode (SLEEP_MODE_ADC): In diesem Modus liegt das Hauptaugenmerk darauf, die CPU soweit stillzulegen, dass der ADC möglichst keine Störungen aus dem inneren der CPU auffangen kann, die das Meßergebnis negativ beeinflussen können. Das Aufwachen aus diesem Modus kann ausgelöst werden durch den ADC, externe Interrupts, TWI, Timer und Watchdog.<br />
<br />
;Power-Down Mode (SLEEP_MODE_PWR_DOWN): In diesem Modus wird ein externer Oszillator (Quarz, Quarzoszillator), wenn vorhanden. gestoppt. Geweckt werden kann die CPU durch einen externen Level-Interrupt, TWI, Watchdog, Brown-Out-Reset.<br />
<br />
;Power-Save-Mode (SLEEP_MODE_PWR_SAVE): Power-Save ist identisch zu Power-Down mit einer Ausnahme: Ist der Timer 2 auf die Verwendung eines externen Taktes konfiguriert, so läuft dieser Timer auch im Power-Save weiter und kann die CPU mit einem Interrupt aufwecken.<br />
<br />
;Standby-Mode (SLEEP_MODE_STANDBY, SLEEP_MODE_EXT_STANDBY): Voraussetzung für den Standby-Modus ist die Verwendung eines Quarzes oder eines Quarzoszillators, also einer externen Taktquelle. Ansonsten ist dieser Modus identisch zum Power-Down Modus. Vorteil dieses Modus' ist eine kürzere Aufwachzeit.<br />
<br />
;Abschalten des Brownout Detect (BOD) während der Sleep-Phase (nur P-Typen): Zur Stromersparnis bieten die P-Typen die Möglichkeit den BOD während der Sleep-Phase abzuschalten. Bei einem Atmega88PA beispielsweise, kann dadurch der Stromverbrauch im SLEEP_MODE_PWR_SAVE mit Timer2 im Asynchronmodus mit Uhrenquarz und periodischer Selbstaufweckung um ca. 50% gesenkt werden.<br />
Das Einschalten dieser Funktion geschieht in einer Timed Sequence.<br />
<br />
<syntaxhighlight lang="c"><br />
unsigned char temp0 = MCUCR;<br />
unsigned char temp1 = MCUCR;<br />
temp0 |= (1 << BODS) | (1 << BODSE);<br />
temp1 |= (1 << BODS);<br />
MCUCR = temp0;<br />
MCUCR = temp1;<br />
sleep_cpu();<br />
</syntaxhighlight><br />
<br />
Hierbei ist unbedingt zu beachten, dass das BODS-Bit 3 Takte nach dem Setzen wieder gelöscht wird. Daher muss der Aufruf des Sleep unmittelbar nach dem Setzen erfolgen und das BODS-Bit muss jedes Mal vor einem Sleep Aufruf erneut gesetzt werden.<br />
<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Power Management and Sleep-Modes<br />
* [http://www.mikrocontroller.net/topic/96369#832712 Forenbeitrag] zur "Nichtverwendung" von sleep_mode in ISRs.<br />
<br />
= Zeiger =<br />
Zeiger (engl. ''Pointer'') sind Variablen, die die Adresse von Daten oder Funktionen enthalten und belegen 16 Bits. Die Größe hängt mit dem adressierbaren Speicherbereich zusammen und der GCC reserviert dann den entsprechenden Platz.<br />
Ggf. ist es also günstiger, Indizes auf Arrays (Listen) zu verwenden, so dass der GCC für die Zeigerarithmetik den erforderlichen RAM nur temporär benötigt.<br />
<br />
Siehe auch: [[Zeiger]]<br />
<br />
= Speicherzugriffe =<br />
<br />
Atmel AVR-Controller verfügen typisch über drei Speicher:<br />
<br />
* [[RAM]]: Im RAM (genauer statisches RAM/SRAM) wird vom gcc-Compiler Platz für Variablen reserviert. Auch der Stack befindet sich im RAM. Dieser Speicher ist "flüchtig", d.h. der Inhalt der Variablen geht beim Ausschalten oder einem Zusammenbruch der Spannungsversorgung verloren. Das bedeutet im Umkehrschluss auch, dass der RAM-Inhalt nach RESET vom Pin oder vom Watchdog erhalten bleibt! Der C-Startupcode löscht jedoch den RAM, d.h. setzt alle Bits auf 0. Dadurch erscheinen „normal definierte“ Variablen als 0. Auch Gleitkommazahlen, die schlauerweise so definiert sind, dass eine +0.0 aus lauter Nullbits besteht. Von der Löschung ausschließen kann man RAM-Variablen mit <tt>__attribute__((section(".noinit")))</tt>.<br />
<br />
* Programmspeicher: Ausgeführt als FLASH-Speicher, seitenweise wiederbeschreibbar. Darin ist das Anwendungsprogramm abgelegt.<br />
<br />
* [[EEPROM]]: Nichtflüchtiger Speicher, d.h. der einmal geschriebene Inhalt bleibt auch ohne Stromversorgung erhalten. Byte-weise schreib/lesbar. Im EEPROM werden typischerweise gerätespezifische Werte wie z.&nbsp;B. Kalibrierungswerte von Sensoren abgelegt.<br />
<br />
Einige AVRs besitzen keinen RAM-Speicher, lediglich die Register können als "Arbeitsvariablen"<br />
genutzt werden. Da die Anwendung des avr-gcc auf solch "kleinen" Controllern ohnehin selten sinnvoll ist und auch nur bei einigen RAM-losen Typen nach [http://lightner.net/avr/ATtinyAvrGcc.html "Bastelarbeiten"] möglich ist, werden diese Controller hier nicht weiter berücksichtigt. Auch EEPROM-Speicher ist nicht auf allen Typen verfügbar. Generell sollten die nachfolgenden Erläuterungen auf alle ATmega-Controller und die größeren AT90-Typen übertragbar sein. Für die Typen ATtiny2313, ATtiny26 und viele weitere der "ATtiny-Reihe" gelten die Ausführungen ebenfalls.<br />
<br />
Siehe auch:<br />
* [[Binäre Daten zum Programm hinzufügen]]<br />
== RAM ==<br />
<br />
Die Verwaltung des RAM-Speichers erfolgt durch den Compiler, im Regelfall ist beim Zugriff auf Variablen im RAM nichts Besonderes zu beachten. Die Erläuterungen in jedem brauchbaren C-Buch gelten auch für den vom avr-gcc-Compiler erzeugten Code.<br />
<br />
Um Speicher dynamisch (während der Laufzeit) zu reservieren, kann '''malloc()''' verwendet werden. malloc(size) "alloziert" (~reserviert) einen gewissen Speicherblock mit '''size''' Bytes. Ist kein Platz für den neuen Block, wird NULL (0) zurückgegeben.<br />
<br />
Wird der angelegte Block zu klein (groß), kann die Größe mit realloc() verändert werden. Den allozierten Speicherbereich kann man mit free() wieder freigeben. Wenn das Freigeben eines Blocks vergessen wird spricht man von einem "Speicherleck" (memory leak).<br />
<br />
malloc() legt Speicherblöcke im '''Heap''' an, belegt man zuviel Platz, dann wächst der Heap zu weit nach oben und überschreibt den Stack, und der Controller kommt in Teufels Küche. Das kann leider nicht nur passieren wenn man insgesamt zu viel Speicher anfordert, sondern auch wenn man Blöcke unterschiedlicher Größe in ungünstiger Reihenfolge alloziert/freigibt (siehe Artikel [[Heap-Fragmentierung]]). Aus diesem Grund sollte man malloc() auf Mikrocontrollern sehr sparsam (am besten gar nicht) verwenden.<br />
<br />
Beispiel zur Verwendung von malloc():<br />
<syntaxhighlight lang="c"><br />
#include <stdlib.h><br />
<br />
void foo(void) {<br />
// neuen speicherbereich anlegen,<br />
// platz für 10 uint16<br />
uint16_t* pBuffer = malloc(10 * sizeof(uint16_t));<br />
<br />
// darauf zugreifen, als wärs ein gewohnter Buffer<br />
pBuffer[2] = 5;<br />
<br />
// Speicher (unbedingt!) wieder freigeben<br />
free(pBuffer);<br />
}<br />
</syntaxhighlight><br />
<br />
Wenn (wie in obigem Beispiel) dynamischer Speicher nur für die Dauer einer Funktion benötigt und am Ende wieder freigegeben wird, bietet es sich an, statt malloc() '''alloca()''' zu verwenden. Der Unterschied zu malloc() ist, dass der Speicher auf dem Stack reserviert wird, und beim Verlassen der Funktion automatisch wieder freigegeben wird. Es kann somit kein Speicherleck und keine Fragmentierung entstehen.<br />
<br />
siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/malloc.html AVR Libc Home Page]: Memory Areas and Using malloc()<br />
* [https://www.mikrocontroller.net/topic/479027#5934443 Forumsbeitrag]: RAM Verbrauch auch von lokalen variablen ermitteln<br />
<br />
== Flash mit PROGMEM und pgm_read ==<br />
<br />
→ [http://nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html avr-libc: Doku zu avr/pgmspace.h]<br />
<br />
Ein Zugriff auf Konstanten im Programmspeicher ist mittels avr-gcc erst ab Version 4.7 "transparent" möglich. Um Daten aus dem Flash zu lesen, muss die AVR-Instruktion LPM (''Load from Program Memory'') erzeugt werden, bei Controllern mit mehr als 64kiB Flash auch ELPM.<br />
<br />
Dazu gibt es das AVR-spezifische GCC-Attribut <tt>progmem</tt>, mit dem eine Variablendeklaration im ''static storage''<ref>Variablen der Speicherklasse ''static storage'' haben eine unbegrenzte Lebensdauer. Beispiel für solche Variablen sind globale Variablen, aber auch static-Variablen innerhalb einer Funktion gehören dazu. Beispiele für Variablen, die nicht ''static storage'' sind: auto-Variablen ("normale" lokale Variablen), register-Variablen, durch malloc geschaffene Objekte, etc.</ref> markiert werden kann:<br />
<syntaxhighlight lang="c"><br />
const int value __attribute__((progmem)) = 1;<br />
</syntaxhighlight><br />
<br />
Effekt ist, dass die so markierte Variable nicht im RAM sondern im Flash angelegt wird. Wird durch "normalen" C-Code auf solch eine Variable zugegriffen, wird jedoch aus der gleichen Adresse aus dem RAM gelesen und nicht aus dem Flash! Das ist ein Fehler, den der Compiler aber nicht anzeigt!<br />
<br />
<syntaxhighlight lang="c"><br />
int test = value; // Fehler! PROGMEM Konstanten müssen mit den pgm_read-Funktionen gelesen werden!<br />
</syntaxhighlight><br />
<br />
Zum Lesen aus dem Flash stellt die avr-libc daher zahlreiche Makros zur Verfügung. Zudem wird das Makro <tt>PROGMEM</tt> definiert, das etwas Tipparbeit spart:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
const int value PROGMEM = 1;<br />
</syntaxhighlight><br />
<br />
<tt>progmem</tt> funktioniert im Wesentlichen wie ein Section-Attribut, das die Daten in der Section <tt>.progmem.data</tt> ablegt. Im Gegensatz zum Section-Attribut werden jedoch noch weitere Prüfungen unternommen, ab avr-gcc 4.6 etwa muss die entsprechende Variable <tt>const</tt> sein.<br />
<br />
=== Integer und float ===<br />
<br />
Zum Lesen von Skalaren stellt die avr-libc folgende Makros zu Verfügung, die jeweils ein Argument erhalten: Die 16-Bit Adresse des zu lesenden Wertes<ref>Damit ist der mögliche Speicherbereich für Flash-Konstanten auf 64kiB begrenzt. Einige pgmspace-Funktionen ermöglichen den Lesezugriff auf den gesamten Flash-Speicher, intern via Assembler-Anweisung ELPM. Die Initialisierungswerte des Speicherinhalts jenseits der 64kiB-Marke müssen dann jedoch auf anderem Weg angelegt werden, d.h. nicht per PROGMEM. Evtl. eigene Section und Linker-Optionen. Alt und nicht ganz korrekt: Die avr-libc pgmspace-Funktionen unterstützen nur die unteren 64kiB Flash bei Controllern mit mehr als 64kiB.</ref><br />
<br />
:{| {{Tabelle}}<br />
|+ Übersicht der <tt>pgm_read</tt> Funktionen aus<br/>dem Header <tt>avr/pgmspace.h</tt> der avr-libc<br />
|-<br />
! Gelesener Wert || <tt>pgm_read_xxx</tt> || Anzahl Bytes<br />
|-<br />
| <tt>uint8_t</tt> || <tt>pgm_read_byte</tt> || 1<br />
|-<br />
| <tt>uint16_t</tt> || <tt>pgm_read_word</tt> || 2<br />
|-<br />
| <tt>uint32_t</tt> || <tt>pgm_read_dword</tt> || 4<br />
|-<br />
| <tt>float</tt> || <tt>pgm_read_float</tt><ref>ab avr-libc 1.7.0</ref> || 4<br />
|}<br />
<br />
Soll ein Zeiger gelesen werden, so verwendet man <tt>pgm_read_word</tt> und castet das Ergebnis zum gewünschten Zeiger-Typ.<br />
<br />
;Beispiele:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
/* Byte */<br />
const uint8_t aByte PROGMEM = 123;<br />
<br />
/* int-Array */<br />
const int anArray[] PROGMEM = { 18, 3 ,70 };<br />
<br />
void foo (void)<br />
{<br />
/* Zeiger */<br />
static const uint8_t* const aPointer PROGMEM = &aByte;<br />
<br />
uint8_t a = pgm_read_byte (&aByte);<br />
int a2 = (int) pgm_read_word (&anArray[2]);<br />
const uint8_t* p = (const uint8_t*) pgm_read_word (&aPointer);<br />
}<br />
</syntaxhighlight><br />
<br />
=== Blöcke ===<br />
<br />
In den Flash-Funktionen der avr-libc sind keine der pgm_read_xxxx Nomenklatur folgenden Funktionen, die Speicherblöcke auslesen oder vergleichen. Die enstprechende Funktionen sind Varianten von <tt>memcpy</tt>, <tt>memcmp</tt> und heißt <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, usw. Für weitere Funktionen und deren Prototypen siehe die Dokumentation der avr-libc.<br />
<br />
=== Strings ===<br />
<br />
Strings sind in C nichts anderes als eine Abfolge von Zeichen und einem <tt>'\0'</tt> als Stringende. Der prinzipielle Weg ist daher identisch zum Lesen von Bytes, wobei auf die [[FAQ#Wie funktioniert String-Verarbeitung in C?|Besonderheiten von Strings]] wie 0-Terminierung geachtet werden muss.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
size_t my_string_length (const char *addr)<br />
{<br />
size_t length = 0;<br />
<br />
while (pgm_read_byte (addr++))<br />
{<br />
length++;<br />
}<br />
return length;<br />
}<br />
</syntaxhighlight><br />
<br />
Zur Unterstützung des Programmierers steht das Repertoire der str-Funktionen auch in jeweils eine Variante zur Verfügung, die mit dem Flash-Speicher arbeiten kann. Die Funktionsnamen tragen den Suffix <tt>_P</tt>. Darüber hinaus gibt es das Makro <tt>PSTR</tt>, das ein String-Literal im Flash-Speicher ablegt und die Adresse des Strings liefert:<br />
<br />
Die nachfolgende Funktion liefert 0 zurück, wenn string_im_ram gleich "Hallo Welt" ist. Mit strcmp (String Compare) können wir zwei Strings vergleichen. Der Rückgabewert kann hierbei folgende Werte haben:<br><br />
0 die Strings sind gleich<br />
>0 das erste ungleiche Zeichen in string_im_ram ist größer als in "Hallo Welt"<br />
<0 das erste ungleiche Zeichen in string_im_ram ist kleiner als in "Hallo Welt"<br />
<br><br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
int foo (const char *string_im_ram)<br />
{<br />
return strcmp_P (string_im_ram, PSTR ("Hallo Welt"));<br />
}<br />
</syntaxhighlight><br />
<br />
Zu beachten ist, dass <tt>PSTR</tt> nur innerhalb von Funktionen verwendet werden kann.<br />
<br />
; Array aus Strings:<br />
<br />
Arrays aus Strings im Flash-Speicher werden in zwei Schritten angelegt:<br />
<br />
# Zuerst die einzelnen Elemente des Arrays und<br />
# im Anschluss ein Array, in dem die Startaddressen der Strings abgelegt werden.<br />
<br />
Zum Auslesen wird zuerst die Adresse des gewünschten Elements aus dem Array im Flash-Speicher gelesen, die im Anschluss dazu genutzt wird, um auf das Element (den String) selbst zuzugreifen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
static const char str1[] PROGMEM = "Hund";<br />
static const char str2[] PROGMEM = "Katze";<br />
static const char str3[] PROGMEM = "Maus";<br />
<br />
const char * const array[] PROGMEM = <br />
{<br />
str1, str2, str3<br />
};<br />
<br />
// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]<br />
void read_string (char *buf, size_t i)<br />
{<br />
// Lese die Adresse des i-ten Strings aus array[]<br />
const char *parray = (const char*) pgm_read_ptr (&array[i]);<br />
<br />
// Kopiere den Inhalt der Zeichenkette vom Flash ins RAM<br />
strcpy_P (buf, parray);<br />
}<br />
</syntaxhighlight><br />
<br />
Eine weitere Möglichkeit ist, die Strings in einem 2-dimensionalen char-Array abzulegen anstatt deren Adresse in einem 1-dimensionalen Adress-Array zu speichern.<br />
<br />
Vorteil ist, dass der Code einfacher wird. Nachteil ist, dass bei unterschiedlich langen Strings Speicherplatz verschwendet wird, weil sich die Array-Dimension and der Länge des längsten Strings orientieret. Bei in etwa gleich langen Strings kann es aber sogar Speicherplatz sparen, denn es die Adressen der einzelnen Strings müssen nicht abgespeichert werden.<ref>In unserem Hund-Katze-Maus Beispiel belegt die erste Variante 22 Bytes Daten und 18 Bytes Code, die zweite Variante mit 2-dimensionalem Array belegt 18 Bytes Daten und 20 Bytes Code. Gemessen wurde mit avr-gcc 4.8 -Os für ATmega8.</ref><br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
// Die "6" ist 1 plus die Länge des längsten Strings ("Katze")<br />
const char array[][6] PROGMEM = <br />
{<br />
"Hund", "Katze", "Maus"<br />
};<br />
<br />
// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]<br />
void read_string (char *buf, size_t i)<br />
{<br />
// Kopiere den Inhalt der i-ten Zeichenkette vom Flash ins RAM<br />
strcpy_P (buf, array[i]);<br />
}<br />
</syntaxhighlight><br />
<br />
Siehe dazu auch die avr-libc FAQ: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_rom_array How do I put an array of strings completely in ROM?]<br />
<br />
=== Warum so kompliziert? ===<br />
<br />
Zu dem Thema, warum die Verabeitung von Werten aus dem Flash-Speicher so kompliziert ist, sei hier nur kurz erläutert: Die Harvard-Architektur des AVR weist getrennte Adressräume für Programm (Flash) und Datenspeicher (RAM) auf. Der C-Standard sieht keine unterschiedlichen Adressräume vor.<br />
<br />
Hat man zum Beispiel eine Funktion string_an_uart (const char* s) und übergibt an diese Funktion die Adresse einer Zeichenkette, dann weiß die Funktion nicht, ob die Adresse in den Flash-Speicher oder das RAM zeigt. Weder aus dem Pointer-Wert, also dem Zahlenwert, noch aus dem "const" kann auf den Ort der Ablage geschlossen werden.<br />
<br />
Einige AVR-Compiler bilden die Harvard-Architektur ab, indem sie in einen Pointer nicht nur die Adresse speichern, sondern auch den Ablageort wie ''Flash'' oder ''RAM''. In einem Aufruf einer Funktion wird dann bei Pointer-Parametern neben der Adresse auch der Speicherbereich, auf den der Pointer zeigt, übergeben.<br />
<br />
Dies hat jedoch auch Nachteile, denn bei jedem Zugriff über einen Zeiger muss zur ''Laufzeit'' entschieden werden, wie der Zugriff auszuführen ist und entsprechend länglicher und langsamer wird der erzeugte Code.<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitte Modules/Program Space String Utilities und Abschnitt Modules/Bootloader Support Utilities<br />
<br />
=== Datenzugriff jenseits 64 KiB ===<br />
<br />
Die Zeiger beim <tt>avr-gcc</tt> sind stets 16 Bit breit, können somit also nur 64 KiB Datenspeicher adressieren. Darauf sind auch alle Funktion der libc ausgelegt, welche auf _P enden. Funktionszeiger können beim AVR bis zu 128 KiB Programmspeicher adressieren, weil Funktionsadressen immer 16-Bit-<u>Worte</u> adressieren und nicht Bytes. Der Zugriff auf den RAM ist mit maximal 16 KiB (extern maximal 64 KiB) durch 16-Bit-Zeiger nicht begrenzt.<br />
<br />
Schlauerweise sortiert <tt>avr-gcc</tt> Flash-Konstanten und -Tabellen <i>so</i> um, dass sie an den Anfang des Flash-Speichers, gleich nach der Interrupt-Tabelle, zu liegen kommen. Somit kommt man auch auf Controllern mit mehr als 64 KByte Flash im Normalfall keine Adresse jenseits 64 KiByte erforderlich.<br />
<br />
<small>Auf Controllern mit mehr als 128 KiB Flash bekommen alle Funktionen <i>jenseits</i> 128 KiB ein <b>Trampolin</b> (Sprungbefehl aus 4 Byte) im dem Adressbereich <i>vor</i> 128 KiB. Damit genügt für alle Funktionszeiger 16 Bit. Wird kein Zeiger benötigt, kann der Optimierer das jeweilige Trampolin entfernen.</small><br />
<br />
Um (dennoch) Zugriff jenseits von 64 KiB zu bewerkstelligen gibt es mehrere Möglichkeiten:<br />
<br />
* Address-Spaces wie <tt>__flash1</tt> oder <tt>__memx</tt>, siehe Abschnitt "[[#Jenseits von flash|Jenseits von __flash]]".<br />
* Die Funktionen bzw. Makros <tt>pgm_read_xxx_far</tt> der AVR-Libc ab Version 1.8.0, wie im folgenden beschrieben. Dafür gibt es die Funktion pgm_get_far_address(), um 32-Bit Pointer eines Objekts zu erhalten<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/pgmspace.h><br />
<br />
//===================================================================<br />
// Define an additional section, which will be placed after all others<br />
//--------------------------------------------------------------------<br />
#define FAR_SECTION __attribute__((__section__(".far_section")))<br />
//--------------------------------------------------------------------<br />
<br />
//====================================================================<br />
// Just an example<br />
//====================================================================<br />
<br />
const char MyString[] FAR_SECTION = "Hier liegt mein FAR-Teststring!";<br />
const char MyBmp64[] FAR_SECTION = {0xAA,0xBB,0xCC,0xDD,0xEE,0xFF,0x00};<br />
<br />
int main(void) {<br />
uint32_t ptr = pgm_get_far_address(MyString);<br />
char MyChar;<br />
DDRC = 0xFF;<br />
do {<br />
MyChar = pgm_read_byte_far(ptr++);<br />
PORTC = MyChar;<br />
} while(MyChar);<br />
}<br />
</syntaxhighlight><br />
<br />
D.h. man muss<br />
* Die Definition der neuen Section <tt>FAR_SECTION</tt> einfügen<br />
* Die konstanten Daten mit dieser Section kennzeichnen<br />
<br />
Dem Linker muss man über diese Section nichts mitteilen, er fügt diese automatisch nach allen bestehenden sections im Flash ein. Der Zugriff auf diese Variablen kann nur mittels direkter Pointerarithmetik erfolgen, eine Indizierung von Arrays mit variablem Index ist nicht möglich. Dabei muss die Größe des Datentyps immer manuell berücksichtigt werden, denn der Pointer ist immer ein Bytepointer!<br />
<br />
<syntaxhighlight lang="c"><br />
int n=3;<br />
MyChar = pgm_read_byte_far(pgm_get_far_address(MyBmp64)+n*sizeof(char));<br />
</syntaxhighlight><br />
<br />
Dabei gibt es einige praktische Probleme.<br />
* Beim recht alten AVR-Studio 4.18 wird die Größe des belegten FLASH-Speichers nicht korrekt angezeigt, die Daten landen aber im HEX-File.<br />
* beim moderneren Atmelstudio 6.2 sieht man in der Consolenausgabe die richtige Größe, welche von avr-size ermittelt wurde, diese wird aber dann in der 2. Ausgabe durch Atmelstudio falsch dargestellt<br />
* Die Arduino-IDE rechnet richtig, siehe dieser [https://www.mikrocontroller.net/topic/511511?goto=6568945#6568945 Forumsbeitrag].<br />
<br />
== Flash mit __flash und Embedded-C ==<br />
<br />
Ab Version 4.7 unterstützt avr-gcc ''Adress-Spaces'' gemäß dem Embedded-C Dokument ISO/IEC TR18037. Der geläufigste Adress-Space ist <tt>__flash</tt>, der im Gegensatz zu <tt>progmem</tt> kein GCC-Attribut ist, sondern ein Qualifier und damit syntaktisch ähnlich verwendet wird wie <tt>const</tt> oder <tt>volatile</tt>.<br />
<br />
GCC kennt keine eigene Option zum Aktivieren von Embedded-C, es wird als GNU-C Erweiterung behandelt. Daher müssen C-Module, die Address-Spaces verwenden, mit <tt>-std=gnu99</tt> o.ä. compiliert werden.<br />
<br />
<syntaxhighlight lang="c"><br />
static const __flash int value = 10;<br />
<br />
int get_value (void)<br />
{<br />
return value;<br />
}<br />
</syntaxhighlight><br />
<br />
# Im Gegensatz zu <tt>progmem</tt> sind keine speziellen Bibliotheksfunktionen oder -makros für den Zugriff mehr notwendig: Der Code zum Lesen der Variable ist "normales" C.<br />
# Die Variable wird im richtigen Speicherbereich (Flash) angelegt.<br />
# <tt>__flash</tt> ist nur zusammen mit read-only Objekten oder Zeigern, d.h. nur zusammen mit <tt>const</tt>, erlaubt.<br />
# Zugriffe wie im obigen Beispiel können (weg)optimiert werden. Das Beispiel entspricht einem "<tt>return 10</tt>". Es besteht keine Notwendigkeit, für <tt>value</tt> überhaupt Flash-Speicher zu reservieren.<br />
<br />
Auch Zeiger-Indirektionen sind problemlos möglich. Zu beachten ist, dass <tt>__flash</tt> auf der richtigen Seite des "<tt>*</tt>" in der Zeigerdeklaration bzw. -definition steht:<br />
* '''Rechts vom <tt>*</tt>:''' Der Zeiger selbst liegt im Flash<br />
* '''Links vom <tt>*</tt>:''' Der Zeiger enthält eine Flash-Adresse<br />
<br />
<syntaxhighlight lang="c"><br />
// val ist eine Variable im Flash<br />
const __flash int val = 42;<br />
<br />
// pval liegt auch im Flash und enthält die Adresse von val<br />
const __flash int* const __flash pval = &val;<br />
<br />
int get_val (void)<br />
{<br />
// liest den Wert von val über die in pval abgelegte Adresse<br />
return *pval;<br />
}<br />
</syntaxhighlight><br />
<br />
=== Blöcke ===<br />
<br />
Um Speicherbereiche vom Flash in den RAM zu kopieren, gibt es zwei Möglichkeiten: Zum einen können wie bei <tt>progmem</tt> beschreiben die Funktionen der avr-libc wie <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, <tt>movmem_P</tt>, etc. verwendet werden:<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
// Eine Datenstruktur<br />
typedef struct<br />
{<br />
int id;<br />
char buf[10];<br />
} data_t;<br />
<br />
extern void uart_send (const void*, size_t);<br />
<br />
void send_data (const __flash data_t *pdata)<br />
{<br />
// buf wird auf dem Stack angelegt<br />
data_t buf;<br />
<br />
// Kopiere Daten vom Flash nach buf ins RAM<br />
memcpy_P (&buf, pdata, sizeof (data_t));<br />
<br />
// Sende die Daten in buf<br />
uart_send (&buf, sizeof (data_t));<br />
}<br />
</syntaxhighlight><br />
<br />
Zum anderen kann eine Struktur auch über direktes Kopieren ins RAM geladen werden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdlib.h><br />
<br />
// Eine Datenstruktur<br />
typedef struct<br />
{<br />
int id;<br />
char buf[10];<br />
} data_t;<br />
<br />
extern void uart_send (const void*, size_t);<br />
<br />
void send_data (const __flash data_t *pdata)<br />
{<br />
// Kopiere Daten ins RAM. buf wird auf dem Stack angelegt<br />
const data_t buf = *pdata;<br />
<br />
// Verwendet die Daten in buf<br />
uart_send (&buf, sizeof (data_t));<br />
}<br />
</syntaxhighlight><br />
<br />
=== Strings ===<br />
<br />
Natürlich können auch Strings im Flash abgelegt werden und auch mit Funktionen wie <tt>strcpy_P</tt> aus der avr-libc verarbeitet werden. Zudem ist es möglich, Flash-Zeiger mit der Adresse eines String-Literals zu initialisieren:<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
#define FSTR(X) ((const __flash char[]) { X } )<br />
<br />
const __flash char * const __flash array[] = <br />
{<br />
FSTR ("Hund"), FSTR ("Katze"), FSTR ("Maus")<br />
};<br />
<br />
size_t get_len (uint8_t tier)<br />
{<br />
return strlen_P (array[tier]);<br />
}<br />
</syntaxhighlight><br />
<br />
Leider sieht der Embedded-C Draft nicht vor, String-Literale direkt in einem anderen Adress-Space als ''generic'' anzulegen, so dass hier der Umweg über <tt>FSTR</tt> genommen werden muss. Dieses Konstrukt ist nur ausserhalb von Funktionen möglich und kann daher nicht als Ersatz für <tt>PSTR</tt> aus der avr-libc dienen.<br />
<br />
Soll <tt>array</tt> ein 2-dimensonales Array sein anstatt ein 1-dimensionales Array von Zeigern, dann geht das ohne große Verrenkungen:<br />
<br />
<syntaxhighlight lang="c"><br />
// Die 6 ergibt sich aus 1 plus der Länge des längsten Strings "Katze"<br />
const __flash char array[][6] = <br />
{<br />
"Hund", "Katze", "Maus"<br />
};<br />
</syntaxhighlight><br />
<br />
Weiters besteht die Möglichkeit, <tt>array</tt> analog anzulegen, wie man es mit <tt>PROGMEM</tt> machen würde: Jeder String wird explizit angelegt und seine Adresse bei der Initialisierung von <tt>array</tt> verwendet. Dies entspricht dem ersten Beispiel eines 1-dimensionalen Zeigerarrays:<br />
<br />
<syntaxhighlight lang="c"><br />
static const __flash char strHund[] = "Hund";<br />
static const __flash char strKatze[] = "Katze";<br />
static const __flash char strMaus[] = "Maus";<br />
<br />
const __flash char * const __flash array[] = <br />
{<br />
strHund, strKatze, strMaus<br />
};<br />
</syntaxhighlight><br />
<br />
=== Casts ===<br />
<br />
Embedded C fordert, dass zwei Adress-Spaces entweder disjunkt sind – d.h. sie enthalten keine gemeinsamen Adressen – oder aber ein Space komplett im anderen enthalten ist, also eine Teilmengen-Beziehung besteht. Die Adress-Spaces von avr-gcc sind so implementiert, dass jeder Space Teilmenge jedes anderes ist. Zwar haben Spaces wie RAM und Flash physikalisch keinen Speicherbereich gemein, allerdings ermöglicht diese Implementierung das Casten von Zeigern zu unterschiedlichen Adress-Spaces<ref>Im Gegensatz zu einem Attribute wie <tt>progmem</tt> ist ein (Adress Space) Qualifier Teil des Zeiger-Typs.</ref>: <br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdbool.h><br />
<br />
char read_char (const char *address, bool data_in_flash)<br />
{<br />
if (data_in_flash)<br />
return *(const __flash char*) address;<br />
else<br />
return *address;<br />
}<br />
</syntaxhighlight><br />
<br />
Der Cast selbst erzeugt keinen zusätzlichen Code, da eine RAM-Adresse und eine Flash-Adresse die gleiche Binärdarstellung haben. Allerdings wird über den nach <tt>__flash</tt> gecasteten Zeiger anders zugegriffen, nämlich per LPM.<br />
<br />
=== Jenseits von __flash ===<br />
<br />
Ausser <tt>__flash</tt> gibt es auch folgende Address-Spaces:<br />
<br />
==== <tt>__flash</tt>''N'' ====<br />
<br />
<tt>__flash</tt>''N'' mit ''N'' = 1..5 sind fünf weitere Spaces, die analog zu <tt>__flash</tt> funktionieren und deren Zeiger ebenfalls 16 Bit breit sind. avr-gcc erwartet, dass die zugehörigen Daten, welche in die Section <tt>.progmem</tt>''N''<tt>.data</tt> abgelegt werden, so lokatiert sind, dass das high-Byte der Adresse (Bits 16..23) gerade ''N'' ist.<br />
<br />
Weil Daten- und Code-Layout höchst projektspezifisch sind, werden diese Sections im Standard Linker-Skript nicht beschrieben. Um funktionsfähigen Code zu erhalten, muss daher ein eigenes Linker-Skript zur Verfügung gestellt werden, das diese Sections beschreibt, oder es kann eine Erweiterung des Standard Skripts bereitgestellt werden falls dies möglich ist.<br />
<br />
;Beispiel: Eine Applikation, die <tt>__flash2</tt> verwendet. Die zugehörende Section <tt>.progmem2.data</tt> wird hinter <tt>.text</tt> angeordnet aber vor den Initializern für <tt>.data</tt>. Dazu wird beim Linken das ld-Skript Fragment per <tt>-Tflash12.ld</tt> angegeben, welches dann an der gewünschten Stelle in das default Skript eingefügt wird:<br />
:{| <!-- Tabelle bitte für korrekte Einrückung belassen --><br />
|-<br />
|<pre><br />
SECTIONS<br />
{<br />
.flash2 :<br />
{<br />
. = MAX (ABSOLUTE(0x20000), .);<br />
PROVIDE (__flash2_start = .);<br />
. = ALIGN(2);<br />
*(.flash2.text*)<br />
*(.progmem2.data*)<br />
PROVIDE (__flash2_end = .);<br />
<br />
ASSERT (__flash2_start == __flash2_end || __flash2_start >= ABSOLUTE(0x20000),<br />
"__flash2 data in .progmem2.data below 0x20000");<br />
ASSERT (__flash2_start == __flash2_end || __flash2_end <= ABSOLUTE(0x30000),<br />
"__flash2 data in .progmem2.data exceeds 0x30000");<br />
}<br />
}<br />
INSERT AFTER .text<br />
</pre><br />
|}<br />
<br />
==== <tt>__memx</tt> ====<br />
<br />
Dieser Address-Space implementiert 3-Byte Zeiger und unterstützt Lesen über 64KiB-Segmentgrenzen hinweg. Das MSB (Bit 23) gibt dabei an, ob der <tt>__memx</tt>-Zeiger eine Flash-Adresse enthält (Bit23 = 0) oder eine RAM-Adresse (Bit23 = 1), was folgenden Code erlaubt:<br />
<br />
<syntaxhighlight lang="c"><br />
const __memx int a_flash = 42;<br />
const int a_ram = 100;<br />
<br />
int get_a (const __memx int* pa)<br />
{<br />
return *pa;<br />
}<br />
<br />
int main (void)<br />
{<br />
return get_a (&a_flash) + get_a (&a_ram);<br />
}</syntaxhighlight><br />
<br />
Dies bedeutet, dass erst zur ''Laufzeit'' entschieden werden kann, ob <tt>get_a</tt> die Daten aus dem RAM oder aus dem Flash lesen soll, was <tt>__memx</tt> im Vergleich zu den anderen Address-Spaces langsamer macht. Ausserdem ist zu beachten, dass <tt>__memx</tt>-Zeiger zwar 24-Bit Zeiger sind, die zugrundeliegende Adress-Arithmetik jedoch gemäß dem C-Standard erfolgt, also als 16-Bit Arithmetik. Bestehende Funktion der avr-libc wie z.B. printf_P funktionieren damit ebensowenig wie printf! Wenn man <tt>__memx</tt> verwenden will, braucht man dafür eigene Funktionen.<br />
<br />
=== __flash, progmem und Portierbarkeit ===<br />
<br />
Da ab er aktuellen Compilerversion 4.7 sowohl <tt>__flash</tt> als auch <tt>PROGMEM</tt> und die <tt>pgm_read</tt>-Funktionen zur Verfügung stehen, ergibt sich die Frage, welche Variante "besser" ist und wie zwischen ihnen hin- und her zu portieren ist.<br />
<br />
Zunächst sei erwähnt, dass <tt>__flash</tt> kein Ersatz für <tt>PROGMEM</tt> ist, sondern lediglich eine Alternative dazu. Das "alte" progmem wird weiterhin mir gleicher Semantik unterstützt, so dass alter Code ohne Änderungen mit den neueren Compilerversionen übersetzbar bleibt.<br />
<br />
Von der Codegüte her dürften sich keine großen Unterschiede ergeben. Es ist nicht zu erwarten, dass die eine oder die andere Variante wesentlich besseren oder schlechteren Code erzeugt — von einer Ausnahme abgesehen: Der Wert beim Zugriff ist zur Compilezeit bekannt und kann daher eliminiert werden.<br />
<syntaxhighlight lang="c"><br />
static const __flash char x[] = { 'A', 'V', 'R' };<br />
<br />
char foo (void)<br />
{<br />
return x[2];<br />
}<br />
</syntaxhighlight><br />
Dies wird übersetzt wie "<tt>return 'R';</tt>", und das Array <tt>x[]</tt> kann komplett wegoptimiert werden und entfallen.<br />
<br />
==== progmem → __flash ====<br />
<br />
Portierung in diese Richtung bedeutet, alten Code anzupassen. Zwingend ist die Portierung nicht, da <tt>progmem</tt> weiterhin unterstützt wird.<br />
Allerdings ist eine Quelle mit <tt>__flash</tt> besser lesbar, denn der Code wird von den <tt>pgm_read</tt>-Funktionen befreit, die vor allem bei Mehrfach-Indirektion den Code ziemlich verunstalten und unleserlich machen können.<br />
Weiterer Vorteil von <tt>_flash</tt> ist, daß eine striktere Typprüfung erfolgen kann.<br />
<br />
Eine Portierung wird man in zwei Schritten vornehmen:<br />
<br />
;1. Definitionen von Flash-Variablen werden angepasst:<br />
<br />
Vorher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
static const char hund[] PROGMEM = "Hund";<br />
static const char katze[] PROGMEM = "Katze";<br />
static const char maus[] PROGMEM = "Maus";<br />
<br />
const char * const tier[] PROGMEM = <br />
{<br />
hund, katze, maus<br />
};<br />
</syntaxhighlight><br />
|}<br />
<br />
Nachher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
static const __flash char hund[] = "Hund";<br />
static const __flash char katze[] = "Katze";<br />
static const __flash char maus[] = "Maus";<br />
<br />
const __flash char * const __flash tier[] = <br />
{<br />
hund, katze, maus<br />
};<br />
</syntaxhighlight><br />
|}<br />
<br />
Der Header <tt>avr/pgmspace.h</tt> wird nicht mehr benötigt. Im Gegensatz zu <tt>progmem</tt> müssen Qualifier immer links von der definierten Variablen stehen; bei Attributen wie <tt>progmem</tt> ist das mehr oder weniger egal.<br />
<br />
Nachdem diese Anpassung erfolgreich abgeschlossen ist, folgt Schritt<br />
<br />
; 2. Der Code wird von <tt>pgm_read</tt>-Aufrufen bereinigt:<br />
<br />
Vorher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
extern const char *tier[];<br />
<br />
char first_letter (uint8_t i)<br />
{<br />
const char* ptier = (const char*) pgm_read_word (&tier[i]);<br />
return (char) pgm_read_byte (&ptier[0]);<br />
}<br />
</syntaxhighlight><br />
|}<br />
<br />
Nachher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <stdint.h><br />
<br />
extern const __flash char * const __flash tier[];<br />
<br />
char first_letter (uint8_t i)<br />
{<br />
return tier[i][0];<br />
}<br />
</syntaxhighlight><br />
|}<br />
<br />
=== Von-Neumannisierung „zu Fuß“ ===<br />
<br />
„Wenn der Prophet nicht zum Berg geht, muss der Berg zum Propheten kommen“.<br />
<br />
Bei Mikrocontrollern mit weniger als 64 KiB Gesamtspeicher ist das mit dem <tt>__flash</tt> oder <tt>PROGMEM</tt> nicht nur lästig sondern erfordert eine Vielzahl von Bibliotheksfunktionen (hier: die auf _P enden) die alle fast dasselbe machen.<br />
<br />
Neuere PIC-Mikrocontroller, AVR xMega3 sowie einige wenige ATtiny verfügen bereits über eine Von-Neumannisierung von RAM und Flash in Hardware, nur bei den gängigen AVRs „will der Prophet nicht zum Berg“, da geht das nicht.<br />
<br />
Hier behilft man sich mit einem Satz aus Inline-Funktionen und Makros, die je nach Bit 15 des Zeigers RAM oder Flash lesen. So setzen die Makros <tt>F(x)</tt> (x als String-Konstante) bzw, <tt>FP(x)</tt> (x als Flash-Adresse) das Bit 15 der Adresse. Die darauf ausgerichtete Bibliotheksfunktion (bspw. ein selbst geschriebener <tt>printf()</tt>-Ersatz) verarbeitet dann den Formatstring aus RAM oder Flash und kommt auch mit <tt>"%s"</tt>-Substitutionen problemlos zurecht. Etwa damit:<br />
<br />
<pre class="c++"><br />
// Von-Neumannisiertes Speicherlesen (RAM oder Flash je nach Bit 15 der Adresse)<br />
inline byte read_byte(const void*addr) {<br />
byte result;<br />
asm(" sbrc %B1,7 \n"<br />
" lpm %0,%a1 \n"<br />
" sbrs %B1,7 \n"<br />
" ld %0,%a1 \n"<br />
:"=r"(result):"z"(addr));<br />
return result;<br />
}<br />
</pre><br />
<br />
== Dateien direkt im Flash einbinden ==<br />
<br />
Wenn man größere Dateien direkt im Programm einbinden will, ohne sie vorher in C Quelltext umzuwandeln, muss man das mit dem Linker machen. Wie das geht steht hier.<br />
<br />
* [http://www.atmel.com/webdoc/avrlibcreferencemanual/FAQ_1faq_binarydata.html Atmel, avr gcc Dokumentation]<br />
* [http://nongnu.org/avr-libc/user-manual/FAQ.html#faq_binarydata Nongnu avr gcc Dokumentation]<br />
<br />
Wie man das dann praktisch umsetzt, sieht man in diesem Beitrag.<br />
<br />
* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056910 Forumsbeitrag]: Binärdateien mittels Linker einbinden<br />
* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056947 Forumsbeitrag]: Ein kleines Tool zum Umwandeln von Binärdateien in C-Quelltext.<br />
<br />
== Flash in der Anwendung schreiben ==<br />
<br />
Bei AVRs mit "self-programming"-Option – auch bekannt als [[Bootloader]]-Support – können Teile des Flash-Speichers vom Anwendungsprogramm beschrieben werden. Dies ist nur möglich, wenn die Schreibfunktion in einem besonderen Speicherbereich, der Boot-Section des Programmspeichers/Flash, abgelegt ist.<br />
<br />
Bei einigen kleinen AVRs gibt es keine gesonderte Boot-Section, bei diesen kann der Flashspeicher von jeder Stelle des Programms geschrieben werden. Für Details sei hier auf das jeweilige Controller-Datenblatt und die Erläuterungen zum Modul boot.h der avr-libc verwiesen. Es existieren auch Application-Notes dazu bei atmel.com, die auf avr-gcc-Code übertragbar sind.<br />
<br />
Siehe auch: <br />
* Forumsbeitrag [http://www.mikrocontroller.net/topic/163632#1561622 Daten in Programmspeicher speichern]<br />
<br />
== EEPROM ==<br />
<br />
Möchte man Werte aus einem Programm heraus so speichern, dass sie auch nach dem Abschalten der Versorgungsspannung noch erhalten bleiben und nach dem Wiederherstellen der Versorgungsspannung bei erneutem Programmstart wieder zur Verfügung stehen, dann benutzt man das EEPROM.<br />
<br />
Schreib- und Lesezugriffe auf den EEPROM-Speicher erfolgen über die im Modul eeprom.h der avr-libc definierten Funktionen. Mit diesen Funktionen können einzelne Bytes, Datenworte (16 Bit), Fließkommawerte (32 Bit, single-precision, float) und Datenblöcke geschrieben und gelesen werden.<br />
<br />
Diese Funktionen kümmern sich auch um diverse Details, die bei der Benutzung des EEPROMs normalerweise notwendig sind:<br />
* EEPROM-Operationen sind im Vergleich relativ langsam. Man muss daher darauf achten, dass eine vorhergehende Operation abgeschlossen ist, ehe die nächste Operation mit dem EEPROM gestartet wird. Die in der avr-libc implementierten Funktionen aus eeprom.h berücksichtigten dies. Soll beim Aufruf einer EEPROM-Funktion sichergestellt werden, dass diese nicht intern in einer Warteschleife auf den Abschluss der vorherigen Operation wartet, kann vorher per eeprom_is_ready testen, ob der Zugriff auf den EEPROM-Speicher sofort möglich ist.<br />
* Es ist darauf zu achten, dass die EEPROM-Funktionen nicht durch einen Interrupt unterbrochen werden. Einige Phasen des Zugriffs sind zeitkritisch und müssen in einer definierten bzw. begrenzten Anzahl von Takten durchgeführt werden. Durch einen unterbrechenden Interrupt würde diese Restriktion nicht mehr eingehalten. Auch dieses Detail wird von den avr-libc Funktionen berücksichtigt, so dass man sich als C-Programmierer nicht darum kümmern muss. Innerhalb der Funktionen werden Interrupts vor der "EEPROM-Sequenz" global deaktiviert und im Anschluss, falls vorher auch schon eingeschaltet, wieder aktiviert.<br />
<br />
Man beachte, dass der EEPROM-Speicher nur eine begrenzte Anzahl von Schreibzugriffen zulässt. Beschreibt man eine EEPROM-Zelle öfter als die im Datenblatt zugesicherte Anzahl (typisch 100.000), wird die Funktion der Zelle nicht mehr garantiert. Dies gilt für jede einzelne Zelle. <br />
<br />
Bei geschickter Programmierung (z.&nbsp;B. Ring-Puffer), bei der die zu beschreibenden Zellen regelmäßig gewechselt werden, kann man eine deutlich höhere Anzahl an Schreibzugriffen, bezogen auf den gesamten EEPROM-Speicher, erreichen. Auf jeden Fall sollte man aber eine Abschätzung über die zu erwartende Lebensdauer des EEPROM durchführen. Wird ein Wert im EEPROM im Durchschnitt nur einmal pro Woche verändert, wird die garantierte Anzahl der Schreibzyklen innerhalb der voraussichtlichen Verwendungszeit des Controllers sicherlich nicht erreicht werden. Welcher Controller ist schon 100000 / 52 = 1923 Jahre im Einsatz? In diesem Fall lohnt es sich daher nicht, erweiterte Programmfunktionen zu implementieren, mit denen die Anzahl der Schreibzugriffe minimiert wird.<br />
<br />
Eine weitere Möglichkeit, Schreibzyklen einzusparen, besteht in der Vorabprüfung, ob der zu speichernde Wert im EEPROM bereits enthalten ist und nur veränderte Werte zu schreiben. In aktuelleren Versionen der avr-libc sind bereits Funktionen enthalten, die solche Prüfungen enthalten (eeprom_update_*).<br />
<br />
Eine dritte Möglichkeit speichert alle Daten zunächst im RAM, wo sie beliebig oft beschrieben werden können. Nur beim Ausschalten oder beim Ausfall der Stromversorgung werden die Daten in den EEPROM geschrieben. Wie man das richtig macht sieht man im Artikel [[Speicher#EEPROM Schreibzugriffe minimieren | Speicher]].<br />
<br />
Lesezugriffe können beliebig oft durchgeführt werden. Sie unterliegen keinen Einschränkungen in Bezug auf deren Anzahl. <br />
<br />
=== EEMEM ===<br />
Um eine Variable im EEPROM anzulegen, stellt die avr-libc das Makro EEMEM zur Verfügung:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdint.h><br />
#include <avr/eeprom.h><br />
<br />
/* Byte */<br />
uint8_t eeFooByte EEMEM = 123;<br />
<br />
/* Wort */<br />
uint16_t eeFooWord EEMEM = 12345;<br />
<br />
/* float */<br />
float eeFooFloat EEMEM;<br />
<br />
/* Byte-Array */<br />
uint8_t eeFooByteArray1[] EEMEM = { 18, 3, 70 };<br />
uint8_t eeFooByteArray2[] EEMEM = { 30, 7, 79 };<br />
<br />
/* 16-bit unsigned short feld */<br />
uint16_t eeFooWordArray1[4] EEMEM;<br />
</syntaxhighlight><br />
<br />
Die grundsätzliche Vorgehensweise ist identisch zur Verwendung von PROGMEM. Auch hier erzeugt man sich spezielle attributierte Variablen (EEMEM erledigt das), die vom Compiler/Linker nicht wie normale Variablen behandelt werden. Compiler/Linker kümmern sich zwar darum, dass diesen Variablen eine Adresse zugewiesen wird, diese Adresse ist dann aber die Adresse der 'Variablen' im EEPROM. Um die dort gespeicherten Werte zu lesen bzw. zu schreiben, übergibt man diese Adresse an spezielle Funktionen, die die entsprechenden Werte aus dem EEPROM holen bzw. das EEPROM neu beschreiben.<br />
<br />
Die mittels EEMEM erzeugten 'Variablen' sind also mehr als Platzhalter zu verstehen, denn als echte Variablen. Es geht nur darum, im C-Programm symbolische Namen zur Verfügung zu haben, anstatt mit echten EEPROM-Adressen hantieren zu müssen, etwas, das grundsätzlich aber auch genauso gut möglich ist. Nur muss man sich in diesem Fall dann selbst darum kümmern, dass mehrere 'Variablen' ohne Überschneidung im EEPROM angeordnet werden.<br />
<br />
=== Bytes lesen/schreiben ===<br />
<br />
Die avr-libc Funktion zum Lesen eines Bytes heißt eeprom_read_byte. Parameter ist die Adresse des Bytes im EEPROM. Geschrieben wird über die Funktion eeprom_write_byte mit den Parametern Adresse und Inhalt. Anwendungsbeispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#define EEPROM_DEF 0xFF<br />
<br />
void eeprom_example (void)<br />
{<br />
uint8_t myByte;<br />
<br />
// myByte lesen (Wert = 123)<br />
myByte = eeprom_read_byte (&eeFooByte);<br />
<br />
// der Wert 99 wird im EEPROM an die Adresse der<br />
// Variablen eeFooByte geschrieben<br />
myByte = 99;<br />
eeprom_write_byte(&eeFooByte, myByte); // schreiben<br />
<br />
myByte = eeprom_read_byte (&eeFooByteArray1[1]); <br />
// myByte hat nun den Wert 3<br />
<br />
// Beispiel fuer eeprom_update_byte: die EEPROM-Zelle wird nur<br />
// dann beschrieben, wenn deren Inhalt sich vom Parameterwert<br />
// unterscheidet. In diesem Beispiel erfolgt also kein Schreib-<br />
// zugriff, da die Werte gleich sind.<br />
eeprom_update_byte(&eeFooByte, myByte);<br />
<br />
<br />
// Beispiel zur "Sicherung" gegen leeres EEPROM nach "Chip Erase"<br />
// (z. B. wenn die .eep-Datei nach Programmierung einer neuen Version<br />
// des Programms nicht in den EEPROM uebertragen wurde und EESAVE<br />
// deaktiviert ist (unprogrammed/1)<br />
// <br />
// Vorsicht: wenn EESAVE "programmed" ist, hilft diese Sicherung nicht<br />
// weiter, da die Speicheraddressen in einem neuen/erweiterten Programm<br />
// moeglicherweise verschoben wurden. An der Stelle &eeFooByte steht<br />
// dann u.U. der Wert einer anderen Variable aus einer "alten" Version.<br />
<br />
uint8_t fooByteDefault = 222;<br />
if ((myByte = eeprom_read_byte (&eeFooByte)) == EEPROM_DEF)<br />
{<br />
myByte = fooByteDefault;<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
=== Wort lesen/schreiben ===<br />
<br />
Schreiben und Lesen von Datenworten erfolgt analog zur Vorgehensweise bei Bytes:<br />
<br />
<syntaxhighlight lang="c"><br />
// lesen<br />
uint16_t myWord = eeprom_read_word (&eeFooWord);<br />
<br />
// schreiben<br />
eeprom_write_word (&eeFooWord, 2222);<br />
</syntaxhighlight><br />
<br />
=== Block lesen/schreiben ===<br />
<br />
Lesen und Schreiben von Datenblöcken erfolgt über die Funktionen <code>eeprom_read_block()</code> bzw. <code>eeprom_write_block()</code>. Die Funktionen erwarten drei Parameter: die Adresse der Quell- bzw. Zieldaten im RAM, die EEPROM-Adresse und die Länge des Datenblocks in Bytes als <code>size_t</code>.<br />
<syntaxhighlight lang="c"><br />
uint8_t myByteBuffer[3];<br />
uint16_t myWordBuffer[4];<br />
<br />
void eeprom_block_example (void)<br />
{<br />
/* Datenblock aus EEPROM lesen */<br />
<br />
/* liest 3 Bytes ab der von eeFooByteArray1 definierten EEPROM-Adresse<br />
in das RAM-Array myByteBuffer */<br />
eeprom_read_block (myByteBuffer, eeFooByteArray1, 3);<br />
<br />
/* dito mit etwas Absicherung betr. der Länge */<br />
eeprom_read_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));<br />
<br />
/* und nun mit 16-Bit Array */<br />
eeprom_read_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));<br />
<br />
/* Datenblock in EEPROM schreiben */<br />
eeprom_write_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));<br />
eeprom_write_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));<br />
}<br />
</syntaxhighlight><br />
<br />
=== Fließkommawerte lesen/schreiben ===<br />
<br />
In der avr-libc stehen auch EEPROM-Funktionen für Variablen des Typs float (Fließkommazahlen mit "einfacher" Genauigkeit) zur Verfügung.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/eeprom.h><br />
<br />
float eeFloat EEMEM = 12.34f;<br />
<br />
float void eeprom_float_example(float value)<br />
{<br />
/* float in EEPROM schreiben */<br />
eeprom_write_float(&eeFloat, value);<br />
<br />
/* float aus EEPROM lesen */<br />
return eeprom_read_float(&eeFloat);<br />
}</syntaxhighlight><br />
<br />
=== EEPROM-Speicherabbild in .eep-Datei ===<br />
<br />
Mit den zum Compiler gehörenden Werkzeugen kann der aus den Variablendeklarationen abgeleitete EEPROM-Inhalt in eine Datei geschrieben werden. Die übliche Dateiendung ist .eep, Daten im Intel Hex-Format. Damit können Standardwerte für den EEPROM-Inhalt im Quellcode definiert werden. <br />
<br />
Makefiles nach WinAVR/MFile-Vorlage enthalten bereits die notwendigen Einstellungen, siehe dazu die Erläuterungen im [[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]].<br />
<br />
Der Inhalt der eep-Datei muss ebenfalls zum Mikrocontroller übertragen werden, wenn die Initialisierungswerte aus der Deklaration vom Programm erwartet werden. Ansonsten enthält der EEPROM-Speicher nach der Übertragung des Programmers mittels ISP abhängig von der Einstellung der EESAVE-Fuse<ref>vgl. Datenblatt Abschnitt Fuse Bits</ref> nicht die korrekten Werte:<br />
; EESAVE = 0 (programmed): Die Daten im EEPROM bleiben erhalten. Werden sie nicht neu geschrieben, so enthält das EEPROM evtl. Daten, die nicht mehr zum Programm passen.<br />
; EESAVE = 1 (unprogrammed): Beim Programmieren werden die Daten im EEPROM gelöscht, also auf 0xff gesetzt.<br />
<br />
Als Sicherung kann man im Programm nochmals die Standardwerte vorhalten, beim Lesen auf 0xFF prüfen und gegebenenfalls einen Standardwert nutzen. Das geht natürlich nur, wenn 0xFF selbst nicht als Datenwert vorkommen kann.<br />
<syntaxhighlight lang="c"><br />
#define DUTY_CYCLE_DEFAULT 0x80<br />
<br />
uint8_t eeDutyCycle EEMEM; // Platzhalter für EEPROM<br />
uint8_t DutyCycle; // die echte Variable<br />
<br />
<br />
int main(void)<br />
{<br />
DutyCycle = eeprom_read_byte( &eeDutyCycle );<br />
if( DutyCycle == 0xFF ) // das allererste mal. Im EEPROM steht noch kein gültiger Wert<br />
{<br />
DutyCycle = DUTY_CYCLE_DEFAULT;<br />
eeprom_writeByte( &eeDutyCycle, DutyCycle );<br />
}<br />
<br />
...<br />
</syntaxhighlight><br />
<br />
=== Direkter Zugriff auf EEPROM-Adressen ===<br />
<br />
Will man direkt auf bestimmte EEPROM Adressen zugreifen, dann sind folgende IAR-kompatiblen Makros <tt>_EEGET</tt> und <tt>_EEPUT</tt> hilfreich, um sich die Typecasts zu ersparen.<br />
<br />
;Hinweis: Die nachfolgend gezeigten Makros und Zugriffe auf absolute Adressen sind in Normalfall nicht nötig und nur auf sehr wenige, spezielle Fälle beschränkt! Im Normalfall sollte man auf absolute Adressen möglichst nicht zugreifen und den Compiler seine Arbeit machen lassen, der verwaltet die Variablen und deren Adressen meist besser als der Programmierer. Der Zugriff auf Variablen im EEPROM sollte immer über ihren Namen erfolgen.<br />
<br />
Verwendung:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/eeprom.h><br />
<br />
_EEPUT (0x20, 128); // Byte-Wert 128 an Adresse 0x20 schreiben<br />
...<br />
uint8_t val = _EEGET (0x20); // EEPROM-Wert von Adresse 0x20 lesen<br />
</syntaxhighlight><br />
<br />
=== Was steckt dahinter? - EEPROM-Register ===<br />
Auch wenn es normalerweise keinen Grund gibt, in C selbst an den Steuerregistern herumzuschrauben - die eeprom Funktionen erledigen das alles zuverlässig - der Vollständigkeit halber der registermässige technische Unterbau.<br />
Um das EEPROM anzusteuern, sind drei Register von Bedeutung:<br />
;EEAR: Hier werden die Adressen eingetragen zum Schreiben oder Lesen. Dieses Register unterteilt sich nochmal in EEARH und EEARL, da in einem 8-Bit-Register keine 512 Adressen adressiert werden können.<br />
;EEDR: Hier werden die Daten eingetragen, die geschrieben werden sollen, bzw. es enthält die gelesenen Daten.<br />
;EECR: Ist das Kontrollregister für das EEPROM<br />
<br />
Das EECR steuert den Zugriff auf das EEPROM und ist wie folgt aufgebaut:<br />
<br />
:{| class="wikitable" style="text-align:center"<br />
|+ '''Aufbau des EECR-Registers'''<br />
|-<br />
!Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|-<br />
! Name<br />
| - || - || - ||- || EERIE || EEMWE || EEWE || EERE<br />
|-<br />
! Read/Write<br />
| R || R || R || R || R/W || R/W || R/W || R/W<br />
|-<br />
!Init Value<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''Bedeutung der Bits'''<br />
<br />
;Bit 4-7: nicht belegt<br />
<br />
;Bit 3 (EERIE): ''EEPROM Ready Interrupt Enable'': Wenn das Bit gesetzt ist und globale Interrupts erlaubt sind in Register SREG (Bit 7), wird ein Interrupt ausgelöst nach Beendigung des Schreibzyklus (EEPROM Ready Interrupt). Ist einer der beiden Bits 0, wird kein Interrupt ausgelöst.<br />
<br />
;Bit 2 EEMWE): ''EEPROM Master Write Enable'': Dieses Bit bestimmt, dass, wenn EEWE = 1 gesetzt wird (innerhalb von 4 Taktzyklen), das EEPROM beschrieben wird mit den Daten in EEDR bei Adresse EEAR. Wenn EEMWE = 0 ist und EEWE = 1 gesetzt wird, hat das keine Auswirkungen. Der Schreibvorgang wird dann nicht ausgelöst. Nach 4 Taktzyklen wird das Bit EEMWE automatisch wieder auf 0 gesetzt. Dieses Bit löst den Schreibvorgang nicht aus, es dient sozusagen als Sicherungsbit für EEWE.<br />
<br />
;Bit 1 (EEWE): ''EEPROM Write Enable'': Dieses Bit löst den Schreibvorgang aus, wenn es auf 1 gesetzt wird, sofern vorher EEMWE gesetzt wurde und seitdem nicht mehr als 4 Taktzyklen vergangen sind. Wenn der Schreibvorgang abgeschlossen ist, wird dieses Bit automatisch wieder auf 0 gesetzt und, sofern EERIE gesetzt ist, ein Interrupt ausgelöst. Ein Schreibvorgang sieht typischerweise wie folgt aus:<br />
:# EEPROM-Bereitschaft abwarten (EEWE=0) <br />
:# Adresse übergeben an EEAR<br />
:# Daten übergeben an EEDR<br />
:# Schreibvorgang auslösen in EECR mit Bit EEMWE=1 und EEWE=1<br />
:# (Optional) Warten, bis Schreibvorgang abgeschlossen ist<br />
<br />
;Bit 0 EERE: ''EEPROM Read Enable'': Wird dieses Bit auf 1 gesetzt wird das EEPROM an der Adresse in EEAR ausgelesen und die Daten in EEDR gespeichert. Das EEPROM kann nicht ausgelesen werden, wenn bereits eine Schreiboperation gestartet wurde. Es ist daher zu empfehlen, die Bereitschaft vorher zu prüfen. Das EEPROM ist lesebereit, wenn das Bit EEWE=0 ist. Ist der Lesevorgang abgeschlossen, wird das Bit wieder auf 0 gesetzt, und das EEPROM ist für neue Lese- und Schreibbefehle wieder bereit. Ein typischer Lesevorgang kann wie folgt aufgebaut sein:<br />
:# Bereitschaft zum Lesen prüfen (EEWE=0)<br />
:# Adresse übergeben an EEAR<br />
:# Lesezyklus auslösen mit EERE = 1<br />
:# Warten, bis Lesevorgang abgeschlossen EERE = 0<br />
:# Daten abholen aus EEDR<br />
<br />
= Die Nutzung von sprintf und printf =<br />
<br />
Um komfortabel, d.h. formatiert, Ausgaben auf ein Display oder die serielle Schnittstelle zu tätigen, bieten sich '''sprintf''' oder '''printf''' an. Alle *printf-Varianten sind jedoch ziemlich speicherintensiv und der Einsatz in einem Mikrocontroller mit knappem Speicher muss sorgsam abgewogen werden.<br />
<br />
Bei '''sprintf''' wird die Ausgabe zunächst in einem Puffer vorbereitet und anschließend mit einfachen Funktionen zeichenweise ausgegeben. Es liegt in der Verantwortung des Programmierers, genügend Platz im Puffer für die erwarteten Zeichen bereitzuhalten.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdio.h><br />
#include <stdint.h><br />
<br />
// ...<br />
// nicht dargestellt: Implementierung von uart_puts (vgl. Abschnitt UART)<br />
// ...<br />
<br />
uint16_t counter;<br />
<br />
// Ausgabe eines unsigned Integerwertes<br />
void uart_puti( uint16_t value )<br />
{<br />
uint8_t puffer[20];<br />
<br />
sprintf( puffer, "Zählerstand: %u", value );<br />
uart_puts( puffer );<br />
}<br />
<br />
int main()<br />
{<br />
counter = 5;<br />
<br />
uart_puti( counter );<br />
uart_puti( 42 );<br />
}<br />
</syntaxhighlight><br />
<br />
Eine weitere elegante Möglichkeit besteht darin, den STREAM stdout (Standardausgabe) auf eine eigene Ausgabefunktion umzuleiten. Dazu wird dem Ausgabemechanismus der C-Bibliothek eine neue Ausgabefunktion bekannt gemacht, deren Aufgabe es ist, ein einzelnes Zeichen auszugeben. Wohin die Ausgabe dann tatsächlich stattfindet, ist Sache der Ausgabefunktion. Im Beispiel unten wird auf UART ausgegeben. Alle anderen, höheren Funktionen wie z.&nbsp;B. '''printf''', greifen letztendlich auf diese primitive Ausgabefunktion zurück. <br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdio.h><br />
<br />
void uart_init(void);<br />
<br />
// a. Deklaration der primitiven Ausgabefunktion<br />
int uart_putchar(char c, FILE *stream);<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 1)<br />
static FILE mystdout = FDEV_SETUP_STREAM( uart_putchar, NULL, _FDEV_SETUP_WRITE );<br />
<br />
// c. Definition der Ausgabefunktion<br />
int uart_putchar( char c, FILE *stream )<br />
{<br />
if( c == '\n' )<br />
uart_putchar( '\r', stream );<br />
<br />
loop_until_bit_is_set( UCSRA, UDRE );<br />
UDR = c;<br />
return 0;<br />
}<br />
<br />
void uart_init(void)<br />
{<br />
/* hier µC spezifischen Code zur Initialisierung */<br />
/* des UART einfügen... s.o. im AVR-GCC-Tutorial */<br />
<br />
// Beispiel: <br />
//<br />
// myAVR Board 1.5 mit externem Quarz Q1 3,6864 MHz<br />
// 9600 Baud 8N1<br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
// Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt)<br />
#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)<br />
<br />
UCSRB |= (1<<TXEN) | (1<<RXEN); // UART TX und RX einschalten<br />
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1 <br />
<br />
UBRRH = (uint8_t)( UART_UBRR_CALC( UART_BAUD_RATE, F_CPU ) >> 8 );<br />
UBRRL = (uint8_t)UART_UBRR_CALC( UART_BAUD_RATE, F_CPU );<br />
}<br />
<br />
int main(void)<br />
{<br />
int16_t antwort = 42;<br />
uart_init();<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 2)<br />
stdout = &mystdout;<br />
<br />
// Anwendung<br />
printf( "Die Antwort ist %d.\n", antwort );<br />
return 0;<br />
}<br />
<br />
// Quelle: avr-libc-user-manual-1.4.3.pdf, S.74<br />
// + Ergänzungen<br />
</syntaxhighlight><br />
<br />
<br />
Sollen Fließkommazahlen ausgegeben werden, muss im Makefile eine andere (größere) Version der [[FAQ#Aktivieren_der_Floating_Point_Version_von_sprintf_beim_WinAVR_mit_AVR-Studio|printflib]] eingebunden werden.<br />
<br />
= Anmerkungen =<br />
<references/><br />
<br />
= TODO =<br />
* Aktualisierung Register- und Bitbeschreibungen an aktuelle AVR<br />
* "naked"-Funktionen [http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html][http://arduino.stackexchange.com/questions/8758/arduino-interruption-on-pin-change]<br />
<br />
[[Kategorie:avr-gcc Tutorial| ]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR-GCC-Tutorial&diff=107263AVR-GCC-Tutorial2025-01-28T08:08:07Z<p>Heha: /* Datenzugriff jenseits 64 KiB */</p>
<hr />
<div>Dieses Tutorial soll den Einstieg in die Programmierung von Atmel [[AVR]]-Mikrocontrollern in der Programmiersprache [[C]] mit dem freien C-Compiler [[avr-gcc]] aus der [http://gcc.gnu.org/ GNU Compiler Collection] (GCC) erleichtern.<br />
<br />
Vorausgesetzt werden Grundkenntnisse der Programmiersprache C. Diese Kenntnisse kann man sich online erarbeiten, z. B. mit dem [http://www.schellong.de/c.htm C Tutorial von Helmut Schellong] ([[C|Liste von C-Tutorials]]). Nicht erforderlich sind Vorkenntnisse in der Programmierung von Mikrocontrollern.<br />
<br />
= Vorwort =<br />
<br />
In diesem Text wird häufig auf die Standardbibliothek avr-libc verwiesen, für die es eine [http://www.nongnu.org/avr-libc/user-manual/index.html Online-Dokumentation] gibt, in der sich auch viele nützliche Informationen zum Compiler und zur Programmierung von AVR-Controllern finden. Beim Paket [[WinAVR]] gehört die avr-libc Dokumentation zum Lieferumfang und wird mitinstalliert.<br />
<br />
Der Compiler und die Standardbibliothek avr-libc werden ständig weiterentwickelt. Einige Unterschiede, die sich im Verlauf der Entwicklung ergeben haben, werden hier und im Artikel [[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen]] zwar angesprochen, Anfängern und Umsteigern sei jedoch empfohlen, eine aktuelle Versionen zu nutzen.<br />
<br />
Das ursprüngliche Tutorial stammt von Christian Schifferle, viele neue Abschnitte und aktuelle Anpassungen von Martin Thomas.<br />
<br />
Dieses Tutorial ist in [[Media:AVR-GCC-Tutorial.pdf|PDF-Form]] erhältlich (zur Zeit nur eine sehr veraltete Version).<br />
<br />
== Weiterführende Kapitel ==<br />
<br />
Um dieses riesige Tutorial etwas überschaubarer zu gestalten, wurden einige Kapitel ausgelagert, die nicht unmittelbar mit den Grundlagen von avr-gcc in Verbindung stehen. All diese Seiten gehören zur [[:Kategorie:avr-gcc Tutorial]].<br />
<br />
;UART: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der UART|Der UART]]''<br />
<br />
;ADC: → Hauptartikel: ''[[AVR-GCC-Tutorial/Analoge Ein- und Ausgabe|Analoge Ein- und Ausgabe (ADC)]]''<br />
<br />
;Timer: → Hauptartikel: ''[[AVR-GCC-Tutorial/Die Timer und Zähler des AVR|Die Timer und Zähler des AVR]]''<br />
<br />
;LCD: → Hauptartikel: ''[[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Ansteuerung]]''<br />
<br />
;Watchdog: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der Watchdog|Der Watchdog]]''<br />
<br />
;Assembler: → Hauptartikel: ''[[AVR-GCC-Tutorial/Assembler und Inline-Assembler|Assembler und Inline-Assembler]]''<br />
<br />
;alte Quellen anpassen: → Hauptartikel: ''[[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen anpassen]]''<br />
<br />
;Makefiles: → Hauptartikel: ''[[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]]'' sowie als Alternative für sehr kleine Projekte → Hauptartikel: ''[[C ohne Makefile]]''<br />
<br />
= Benötigte Werkzeuge =<br />
<br />
Um eigene Programme für AVRs mittels einer AVR-Toolchain zu erstellen wird folgende Hard- und Software benötigt:<br />
<br />
* Eine AVR-Toolchain bestehend aus avr-gcc, den avr-Binutils (Assembler, Linker, etc) und einer Standard-C Bibliothek. Üblich ist die AVR-LibC, die auch quasi in allen avr-gcc Distributionen enthalten ist.<br />
<br />
Hardware wird keine benötigt – bis auf einen PC natürlich, auf dem der Compiler ablaufen kann. Selbst ohne AVR-Hardware kann man also bereits C-Programme für AVRs schreiben, compiliern und sich das Look-and-Feel von avr-gcc sowie von IDEs wie [[Atmel Studio]], Eclipse oder leichtgewichtigeren Entwicklungsumbgebungen anschauen. Selbst das Debuggen und Simulieren ist mithilfe entsprechender Tools wie Debugger und Simulator in gewissen Grenzen möglich.<br />
<br />
Um Programme für AVRs mittels einer AVR-Toolchain zu testen, wird folgende Hard- und Software benötigt:<br />
<br />
* Platine oder Versuchsaufbau für die Aufnahme eines AVR-Controllers, der vom avr-gcc Compiler unterstützt wird.<ref>Für eine Liste der unterstützten COntroller siehe die Dokumentation des Compilers oder [http://www.nongnu.org/avr-libc/user-manual/index.html#supported_devices AVR-Libc: Supported Devices].</ref> Dieses Testboard kann durchaus auch selbst gelötet oder auf einem Steckbrett aufgebaut werden. Einige Registerbeschreibungen dieses Tutorials beziehen sich auf den inzwischen veralteten AT90S2313. Der weitaus größte Teil des Textes ist aber für alle Controller der AVR-Familie gültig. <br />
<br />
:Brauchbare Testplattformen sind auch das [[STK500]] und der [[AVR Butterfly]] von Atmel. Weitere Infos findet man in den Artikeln [[AVR#Starterkits|AVR Starterkits]] und [[AVR-Tutorial: Equipment]].<br />
<br />
* Programmiersoftware und -[[AVR In System Programmer |hardware]] z. B. PonyProg (siehe auch: [[Pony-Prog Tutorial]]) oder [[AVRDUDE]] mit [[STK200]]-Dongle oder die von Atmel verfügbare Hard- und Software ([[STK500]], Atmel AVRISP, [[AVR-Studio]]).<br />
<br />
* Nicht unbedingt erforderlich, aber zur Simulation und zum Debuggen unter MS-Windows recht nützlich: [[AVR-Studio]].<br />
<br />
* Wer unter Windows und Linux gleichermassen entwickeln will, der sollte sich die [http://www.eclipse.org/ IDE Eclipse for C/C++ Developers] und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] ansehen. Beide sind unter Windows und Linux einfach zu installieren, siehe auch [[AVR Eclipse]]. Ebenfalls unter Linux und Windows verfügbar ist die Entwicklungsumgebung [http://www.codeblocks.org/ Code::Blocks]<ref>Aktuelle, stabile Versionen sind als Nightly Builds regelmäßig im [http://forums.codeblocks.org/ Forum] verfügbar.</ref>. Innerhalb dieser Entwicklungsumgebung können ohne die Installation zusätzlicher Plugins "AVR-Projekte" angelegt werden. Für Linux gibt es auch noch das [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=25220 KontrollerLab].<br />
<br />
= Was tun, wenn's nicht klappt? =<br />
<br />
* Herausfinden, ob es tatsächlich ein avr(-gcc) spezifisches Problem ist oder nur die eigenen C-Kenntnisse einer Auffrischung bedürfen. Allgemeine C-Fragen kann man eventuell "beim freundlichen Programmierer zwei Büro-, Zimmer- oder Haustüren weiter" loswerden. Ansonsten: [[C]]-Buch (gibt's auch "gratis" online) lesen.<br />
<br />
* Die [[AVR Checkliste]] durcharbeiten.<br />
<br />
* Die '''[http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc]''' lesen, vor allem (aber nicht nur) den Abschnitt Related Pages/'''Frequently Asked Questions''' = Oft gestellte Fragen (und Antworten dazu). Z.Zt leider nur in englischer Sprache verfügbar.<br />
<br />
* Den Artikel [[AVR-GCC]] in diesem Wiki lesen.<br />
<br />
* Das [http://www.mikrocontroller.net/forum/gcc GCC-Forum auf www.mikrocontroller.net] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das avr-gcc-Forum bei [http://www.avrfreaks.net AVRfreaks] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das [http://lists.gnu.org/archive/html/avr-gcc-list/ Archiv der avr-gcc Mailing-Liste] nach vergleichbaren Problemen absuchen.<br />
<br />
* Nach Beispielcode suchen. Vor allem im ''Projects''-Bereich von [http://www.avrfreaks.net AVRfreaks] (anmelden).<br />
<br />
* Google oder yahoo befragen schadet nie.<br />
<br />
* Bei Problemen mit der Ansteuerung interner AVR-Funktionen mit C-Code: das Datenblatt des Controllers lesen (ganz und am Besten zweimal). Datenblätter sind auf den [http://www.atmel.com Atmel Webseiten] als pdf-Dateien verfügbar. Das komplette Datenblatt (complete) und nicht die Kurzfassung (summary) verwenden.<br />
<br />
* Die Beispielprogramme im [[AVR-Tutorial]] sind zwar in AVR-Assembler verfasst, Erläuterungen und Vorgehensweisen sind aber auch auf C-Programme übertragbar.<br />
<br />
* Einen Beitrag in eines der Foren oder eine Mail an die Mailing-Liste schreiben. Dabei möglichst viel Information geben: Controller, Compilerversion, genutzte Bibliotheken, Ausschnitte aus dem Quellcode oder besser ein [http://www.mikrocontroller.net/topic/72767#598986 Testprojekt] mit allen notwendigen Dateien, um das Problem nachzuvollziehen, sowie genaue Fehlermeldungen bzw. Beschreibung des Fehlverhaltens. Bei Ansteuerung externer Geräte die Beschaltung beschreiben oder skizzieren (z. B. mit [http://www.tech-chat.de/ Andys ASCII Circuit]). Siehe dazu auch: '''[http://www.tty1.net/smart-questions_de.html "Wie man Fragen richtig stellt"]'''.<br />
<br />
= Erzeugen von Maschinencode =<br />
<br />
Aus dem C-Quellcode erzeugt der avr-gcc Compiler (zusammen mit Hilfsprogrammen wie z.&nbsp;B. Präprozessor, Assembler und Linker) Maschinencode für den AVR-Controller. Üblicherweise liegt dieser Code dann im Intel Hex-Format vor ("Hex-Datei"). Die Programmiersoftware (z.&nbsp;B. [[AVRDUDE]], PonyProg oder AVRStudio/STK500-plugin) liest diese Datei ein und überträgt die enthaltene Information (den Maschinencode) in den Speicher des Controllers. Im Prinzip sind also "nur" der avr-gcc-Compiler (und wenige Hilfsprogramme) mit den "richtigen" Optionen aufzurufen, um aus C-Code eine "Hex-Datei" zu erzeugen. Grundsätzlich stehen dazu drei verschiedene Ansätze zur Verfügung:<br />
<br />
* Die Verwendung einer integrierten Entwicklungsumgebung (IDE = '''I'''ntegrated '''D'''evelopment '''E'''nvironment), bei der alle Einstellungen z.&nbsp;B. in Dialogboxen durchgeführt werden können. Unter Anderem kann AVRStudio ab Version 4.12 (kostenlos auf [http://www.atmel.com/ atmel.com]) zusammen mit WinAVR als integrierte Entwicklungsumgebung für den Compiler avr-gcc genutzt werden (dazu müssen AVRStudio und WinAVR auf dem Rechner installiert sein). Weitere IDEs (ohne Anspruch auf Vollständigkeit): [http://www.eclipse.org/ Eclipse for C/C++ Developers] (d.h. inkl. CDT) und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] (für diverse Plattformen, u.a. Linux und MS Windows, IDE und Plugin kostenlos), [http://sourceforge.net/projects/kontrollerlab KontrollerLab] (Linux/KDE, kostenlos). [http://www.atmanecl.com/EnglishSite/SoftwareEnglish.htm AtmanAvr] (MS Windows, relativ günstig), KamAVR (MS-Windows, kostenlos, wird augenscheinlich nicht mehr weiterentwickelt), [http://www.amctools.com/vmlab.htm VMLab] (MS Windows, ab Version 3.12 ebenfalls kostenlos). Integrierte Entwicklungsumgebungen unterscheiden sich stark in Ihrer Bedienung und stehen auch nicht für alle Plattformen zur Verfügung, auf denen der Compiler ausführbar ist (z.&nbsp;B. AVRStudio nur für MS-Windows). Zur Anwendung des avr-gcc Compilers mit IDEs sei hier auf deren Dokumentation verwiesen. <br />
<br />
* Die Nutzung des Programms make mit passenden Makefiles. In den folgenden Abschnitten wird die Generierung von Maschinencode für einen AVR ("hex-Datei") aus C-Quellcode ("c-Dateien") anhand von "make" und den "Makefiles" näher erläutert. Viele der darin beschriebenen Optionen findet man auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio (AVRStudio generiert ein makefile in einem Unterverzeichnis des Projektverzeichnisses). <br />
<br />
* Das Generieren des Programms ohne IDE und ohne Makefile. In diesem Fall muss die Quellcodedatei durch eine vorgefertigte Kommandofolge an den Compiler übergeben werden. Der Artikel [[C ohne Makefile]] zeigt, wie das funktioniert. Diese Vorgehensweise empfiehlt sich jedoch nur für kleine Programme, die nicht auf verschiedene Quellcodedateien verteilt sind.<br />
<br />
Beim Wechsel vom makefile-Ansatz nach WinAVR-Vorlage zu AVRStudio ist darauf zu achten, dass AVRStudio (Stand: AVRStudio Version 4.13) bei einem neuen Projekt die Optimierungsoption (vgl. Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|AVR-GCC-Tutorial/Exkurs: Makefiles]], typisch: -Os) nicht einstellt und die mathematische Bibliothek der avr-libc (libm.a, Linker-Option -lm) nicht einbindet. (Hinweis: Bei Version 4.16 wird beides bereits gesetzt). Beides ist Standard bei Verwendung von makefiles nach WinAVR-Vorlage und sollte daher auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio "manuell" eingestellt werden, um auch mit AVRStudio kompakten Code zu erzeugen.<br />
<br />
= Einführungsbeispiel =<br />
<br />
Zum Einstieg ein kleines Beispiel, an dem die Nutzung des Compilers und der Hilfsprogramme (der sogenannten ''Toolchain'') demonstriert wird. Detaillierte Erläuterungen folgen in den weiteren Abschnitten dieses Tutorials.<br />
<br />
Das Programm soll auf einem AVR Mikrocontroller einige Ausgänge ein- und andere ausschalten. Das Beispiel ist für einen ATmega16 programmiert ([http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf Datenblatt]), kann aber sinngemäß für andere Controller der AVR-Familie modifiziert werden. <br />
<br />
Ein kurzes Wort zur Hardware: Bei diesem Programm werden alle Pins von PORTB auf Ausgang gesetzt, und einige davon werden auf HIGH andere auf LOW gesetzt. Das kann je nach angeschlossener Hardware an diesen Pins kritisch sein. Am ungefährlichsten ist es, wenn nichts an den Pins angeschlossen ist und man die Funktion des Programmes durch eine Spannungsmessung mit einem Multimeter kontrolliert. Die Spannung wird dabei zwischen GND-Pin und den einzelnen Pins von PORTB gemessen.<br />
<br />
Zunächst der Quellcode der Anwendung, der in einer Text-Datei mit dem Namen ''main.c'' abgespeichert wird.<br />
<br />
<syntaxhighlight lang="c"><br />
/* Alle Zeichen zwischen Schrägstrich-Stern <br />
und Stern-Schrägstrich sind Kommentare */<br />
<br />
// Zeilenkommentare sind ebenfalls möglich<br />
// alle auf die beiden Schrägstriche folgenden<br />
// Zeichen einer Zeile sind Kommentar<br />
<br />
#include <avr/io.h> // (1)<br />
<br />
int main (void) { // (2)<br />
<br />
DDRB = 0xFF; // (3)<br />
PORTB = 0x03; // (4)<br />
<br />
while(1) { // (5)<br />
/* "leere" Schleife*/ // (6)<br />
} // (7)<br />
<br />
/* wird nie erreicht */<br />
return 0; // (8)<br />
}<br />
</syntaxhighlight><br />
<br />
# In dieser Zeile wird eine sogenannte Header-Datei eingebunden. In <code>avr/io.h</code> sind die Registernamen definiert, die im späteren Verlauf genutzt werden. Auch unter Windows wird ein&nbsp;<code>/</code> zur Kennzeichnung von Unterverzeichnissen in Include-Dateinamen verwendet und kein&nbsp;<code>\</code>.<br />
# Hier beginnt das eigentliche Programm. Jedes C-Programm beginnt mit den Anweisungen in der Funktion <code>main</code>.<br />
# Die Anschlüsse eines AVR (Pins) werden zu Blöcken zusammengefasst, einen solchen Block bezeichnet man als Port. Beim ATmega16 hat jeder Port 8 Anschlüsse, bei kleineren AVRs können einem Port auch weniger als 8 Anschlüsse zugeordnet sein. Da per Definition (Datenblatt) alle gesetzten Bits in einem Datenrichtungsregister den entsprechenden Anschluss auf Ausgang schalten, werden mit DDRB=0xff alle Anschlüsse des Ports B als Ausgänge eingestellt.<br />
# Die den ersten beiden Bits des Ports zugeordneten Anschlüsse (PB0 und PB1) werden 1, alle anderen Anschlüsse des Ports B (PB2-PB7) zu 0. Aktivierte Ausgänge (logisch 1 oder "high") liegen auf Betriebsspannung (VCC, meist 5 Volt), nicht aktivierte Ausgänge führen 0 Volt (GND, Bezugspotential). Es ist sinnvoll, sich möglichst frühzeitig eine alternative Schreibweise beizubringen, die wegen der leichteren Überprüfbarkeit und Portierbarkeit oft im weiteren Tutorial und in Forenbeiträgen benutzt wird. Die Zuordnung sieht in diesem Fall so aus, Näheres dazu im Artikel [[Bitmanipulation]]:<syntaxhighlight lang="c">PORTB = (1<<PB1) | (1<<PB0);</syntaxhighlight><br />
# ist der Beginn der sogenannte ''Hauptschleife'' (main-loop). Dies ist eine Endlosschleife, welche kontinuierlich wiederkehrende Befehle enthält.<br />
# In diesem Beispiel ist die Hauptschleife leer. Der Controller durchläuft die Schleife immer wieder, ohne dass etwas passiert. Eine solche Schleife ist notwendig, da es auf dem Controller kein Betriebssystem gibt, das nach Beendigung des Programmes die Kontrolle übernehmen könnte. Ohne diese Schleife kehrt das Programm aus <code>main</code> zurück, alle Interrupts werden deaktiviert und eine Endlosschleife betreten.<br />
# Ende der Hauptschleife und Sprung zur passenden, öffnenden Klammer, also zu 5.<br />
# ist das Programmende. Die Zeile ist nur aus Gründen der C-Kompatibilität enthalten: <syntaxhighlight lang="c">int main(void)</syntaxhighlight> besagt, dass die Funktion einen int-Wert zurückgibt. Die Anweisung wird aber nicht erreicht, da das Programm die Hauptschleife nie verlässt.<br />
<br />
Um diesen Quellcode in ein lauffähiges Programm zu übersetzen, wird hier ein Makefile genutzt. Das verwendete Makefile findet sich auf der Seite [[Beispiel Makefile]] und basiert auf der Vorlage, die in WinAVR mitgeliefert wird und wurde bereits angepasst (Controllertyp ATmega16). Man kann das Makefile bearbeiten und an andere Controller anpassen oder sich mit dem Programm MFile menügesteuert ein Makefile "zusammenklicken". Das Makefile speichert man unter dem Namen <code>Makefile</code> (ohne Endung) im selben Verzeichnis, in dem auch die Datei <code>main.c</code> mit dem Programmcode abgelegt ist. Detailliertere Erklärungen zur Funktion von Makefiles finden sich im Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|Exkurs: Makefiles]].<br />
<br />
<pre><br />
D:\beispiel>dir<br />
<br />
Verzeichnis von D:\beispiel<br />
<br />
28.11.2006 22:53 <DIR> .<br />
28.11.2006 22:53 <DIR> ..<br />
28.11.2006 20:06 118 main.c<br />
28.11.2006 20:03 16.810 Makefile<br />
2 Datei(en) 16.928 Bytes<br />
</pre><br />
<br />
Nun gibt man ''make all'' ein. Falls das mit WinAVR installierte Programmers Notepad genutzt wird, gibt es dazu einen Menüpunkt im Tools Menü. Sind alle Einstellungen korrekt, entsteht eine Datei <code>main.hex</code>, in welcher der Code für den AVR enthalten ist. <br />
<pre><br />
D:\beispiel>make all<br />
<br />
-------- begin --------<br />
avr-gcc (GCC) 3.4.6<br />
Copyright (C) 2006 Free Software Foundation, Inc.<br />
This is free software; see the source for copying conditions. There is NO<br />
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.<br />
<br />
Compiling C: main.c<br />
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -f<br />
unsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef<br />
-Wa,-adhlns=obj/main.lst -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c -<br />
o obj/main.o<br />
<br />
Linking: main.elf<br />
avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -funs<br />
igned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -W<br />
a,-adhlns=obj/main.o -std=gnu99 -Wundef -MD -MP -MF .dep/main.elf.d obj/main.o<br />
--output main.elf -Wl,-Map=main.map,--cref -lm<br />
<br />
Creating load file for Flash: main.hex<br />
avr-objcopy -O ihex -R .eeprom main.elf main.hex<br />
</pre><br />
<br />
Der Inhalt der hex-Datei kann nun zum Controller übertragen werden. Dies kann z.&nbsp;B. über In-System-Programming ([[ISP]]) erfolgen, das im [[AVR-Tutorial: Equipment]] beschrieben ist. Makefiles nach der WinAVR/MFile-Vorlage sind für die Nutzung des Programms [[AVRDUDE]] vorbereitet. Wenn man den Typ und Anschluss des Programmiergerätes richtig eingestellt hat, kann mit ''make program'' die Übertragung mittels AVRDUDE gestartet werden. Jede andere Software, die hex-Dateien lesen und zu einem AVR übertragen kann<ref>z.&nbsp;B. [[Pony-Prog_Tutorial|Ponyprog]], yapp, AVRStudio</ref>, kann natürlich ebenfalls genutzt werden.<br />
<br />
Startet man nun den Controller (Reset-Taster oder Stromzufuhr aus/an), werden vom Programm die Anschlüsse PB0 und PB1 auf 1 gesetzt. Man kann mit einem Messgerät nun an diesem Anschluss die Betriebsspannung messen oder eine [[LED]] leuchten lassen (Anode an den Pin, Vorwiderstand nicht vergessen). An den Anschlüssen PB2-PB7 misst man 0 Volt. Eine mit der Anode mit einem dieser Anschlüsse verbundene LED leuchtet nicht.<br />
<br />
= Ganzzahlige Datentypen (Integer) =<br />
<br />
Bei der Programmierung von Mikrokontrollern ist die Definition einiger ganzzahliger Datentypen sinnvoll, an denen eindeutig die Bit-Länge abgelesen werden kann.<br />
<br />
Standardisierte Datentypen werden in der Header-Datei <code>stdint.h</code> definiert, die folgendermaßen eingebunden werden kann:<br />
<syntaxhighlight lang="c">#include <stdint.h></syntaxhighlight><br />
<br />
{| {{Tabelle}}<br />
|+ '''int-Typen aus <code>stdint.h</code> (C99)'''<br/>&nbsp;<br />
|- bgcolor="#d0d0ff"<br />
!colspan="5"| Vorzeichenbehaftete int-Typen<br />
|- bgcolor="#e8e8ff"<br />
! Typname || Bit-Breite ||colspan="2"| Wertebereich<br />
|align="center| '''C-Entsprechung''' (avr-gcc)<br />
|-<br />
|<code>int8_t</code> ||align="right"| 8 || −128 ⋯ 127 || −2<sup>7</sup> ⋯ 2<sup>7</sup>−1 || <code>signed char</code><br />
|-<br />
|<code>int16_t</code> ||align="right"| 16 || −32768 ⋯ 32767 || −2<sup>15</sup> ⋯ 2<sup>15</sup>−1 || <code>signed short</code>, <code>signed int</code><br />
|-<br />
|<code>int32_t</code> ||align="right"| 32 || −2147483648 ⋯ 2147483647 || −2<sup>31</sup> ⋯ 2<sup>31</sup>−1 || <code>signed long</code><br />
|-<br />
|<code>int64_t</code> ||align="right"| 64 || −9223372036854775808 ⋯ 9223372036854775807 || −2<sup>63</sup> ⋯ 2<sup>63</sup>−1 || <code>signed long long</code><br />
|- bgcolor="#d0d0ff"<br />
!colspan="5"| Vorzeichenlose int-Typen<br />
|- bgcolor="#e8e8ff"<br />
! Typname || Bit-Breite ||colspan="2"| Wertebereich<br />
|align="center| '''C-Entsprechung''' (avr-gcc)<br />
|-<br />
|<code>uint8_t</code> ||align="right"| 8 || 0 ⋯ 255 || 0 ⋯ 2<sup>8</sup>−1 || <code>unsigned char</code><br />
|-<br />
|<code>uint16_t</code> ||align="right"| 16 || 0 ⋯ 65535 || 0 ⋯ 2<sup>16</sup>−1 || <code>unsigned short</code>, <code>unsigned int</code><br />
|-<br />
|<code>uint32_t</code> ||align="right"| 32 || 0 ⋯ 4294967295 || 0 ⋯ 2<sup>32</sup>−1 || <code>unsigned long</code><br />
|-<br />
|<code>uint64_t</code> ||align="right"| 64 || 0 ⋯ 18446744073709551615 || 0 ⋯ 2<sup>64</sup>−1 || <code>unsigned long long</code><br />
|}<br />
<br />
Neben den Typen gibt es auch Makros für die Bereichsgrenzen wie <code>INT8_MIN</code> oder <code>UINT16_MAX</code>. Siehe dazu auch: [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html Dokumentation der avr-libc: Standard Integer Types].<br />
<br />
= Grundsätzlicher Programmaufbau eines µC-Programms =<br />
<br />
Wir unterscheiden zwischen 2 verschiedenen Methoden, um ein<br />
Mikrocontroller-Programm zu schreiben, und zwar völlig unabhängig davon, in<br />
welcher Programmiersprache das Programm geschrieben wird.<br />
<br />
== Sequentieller Programmablauf ==<br />
<br />
[[Image:Sequentielle Programme.gif|left]]<br />
Bei dieser Programmiertechnik wird eine Endlosschleife programmiert, welche im<br />
Wesentlichen immer den gleichen Aufbau hat. Es wird hier nach dem sogenannten EVA-Prinzip gehandelt. EVA steht für "Eingabe, Verarbeitung, Ausgabe".<br />
{{Absatz}}<br />
<br />
== Interruptgesteuerter Programmablauf ==<br />
<br />
[[Image:Interrupt Programme.gif|left]]<br />
Bei dieser Methode werden beim Programmstart zuerst die gewünschten Interruptquellen aktiviert und dann in eine Endlosschleife gegangen, in welcher Dinge erledigt werden können, welche nicht zeitkritisch sind. Wenn ein Interrupt ausgelöst wird, so wird automatisch die zugeordnete Interruptfunktion ausgeführt.<br />
{{Absatz}}<br />
<br />
= Zugriff auf Register =<br />
<br />
Die AVR-Controller verfügen über eine Vielzahl von Registern. Die meisten<br />
davon sind sogenannte Schreib-/Leseregister. Das heißt, das Programm kann die<br />
Inhalte der Register sowohl auslesen als auch beschreiben.<br />
<br />
Register haben einen besonderen Stellenwert bei den AVR Controllern. Sie dienen dem Zugriff auf die Ports und die Schnittstellen des Controllers. Wir unterscheiden zwischen 8-Bit und 16-Bit Registern. Vorerst behandeln wir die 8-Bit Register.<br />
<br />
Einzelne Register sind bei allen AVRs vorhanden, andere wiederum nur bei bestimmten Typen. So sind beispielsweise die Register, welche für den Zugriff auf den UART notwendig sind, selbstverständlich nur bei denjenigen Modellen vorhanden, welche über einen integrierten Hardware UART bzw. USART verfügen.<br />
<br />
Die Namen der Register sind in den Headerdateien zu den entsprechenden AVR-Typen definiert. Dazu muss man den Namen der controllerspezifischen Headerdatei nicht kennen. Es reicht aus, die allgemeine Headerdatei ''avr/io.h'' einzubinden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
</syntaxhighlight><br />
<br />
Ist im Makefile der MCU-Typ z.&nbsp;B. mit dem Inhalt atmega8 definiert (und wird somit per -mmcu=atmega8 an den Compiler übergeben), wird beim Einlesen der io.h-Datei implizit ("automatisch") auch die iom8.h-Datei mit den Register-Definitionen für den ATmega8 eingelesen.<br />
<br />
<!-- Wohl besser als Anhang - spaeter... --><br />
Intern wird diese "Automatik" wie folgt realisiert: Der Controllertyp wird dem Compiler als Parameter übergeben (vgl. ''avr-gcc -c -mmcu=atmega16 [...]'' im Einführungsbeispiel). Wird ein Makefile nach der WinAVR/mfile-Vorlage verwendet, setzt man die Variable ''MCU'', der Inhalt dieser Variable wird dann an passender Stelle für die Compilerparameter verwendet. Der Compiler definiert intern eine dem mmcu-Parameter zugeordnete "Variable" (genauer: ein Makro) mit dem Namen des Controllers, vorangestelltem ''__AVR_'' und angehängten Unterstrichen (z.&nbsp;B. wird bei ''-mmcu=atmega16'' das Makro ''__AVR_ATmega16__'' definiert). Beim Einbinden der Header-Datei ''avr/io.h'' wird geprüft, ob das jeweilige Makro definiert ist und die zum Controller passende Definitionsdatei eingelesen. Zur Veranschaulichung einige Ausschnitte aus einem Makefile:<br />
<br />
<pre><br />
[...]<br />
# MCU Type ("name") setzen:<br />
MCU = atmega16<br />
[...]<br />
<br />
[...]<br />
## Verwendung des Inhalts von MCU (hier atmega16) fuer die <br />
## Compiler- und Assembler-Parameter<br />
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)<br />
ALL_CPPFLAGS = -mmcu=$(MCU) -I. -x c++ $(CPPFLAGS) $(GENDEPFLAGS)<br />
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)<br />
[...]<br />
<br />
[...]<br />
## Aufruf des Compilers:<br />
## mit den Parametern ($(ALL_CFLAGS) ist -mmcu=$(MCU)[...] = -mmcu=atmega16[...]<br />
$(OBJDIR)/%.o : %.c<br />
@echo<br />
@echo $(MSG_COMPILING) $<<br />
$(CC) -c $(ALL_CFLAGS) $< -o $@ <br />
[...]<br />
</pre><br />
<br />
Da --mmcu=atmega16 übergeben wurde, wird __AVR_ATmega16__ definiert und kann in avr/io.h zur Fallunterscheidung genutzt werden:<br />
<br />
<syntaxhighlight lang="c"><br />
// avr/io.h <br />
// (bei WinAVR-Standardinstallation in C:\WinAVR\avr\include\avr)<br />
[...]<br />
#if defined (__AVR_AT94K__)<br />
# include <avr/ioat94k.h><br />
// [...]<br />
#elif defined (__AVR_ATmega16__)<br />
// da __AVR_ATmega16__ definiert ist, wird avr/iom16.h eingebunden:<br />
# include <avr/iom16.h><br />
// [...]<br />
#else<br />
# if !defined(__COMPILING_AVR_LIBC__)<br />
# warning "device type not defined"<br />
# endif<br />
#endif<br />
</syntaxhighlight><br />
<br />
Die Beispiele in den folgenden Abschnitten demonstrieren den Zugriff auf Register anhand der Register für I/O-Ports (PORTx, DDRx, PINx), die Vorgehensweise ist jedoch für alle Register (z.&nbsp;B. die des UART, ADC, SPI) analog.<br />
<br />
== Schreiben in Register ==<br />
<br />
Zum Schreiben kann man Register einfach wie eine Variable setzen.<ref>In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Schreibzugriff über die Funktion outp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt, outp() ist nicht mehr erforderlich.</ref><br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
/* Setzt das Richtungsregister des Ports A auf 0xff <br />
(alle Pins als Ausgang, vgl. Abschnitt Zugriff auf Ports): */<br />
DDRA = 0xff; <br />
<br />
/* Setzt PortA auf 0x03, Bit 0 und 1 "high", restliche "low": */<br />
PORTA = 0x03; <br />
<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binär 00011111 = Hexadezimal 1F<br />
DDRB = 0x1F; /* direkte Zuweisung - unübersichtlich */<br />
<br />
/* Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit<br />
aber übersichtlicher und selbsterklärend: */<br />
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);<br />
<br />
while (1);<br />
}<br />
</syntaxhighlight><br />
<br />
Die ausführliche Schreibweise sollte bevorzugt verwendet werden, da dadurch die Zuweisungen selbsterklärend sind und somit der Code leichter nachvollzogen werden kann. Atmel verwendet sie auch bei Beispielen in Datenblätten und in den allermeisten Quellcodes zu Application-Notes. Mehr zu der Schreibweise mit "|" und "<<" findet man unter [[Bitmanipulation]].<br />
<br />
Der gcc C-Compiler unterstützt ab Version 4.3.0 Konstanten im Binärformat, z.&nbsp;B. DDRB&nbsp;=&nbsp;0b00011111. Diese Schreibweise ist jedoch nur in GNU-C verfügbar und nicht in ISO-C definiert. Man sollte sie daher nicht verwenden, wenn Code mit anderen ausgetauscht oder mit anderen Compilern bzw. älteren Versionen des gcc genutzt werden soll.<br />
<br />
== Verändern von Registerinhalten ==<br />
<br />
Einzelne Bits setzt und löscht man "Standard-C-konform" mittels logischer (Bit-) Operationen. <br />
<br />
<syntaxhighlight lang="c"><br />
x |= (1 << Bitnummer); // Hiermit wird ein Bit in x gesetzt<br />
x &= ~(1 << Bitnummer); // Hiermit wird ein Bit in x geloescht<br />
</syntaxhighlight><br />
<br />
Es wird jeweils nur der Zustand des angegebenen Bits geändert, der vorherige Zustand der anderen Bits bleibt erhalten. <br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
#define MEINBIT 2<br />
...<br />
PORTA |= (1 << MEINBIT); /* setzt Bit 2 an PortA auf 1 */<br />
PORTA &= ~(1 << MEINBIT); /* loescht Bit 2 an PortA */<br />
</syntaxhighlight><br />
<br />
Mit dieser Methode lassen sich auch mehrere Bits eines Registers gleichzeitig setzen und löschen.<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
DDRA &= ~( (1<<PA0) | (1<<PA3) ); /* PA0 und PA3 als Eingaenge */<br />
PORTA |= ( (1<<PA0) | (1<<PA3) ); /* Interne Pull-Up fuer beide einschalten */<br />
</syntaxhighlight><br />
<br />
Bei bestimmten AVR Registern mit Bits, die durch Beschreiben mit einer logischen 1 gelöscht werden, muss eine absolute Zuweisung benutzt werden. Ein ODER löscht in diesen Registern ALLE gesetzten Bits!<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
TIFR2 = (1<<OCF2A); // Nur Bit OCF2A löschen<br />
</syntaxhighlight><br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind nicht mehr erforderlich.<br />
<br />
Siehe auch:<br />
* [[Bitmanipulation]]<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
<br />
== Lesen aus Registern ==<br />
<br />
Zum Lesen kann man auf Register einfach wie auf eine Variable zugreifen. In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Lesezugriff über die Funktion inp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt und inp() ist nicht mehr erforderlich.<br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdint.h><br />
<br />
uint8_t foo;<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
/* kopiert den Status der Eingabepins an PortB <br />
in die Variable foo: */<br />
foo = PINB; <br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Die Abfrage der Zustände von Bits erfolgt durch Einlesen des gesamten Registerinhalts und ausblenden der Bits deren Zustand nicht von Interesse ist. Einige Beispiele zum Prüfen ob Bits gesetzt oder gelöscht sind:<br />
<br />
<syntaxhighlight lang="c"><br />
#define MEINBIT0 0 <br />
#define MEINBIT2 2<br />
<br />
uint8_t i;<br />
<br />
extern test1();<br />
<br />
// Funkion test1 aufrufen, wenn Bit 0 in Register PINA gesetzt (1) ist<br />
i = PINA; // Inhalt in Arbeitsvariable<br />
i = i & 0x01; // alle Bits bis auf Bit 0 ausblenden (bitweise und)<br />
// falls das Bit gesetzt war, hat i den Inhalt 1<br />
if ( i != 0 ) { // Ergebnis ungleich 0 (wahr)? <br />
test1(); // dann muss Bit 0 in i gesetzt sein -> Funktion aufrufen<br />
}<br />
// verkürzt:<br />
if ( ( PINA & 0x01 ) != 0 ) {<br />
test1();<br />
}<br />
// nochmals verkürzt:<br />
if ( PINA & 0x01 ) {<br />
test1();<br />
}<br />
// mit definierter Bitnummer:<br />
if ( PINA & ( 1 << MEINBIT0 ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und/oder Bit 2 gesetzt ist. (Bit 0 und 2 also Wert 5) <br />
// (Bedenke: Bit 0 hat Wert 1, Bit 1 hat Wert 2 und Bit 2 hat Wert 4)<br />
if ( PINA & 0x05 ) {<br />
test1(); // Vergleich <> 0 (wahr), also mindestens eines der Bits gesetzt<br />
}<br />
// mit definierten Bitnummern:<br />
if ( PINA & ( ( 1 << MEINBIT0 ) | ( 1 << MEINBIT2 ) ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und Bit 2 gesetzt sind<br />
if ( ( PINA & 0x05 ) == 0x05 ) { // nur wahr, wenn beide Bits gesetzt<br />
test1();<br />
}<br />
<br />
// Funktion test2() aufrufen, wenn Bit 0 gelöscht (0) ist<br />
i = PINA; // einlesen in temporäre Variable<br />
i = i & 0x01; // maskieren von Bit 0<br />
if ( i == 0 ) { // Vergleich ist wahr, wenn Bit 0 nicht gesetzt ist<br />
test2();<br />
}<br />
// analog mit not-Operator<br />
if ( !i ) {<br />
test2();<br />
}<br />
// nochmals verkürzt:<br />
if ( !( PINA & 0x01 ) ) {<br />
test2();<br />
}<br />
</syntaxhighlight><br />
<br />
== Warten auf einen bestimmten Zustand ==<br />
<br />
Es gibt in der Bibliothek avr-libc Funktionen, die warten, bis ein bestimmter Zustand eines Bits erreicht ist. Es ist allerdings normalerweise eine eher unschöne Programmiertechnik, da in diesen Funktionen "blockierend" gewartet wird. Der Programmablauf bleibt also an dieser Stelle stehen, bis das maskierte Ereignis erfolgt ist. Setzt man den [[Watchdog]] ein, muss man darauf achten, dass dieser auch noch getriggert wird (Zurücksetzen des Watchdogtimers). <br />
<br />
Die Funktion '''loop_until_bit_is_set''' wartet in einer Schleife, bis das definierte Bit gesetzt ist. Wenn das Bit beim Aufruf der Funktion bereits gesetzt ist, wird die Funktion sofort wieder verlassen. Das niederwertigste Bit hat die Bitnummer 0. <br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 2 (das dritte Bit) in Register PINA gesetzt (1) ist */<br />
<br />
#define WARTEPIN PINA<br />
#define WARTEBIT PA2<br />
<br />
// mit der avr-libc Funktion:<br />
loop_until_bit_is_set(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// _nicht_ ungleich 0 (also 0) ist.<br />
while ( !(WARTEPIN & (1 << WARTEBIT)) ) {}<br />
...<br />
</syntaxhighlight><br />
<br />
<br />
Die Funktion '''loop_until_bit_is_clear''' wartet in einer Schleife, bis das definierte Bit gelöscht ist. Wenn das Bit beim Aufruf der Funktion bereits gelöscht ist, wird die Funktion sofort wieder verlassen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 4 (das fuenfte Bit) in Register PINB geloescht (0) ist */<br />
#define WARTEPIN PINB<br />
#define WARTEBIT PB4<br />
<br />
// avr-libc-Funktion:<br />
loop_until_bit_is_clear(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// gesetzt (1) ist <br />
while ( WARTEPIN & (1<<WARTEBIT) ) {}<br />
...<br />
</syntaxhighlight><br />
<br />
Universeller und auch auf andere Plattformen besser übertragbar ist die Verwendung von C-Standardoperationen.<br />
<br />
Siehe auch: <br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
* [[Bitmanipulation]]<br />
<br />
== 16-Bit Register (ADC, ICR1, OCR1x, TCNT1, UBRR) ==<br />
<br />
Einige der Portregister in den AVR-Controllern sind 16 Bit breit. Im Datenblatt sind diese Register üblicherweise mit dem Suffix "L" (Low-Byte) und "H" (High-Byte) versehen. Die avr-libc definiert zusätzlich die meisten dieser Variablen die Bezeichnung ohne "L" oder "H". Auf diese Register kann dann direkt zugegriffen werden. Dies ist zum Beispiel der Fall für Register wie ADC oder TCNT1.<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
uint16_t foo;<br />
<br />
/* setzt die Wort-Variable foo auf den Wert der letzten AD-Wandlung */<br />
foo = ADC; <br />
</syntaxhighlight><br />
<br />
Bei anderen Registern, wie zum Beispiel Baudraten-Register, liegen High- und Low-Teil nicht direkt nebeneinander im SFR-Bereich, so dass ein 16-Bit Zugriff nicht möglich ist und der Zugriff zusammengebastelt werden muss:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
...<br />
uint16_t baud = F_CPU / (UART_BAUD_RATE * 16L) -1;<br />
<br />
UBRRH = (uint8_t) (baud >> 8);<br />
UBRRL = (uint8_t) baud;<br />
...<br />
</syntaxhighlight><br />
<br />
Bei einigen AVR-Typen wie ATmega8 oder ATmega16 teilen sich UBRRH und UCSRC die gleiche Speicher-Adresse. Damit der AVR trotzdem zwischen den beiden Registern unterscheiden kann, bestimmt das Bit7 (URSEL), welches Register tatsächlich beschrieben werden soll. ''1000 0011'' (0x83) adressiert demnach UCSRC und übergibt den Wert ''3''. Und ''0000 0011'' (0x3) adressiert UBRRH und übergibt ebenfalls den Wert ''3''. <br />
<br />
Speziell bei den 16-Bit-Timern und auch beim ADC ist es bei allen Zugriffen auf Datenregister erforderlich, dass diese Daten synchronisiert sind. Wenn z.&nbsp;B. bei einem 16-Bit-Timer das High-Byte des Zählregisters gelesen wurde und vor dem Lesezugriff auf das Low-Byte ein Überlauf des Low-Bytes stattfindet, erhält man einen völlig unsinnigen Wert. Auch die Compare-Register müssen synchron geschrieben werden, da es ansonsten zu unerwünschten Compare-Ereignissen kommen kann. <br />
<br />
Beim ADC besteht das Problem darin, dass zwischen den Zugriffen auf die beiden Teilregister eine Wandlung beendet werden kann und der ADC ein neues Ergebnis in ADCL und ADCH schreiben will, wodurch High- und Low-Byte nicht zusammenpassen.<br />
<br />
Um diese Datenmüllproduktion zu verhindern, gibt es in beiden Fällen eine Synchronisation, die jeweils durch den Zugriff auf das Low-Byte ausgelöst wird:<br />
* Bei den Timer-Registern (das gilt für alle TCNT-, OCR- und ICR-Register bei den 16-Bit-Timern) wird bei einem ''Lesezugriff'' auf das Low-Byte automatisch das High-Byte in ein temporäres Register, das ansonsten nach außen nicht sichtbar ist, geschoben. Greift man nun ''anschließend'' auf das High-Byte zu, dann wird eben dieses temporäre Register gelesen.<br />
* Bei einem ''Schreibzugriff'' auf eines der genannten Register wird das High-Byte in besagtem temporären Register zwischengespeichert und erst beim Schreiben des Low-Bytes werden ''beide'' gleichzeitig in das eigentliche Register übernommen.<br />
<br />
Das bedeutet für die Reihenfolge:<br />
* Lesezugriff: Erst Low-Byte, dann High-Byte<br />
* Schreibzugriff: Erst High-Byte, dann Low-Byte<br />
<br />
Des weiteren ist zu beachten, dass es für all diese 16-Bit-Register nur ein einziges temporäres Register gibt, so dass das Auftreten eines Interrupts, in dessen Handler ein solches Register manipuliert wird, bei einem durch ihn unterbrochenen Zugriff i.d.R. zu Datenmüll führt. 16-Bit-Zugriffe sind generell nicht atomar! Wenn mit Interrupts gearbeitet wird, kann es erforderlich sein, vor einem solchen Zugriff auf ein 16-Bit-Register die Interrupt-Bearbeitung zu deaktivieren.<br />
<br />
Beim ADC-Datenregister ADCH/ADCL ist die Synchronisierung anders gelöst. Hier wird beim Lesezugriff (ADCH/ADCL sind logischerweise read-only) auf das Low-Byte ADCL beide Teilregister für Zugriffe seitens des ADC so lange gesperrt, bis das High-Byte ADCH ausgelesen wurde. Dadurch kann der ADC nach einem Zugriff auf ADCL keinen neuen Wert in ADCH/ADCL ablegen, bis ADCH gelesen wurde. Ergebnisse von Wandlungen, die zwischen einem Zugriff auf ADCL und ADCH beendet werden, gehen verloren!<br />
<br />
Nach einem Zugriff auf ADCL muss grundsätzlich ADCH gelesen werden!<br />
<br />
In beiden Fällen – also sowohl bei den Timern als auch beim ADC – werden vom C-Compiler 16-Bit Pseudo-Register zur Verfügung gestellt (z.&nbsp;B. TCNT1H/TCNT1L → TCNT1, ADCH/ADCL → ADC bzw. ADCW), bei deren Verwendung der Compiler automatisch die richtige Zugriffsreihenfolge regelt. In C-Programmen sollten grundsätzlich diese 16-Bit-Register verwendet werden! Sollte trotzdem ein Zugriff auf ein Teilregister erforderlich sein, sind obige Angaben zu berücksichtigen.<br />
<br />
Es ist darauf zu achten, dass auch ein Zugriff auf die 16-Bit-Register vom Compiler in zwei 8-Bit-Zugriffe aufgeteilt wird und dementsprechend genauso nicht-atomar ist wie die Einzelzugriffe. Auch hier gilt, dass u.U. die Interrupt-Bearbeitung gesperrt werden muss, um Datenmüll zu vermeiden.<br />
<br />
Beim ADC gibt es für den Fall, dass eine Auflösung von 8 Bit ausreicht, die Möglichkeit, das Ergebnis "linksbündig" in ADCH/ADCL auszurichten, so dass die relevanten 8 MSB in ADCH stehen. In diesem Fall muss bzw. sollte nur ADCH ausgelesen werden.<br />
<br />
ADC und ADCW sind unterschiedliche Bezeichner für das selbe Registerpaar. Üblicherweise kann man in C-Programmen ADC verwenden, was analog zu den anderen 16-Bit-Registern benannt ist. ADCW (ADC Word) existiert nur deshalb, weil die Headerdateien auch für Assembler vorgesehen sind und es bereits einen Assembler-Befehl namens ''adc'' gibt. <br />
<br />
Im Umgang mit 16-Bit Registern siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Related Pages/Frequently Asked Questions/Nr. 8<br />
* Datenblatt Abschnitt ''Accessing 16-bit Registers''<br />
<br />
== IO-Register als Parameter und Variablen ==<br />
<br />
Um Register als Parameter für eigene Funktionen übergeben zu können, muss man sie als einen volatile uint8_t Pointer übergeben. Zum Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <util/delay.h><br />
<br />
uint8_t key_pressed (volatile uint8_t *inputreg, uint8_t inputbit)<br />
{<br />
static uint8_t last_state = 0;<br />
<br />
if (last_state == (*inputreg & (1<<inputbit)))<br />
return 0; /* keine Änderung */<br />
<br />
/* Wenn doch, warten bis etwaiges Prellen vorbei ist: */<br />
_delay_ms(20);<br />
<br />
/* Zustand für nächsten Aufruf merken: */<br />
last_state = *inputreg & (1<<inputbit);<br />
<br />
/* und den entprellten Tastendruck zurückgeben: */<br />
return *inputreg & (1<<inputbit);<br />
}<br />
<br />
/* Beispiel für einen Funktionsaufruf: */<br />
<br />
void foo (void)<br />
{<br />
uint8_t i = key_pressed (&PINB, PB1);<br />
}<br />
</syntaxhighlight><br />
<br />
Ein Aufruf der Funktion mit call by value würde Folgendes bewirken: Beim Funktionseintritt wird nur eine Kopie des momentanen Portzustandes angefertigt, die sich unabhängig vom tatsächlichen Zustand das Ports nicht mehr ändert, womit die Funktion wirkungslos wäre. Die Übergabe eines Zeigers wäre die Lösung, wenn der Compiler nicht optimieren würde. Denn dadurch wird im Programm nicht von der Hardware gelesen, sondern wieder nur von einem Abbild im Speicher. Das Ergebnis wäre das gleiche wie oben. Mit dem Schlüsselwort volatile sagt man nun dem Compiler, dass die entsprechende Variable entweder durch andere Softwareroutinen (Interrupts) oder durch die Hardware verändert werden kann.<br />
<br />
Siehe auch: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass avr-libc FAQ: "How do I pass an IO port as a parameter to a function?"]<br />
<br />
= Zugriff auf IO-Ports =<br />
<br />
Jeder AVR implementiert eine unterschiedliche Menge an GPIO-Registern<br />
(GPIO - General Purpose Input/Output). Diese Register dienen dazu:<br />
* einzustellen welche der Anschlüsse ("Beinchen") des Controllers als Ein- oder Ausgänge dienen<br />
* bei Ausgängen deren Zustand festzulegen<br />
* bei Eingängen deren Zustand zu erfassen<br />
<br />
Mittels GPIO werden digitale Zustände gesetzt und erfasst, d.h. die Spannung an einem Ausgang wird ein- oder ausgeschaltet und an einem Eingang wird erfasst, ob die anliegende Spannung über oder unter einem bestimmten Schwellwert liegt. Im Datenblatt Abschnitt Electrical Characteristics/DC Characteristics finden sich die Spannungswerte (V_OL, V_OH für Ausgänge, V_IL, V_IH für Eingänge).<br />
<br />
Die Verarbeitung von analogen Eingangswerten und die Ausgabe von Analogwerten wird in Kapitel [[AVR-GCC-Tutorial#Analoge_Ein-_und_Ausgabe|Analoge Ein- und Ausgabe]] behandelt.<br />
<br />
Die physischen Ein- und Ausgänge werden bei AVR-Controllern zu logischen Ports gruppiert.<br />
<br />
Alle Ports werden über Register gesteuert. Dazu sind jedem Port 3 Register zugeordnet:<br />
<br />
{| class="wikitable"<br />
|- <br />
! width="10%"| DDRx<br />
| Datenrichtungsregister für Port'''x'''. <br />
'''x''' entspricht '''A''', '''B''', ''' C''' usw. je nach gewünschtem Port. Bit im Register gesetzt (1) für Ausgang, Bit gelöscht (0) für Eingang.<br />
|- <br />
! PINx<br />
| Eingangsadresse für Port'''x'''. <br />
Zustand des Ports. Die Bits in PINx entsprechen dem Zustand der als Eingang definierten Portpins. Bit 1 wenn Pin "high", Bit 0 wenn Portpin low.<br />
|-<br />
! PORTx<br />
| Datenregister für Port'''x'''. <br />
Dieses Register wird verwendet, um die Ausgänge eines Ports anzusteuern. Bei Pins, die mittels DDRx auf Eingang geschaltet wurden, können über PORTx<br />
die internen Pull-Up Widerstände aktiviert oder deaktiviert werden (1 = aktiv).<br />
|}<br />
<br />
Die folgenden Beispiele gehen von einem AVR aus, der sowohl Port A als auch Port B besitzt. Sie müssen für andere AVRs (zum Beispiel ATmega8/48/88/168) entsprechend angepasst werden.<br />
<br />
== Datenrichtung bestimmen ==<br />
<br />
Zuerst muss die Datenrichtung der verwendeten Pins bestimmt werden. Um dies zu erreichen, wird das Datenrichtungsregister des entsprechenden Ports beschrieben.<br />
<br />
Für jeden Pin, der als Ausgang verwendet werden soll, muss dabei das<br />
entsprechende Bit auf dem Port gesetzt werden. Soll der Pin als Eingang<br />
verwendet werden, muss das entsprechende Bit gelöscht sein.<br />
<br />
Beispiel:<br />
Angenommen am Port B sollen die Pins 0 bis 4 als Ausgänge definiert werden, die noch verbleibenden Pins 5 bis 7 sollen als Eingänge fungieren. Dazu ist es daher notwendig, im für das Port B zuständigen Datenrichtungsregister DDRB folgende Bitkonfiguration einzutragen<br />
<br />
+---+---+---+---+---+---+---+---+<br />
| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |<br />
+---+---+---+---+---+---+---+---+<br />
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br />
<br />
In C liest sich das dann so:<br />
<br />
<syntaxhighlight lang="c"><br />
// in io.h wird u.a. DDRB definiert:<br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binaer 00011111 = Hexadezimal 1F<br />
// direkte Zuweisung - standardkonform */<br />
DDRB = 0x1F; /* <br />
<br />
// Uebersichtliche Alternative - Binaerschreibweise, aber kein ISO-C<br />
DDRB = 0b00011111;<br />
<br />
// Ausfuehrliche Schreibweise: identische Funktionalitaet, mehr Tipparbeit<br />
// aber uebersichtlicher und selbsterklaerend:<br />
DDRB |= (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4); <br />
</syntaxhighlight><br />
<br />
Die Pins 5 bis 7 werden (da 0) als Eingänge geschaltet. Weitere Beispiele:<br />
<br />
<syntaxhighlight lang="c"><br />
// Alle Pins des Ports B als Ausgang definieren:<br />
DDRB = 0xff; <br />
// Pin0 wieder auf Eingang und andere im urspruenglichen Zustand belassen:<br />
DDRB &= ~(1 << DDB0);<br />
// Pin 3 und 4 auf Eingang und andere im urspruenglichen Zustand belassen:<br />
DDRB &= ~((1 << DDB3) | (1 << DDB4));<br />
// Pin 0 und 3 wieder auf Ausgang und andere im ursprünglichen Zustand belassen:<br />
DDRB |= (1 << DDB0) | (1 << DDB3);<br />
// Alle Pins auf Eingang:<br />
DDRB = 0x00;<br />
</syntaxhighlight><br />
<br />
== Vordefinierte Bitnummern für I/O-Register ==<br />
<br />
Die Bitnummern (z.&nbsp;B. PCx, PINCx und DDCx für den Port C) sind in den io*.h-Dateien der avr-libc definiert und dienen lediglich der besseren Lesbarkeit. Man muss diese Definitionen nicht verwenden oder kann auch einfach "immer" PAx, PBx, PCx usw. nutzen, auch wenn der Zugriff auf Bits in DDRx- oder PINx-Registern erfolgt. Für den Compiler sind die Ausdrücke (1<<PC7), (1<<DDC7) und (1<<PINC7) identisch zu (1<<7) (genauer: der Präprozessor ersetzt die Ausdrücke (1<<PC7),... zu (1<<7)). Ein Ausschnitt der Definitionen für Port C eines ATmega32 aus der iom32.h-Datei zur Verdeutlichung (analog für die weiteren Ports):<br />
<br />
<syntaxhighlight lang="c"><br />
...<br />
/* PORTC */<br />
#define PC7 7<br />
#define PC6 6<br />
#define PC5 5<br />
#define PC4 4<br />
#define PC3 3<br />
#define PC2 2<br />
#define PC1 1<br />
#define PC0 0<br />
<br />
/* DDRC */<br />
#define DDC7 7<br />
#define DDC6 6<br />
#define DDC5 5<br />
#define DDC4 4<br />
#define DDC3 3<br />
#define DDC2 2<br />
#define DDC1 1<br />
#define DDC0 0<br />
<br />
/* PINC */<br />
#define PINC7 7<br />
#define PINC6 6<br />
#define PINC5 5<br />
#define PINC4 4<br />
#define PINC3 3<br />
#define PINC2 2<br />
#define PINC1 1<br />
#define PINC0 0<br />
</syntaxhighlight><br />
<br />
<br />
== Digitale Signale ==<br />
<br />
Am einfachsten ist es, digitale Signale mit dem Mikrocontroller zu erfassen bzw. auszugeben.<br />
<br />
== Ausgänge ==<br />
Will man als Ausgang definierte Pins (entsprechende DDRx-Bits = 1) auf Logisch 1 setzen, setzt man die entsprechenden Bits im Portregister.<br />
<br />
Mit dem Befehl<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB = 0x04; /* besser PORTB=(1<<PB2) */<br />
<br />
// Uebersichtliche Alternative - Binaerschreibweise<br />
PORTB = 0b00000100; /* direkte Zuweisung - uebersichtlich */<br />
<br />
</syntaxhighlight><br />
wird also der Ausgang an Pin PB2 gesetzt (Beachte, dass die Bits immer ''von 0 an'' gezählt werden, das niederwertigste Bit ist also Bitnummer 0 und nicht etwa Bitnummer 1).<br />
<br />
Man beachte, dass bei der Zuweisung mittels '''=''' immer alle Pins gleichzeitig angegeben werden. Man sollte also, wenn nur bestimmte Ausgänge geschaltet werden sollen, zuerst den aktuellen Wert des Ports einlesen und das Bit des gewünschten Ports in diesen Wert einfließen lassen. Will man also nur den dritten Pin (Bit Nr. 2) an Port B auf "high" setzen und den Status der anderen Ausgänge unverändert lassen, nutze man diese Form:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB = PORTB | 0x04; /* besser: PORTB = PORTB | ( 1<<PB2 ) */<br />
/* vereinfacht durch Nutzung des |= Operators : */<br />
PORTB |= (1<<PB2);<br />
<br />
/* auch mehrere "gleichzeitig": */<br />
PORTB |= (1<<PB4) | (1<<PB5); /* Pins PB4 und PB5 "high" */<br />
</syntaxhighlight><br />
<br />
"Ausschalten", also Ausgänge auf "low" setzen, erfolgt analog:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB &= ~(1<<PB2); /* loescht Bit 2 in PORTB und setzt damit Pin PB2 auf low */ <br />
PORTB &= ~( (1<<PB4) | (1<<PB5) ); /* Pin PB4 und Pin PB5 "low" */<br />
</syntaxhighlight><br />
Siehe auch [[Bitmanipulation]]<br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind in aktuellen Versionen der avr-libc nicht mehr enthalten und auch nicht mehr erforderlich.<br />
<br />
''Falls der Anfangszustand von Ausgängen kritisch ist, muss die Reihenfolge beachtet werden, mit der die Datenrichtung (DDRx) eingestellt und der Ausgabewert (PORTx) gesetzt wird:''<br />
<br />
Für Ausgangspins, die mit Anfangswert "high" initialisiert werden sollen:<br />
* zuerst die Bits im PORTx-Register setzen<br />
* anschließend die Datenrichtung auf Ausgang stellen<br />
<br />
Daraus ergibt sich die Abfolge für einen Pin, der bisher als Eingang mit abgeschaltetem Pull-Up konfiguriert war:<br />
* setze PORTx: interner Pull-Up aktiv<br />
* setze DDRx: Ausgang ("high")<br />
<br />
Bei der Reihenfolge erst DDRx und dann PORTx kann es zu einem kurzen "low-Puls" kommen, der auch externe Pull-Up-Widerstände "überstimmt". Die (ungünstige) Abfolge: Eingang -> setze DDRx: Ausgang (auf "low", da PORTx nach Reset 0) -> setze PORTx: Ausgang auf high. Vergleiche dazu auch das Datenblatt Abschnitt ''Configuring the Pin''.<br />
<br />
== Eingänge (Wie kommen Signale in den &micro;C) ==<br />
<br />
Die digitalen Eingangssignale können auf verschiedene Arten zu unserer Logik gelangen.<br />
<br />
=== Signalkopplung ===<br />
<br />
Am einfachsten ist es, wenn die Signale direkt aus einer anderen digitalen Schaltung übernommen werden können. Hat der Ausgang der entsprechenden Schaltung TTL-Pegel dann können wir sogar direkt den Ausgang der Schaltung mit einem Eingangspin von unserem Controller verbinden.<br />
<br />
Hat der Ausgang der anderen Schaltung keinen TTL-Pegel so müssen wir den Pegel über entsprechende Hardware (z.&nbsp;B. Optokoppler, [[Widerstand#Spannungsteiler|Spannungsteiler]], "Levelshifter" aka [[Pegelwandler]]) anpassen.<br />
<br />
Die Masse der beiden Schaltungen muss selbstverständlich miteinander verbunden werden. Der Software selber ist es natürlich letztendlich egal, wie das Signal eingespeist wird. Wir können ja ohnehin lediglich prüfen, ob an einem Pin unseres Controllers eine logische 1 (Spannung größer ca. 0,7*Vcc) oder eine logische 0 (Spannung kleiner ca. 0,2*Vcc) anliegt. Detaillierte Informationen darüber, ab welcher Spannung ein Eingang als 0 ("low") bzw. 1 ("high") erkannt wird, liefert die Tabelle DC Characteristics im Datenblatt des genutzten Controllers.<br />
<br />
{| class="wikitable" style="text-align:center; width:20em"<br />
|+ '''Logikpegel'''<br />
|-<br />
! VCC [V]<br />
! Low [V]<br />
! High [V]<br />
|-<br />
! 5<br />
| 1,0 || 3,5<br />
|-<br />
! 3,3<br />
| 0,66 || 2,3<br />
|-<br />
! 1,8<br />
| 0,36 || 1,26 <br />
|}<br />
<br />
Die Abfrage der Zustände der Portpins erfolgt direkt über den Registernamen.<br />
<br />
{{Warnung|Dabei ist wichtig, zur Abfrage der Eingänge ''nicht'' etwa Portregister '''PORTx''' zu verwenden, sondern Eingangsregister '''PINx'''. Ansonsten liest man nicht den Zustand der Eingänge, sondern den Status der internen Pull-Up-Widerstände. Die Abfrage der Pinzustände über PORTx statt PINx ist ein häufiger Fehler beim AVR-"Erstkontakt".}}<br />
<br />
Will man also die aktuellen Signalzustände von Port D abfragen und in eine Variable namens bPortD abspeichern, schreibt man folgende Befehlszeilen:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdint.h><br />
...<br />
uint8_t bPortD;<br />
...<br />
bPortD = PIND;<br />
...<br />
</syntaxhighlight><br />
<br />
Mit den C-Bitoperationen kann man den Status der Bits abfragen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
/* Fuehre Aktion aus, wenn Bit Nr. 1 (das "zweite" Bit) in PINC gesetzt (1) ist */<br />
if ( PINC & (1<<PINC1) ) {<br />
/* Aktion */<br />
}<br />
<br />
/* Fuehre Aktion aus, wenn Bit Nr. 2 (das "dritte" Bit) in PINB geloescht (0) ist */<br />
if ( !(PINB & (1<<PINB2)) ) {<br />
/* Aktion */<br />
}<br />
...<br />
</syntaxhighlight><br />
Siehe auch [[Bitmanipulation#Bits_prüfen]]<br />
<br />
=== Interne Pull-Up Widerstände ===<br />
<br />
Portpins für Ein- und Ausgänge (GPIO) eines AVR verfügen über zuschaltbare interne Pull-Up Widerstände (nominal mehrere 10kOhm, z.&nbsp;B. ATmega16 20-50kOhm). Diese können in vielen Fällen statt externer Widerstände genutzt werden.<br />
<br />
Die internen Pull-Up Widerstände von Vcc zu den einzelnen Portpins werden über das Register ''' PORTx''' aktiviert bzw. deaktiviert, wenn ein Pin als ''' Eingang''' geschaltet ist.<br />
<br />
Wird der Wert des entsprechenden Portpins auf 1 gesetzt, so ist der Pull-Up Widerstand aktiviert. Bei einem Wert von 0 ist der Pull-Up Widerstand nicht aktiv. Man sollte jeweils entweder den internen oder einen externen Pull-Up Widerstand verwenden, aber nicht beide zusammen.<br />
<br />
Im Beispiel werden alle Pins des Ports D als Eingänge geschaltet und alle Pull-Up Widerstände aktiviert. Weiterhin wird Pin PC7 als Eingang geschaltet und dessen interner Pull-Up Widerstand aktiviert, ohne die Einstellungen für die anderen Portpins (PC0-PC6) zu verändern.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
DDRD = 0x00; /* alle Pins von Port D als Eingang */<br />
PORTD = 0xff; /* interne Pull-Ups an allen Port-Pins aktivieren */<br />
...<br />
DDRC &= ~(1<<PC7); /* Pin PC7 als Eingang */<br />
PORTC |= (1<<PC7); /* internen Pull-Up an PC7 aktivieren */<br />
</syntaxhighlight><br />
<br />
=== Taster und Schalter ===<br />
<br />
Der Anschluss mechanischer Kontakte an den Mikrocontroller, ist zwischen zwei unterschiedliche Methoden zu unterscheiden: ''Active Low'' und ''Active High''.<br />
<br />
<gallery widths="300" heights="300" caption="Anschluss mechanischer Kontakte an einen µC"><br />
Image:Active Low.gif|'''Active Low:''' Bei dieser Methode wird der Kontakt zwischen den Eingangspin des Controllers und Masse geschaltet. Damit bei offenem Schalter der Controller kein undefiniertes Signal bekommt, wird zwischen die Versorgungsspannung und den Eingangspin ein sogenannter '''Pull-Up''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffnetem Schalter auf logisch 1 zu ziehen.<br />
Image:Active High.gif|'''Active High:''' Hier wird der Kontakt zwischen die Versorgungsspannung und den Eingangspin geschaltet. Damit bei offener Schalterstellung kein undefiniertes Signal am Controller ansteht, wird zwischen den Eingangspin und die Masse ein '''Pull-Down''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffneter Schalterstellung auf logisch 0 zu halten. <br />
</gallery><br />
<br />
Der Widerstandswert von Pull-Up- und Pull-Down-Widerständen ist an sich nicht kritisch. Wird er allerdings zu hoch gewählt, ist die Wirkung eventuell nicht gegeben. Als üblicher Wert haben sich 10 kOhm eingebürgert. Die AVRs verfügen an den meisten Pins über zuschaltbare interne Pull-Up Widerstände (vgl. Abschnitt [[AVR-GCC-Tutorial#Interne Pull-Up Widerstände|Interne Pull-Up Widerstände]]), welche insbesondere wie hier bei Tastern und ähnlichen Bauteilen (z.&nbsp;B. Drehgebern) statt externer Bauteile verwendet werden können. Interne Pull-Down-Widerstand sind nicht verfügbar und müssen daher in Form zusätzlicher Bauteile in die Schaltung eingefügt werden.<br />
<br />
==== Taster entprellen ====<br />
<br />
Siehe: ''[[Entprellung#Warteschleifen-Verfahren|Entprellung: Warteschleifen-Verfahren]]<br />
<br />
= Warteschleifen (delay.h) =<br />
<br />
Der Programmablauf kann verschiedene Arten von Wartefunktionen erfordern:<br />
<br />
* Warten im Sinn von Zeitvertrödeln<br />
* Warten auf einen bestimmten Zustand an den I/O-Pins<br />
* Warten auf einen bestimmten Zeitpunkt (siehe Timer)<br />
* Warten auf einen bestimmten Zählerstand (siehe Counter)<br />
<br />
Der einfachste Fall, das Zeitvertrödeln, kann in vielen Fällen und mit großer Genauigkeit anhand der avr-libc Bibliotheksfunktionen _delay_ms() und _delay_us() erledigt werden. Die Bibliotheksfunktionen sind einfachen Zählschleifen (Warteschleifen) vorzuziehen, da leere Zählschleifen ohne besondere Vorkehrungen sonst bei eingeschalteter Optimierung vom avr-gcc-Compiler wegoptimiert werden. Weiterhin sind die Bibliotheksfunktionen bereits darauf vorbereitet, die in F_CPU definierte Taktfrequenz zu verwenden. Außerdem sind die Funktionen der Bibliothek wirklich getestet.<br />
<br />
Einfach!? Schon, aber während gewartet wird, macht der µC nichts anderes mehr (abgesehen von möglicherweise auftretenden Interrupts, falls welche aktiviert sind). Die Wartefunktion blockiert den Programmablauf. Möchte man einerseits warten, um z.&nbsp;B. eine LED blinken zu lassen und gleichzeitig andere Aktionen ausführen z.&nbsp;B. weitere LED bedienen, sollten die Timer/Counter des AVR verwendet werden, siehe Artikel [[Multitasking]].<br />
<br />
Die Bibliotheksfunktionen funktionieren allerdings nur dann korrekt, wenn sie mit zur Übersetzungszeit (beim Compilieren) bekannten konstanten Werten aufgerufen werden. Der Quellcode muss mit eingeschalteter Optimierung übersetzt werden, sonst wird sehr viel Maschinencode erzeugt, und die Wartezeiten stimmen nicht mehr mit dem Parameter überein.<br />
<br />
Eine weitere Einschränkung liegt darin, daß sie möglicherweise länger warten, als erwartet, nämlich in dem Fall, daß Interrupts auftreten und die _delay...()-Funktion unterbrechen. Genau genommen warten diese nämlich nicht eine bestimmte Zeit, sondern verbrauchen eine bestimmte Anzahl von Prozessortakten. Die wiederum ist so bemessen, daß ohne Unterbrechung durch Interrupts die gewünschte Wartezeit erreicht wird.<br />
Wird das Warten aber durch eine oder mehrere ISR unterbrochen, die zusammen 1% Prozessorzeit verbrauchen, dann dauert das Warten etwa 1% länger. Bei 50% Last durch die ISR dauert das Warten doppelt solange wie gewünscht, bei 90% zehnmal solange...<br />
<br />
Abhängig von der Version der Bibliothek verhalten sich die Bibliotheksfunktionen etwas unterschiedlich.<br />
<br />
== avr-libc Versionen bis 1.6 ==<br />
<br />
Die Wartezeit der Funktion _delay_ms() ist auf 262,14ms/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 13,1ms warten. Die Wartezeit der Funktion _delay_us() ist auf 768us/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 38,4µs warten. Längere Wartezeiten müssen dann über einen mehrfachen Aufruf in einer Schleife gelöst werden.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.&nbsp;B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h> /* in älteren avr-libc Versionen <avr/delay.h> */ <br />
<br />
/*<br />
lange, variable Verzögerungszeit, Einheit in Millisekunden<br />
<br />
Die maximale Zeit pro Funktionsaufruf ist begrenzt auf <br />
262.14 ms / F_CPU in MHz (im Beispiel: <br />
262.1 / 3.6864 = max. 71 ms) <br />
<br />
Daher wird die kleine Warteschleife mehrfach aufgerufen,<br />
um auf eine längere Wartezeit zu kommen. Die zusätzliche <br />
Prüfung der Schleifenbedingung lässt die Wartezeit geringfügig<br />
ungenau werden (macht hier vielleicht 2-3ms aus).<br />
*/<br />
<br />
void long_delay(uint16_t ms)<br />
{<br />
for(; ms>0; ms--) _delay_ms(1);<br />
}<br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) // Endlosschleife<br />
{ <br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.&nbsp;B. angeschlossene LED<br />
long_delay(1000); // Eine Sekunde warten...<br />
}<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
== avr-libc Versionen ab 1.7 ==<br />
<br />
_delay_ms() kann mit einem Argument bis 6553,5 ms (= 6,5535 Sekunden) benutzt werden. Es ist nicht möglich, eine Variable als Argument zu übergeben. Wird die früher gültige Grenze von 262,14 ms/F_CPU (in MHz) überschritten, so arbeitet _delay_ms() einfach etwas ungenauer und zählt nur noch mit einer Auflösung von 1/10 ms. Eine Verzögerung von 1000,10 ms ließe sich nicht mehr von einer von 1000,19 ms unterscheiden. Ein Verlust, der sich im Allgemeinen verschmerzen lässt. Dem Programmierer wird keine Rückmeldung gegeben, dass die Funktion ggf. gröber arbeitet, d.h. wenn es darauf ankommt, bitte den Parameter wie bisher geschickt wählen.<br />
<br />
Die Funktion _delay_us() wurde ebenfalls erweitert. Wenn deren maximal als genau behandelbares Argument überschritten wird, benutzt diese intern _delay_ms(). Damit gelten in diesem Fall die _delay_ms() Einschränkungen.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus, avr-libc ab Version 1.6<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h><br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) { // Endlosschleife<br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED<br />
_delay_ms(1000); // Eine Sekunde +/-1/10000 Sekunde warten...<br />
// funktioniert nicht mit Bibliotheken vor 1.6<br />
<br />
}<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
Die _delay_ms() und die _delay_us aus '''avr-libc 1.7.0''' sind fehlerhaft. _delay_ms () läuft 4x schneller als erwartet. Abhilfe ist eine korrigierte Includedatei: [http://www.mikrocontroller.net/topic/196738#1943039]<br />
<br />
= Programmieren mit Interrupts =<br />
<br />
<div style="float:right; margin:2em;"><br />
[[Image:Interrupt Programme.gif]]<br />
</div><br />
Nachdem wir nun alles Wissenswerte für die serielle Programmerstellung<br />
gelernt haben nehmen wir jetzt ein völlig anderes Thema in Angriff, nämlich<br />
die Programmierung unter Zuhilfenahme der Interrupts des AVR.<br />
<br />
Tritt ein Interrupt auf, unterbricht (engl. interrupts) der Controller die Verarbeitung des Hauptprogramms und verzweigt zu einer Interruptroutine. Das Hauptprogramm wird also beim Eintreffen eines Interrupts unterbrochen, die Interruptroutine ausgeführt und danach erst wieder das Hauptprogramm an der Unterbrechungsstelle fortgesetzt (vgl. die Abbildung).<br />
<br />
Um Interrupts verarbeiten zu können, ist folgendes zu beachten:<br />
<br />
* Für jede aktivierte Interruptquelle ist eine Funktion zu programmieren, in der die beim Auftreten des jeweiligen Interrupts erforderlichen Verarbeitungsschritte enthalten sind. Für diese Funktion existieren verschiedene Bezeichnungen. Üblich sind die englischen Begriffe Interrupt-Handler oder Interrupt-Service-Routinen (ISR), man findet aber auch die Bezeichnungen Interruptverarbeitungs- oder -behandlungsroutine oder auch kurz Interruptroutine. Zum Beispiel wird üblicherweise in der ISR zur Verarbeitung des Empfangsinterrupts eines UARTs (UART-RX Interrupt) das empfangene Zeichen in einen Zwischenspeicher (FIFO-Buffer) kopiert, dessen Inhalt später von anderen Programmteilen geleert wird. Sofern der Zwischenspeicher ausreichend groß ist, geht also kein Zeichen verloren, auch wenn im Hauptprogramm zeitintensive Operationen durchgeführt werden.<br />
* Die benötigten Interrupts sind in den jeweiligen Funktionsbausteinen einzuschalten. Dies erfolgt über das jeweilige Aktivierungsbit (Interrupt Enable) in einem der Hardwareregister (z.B. RX(Complete)Interrupt Enable eines UARTs)<br />
* Sämtliche Interrupts werden über einen weiteren globalen Schalter aktiviert und deaktiviert. Zur Verarbeitung der Interrupts ist dieser Schalter zu aktivieren (sei(), siehe unten).<br />
<br />
Alle Punkte sind zu beachten. Fehlt z.B. die globale Aktivierung, werden Interruptroutinen auch dann nicht aufgerufen, wenn sie im Funktionsbaustein eingeschaltet sind und eine Behandlungsroutine verhanden ist.<br />
<br />
Siehe auch<br />
<br />
* [http://www.mikrocontroller.net/forum/read-1-235092.html#new Ausführlicher Thread im Forum]<br />
* Artikel [[Interrupt]]<br />
* Artikel [[Multitasking]]<br />
{{Clear}}<br />
<br />
== Anforderungen an Interrupt-Routinen ==<br />
<br />
Um unliebsamen Überraschungen vorzubeugen, sollten einige Grundregeln bei der Implementierung der Interruptroutinen beachtet werden. Interruptroutinen sollten möglichst kurz und schnell abarbeitbar sein, daraus folgt:<br />
<br />
* Keine umfangreichen Berechnungen innerhalb der Interruptroutine. (*)<br />
* Keine langen Programmschleifen.<br />
* Obwohl es möglich ist, während der Abarbeitung einer Interruptroutine andere oder sogar den gleichen Interrupt wieder zuzulassen, wird davon ohne genaue Kenntnis der internen Abläufe dringend abgeraten.<br />
<br />
Interruptroutinen (ISRs) sollten also möglichst kurz sein und keine Schleifen mit vielen Durchläufen enthalten. Längere Operationen können meist in einen "Interrupt-Teil" in einer ISR und einen "Arbeitsteil" im Hauptprogramm aufgetrennt werden. Z.B. Speichern des Zustands aller Eingänge im EEPROM in bestimmten Zeitabständen: ISR-Teil: Zeitvergleich (Timer,RTC) mit Logzeit/-intervall. Bei Übereinstimmung ein globales Flag setzen (volatile bei Flag-Deklaration nicht vergessen, s.u.). Dann im Hauptprogramm prüfen, ob das Flag gesetzt ist. Wenn ja: die Daten im EEPROM ablegen und Flag löschen.<br />
<br />
(*)<br />
Hinweis: <br />
Es gibt allerdings die seltene Situation, dass man gerade eingelesene<br />
ADC-Werte sofort verarbeiten muss. Besonders dann, wenn man mehrere Werte sehr<br />
schnell hintereinander bekommt. Dann bleibt einem nichts anderes übrig, als die<br />
Werte noch in der ISR zu verarbeiten. Kommt aber sehr selten vor und sollte<br />
durch geeignete Wahl des Systemtaktes bzw. Auswahl des Controllers vermieden werden!<br />
<br />
== Interrupt-Quellen ==<br />
<br />
Die folgenden Ereignisse können einen Interrupt auf einem AVR AT90S2313 auslösen, wobei die Reihenfolge der Auflistung auch die Priorität der Interrupts aufzeigt.<br />
<br />
* Reset<br />
* Externer Interrupt 0<br />
* Externer Interrupt 1<br />
* Timer/Counter 1 Capture Ereignis<br />
* Timer/Counter 1 Compare Match<br />
* Timer/Counter 1 Überlauf<br />
* Timer/Counter 0 Überlauf<br />
* UART Zeichen empfangen<br />
* UART Datenregister leer<br />
* UART Zeichen gesendet<br />
* Analoger Komparator<br />
<br />
Die Anzahl der möglichen Interruptquellen variiert zwischen den verschiedenen Microcontroller-Typen. Im Zweifel hilft ein Blick ins Datenblatt ("Interrupt Vectors").<br />
<br />
== Register ==<br />
<br />
Der AT90S2313 verfügt über 2 Register die mit den<br />
Interrupts zusammenhängen.<br />
<br />
{| class="wikitable"<br />
|- <br />
!width="10%"| GIMSK<br />
| '''G'''eneral '''I'''nterrupt '''M'''a'''sk''' Register.<br /><br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit <br />
| 7 || 6|| 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INT1''' || '''INT0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INT1''' (External '''Int'''errupt Request '''1''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT1'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
'''INT0''' (External '''Int'''errupt Request '''0''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT0'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
|- <br />
! GIFR<br />
| '''G'''eneral '''I'''nterrupt '''F'''lag '''R'''egister.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INTF1''' || '''INTF0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INTF1''' (External '''Int'''errupt Flag '''1''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT1'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
<br />
'''INTF0''' (External '''Int'''errupt Flag '''0''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT0'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
|- <br />
! MCUCR<br />
| '''MCU''' '''C'''ontrol '''R'''egister.<br />
<br />
Das MCU Control Register enthält Kontrollbits für allgemeine MCU-Funktionen.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''-'''|| '''-'''|| '''SE'''|| '''SM'''|| '''ISC11'''|| '''ISC10'''|| '''ISC01'''|| '''ISC00'''<br />
|- <br />
! R/W<br />
| R || R || R/W || R/W || R/W || R/W || R/W || R/W<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
<br />
|}<br />
<br />
'''SE''' ('''S'''leep '''E'''nable)<br />
:Dieses Bit muss gesetzt sein, um den Controller mit dem '''SLEEP'''-Befehl in den Schlafzustand versetzen zu können.<br />
:Um den Schlafmodus nicht irrtümlich einzuschalten, wird empfohlen, das Bit erst unmittelbar vor Ausführung des '''SLEEP'''-Befehls zu setzen.<br />
<br />
'''SM''' ('''S'''leep '''M'''ode)<br />
:Dieses Bit bestimmt über den Schlafmodus.<br />
:Ist das Bit gelöscht, so wird der '''Idle'''-Modus ausgeführt. Ist das Bit gesetzt, so wird der '''Power-Down'''-Modus ausgeführt. (für andere AVR Controller siehe Abschnitt "Sleep-Mode")<br />
<br />
'''ISC11''', '''ISC10''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''1''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT1'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
!width="10%"| ISC11 ||width="10%"| ISC10 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT1''' erzeugt einen Interrupt.<br />
<br />
Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|}<br />
<br />
'''ISC01''', '''ISC00''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''0''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT0'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
!width="10%"| ISC01 ||width="10%"| ISC00 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT0''' erzeugt einen Interrupt.<br />
<br />
Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|}<br />
<br />
|}<br />
<br />
== Allgemeines über die Interrupt-Abarbeitung ==<br />
<br />
Wenn ein Interrupt eintrifft, wird automatisch das '''Global Interrupt Enable''' Bit im Status Register '''SREG''' gelöscht und alle weiteren Interrupts unterbunden. Dieses wird automatisch wieder gesetzt, wenn die Interruptroutine beendet wird. Wenn in der Zwischenzeit weitere Interrupts eintreffen, werden die zugehörigen Interrupt-Bits gesetzt und die Interrupts bei Beendigung der laufenden Interrupt-Routine in der Reihenfolge ihrer Priorität ausgeführt. Dies kann<br />
eigentlich nur dann zu Problemen führen, wenn ein hoch priorisierter Interrupt ständig und in kurzer Folge auftritt. Dieser sperrt dann möglicherweise alle anderen Interrupts mit niedrigerer Priorität. Dies ist einer der Gründe, weshalb die Interrupt-Routinen sehr kurz gehalten werden sollen. Es ist möglich das GIE-Bit in der ISR zu setzen und so schon wieder weitere Interrupts zuzulassen - allerdings sollte man damit vorsichtig sein und genau wissen was man damit macht. Kritisch wird es vor allem wenn der gleiche Interrupt noch einmal kommt, bevor die ISR abgearbeitet ist. <br />
<br />
<!-- === Das Status-Register ===<br />
<br />
Es gilt auch zu beachten, dass das Status-Register während der Abarbeitung einer Interruptroutine nicht automatisch gesichert wird. Falls notwendig, muss dies vom Programmierer selber vorgesehen werden. --><br />
<br />
== Interrupts mit avr-gcc ==<br />
<br />
<!-- ''Anmerkung eines Nutzers: Ich habe mir das Thema hier angearbeitet und hatte am Anfang starke Probleme: Jeder Interrupt muss nochmals einzeln aktiviert werden. Es reicht nicht nur per ''sei()'' die Interrupts global zu aktiveren.'' - mthomas: Hoffentlich duch die modifizerte Einleitung etwas offensichtlicher erläutert. Ansonsten bitte per Eintrag auf die Diskussionseite nochmals melden) --> <br />
<!-- Selbstverständlich können alle interruptspezifischen Registerzugriffe wie gewohnt über I/O-Adressierung vorgenommen werden. Etwas einfacher geht es jedoch, wenn wir die vom Compiler zur Verfügung gestellten Mittel einsetzen.--><br />
Funktionen zur Interrupt-Verarbeitung werden in den Includedateien ''interrupt.h'' der avr-libc zur Verfügung gestellt (bei älterem Quellcode zusätzlich ''signal.h'').<br />
<br />
<syntaxhighlight lang="c"><br />
// fuer sei(), cli() und ISR():<br />
#include <avr/interrupt.h><br />
</syntaxhighlight><br />
<br />
Das Makro '''sei()''' schaltet die Interrupts ein. Eigentlich wird nichts anderes gemacht, als das '''Global Interrupt Enable''' Bit im Status Register gesetzt.<br />
<br />
<syntaxhighlight lang="c"><br />
sei();<br />
</syntaxhighlight><br />
<br />
Das Makro '''cli()''' schaltet die Interrupts aus, oder anders gesagt, das '''Global Interrupt Enable''' Bit im Status Register wird gelöscht.<br />
<br />
<syntaxhighlight lang="c"><br />
cli();<br />
</syntaxhighlight><br />
<br />
Oft steht man vor der Aufgabe, dass eine Codesequenz nicht unterbrochen werden darf. Es liegt dann nahe, zu Beginn dieser Sequenz ein cli() und am Ende ein sei() einzufügen. Dies ist jedoch ungünstig, wenn die Interrupts vor Aufruf der Sequenz deaktiviert waren und danach auch weiterhin deaktiviert bleiben sollen. Ein sei() würde ungeachtet des vorherigen Zustands die Interrupts aktivieren, was zu unerwünschten Seiteneffekten führen kann. Die aus dem folgenden Beispiel ersichtliche Vorgehensweise ist in solchen Fällen vorzuziehen:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <inttypes.h><br />
<br />
//...<br />
<br />
void NichtUnterbrechenBitte(void)<br />
{<br />
uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister<br />
<br />
tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) sichern<br />
cli(); // Interrupts global deaktivieren<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
/* Beispiel Anfang<br />
JTAG-Interface eines ATmega16 per Software deaktivieren <br />
und damit die JTAG-Pins an PORTC für "general I/O" nutzbar machen<br />
ohne die JTAG-Fuse-Bit zu aendern. Dazu ist eine "timed sequence"<br />
einzuhalten (vgl Datenblatt ATmega16, Stand 10/04, S. 229): <br />
Das JTD-Bit muss zweimal innerhalb von 4 Taktzyklen geschrieben <br />
werden. Ein Interrupt zwischen den beiden Schreibzugriffen wuerde <br />
die erforderliche Sequenz "brechen", das JTAG-Interface bliebe<br />
weiterhin aktiv und die IO-Pins weiterhin für JTAG reserviert. */<br />
<br />
MCUCSR |= (1<<JTD);<br />
MCUCSR |= (1<<JTD); // 2 mal in Folge ,vgl. Datenblatt fuer mehr Information<br />
<br />
/* Beispiel Ende */<br />
<br />
SREG = tmp_sreg; // Status-Register wieder herstellen <br />
// somit auch das I-Flag auf gesicherten Zustand setzen<br />
}<br />
<br />
void NichtSoGut(void)<br />
{<br />
cli();<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
sei();<br />
}<br />
<br />
<br />
int main(void)<br />
{<br />
//...<br />
<br />
cli(); <br />
// Interrupts global deaktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// auch nach Aufruf der Funktion deaktiviert<br />
<br />
sei();<br />
// Interrupts global aktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// weiterhin aktiviert<br />
//...<br />
<br />
/* Verdeutlichung der unguenstigen Vorgehensweise mit cli/sei: */<br />
cli(); <br />
// Interrupts jetzt global deaktiviert <br />
<br />
NichtSoGut();<br />
// nach Aufruf der Funktion sind Interrupts global aktiviert <br />
// dies ist mglw. ungewollt!<br />
//...<br />
<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
<!-- mt: besser so nicht(?), lieber "datenblattkonform"<br />
<br />
<font face="Courier New">'''timer_enable_int (unsigned char ints);<br /><br />
'''</font>Schaltet Timerbezogene Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle<br />
Timerinterrupts ausgeschaltet, ansonsten muss in '''ints''' angegeben werden,<br />
welche Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">timer_enable_int (1 << TOIE1));<br /><br />
</font>'''Achtung: Wenn ein Timerinterrupt eingeschaltet wird während ein<br />
anderer Timerinterrupt bereits läuft, dann müssen beide Bits angegeben werden<br />
sonst wird der andere Timerinterrupt versehentlich ausgeschaltet.<br />
<br />
<font face="Courier New">'''enable_external_int (unsigned char ints);<br /><br />
'''</font>Schaltet die externen Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle externen<br />
Interrrups ausgeschaltet, ansonsten muss in '''ints''' angegeben werden, welche<br />
Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">enable_external_int ((1<<br />
</font>'''Schaltet die externen Interrupts 0 und 1 ein.<br />
<br />
Nachdem nun die Interrupts aktiviert sind, braucht es selbstverständlich noch den auszuführenden Code, der ablaufen soll, wenn ein Interrupt eintrifft.<br />
--><br />
Zu den aktivierten Interrupts ist eine Funktion zu programmieren, deren Code aufgerufen wird, wenn der betreffende Interrupt auftritt (Interrupt-Handler, Interrupt-Service-Routine). Dazu existiert die Definition (ein Makro) '''ISR'''.<br />
<br />
=== ISR ===<br />
<br />
(''ISR()'' ersetzt bei neueren Versionen der avr-libc ''SIGNAL()''. SIGNAL sollte nicht mehr genutzt werden, zur Portierung von SIGNAL nach ISR siehe den [[AVR-GCC-Tutorial#Anhang|Anhang]].)<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
//...<br />
ISR(Vectorname) /* vormals: SIGNAL(siglabel) dabei Vectorname != siglabel ! */<br />
{<br />
/* Interrupt Code */<br />
}<br />
</syntaxhighlight><br />
<br />
Mit ''ISR'' wird eine Funktion für die Bearbeitung eines Interrupts eingeleitet. Als Argument muss dabei die Benennung des entsprechenden Interruptvektors angegeben werden. Diese sind in den jeweiligen Includedateien IOxxxx.h zu finden. Die Bezeichnung entspricht dem Namen aus dem Datenblatt, bei dem die Leerzeichen durch Unterstriche ersetzt sind und ein ''_vect'' angehängt ist.<br />
<br />
Als Beispiel ein Ausschnitt aus der Datei für den ATmega8 (bei WinAVR Standardinstallation in C:\WinAVR\avr\include\avr\iom8.h) in der neben den aktuellen Namen für ''ISR'' (*_vect) noch die Bezeichnungen für das inzwischen nicht mehr aktuelle ''SIGNAL'' (SIG_*) enthalten sind.<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
/* $Id: iom8.h,v 1.13 2005/10/30 22:11:23 joerg_wunsch Exp $ */<br />
<br />
/* avr/iom8.h - definitions for ATmega8 */<br />
//...<br />
<br />
/* Interrupt vectors */<br />
<br />
/* External Interrupt Request 0 */<br />
#define INT0_vect _VECTOR(1)<br />
#define SIG_INTERRUPT0 _VECTOR(1)<br />
<br />
/* External Interrupt Request 1 */<br />
#define INT1_vect _VECTOR(2)<br />
#define SIG_INTERRUPT1 _VECTOR(2)<br />
<br />
/* Timer/Counter2 Compare Match */<br />
#define TIMER2_COMP_vect _VECTOR(3)<br />
#define SIG_OUTPUT_COMPARE2 _VECTOR(3)<br />
<br />
/* Timer/Counter2 Overflow */<br />
#define TIMER2_OVF_vect _VECTOR(4)<br />
#define SIG_OVERFLOW2 _VECTOR(4)<br />
<br />
/* Timer/Counter1 Capture Event */<br />
#define TIMER1_CAPT_vect _VECTOR(5)<br />
#define SIG_INPUT_CAPTURE1 _VECTOR(5)<br />
<br />
/* Timer/Counter1 Compare Match A */<br />
#define TIMER1_COMPA_vect _VECTOR(6)<br />
#define SIG_OUTPUT_COMPARE1A _VECTOR(6)<br />
<br />
/* Timer/Counter1 Compare Match B */<br />
#define TIMER1_COMPB_vect _VECTOR(7)<br />
#define SIG_OUTPUT_COMPARE1B _VECTOR(7)<br />
<br />
//...<br />
</syntaxhighlight><br />
<br />
<!--Vor Nutzung von SIGNAL muss ebenfalls die Header-Datei signal.h eingebunden werden.--> <br />
Mögliche Funktionsrümpfe für Interruptfunktionen sind zum Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
/* veraltet: #include <avr/signal.h> */<br />
<br />
ISR(INT0_vect) /* veraltet: SIGNAL(SIG_INTERRUPT0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(TIMER0_OVF_vect) /* veraltet: SIGNAL(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(USART_RXC_vect) /* veraltet: SIGNAL(SIG_UART_RECV) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
// und so weiter und so fort...<br />
</syntaxhighlight><br />
<br />
Auf die korrekte Schreibweise der Vektorbezeichnung ist zu achten. Der gcc-Compiler prüft erst ab Version 4.x, ob ein Signal/Interrupt der angegebenen Bezeichnung tatsächlich in der Includedatei definiert ist und gibt andernfalls eine Warnung aus. Bei WinAVR (ab 2/2005) wurde die Überprüfung auch in den mitgelieferten Compiler der Version 3.x integriert. Aus dem gcc-Quellcode Version 3.x selbst erstellte Compiler enthalten die Prüfung nicht (vgl. [[AVR-GCC]]). <br />
<br />
Während der Ausführung der Funktion sind alle weiteren Interrupts automatisch gesperrt. Beim Verlassen der Funktion werden die Interrupts wieder zugelassen.<br />
<br />
Sollte während der Abarbeitung der Interruptroutine ein weiterer Interrupt (gleiche oder andere Interruptquelle) auftreten, so wird das entsprechende Bit im zugeordneten Interrupt Flag Register gesetzt und die entsprechende Interruptroutine automatisch nach dem Beenden der aktuellen Funktion aufgerufen.<br />
<br />
Ein Problem ergibt sich eigentlich nur dann, wenn während der Abarbeitung der aktuellen Interruptroutine mehrere gleichartige Interrupts auftreten. Die entsprechende Interruptroutine wird im Nachhinein zwar aufgerufen jedoch wissen wir nicht, ob nun der entsprechende Interrupt einmal, zweimal oder gar noch öfter aufgetreten ist. Deshalb soll hier noch einmal betont werden, dass Interruptroutinen so schnell wie nur irgend möglich wieder verlassen werden sollten.<br />
<br />
=== Unterbrechbare Interruptroutinen ===<br />
<br />
"Faustregel": im Zweifel '''ISR'''. Die nachfolgend beschriebene Methode nur dann verwenden, wenn man sich über die unterschiedliche Funktionsweise im Klaren ist.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
<br />
ISR(XXX,ISR_NOBLOCK) /* veraltet: INTERRUPT(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt-Code */<br />
}<br />
</syntaxhighlight><br />
<br />
Hierbei steht XXX für den oben beschriebenen Namen des Vektors (also z.&nbsp;B. ''TIMER0_OVF_vect''). Der Unterschied im Vergleich zu einer herkömmlichen ISR ist, dass hier beim Aufrufen der Funktion das '''Global Enable Interrupt''' Bit durch Einfügen einer SEI-Anweisung direkt wieder gesetzt und somit alle Interrupts zugelassen werden &ndash; auch XXX-Interrupts. <br />
<br />
Bei unsachgemässer Handhabung kann dies zu erheblichen Problemen durch Rekursion wie einem Stack-Overflow oder anderen unerwarteten Effekten führen und sollte wirklich nur dann eingesetzt werden, wenn man sich sicher ist, das Ganze auch im Griff zu haben.<br />
<br />
Insbesondere sollte möglichst am ISR-Anfang die auslösende IRQ-Quelle deaktiviert und erst am Ende der ISR wieder aktiviert werden. Robuster als die Verwendung einer NOBLOCK-ISR ist daher folgender ISR-Aufbau:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
<br />
ISR (XXX) <br />
{<br />
// Implementiere die ISR ohne zunaechst weitere IRQs zuzulassen<br />
<br />
<<Deaktiviere die XXX-IRQ>><br />
<br />
// Erlaube alle Interrupts (ausser XXX)<br />
sei();<br />
<br />
//... Code ...<br />
<br />
// IRQs global deaktivieren um die XXX-IRQ wieder gefahrlos <br />
// aktivieren zu koennen<br />
cli();<br />
<br />
<<Aktiviere die XXX-IRQ>><br />
}<br />
</syntaxhighlight><br />
Auf diese Weise kann sich die XXX-IRQ nicht selbst unterbrechen, was zu einer Art Endlosschleife führen würde.<br />
<br />
Siehe auch: Hinweise in [[AVR-GCC]]<br />
<br />
siehe dazu: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html<br />
<br />
== Datenaustausch mit Interrupt-Routinen ==<br />
<br />
Variablen, die sowohl in Interrupt-Routinen (ISR = Interrupt Service Routine(s)) als auch vom übrigen Programmcode geschrieben oder gelesen werden, müssen mit einem '''volatile''' deklariert werden. Damit wird dem Compiler mitgeteilt, dass der Inhalt der Variablen vor jedem Lesezugriff aus dem Speicher gelesen und nach jedem Schreibzugriff in den Speicher geschrieben wird. Ansonsten könnte der Compiler den Code so optimieren, dass der Wert der Variablen nur in Prozessorregistern zwischengespeichert wird, die nichts von der Änderung woanders mitbekommen.<br />
<br />
Zur Veranschaulichung ein Codefragment für eine Tastenentprellung mit Erkennung einer "lange gedrückten" Taste.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <stdint.h><br />
//...<br />
<br />
// Schwellwerte<br />
// Entprellung: <br />
#define CNTDEBOUNCE 10<br />
// "lange gedrueckt:"<br />
#define CNTREPEAT 200<br />
<br />
// hier z.&nbsp;B. Taste an Pin2 PortA "active low" = 0 wenn gedrueckt<br />
#define KEY_PIN PINA<br />
#define KEY_PINNO PA2<br />
<br />
// beachte: volatile! <br />
volatile uint8_t gKeyCounter;<br />
<br />
// Timer-Compare Interrupt ISR, wird z.B. alle 10ms ausgefuehrt<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
// hier wird gKeyCounter veraendert. Die übrigen<br />
// Programmteile müssen diese Aenderung "sehen":<br />
// volatile -> aktuellen Wert immer in den Speicher schreiben<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
}<br />
else {<br />
gKeyCounter = 0;<br />
}<br />
}<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
//...<br />
/* hier: Initialisierung der Ports und des Timer-Interrupts */<br />
//... <br />
// hier wird auf gKeyCounter zugegriffen. Dazu muss der in der<br />
// ISR geschriebene Wert bekannt sein:<br />
// volatile -> aktuellen Wert immer aus dem Speicher lesen<br />
if ( gKeyCounter > CNTDEBOUNCE ) { // Taste mind. 10*10 ms "prellfrei"<br />
if (gKeyCounter == CNTREPEAT) {<br />
/* hier: Code fuer "Taste lange gedrueckt" */<br />
}<br />
else {<br />
/* hier: Code fuer "Taste kurz gedrueckt" */<br />
}<br />
}<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Wird innerhalb einer ISR mehrfach auf eine mit volatile deklarierte Variable zugegriffen, wirkt sich dies ungünstig auf die Verarbeitungsgeschwindigkeit aus, da bei jedem Zugriff mit dem Speicherinhalt abgeglichen wird. Da bei AVR-Controllern ''innerhalb'' einer ISR keine Unterbrechungen zu erwarten sind, bietet es sich an, einen Zwischenspeicher in Form einer lokalen Variable zu verwenden, deren Inhalt zu Beginn und am Ende mit dem der volatile Variable synchronisiert wird. Lokale Variable werden bei eingeschalteter Optimierung mit hoher Wahrscheinlichkeit in Prozessorregistern verwaltet und der Zugriff darauf ist daher nur mit wenigen internen Operationen verbunden. Die ISR aus dem vorherigen Beispiel lässt sich so optimieren:<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter; // Uebernahme in lokale Arbeitsvariable<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (tmp_kc < CNTREPEAT) {<br />
tmp_kc++;<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc; // Zurueckschreiben<br />
}<br />
//...<br />
</syntaxhighlight><br />
<br />
Zum Vergleich die Disassemblies (Ausschnitte der "lss-Dateien", compiliert für ATmega162) im Anschluss. Man erkennt den viermaligen Zugriff auf die Speicheraddresse von ''gKeyCounter'' (hier 0x032A) in der ISR ohne "Cache"-Variable und den zweimaligen Zugriff in der Variante mit Zwischenspeicher. Im Beispiel ist der Vorteil gering, bei komplexeren Routinen kann die Zwischenspeicherung in lokalen Variablen jedoch zu deutlicheren Verbesserungen führen.<br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
876: ca 99 sbic 0x19, 2 ; 25<br />
878: 0a c0 rjmp .+20 ; 0x88e <__vector_13+0x24><br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
87a: 80 91 2a 03 lds r24, 0x032A<br />
87e: 88 3c cpi r24, 0xC8 ; 200 <br />
880: 40 f4 brcc .+16 ; 0x892 <__vector_13+0x28><br />
882: 80 91 2a 03 lds r24, 0x032A<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 02 c0 rjmp .+4 ; 0x892 <__vector_13+0x28><br />
}<br />
else {<br />
gKeyCounter = 0;<br />
88e: 10 92 2a 03 sts 0x032A, r1<br />
892: 8f 91 pop r24<br />
894: 0f 90 pop r0<br />
896: 0f be out 0x3f, r0 ; 63<br />
898: 0f 90 pop r0<br />
89a: 1f 90 pop r1<br />
89c: 18 95 reti<br />
</pre><br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter;<br />
876: 80 91 2a 03 lds r24, 0x032A<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
87a: ca 9b sbis 0x19, 2 ; 25<br />
87c: 02 c0 rjmp .+4 ; 0x882 <__vector_13+0x18><br />
87e: 80 e0 ldi r24, 0x00 ; 0<br />
880: 03 c0 rjmp .+6 ; 0x888 <__vector_13+0x1e><br />
if (tmp_kc < CNTREPEAT) {<br />
882: 88 3c cpi r24, 0xC8 ; 200<br />
884: 08 f4 brcc .+2 ; 0x888 <__vector_13+0x1e><br />
tmp_kc++;<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc;<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 8f 91 pop r24<br />
88e: 0f 90 pop r0<br />
890: 0f be out 0x3f, r0 ; 63<br />
892: 0f 90 pop r0<br />
894: 1f 90 pop r1<br />
896: 18 95 reti<br />
</pre><br />
<br />
=== volatile und Pointer ===<br />
<br />
Bei '''volatile''' in Verbindung mit Pointern ist zu beachten, ob der Pointer selbst oder die Variable, auf die der Pointer zeigt, '''volatile''' ist.<br />
<br />
<syntaxhighlight lang="c"><br />
volatile uint8_t *a; // das Ziel von a ist volatile<br />
<br />
uint8_t *volatile a; // a selbst ist volatile<br />
</syntaxhighlight><br />
<br />
Falls der Pointer volatile ist (zweiter Fall im Beispiel), ist zu beachten, dass der Wert des Pointers, also eine Speicheradresse, intern in mehr als einem Byte verwaltet wird. Lese- und Schreibzugriffe im Hauptprogramm (außerhalb von Interrupt-Routinen) sind daher so zu implementieren, dass alle Teilbytes der Adresse konsistent bleiben, vgl. dazu den folgenden Abschnitt.<br />
<br />
=== Variablen größer 1 Byte ===<br />
<br />
Bei Variablen größer ein Byte, auf die in Interrupt-Routinen und im Hauptprogramm zugegriffen wird, muss darauf geachtet werden, dass die Zugriffe auf die einzelnen Bytes außerhalb der ISR nicht durch einen Interrupt unterbrochen werden. (Allgemeinplatz: AVRs sind 8-bit Controller). Zur Veranschaulichung ein Codefragment:<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
volatile uint16_t gMyCounter16bit;<br />
//...<br />
ISR(...)<br />
{<br />
//...<br />
gMyCounter16Bit++;<br />
//...<br />
}<br />
<br />
int main(void)<br />
{<br />
uint16_t tmpCnt;<br />
//...<br />
// nicht gut: Mglw. hier ein Fehler, wenn ein Byte von MyCounter <br />
// schon in tmpCnt kopiert ist aber vor dem Kopieren des zweiten Bytes <br />
// ein Interrupt auftritt, der den Inhalt von MyCounter verändert.<br />
tmpCnt = gMyCounter16bit; <br />
<br />
<br />
// besser: Änderungen "außerhalb" verhindern -> alle "Teilbytes"<br />
// bleiben konsistent<br />
cli(); // Interrupts deaktivieren<br />
tmpCnt = gMyCounter16Bit;<br />
sei(); // wieder aktivieren<br />
<br />
// oder: vorheriger Status des globalen Interrupt-Flags bleibt erhalten<br />
uint8_t sreg_tmp;<br />
sreg_tmp = SREG; /* Sichern */<br />
cli()<br />
tmpCnt = gMyCounter16Bit;<br />
SREG = sreg_tmp; /* Wiederherstellen */<br />
<br />
// oder: mehrfach lesen, bis man konsistente Daten hat<br />
uint16_t count1 = gMyCounter16Bit;<br />
uint16_t count2 = gMyCounter16Bit;<br />
while (count1 != count2) {<br />
count1 = count2;<br />
count2 = gMyCounter16Bit;<br />
}<br />
tmpCnt = count1;<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Die avr-libc bietet ab Version 1.6.0(?) einige Hilfsfunktionen/Makros, mit der im Beispiel oben gezeigten Funktionalität, die zusätzlich auch sogenannte [http://en.wikipedia.org/wiki/Memory_barrier memory barriers] beinhalten. Diese stehen nach #include <util/atomic.h> zur Verfügung.<br />
<syntaxhighlight lang="c"><br />
//...<br />
#include <util/atomic.h><br />
//...<br />
<br />
// analog zu cli, Zugriff, sei:<br />
ATOMIC_BLOCK(ATOMIC_FORCEON) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
// oder:<br />
<br />
// analog zu Sicherung des SREG, cli, Zugriff und Zurückschreiben des SREG:<br />
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
//...<br />
</syntaxhighlight><br />
<br />
* siehe auch [http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Dokumentation der avr-libc zu atomic.h]<br />
<br />
== Interrupt-Routinen und Registerzugriffe ==<br />
<br />
Falls Register sowohl im Hauptprogramm als auch in Interrupt-Routinen verändert werden, ist darauf zu achten, dass diese Zugriffe sich nicht überlappen. Nur wenige Anweisungen lassen sich in sogenannte "atomare" Zugriffe übersetzen, die nicht von Interrupt-Routinen unterbrochen werden können. <br />
<br />
Zur Veranschaulichung eine Anweisung, bei der ein Bit und im Anschluss drei Bits in einem Register gesetzt werden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
int main(void)<br />
{<br />
//...<br />
PORTA |= (1<<PA0);<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Der Compiler übersetzt diese Anweisungen für einen ATmega128 bei Optimierungsstufe "S" nach:<br />
<br />
<div class="code"><pre><br />
...<br />
PORTA |= (1<<PA0);<br />
d2: d8 9a sbi 0x1b, 0 ; 27 (a)<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
d4: 8b b3 in r24, 0x1b ; 27 (b)<br />
d6: 8c 61 ori r24, 0x1C ; 28 (c)<br />
d8: 8b bb out 0x1b, r24 ; 27 (d)<br />
...<br />
</pre></div><br />
<br />
Das Setzen des einzelnen Bits wird bei eingeschalteter Optimierung für Register im unteren Speicherbereich in eine einzige Assembler-Anweisung (sbi) übersetzt und ist nicht anfällig für Unterbrechungen durch Interrupts. Die Anweisung zum Setzen von drei Bits wird jedoch in drei abhängige Assembler-Anweisungen übersetzt und bietet damit zwei "Angriffspunkte" für Unterbrechungen. Eine Interrupt-Routine könnte nach dem Laden des Ausgangszustands in den Zwischenspeicher (hier Register 24) den Wert des Registers ändern, z.&nbsp;B. ein Bit löschen. Damit würde der Zwischenspeicher nicht mehr mit dem tatsächlichen Zustand übereinstimmen aber dennoch nach der Bitoperation (hier ori) in das Register zurückgeschrieben. <br />
<br />
Beispiel: PORTA sei anfangs 0b00000000. Die erste Anweisung (a) setzt Bit 0 auf '''1''', PORTA ist danach 0b0000000'''1'''. Nun wird im ersten Teil der zweiten Anweisung der Portzustand in ein Register eingelesen (b). Unmittelbar darauf (vor (c)) "feuert" ein Interrupt, in dessen Interrupt-Routine Bit 0 von PORTA gelöscht wird. Nach Verlassen der Interrupt-Routine hat PORTA den Wert 0b00000000. In den beiden noch folgenden Anweisungen des Hauptprogramms wird nun der zwischengespeicherte "alte" Zustand 0b00000001 mit 0b00011100 logisch-'''ODER'''-verknüft (c) und das Ergebnis 0b00011101 in PortA geschrieben (d). Obwohl zwischenzeitlich Bit 0 gelöscht wurde, ist es nach (d) wieder gesetzt. <br />
<br />
Lösungsmöglichkeiten:<br />
* Register ohne besondere Vorkehrungen nicht in Interruptroutinen ''und'' im Hauptprogramm verändern.<br />
* Interrupts vor Veränderungen in Registern, die auch in ISRs verändert werden, deaktivieren ("cli").<br />
* Bits einzeln löschen oder setzen. sbi und cbi können nicht unterbrochen werden. Vorsicht: nur Register im unteren Speicherbereich sind mittels sbi/cbi ansprechbar. Der Compiler kann nur für diese sbi/cbi-Anweisungen generieren. Für Register außerhalb dieses Adressbereichs ("Memory-Mapped"-Register) werden auch zur Manipulation einzelner Bits abhängige Anweisungen erzeugt (lds,...,sts).<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Frequently asked Questions/Fragen Nr. 1 und 8. (Stand: avr-libc Vers. 1.0.4)<br />
<br />
== Interruptflags löschen ==<br />
<br />
Beim Löschen von Interruptflags haben AVRs eine Besonderheit, die auch im Datenblatt beschrieben ist: Es wird zum Löschen eine 1 in das betreffende Bit geschrieben. <br />
<br />
Hinweis:<br /><br />
Bei Registern mit mehreren Interrupt-Flag-Bits (wie die Timer Interrupt Flag Register) '''nicht''' die übliche bitweise VerODERung nehmen, sondern eine direkte Zuweisung machen. Da sonst weitere Flags, als nur das gewünschte, ebenfalls gelöscht werden könnten.<br /><br />
([http://www.mikrocontroller.net/topic/171148#1640133 Erklärung]).<br />
<br />
== Was macht das Hauptprogramm? ==<br />
<br />
Im einfachsten (Ausnahme-)Fall gar nichts mehr. Es ist also durchaus denkbar, ein Programm zu schreiben, welches in der main-Funktion lediglich noch die Interrupts aktiviert und dann in einer Endlosschleife verharrt. Sämtliche Funktionen werden dann in den ISRs abgearbeitet. Diese Vorgehensweise ist jedoch bei den <i>meisten</i> Anwendungen schlecht: man verschenkt eine Verarbeitungsebene und hat außerdem möglicherweise Probleme durch Interruptroutinen, die zu viel Verarbeitungszeit benötigen.<br />
<br />
Für <i>wenige</i> Anwendungen ist diese Vorgehensweise jedoch perfekt: Die Hauptschleife verkommt zu <tt>for(;;) sleep_cpu();</tt> — siehe nächster Abschnitt „Sleep“. Weiterer Vorteil: ISRs brauchen keine(!) Register retten, ein Fall für <tt>ISR(<i>name</i>,ISR_NAKED){ … reti();}</tt>. <i>So</i> können Mikrocontroller für batteriebetriebene Geräte, etwa Fernbedienungen, maximal Energie sparen.<br />
<br />
Normalerweise wird man in den Interruptroutinen nur die bei Auftreten des jeweiligen Interruptereignisses unbedingt notwendigen Operationen ausführen lassen. Alle weniger kritischen Aufgaben werden dann im Hauptprogramm abgearbeitet.<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Interrupts and Signals<br />
<br />
= Sleep-Modes =<br />
<br />
AVR Controller verfügen über eine Reihe von sogenannten [[Sleep Mode |''Sleep-Modes'']] ("Schlaf-Modi"). Diese ermöglichen es, Teile des Controllers abzuschalten. Zum Einen kann damit besonders bei Batteriebetrieb Strom gespart werden, zum Anderen können Komponenten des Controllers deaktiviert werden, die die Genauigkeit des Analog-Digital-Wandlers bzw. des Analog-Comparators negativ beeinflussen. Der Controller wird durch Interrupts aus dem Schlaf geweckt. Welche Interrupts den jeweiligen Schlafmodus beenden, ist einer Tabelle im Datenblatt des jeweiligen Controllers zu entnehmen.<br />
Die Funktionen (eigentlich Makros) der avr-libc stehen nach Einbinden der header-Datei ''sleep.h'' zur Verfügung.<br />
<br />
;set_sleep_mode (uint8_t mode): Setzt den Schlafmodus, der bei Aufruf von sleep() aktiviert wird. In sleep.h sind einige Konstanten definiert (z.&nbsp;B. SLEEP_MODE_PWR_DOWN). Die definierten Modi werden jedoch nicht alle von sämtlichten AVR-Controllern unterstützt.<br />
;sleep_enable(): Aktiviert den gesetzten Schlafmodus, versetzt den Controller aber noch nicht in den Schlafmodus<br />
;sleep_cpu(): Versetzt den Controller in den Schlafmodus .sleep_cpu wird im Prinzip durch die Assembler-Anweisung ''sleep'' ersetzt.<br />
;sleep_disable(): Deaktiviert den gesetzten Schlafmodus<br />
;sleep_mode(): Versetzt den Controller in den mit set_sleep_mode gewählten Schlafmodus. Das Makro entspricht sleep_enable()+sleep_cpu()+sleep_disable(), beinhaltet also nicht die Aktivierung von Interrupts (besser nicht benutzen).<br />
<br />
Bei Anwendung von sleep_cpu() müssen Interrupts also bereits freigeben sein (sei()), da der Controller sonst nicht mehr "aufwachen" kann. sleep_mode() ist nicht geeignet für die Verwendung in ISR Interrupt-Service-Routinen, da bei deren Abarbeitung Interrupts global deaktiviert sind und somit auch die möglichen "Aufwachinterrupts". Abhilfe: stattdessen sleep_enable(), sei(), sleep_cpu(), sleep_disable() und evtl. cli() verwenden (vgl. Dokumentation der avr-libc).<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/sleep.h><br />
<br />
int main(void)<br />
{<br />
...<br />
<br />
while (1) {<br />
...<br />
set_sleep_mode(SLEEP_MODE_PWR_DOWN);<br />
sleep_mode();<br />
<br />
// Code hier wird erst nach Auftreten eines entsprechenden<br />
// "Aufwach-Interrupts" verarbeitet<br />
...<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
In älteren Versionenen der avr-libc wurden nicht alle AVR-Controller durch die sleep-Funktionen richtig angesteuert. Mit avr-libc 1.2.0 wurde die Anzahl der unterstützten Typen jedoch deutlich erweitert. Bei nicht-unterstützten Typen erreicht man die gewünschte Funktionalität durch direkte "[[Bitmanipulation]]" der entsprechenden Register (vgl. Datenblatt) und Aufruf des Sleep-Befehls via Inline-Assembler oder sleep_cpu():<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
// Sleep-Mode "Power-Save" beim ATmega169 "manuell" aktivieren<br />
SMCR = (3<<SM0) | (1<<SE);<br />
asm volatile ("sleep"::); // alternativ sleep_cpu() aus sleep.h<br />
...<br />
</syntaxhighlight><br />
<br />
== Sleep-Modi ==<br />
Die vielen Prozessoren aus der AVR-Familie unterstützen unterschiedliche Sleep-Modi, gefächert nach Vorhandensein von Funktionsblöcken im Controller. Konkrete und verläßliche Auskunft über die tatsächlichen Gegebenheiten finden sich wie immer in den jeweiligen Datenblättern. Die Modi unterscheiden sich darin, welche Funktionsbereiche zum Energiesparen abgeschaltet werden. Davon hängt auch ab, mit welchen Mitteln der Prozessor aus der jeweiligen Schlaftiefe wieder aufgeweckt werden kann.<br />
<br />
;Idle Mode (SLEEP_MODE_IDLE): Die CPU kann durch SPI, USART, Analog Comperator, ADC, TWI, Timer, Watchdog und irgendeinen anderen Interrupt wieder aufgeweckt werden.<br />
<br />
;ADC Noise Reduction Mode (SLEEP_MODE_ADC): In diesem Modus liegt das Hauptaugenmerk darauf, die CPU soweit stillzulegen, dass der ADC möglichst keine Störungen aus dem inneren der CPU auffangen kann, die das Meßergebnis negativ beeinflussen können. Das Aufwachen aus diesem Modus kann ausgelöst werden durch den ADC, externe Interrupts, TWI, Timer und Watchdog.<br />
<br />
;Power-Down Mode (SLEEP_MODE_PWR_DOWN): In diesem Modus wird ein externer Oszillator (Quarz, Quarzoszillator), wenn vorhanden. gestoppt. Geweckt werden kann die CPU durch einen externen Level-Interrupt, TWI, Watchdog, Brown-Out-Reset.<br />
<br />
;Power-Save-Mode (SLEEP_MODE_PWR_SAVE): Power-Save ist identisch zu Power-Down mit einer Ausnahme: Ist der Timer 2 auf die Verwendung eines externen Taktes konfiguriert, so läuft dieser Timer auch im Power-Save weiter und kann die CPU mit einem Interrupt aufwecken.<br />
<br />
;Standby-Mode (SLEEP_MODE_STANDBY, SLEEP_MODE_EXT_STANDBY): Voraussetzung für den Standby-Modus ist die Verwendung eines Quarzes oder eines Quarzoszillators, also einer externen Taktquelle. Ansonsten ist dieser Modus identisch zum Power-Down Modus. Vorteil dieses Modus' ist eine kürzere Aufwachzeit.<br />
<br />
;Abschalten des Brownout Detect (BOD) während der Sleep-Phase (nur P-Typen): Zur Stromersparnis bieten die P-Typen die Möglichkeit den BOD während der Sleep-Phase abzuschalten. Bei einem Atmega88PA beispielsweise, kann dadurch der Stromverbrauch im SLEEP_MODE_PWR_SAVE mit Timer2 im Asynchronmodus mit Uhrenquarz und periodischer Selbstaufweckung um ca. 50% gesenkt werden.<br />
Das Einschalten dieser Funktion geschieht in einer Timed Sequence.<br />
<br />
<syntaxhighlight lang="c"><br />
unsigned char temp0 = MCUCR;<br />
unsigned char temp1 = MCUCR;<br />
temp0 |= (1 << BODS) | (1 << BODSE);<br />
temp1 |= (1 << BODS);<br />
MCUCR = temp0;<br />
MCUCR = temp1;<br />
sleep_cpu();<br />
</syntaxhighlight><br />
<br />
Hierbei ist unbedingt zu beachten, dass das BODS-Bit 3 Takte nach dem Setzen wieder gelöscht wird. Daher muss der Aufruf des Sleep unmittelbar nach dem Setzen erfolgen und das BODS-Bit muss jedes Mal vor einem Sleep Aufruf erneut gesetzt werden.<br />
<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Power Management and Sleep-Modes<br />
* [http://www.mikrocontroller.net/topic/96369#832712 Forenbeitrag] zur "Nichtverwendung" von sleep_mode in ISRs.<br />
<br />
= Zeiger =<br />
Zeiger (engl. ''Pointer'') sind Variablen, die die Adresse von Daten oder Funktionen enthalten und belegen 16 Bits. Die Größe hängt mit dem adressierbaren Speicherbereich zusammen und der GCC reserviert dann den entsprechenden Platz.<br />
Ggf. ist es also günstiger, Indizes auf Arrays (Listen) zu verwenden, so dass der GCC für die Zeigerarithmetik den erforderlichen RAM nur temporär benötigt.<br />
<br />
Siehe auch: [[Zeiger]]<br />
<br />
= Speicherzugriffe =<br />
<br />
Atmel AVR-Controller verfügen typisch über drei Speicher:<br />
<br />
* [[RAM]]: Im RAM (genauer statisches RAM/SRAM) wird vom gcc-Compiler Platz für Variablen reserviert. Auch der Stack befindet sich im RAM. Dieser Speicher ist "flüchtig", d.h. der Inhalt der Variablen geht beim Ausschalten oder einem Zusammenbruch der Spannungsversorgung verloren. Das bedeutet im Umkehrschluss auch, dass der RAM-Inhalt nach RESET vom Pin oder vom Watchdog erhalten bleibt! Der C-Startupcode löscht jedoch den RAM, d.h. setzt alle Bits auf 0. Dadurch erscheinen „normal definierte“ Variablen als 0. Auch Gleitkommazahlen, die schlauerweise so definiert sind, dass eine +0.0 aus lauter Nullbits besteht. Von der Löschung ausschließen kann man RAM-Variablen mit <tt>__attribute__((section(".noinit")))</tt>.<br />
<br />
* Programmspeicher: Ausgeführt als FLASH-Speicher, seitenweise wiederbeschreibbar. Darin ist das Anwendungsprogramm abgelegt.<br />
<br />
* [[EEPROM]]: Nichtflüchtiger Speicher, d.h. der einmal geschriebene Inhalt bleibt auch ohne Stromversorgung erhalten. Byte-weise schreib/lesbar. Im EEPROM werden typischerweise gerätespezifische Werte wie z.&nbsp;B. Kalibrierungswerte von Sensoren abgelegt.<br />
<br />
Einige AVRs besitzen keinen RAM-Speicher, lediglich die Register können als "Arbeitsvariablen"<br />
genutzt werden. Da die Anwendung des avr-gcc auf solch "kleinen" Controllern ohnehin selten sinnvoll ist und auch nur bei einigen RAM-losen Typen nach [http://lightner.net/avr/ATtinyAvrGcc.html "Bastelarbeiten"] möglich ist, werden diese Controller hier nicht weiter berücksichtigt. Auch EEPROM-Speicher ist nicht auf allen Typen verfügbar. Generell sollten die nachfolgenden Erläuterungen auf alle ATmega-Controller und die größeren AT90-Typen übertragbar sein. Für die Typen ATtiny2313, ATtiny26 und viele weitere der "ATtiny-Reihe" gelten die Ausführungen ebenfalls.<br />
<br />
Siehe auch:<br />
* [[Binäre Daten zum Programm hinzufügen]]<br />
== RAM ==<br />
<br />
Die Verwaltung des RAM-Speichers erfolgt durch den Compiler, im Regelfall ist beim Zugriff auf Variablen im RAM nichts Besonderes zu beachten. Die Erläuterungen in jedem brauchbaren C-Buch gelten auch für den vom avr-gcc-Compiler erzeugten Code.<br />
<br />
Um Speicher dynamisch (während der Laufzeit) zu reservieren, kann '''malloc()''' verwendet werden. malloc(size) "alloziert" (~reserviert) einen gewissen Speicherblock mit '''size''' Bytes. Ist kein Platz für den neuen Block, wird NULL (0) zurückgegeben.<br />
<br />
Wird der angelegte Block zu klein (groß), kann die Größe mit realloc() verändert werden. Den allozierten Speicherbereich kann man mit free() wieder freigeben. Wenn das Freigeben eines Blocks vergessen wird spricht man von einem "Speicherleck" (memory leak).<br />
<br />
malloc() legt Speicherblöcke im '''Heap''' an, belegt man zuviel Platz, dann wächst der Heap zu weit nach oben und überschreibt den Stack, und der Controller kommt in Teufels Küche. Das kann leider nicht nur passieren wenn man insgesamt zu viel Speicher anfordert, sondern auch wenn man Blöcke unterschiedlicher Größe in ungünstiger Reihenfolge alloziert/freigibt (siehe Artikel [[Heap-Fragmentierung]]). Aus diesem Grund sollte man malloc() auf Mikrocontrollern sehr sparsam (am besten gar nicht) verwenden.<br />
<br />
Beispiel zur Verwendung von malloc():<br />
<syntaxhighlight lang="c"><br />
#include <stdlib.h><br />
<br />
void foo(void) {<br />
// neuen speicherbereich anlegen,<br />
// platz für 10 uint16<br />
uint16_t* pBuffer = malloc(10 * sizeof(uint16_t));<br />
<br />
// darauf zugreifen, als wärs ein gewohnter Buffer<br />
pBuffer[2] = 5;<br />
<br />
// Speicher (unbedingt!) wieder freigeben<br />
free(pBuffer);<br />
}<br />
</syntaxhighlight><br />
<br />
Wenn (wie in obigem Beispiel) dynamischer Speicher nur für die Dauer einer Funktion benötigt und am Ende wieder freigegeben wird, bietet es sich an, statt malloc() '''alloca()''' zu verwenden. Der Unterschied zu malloc() ist, dass der Speicher auf dem Stack reserviert wird, und beim Verlassen der Funktion automatisch wieder freigegeben wird. Es kann somit kein Speicherleck und keine Fragmentierung entstehen.<br />
<br />
siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/malloc.html AVR Libc Home Page]: Memory Areas and Using malloc()<br />
* [https://www.mikrocontroller.net/topic/479027#5934443 Forumsbeitrag]: RAM Verbrauch auch von lokalen variablen ermitteln<br />
<br />
== Flash mit PROGMEM und pgm_read ==<br />
<br />
→ [http://nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html avr-libc: Doku zu avr/pgmspace.h]<br />
<br />
Ein Zugriff auf Konstanten im Programmspeicher ist mittels avr-gcc erst ab Version 4.7 "transparent" möglich. Um Daten aus dem Flash zu lesen, muss die AVR-Instruktion LPM (''Load from Program Memory'') erzeugt werden, bei Controllern mit mehr als 64kiB Flash auch ELPM.<br />
<br />
Dazu gibt es das AVR-spezifische GCC-Attribut <tt>progmem</tt>, mit dem eine Variablendeklaration im ''static storage''<ref>Variablen der Speicherklasse ''static storage'' haben eine unbegrenzte Lebensdauer. Beispiel für solche Variablen sind globale Variablen, aber auch static-Variablen innerhalb einer Funktion gehören dazu. Beispiele für Variablen, die nicht ''static storage'' sind: auto-Variablen ("normale" lokale Variablen), register-Variablen, durch malloc geschaffene Objekte, etc.</ref> markiert werden kann:<br />
<syntaxhighlight lang="c"><br />
const int value __attribute__((progmem)) = 1;<br />
</syntaxhighlight><br />
<br />
Effekt ist, dass die so markierte Variable nicht im RAM sondern im Flash angelegt wird. Wird durch "normalen" C-Code auf solch eine Variable zugegriffen, wird jedoch aus der gleichen Adresse aus dem RAM gelesen und nicht aus dem Flash! Das ist ein Fehler, den der Compiler aber nicht anzeigt!<br />
<br />
<syntaxhighlight lang="c"><br />
int test = value; // Fehler! PROGMEM Konstanten müssen mit den pgm_read-Funktionen gelesen werden!<br />
</syntaxhighlight><br />
<br />
Zum Lesen aus dem Flash stellt die avr-libc daher zahlreiche Makros zur Verfügung. Zudem wird das Makro <tt>PROGMEM</tt> definiert, das etwas Tipparbeit spart:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
const int value PROGMEM = 1;<br />
</syntaxhighlight><br />
<br />
<tt>progmem</tt> funktioniert im Wesentlichen wie ein Section-Attribut, das die Daten in der Section <tt>.progmem.data</tt> ablegt. Im Gegensatz zum Section-Attribut werden jedoch noch weitere Prüfungen unternommen, ab avr-gcc 4.6 etwa muss die entsprechende Variable <tt>const</tt> sein.<br />
<br />
=== Integer und float ===<br />
<br />
Zum Lesen von Skalaren stellt die avr-libc folgende Makros zu Verfügung, die jeweils ein Argument erhalten: Die 16-Bit Adresse des zu lesenden Wertes<ref>Damit ist der mögliche Speicherbereich für Flash-Konstanten auf 64kiB begrenzt. Einige pgmspace-Funktionen ermöglichen den Lesezugriff auf den gesamten Flash-Speicher, intern via Assembler-Anweisung ELPM. Die Initialisierungswerte des Speicherinhalts jenseits der 64kiB-Marke müssen dann jedoch auf anderem Weg angelegt werden, d.h. nicht per PROGMEM. Evtl. eigene Section und Linker-Optionen. Alt und nicht ganz korrekt: Die avr-libc pgmspace-Funktionen unterstützen nur die unteren 64kiB Flash bei Controllern mit mehr als 64kiB.</ref><br />
<br />
:{| {{Tabelle}}<br />
|+ Übersicht der <tt>pgm_read</tt> Funktionen aus<br/>dem Header <tt>avr/pgmspace.h</tt> der avr-libc<br />
|-<br />
! Gelesener Wert || <tt>pgm_read_xxx</tt> || Anzahl Bytes<br />
|-<br />
| <tt>uint8_t</tt> || <tt>pgm_read_byte</tt> || 1<br />
|-<br />
| <tt>uint16_t</tt> || <tt>pgm_read_word</tt> || 2<br />
|-<br />
| <tt>uint32_t</tt> || <tt>pgm_read_dword</tt> || 4<br />
|-<br />
| <tt>float</tt> || <tt>pgm_read_float</tt><ref>ab avr-libc 1.7.0</ref> || 4<br />
|}<br />
<br />
Soll ein Zeiger gelesen werden, so verwendet man <tt>pgm_read_word</tt> und castet das Ergebnis zum gewünschten Zeiger-Typ.<br />
<br />
;Beispiele:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
/* Byte */<br />
const uint8_t aByte PROGMEM = 123;<br />
<br />
/* int-Array */<br />
const int anArray[] PROGMEM = { 18, 3 ,70 };<br />
<br />
void foo (void)<br />
{<br />
/* Zeiger */<br />
static const uint8_t* const aPointer PROGMEM = &aByte;<br />
<br />
uint8_t a = pgm_read_byte (&aByte);<br />
int a2 = (int) pgm_read_word (&anArray[2]);<br />
const uint8_t* p = (const uint8_t*) pgm_read_word (&aPointer);<br />
}<br />
</syntaxhighlight><br />
<br />
=== Blöcke ===<br />
<br />
In den Flash-Funktionen der avr-libc sind keine der pgm_read_xxxx Nomenklatur folgenden Funktionen, die Speicherblöcke auslesen oder vergleichen. Die enstprechende Funktionen sind Varianten von <tt>memcpy</tt>, <tt>memcmp</tt> und heißt <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, usw. Für weitere Funktionen und deren Prototypen siehe die Dokumentation der avr-libc.<br />
<br />
=== Strings ===<br />
<br />
Strings sind in C nichts anderes als eine Abfolge von Zeichen und einem <tt>'\0'</tt> als Stringende. Der prinzipielle Weg ist daher identisch zum Lesen von Bytes, wobei auf die [[FAQ#Wie funktioniert String-Verarbeitung in C?|Besonderheiten von Strings]] wie 0-Terminierung geachtet werden muss.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
size_t my_string_length (const char *addr)<br />
{<br />
size_t length = 0;<br />
<br />
while (pgm_read_byte (addr++))<br />
{<br />
length++;<br />
}<br />
return length;<br />
}<br />
</syntaxhighlight><br />
<br />
Zur Unterstützung des Programmierers steht das Repertoire der str-Funktionen auch in jeweils eine Variante zur Verfügung, die mit dem Flash-Speicher arbeiten kann. Die Funktionsnamen tragen den Suffix <tt>_P</tt>. Darüber hinaus gibt es das Makro <tt>PSTR</tt>, das ein String-Literal im Flash-Speicher ablegt und die Adresse des Strings liefert:<br />
<br />
Die nachfolgende Funktion liefert 0 zurück, wenn string_im_ram gleich "Hallo Welt" ist. Mit strcmp (String Compare) können wir zwei Strings vergleichen. Der Rückgabewert kann hierbei folgende Werte haben:<br><br />
0 die Strings sind gleich<br />
>0 das erste ungleiche Zeichen in string_im_ram ist größer als in "Hallo Welt"<br />
<0 das erste ungleiche Zeichen in string_im_ram ist kleiner als in "Hallo Welt"<br />
<br><br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
int foo (const char *string_im_ram)<br />
{<br />
return strcmp_P (string_im_ram, PSTR ("Hallo Welt"));<br />
}<br />
</syntaxhighlight><br />
<br />
Zu beachten ist, dass <tt>PSTR</tt> nur innerhalb von Funktionen verwendet werden kann.<br />
<br />
; Array aus Strings:<br />
<br />
Arrays aus Strings im Flash-Speicher werden in zwei Schritten angelegt:<br />
<br />
# Zuerst die einzelnen Elemente des Arrays und<br />
# im Anschluss ein Array, in dem die Startaddressen der Strings abgelegt werden.<br />
<br />
Zum Auslesen wird zuerst die Adresse des gewünschten Elements aus dem Array im Flash-Speicher gelesen, die im Anschluss dazu genutzt wird, um auf das Element (den String) selbst zuzugreifen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
static const char str1[] PROGMEM = "Hund";<br />
static const char str2[] PROGMEM = "Katze";<br />
static const char str3[] PROGMEM = "Maus";<br />
<br />
const char * const array[] PROGMEM = <br />
{<br />
str1, str2, str3<br />
};<br />
<br />
// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]<br />
void read_string (char *buf, size_t i)<br />
{<br />
// Lese die Adresse des i-ten Strings aus array[]<br />
const char *parray = (const char*) pgm_read_ptr (&array[i]);<br />
<br />
// Kopiere den Inhalt der Zeichenkette vom Flash ins RAM<br />
strcpy_P (buf, parray);<br />
}<br />
</syntaxhighlight><br />
<br />
Eine weitere Möglichkeit ist, die Strings in einem 2-dimensionalen char-Array abzulegen anstatt deren Adresse in einem 1-dimensionalen Adress-Array zu speichern.<br />
<br />
Vorteil ist, dass der Code einfacher wird. Nachteil ist, dass bei unterschiedlich langen Strings Speicherplatz verschwendet wird, weil sich die Array-Dimension and der Länge des längsten Strings orientieret. Bei in etwa gleich langen Strings kann es aber sogar Speicherplatz sparen, denn es die Adressen der einzelnen Strings müssen nicht abgespeichert werden.<ref>In unserem Hund-Katze-Maus Beispiel belegt die erste Variante 22 Bytes Daten und 18 Bytes Code, die zweite Variante mit 2-dimensionalem Array belegt 18 Bytes Daten und 20 Bytes Code. Gemessen wurde mit avr-gcc 4.8 -Os für ATmega8.</ref><br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
// Die "6" ist 1 plus die Länge des längsten Strings ("Katze")<br />
const char array[][6] PROGMEM = <br />
{<br />
"Hund", "Katze", "Maus"<br />
};<br />
<br />
// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]<br />
void read_string (char *buf, size_t i)<br />
{<br />
// Kopiere den Inhalt der i-ten Zeichenkette vom Flash ins RAM<br />
strcpy_P (buf, array[i]);<br />
}<br />
</syntaxhighlight><br />
<br />
Siehe dazu auch die avr-libc FAQ: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_rom_array How do I put an array of strings completely in ROM?]<br />
<br />
=== Warum so kompliziert? ===<br />
<br />
Zu dem Thema, warum die Verabeitung von Werten aus dem Flash-Speicher so kompliziert ist, sei hier nur kurz erläutert: Die Harvard-Architektur des AVR weist getrennte Adressräume für Programm (Flash) und Datenspeicher (RAM) auf. Der C-Standard sieht keine unterschiedlichen Adressräume vor.<br />
<br />
Hat man zum Beispiel eine Funktion string_an_uart (const char* s) und übergibt an diese Funktion die Adresse einer Zeichenkette, dann weiß die Funktion nicht, ob die Adresse in den Flash-Speicher oder das RAM zeigt. Weder aus dem Pointer-Wert, also dem Zahlenwert, noch aus dem "const" kann auf den Ort der Ablage geschlossen werden.<br />
<br />
Einige AVR-Compiler bilden die Harvard-Architektur ab, indem sie in einen Pointer nicht nur die Adresse speichern, sondern auch den Ablageort wie ''Flash'' oder ''RAM''. In einem Aufruf einer Funktion wird dann bei Pointer-Parametern neben der Adresse auch der Speicherbereich, auf den der Pointer zeigt, übergeben.<br />
<br />
Dies hat jedoch auch Nachteile, denn bei jedem Zugriff über einen Zeiger muss zur ''Laufzeit'' entschieden werden, wie der Zugriff auszuführen ist und entsprechend länglicher und langsamer wird der erzeugte Code.<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitte Modules/Program Space String Utilities und Abschnitt Modules/Bootloader Support Utilities<br />
<br />
=== Datenzugriff jenseits 64 KiB ===<br />
<br />
Die Zeiger beim <tt>avr-gcc</tt> sind stets 16 Bit breit, können somit also nur 64 KiB Datenspeicher adressieren. Darauf sind auch alle Funktion der libc ausgelegt, welche auf _P enden. Funktionszeiger können beim AVR bis zu 128 KiB Programmspeicher adressieren, weil Funktionsadressen immer 16-Bit-<u>Worte</u> adressieren und nicht Bytes. Der Zugriff auf den RAM ist mit maximal 16 KiB (extern maximal 64 KiB) durch 16-Bit-Zeiger nicht begrenzt.<br />
<br />
Schlauerweise sortiert <tt>avr-gcc</tt> Flash-Konstanten und -Tabellen <i>so</i> um, dass sie an den Anfang des Flash-Speichers, gleich nach der Interrupt-Tabelle, zu liegen kommen. Somit kommt man auch auf Controllern mit mehr als 64 KByte Flash im Normalfall keine Adresse jenseits 64 KiByte erforderlich.<br />
<br />
<small>Auf Controllern mit mehr als 128 KiB Flash bekommen alle Funktionen <i>jenseits</i> 128 KiB ein <b>Trampolin</b> (Sprungbefehl aus 4 Byte) im dem Adressbereich <i>vor</i> 128 KiB. Damit genügt für alle Funktionszeiger 16 Bit. Wird kein Zeiger benötigt, kann der Optimierer das jeweilige Trampolin entfernen.</small><br />
<br />
Um (dennoch) Zugriff jenseits von 64 KiB zu bewerkstelligen gibt es mehrere Möglichkeiten:<br />
<br />
* Address-Spaces wie <tt>__flash1</tt> oder <tt>__memx</tt>, siehe Abschnitt "[[#Jenseits von flash|Jenseits von __flash]]".<br />
* Die Funktionen bzw. Makros <tt>pgm_read_xxx_far</tt> der AVR-Libc ab Version 1.8.0, wie im folgenden beschrieben. Dafür gibt es die Funktion pgm_get_far_address(), um 32-Bit Pointer eines Objekts zu erhalten<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/pgmspace.h><br />
<br />
//===================================================================<br />
// Define an additional section, which will be placed after all others<br />
//--------------------------------------------------------------------<br />
#define FAR_SECTION __attribute__((__section__(".far_section")))<br />
//--------------------------------------------------------------------<br />
<br />
//====================================================================<br />
// Just an example<br />
//====================================================================<br />
<br />
const char MyString[] FAR_SECTION = "Hier liegt mein FAR-Teststring!";<br />
const char MyBmp64[] FAR_SECTION = {0xAA,0xBB,0xCC,0xDD,0xEE,0xFF,0x00};<br />
<br />
int main(void) {<br />
uint32_t ptr = pgm_get_far_address(MyString);<br />
char MyChar;<br />
DDRC = 0xFF;<br />
do {<br />
MyChar = pgm_read_byte_far(ptr++);<br />
PORTC = MyChar;<br />
} while(MyChar);<br />
}<br />
</syntaxhighlight><br />
<br />
D.h. man muss<br />
* Die Definition der neuen Section <tt>FAR_SECTION</tt> einfügen<br />
* Die konstanten Daten mit dieser Section kennzeichnen<br />
<br />
Dem Linker muss man über diese Section nichts mitteilen, er fügt diese automatisch nach allen bestehenden sections im Flash ein. Der Zugriff auf diese Variablen kann nur mittels direkter Pointerarithmetik erfolgen, eine Indizierung von Arrays mit variablem Index ist nicht möglich. Dabei muss die Größe des Datentyps immer manuell berücksichtigt werden, denn der Pointer ist immer ein Bytepointer!<br />
<br />
<syntaxhighlight lang="c"><br />
int n=3;<br />
MyChar = pgm_read_byte_far(pgm_get_far_address(MyBmp64)+n*sizeof(char));<br />
</syntaxhighlight><br />
<br />
Dabei gibt es einige praktische Probleme.<br />
* Beim recht alten AVR-Studio 4.18 wird die Größe des belegten FLASH-Speichers nicht korrekt angezeigt, die Daten landen aber im HEX-File.<br />
* beim moderneren Atmelstudio 6.2 sieht man in der Consolenausgabe die richtige Größe, welche von avr-size ermittelt wurde, diese wird aber dann in der 2. Ausgabe durch Atmelstudio falsch dargestellt<br />
* Die Arduino-IDE rechnet richtig, siehe dieser [https://www.mikrocontroller.net/topic/511511?goto=6568945#6568945 Forumsbeitrag].<br />
<br />
== Flash mit __flash und Embedded-C ==<br />
<br />
Ab Version 4.7 unterstützt avr-gcc ''Adress-Spaces'' gemäß dem Embedded-C Dokument ISO/IEC TR18037. Der geläufigste Adress-Space ist <tt>__flash</tt>, der im Gegensatz zu <tt>progmem</tt> kein GCC-Attribut ist, sondern ein Qualifier und damit syntaktisch ähnlich verwendet wird wie <tt>const</tt> oder <tt>volatile</tt>.<br />
<br />
GCC kennt keine eigene Option zum Aktivieren von Embedded-C, es wird als GNU-C Erweiterung behandelt. Daher müssen C-Module, die Address-Spaces verwenden, mit <tt>-std=gnu99</tt> o.ä. compiliert werden.<br />
<br />
<syntaxhighlight lang="c"><br />
static const __flash int value = 10;<br />
<br />
int get_value (void)<br />
{<br />
return value;<br />
}<br />
</syntaxhighlight><br />
<br />
# Im Gegensatz zu <tt>progmem</tt> sind keine speziellen Bibliotheksfunktionen oder -makros für den Zugriff mehr notwendig: Der Code zum Lesen der Variable ist "normales" C.<br />
# Die Variable wird im richtigen Speicherbereich (Flash) angelegt.<br />
# <tt>__flash</tt> ist nur zusammen mit read-only Objekten oder Zeigern, d.h. nur zusammen mit <tt>const</tt>, erlaubt.<br />
# Zugriffe wie im obigen Beispiel können (weg)optimiert werden. Das Beispiel entspricht einem "<tt>return 10</tt>". Es besteht keine Notwendigkeit, für <tt>value</tt> überhaupt Flash-Speicher zu reservieren.<br />
<br />
Auch Zeiger-Indirektionen sind problemlos möglich. Zu beachten ist, dass <tt>__flash</tt> auf der richtigen Seite des "<tt>*</tt>" in der Zeigerdeklaration bzw. -definition steht:<br />
* '''Rechts vom <tt>*</tt>:''' Der Zeiger selbst liegt im Flash<br />
* '''Links vom <tt>*</tt>:''' Der Zeiger enthält eine Flash-Adresse<br />
<br />
<syntaxhighlight lang="c"><br />
// val ist eine Variable im Flash<br />
const __flash int val = 42;<br />
<br />
// pval liegt auch im Flash und enthält die Adresse von val<br />
const __flash int* const __flash pval = &val;<br />
<br />
int get_val (void)<br />
{<br />
// liest den Wert von val über die in pval abgelegte Adresse<br />
return *pval;<br />
}<br />
</syntaxhighlight><br />
<br />
=== Blöcke ===<br />
<br />
Um Speicherbereiche vom Flash in den RAM zu kopieren, gibt es zwei Möglichkeiten: Zum einen können wie bei <tt>progmem</tt> beschreiben die Funktionen der avr-libc wie <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, <tt>movmem_P</tt>, etc. verwendet werden:<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
// Eine Datenstruktur<br />
typedef struct<br />
{<br />
int id;<br />
char buf[10];<br />
} data_t;<br />
<br />
extern void uart_send (const void*, size_t);<br />
<br />
void send_data (const __flash data_t *pdata)<br />
{<br />
// buf wird auf dem Stack angelegt<br />
data_t buf;<br />
<br />
// Kopiere Daten vom Flash nach buf ins RAM<br />
memcpy_P (&buf, pdata, sizeof (data_t));<br />
<br />
// Sende die Daten in buf<br />
uart_send (&buf, sizeof (data_t));<br />
}<br />
</syntaxhighlight><br />
<br />
Zum anderen kann eine Struktur auch über direktes Kopieren ins RAM geladen werden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdlib.h><br />
<br />
// Eine Datenstruktur<br />
typedef struct<br />
{<br />
int id;<br />
char buf[10];<br />
} data_t;<br />
<br />
extern void uart_send (const void*, size_t);<br />
<br />
void send_data (const __flash data_t *pdata)<br />
{<br />
// Kopiere Daten ins RAM. buf wird auf dem Stack angelegt<br />
const data_t buf = *pdata;<br />
<br />
// Verwendet die Daten in buf<br />
uart_send (&buf, sizeof (data_t));<br />
}<br />
</syntaxhighlight><br />
<br />
=== Strings ===<br />
<br />
Natürlich können auch Strings im Flash abgelegt werden und auch mit Funktionen wie <tt>strcpy_P</tt> aus der avr-libc verarbeitet werden. Zudem ist es möglich, Flash-Zeiger mit der Adresse eines String-Literals zu initialisieren:<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
#define FSTR(X) ((const __flash char[]) { X } )<br />
<br />
const __flash char * const __flash array[] = <br />
{<br />
FSTR ("Hund"), FSTR ("Katze"), FSTR ("Maus")<br />
};<br />
<br />
size_t get_len (uint8_t tier)<br />
{<br />
return strlen_P (array[tier]);<br />
}<br />
</syntaxhighlight><br />
<br />
Leider sieht der Embedded-C Draft nicht vor, String-Literale direkt in einem anderen Adress-Space als ''generic'' anzulegen, so dass hier der Umweg über <tt>FSTR</tt> genommen werden muss. Dieses Konstrukt ist nur ausserhalb von Funktionen möglich und kann daher nicht als Ersatz für <tt>PSTR</tt> aus der avr-libc dienen.<br />
<br />
Soll <tt>array</tt> ein 2-dimensonales Array sein anstatt ein 1-dimensionales Array von Zeigern, dann geht das ohne große Verrenkungen:<br />
<br />
<syntaxhighlight lang="c"><br />
// Die 6 ergibt sich aus 1 plus der Länge des längsten Strings "Katze"<br />
const __flash char array[][6] = <br />
{<br />
"Hund", "Katze", "Maus"<br />
};<br />
</syntaxhighlight><br />
<br />
Weiters besteht die Möglichkeit, <tt>array</tt> analog anzulegen, wie man es mit <tt>PROGMEM</tt> machen würde: Jeder String wird explizit angelegt und seine Adresse bei der Initialisierung von <tt>array</tt> verwendet. Dies entspricht dem ersten Beispiel eines 1-dimensionalen Zeigerarrays:<br />
<br />
<syntaxhighlight lang="c"><br />
static const __flash char strHund[] = "Hund";<br />
static const __flash char strKatze[] = "Katze";<br />
static const __flash char strMaus[] = "Maus";<br />
<br />
const __flash char * const __flash array[] = <br />
{<br />
strHund, strKatze, strMaus<br />
};<br />
</syntaxhighlight><br />
<br />
=== Casts ===<br />
<br />
Embedded C fordert, dass zwei Adress-Spaces entweder disjunkt sind – d.h. sie enthalten keine gemeinsamen Adressen – oder aber ein Space komplett im anderen enthalten ist, also eine Teilmengen-Beziehung besteht. Die Adress-Spaces von avr-gcc sind so implementiert, dass jeder Space Teilmenge jedes anderes ist. Zwar haben Spaces wie RAM und Flash physikalisch keinen Speicherbereich gemein, allerdings ermöglicht diese Implementierung das Casten von Zeigern zu unterschiedlichen Adress-Spaces<ref>Im Gegensatz zu einem Attribute wie <tt>progmem</tt> ist ein (Adress Space) Qualifier Teil des Zeiger-Typs.</ref>: <br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdbool.h><br />
<br />
char read_char (const char *address, bool data_in_flash)<br />
{<br />
if (data_in_flash)<br />
return *(const __flash char*) address;<br />
else<br />
return *address;<br />
}<br />
</syntaxhighlight><br />
<br />
Der Cast selbst erzeugt keinen zusätzlichen Code, da eine RAM-Adresse und eine Flash-Adresse die gleiche Binärdarstellung haben. Allerdings wird über den nach <tt>__flash</tt> gecasteten Zeiger anders zugegriffen, nämlich per LPM.<br />
<br />
=== Jenseits von __flash ===<br />
<br />
Ausser <tt>__flash</tt> gibt es auch folgende Address-Spaces:<br />
<br />
==== <tt>__flash</tt>''N'' ====<br />
<br />
<tt>__flash</tt>''N'' mit ''N'' = 1..5 sind fünf weitere Spaces, die analog zu <tt>__flash</tt> funktionieren und deren Zeiger ebenfalls 16 Bit breit sind. avr-gcc erwartet, dass die zugehörigen Daten, welche in die Section <tt>.progmem</tt>''N''<tt>.data</tt> abgelegt werden, so lokatiert sind, dass das high-Byte der Adresse (Bits 16..23) gerade ''N'' ist.<br />
<br />
Weil Daten- und Code-Layout höchst projektspezifisch sind, werden diese Sections im Standard Linker-Skript nicht beschrieben. Um funktionsfähigen Code zu erhalten, muss daher ein eigenes Linker-Skript zur Verfügung gestellt werden, das diese Sections beschreibt, oder es kann eine Erweiterung des Standard Skripts bereitgestellt werden falls dies möglich ist.<br />
<br />
;Beispiel: Eine Applikation, die <tt>__flash2</tt> verwendet. Die zugehörende Section <tt>.progmem2.data</tt> wird hinter <tt>.text</tt> angeordnet aber vor den Initializern für <tt>.data</tt>. Dazu wird beim Linken das ld-Skript Fragment per <tt>-Tflash12.ld</tt> angegeben, welches dann an der gewünschten Stelle in das default Skript eingefügt wird:<br />
:{| <!-- Tabelle bitte für korrekte Einrückung belassen --><br />
|-<br />
|<pre><br />
SECTIONS<br />
{<br />
.flash2 :<br />
{<br />
. = MAX (ABSOLUTE(0x20000), .);<br />
PROVIDE (__flash2_start = .);<br />
. = ALIGN(2);<br />
*(.flash2.text*)<br />
*(.progmem2.data*)<br />
PROVIDE (__flash2_end = .);<br />
<br />
ASSERT (__flash2_start == __flash2_end || __flash2_start >= ABSOLUTE(0x20000),<br />
"__flash2 data in .progmem2.data below 0x20000");<br />
ASSERT (__flash2_start == __flash2_end || __flash2_end <= ABSOLUTE(0x30000),<br />
"__flash2 data in .progmem2.data exceeds 0x30000");<br />
}<br />
}<br />
INSERT AFTER .text<br />
</pre><br />
|}<br />
<br />
==== <tt>__memx</tt> ====<br />
<br />
Dieser Address-Space implementiert 3-Byte Zeiger und unterstützt Lesen über 64KiB-Segmentgrenzen hinweg. Das MSB (Bit 23) gibt dabei an, ob der <tt>__memx</tt>-Zeiger eine Flash-Adresse enthält (Bit23 = 0) oder eine RAM-Adresse (Bit23 = 1), was folgenden Code erlaubt:<br />
<br />
<syntaxhighlight lang="c"><br />
const __memx int a_flash = 42;<br />
const int a_ram = 100;<br />
<br />
int get_a (const __memx int* pa)<br />
{<br />
return *pa;<br />
}<br />
<br />
int main (void)<br />
{<br />
return get_a (&a_flash) + get_a (&a_ram);<br />
}</syntaxhighlight><br />
<br />
Dies bedeutet, dass erst zur ''Laufzeit'' entschieden werden kann, ob <tt>get_a</tt> die Daten aus dem RAM oder aus dem Flash lesen soll, was <tt>__memx</tt> im Vergleich zu den anderen Address-Spaces langsamer macht. Ausserdem ist zu beachten, dass <tt>__memx</tt>-Zeiger zwar 24-Bit Zeiger sind, die zugrundeliegende Adress-Arithmetik jedoch gemäß dem C-Standard erfolgt, also als 16-Bit Arithmetik. Bestehende Funktion der avr-libc wie z.B. printf_P funktionieren damit ebensowenig wie printf! Wenn man <tt>__memx</tt> verwenden will, braucht man dafür eigene Funktionen.<br />
<br />
=== __flash, progmem und Portierbarkeit ===<br />
<br />
Da ab er aktuellen Compilerversion 4.7 sowohl <tt>__flash</tt> als auch <tt>PROGMEM</tt> und die <tt>pgm_read</tt>-Funktionen zur Verfügung stehen, ergibt sich die Frage, welche Variante "besser" ist und wie zwischen ihnen hin- und her zu portieren ist.<br />
<br />
Zunächst sei erwähnt, dass <tt>__flash</tt> kein Ersatz für <tt>PROGMEM</tt> ist, sondern lediglich eine Alternative dazu. Das "alte" progmem wird weiterhin mir gleicher Semantik unterstützt, so dass alter Code ohne Änderungen mit den neueren Compilerversionen übersetzbar bleibt.<br />
<br />
Von der Codegüte her dürften sich keine großen Unterschiede ergeben. Es ist nicht zu erwarten, dass die eine oder die andere Variante wesentlich besseren oder schlechteren Code erzeugt — von einer Ausnahme abgesehen: Der Wert beim Zugriff ist zur Compilezeit bekannt und kann daher eliminiert werden.<br />
<syntaxhighlight lang="c"><br />
static const __flash char x[] = { 'A', 'V', 'R' };<br />
<br />
char foo (void)<br />
{<br />
return x[2];<br />
}<br />
</syntaxhighlight><br />
Dies wird übersetzt wie "<tt>return 'R';</tt>", und das Array <tt>x[]</tt> kann komplett wegoptimiert werden und entfallen.<br />
<br />
==== progmem → __flash ====<br />
<br />
Portierung in diese Richtung bedeutet, alten Code anzupassen. Zwingend ist die Portierung nicht, da <tt>progmem</tt> weiterhin unterstützt wird.<br />
Allerdings ist eine Quelle mit <tt>__flash</tt> besser lesbar, denn der Code wird von den <tt>pgm_read</tt>-Funktionen befreit, die vor allem bei Mehrfach-Indirektion den Code ziemlich verunstalten und unleserlich machen können.<br />
Weiterer Vorteil von <tt>_flash</tt> ist, daß eine striktere Typprüfung erfolgen kann.<br />
<br />
Eine Portierung wird man in zwei Schritten vornehmen:<br />
<br />
;1. Definitionen von Flash-Variablen werden angepasst:<br />
<br />
Vorher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
static const char hund[] PROGMEM = "Hund";<br />
static const char katze[] PROGMEM = "Katze";<br />
static const char maus[] PROGMEM = "Maus";<br />
<br />
const char * const tier[] PROGMEM = <br />
{<br />
hund, katze, maus<br />
};<br />
</syntaxhighlight><br />
|}<br />
<br />
Nachher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
static const __flash char hund[] = "Hund";<br />
static const __flash char katze[] = "Katze";<br />
static const __flash char maus[] = "Maus";<br />
<br />
const __flash char * const __flash tier[] = <br />
{<br />
hund, katze, maus<br />
};<br />
</syntaxhighlight><br />
|}<br />
<br />
Der Header <tt>avr/pgmspace.h</tt> wird nicht mehr benötigt. Im Gegensatz zu <tt>progmem</tt> müssen Qualifier immer links von der definierten Variablen stehen; bei Attributen wie <tt>progmem</tt> ist das mehr oder weniger egal.<br />
<br />
Nachdem diese Anpassung erfolgreich abgeschlossen ist, folgt Schritt<br />
<br />
; 2. Der Code wird von <tt>pgm_read</tt>-Aufrufen bereinigt:<br />
<br />
Vorher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
extern const char *tier[];<br />
<br />
char first_letter (uint8_t i)<br />
{<br />
const char* ptier = (const char*) pgm_read_word (&tier[i]);<br />
return (char) pgm_read_byte (&ptier[0]);<br />
}<br />
</syntaxhighlight><br />
|}<br />
<br />
Nachher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <stdint.h><br />
<br />
extern const __flash char * const __flash tier[];<br />
<br />
char first_letter (uint8_t i)<br />
{<br />
return tier[i][0];<br />
}<br />
</syntaxhighlight><br />
|}<br />
<br />
=== Von-Neumannisierung „zu Fuß“ ===<br />
<br />
„Wenn der Prophet nicht zum Berg geht, muss der Berg zum Propheten kommen“.<br />
<br />
Bei Mikrocontrollern mit weniger als 64 KiB Gesamtspeicher ist das mit dem <tt>__flash</tt> oder <tt>PROGMEM</tt> nicht nur lästig sondern erfordert eine Vielzahl von Bibliotheksfunktionen (hier: die auf _P enden) die alle fast dasselbe machen.<br />
<br />
Neuere PIC-Mikrocontroller sowie (limitiert auf LPM) AVR xMegas verfügen bereits über eine Von-Neumannisierung von RAM und Flash in Hardware, nur bei AVRs „will der Prophet nicht zum Berg“, da geht das nicht.<br />
<br />
Hier behilft man sich mit einem Satz aus Inline-Funktionen und Makros, die je nach Bit 15 des Zeigers RAM oder Flash lesen. So setzen die Makros <tt>F(x)</tt> (x als String-Konstante) bzw, <tt>FP(x)</tt> (x als Flash-Adresse) das Bit 15 der Adresse. Die darauf ausgerichtete Bibliotheksfunktion (bspw. ein selbst geschriebener <tt>printf()</tt>-Ersatz) verarbeitet dann den Formatstring aus RAM oder Flash und kommt auch mit <tt>"%s"</tt>-Substitutionen problemlos zurecht.<br />
<br />
== Dateien direkt im Flash einbinden ==<br />
<br />
Wenn man größere Dateien direkt im Programm einbinden will, ohne sie vorher in C Quelltext umzuwandeln, muss man das mit dem Linker machen. Wie das geht steht hier.<br />
<br />
* [http://www.atmel.com/webdoc/avrlibcreferencemanual/FAQ_1faq_binarydata.html Atmel, avr gcc Dokumentation]<br />
* [http://nongnu.org/avr-libc/user-manual/FAQ.html#faq_binarydata Nongnu avr gcc Dokumentation]<br />
<br />
Wie man das dann praktisch umsetzt, sieht man in diesem Beitrag.<br />
<br />
* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056910 Forumsbeitrag]: Binärdateien mittels Linker einbinden<br />
* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056947 Forumsbeitrag]: Ein kleines Tool zum Umwandeln von Binärdateien in C-Quelltext.<br />
<br />
== Flash in der Anwendung schreiben ==<br />
<br />
Bei AVRs mit "self-programming"-Option – auch bekannt als [[Bootloader]]-Support – können Teile des Flash-Speichers vom Anwendungsprogramm beschrieben werden. Dies ist nur möglich, wenn die Schreibfunktion in einem besonderen Speicherbereich, der Boot-Section des Programmspeichers/Flash, abgelegt ist.<br />
<br />
Bei einigen kleinen AVRs gibt es keine gesonderte Boot-Section, bei diesen kann der Flashspeicher von jeder Stelle des Programms geschrieben werden. Für Details sei hier auf das jeweilige Controller-Datenblatt und die Erläuterungen zum Modul boot.h der avr-libc verwiesen. Es existieren auch Application-Notes dazu bei atmel.com, die auf avr-gcc-Code übertragbar sind.<br />
<br />
Siehe auch: <br />
* Forumsbeitrag [http://www.mikrocontroller.net/topic/163632#1561622 Daten in Programmspeicher speichern]<br />
<br />
== EEPROM ==<br />
<br />
Möchte man Werte aus einem Programm heraus so speichern, dass sie auch nach dem Abschalten der Versorgungsspannung noch erhalten bleiben und nach dem Wiederherstellen der Versorgungsspannung bei erneutem Programmstart wieder zur Verfügung stehen, dann benutzt man das EEPROM.<br />
<br />
Schreib- und Lesezugriffe auf den EEPROM-Speicher erfolgen über die im Modul eeprom.h der avr-libc definierten Funktionen. Mit diesen Funktionen können einzelne Bytes, Datenworte (16 Bit), Fließkommawerte (32 Bit, single-precision, float) und Datenblöcke geschrieben und gelesen werden.<br />
<br />
Diese Funktionen kümmern sich auch um diverse Details, die bei der Benutzung des EEPROMs normalerweise notwendig sind:<br />
* EEPROM-Operationen sind im Vergleich relativ langsam. Man muss daher darauf achten, dass eine vorhergehende Operation abgeschlossen ist, ehe die nächste Operation mit dem EEPROM gestartet wird. Die in der avr-libc implementierten Funktionen aus eeprom.h berücksichtigten dies. Soll beim Aufruf einer EEPROM-Funktion sichergestellt werden, dass diese nicht intern in einer Warteschleife auf den Abschluss der vorherigen Operation wartet, kann vorher per eeprom_is_ready testen, ob der Zugriff auf den EEPROM-Speicher sofort möglich ist.<br />
* Es ist darauf zu achten, dass die EEPROM-Funktionen nicht durch einen Interrupt unterbrochen werden. Einige Phasen des Zugriffs sind zeitkritisch und müssen in einer definierten bzw. begrenzten Anzahl von Takten durchgeführt werden. Durch einen unterbrechenden Interrupt würde diese Restriktion nicht mehr eingehalten. Auch dieses Detail wird von den avr-libc Funktionen berücksichtigt, so dass man sich als C-Programmierer nicht darum kümmern muss. Innerhalb der Funktionen werden Interrupts vor der "EEPROM-Sequenz" global deaktiviert und im Anschluss, falls vorher auch schon eingeschaltet, wieder aktiviert.<br />
<br />
Man beachte, dass der EEPROM-Speicher nur eine begrenzte Anzahl von Schreibzugriffen zulässt. Beschreibt man eine EEPROM-Zelle öfter als die im Datenblatt zugesicherte Anzahl (typisch 100.000), wird die Funktion der Zelle nicht mehr garantiert. Dies gilt für jede einzelne Zelle. <br />
<br />
Bei geschickter Programmierung (z.&nbsp;B. Ring-Puffer), bei der die zu beschreibenden Zellen regelmäßig gewechselt werden, kann man eine deutlich höhere Anzahl an Schreibzugriffen, bezogen auf den gesamten EEPROM-Speicher, erreichen. Auf jeden Fall sollte man aber eine Abschätzung über die zu erwartende Lebensdauer des EEPROM durchführen. Wird ein Wert im EEPROM im Durchschnitt nur einmal pro Woche verändert, wird die garantierte Anzahl der Schreibzyklen innerhalb der voraussichtlichen Verwendungszeit des Controllers sicherlich nicht erreicht werden. Welcher Controller ist schon 100000 / 52 = 1923 Jahre im Einsatz? In diesem Fall lohnt es sich daher nicht, erweiterte Programmfunktionen zu implementieren, mit denen die Anzahl der Schreibzugriffe minimiert wird.<br />
<br />
Eine weitere Möglichkeit, Schreibzyklen einzusparen, besteht in der Vorabprüfung, ob der zu speichernde Wert im EEPROM bereits enthalten ist und nur veränderte Werte zu schreiben. In aktuelleren Versionen der avr-libc sind bereits Funktionen enthalten, die solche Prüfungen enthalten (eeprom_update_*).<br />
<br />
Eine dritte Möglichkeit speichert alle Daten zunächst im RAM, wo sie beliebig oft beschrieben werden können. Nur beim Ausschalten oder beim Ausfall der Stromversorgung werden die Daten in den EEPROM geschrieben. Wie man das richtig macht sieht man im Artikel [[Speicher#EEPROM Schreibzugriffe minimieren | Speicher]].<br />
<br />
Lesezugriffe können beliebig oft durchgeführt werden. Sie unterliegen keinen Einschränkungen in Bezug auf deren Anzahl. <br />
<br />
=== EEMEM ===<br />
Um eine Variable im EEPROM anzulegen, stellt die avr-libc das Makro EEMEM zur Verfügung:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdint.h><br />
#include <avr/eeprom.h><br />
<br />
/* Byte */<br />
uint8_t eeFooByte EEMEM = 123;<br />
<br />
/* Wort */<br />
uint16_t eeFooWord EEMEM = 12345;<br />
<br />
/* float */<br />
float eeFooFloat EEMEM;<br />
<br />
/* Byte-Array */<br />
uint8_t eeFooByteArray1[] EEMEM = { 18, 3, 70 };<br />
uint8_t eeFooByteArray2[] EEMEM = { 30, 7, 79 };<br />
<br />
/* 16-bit unsigned short feld */<br />
uint16_t eeFooWordArray1[4] EEMEM;<br />
</syntaxhighlight><br />
<br />
Die grundsätzliche Vorgehensweise ist identisch zur Verwendung von PROGMEM. Auch hier erzeugt man sich spezielle attributierte Variablen (EEMEM erledigt das), die vom Compiler/Linker nicht wie normale Variablen behandelt werden. Compiler/Linker kümmern sich zwar darum, dass diesen Variablen eine Adresse zugewiesen wird, diese Adresse ist dann aber die Adresse der 'Variablen' im EEPROM. Um die dort gespeicherten Werte zu lesen bzw. zu schreiben, übergibt man diese Adresse an spezielle Funktionen, die die entsprechenden Werte aus dem EEPROM holen bzw. das EEPROM neu beschreiben.<br />
<br />
Die mittels EEMEM erzeugten 'Variablen' sind also mehr als Platzhalter zu verstehen, denn als echte Variablen. Es geht nur darum, im C-Programm symbolische Namen zur Verfügung zu haben, anstatt mit echten EEPROM-Adressen hantieren zu müssen, etwas, das grundsätzlich aber auch genauso gut möglich ist. Nur muss man sich in diesem Fall dann selbst darum kümmern, dass mehrere 'Variablen' ohne Überschneidung im EEPROM angeordnet werden.<br />
<br />
=== Bytes lesen/schreiben ===<br />
<br />
Die avr-libc Funktion zum Lesen eines Bytes heißt eeprom_read_byte. Parameter ist die Adresse des Bytes im EEPROM. Geschrieben wird über die Funktion eeprom_write_byte mit den Parametern Adresse und Inhalt. Anwendungsbeispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#define EEPROM_DEF 0xFF<br />
<br />
void eeprom_example (void)<br />
{<br />
uint8_t myByte;<br />
<br />
// myByte lesen (Wert = 123)<br />
myByte = eeprom_read_byte (&eeFooByte);<br />
<br />
// der Wert 99 wird im EEPROM an die Adresse der<br />
// Variablen eeFooByte geschrieben<br />
myByte = 99;<br />
eeprom_write_byte(&eeFooByte, myByte); // schreiben<br />
<br />
myByte = eeprom_read_byte (&eeFooByteArray1[1]); <br />
// myByte hat nun den Wert 3<br />
<br />
// Beispiel fuer eeprom_update_byte: die EEPROM-Zelle wird nur<br />
// dann beschrieben, wenn deren Inhalt sich vom Parameterwert<br />
// unterscheidet. In diesem Beispiel erfolgt also kein Schreib-<br />
// zugriff, da die Werte gleich sind.<br />
eeprom_update_byte(&eeFooByte, myByte);<br />
<br />
<br />
// Beispiel zur "Sicherung" gegen leeres EEPROM nach "Chip Erase"<br />
// (z. B. wenn die .eep-Datei nach Programmierung einer neuen Version<br />
// des Programms nicht in den EEPROM uebertragen wurde und EESAVE<br />
// deaktiviert ist (unprogrammed/1)<br />
// <br />
// Vorsicht: wenn EESAVE "programmed" ist, hilft diese Sicherung nicht<br />
// weiter, da die Speicheraddressen in einem neuen/erweiterten Programm<br />
// moeglicherweise verschoben wurden. An der Stelle &eeFooByte steht<br />
// dann u.U. der Wert einer anderen Variable aus einer "alten" Version.<br />
<br />
uint8_t fooByteDefault = 222;<br />
if ((myByte = eeprom_read_byte (&eeFooByte)) == EEPROM_DEF)<br />
{<br />
myByte = fooByteDefault;<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
=== Wort lesen/schreiben ===<br />
<br />
Schreiben und Lesen von Datenworten erfolgt analog zur Vorgehensweise bei Bytes:<br />
<br />
<syntaxhighlight lang="c"><br />
// lesen<br />
uint16_t myWord = eeprom_read_word (&eeFooWord);<br />
<br />
// schreiben<br />
eeprom_write_word (&eeFooWord, 2222);<br />
</syntaxhighlight><br />
<br />
=== Block lesen/schreiben ===<br />
<br />
Lesen und Schreiben von Datenblöcken erfolgt über die Funktionen <code>eeprom_read_block()</code> bzw. <code>eeprom_write_block()</code>. Die Funktionen erwarten drei Parameter: die Adresse der Quell- bzw. Zieldaten im RAM, die EEPROM-Adresse und die Länge des Datenblocks in Bytes als <code>size_t</code>.<br />
<syntaxhighlight lang="c"><br />
uint8_t myByteBuffer[3];<br />
uint16_t myWordBuffer[4];<br />
<br />
void eeprom_block_example (void)<br />
{<br />
/* Datenblock aus EEPROM lesen */<br />
<br />
/* liest 3 Bytes ab der von eeFooByteArray1 definierten EEPROM-Adresse<br />
in das RAM-Array myByteBuffer */<br />
eeprom_read_block (myByteBuffer, eeFooByteArray1, 3);<br />
<br />
/* dito mit etwas Absicherung betr. der Länge */<br />
eeprom_read_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));<br />
<br />
/* und nun mit 16-Bit Array */<br />
eeprom_read_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));<br />
<br />
/* Datenblock in EEPROM schreiben */<br />
eeprom_write_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));<br />
eeprom_write_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));<br />
}<br />
</syntaxhighlight><br />
<br />
=== Fließkommawerte lesen/schreiben ===<br />
<br />
In der avr-libc stehen auch EEPROM-Funktionen für Variablen des Typs float (Fließkommazahlen mit "einfacher" Genauigkeit) zur Verfügung.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/eeprom.h><br />
<br />
float eeFloat EEMEM = 12.34f;<br />
<br />
float void eeprom_float_example(float value)<br />
{<br />
/* float in EEPROM schreiben */<br />
eeprom_write_float(&eeFloat, value);<br />
<br />
/* float aus EEPROM lesen */<br />
return eeprom_read_float(&eeFloat);<br />
}</syntaxhighlight><br />
<br />
=== EEPROM-Speicherabbild in .eep-Datei ===<br />
<br />
Mit den zum Compiler gehörenden Werkzeugen kann der aus den Variablendeklarationen abgeleitete EEPROM-Inhalt in eine Datei geschrieben werden. Die übliche Dateiendung ist .eep, Daten im Intel Hex-Format. Damit können Standardwerte für den EEPROM-Inhalt im Quellcode definiert werden. <br />
<br />
Makefiles nach WinAVR/MFile-Vorlage enthalten bereits die notwendigen Einstellungen, siehe dazu die Erläuterungen im [[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]].<br />
<br />
Der Inhalt der eep-Datei muss ebenfalls zum Mikrocontroller übertragen werden, wenn die Initialisierungswerte aus der Deklaration vom Programm erwartet werden. Ansonsten enthält der EEPROM-Speicher nach der Übertragung des Programmers mittels ISP abhängig von der Einstellung der EESAVE-Fuse<ref>vgl. Datenblatt Abschnitt Fuse Bits</ref> nicht die korrekten Werte:<br />
; EESAVE = 0 (programmed): Die Daten im EEPROM bleiben erhalten. Werden sie nicht neu geschrieben, so enthält das EEPROM evtl. Daten, die nicht mehr zum Programm passen.<br />
; EESAVE = 1 (unprogrammed): Beim Programmieren werden die Daten im EEPROM gelöscht, also auf 0xff gesetzt.<br />
<br />
Als Sicherung kann man im Programm nochmals die Standardwerte vorhalten, beim Lesen auf 0xFF prüfen und gegebenenfalls einen Standardwert nutzen. Das geht natürlich nur, wenn 0xFF selbst nicht als Datenwert vorkommen kann.<br />
<syntaxhighlight lang="c"><br />
#define DUTY_CYCLE_DEFAULT 0x80<br />
<br />
uint8_t eeDutyCycle EEMEM; // Platzhalter für EEPROM<br />
uint8_t DutyCycle; // die echte Variable<br />
<br />
<br />
int main(void)<br />
{<br />
DutyCycle = eeprom_read_byte( &eeDutyCycle );<br />
if( DutyCycle == 0xFF ) // das allererste mal. Im EEPROM steht noch kein gültiger Wert<br />
{<br />
DutyCycle = DUTY_CYCLE_DEFAULT;<br />
eeprom_writeByte( &eeDutyCycle, DutyCycle );<br />
}<br />
<br />
...<br />
</syntaxhighlight><br />
<br />
=== Direkter Zugriff auf EEPROM-Adressen ===<br />
<br />
Will man direkt auf bestimmte EEPROM Adressen zugreifen, dann sind folgende IAR-kompatiblen Makros <tt>_EEGET</tt> und <tt>_EEPUT</tt> hilfreich, um sich die Typecasts zu ersparen.<br />
<br />
;Hinweis: Die nachfolgend gezeigten Makros und Zugriffe auf absolute Adressen sind in Normalfall nicht nötig und nur auf sehr wenige, spezielle Fälle beschränkt! Im Normalfall sollte man auf absolute Adressen möglichst nicht zugreifen und den Compiler seine Arbeit machen lassen, der verwaltet die Variablen und deren Adressen meist besser als der Programmierer. Der Zugriff auf Variablen im EEPROM sollte immer über ihren Namen erfolgen.<br />
<br />
Verwendung:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/eeprom.h><br />
<br />
_EEPUT (0x20, 128); // Byte-Wert 128 an Adresse 0x20 schreiben<br />
...<br />
uint8_t val = _EEGET (0x20); // EEPROM-Wert von Adresse 0x20 lesen<br />
</syntaxhighlight><br />
<br />
=== Was steckt dahinter? - EEPROM-Register ===<br />
Auch wenn es normalerweise keinen Grund gibt, in C selbst an den Steuerregistern herumzuschrauben - die eeprom Funktionen erledigen das alles zuverlässig - der Vollständigkeit halber der registermässige technische Unterbau.<br />
Um das EEPROM anzusteuern, sind drei Register von Bedeutung:<br />
;EEAR: Hier werden die Adressen eingetragen zum Schreiben oder Lesen. Dieses Register unterteilt sich nochmal in EEARH und EEARL, da in einem 8-Bit-Register keine 512 Adressen adressiert werden können.<br />
;EEDR: Hier werden die Daten eingetragen, die geschrieben werden sollen, bzw. es enthält die gelesenen Daten.<br />
;EECR: Ist das Kontrollregister für das EEPROM<br />
<br />
Das EECR steuert den Zugriff auf das EEPROM und ist wie folgt aufgebaut:<br />
<br />
:{| class="wikitable" style="text-align:center"<br />
|+ '''Aufbau des EECR-Registers'''<br />
|-<br />
!Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|-<br />
! Name<br />
| - || - || - ||- || EERIE || EEMWE || EEWE || EERE<br />
|-<br />
! Read/Write<br />
| R || R || R || R || R/W || R/W || R/W || R/W<br />
|-<br />
!Init Value<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''Bedeutung der Bits'''<br />
<br />
;Bit 4-7: nicht belegt<br />
<br />
;Bit 3 (EERIE): ''EEPROM Ready Interrupt Enable'': Wenn das Bit gesetzt ist und globale Interrupts erlaubt sind in Register SREG (Bit 7), wird ein Interrupt ausgelöst nach Beendigung des Schreibzyklus (EEPROM Ready Interrupt). Ist einer der beiden Bits 0, wird kein Interrupt ausgelöst.<br />
<br />
;Bit 2 EEMWE): ''EEPROM Master Write Enable'': Dieses Bit bestimmt, dass, wenn EEWE = 1 gesetzt wird (innerhalb von 4 Taktzyklen), das EEPROM beschrieben wird mit den Daten in EEDR bei Adresse EEAR. Wenn EEMWE = 0 ist und EEWE = 1 gesetzt wird, hat das keine Auswirkungen. Der Schreibvorgang wird dann nicht ausgelöst. Nach 4 Taktzyklen wird das Bit EEMWE automatisch wieder auf 0 gesetzt. Dieses Bit löst den Schreibvorgang nicht aus, es dient sozusagen als Sicherungsbit für EEWE.<br />
<br />
;Bit 1 (EEWE): ''EEPROM Write Enable'': Dieses Bit löst den Schreibvorgang aus, wenn es auf 1 gesetzt wird, sofern vorher EEMWE gesetzt wurde und seitdem nicht mehr als 4 Taktzyklen vergangen sind. Wenn der Schreibvorgang abgeschlossen ist, wird dieses Bit automatisch wieder auf 0 gesetzt und, sofern EERIE gesetzt ist, ein Interrupt ausgelöst. Ein Schreibvorgang sieht typischerweise wie folgt aus:<br />
:# EEPROM-Bereitschaft abwarten (EEWE=0) <br />
:# Adresse übergeben an EEAR<br />
:# Daten übergeben an EEDR<br />
:# Schreibvorgang auslösen in EECR mit Bit EEMWE=1 und EEWE=1<br />
:# (Optional) Warten, bis Schreibvorgang abgeschlossen ist<br />
<br />
;Bit 0 EERE: ''EEPROM Read Enable'': Wird dieses Bit auf 1 gesetzt wird das EEPROM an der Adresse in EEAR ausgelesen und die Daten in EEDR gespeichert. Das EEPROM kann nicht ausgelesen werden, wenn bereits eine Schreiboperation gestartet wurde. Es ist daher zu empfehlen, die Bereitschaft vorher zu prüfen. Das EEPROM ist lesebereit, wenn das Bit EEWE=0 ist. Ist der Lesevorgang abgeschlossen, wird das Bit wieder auf 0 gesetzt, und das EEPROM ist für neue Lese- und Schreibbefehle wieder bereit. Ein typischer Lesevorgang kann wie folgt aufgebaut sein:<br />
:# Bereitschaft zum Lesen prüfen (EEWE=0)<br />
:# Adresse übergeben an EEAR<br />
:# Lesezyklus auslösen mit EERE = 1<br />
:# Warten, bis Lesevorgang abgeschlossen EERE = 0<br />
:# Daten abholen aus EEDR<br />
<br />
= Die Nutzung von sprintf und printf =<br />
<br />
Um komfortabel, d.h. formatiert, Ausgaben auf ein Display oder die serielle Schnittstelle zu tätigen, bieten sich '''sprintf''' oder '''printf''' an. Alle *printf-Varianten sind jedoch ziemlich speicherintensiv und der Einsatz in einem Mikrocontroller mit knappem Speicher muss sorgsam abgewogen werden.<br />
<br />
Bei '''sprintf''' wird die Ausgabe zunächst in einem Puffer vorbereitet und anschließend mit einfachen Funktionen zeichenweise ausgegeben. Es liegt in der Verantwortung des Programmierers, genügend Platz im Puffer für die erwarteten Zeichen bereitzuhalten.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdio.h><br />
#include <stdint.h><br />
<br />
// ...<br />
// nicht dargestellt: Implementierung von uart_puts (vgl. Abschnitt UART)<br />
// ...<br />
<br />
uint16_t counter;<br />
<br />
// Ausgabe eines unsigned Integerwertes<br />
void uart_puti( uint16_t value )<br />
{<br />
uint8_t puffer[20];<br />
<br />
sprintf( puffer, "Zählerstand: %u", value );<br />
uart_puts( puffer );<br />
}<br />
<br />
int main()<br />
{<br />
counter = 5;<br />
<br />
uart_puti( counter );<br />
uart_puti( 42 );<br />
}<br />
</syntaxhighlight><br />
<br />
Eine weitere elegante Möglichkeit besteht darin, den STREAM stdout (Standardausgabe) auf eine eigene Ausgabefunktion umzuleiten. Dazu wird dem Ausgabemechanismus der C-Bibliothek eine neue Ausgabefunktion bekannt gemacht, deren Aufgabe es ist, ein einzelnes Zeichen auszugeben. Wohin die Ausgabe dann tatsächlich stattfindet, ist Sache der Ausgabefunktion. Im Beispiel unten wird auf UART ausgegeben. Alle anderen, höheren Funktionen wie z.&nbsp;B. '''printf''', greifen letztendlich auf diese primitive Ausgabefunktion zurück. <br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdio.h><br />
<br />
void uart_init(void);<br />
<br />
// a. Deklaration der primitiven Ausgabefunktion<br />
int uart_putchar(char c, FILE *stream);<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 1)<br />
static FILE mystdout = FDEV_SETUP_STREAM( uart_putchar, NULL, _FDEV_SETUP_WRITE );<br />
<br />
// c. Definition der Ausgabefunktion<br />
int uart_putchar( char c, FILE *stream )<br />
{<br />
if( c == '\n' )<br />
uart_putchar( '\r', stream );<br />
<br />
loop_until_bit_is_set( UCSRA, UDRE );<br />
UDR = c;<br />
return 0;<br />
}<br />
<br />
void uart_init(void)<br />
{<br />
/* hier µC spezifischen Code zur Initialisierung */<br />
/* des UART einfügen... s.o. im AVR-GCC-Tutorial */<br />
<br />
// Beispiel: <br />
//<br />
// myAVR Board 1.5 mit externem Quarz Q1 3,6864 MHz<br />
// 9600 Baud 8N1<br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
// Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt)<br />
#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)<br />
<br />
UCSRB |= (1<<TXEN) | (1<<RXEN); // UART TX und RX einschalten<br />
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1 <br />
<br />
UBRRH = (uint8_t)( UART_UBRR_CALC( UART_BAUD_RATE, F_CPU ) >> 8 );<br />
UBRRL = (uint8_t)UART_UBRR_CALC( UART_BAUD_RATE, F_CPU );<br />
}<br />
<br />
int main(void)<br />
{<br />
int16_t antwort = 42;<br />
uart_init();<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 2)<br />
stdout = &mystdout;<br />
<br />
// Anwendung<br />
printf( "Die Antwort ist %d.\n", antwort );<br />
return 0;<br />
}<br />
<br />
// Quelle: avr-libc-user-manual-1.4.3.pdf, S.74<br />
// + Ergänzungen<br />
</syntaxhighlight><br />
<br />
<br />
Sollen Fließkommazahlen ausgegeben werden, muss im Makefile eine andere (größere) Version der [[FAQ#Aktivieren_der_Floating_Point_Version_von_sprintf_beim_WinAVR_mit_AVR-Studio|printflib]] eingebunden werden.<br />
<br />
= Anmerkungen =<br />
<references/><br />
<br />
= TODO =<br />
* Aktualisierung Register- und Bitbeschreibungen an aktuelle AVR<br />
* "naked"-Funktionen [http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html][http://arduino.stackexchange.com/questions/8758/arduino-interruption-on-pin-change]<br />
<br />
[[Kategorie:avr-gcc Tutorial| ]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR-GCC-Tutorial&diff=107262AVR-GCC-Tutorial2025-01-28T08:07:37Z<p>Heha: pardon, Detail korrigiert</p>
<hr />
<div>Dieses Tutorial soll den Einstieg in die Programmierung von Atmel [[AVR]]-Mikrocontrollern in der Programmiersprache [[C]] mit dem freien C-Compiler [[avr-gcc]] aus der [http://gcc.gnu.org/ GNU Compiler Collection] (GCC) erleichtern.<br />
<br />
Vorausgesetzt werden Grundkenntnisse der Programmiersprache C. Diese Kenntnisse kann man sich online erarbeiten, z. B. mit dem [http://www.schellong.de/c.htm C Tutorial von Helmut Schellong] ([[C|Liste von C-Tutorials]]). Nicht erforderlich sind Vorkenntnisse in der Programmierung von Mikrocontrollern.<br />
<br />
= Vorwort =<br />
<br />
In diesem Text wird häufig auf die Standardbibliothek avr-libc verwiesen, für die es eine [http://www.nongnu.org/avr-libc/user-manual/index.html Online-Dokumentation] gibt, in der sich auch viele nützliche Informationen zum Compiler und zur Programmierung von AVR-Controllern finden. Beim Paket [[WinAVR]] gehört die avr-libc Dokumentation zum Lieferumfang und wird mitinstalliert.<br />
<br />
Der Compiler und die Standardbibliothek avr-libc werden ständig weiterentwickelt. Einige Unterschiede, die sich im Verlauf der Entwicklung ergeben haben, werden hier und im Artikel [[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen]] zwar angesprochen, Anfängern und Umsteigern sei jedoch empfohlen, eine aktuelle Versionen zu nutzen.<br />
<br />
Das ursprüngliche Tutorial stammt von Christian Schifferle, viele neue Abschnitte und aktuelle Anpassungen von Martin Thomas.<br />
<br />
Dieses Tutorial ist in [[Media:AVR-GCC-Tutorial.pdf|PDF-Form]] erhältlich (zur Zeit nur eine sehr veraltete Version).<br />
<br />
== Weiterführende Kapitel ==<br />
<br />
Um dieses riesige Tutorial etwas überschaubarer zu gestalten, wurden einige Kapitel ausgelagert, die nicht unmittelbar mit den Grundlagen von avr-gcc in Verbindung stehen. All diese Seiten gehören zur [[:Kategorie:avr-gcc Tutorial]].<br />
<br />
;UART: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der UART|Der UART]]''<br />
<br />
;ADC: → Hauptartikel: ''[[AVR-GCC-Tutorial/Analoge Ein- und Ausgabe|Analoge Ein- und Ausgabe (ADC)]]''<br />
<br />
;Timer: → Hauptartikel: ''[[AVR-GCC-Tutorial/Die Timer und Zähler des AVR|Die Timer und Zähler des AVR]]''<br />
<br />
;LCD: → Hauptartikel: ''[[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Ansteuerung]]''<br />
<br />
;Watchdog: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der Watchdog|Der Watchdog]]''<br />
<br />
;Assembler: → Hauptartikel: ''[[AVR-GCC-Tutorial/Assembler und Inline-Assembler|Assembler und Inline-Assembler]]''<br />
<br />
;alte Quellen anpassen: → Hauptartikel: ''[[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen anpassen]]''<br />
<br />
;Makefiles: → Hauptartikel: ''[[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]]'' sowie als Alternative für sehr kleine Projekte → Hauptartikel: ''[[C ohne Makefile]]''<br />
<br />
= Benötigte Werkzeuge =<br />
<br />
Um eigene Programme für AVRs mittels einer AVR-Toolchain zu erstellen wird folgende Hard- und Software benötigt:<br />
<br />
* Eine AVR-Toolchain bestehend aus avr-gcc, den avr-Binutils (Assembler, Linker, etc) und einer Standard-C Bibliothek. Üblich ist die AVR-LibC, die auch quasi in allen avr-gcc Distributionen enthalten ist.<br />
<br />
Hardware wird keine benötigt – bis auf einen PC natürlich, auf dem der Compiler ablaufen kann. Selbst ohne AVR-Hardware kann man also bereits C-Programme für AVRs schreiben, compiliern und sich das Look-and-Feel von avr-gcc sowie von IDEs wie [[Atmel Studio]], Eclipse oder leichtgewichtigeren Entwicklungsumbgebungen anschauen. Selbst das Debuggen und Simulieren ist mithilfe entsprechender Tools wie Debugger und Simulator in gewissen Grenzen möglich.<br />
<br />
Um Programme für AVRs mittels einer AVR-Toolchain zu testen, wird folgende Hard- und Software benötigt:<br />
<br />
* Platine oder Versuchsaufbau für die Aufnahme eines AVR-Controllers, der vom avr-gcc Compiler unterstützt wird.<ref>Für eine Liste der unterstützten COntroller siehe die Dokumentation des Compilers oder [http://www.nongnu.org/avr-libc/user-manual/index.html#supported_devices AVR-Libc: Supported Devices].</ref> Dieses Testboard kann durchaus auch selbst gelötet oder auf einem Steckbrett aufgebaut werden. Einige Registerbeschreibungen dieses Tutorials beziehen sich auf den inzwischen veralteten AT90S2313. Der weitaus größte Teil des Textes ist aber für alle Controller der AVR-Familie gültig. <br />
<br />
:Brauchbare Testplattformen sind auch das [[STK500]] und der [[AVR Butterfly]] von Atmel. Weitere Infos findet man in den Artikeln [[AVR#Starterkits|AVR Starterkits]] und [[AVR-Tutorial: Equipment]].<br />
<br />
* Programmiersoftware und -[[AVR In System Programmer |hardware]] z. B. PonyProg (siehe auch: [[Pony-Prog Tutorial]]) oder [[AVRDUDE]] mit [[STK200]]-Dongle oder die von Atmel verfügbare Hard- und Software ([[STK500]], Atmel AVRISP, [[AVR-Studio]]).<br />
<br />
* Nicht unbedingt erforderlich, aber zur Simulation und zum Debuggen unter MS-Windows recht nützlich: [[AVR-Studio]].<br />
<br />
* Wer unter Windows und Linux gleichermassen entwickeln will, der sollte sich die [http://www.eclipse.org/ IDE Eclipse for C/C++ Developers] und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] ansehen. Beide sind unter Windows und Linux einfach zu installieren, siehe auch [[AVR Eclipse]]. Ebenfalls unter Linux und Windows verfügbar ist die Entwicklungsumgebung [http://www.codeblocks.org/ Code::Blocks]<ref>Aktuelle, stabile Versionen sind als Nightly Builds regelmäßig im [http://forums.codeblocks.org/ Forum] verfügbar.</ref>. Innerhalb dieser Entwicklungsumgebung können ohne die Installation zusätzlicher Plugins "AVR-Projekte" angelegt werden. Für Linux gibt es auch noch das [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=25220 KontrollerLab].<br />
<br />
= Was tun, wenn's nicht klappt? =<br />
<br />
* Herausfinden, ob es tatsächlich ein avr(-gcc) spezifisches Problem ist oder nur die eigenen C-Kenntnisse einer Auffrischung bedürfen. Allgemeine C-Fragen kann man eventuell "beim freundlichen Programmierer zwei Büro-, Zimmer- oder Haustüren weiter" loswerden. Ansonsten: [[C]]-Buch (gibt's auch "gratis" online) lesen.<br />
<br />
* Die [[AVR Checkliste]] durcharbeiten.<br />
<br />
* Die '''[http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc]''' lesen, vor allem (aber nicht nur) den Abschnitt Related Pages/'''Frequently Asked Questions''' = Oft gestellte Fragen (und Antworten dazu). Z.Zt leider nur in englischer Sprache verfügbar.<br />
<br />
* Den Artikel [[AVR-GCC]] in diesem Wiki lesen.<br />
<br />
* Das [http://www.mikrocontroller.net/forum/gcc GCC-Forum auf www.mikrocontroller.net] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das avr-gcc-Forum bei [http://www.avrfreaks.net AVRfreaks] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das [http://lists.gnu.org/archive/html/avr-gcc-list/ Archiv der avr-gcc Mailing-Liste] nach vergleichbaren Problemen absuchen.<br />
<br />
* Nach Beispielcode suchen. Vor allem im ''Projects''-Bereich von [http://www.avrfreaks.net AVRfreaks] (anmelden).<br />
<br />
* Google oder yahoo befragen schadet nie.<br />
<br />
* Bei Problemen mit der Ansteuerung interner AVR-Funktionen mit C-Code: das Datenblatt des Controllers lesen (ganz und am Besten zweimal). Datenblätter sind auf den [http://www.atmel.com Atmel Webseiten] als pdf-Dateien verfügbar. Das komplette Datenblatt (complete) und nicht die Kurzfassung (summary) verwenden.<br />
<br />
* Die Beispielprogramme im [[AVR-Tutorial]] sind zwar in AVR-Assembler verfasst, Erläuterungen und Vorgehensweisen sind aber auch auf C-Programme übertragbar.<br />
<br />
* Einen Beitrag in eines der Foren oder eine Mail an die Mailing-Liste schreiben. Dabei möglichst viel Information geben: Controller, Compilerversion, genutzte Bibliotheken, Ausschnitte aus dem Quellcode oder besser ein [http://www.mikrocontroller.net/topic/72767#598986 Testprojekt] mit allen notwendigen Dateien, um das Problem nachzuvollziehen, sowie genaue Fehlermeldungen bzw. Beschreibung des Fehlverhaltens. Bei Ansteuerung externer Geräte die Beschaltung beschreiben oder skizzieren (z. B. mit [http://www.tech-chat.de/ Andys ASCII Circuit]). Siehe dazu auch: '''[http://www.tty1.net/smart-questions_de.html "Wie man Fragen richtig stellt"]'''.<br />
<br />
= Erzeugen von Maschinencode =<br />
<br />
Aus dem C-Quellcode erzeugt der avr-gcc Compiler (zusammen mit Hilfsprogrammen wie z.&nbsp;B. Präprozessor, Assembler und Linker) Maschinencode für den AVR-Controller. Üblicherweise liegt dieser Code dann im Intel Hex-Format vor ("Hex-Datei"). Die Programmiersoftware (z.&nbsp;B. [[AVRDUDE]], PonyProg oder AVRStudio/STK500-plugin) liest diese Datei ein und überträgt die enthaltene Information (den Maschinencode) in den Speicher des Controllers. Im Prinzip sind also "nur" der avr-gcc-Compiler (und wenige Hilfsprogramme) mit den "richtigen" Optionen aufzurufen, um aus C-Code eine "Hex-Datei" zu erzeugen. Grundsätzlich stehen dazu drei verschiedene Ansätze zur Verfügung:<br />
<br />
* Die Verwendung einer integrierten Entwicklungsumgebung (IDE = '''I'''ntegrated '''D'''evelopment '''E'''nvironment), bei der alle Einstellungen z.&nbsp;B. in Dialogboxen durchgeführt werden können. Unter Anderem kann AVRStudio ab Version 4.12 (kostenlos auf [http://www.atmel.com/ atmel.com]) zusammen mit WinAVR als integrierte Entwicklungsumgebung für den Compiler avr-gcc genutzt werden (dazu müssen AVRStudio und WinAVR auf dem Rechner installiert sein). Weitere IDEs (ohne Anspruch auf Vollständigkeit): [http://www.eclipse.org/ Eclipse for C/C++ Developers] (d.h. inkl. CDT) und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] (für diverse Plattformen, u.a. Linux und MS Windows, IDE und Plugin kostenlos), [http://sourceforge.net/projects/kontrollerlab KontrollerLab] (Linux/KDE, kostenlos). [http://www.atmanecl.com/EnglishSite/SoftwareEnglish.htm AtmanAvr] (MS Windows, relativ günstig), KamAVR (MS-Windows, kostenlos, wird augenscheinlich nicht mehr weiterentwickelt), [http://www.amctools.com/vmlab.htm VMLab] (MS Windows, ab Version 3.12 ebenfalls kostenlos). Integrierte Entwicklungsumgebungen unterscheiden sich stark in Ihrer Bedienung und stehen auch nicht für alle Plattformen zur Verfügung, auf denen der Compiler ausführbar ist (z.&nbsp;B. AVRStudio nur für MS-Windows). Zur Anwendung des avr-gcc Compilers mit IDEs sei hier auf deren Dokumentation verwiesen. <br />
<br />
* Die Nutzung des Programms make mit passenden Makefiles. In den folgenden Abschnitten wird die Generierung von Maschinencode für einen AVR ("hex-Datei") aus C-Quellcode ("c-Dateien") anhand von "make" und den "Makefiles" näher erläutert. Viele der darin beschriebenen Optionen findet man auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio (AVRStudio generiert ein makefile in einem Unterverzeichnis des Projektverzeichnisses). <br />
<br />
* Das Generieren des Programms ohne IDE und ohne Makefile. In diesem Fall muss die Quellcodedatei durch eine vorgefertigte Kommandofolge an den Compiler übergeben werden. Der Artikel [[C ohne Makefile]] zeigt, wie das funktioniert. Diese Vorgehensweise empfiehlt sich jedoch nur für kleine Programme, die nicht auf verschiedene Quellcodedateien verteilt sind.<br />
<br />
Beim Wechsel vom makefile-Ansatz nach WinAVR-Vorlage zu AVRStudio ist darauf zu achten, dass AVRStudio (Stand: AVRStudio Version 4.13) bei einem neuen Projekt die Optimierungsoption (vgl. Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|AVR-GCC-Tutorial/Exkurs: Makefiles]], typisch: -Os) nicht einstellt und die mathematische Bibliothek der avr-libc (libm.a, Linker-Option -lm) nicht einbindet. (Hinweis: Bei Version 4.16 wird beides bereits gesetzt). Beides ist Standard bei Verwendung von makefiles nach WinAVR-Vorlage und sollte daher auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio "manuell" eingestellt werden, um auch mit AVRStudio kompakten Code zu erzeugen.<br />
<br />
= Einführungsbeispiel =<br />
<br />
Zum Einstieg ein kleines Beispiel, an dem die Nutzung des Compilers und der Hilfsprogramme (der sogenannten ''Toolchain'') demonstriert wird. Detaillierte Erläuterungen folgen in den weiteren Abschnitten dieses Tutorials.<br />
<br />
Das Programm soll auf einem AVR Mikrocontroller einige Ausgänge ein- und andere ausschalten. Das Beispiel ist für einen ATmega16 programmiert ([http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf Datenblatt]), kann aber sinngemäß für andere Controller der AVR-Familie modifiziert werden. <br />
<br />
Ein kurzes Wort zur Hardware: Bei diesem Programm werden alle Pins von PORTB auf Ausgang gesetzt, und einige davon werden auf HIGH andere auf LOW gesetzt. Das kann je nach angeschlossener Hardware an diesen Pins kritisch sein. Am ungefährlichsten ist es, wenn nichts an den Pins angeschlossen ist und man die Funktion des Programmes durch eine Spannungsmessung mit einem Multimeter kontrolliert. Die Spannung wird dabei zwischen GND-Pin und den einzelnen Pins von PORTB gemessen.<br />
<br />
Zunächst der Quellcode der Anwendung, der in einer Text-Datei mit dem Namen ''main.c'' abgespeichert wird.<br />
<br />
<syntaxhighlight lang="c"><br />
/* Alle Zeichen zwischen Schrägstrich-Stern <br />
und Stern-Schrägstrich sind Kommentare */<br />
<br />
// Zeilenkommentare sind ebenfalls möglich<br />
// alle auf die beiden Schrägstriche folgenden<br />
// Zeichen einer Zeile sind Kommentar<br />
<br />
#include <avr/io.h> // (1)<br />
<br />
int main (void) { // (2)<br />
<br />
DDRB = 0xFF; // (3)<br />
PORTB = 0x03; // (4)<br />
<br />
while(1) { // (5)<br />
/* "leere" Schleife*/ // (6)<br />
} // (7)<br />
<br />
/* wird nie erreicht */<br />
return 0; // (8)<br />
}<br />
</syntaxhighlight><br />
<br />
# In dieser Zeile wird eine sogenannte Header-Datei eingebunden. In <code>avr/io.h</code> sind die Registernamen definiert, die im späteren Verlauf genutzt werden. Auch unter Windows wird ein&nbsp;<code>/</code> zur Kennzeichnung von Unterverzeichnissen in Include-Dateinamen verwendet und kein&nbsp;<code>\</code>.<br />
# Hier beginnt das eigentliche Programm. Jedes C-Programm beginnt mit den Anweisungen in der Funktion <code>main</code>.<br />
# Die Anschlüsse eines AVR (Pins) werden zu Blöcken zusammengefasst, einen solchen Block bezeichnet man als Port. Beim ATmega16 hat jeder Port 8 Anschlüsse, bei kleineren AVRs können einem Port auch weniger als 8 Anschlüsse zugeordnet sein. Da per Definition (Datenblatt) alle gesetzten Bits in einem Datenrichtungsregister den entsprechenden Anschluss auf Ausgang schalten, werden mit DDRB=0xff alle Anschlüsse des Ports B als Ausgänge eingestellt.<br />
# Die den ersten beiden Bits des Ports zugeordneten Anschlüsse (PB0 und PB1) werden 1, alle anderen Anschlüsse des Ports B (PB2-PB7) zu 0. Aktivierte Ausgänge (logisch 1 oder "high") liegen auf Betriebsspannung (VCC, meist 5 Volt), nicht aktivierte Ausgänge führen 0 Volt (GND, Bezugspotential). Es ist sinnvoll, sich möglichst frühzeitig eine alternative Schreibweise beizubringen, die wegen der leichteren Überprüfbarkeit und Portierbarkeit oft im weiteren Tutorial und in Forenbeiträgen benutzt wird. Die Zuordnung sieht in diesem Fall so aus, Näheres dazu im Artikel [[Bitmanipulation]]:<syntaxhighlight lang="c">PORTB = (1<<PB1) | (1<<PB0);</syntaxhighlight><br />
# ist der Beginn der sogenannte ''Hauptschleife'' (main-loop). Dies ist eine Endlosschleife, welche kontinuierlich wiederkehrende Befehle enthält.<br />
# In diesem Beispiel ist die Hauptschleife leer. Der Controller durchläuft die Schleife immer wieder, ohne dass etwas passiert. Eine solche Schleife ist notwendig, da es auf dem Controller kein Betriebssystem gibt, das nach Beendigung des Programmes die Kontrolle übernehmen könnte. Ohne diese Schleife kehrt das Programm aus <code>main</code> zurück, alle Interrupts werden deaktiviert und eine Endlosschleife betreten.<br />
# Ende der Hauptschleife und Sprung zur passenden, öffnenden Klammer, also zu 5.<br />
# ist das Programmende. Die Zeile ist nur aus Gründen der C-Kompatibilität enthalten: <syntaxhighlight lang="c">int main(void)</syntaxhighlight> besagt, dass die Funktion einen int-Wert zurückgibt. Die Anweisung wird aber nicht erreicht, da das Programm die Hauptschleife nie verlässt.<br />
<br />
Um diesen Quellcode in ein lauffähiges Programm zu übersetzen, wird hier ein Makefile genutzt. Das verwendete Makefile findet sich auf der Seite [[Beispiel Makefile]] und basiert auf der Vorlage, die in WinAVR mitgeliefert wird und wurde bereits angepasst (Controllertyp ATmega16). Man kann das Makefile bearbeiten und an andere Controller anpassen oder sich mit dem Programm MFile menügesteuert ein Makefile "zusammenklicken". Das Makefile speichert man unter dem Namen <code>Makefile</code> (ohne Endung) im selben Verzeichnis, in dem auch die Datei <code>main.c</code> mit dem Programmcode abgelegt ist. Detailliertere Erklärungen zur Funktion von Makefiles finden sich im Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|Exkurs: Makefiles]].<br />
<br />
<pre><br />
D:\beispiel>dir<br />
<br />
Verzeichnis von D:\beispiel<br />
<br />
28.11.2006 22:53 <DIR> .<br />
28.11.2006 22:53 <DIR> ..<br />
28.11.2006 20:06 118 main.c<br />
28.11.2006 20:03 16.810 Makefile<br />
2 Datei(en) 16.928 Bytes<br />
</pre><br />
<br />
Nun gibt man ''make all'' ein. Falls das mit WinAVR installierte Programmers Notepad genutzt wird, gibt es dazu einen Menüpunkt im Tools Menü. Sind alle Einstellungen korrekt, entsteht eine Datei <code>main.hex</code>, in welcher der Code für den AVR enthalten ist. <br />
<pre><br />
D:\beispiel>make all<br />
<br />
-------- begin --------<br />
avr-gcc (GCC) 3.4.6<br />
Copyright (C) 2006 Free Software Foundation, Inc.<br />
This is free software; see the source for copying conditions. There is NO<br />
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.<br />
<br />
Compiling C: main.c<br />
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -f<br />
unsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef<br />
-Wa,-adhlns=obj/main.lst -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c -<br />
o obj/main.o<br />
<br />
Linking: main.elf<br />
avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -funs<br />
igned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -W<br />
a,-adhlns=obj/main.o -std=gnu99 -Wundef -MD -MP -MF .dep/main.elf.d obj/main.o<br />
--output main.elf -Wl,-Map=main.map,--cref -lm<br />
<br />
Creating load file for Flash: main.hex<br />
avr-objcopy -O ihex -R .eeprom main.elf main.hex<br />
</pre><br />
<br />
Der Inhalt der hex-Datei kann nun zum Controller übertragen werden. Dies kann z.&nbsp;B. über In-System-Programming ([[ISP]]) erfolgen, das im [[AVR-Tutorial: Equipment]] beschrieben ist. Makefiles nach der WinAVR/MFile-Vorlage sind für die Nutzung des Programms [[AVRDUDE]] vorbereitet. Wenn man den Typ und Anschluss des Programmiergerätes richtig eingestellt hat, kann mit ''make program'' die Übertragung mittels AVRDUDE gestartet werden. Jede andere Software, die hex-Dateien lesen und zu einem AVR übertragen kann<ref>z.&nbsp;B. [[Pony-Prog_Tutorial|Ponyprog]], yapp, AVRStudio</ref>, kann natürlich ebenfalls genutzt werden.<br />
<br />
Startet man nun den Controller (Reset-Taster oder Stromzufuhr aus/an), werden vom Programm die Anschlüsse PB0 und PB1 auf 1 gesetzt. Man kann mit einem Messgerät nun an diesem Anschluss die Betriebsspannung messen oder eine [[LED]] leuchten lassen (Anode an den Pin, Vorwiderstand nicht vergessen). An den Anschlüssen PB2-PB7 misst man 0 Volt. Eine mit der Anode mit einem dieser Anschlüsse verbundene LED leuchtet nicht.<br />
<br />
= Ganzzahlige Datentypen (Integer) =<br />
<br />
Bei der Programmierung von Mikrokontrollern ist die Definition einiger ganzzahliger Datentypen sinnvoll, an denen eindeutig die Bit-Länge abgelesen werden kann.<br />
<br />
Standardisierte Datentypen werden in der Header-Datei <code>stdint.h</code> definiert, die folgendermaßen eingebunden werden kann:<br />
<syntaxhighlight lang="c">#include <stdint.h></syntaxhighlight><br />
<br />
{| {{Tabelle}}<br />
|+ '''int-Typen aus <code>stdint.h</code> (C99)'''<br/>&nbsp;<br />
|- bgcolor="#d0d0ff"<br />
!colspan="5"| Vorzeichenbehaftete int-Typen<br />
|- bgcolor="#e8e8ff"<br />
! Typname || Bit-Breite ||colspan="2"| Wertebereich<br />
|align="center| '''C-Entsprechung''' (avr-gcc)<br />
|-<br />
|<code>int8_t</code> ||align="right"| 8 || −128 ⋯ 127 || −2<sup>7</sup> ⋯ 2<sup>7</sup>−1 || <code>signed char</code><br />
|-<br />
|<code>int16_t</code> ||align="right"| 16 || −32768 ⋯ 32767 || −2<sup>15</sup> ⋯ 2<sup>15</sup>−1 || <code>signed short</code>, <code>signed int</code><br />
|-<br />
|<code>int32_t</code> ||align="right"| 32 || −2147483648 ⋯ 2147483647 || −2<sup>31</sup> ⋯ 2<sup>31</sup>−1 || <code>signed long</code><br />
|-<br />
|<code>int64_t</code> ||align="right"| 64 || −9223372036854775808 ⋯ 9223372036854775807 || −2<sup>63</sup> ⋯ 2<sup>63</sup>−1 || <code>signed long long</code><br />
|- bgcolor="#d0d0ff"<br />
!colspan="5"| Vorzeichenlose int-Typen<br />
|- bgcolor="#e8e8ff"<br />
! Typname || Bit-Breite ||colspan="2"| Wertebereich<br />
|align="center| '''C-Entsprechung''' (avr-gcc)<br />
|-<br />
|<code>uint8_t</code> ||align="right"| 8 || 0 ⋯ 255 || 0 ⋯ 2<sup>8</sup>−1 || <code>unsigned char</code><br />
|-<br />
|<code>uint16_t</code> ||align="right"| 16 || 0 ⋯ 65535 || 0 ⋯ 2<sup>16</sup>−1 || <code>unsigned short</code>, <code>unsigned int</code><br />
|-<br />
|<code>uint32_t</code> ||align="right"| 32 || 0 ⋯ 4294967295 || 0 ⋯ 2<sup>32</sup>−1 || <code>unsigned long</code><br />
|-<br />
|<code>uint64_t</code> ||align="right"| 64 || 0 ⋯ 18446744073709551615 || 0 ⋯ 2<sup>64</sup>−1 || <code>unsigned long long</code><br />
|}<br />
<br />
Neben den Typen gibt es auch Makros für die Bereichsgrenzen wie <code>INT8_MIN</code> oder <code>UINT16_MAX</code>. Siehe dazu auch: [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html Dokumentation der avr-libc: Standard Integer Types].<br />
<br />
= Grundsätzlicher Programmaufbau eines µC-Programms =<br />
<br />
Wir unterscheiden zwischen 2 verschiedenen Methoden, um ein<br />
Mikrocontroller-Programm zu schreiben, und zwar völlig unabhängig davon, in<br />
welcher Programmiersprache das Programm geschrieben wird.<br />
<br />
== Sequentieller Programmablauf ==<br />
<br />
[[Image:Sequentielle Programme.gif|left]]<br />
Bei dieser Programmiertechnik wird eine Endlosschleife programmiert, welche im<br />
Wesentlichen immer den gleichen Aufbau hat. Es wird hier nach dem sogenannten EVA-Prinzip gehandelt. EVA steht für "Eingabe, Verarbeitung, Ausgabe".<br />
{{Absatz}}<br />
<br />
== Interruptgesteuerter Programmablauf ==<br />
<br />
[[Image:Interrupt Programme.gif|left]]<br />
Bei dieser Methode werden beim Programmstart zuerst die gewünschten Interruptquellen aktiviert und dann in eine Endlosschleife gegangen, in welcher Dinge erledigt werden können, welche nicht zeitkritisch sind. Wenn ein Interrupt ausgelöst wird, so wird automatisch die zugeordnete Interruptfunktion ausgeführt.<br />
{{Absatz}}<br />
<br />
= Zugriff auf Register =<br />
<br />
Die AVR-Controller verfügen über eine Vielzahl von Registern. Die meisten<br />
davon sind sogenannte Schreib-/Leseregister. Das heißt, das Programm kann die<br />
Inhalte der Register sowohl auslesen als auch beschreiben.<br />
<br />
Register haben einen besonderen Stellenwert bei den AVR Controllern. Sie dienen dem Zugriff auf die Ports und die Schnittstellen des Controllers. Wir unterscheiden zwischen 8-Bit und 16-Bit Registern. Vorerst behandeln wir die 8-Bit Register.<br />
<br />
Einzelne Register sind bei allen AVRs vorhanden, andere wiederum nur bei bestimmten Typen. So sind beispielsweise die Register, welche für den Zugriff auf den UART notwendig sind, selbstverständlich nur bei denjenigen Modellen vorhanden, welche über einen integrierten Hardware UART bzw. USART verfügen.<br />
<br />
Die Namen der Register sind in den Headerdateien zu den entsprechenden AVR-Typen definiert. Dazu muss man den Namen der controllerspezifischen Headerdatei nicht kennen. Es reicht aus, die allgemeine Headerdatei ''avr/io.h'' einzubinden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
</syntaxhighlight><br />
<br />
Ist im Makefile der MCU-Typ z.&nbsp;B. mit dem Inhalt atmega8 definiert (und wird somit per -mmcu=atmega8 an den Compiler übergeben), wird beim Einlesen der io.h-Datei implizit ("automatisch") auch die iom8.h-Datei mit den Register-Definitionen für den ATmega8 eingelesen.<br />
<br />
<!-- Wohl besser als Anhang - spaeter... --><br />
Intern wird diese "Automatik" wie folgt realisiert: Der Controllertyp wird dem Compiler als Parameter übergeben (vgl. ''avr-gcc -c -mmcu=atmega16 [...]'' im Einführungsbeispiel). Wird ein Makefile nach der WinAVR/mfile-Vorlage verwendet, setzt man die Variable ''MCU'', der Inhalt dieser Variable wird dann an passender Stelle für die Compilerparameter verwendet. Der Compiler definiert intern eine dem mmcu-Parameter zugeordnete "Variable" (genauer: ein Makro) mit dem Namen des Controllers, vorangestelltem ''__AVR_'' und angehängten Unterstrichen (z.&nbsp;B. wird bei ''-mmcu=atmega16'' das Makro ''__AVR_ATmega16__'' definiert). Beim Einbinden der Header-Datei ''avr/io.h'' wird geprüft, ob das jeweilige Makro definiert ist und die zum Controller passende Definitionsdatei eingelesen. Zur Veranschaulichung einige Ausschnitte aus einem Makefile:<br />
<br />
<pre><br />
[...]<br />
# MCU Type ("name") setzen:<br />
MCU = atmega16<br />
[...]<br />
<br />
[...]<br />
## Verwendung des Inhalts von MCU (hier atmega16) fuer die <br />
## Compiler- und Assembler-Parameter<br />
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)<br />
ALL_CPPFLAGS = -mmcu=$(MCU) -I. -x c++ $(CPPFLAGS) $(GENDEPFLAGS)<br />
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)<br />
[...]<br />
<br />
[...]<br />
## Aufruf des Compilers:<br />
## mit den Parametern ($(ALL_CFLAGS) ist -mmcu=$(MCU)[...] = -mmcu=atmega16[...]<br />
$(OBJDIR)/%.o : %.c<br />
@echo<br />
@echo $(MSG_COMPILING) $<<br />
$(CC) -c $(ALL_CFLAGS) $< -o $@ <br />
[...]<br />
</pre><br />
<br />
Da --mmcu=atmega16 übergeben wurde, wird __AVR_ATmega16__ definiert und kann in avr/io.h zur Fallunterscheidung genutzt werden:<br />
<br />
<syntaxhighlight lang="c"><br />
// avr/io.h <br />
// (bei WinAVR-Standardinstallation in C:\WinAVR\avr\include\avr)<br />
[...]<br />
#if defined (__AVR_AT94K__)<br />
# include <avr/ioat94k.h><br />
// [...]<br />
#elif defined (__AVR_ATmega16__)<br />
// da __AVR_ATmega16__ definiert ist, wird avr/iom16.h eingebunden:<br />
# include <avr/iom16.h><br />
// [...]<br />
#else<br />
# if !defined(__COMPILING_AVR_LIBC__)<br />
# warning "device type not defined"<br />
# endif<br />
#endif<br />
</syntaxhighlight><br />
<br />
Die Beispiele in den folgenden Abschnitten demonstrieren den Zugriff auf Register anhand der Register für I/O-Ports (PORTx, DDRx, PINx), die Vorgehensweise ist jedoch für alle Register (z.&nbsp;B. die des UART, ADC, SPI) analog.<br />
<br />
== Schreiben in Register ==<br />
<br />
Zum Schreiben kann man Register einfach wie eine Variable setzen.<ref>In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Schreibzugriff über die Funktion outp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt, outp() ist nicht mehr erforderlich.</ref><br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
/* Setzt das Richtungsregister des Ports A auf 0xff <br />
(alle Pins als Ausgang, vgl. Abschnitt Zugriff auf Ports): */<br />
DDRA = 0xff; <br />
<br />
/* Setzt PortA auf 0x03, Bit 0 und 1 "high", restliche "low": */<br />
PORTA = 0x03; <br />
<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binär 00011111 = Hexadezimal 1F<br />
DDRB = 0x1F; /* direkte Zuweisung - unübersichtlich */<br />
<br />
/* Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit<br />
aber übersichtlicher und selbsterklärend: */<br />
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);<br />
<br />
while (1);<br />
}<br />
</syntaxhighlight><br />
<br />
Die ausführliche Schreibweise sollte bevorzugt verwendet werden, da dadurch die Zuweisungen selbsterklärend sind und somit der Code leichter nachvollzogen werden kann. Atmel verwendet sie auch bei Beispielen in Datenblätten und in den allermeisten Quellcodes zu Application-Notes. Mehr zu der Schreibweise mit "|" und "<<" findet man unter [[Bitmanipulation]].<br />
<br />
Der gcc C-Compiler unterstützt ab Version 4.3.0 Konstanten im Binärformat, z.&nbsp;B. DDRB&nbsp;=&nbsp;0b00011111. Diese Schreibweise ist jedoch nur in GNU-C verfügbar und nicht in ISO-C definiert. Man sollte sie daher nicht verwenden, wenn Code mit anderen ausgetauscht oder mit anderen Compilern bzw. älteren Versionen des gcc genutzt werden soll.<br />
<br />
== Verändern von Registerinhalten ==<br />
<br />
Einzelne Bits setzt und löscht man "Standard-C-konform" mittels logischer (Bit-) Operationen. <br />
<br />
<syntaxhighlight lang="c"><br />
x |= (1 << Bitnummer); // Hiermit wird ein Bit in x gesetzt<br />
x &= ~(1 << Bitnummer); // Hiermit wird ein Bit in x geloescht<br />
</syntaxhighlight><br />
<br />
Es wird jeweils nur der Zustand des angegebenen Bits geändert, der vorherige Zustand der anderen Bits bleibt erhalten. <br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
#define MEINBIT 2<br />
...<br />
PORTA |= (1 << MEINBIT); /* setzt Bit 2 an PortA auf 1 */<br />
PORTA &= ~(1 << MEINBIT); /* loescht Bit 2 an PortA */<br />
</syntaxhighlight><br />
<br />
Mit dieser Methode lassen sich auch mehrere Bits eines Registers gleichzeitig setzen und löschen.<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
DDRA &= ~( (1<<PA0) | (1<<PA3) ); /* PA0 und PA3 als Eingaenge */<br />
PORTA |= ( (1<<PA0) | (1<<PA3) ); /* Interne Pull-Up fuer beide einschalten */<br />
</syntaxhighlight><br />
<br />
Bei bestimmten AVR Registern mit Bits, die durch Beschreiben mit einer logischen 1 gelöscht werden, muss eine absolute Zuweisung benutzt werden. Ein ODER löscht in diesen Registern ALLE gesetzten Bits!<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
TIFR2 = (1<<OCF2A); // Nur Bit OCF2A löschen<br />
</syntaxhighlight><br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind nicht mehr erforderlich.<br />
<br />
Siehe auch:<br />
* [[Bitmanipulation]]<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
<br />
== Lesen aus Registern ==<br />
<br />
Zum Lesen kann man auf Register einfach wie auf eine Variable zugreifen. In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Lesezugriff über die Funktion inp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt und inp() ist nicht mehr erforderlich.<br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdint.h><br />
<br />
uint8_t foo;<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
/* kopiert den Status der Eingabepins an PortB <br />
in die Variable foo: */<br />
foo = PINB; <br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Die Abfrage der Zustände von Bits erfolgt durch Einlesen des gesamten Registerinhalts und ausblenden der Bits deren Zustand nicht von Interesse ist. Einige Beispiele zum Prüfen ob Bits gesetzt oder gelöscht sind:<br />
<br />
<syntaxhighlight lang="c"><br />
#define MEINBIT0 0 <br />
#define MEINBIT2 2<br />
<br />
uint8_t i;<br />
<br />
extern test1();<br />
<br />
// Funkion test1 aufrufen, wenn Bit 0 in Register PINA gesetzt (1) ist<br />
i = PINA; // Inhalt in Arbeitsvariable<br />
i = i & 0x01; // alle Bits bis auf Bit 0 ausblenden (bitweise und)<br />
// falls das Bit gesetzt war, hat i den Inhalt 1<br />
if ( i != 0 ) { // Ergebnis ungleich 0 (wahr)? <br />
test1(); // dann muss Bit 0 in i gesetzt sein -> Funktion aufrufen<br />
}<br />
// verkürzt:<br />
if ( ( PINA & 0x01 ) != 0 ) {<br />
test1();<br />
}<br />
// nochmals verkürzt:<br />
if ( PINA & 0x01 ) {<br />
test1();<br />
}<br />
// mit definierter Bitnummer:<br />
if ( PINA & ( 1 << MEINBIT0 ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und/oder Bit 2 gesetzt ist. (Bit 0 und 2 also Wert 5) <br />
// (Bedenke: Bit 0 hat Wert 1, Bit 1 hat Wert 2 und Bit 2 hat Wert 4)<br />
if ( PINA & 0x05 ) {<br />
test1(); // Vergleich <> 0 (wahr), also mindestens eines der Bits gesetzt<br />
}<br />
// mit definierten Bitnummern:<br />
if ( PINA & ( ( 1 << MEINBIT0 ) | ( 1 << MEINBIT2 ) ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und Bit 2 gesetzt sind<br />
if ( ( PINA & 0x05 ) == 0x05 ) { // nur wahr, wenn beide Bits gesetzt<br />
test1();<br />
}<br />
<br />
// Funktion test2() aufrufen, wenn Bit 0 gelöscht (0) ist<br />
i = PINA; // einlesen in temporäre Variable<br />
i = i & 0x01; // maskieren von Bit 0<br />
if ( i == 0 ) { // Vergleich ist wahr, wenn Bit 0 nicht gesetzt ist<br />
test2();<br />
}<br />
// analog mit not-Operator<br />
if ( !i ) {<br />
test2();<br />
}<br />
// nochmals verkürzt:<br />
if ( !( PINA & 0x01 ) ) {<br />
test2();<br />
}<br />
</syntaxhighlight><br />
<br />
== Warten auf einen bestimmten Zustand ==<br />
<br />
Es gibt in der Bibliothek avr-libc Funktionen, die warten, bis ein bestimmter Zustand eines Bits erreicht ist. Es ist allerdings normalerweise eine eher unschöne Programmiertechnik, da in diesen Funktionen "blockierend" gewartet wird. Der Programmablauf bleibt also an dieser Stelle stehen, bis das maskierte Ereignis erfolgt ist. Setzt man den [[Watchdog]] ein, muss man darauf achten, dass dieser auch noch getriggert wird (Zurücksetzen des Watchdogtimers). <br />
<br />
Die Funktion '''loop_until_bit_is_set''' wartet in einer Schleife, bis das definierte Bit gesetzt ist. Wenn das Bit beim Aufruf der Funktion bereits gesetzt ist, wird die Funktion sofort wieder verlassen. Das niederwertigste Bit hat die Bitnummer 0. <br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 2 (das dritte Bit) in Register PINA gesetzt (1) ist */<br />
<br />
#define WARTEPIN PINA<br />
#define WARTEBIT PA2<br />
<br />
// mit der avr-libc Funktion:<br />
loop_until_bit_is_set(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// _nicht_ ungleich 0 (also 0) ist.<br />
while ( !(WARTEPIN & (1 << WARTEBIT)) ) {}<br />
...<br />
</syntaxhighlight><br />
<br />
<br />
Die Funktion '''loop_until_bit_is_clear''' wartet in einer Schleife, bis das definierte Bit gelöscht ist. Wenn das Bit beim Aufruf der Funktion bereits gelöscht ist, wird die Funktion sofort wieder verlassen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 4 (das fuenfte Bit) in Register PINB geloescht (0) ist */<br />
#define WARTEPIN PINB<br />
#define WARTEBIT PB4<br />
<br />
// avr-libc-Funktion:<br />
loop_until_bit_is_clear(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// gesetzt (1) ist <br />
while ( WARTEPIN & (1<<WARTEBIT) ) {}<br />
...<br />
</syntaxhighlight><br />
<br />
Universeller und auch auf andere Plattformen besser übertragbar ist die Verwendung von C-Standardoperationen.<br />
<br />
Siehe auch: <br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
* [[Bitmanipulation]]<br />
<br />
== 16-Bit Register (ADC, ICR1, OCR1x, TCNT1, UBRR) ==<br />
<br />
Einige der Portregister in den AVR-Controllern sind 16 Bit breit. Im Datenblatt sind diese Register üblicherweise mit dem Suffix "L" (Low-Byte) und "H" (High-Byte) versehen. Die avr-libc definiert zusätzlich die meisten dieser Variablen die Bezeichnung ohne "L" oder "H". Auf diese Register kann dann direkt zugegriffen werden. Dies ist zum Beispiel der Fall für Register wie ADC oder TCNT1.<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
uint16_t foo;<br />
<br />
/* setzt die Wort-Variable foo auf den Wert der letzten AD-Wandlung */<br />
foo = ADC; <br />
</syntaxhighlight><br />
<br />
Bei anderen Registern, wie zum Beispiel Baudraten-Register, liegen High- und Low-Teil nicht direkt nebeneinander im SFR-Bereich, so dass ein 16-Bit Zugriff nicht möglich ist und der Zugriff zusammengebastelt werden muss:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
...<br />
uint16_t baud = F_CPU / (UART_BAUD_RATE * 16L) -1;<br />
<br />
UBRRH = (uint8_t) (baud >> 8);<br />
UBRRL = (uint8_t) baud;<br />
...<br />
</syntaxhighlight><br />
<br />
Bei einigen AVR-Typen wie ATmega8 oder ATmega16 teilen sich UBRRH und UCSRC die gleiche Speicher-Adresse. Damit der AVR trotzdem zwischen den beiden Registern unterscheiden kann, bestimmt das Bit7 (URSEL), welches Register tatsächlich beschrieben werden soll. ''1000 0011'' (0x83) adressiert demnach UCSRC und übergibt den Wert ''3''. Und ''0000 0011'' (0x3) adressiert UBRRH und übergibt ebenfalls den Wert ''3''. <br />
<br />
Speziell bei den 16-Bit-Timern und auch beim ADC ist es bei allen Zugriffen auf Datenregister erforderlich, dass diese Daten synchronisiert sind. Wenn z.&nbsp;B. bei einem 16-Bit-Timer das High-Byte des Zählregisters gelesen wurde und vor dem Lesezugriff auf das Low-Byte ein Überlauf des Low-Bytes stattfindet, erhält man einen völlig unsinnigen Wert. Auch die Compare-Register müssen synchron geschrieben werden, da es ansonsten zu unerwünschten Compare-Ereignissen kommen kann. <br />
<br />
Beim ADC besteht das Problem darin, dass zwischen den Zugriffen auf die beiden Teilregister eine Wandlung beendet werden kann und der ADC ein neues Ergebnis in ADCL und ADCH schreiben will, wodurch High- und Low-Byte nicht zusammenpassen.<br />
<br />
Um diese Datenmüllproduktion zu verhindern, gibt es in beiden Fällen eine Synchronisation, die jeweils durch den Zugriff auf das Low-Byte ausgelöst wird:<br />
* Bei den Timer-Registern (das gilt für alle TCNT-, OCR- und ICR-Register bei den 16-Bit-Timern) wird bei einem ''Lesezugriff'' auf das Low-Byte automatisch das High-Byte in ein temporäres Register, das ansonsten nach außen nicht sichtbar ist, geschoben. Greift man nun ''anschließend'' auf das High-Byte zu, dann wird eben dieses temporäre Register gelesen.<br />
* Bei einem ''Schreibzugriff'' auf eines der genannten Register wird das High-Byte in besagtem temporären Register zwischengespeichert und erst beim Schreiben des Low-Bytes werden ''beide'' gleichzeitig in das eigentliche Register übernommen.<br />
<br />
Das bedeutet für die Reihenfolge:<br />
* Lesezugriff: Erst Low-Byte, dann High-Byte<br />
* Schreibzugriff: Erst High-Byte, dann Low-Byte<br />
<br />
Des weiteren ist zu beachten, dass es für all diese 16-Bit-Register nur ein einziges temporäres Register gibt, so dass das Auftreten eines Interrupts, in dessen Handler ein solches Register manipuliert wird, bei einem durch ihn unterbrochenen Zugriff i.d.R. zu Datenmüll führt. 16-Bit-Zugriffe sind generell nicht atomar! Wenn mit Interrupts gearbeitet wird, kann es erforderlich sein, vor einem solchen Zugriff auf ein 16-Bit-Register die Interrupt-Bearbeitung zu deaktivieren.<br />
<br />
Beim ADC-Datenregister ADCH/ADCL ist die Synchronisierung anders gelöst. Hier wird beim Lesezugriff (ADCH/ADCL sind logischerweise read-only) auf das Low-Byte ADCL beide Teilregister für Zugriffe seitens des ADC so lange gesperrt, bis das High-Byte ADCH ausgelesen wurde. Dadurch kann der ADC nach einem Zugriff auf ADCL keinen neuen Wert in ADCH/ADCL ablegen, bis ADCH gelesen wurde. Ergebnisse von Wandlungen, die zwischen einem Zugriff auf ADCL und ADCH beendet werden, gehen verloren!<br />
<br />
Nach einem Zugriff auf ADCL muss grundsätzlich ADCH gelesen werden!<br />
<br />
In beiden Fällen – also sowohl bei den Timern als auch beim ADC – werden vom C-Compiler 16-Bit Pseudo-Register zur Verfügung gestellt (z.&nbsp;B. TCNT1H/TCNT1L → TCNT1, ADCH/ADCL → ADC bzw. ADCW), bei deren Verwendung der Compiler automatisch die richtige Zugriffsreihenfolge regelt. In C-Programmen sollten grundsätzlich diese 16-Bit-Register verwendet werden! Sollte trotzdem ein Zugriff auf ein Teilregister erforderlich sein, sind obige Angaben zu berücksichtigen.<br />
<br />
Es ist darauf zu achten, dass auch ein Zugriff auf die 16-Bit-Register vom Compiler in zwei 8-Bit-Zugriffe aufgeteilt wird und dementsprechend genauso nicht-atomar ist wie die Einzelzugriffe. Auch hier gilt, dass u.U. die Interrupt-Bearbeitung gesperrt werden muss, um Datenmüll zu vermeiden.<br />
<br />
Beim ADC gibt es für den Fall, dass eine Auflösung von 8 Bit ausreicht, die Möglichkeit, das Ergebnis "linksbündig" in ADCH/ADCL auszurichten, so dass die relevanten 8 MSB in ADCH stehen. In diesem Fall muss bzw. sollte nur ADCH ausgelesen werden.<br />
<br />
ADC und ADCW sind unterschiedliche Bezeichner für das selbe Registerpaar. Üblicherweise kann man in C-Programmen ADC verwenden, was analog zu den anderen 16-Bit-Registern benannt ist. ADCW (ADC Word) existiert nur deshalb, weil die Headerdateien auch für Assembler vorgesehen sind und es bereits einen Assembler-Befehl namens ''adc'' gibt. <br />
<br />
Im Umgang mit 16-Bit Registern siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Related Pages/Frequently Asked Questions/Nr. 8<br />
* Datenblatt Abschnitt ''Accessing 16-bit Registers''<br />
<br />
== IO-Register als Parameter und Variablen ==<br />
<br />
Um Register als Parameter für eigene Funktionen übergeben zu können, muss man sie als einen volatile uint8_t Pointer übergeben. Zum Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <util/delay.h><br />
<br />
uint8_t key_pressed (volatile uint8_t *inputreg, uint8_t inputbit)<br />
{<br />
static uint8_t last_state = 0;<br />
<br />
if (last_state == (*inputreg & (1<<inputbit)))<br />
return 0; /* keine Änderung */<br />
<br />
/* Wenn doch, warten bis etwaiges Prellen vorbei ist: */<br />
_delay_ms(20);<br />
<br />
/* Zustand für nächsten Aufruf merken: */<br />
last_state = *inputreg & (1<<inputbit);<br />
<br />
/* und den entprellten Tastendruck zurückgeben: */<br />
return *inputreg & (1<<inputbit);<br />
}<br />
<br />
/* Beispiel für einen Funktionsaufruf: */<br />
<br />
void foo (void)<br />
{<br />
uint8_t i = key_pressed (&PINB, PB1);<br />
}<br />
</syntaxhighlight><br />
<br />
Ein Aufruf der Funktion mit call by value würde Folgendes bewirken: Beim Funktionseintritt wird nur eine Kopie des momentanen Portzustandes angefertigt, die sich unabhängig vom tatsächlichen Zustand das Ports nicht mehr ändert, womit die Funktion wirkungslos wäre. Die Übergabe eines Zeigers wäre die Lösung, wenn der Compiler nicht optimieren würde. Denn dadurch wird im Programm nicht von der Hardware gelesen, sondern wieder nur von einem Abbild im Speicher. Das Ergebnis wäre das gleiche wie oben. Mit dem Schlüsselwort volatile sagt man nun dem Compiler, dass die entsprechende Variable entweder durch andere Softwareroutinen (Interrupts) oder durch die Hardware verändert werden kann.<br />
<br />
Siehe auch: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass avr-libc FAQ: "How do I pass an IO port as a parameter to a function?"]<br />
<br />
= Zugriff auf IO-Ports =<br />
<br />
Jeder AVR implementiert eine unterschiedliche Menge an GPIO-Registern<br />
(GPIO - General Purpose Input/Output). Diese Register dienen dazu:<br />
* einzustellen welche der Anschlüsse ("Beinchen") des Controllers als Ein- oder Ausgänge dienen<br />
* bei Ausgängen deren Zustand festzulegen<br />
* bei Eingängen deren Zustand zu erfassen<br />
<br />
Mittels GPIO werden digitale Zustände gesetzt und erfasst, d.h. die Spannung an einem Ausgang wird ein- oder ausgeschaltet und an einem Eingang wird erfasst, ob die anliegende Spannung über oder unter einem bestimmten Schwellwert liegt. Im Datenblatt Abschnitt Electrical Characteristics/DC Characteristics finden sich die Spannungswerte (V_OL, V_OH für Ausgänge, V_IL, V_IH für Eingänge).<br />
<br />
Die Verarbeitung von analogen Eingangswerten und die Ausgabe von Analogwerten wird in Kapitel [[AVR-GCC-Tutorial#Analoge_Ein-_und_Ausgabe|Analoge Ein- und Ausgabe]] behandelt.<br />
<br />
Die physischen Ein- und Ausgänge werden bei AVR-Controllern zu logischen Ports gruppiert.<br />
<br />
Alle Ports werden über Register gesteuert. Dazu sind jedem Port 3 Register zugeordnet:<br />
<br />
{| class="wikitable"<br />
|- <br />
! width="10%"| DDRx<br />
| Datenrichtungsregister für Port'''x'''. <br />
'''x''' entspricht '''A''', '''B''', ''' C''' usw. je nach gewünschtem Port. Bit im Register gesetzt (1) für Ausgang, Bit gelöscht (0) für Eingang.<br />
|- <br />
! PINx<br />
| Eingangsadresse für Port'''x'''. <br />
Zustand des Ports. Die Bits in PINx entsprechen dem Zustand der als Eingang definierten Portpins. Bit 1 wenn Pin "high", Bit 0 wenn Portpin low.<br />
|-<br />
! PORTx<br />
| Datenregister für Port'''x'''. <br />
Dieses Register wird verwendet, um die Ausgänge eines Ports anzusteuern. Bei Pins, die mittels DDRx auf Eingang geschaltet wurden, können über PORTx<br />
die internen Pull-Up Widerstände aktiviert oder deaktiviert werden (1 = aktiv).<br />
|}<br />
<br />
Die folgenden Beispiele gehen von einem AVR aus, der sowohl Port A als auch Port B besitzt. Sie müssen für andere AVRs (zum Beispiel ATmega8/48/88/168) entsprechend angepasst werden.<br />
<br />
== Datenrichtung bestimmen ==<br />
<br />
Zuerst muss die Datenrichtung der verwendeten Pins bestimmt werden. Um dies zu erreichen, wird das Datenrichtungsregister des entsprechenden Ports beschrieben.<br />
<br />
Für jeden Pin, der als Ausgang verwendet werden soll, muss dabei das<br />
entsprechende Bit auf dem Port gesetzt werden. Soll der Pin als Eingang<br />
verwendet werden, muss das entsprechende Bit gelöscht sein.<br />
<br />
Beispiel:<br />
Angenommen am Port B sollen die Pins 0 bis 4 als Ausgänge definiert werden, die noch verbleibenden Pins 5 bis 7 sollen als Eingänge fungieren. Dazu ist es daher notwendig, im für das Port B zuständigen Datenrichtungsregister DDRB folgende Bitkonfiguration einzutragen<br />
<br />
+---+---+---+---+---+---+---+---+<br />
| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |<br />
+---+---+---+---+---+---+---+---+<br />
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br />
<br />
In C liest sich das dann so:<br />
<br />
<syntaxhighlight lang="c"><br />
// in io.h wird u.a. DDRB definiert:<br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binaer 00011111 = Hexadezimal 1F<br />
// direkte Zuweisung - standardkonform */<br />
DDRB = 0x1F; /* <br />
<br />
// Uebersichtliche Alternative - Binaerschreibweise, aber kein ISO-C<br />
DDRB = 0b00011111;<br />
<br />
// Ausfuehrliche Schreibweise: identische Funktionalitaet, mehr Tipparbeit<br />
// aber uebersichtlicher und selbsterklaerend:<br />
DDRB |= (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4); <br />
</syntaxhighlight><br />
<br />
Die Pins 5 bis 7 werden (da 0) als Eingänge geschaltet. Weitere Beispiele:<br />
<br />
<syntaxhighlight lang="c"><br />
// Alle Pins des Ports B als Ausgang definieren:<br />
DDRB = 0xff; <br />
// Pin0 wieder auf Eingang und andere im urspruenglichen Zustand belassen:<br />
DDRB &= ~(1 << DDB0);<br />
// Pin 3 und 4 auf Eingang und andere im urspruenglichen Zustand belassen:<br />
DDRB &= ~((1 << DDB3) | (1 << DDB4));<br />
// Pin 0 und 3 wieder auf Ausgang und andere im ursprünglichen Zustand belassen:<br />
DDRB |= (1 << DDB0) | (1 << DDB3);<br />
// Alle Pins auf Eingang:<br />
DDRB = 0x00;<br />
</syntaxhighlight><br />
<br />
== Vordefinierte Bitnummern für I/O-Register ==<br />
<br />
Die Bitnummern (z.&nbsp;B. PCx, PINCx und DDCx für den Port C) sind in den io*.h-Dateien der avr-libc definiert und dienen lediglich der besseren Lesbarkeit. Man muss diese Definitionen nicht verwenden oder kann auch einfach "immer" PAx, PBx, PCx usw. nutzen, auch wenn der Zugriff auf Bits in DDRx- oder PINx-Registern erfolgt. Für den Compiler sind die Ausdrücke (1<<PC7), (1<<DDC7) und (1<<PINC7) identisch zu (1<<7) (genauer: der Präprozessor ersetzt die Ausdrücke (1<<PC7),... zu (1<<7)). Ein Ausschnitt der Definitionen für Port C eines ATmega32 aus der iom32.h-Datei zur Verdeutlichung (analog für die weiteren Ports):<br />
<br />
<syntaxhighlight lang="c"><br />
...<br />
/* PORTC */<br />
#define PC7 7<br />
#define PC6 6<br />
#define PC5 5<br />
#define PC4 4<br />
#define PC3 3<br />
#define PC2 2<br />
#define PC1 1<br />
#define PC0 0<br />
<br />
/* DDRC */<br />
#define DDC7 7<br />
#define DDC6 6<br />
#define DDC5 5<br />
#define DDC4 4<br />
#define DDC3 3<br />
#define DDC2 2<br />
#define DDC1 1<br />
#define DDC0 0<br />
<br />
/* PINC */<br />
#define PINC7 7<br />
#define PINC6 6<br />
#define PINC5 5<br />
#define PINC4 4<br />
#define PINC3 3<br />
#define PINC2 2<br />
#define PINC1 1<br />
#define PINC0 0<br />
</syntaxhighlight><br />
<br />
<br />
== Digitale Signale ==<br />
<br />
Am einfachsten ist es, digitale Signale mit dem Mikrocontroller zu erfassen bzw. auszugeben.<br />
<br />
== Ausgänge ==<br />
Will man als Ausgang definierte Pins (entsprechende DDRx-Bits = 1) auf Logisch 1 setzen, setzt man die entsprechenden Bits im Portregister.<br />
<br />
Mit dem Befehl<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB = 0x04; /* besser PORTB=(1<<PB2) */<br />
<br />
// Uebersichtliche Alternative - Binaerschreibweise<br />
PORTB = 0b00000100; /* direkte Zuweisung - uebersichtlich */<br />
<br />
</syntaxhighlight><br />
wird also der Ausgang an Pin PB2 gesetzt (Beachte, dass die Bits immer ''von 0 an'' gezählt werden, das niederwertigste Bit ist also Bitnummer 0 und nicht etwa Bitnummer 1).<br />
<br />
Man beachte, dass bei der Zuweisung mittels '''=''' immer alle Pins gleichzeitig angegeben werden. Man sollte also, wenn nur bestimmte Ausgänge geschaltet werden sollen, zuerst den aktuellen Wert des Ports einlesen und das Bit des gewünschten Ports in diesen Wert einfließen lassen. Will man also nur den dritten Pin (Bit Nr. 2) an Port B auf "high" setzen und den Status der anderen Ausgänge unverändert lassen, nutze man diese Form:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB = PORTB | 0x04; /* besser: PORTB = PORTB | ( 1<<PB2 ) */<br />
/* vereinfacht durch Nutzung des |= Operators : */<br />
PORTB |= (1<<PB2);<br />
<br />
/* auch mehrere "gleichzeitig": */<br />
PORTB |= (1<<PB4) | (1<<PB5); /* Pins PB4 und PB5 "high" */<br />
</syntaxhighlight><br />
<br />
"Ausschalten", also Ausgänge auf "low" setzen, erfolgt analog:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB &= ~(1<<PB2); /* loescht Bit 2 in PORTB und setzt damit Pin PB2 auf low */ <br />
PORTB &= ~( (1<<PB4) | (1<<PB5) ); /* Pin PB4 und Pin PB5 "low" */<br />
</syntaxhighlight><br />
Siehe auch [[Bitmanipulation]]<br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind in aktuellen Versionen der avr-libc nicht mehr enthalten und auch nicht mehr erforderlich.<br />
<br />
''Falls der Anfangszustand von Ausgängen kritisch ist, muss die Reihenfolge beachtet werden, mit der die Datenrichtung (DDRx) eingestellt und der Ausgabewert (PORTx) gesetzt wird:''<br />
<br />
Für Ausgangspins, die mit Anfangswert "high" initialisiert werden sollen:<br />
* zuerst die Bits im PORTx-Register setzen<br />
* anschließend die Datenrichtung auf Ausgang stellen<br />
<br />
Daraus ergibt sich die Abfolge für einen Pin, der bisher als Eingang mit abgeschaltetem Pull-Up konfiguriert war:<br />
* setze PORTx: interner Pull-Up aktiv<br />
* setze DDRx: Ausgang ("high")<br />
<br />
Bei der Reihenfolge erst DDRx und dann PORTx kann es zu einem kurzen "low-Puls" kommen, der auch externe Pull-Up-Widerstände "überstimmt". Die (ungünstige) Abfolge: Eingang -> setze DDRx: Ausgang (auf "low", da PORTx nach Reset 0) -> setze PORTx: Ausgang auf high. Vergleiche dazu auch das Datenblatt Abschnitt ''Configuring the Pin''.<br />
<br />
== Eingänge (Wie kommen Signale in den &micro;C) ==<br />
<br />
Die digitalen Eingangssignale können auf verschiedene Arten zu unserer Logik gelangen.<br />
<br />
=== Signalkopplung ===<br />
<br />
Am einfachsten ist es, wenn die Signale direkt aus einer anderen digitalen Schaltung übernommen werden können. Hat der Ausgang der entsprechenden Schaltung TTL-Pegel dann können wir sogar direkt den Ausgang der Schaltung mit einem Eingangspin von unserem Controller verbinden.<br />
<br />
Hat der Ausgang der anderen Schaltung keinen TTL-Pegel so müssen wir den Pegel über entsprechende Hardware (z.&nbsp;B. Optokoppler, [[Widerstand#Spannungsteiler|Spannungsteiler]], "Levelshifter" aka [[Pegelwandler]]) anpassen.<br />
<br />
Die Masse der beiden Schaltungen muss selbstverständlich miteinander verbunden werden. Der Software selber ist es natürlich letztendlich egal, wie das Signal eingespeist wird. Wir können ja ohnehin lediglich prüfen, ob an einem Pin unseres Controllers eine logische 1 (Spannung größer ca. 0,7*Vcc) oder eine logische 0 (Spannung kleiner ca. 0,2*Vcc) anliegt. Detaillierte Informationen darüber, ab welcher Spannung ein Eingang als 0 ("low") bzw. 1 ("high") erkannt wird, liefert die Tabelle DC Characteristics im Datenblatt des genutzten Controllers.<br />
<br />
{| class="wikitable" style="text-align:center; width:20em"<br />
|+ '''Logikpegel'''<br />
|-<br />
! VCC [V]<br />
! Low [V]<br />
! High [V]<br />
|-<br />
! 5<br />
| 1,0 || 3,5<br />
|-<br />
! 3,3<br />
| 0,66 || 2,3<br />
|-<br />
! 1,8<br />
| 0,36 || 1,26 <br />
|}<br />
<br />
Die Abfrage der Zustände der Portpins erfolgt direkt über den Registernamen.<br />
<br />
{{Warnung|Dabei ist wichtig, zur Abfrage der Eingänge ''nicht'' etwa Portregister '''PORTx''' zu verwenden, sondern Eingangsregister '''PINx'''. Ansonsten liest man nicht den Zustand der Eingänge, sondern den Status der internen Pull-Up-Widerstände. Die Abfrage der Pinzustände über PORTx statt PINx ist ein häufiger Fehler beim AVR-"Erstkontakt".}}<br />
<br />
Will man also die aktuellen Signalzustände von Port D abfragen und in eine Variable namens bPortD abspeichern, schreibt man folgende Befehlszeilen:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdint.h><br />
...<br />
uint8_t bPortD;<br />
...<br />
bPortD = PIND;<br />
...<br />
</syntaxhighlight><br />
<br />
Mit den C-Bitoperationen kann man den Status der Bits abfragen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
/* Fuehre Aktion aus, wenn Bit Nr. 1 (das "zweite" Bit) in PINC gesetzt (1) ist */<br />
if ( PINC & (1<<PINC1) ) {<br />
/* Aktion */<br />
}<br />
<br />
/* Fuehre Aktion aus, wenn Bit Nr. 2 (das "dritte" Bit) in PINB geloescht (0) ist */<br />
if ( !(PINB & (1<<PINB2)) ) {<br />
/* Aktion */<br />
}<br />
...<br />
</syntaxhighlight><br />
Siehe auch [[Bitmanipulation#Bits_prüfen]]<br />
<br />
=== Interne Pull-Up Widerstände ===<br />
<br />
Portpins für Ein- und Ausgänge (GPIO) eines AVR verfügen über zuschaltbare interne Pull-Up Widerstände (nominal mehrere 10kOhm, z.&nbsp;B. ATmega16 20-50kOhm). Diese können in vielen Fällen statt externer Widerstände genutzt werden.<br />
<br />
Die internen Pull-Up Widerstände von Vcc zu den einzelnen Portpins werden über das Register ''' PORTx''' aktiviert bzw. deaktiviert, wenn ein Pin als ''' Eingang''' geschaltet ist.<br />
<br />
Wird der Wert des entsprechenden Portpins auf 1 gesetzt, so ist der Pull-Up Widerstand aktiviert. Bei einem Wert von 0 ist der Pull-Up Widerstand nicht aktiv. Man sollte jeweils entweder den internen oder einen externen Pull-Up Widerstand verwenden, aber nicht beide zusammen.<br />
<br />
Im Beispiel werden alle Pins des Ports D als Eingänge geschaltet und alle Pull-Up Widerstände aktiviert. Weiterhin wird Pin PC7 als Eingang geschaltet und dessen interner Pull-Up Widerstand aktiviert, ohne die Einstellungen für die anderen Portpins (PC0-PC6) zu verändern.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
DDRD = 0x00; /* alle Pins von Port D als Eingang */<br />
PORTD = 0xff; /* interne Pull-Ups an allen Port-Pins aktivieren */<br />
...<br />
DDRC &= ~(1<<PC7); /* Pin PC7 als Eingang */<br />
PORTC |= (1<<PC7); /* internen Pull-Up an PC7 aktivieren */<br />
</syntaxhighlight><br />
<br />
=== Taster und Schalter ===<br />
<br />
Der Anschluss mechanischer Kontakte an den Mikrocontroller, ist zwischen zwei unterschiedliche Methoden zu unterscheiden: ''Active Low'' und ''Active High''.<br />
<br />
<gallery widths="300" heights="300" caption="Anschluss mechanischer Kontakte an einen µC"><br />
Image:Active Low.gif|'''Active Low:''' Bei dieser Methode wird der Kontakt zwischen den Eingangspin des Controllers und Masse geschaltet. Damit bei offenem Schalter der Controller kein undefiniertes Signal bekommt, wird zwischen die Versorgungsspannung und den Eingangspin ein sogenannter '''Pull-Up''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffnetem Schalter auf logisch 1 zu ziehen.<br />
Image:Active High.gif|'''Active High:''' Hier wird der Kontakt zwischen die Versorgungsspannung und den Eingangspin geschaltet. Damit bei offener Schalterstellung kein undefiniertes Signal am Controller ansteht, wird zwischen den Eingangspin und die Masse ein '''Pull-Down''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffneter Schalterstellung auf logisch 0 zu halten. <br />
</gallery><br />
<br />
Der Widerstandswert von Pull-Up- und Pull-Down-Widerständen ist an sich nicht kritisch. Wird er allerdings zu hoch gewählt, ist die Wirkung eventuell nicht gegeben. Als üblicher Wert haben sich 10 kOhm eingebürgert. Die AVRs verfügen an den meisten Pins über zuschaltbare interne Pull-Up Widerstände (vgl. Abschnitt [[AVR-GCC-Tutorial#Interne Pull-Up Widerstände|Interne Pull-Up Widerstände]]), welche insbesondere wie hier bei Tastern und ähnlichen Bauteilen (z.&nbsp;B. Drehgebern) statt externer Bauteile verwendet werden können. Interne Pull-Down-Widerstand sind nicht verfügbar und müssen daher in Form zusätzlicher Bauteile in die Schaltung eingefügt werden.<br />
<br />
==== Taster entprellen ====<br />
<br />
Siehe: ''[[Entprellung#Warteschleifen-Verfahren|Entprellung: Warteschleifen-Verfahren]]<br />
<br />
= Warteschleifen (delay.h) =<br />
<br />
Der Programmablauf kann verschiedene Arten von Wartefunktionen erfordern:<br />
<br />
* Warten im Sinn von Zeitvertrödeln<br />
* Warten auf einen bestimmten Zustand an den I/O-Pins<br />
* Warten auf einen bestimmten Zeitpunkt (siehe Timer)<br />
* Warten auf einen bestimmten Zählerstand (siehe Counter)<br />
<br />
Der einfachste Fall, das Zeitvertrödeln, kann in vielen Fällen und mit großer Genauigkeit anhand der avr-libc Bibliotheksfunktionen _delay_ms() und _delay_us() erledigt werden. Die Bibliotheksfunktionen sind einfachen Zählschleifen (Warteschleifen) vorzuziehen, da leere Zählschleifen ohne besondere Vorkehrungen sonst bei eingeschalteter Optimierung vom avr-gcc-Compiler wegoptimiert werden. Weiterhin sind die Bibliotheksfunktionen bereits darauf vorbereitet, die in F_CPU definierte Taktfrequenz zu verwenden. Außerdem sind die Funktionen der Bibliothek wirklich getestet.<br />
<br />
Einfach!? Schon, aber während gewartet wird, macht der µC nichts anderes mehr (abgesehen von möglicherweise auftretenden Interrupts, falls welche aktiviert sind). Die Wartefunktion blockiert den Programmablauf. Möchte man einerseits warten, um z.&nbsp;B. eine LED blinken zu lassen und gleichzeitig andere Aktionen ausführen z.&nbsp;B. weitere LED bedienen, sollten die Timer/Counter des AVR verwendet werden, siehe Artikel [[Multitasking]].<br />
<br />
Die Bibliotheksfunktionen funktionieren allerdings nur dann korrekt, wenn sie mit zur Übersetzungszeit (beim Compilieren) bekannten konstanten Werten aufgerufen werden. Der Quellcode muss mit eingeschalteter Optimierung übersetzt werden, sonst wird sehr viel Maschinencode erzeugt, und die Wartezeiten stimmen nicht mehr mit dem Parameter überein.<br />
<br />
Eine weitere Einschränkung liegt darin, daß sie möglicherweise länger warten, als erwartet, nämlich in dem Fall, daß Interrupts auftreten und die _delay...()-Funktion unterbrechen. Genau genommen warten diese nämlich nicht eine bestimmte Zeit, sondern verbrauchen eine bestimmte Anzahl von Prozessortakten. Die wiederum ist so bemessen, daß ohne Unterbrechung durch Interrupts die gewünschte Wartezeit erreicht wird.<br />
Wird das Warten aber durch eine oder mehrere ISR unterbrochen, die zusammen 1% Prozessorzeit verbrauchen, dann dauert das Warten etwa 1% länger. Bei 50% Last durch die ISR dauert das Warten doppelt solange wie gewünscht, bei 90% zehnmal solange...<br />
<br />
Abhängig von der Version der Bibliothek verhalten sich die Bibliotheksfunktionen etwas unterschiedlich.<br />
<br />
== avr-libc Versionen bis 1.6 ==<br />
<br />
Die Wartezeit der Funktion _delay_ms() ist auf 262,14ms/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 13,1ms warten. Die Wartezeit der Funktion _delay_us() ist auf 768us/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 38,4µs warten. Längere Wartezeiten müssen dann über einen mehrfachen Aufruf in einer Schleife gelöst werden.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.&nbsp;B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h> /* in älteren avr-libc Versionen <avr/delay.h> */ <br />
<br />
/*<br />
lange, variable Verzögerungszeit, Einheit in Millisekunden<br />
<br />
Die maximale Zeit pro Funktionsaufruf ist begrenzt auf <br />
262.14 ms / F_CPU in MHz (im Beispiel: <br />
262.1 / 3.6864 = max. 71 ms) <br />
<br />
Daher wird die kleine Warteschleife mehrfach aufgerufen,<br />
um auf eine längere Wartezeit zu kommen. Die zusätzliche <br />
Prüfung der Schleifenbedingung lässt die Wartezeit geringfügig<br />
ungenau werden (macht hier vielleicht 2-3ms aus).<br />
*/<br />
<br />
void long_delay(uint16_t ms)<br />
{<br />
for(; ms>0; ms--) _delay_ms(1);<br />
}<br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) // Endlosschleife<br />
{ <br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.&nbsp;B. angeschlossene LED<br />
long_delay(1000); // Eine Sekunde warten...<br />
}<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
== avr-libc Versionen ab 1.7 ==<br />
<br />
_delay_ms() kann mit einem Argument bis 6553,5 ms (= 6,5535 Sekunden) benutzt werden. Es ist nicht möglich, eine Variable als Argument zu übergeben. Wird die früher gültige Grenze von 262,14 ms/F_CPU (in MHz) überschritten, so arbeitet _delay_ms() einfach etwas ungenauer und zählt nur noch mit einer Auflösung von 1/10 ms. Eine Verzögerung von 1000,10 ms ließe sich nicht mehr von einer von 1000,19 ms unterscheiden. Ein Verlust, der sich im Allgemeinen verschmerzen lässt. Dem Programmierer wird keine Rückmeldung gegeben, dass die Funktion ggf. gröber arbeitet, d.h. wenn es darauf ankommt, bitte den Parameter wie bisher geschickt wählen.<br />
<br />
Die Funktion _delay_us() wurde ebenfalls erweitert. Wenn deren maximal als genau behandelbares Argument überschritten wird, benutzt diese intern _delay_ms(). Damit gelten in diesem Fall die _delay_ms() Einschränkungen.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus, avr-libc ab Version 1.6<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h><br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) { // Endlosschleife<br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED<br />
_delay_ms(1000); // Eine Sekunde +/-1/10000 Sekunde warten...<br />
// funktioniert nicht mit Bibliotheken vor 1.6<br />
<br />
}<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
Die _delay_ms() und die _delay_us aus '''avr-libc 1.7.0''' sind fehlerhaft. _delay_ms () läuft 4x schneller als erwartet. Abhilfe ist eine korrigierte Includedatei: [http://www.mikrocontroller.net/topic/196738#1943039]<br />
<br />
= Programmieren mit Interrupts =<br />
<br />
<div style="float:right; margin:2em;"><br />
[[Image:Interrupt Programme.gif]]<br />
</div><br />
Nachdem wir nun alles Wissenswerte für die serielle Programmerstellung<br />
gelernt haben nehmen wir jetzt ein völlig anderes Thema in Angriff, nämlich<br />
die Programmierung unter Zuhilfenahme der Interrupts des AVR.<br />
<br />
Tritt ein Interrupt auf, unterbricht (engl. interrupts) der Controller die Verarbeitung des Hauptprogramms und verzweigt zu einer Interruptroutine. Das Hauptprogramm wird also beim Eintreffen eines Interrupts unterbrochen, die Interruptroutine ausgeführt und danach erst wieder das Hauptprogramm an der Unterbrechungsstelle fortgesetzt (vgl. die Abbildung).<br />
<br />
Um Interrupts verarbeiten zu können, ist folgendes zu beachten:<br />
<br />
* Für jede aktivierte Interruptquelle ist eine Funktion zu programmieren, in der die beim Auftreten des jeweiligen Interrupts erforderlichen Verarbeitungsschritte enthalten sind. Für diese Funktion existieren verschiedene Bezeichnungen. Üblich sind die englischen Begriffe Interrupt-Handler oder Interrupt-Service-Routinen (ISR), man findet aber auch die Bezeichnungen Interruptverarbeitungs- oder -behandlungsroutine oder auch kurz Interruptroutine. Zum Beispiel wird üblicherweise in der ISR zur Verarbeitung des Empfangsinterrupts eines UARTs (UART-RX Interrupt) das empfangene Zeichen in einen Zwischenspeicher (FIFO-Buffer) kopiert, dessen Inhalt später von anderen Programmteilen geleert wird. Sofern der Zwischenspeicher ausreichend groß ist, geht also kein Zeichen verloren, auch wenn im Hauptprogramm zeitintensive Operationen durchgeführt werden.<br />
* Die benötigten Interrupts sind in den jeweiligen Funktionsbausteinen einzuschalten. Dies erfolgt über das jeweilige Aktivierungsbit (Interrupt Enable) in einem der Hardwareregister (z.B. RX(Complete)Interrupt Enable eines UARTs)<br />
* Sämtliche Interrupts werden über einen weiteren globalen Schalter aktiviert und deaktiviert. Zur Verarbeitung der Interrupts ist dieser Schalter zu aktivieren (sei(), siehe unten).<br />
<br />
Alle Punkte sind zu beachten. Fehlt z.B. die globale Aktivierung, werden Interruptroutinen auch dann nicht aufgerufen, wenn sie im Funktionsbaustein eingeschaltet sind und eine Behandlungsroutine verhanden ist.<br />
<br />
Siehe auch<br />
<br />
* [http://www.mikrocontroller.net/forum/read-1-235092.html#new Ausführlicher Thread im Forum]<br />
* Artikel [[Interrupt]]<br />
* Artikel [[Multitasking]]<br />
{{Clear}}<br />
<br />
== Anforderungen an Interrupt-Routinen ==<br />
<br />
Um unliebsamen Überraschungen vorzubeugen, sollten einige Grundregeln bei der Implementierung der Interruptroutinen beachtet werden. Interruptroutinen sollten möglichst kurz und schnell abarbeitbar sein, daraus folgt:<br />
<br />
* Keine umfangreichen Berechnungen innerhalb der Interruptroutine. (*)<br />
* Keine langen Programmschleifen.<br />
* Obwohl es möglich ist, während der Abarbeitung einer Interruptroutine andere oder sogar den gleichen Interrupt wieder zuzulassen, wird davon ohne genaue Kenntnis der internen Abläufe dringend abgeraten.<br />
<br />
Interruptroutinen (ISRs) sollten also möglichst kurz sein und keine Schleifen mit vielen Durchläufen enthalten. Längere Operationen können meist in einen "Interrupt-Teil" in einer ISR und einen "Arbeitsteil" im Hauptprogramm aufgetrennt werden. Z.B. Speichern des Zustands aller Eingänge im EEPROM in bestimmten Zeitabständen: ISR-Teil: Zeitvergleich (Timer,RTC) mit Logzeit/-intervall. Bei Übereinstimmung ein globales Flag setzen (volatile bei Flag-Deklaration nicht vergessen, s.u.). Dann im Hauptprogramm prüfen, ob das Flag gesetzt ist. Wenn ja: die Daten im EEPROM ablegen und Flag löschen.<br />
<br />
(*)<br />
Hinweis: <br />
Es gibt allerdings die seltene Situation, dass man gerade eingelesene<br />
ADC-Werte sofort verarbeiten muss. Besonders dann, wenn man mehrere Werte sehr<br />
schnell hintereinander bekommt. Dann bleibt einem nichts anderes übrig, als die<br />
Werte noch in der ISR zu verarbeiten. Kommt aber sehr selten vor und sollte<br />
durch geeignete Wahl des Systemtaktes bzw. Auswahl des Controllers vermieden werden!<br />
<br />
== Interrupt-Quellen ==<br />
<br />
Die folgenden Ereignisse können einen Interrupt auf einem AVR AT90S2313 auslösen, wobei die Reihenfolge der Auflistung auch die Priorität der Interrupts aufzeigt.<br />
<br />
* Reset<br />
* Externer Interrupt 0<br />
* Externer Interrupt 1<br />
* Timer/Counter 1 Capture Ereignis<br />
* Timer/Counter 1 Compare Match<br />
* Timer/Counter 1 Überlauf<br />
* Timer/Counter 0 Überlauf<br />
* UART Zeichen empfangen<br />
* UART Datenregister leer<br />
* UART Zeichen gesendet<br />
* Analoger Komparator<br />
<br />
Die Anzahl der möglichen Interruptquellen variiert zwischen den verschiedenen Microcontroller-Typen. Im Zweifel hilft ein Blick ins Datenblatt ("Interrupt Vectors").<br />
<br />
== Register ==<br />
<br />
Der AT90S2313 verfügt über 2 Register die mit den<br />
Interrupts zusammenhängen.<br />
<br />
{| class="wikitable"<br />
|- <br />
!width="10%"| GIMSK<br />
| '''G'''eneral '''I'''nterrupt '''M'''a'''sk''' Register.<br /><br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit <br />
| 7 || 6|| 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INT1''' || '''INT0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INT1''' (External '''Int'''errupt Request '''1''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT1'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
'''INT0''' (External '''Int'''errupt Request '''0''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT0'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
|- <br />
! GIFR<br />
| '''G'''eneral '''I'''nterrupt '''F'''lag '''R'''egister.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INTF1''' || '''INTF0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INTF1''' (External '''Int'''errupt Flag '''1''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT1'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
<br />
'''INTF0''' (External '''Int'''errupt Flag '''0''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT0'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
|- <br />
! MCUCR<br />
| '''MCU''' '''C'''ontrol '''R'''egister.<br />
<br />
Das MCU Control Register enthält Kontrollbits für allgemeine MCU-Funktionen.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''-'''|| '''-'''|| '''SE'''|| '''SM'''|| '''ISC11'''|| '''ISC10'''|| '''ISC01'''|| '''ISC00'''<br />
|- <br />
! R/W<br />
| R || R || R/W || R/W || R/W || R/W || R/W || R/W<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
<br />
|}<br />
<br />
'''SE''' ('''S'''leep '''E'''nable)<br />
:Dieses Bit muss gesetzt sein, um den Controller mit dem '''SLEEP'''-Befehl in den Schlafzustand versetzen zu können.<br />
:Um den Schlafmodus nicht irrtümlich einzuschalten, wird empfohlen, das Bit erst unmittelbar vor Ausführung des '''SLEEP'''-Befehls zu setzen.<br />
<br />
'''SM''' ('''S'''leep '''M'''ode)<br />
:Dieses Bit bestimmt über den Schlafmodus.<br />
:Ist das Bit gelöscht, so wird der '''Idle'''-Modus ausgeführt. Ist das Bit gesetzt, so wird der '''Power-Down'''-Modus ausgeführt. (für andere AVR Controller siehe Abschnitt "Sleep-Mode")<br />
<br />
'''ISC11''', '''ISC10''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''1''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT1'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
!width="10%"| ISC11 ||width="10%"| ISC10 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT1''' erzeugt einen Interrupt.<br />
<br />
Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|}<br />
<br />
'''ISC01''', '''ISC00''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''0''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT0'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
!width="10%"| ISC01 ||width="10%"| ISC00 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT0''' erzeugt einen Interrupt.<br />
<br />
Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|}<br />
<br />
|}<br />
<br />
== Allgemeines über die Interrupt-Abarbeitung ==<br />
<br />
Wenn ein Interrupt eintrifft, wird automatisch das '''Global Interrupt Enable''' Bit im Status Register '''SREG''' gelöscht und alle weiteren Interrupts unterbunden. Dieses wird automatisch wieder gesetzt, wenn die Interruptroutine beendet wird. Wenn in der Zwischenzeit weitere Interrupts eintreffen, werden die zugehörigen Interrupt-Bits gesetzt und die Interrupts bei Beendigung der laufenden Interrupt-Routine in der Reihenfolge ihrer Priorität ausgeführt. Dies kann<br />
eigentlich nur dann zu Problemen führen, wenn ein hoch priorisierter Interrupt ständig und in kurzer Folge auftritt. Dieser sperrt dann möglicherweise alle anderen Interrupts mit niedrigerer Priorität. Dies ist einer der Gründe, weshalb die Interrupt-Routinen sehr kurz gehalten werden sollen. Es ist möglich das GIE-Bit in der ISR zu setzen und so schon wieder weitere Interrupts zuzulassen - allerdings sollte man damit vorsichtig sein und genau wissen was man damit macht. Kritisch wird es vor allem wenn der gleiche Interrupt noch einmal kommt, bevor die ISR abgearbeitet ist. <br />
<br />
<!-- === Das Status-Register ===<br />
<br />
Es gilt auch zu beachten, dass das Status-Register während der Abarbeitung einer Interruptroutine nicht automatisch gesichert wird. Falls notwendig, muss dies vom Programmierer selber vorgesehen werden. --><br />
<br />
== Interrupts mit avr-gcc ==<br />
<br />
<!-- ''Anmerkung eines Nutzers: Ich habe mir das Thema hier angearbeitet und hatte am Anfang starke Probleme: Jeder Interrupt muss nochmals einzeln aktiviert werden. Es reicht nicht nur per ''sei()'' die Interrupts global zu aktiveren.'' - mthomas: Hoffentlich duch die modifizerte Einleitung etwas offensichtlicher erläutert. Ansonsten bitte per Eintrag auf die Diskussionseite nochmals melden) --> <br />
<!-- Selbstverständlich können alle interruptspezifischen Registerzugriffe wie gewohnt über I/O-Adressierung vorgenommen werden. Etwas einfacher geht es jedoch, wenn wir die vom Compiler zur Verfügung gestellten Mittel einsetzen.--><br />
Funktionen zur Interrupt-Verarbeitung werden in den Includedateien ''interrupt.h'' der avr-libc zur Verfügung gestellt (bei älterem Quellcode zusätzlich ''signal.h'').<br />
<br />
<syntaxhighlight lang="c"><br />
// fuer sei(), cli() und ISR():<br />
#include <avr/interrupt.h><br />
</syntaxhighlight><br />
<br />
Das Makro '''sei()''' schaltet die Interrupts ein. Eigentlich wird nichts anderes gemacht, als das '''Global Interrupt Enable''' Bit im Status Register gesetzt.<br />
<br />
<syntaxhighlight lang="c"><br />
sei();<br />
</syntaxhighlight><br />
<br />
Das Makro '''cli()''' schaltet die Interrupts aus, oder anders gesagt, das '''Global Interrupt Enable''' Bit im Status Register wird gelöscht.<br />
<br />
<syntaxhighlight lang="c"><br />
cli();<br />
</syntaxhighlight><br />
<br />
Oft steht man vor der Aufgabe, dass eine Codesequenz nicht unterbrochen werden darf. Es liegt dann nahe, zu Beginn dieser Sequenz ein cli() und am Ende ein sei() einzufügen. Dies ist jedoch ungünstig, wenn die Interrupts vor Aufruf der Sequenz deaktiviert waren und danach auch weiterhin deaktiviert bleiben sollen. Ein sei() würde ungeachtet des vorherigen Zustands die Interrupts aktivieren, was zu unerwünschten Seiteneffekten führen kann. Die aus dem folgenden Beispiel ersichtliche Vorgehensweise ist in solchen Fällen vorzuziehen:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <inttypes.h><br />
<br />
//...<br />
<br />
void NichtUnterbrechenBitte(void)<br />
{<br />
uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister<br />
<br />
tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) sichern<br />
cli(); // Interrupts global deaktivieren<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
/* Beispiel Anfang<br />
JTAG-Interface eines ATmega16 per Software deaktivieren <br />
und damit die JTAG-Pins an PORTC für "general I/O" nutzbar machen<br />
ohne die JTAG-Fuse-Bit zu aendern. Dazu ist eine "timed sequence"<br />
einzuhalten (vgl Datenblatt ATmega16, Stand 10/04, S. 229): <br />
Das JTD-Bit muss zweimal innerhalb von 4 Taktzyklen geschrieben <br />
werden. Ein Interrupt zwischen den beiden Schreibzugriffen wuerde <br />
die erforderliche Sequenz "brechen", das JTAG-Interface bliebe<br />
weiterhin aktiv und die IO-Pins weiterhin für JTAG reserviert. */<br />
<br />
MCUCSR |= (1<<JTD);<br />
MCUCSR |= (1<<JTD); // 2 mal in Folge ,vgl. Datenblatt fuer mehr Information<br />
<br />
/* Beispiel Ende */<br />
<br />
SREG = tmp_sreg; // Status-Register wieder herstellen <br />
// somit auch das I-Flag auf gesicherten Zustand setzen<br />
}<br />
<br />
void NichtSoGut(void)<br />
{<br />
cli();<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
sei();<br />
}<br />
<br />
<br />
int main(void)<br />
{<br />
//...<br />
<br />
cli(); <br />
// Interrupts global deaktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// auch nach Aufruf der Funktion deaktiviert<br />
<br />
sei();<br />
// Interrupts global aktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// weiterhin aktiviert<br />
//...<br />
<br />
/* Verdeutlichung der unguenstigen Vorgehensweise mit cli/sei: */<br />
cli(); <br />
// Interrupts jetzt global deaktiviert <br />
<br />
NichtSoGut();<br />
// nach Aufruf der Funktion sind Interrupts global aktiviert <br />
// dies ist mglw. ungewollt!<br />
//...<br />
<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
<!-- mt: besser so nicht(?), lieber "datenblattkonform"<br />
<br />
<font face="Courier New">'''timer_enable_int (unsigned char ints);<br /><br />
'''</font>Schaltet Timerbezogene Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle<br />
Timerinterrupts ausgeschaltet, ansonsten muss in '''ints''' angegeben werden,<br />
welche Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">timer_enable_int (1 << TOIE1));<br /><br />
</font>'''Achtung: Wenn ein Timerinterrupt eingeschaltet wird während ein<br />
anderer Timerinterrupt bereits läuft, dann müssen beide Bits angegeben werden<br />
sonst wird der andere Timerinterrupt versehentlich ausgeschaltet.<br />
<br />
<font face="Courier New">'''enable_external_int (unsigned char ints);<br /><br />
'''</font>Schaltet die externen Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle externen<br />
Interrrups ausgeschaltet, ansonsten muss in '''ints''' angegeben werden, welche<br />
Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">enable_external_int ((1<<br />
</font>'''Schaltet die externen Interrupts 0 und 1 ein.<br />
<br />
Nachdem nun die Interrupts aktiviert sind, braucht es selbstverständlich noch den auszuführenden Code, der ablaufen soll, wenn ein Interrupt eintrifft.<br />
--><br />
Zu den aktivierten Interrupts ist eine Funktion zu programmieren, deren Code aufgerufen wird, wenn der betreffende Interrupt auftritt (Interrupt-Handler, Interrupt-Service-Routine). Dazu existiert die Definition (ein Makro) '''ISR'''.<br />
<br />
=== ISR ===<br />
<br />
(''ISR()'' ersetzt bei neueren Versionen der avr-libc ''SIGNAL()''. SIGNAL sollte nicht mehr genutzt werden, zur Portierung von SIGNAL nach ISR siehe den [[AVR-GCC-Tutorial#Anhang|Anhang]].)<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
//...<br />
ISR(Vectorname) /* vormals: SIGNAL(siglabel) dabei Vectorname != siglabel ! */<br />
{<br />
/* Interrupt Code */<br />
}<br />
</syntaxhighlight><br />
<br />
Mit ''ISR'' wird eine Funktion für die Bearbeitung eines Interrupts eingeleitet. Als Argument muss dabei die Benennung des entsprechenden Interruptvektors angegeben werden. Diese sind in den jeweiligen Includedateien IOxxxx.h zu finden. Die Bezeichnung entspricht dem Namen aus dem Datenblatt, bei dem die Leerzeichen durch Unterstriche ersetzt sind und ein ''_vect'' angehängt ist.<br />
<br />
Als Beispiel ein Ausschnitt aus der Datei für den ATmega8 (bei WinAVR Standardinstallation in C:\WinAVR\avr\include\avr\iom8.h) in der neben den aktuellen Namen für ''ISR'' (*_vect) noch die Bezeichnungen für das inzwischen nicht mehr aktuelle ''SIGNAL'' (SIG_*) enthalten sind.<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
/* $Id: iom8.h,v 1.13 2005/10/30 22:11:23 joerg_wunsch Exp $ */<br />
<br />
/* avr/iom8.h - definitions for ATmega8 */<br />
//...<br />
<br />
/* Interrupt vectors */<br />
<br />
/* External Interrupt Request 0 */<br />
#define INT0_vect _VECTOR(1)<br />
#define SIG_INTERRUPT0 _VECTOR(1)<br />
<br />
/* External Interrupt Request 1 */<br />
#define INT1_vect _VECTOR(2)<br />
#define SIG_INTERRUPT1 _VECTOR(2)<br />
<br />
/* Timer/Counter2 Compare Match */<br />
#define TIMER2_COMP_vect _VECTOR(3)<br />
#define SIG_OUTPUT_COMPARE2 _VECTOR(3)<br />
<br />
/* Timer/Counter2 Overflow */<br />
#define TIMER2_OVF_vect _VECTOR(4)<br />
#define SIG_OVERFLOW2 _VECTOR(4)<br />
<br />
/* Timer/Counter1 Capture Event */<br />
#define TIMER1_CAPT_vect _VECTOR(5)<br />
#define SIG_INPUT_CAPTURE1 _VECTOR(5)<br />
<br />
/* Timer/Counter1 Compare Match A */<br />
#define TIMER1_COMPA_vect _VECTOR(6)<br />
#define SIG_OUTPUT_COMPARE1A _VECTOR(6)<br />
<br />
/* Timer/Counter1 Compare Match B */<br />
#define TIMER1_COMPB_vect _VECTOR(7)<br />
#define SIG_OUTPUT_COMPARE1B _VECTOR(7)<br />
<br />
//...<br />
</syntaxhighlight><br />
<br />
<!--Vor Nutzung von SIGNAL muss ebenfalls die Header-Datei signal.h eingebunden werden.--> <br />
Mögliche Funktionsrümpfe für Interruptfunktionen sind zum Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
/* veraltet: #include <avr/signal.h> */<br />
<br />
ISR(INT0_vect) /* veraltet: SIGNAL(SIG_INTERRUPT0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(TIMER0_OVF_vect) /* veraltet: SIGNAL(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(USART_RXC_vect) /* veraltet: SIGNAL(SIG_UART_RECV) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
// und so weiter und so fort...<br />
</syntaxhighlight><br />
<br />
Auf die korrekte Schreibweise der Vektorbezeichnung ist zu achten. Der gcc-Compiler prüft erst ab Version 4.x, ob ein Signal/Interrupt der angegebenen Bezeichnung tatsächlich in der Includedatei definiert ist und gibt andernfalls eine Warnung aus. Bei WinAVR (ab 2/2005) wurde die Überprüfung auch in den mitgelieferten Compiler der Version 3.x integriert. Aus dem gcc-Quellcode Version 3.x selbst erstellte Compiler enthalten die Prüfung nicht (vgl. [[AVR-GCC]]). <br />
<br />
Während der Ausführung der Funktion sind alle weiteren Interrupts automatisch gesperrt. Beim Verlassen der Funktion werden die Interrupts wieder zugelassen.<br />
<br />
Sollte während der Abarbeitung der Interruptroutine ein weiterer Interrupt (gleiche oder andere Interruptquelle) auftreten, so wird das entsprechende Bit im zugeordneten Interrupt Flag Register gesetzt und die entsprechende Interruptroutine automatisch nach dem Beenden der aktuellen Funktion aufgerufen.<br />
<br />
Ein Problem ergibt sich eigentlich nur dann, wenn während der Abarbeitung der aktuellen Interruptroutine mehrere gleichartige Interrupts auftreten. Die entsprechende Interruptroutine wird im Nachhinein zwar aufgerufen jedoch wissen wir nicht, ob nun der entsprechende Interrupt einmal, zweimal oder gar noch öfter aufgetreten ist. Deshalb soll hier noch einmal betont werden, dass Interruptroutinen so schnell wie nur irgend möglich wieder verlassen werden sollten.<br />
<br />
=== Unterbrechbare Interruptroutinen ===<br />
<br />
"Faustregel": im Zweifel '''ISR'''. Die nachfolgend beschriebene Methode nur dann verwenden, wenn man sich über die unterschiedliche Funktionsweise im Klaren ist.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
<br />
ISR(XXX,ISR_NOBLOCK) /* veraltet: INTERRUPT(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt-Code */<br />
}<br />
</syntaxhighlight><br />
<br />
Hierbei steht XXX für den oben beschriebenen Namen des Vektors (also z.&nbsp;B. ''TIMER0_OVF_vect''). Der Unterschied im Vergleich zu einer herkömmlichen ISR ist, dass hier beim Aufrufen der Funktion das '''Global Enable Interrupt''' Bit durch Einfügen einer SEI-Anweisung direkt wieder gesetzt und somit alle Interrupts zugelassen werden &ndash; auch XXX-Interrupts. <br />
<br />
Bei unsachgemässer Handhabung kann dies zu erheblichen Problemen durch Rekursion wie einem Stack-Overflow oder anderen unerwarteten Effekten führen und sollte wirklich nur dann eingesetzt werden, wenn man sich sicher ist, das Ganze auch im Griff zu haben.<br />
<br />
Insbesondere sollte möglichst am ISR-Anfang die auslösende IRQ-Quelle deaktiviert und erst am Ende der ISR wieder aktiviert werden. Robuster als die Verwendung einer NOBLOCK-ISR ist daher folgender ISR-Aufbau:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
<br />
ISR (XXX) <br />
{<br />
// Implementiere die ISR ohne zunaechst weitere IRQs zuzulassen<br />
<br />
<<Deaktiviere die XXX-IRQ>><br />
<br />
// Erlaube alle Interrupts (ausser XXX)<br />
sei();<br />
<br />
//... Code ...<br />
<br />
// IRQs global deaktivieren um die XXX-IRQ wieder gefahrlos <br />
// aktivieren zu koennen<br />
cli();<br />
<br />
<<Aktiviere die XXX-IRQ>><br />
}<br />
</syntaxhighlight><br />
Auf diese Weise kann sich die XXX-IRQ nicht selbst unterbrechen, was zu einer Art Endlosschleife führen würde.<br />
<br />
Siehe auch: Hinweise in [[AVR-GCC]]<br />
<br />
siehe dazu: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html<br />
<br />
== Datenaustausch mit Interrupt-Routinen ==<br />
<br />
Variablen, die sowohl in Interrupt-Routinen (ISR = Interrupt Service Routine(s)) als auch vom übrigen Programmcode geschrieben oder gelesen werden, müssen mit einem '''volatile''' deklariert werden. Damit wird dem Compiler mitgeteilt, dass der Inhalt der Variablen vor jedem Lesezugriff aus dem Speicher gelesen und nach jedem Schreibzugriff in den Speicher geschrieben wird. Ansonsten könnte der Compiler den Code so optimieren, dass der Wert der Variablen nur in Prozessorregistern zwischengespeichert wird, die nichts von der Änderung woanders mitbekommen.<br />
<br />
Zur Veranschaulichung ein Codefragment für eine Tastenentprellung mit Erkennung einer "lange gedrückten" Taste.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <stdint.h><br />
//...<br />
<br />
// Schwellwerte<br />
// Entprellung: <br />
#define CNTDEBOUNCE 10<br />
// "lange gedrueckt:"<br />
#define CNTREPEAT 200<br />
<br />
// hier z.&nbsp;B. Taste an Pin2 PortA "active low" = 0 wenn gedrueckt<br />
#define KEY_PIN PINA<br />
#define KEY_PINNO PA2<br />
<br />
// beachte: volatile! <br />
volatile uint8_t gKeyCounter;<br />
<br />
// Timer-Compare Interrupt ISR, wird z.B. alle 10ms ausgefuehrt<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
// hier wird gKeyCounter veraendert. Die übrigen<br />
// Programmteile müssen diese Aenderung "sehen":<br />
// volatile -> aktuellen Wert immer in den Speicher schreiben<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
}<br />
else {<br />
gKeyCounter = 0;<br />
}<br />
}<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
//...<br />
/* hier: Initialisierung der Ports und des Timer-Interrupts */<br />
//... <br />
// hier wird auf gKeyCounter zugegriffen. Dazu muss der in der<br />
// ISR geschriebene Wert bekannt sein:<br />
// volatile -> aktuellen Wert immer aus dem Speicher lesen<br />
if ( gKeyCounter > CNTDEBOUNCE ) { // Taste mind. 10*10 ms "prellfrei"<br />
if (gKeyCounter == CNTREPEAT) {<br />
/* hier: Code fuer "Taste lange gedrueckt" */<br />
}<br />
else {<br />
/* hier: Code fuer "Taste kurz gedrueckt" */<br />
}<br />
}<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Wird innerhalb einer ISR mehrfach auf eine mit volatile deklarierte Variable zugegriffen, wirkt sich dies ungünstig auf die Verarbeitungsgeschwindigkeit aus, da bei jedem Zugriff mit dem Speicherinhalt abgeglichen wird. Da bei AVR-Controllern ''innerhalb'' einer ISR keine Unterbrechungen zu erwarten sind, bietet es sich an, einen Zwischenspeicher in Form einer lokalen Variable zu verwenden, deren Inhalt zu Beginn und am Ende mit dem der volatile Variable synchronisiert wird. Lokale Variable werden bei eingeschalteter Optimierung mit hoher Wahrscheinlichkeit in Prozessorregistern verwaltet und der Zugriff darauf ist daher nur mit wenigen internen Operationen verbunden. Die ISR aus dem vorherigen Beispiel lässt sich so optimieren:<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter; // Uebernahme in lokale Arbeitsvariable<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (tmp_kc < CNTREPEAT) {<br />
tmp_kc++;<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc; // Zurueckschreiben<br />
}<br />
//...<br />
</syntaxhighlight><br />
<br />
Zum Vergleich die Disassemblies (Ausschnitte der "lss-Dateien", compiliert für ATmega162) im Anschluss. Man erkennt den viermaligen Zugriff auf die Speicheraddresse von ''gKeyCounter'' (hier 0x032A) in der ISR ohne "Cache"-Variable und den zweimaligen Zugriff in der Variante mit Zwischenspeicher. Im Beispiel ist der Vorteil gering, bei komplexeren Routinen kann die Zwischenspeicherung in lokalen Variablen jedoch zu deutlicheren Verbesserungen führen.<br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
876: ca 99 sbic 0x19, 2 ; 25<br />
878: 0a c0 rjmp .+20 ; 0x88e <__vector_13+0x24><br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
87a: 80 91 2a 03 lds r24, 0x032A<br />
87e: 88 3c cpi r24, 0xC8 ; 200 <br />
880: 40 f4 brcc .+16 ; 0x892 <__vector_13+0x28><br />
882: 80 91 2a 03 lds r24, 0x032A<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 02 c0 rjmp .+4 ; 0x892 <__vector_13+0x28><br />
}<br />
else {<br />
gKeyCounter = 0;<br />
88e: 10 92 2a 03 sts 0x032A, r1<br />
892: 8f 91 pop r24<br />
894: 0f 90 pop r0<br />
896: 0f be out 0x3f, r0 ; 63<br />
898: 0f 90 pop r0<br />
89a: 1f 90 pop r1<br />
89c: 18 95 reti<br />
</pre><br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter;<br />
876: 80 91 2a 03 lds r24, 0x032A<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
87a: ca 9b sbis 0x19, 2 ; 25<br />
87c: 02 c0 rjmp .+4 ; 0x882 <__vector_13+0x18><br />
87e: 80 e0 ldi r24, 0x00 ; 0<br />
880: 03 c0 rjmp .+6 ; 0x888 <__vector_13+0x1e><br />
if (tmp_kc < CNTREPEAT) {<br />
882: 88 3c cpi r24, 0xC8 ; 200<br />
884: 08 f4 brcc .+2 ; 0x888 <__vector_13+0x1e><br />
tmp_kc++;<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc;<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 8f 91 pop r24<br />
88e: 0f 90 pop r0<br />
890: 0f be out 0x3f, r0 ; 63<br />
892: 0f 90 pop r0<br />
894: 1f 90 pop r1<br />
896: 18 95 reti<br />
</pre><br />
<br />
=== volatile und Pointer ===<br />
<br />
Bei '''volatile''' in Verbindung mit Pointern ist zu beachten, ob der Pointer selbst oder die Variable, auf die der Pointer zeigt, '''volatile''' ist.<br />
<br />
<syntaxhighlight lang="c"><br />
volatile uint8_t *a; // das Ziel von a ist volatile<br />
<br />
uint8_t *volatile a; // a selbst ist volatile<br />
</syntaxhighlight><br />
<br />
Falls der Pointer volatile ist (zweiter Fall im Beispiel), ist zu beachten, dass der Wert des Pointers, also eine Speicheradresse, intern in mehr als einem Byte verwaltet wird. Lese- und Schreibzugriffe im Hauptprogramm (außerhalb von Interrupt-Routinen) sind daher so zu implementieren, dass alle Teilbytes der Adresse konsistent bleiben, vgl. dazu den folgenden Abschnitt.<br />
<br />
=== Variablen größer 1 Byte ===<br />
<br />
Bei Variablen größer ein Byte, auf die in Interrupt-Routinen und im Hauptprogramm zugegriffen wird, muss darauf geachtet werden, dass die Zugriffe auf die einzelnen Bytes außerhalb der ISR nicht durch einen Interrupt unterbrochen werden. (Allgemeinplatz: AVRs sind 8-bit Controller). Zur Veranschaulichung ein Codefragment:<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
volatile uint16_t gMyCounter16bit;<br />
//...<br />
ISR(...)<br />
{<br />
//...<br />
gMyCounter16Bit++;<br />
//...<br />
}<br />
<br />
int main(void)<br />
{<br />
uint16_t tmpCnt;<br />
//...<br />
// nicht gut: Mglw. hier ein Fehler, wenn ein Byte von MyCounter <br />
// schon in tmpCnt kopiert ist aber vor dem Kopieren des zweiten Bytes <br />
// ein Interrupt auftritt, der den Inhalt von MyCounter verändert.<br />
tmpCnt = gMyCounter16bit; <br />
<br />
<br />
// besser: Änderungen "außerhalb" verhindern -> alle "Teilbytes"<br />
// bleiben konsistent<br />
cli(); // Interrupts deaktivieren<br />
tmpCnt = gMyCounter16Bit;<br />
sei(); // wieder aktivieren<br />
<br />
// oder: vorheriger Status des globalen Interrupt-Flags bleibt erhalten<br />
uint8_t sreg_tmp;<br />
sreg_tmp = SREG; /* Sichern */<br />
cli()<br />
tmpCnt = gMyCounter16Bit;<br />
SREG = sreg_tmp; /* Wiederherstellen */<br />
<br />
// oder: mehrfach lesen, bis man konsistente Daten hat<br />
uint16_t count1 = gMyCounter16Bit;<br />
uint16_t count2 = gMyCounter16Bit;<br />
while (count1 != count2) {<br />
count1 = count2;<br />
count2 = gMyCounter16Bit;<br />
}<br />
tmpCnt = count1;<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Die avr-libc bietet ab Version 1.6.0(?) einige Hilfsfunktionen/Makros, mit der im Beispiel oben gezeigten Funktionalität, die zusätzlich auch sogenannte [http://en.wikipedia.org/wiki/Memory_barrier memory barriers] beinhalten. Diese stehen nach #include <util/atomic.h> zur Verfügung.<br />
<syntaxhighlight lang="c"><br />
//...<br />
#include <util/atomic.h><br />
//...<br />
<br />
// analog zu cli, Zugriff, sei:<br />
ATOMIC_BLOCK(ATOMIC_FORCEON) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
// oder:<br />
<br />
// analog zu Sicherung des SREG, cli, Zugriff und Zurückschreiben des SREG:<br />
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
//...<br />
</syntaxhighlight><br />
<br />
* siehe auch [http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Dokumentation der avr-libc zu atomic.h]<br />
<br />
== Interrupt-Routinen und Registerzugriffe ==<br />
<br />
Falls Register sowohl im Hauptprogramm als auch in Interrupt-Routinen verändert werden, ist darauf zu achten, dass diese Zugriffe sich nicht überlappen. Nur wenige Anweisungen lassen sich in sogenannte "atomare" Zugriffe übersetzen, die nicht von Interrupt-Routinen unterbrochen werden können. <br />
<br />
Zur Veranschaulichung eine Anweisung, bei der ein Bit und im Anschluss drei Bits in einem Register gesetzt werden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
int main(void)<br />
{<br />
//...<br />
PORTA |= (1<<PA0);<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Der Compiler übersetzt diese Anweisungen für einen ATmega128 bei Optimierungsstufe "S" nach:<br />
<br />
<div class="code"><pre><br />
...<br />
PORTA |= (1<<PA0);<br />
d2: d8 9a sbi 0x1b, 0 ; 27 (a)<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
d4: 8b b3 in r24, 0x1b ; 27 (b)<br />
d6: 8c 61 ori r24, 0x1C ; 28 (c)<br />
d8: 8b bb out 0x1b, r24 ; 27 (d)<br />
...<br />
</pre></div><br />
<br />
Das Setzen des einzelnen Bits wird bei eingeschalteter Optimierung für Register im unteren Speicherbereich in eine einzige Assembler-Anweisung (sbi) übersetzt und ist nicht anfällig für Unterbrechungen durch Interrupts. Die Anweisung zum Setzen von drei Bits wird jedoch in drei abhängige Assembler-Anweisungen übersetzt und bietet damit zwei "Angriffspunkte" für Unterbrechungen. Eine Interrupt-Routine könnte nach dem Laden des Ausgangszustands in den Zwischenspeicher (hier Register 24) den Wert des Registers ändern, z.&nbsp;B. ein Bit löschen. Damit würde der Zwischenspeicher nicht mehr mit dem tatsächlichen Zustand übereinstimmen aber dennoch nach der Bitoperation (hier ori) in das Register zurückgeschrieben. <br />
<br />
Beispiel: PORTA sei anfangs 0b00000000. Die erste Anweisung (a) setzt Bit 0 auf '''1''', PORTA ist danach 0b0000000'''1'''. Nun wird im ersten Teil der zweiten Anweisung der Portzustand in ein Register eingelesen (b). Unmittelbar darauf (vor (c)) "feuert" ein Interrupt, in dessen Interrupt-Routine Bit 0 von PORTA gelöscht wird. Nach Verlassen der Interrupt-Routine hat PORTA den Wert 0b00000000. In den beiden noch folgenden Anweisungen des Hauptprogramms wird nun der zwischengespeicherte "alte" Zustand 0b00000001 mit 0b00011100 logisch-'''ODER'''-verknüft (c) und das Ergebnis 0b00011101 in PortA geschrieben (d). Obwohl zwischenzeitlich Bit 0 gelöscht wurde, ist es nach (d) wieder gesetzt. <br />
<br />
Lösungsmöglichkeiten:<br />
* Register ohne besondere Vorkehrungen nicht in Interruptroutinen ''und'' im Hauptprogramm verändern.<br />
* Interrupts vor Veränderungen in Registern, die auch in ISRs verändert werden, deaktivieren ("cli").<br />
* Bits einzeln löschen oder setzen. sbi und cbi können nicht unterbrochen werden. Vorsicht: nur Register im unteren Speicherbereich sind mittels sbi/cbi ansprechbar. Der Compiler kann nur für diese sbi/cbi-Anweisungen generieren. Für Register außerhalb dieses Adressbereichs ("Memory-Mapped"-Register) werden auch zur Manipulation einzelner Bits abhängige Anweisungen erzeugt (lds,...,sts).<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Frequently asked Questions/Fragen Nr. 1 und 8. (Stand: avr-libc Vers. 1.0.4)<br />
<br />
== Interruptflags löschen ==<br />
<br />
Beim Löschen von Interruptflags haben AVRs eine Besonderheit, die auch im Datenblatt beschrieben ist: Es wird zum Löschen eine 1 in das betreffende Bit geschrieben. <br />
<br />
Hinweis:<br /><br />
Bei Registern mit mehreren Interrupt-Flag-Bits (wie die Timer Interrupt Flag Register) '''nicht''' die übliche bitweise VerODERung nehmen, sondern eine direkte Zuweisung machen. Da sonst weitere Flags, als nur das gewünschte, ebenfalls gelöscht werden könnten.<br /><br />
([http://www.mikrocontroller.net/topic/171148#1640133 Erklärung]).<br />
<br />
== Was macht das Hauptprogramm? ==<br />
<br />
Im einfachsten (Ausnahme-)Fall gar nichts mehr. Es ist also durchaus denkbar, ein Programm zu schreiben, welches in der main-Funktion lediglich noch die Interrupts aktiviert und dann in einer Endlosschleife verharrt. Sämtliche Funktionen werden dann in den ISRs abgearbeitet. Diese Vorgehensweise ist jedoch bei den <i>meisten</i> Anwendungen schlecht: man verschenkt eine Verarbeitungsebene und hat außerdem möglicherweise Probleme durch Interruptroutinen, die zu viel Verarbeitungszeit benötigen.<br />
<br />
Für <i>wenige</i> Anwendungen ist diese Vorgehensweise jedoch perfekt: Die Hauptschleife verkommt zu <tt>for(;;) sleep_cpu();</tt> — siehe nächster Abschnitt „Sleep“. Weiterer Vorteil: ISRs brauchen keine(!) Register retten, ein Fall für <tt>ISR(<i>name</i>,ISR_NAKED){ … reti();}</tt>. <i>So</i> können Mikrocontroller für batteriebetriebene Geräte, etwa Fernbedienungen, maximal Energie sparen.<br />
<br />
Normalerweise wird man in den Interruptroutinen nur die bei Auftreten des jeweiligen Interruptereignisses unbedingt notwendigen Operationen ausführen lassen. Alle weniger kritischen Aufgaben werden dann im Hauptprogramm abgearbeitet.<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Interrupts and Signals<br />
<br />
= Sleep-Modes =<br />
<br />
AVR Controller verfügen über eine Reihe von sogenannten [[Sleep Mode |''Sleep-Modes'']] ("Schlaf-Modi"). Diese ermöglichen es, Teile des Controllers abzuschalten. Zum Einen kann damit besonders bei Batteriebetrieb Strom gespart werden, zum Anderen können Komponenten des Controllers deaktiviert werden, die die Genauigkeit des Analog-Digital-Wandlers bzw. des Analog-Comparators negativ beeinflussen. Der Controller wird durch Interrupts aus dem Schlaf geweckt. Welche Interrupts den jeweiligen Schlafmodus beenden, ist einer Tabelle im Datenblatt des jeweiligen Controllers zu entnehmen.<br />
Die Funktionen (eigentlich Makros) der avr-libc stehen nach Einbinden der header-Datei ''sleep.h'' zur Verfügung.<br />
<br />
;set_sleep_mode (uint8_t mode): Setzt den Schlafmodus, der bei Aufruf von sleep() aktiviert wird. In sleep.h sind einige Konstanten definiert (z.&nbsp;B. SLEEP_MODE_PWR_DOWN). Die definierten Modi werden jedoch nicht alle von sämtlichten AVR-Controllern unterstützt.<br />
;sleep_enable(): Aktiviert den gesetzten Schlafmodus, versetzt den Controller aber noch nicht in den Schlafmodus<br />
;sleep_cpu(): Versetzt den Controller in den Schlafmodus .sleep_cpu wird im Prinzip durch die Assembler-Anweisung ''sleep'' ersetzt.<br />
;sleep_disable(): Deaktiviert den gesetzten Schlafmodus<br />
;sleep_mode(): Versetzt den Controller in den mit set_sleep_mode gewählten Schlafmodus. Das Makro entspricht sleep_enable()+sleep_cpu()+sleep_disable(), beinhaltet also nicht die Aktivierung von Interrupts (besser nicht benutzen).<br />
<br />
Bei Anwendung von sleep_cpu() müssen Interrupts also bereits freigeben sein (sei()), da der Controller sonst nicht mehr "aufwachen" kann. sleep_mode() ist nicht geeignet für die Verwendung in ISR Interrupt-Service-Routinen, da bei deren Abarbeitung Interrupts global deaktiviert sind und somit auch die möglichen "Aufwachinterrupts". Abhilfe: stattdessen sleep_enable(), sei(), sleep_cpu(), sleep_disable() und evtl. cli() verwenden (vgl. Dokumentation der avr-libc).<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/sleep.h><br />
<br />
int main(void)<br />
{<br />
...<br />
<br />
while (1) {<br />
...<br />
set_sleep_mode(SLEEP_MODE_PWR_DOWN);<br />
sleep_mode();<br />
<br />
// Code hier wird erst nach Auftreten eines entsprechenden<br />
// "Aufwach-Interrupts" verarbeitet<br />
...<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
In älteren Versionenen der avr-libc wurden nicht alle AVR-Controller durch die sleep-Funktionen richtig angesteuert. Mit avr-libc 1.2.0 wurde die Anzahl der unterstützten Typen jedoch deutlich erweitert. Bei nicht-unterstützten Typen erreicht man die gewünschte Funktionalität durch direkte "[[Bitmanipulation]]" der entsprechenden Register (vgl. Datenblatt) und Aufruf des Sleep-Befehls via Inline-Assembler oder sleep_cpu():<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
// Sleep-Mode "Power-Save" beim ATmega169 "manuell" aktivieren<br />
SMCR = (3<<SM0) | (1<<SE);<br />
asm volatile ("sleep"::); // alternativ sleep_cpu() aus sleep.h<br />
...<br />
</syntaxhighlight><br />
<br />
== Sleep-Modi ==<br />
Die vielen Prozessoren aus der AVR-Familie unterstützen unterschiedliche Sleep-Modi, gefächert nach Vorhandensein von Funktionsblöcken im Controller. Konkrete und verläßliche Auskunft über die tatsächlichen Gegebenheiten finden sich wie immer in den jeweiligen Datenblättern. Die Modi unterscheiden sich darin, welche Funktionsbereiche zum Energiesparen abgeschaltet werden. Davon hängt auch ab, mit welchen Mitteln der Prozessor aus der jeweiligen Schlaftiefe wieder aufgeweckt werden kann.<br />
<br />
;Idle Mode (SLEEP_MODE_IDLE): Die CPU kann durch SPI, USART, Analog Comperator, ADC, TWI, Timer, Watchdog und irgendeinen anderen Interrupt wieder aufgeweckt werden.<br />
<br />
;ADC Noise Reduction Mode (SLEEP_MODE_ADC): In diesem Modus liegt das Hauptaugenmerk darauf, die CPU soweit stillzulegen, dass der ADC möglichst keine Störungen aus dem inneren der CPU auffangen kann, die das Meßergebnis negativ beeinflussen können. Das Aufwachen aus diesem Modus kann ausgelöst werden durch den ADC, externe Interrupts, TWI, Timer und Watchdog.<br />
<br />
;Power-Down Mode (SLEEP_MODE_PWR_DOWN): In diesem Modus wird ein externer Oszillator (Quarz, Quarzoszillator), wenn vorhanden. gestoppt. Geweckt werden kann die CPU durch einen externen Level-Interrupt, TWI, Watchdog, Brown-Out-Reset.<br />
<br />
;Power-Save-Mode (SLEEP_MODE_PWR_SAVE): Power-Save ist identisch zu Power-Down mit einer Ausnahme: Ist der Timer 2 auf die Verwendung eines externen Taktes konfiguriert, so läuft dieser Timer auch im Power-Save weiter und kann die CPU mit einem Interrupt aufwecken.<br />
<br />
;Standby-Mode (SLEEP_MODE_STANDBY, SLEEP_MODE_EXT_STANDBY): Voraussetzung für den Standby-Modus ist die Verwendung eines Quarzes oder eines Quarzoszillators, also einer externen Taktquelle. Ansonsten ist dieser Modus identisch zum Power-Down Modus. Vorteil dieses Modus' ist eine kürzere Aufwachzeit.<br />
<br />
;Abschalten des Brownout Detect (BOD) während der Sleep-Phase (nur P-Typen): Zur Stromersparnis bieten die P-Typen die Möglichkeit den BOD während der Sleep-Phase abzuschalten. Bei einem Atmega88PA beispielsweise, kann dadurch der Stromverbrauch im SLEEP_MODE_PWR_SAVE mit Timer2 im Asynchronmodus mit Uhrenquarz und periodischer Selbstaufweckung um ca. 50% gesenkt werden.<br />
Das Einschalten dieser Funktion geschieht in einer Timed Sequence.<br />
<br />
<syntaxhighlight lang="c"><br />
unsigned char temp0 = MCUCR;<br />
unsigned char temp1 = MCUCR;<br />
temp0 |= (1 << BODS) | (1 << BODSE);<br />
temp1 |= (1 << BODS);<br />
MCUCR = temp0;<br />
MCUCR = temp1;<br />
sleep_cpu();<br />
</syntaxhighlight><br />
<br />
Hierbei ist unbedingt zu beachten, dass das BODS-Bit 3 Takte nach dem Setzen wieder gelöscht wird. Daher muss der Aufruf des Sleep unmittelbar nach dem Setzen erfolgen und das BODS-Bit muss jedes Mal vor einem Sleep Aufruf erneut gesetzt werden.<br />
<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Power Management and Sleep-Modes<br />
* [http://www.mikrocontroller.net/topic/96369#832712 Forenbeitrag] zur "Nichtverwendung" von sleep_mode in ISRs.<br />
<br />
= Zeiger =<br />
Zeiger (engl. ''Pointer'') sind Variablen, die die Adresse von Daten oder Funktionen enthalten und belegen 16 Bits. Die Größe hängt mit dem adressierbaren Speicherbereich zusammen und der GCC reserviert dann den entsprechenden Platz.<br />
Ggf. ist es also günstiger, Indizes auf Arrays (Listen) zu verwenden, so dass der GCC für die Zeigerarithmetik den erforderlichen RAM nur temporär benötigt.<br />
<br />
Siehe auch: [[Zeiger]]<br />
<br />
= Speicherzugriffe =<br />
<br />
Atmel AVR-Controller verfügen typisch über drei Speicher:<br />
<br />
* [[RAM]]: Im RAM (genauer statisches RAM/SRAM) wird vom gcc-Compiler Platz für Variablen reserviert. Auch der Stack befindet sich im RAM. Dieser Speicher ist "flüchtig", d.h. der Inhalt der Variablen geht beim Ausschalten oder einem Zusammenbruch der Spannungsversorgung verloren. Das bedeutet im Umkehrschluss auch, dass der RAM-Inhalt nach RESET vom Pin oder vom Watchdog erhalten bleibt! Der C-Startupcode löscht jedoch den RAM, d.h. setzt alle Bits auf 0. Dadurch erscheinen „normal definierte“ Variablen als 0. Auch Gleitkommazahlen, die schlauerweise so definiert sind, dass eine +0.0 aus lauter Nullbits besteht. Von der Löschung ausschließen kann man RAM-Variablen mit <tt>__attribute__((section(".noinit")))</tt>.<br />
<br />
* Programmspeicher: Ausgeführt als FLASH-Speicher, seitenweise wiederbeschreibbar. Darin ist das Anwendungsprogramm abgelegt.<br />
<br />
* [[EEPROM]]: Nichtflüchtiger Speicher, d.h. der einmal geschriebene Inhalt bleibt auch ohne Stromversorgung erhalten. Byte-weise schreib/lesbar. Im EEPROM werden typischerweise gerätespezifische Werte wie z.&nbsp;B. Kalibrierungswerte von Sensoren abgelegt.<br />
<br />
Einige AVRs besitzen keinen RAM-Speicher, lediglich die Register können als "Arbeitsvariablen"<br />
genutzt werden. Da die Anwendung des avr-gcc auf solch "kleinen" Controllern ohnehin selten sinnvoll ist und auch nur bei einigen RAM-losen Typen nach [http://lightner.net/avr/ATtinyAvrGcc.html "Bastelarbeiten"] möglich ist, werden diese Controller hier nicht weiter berücksichtigt. Auch EEPROM-Speicher ist nicht auf allen Typen verfügbar. Generell sollten die nachfolgenden Erläuterungen auf alle ATmega-Controller und die größeren AT90-Typen übertragbar sein. Für die Typen ATtiny2313, ATtiny26 und viele weitere der "ATtiny-Reihe" gelten die Ausführungen ebenfalls.<br />
<br />
Siehe auch:<br />
* [[Binäre Daten zum Programm hinzufügen]]<br />
== RAM ==<br />
<br />
Die Verwaltung des RAM-Speichers erfolgt durch den Compiler, im Regelfall ist beim Zugriff auf Variablen im RAM nichts Besonderes zu beachten. Die Erläuterungen in jedem brauchbaren C-Buch gelten auch für den vom avr-gcc-Compiler erzeugten Code.<br />
<br />
Um Speicher dynamisch (während der Laufzeit) zu reservieren, kann '''malloc()''' verwendet werden. malloc(size) "alloziert" (~reserviert) einen gewissen Speicherblock mit '''size''' Bytes. Ist kein Platz für den neuen Block, wird NULL (0) zurückgegeben.<br />
<br />
Wird der angelegte Block zu klein (groß), kann die Größe mit realloc() verändert werden. Den allozierten Speicherbereich kann man mit free() wieder freigeben. Wenn das Freigeben eines Blocks vergessen wird spricht man von einem "Speicherleck" (memory leak).<br />
<br />
malloc() legt Speicherblöcke im '''Heap''' an, belegt man zuviel Platz, dann wächst der Heap zu weit nach oben und überschreibt den Stack, und der Controller kommt in Teufels Küche. Das kann leider nicht nur passieren wenn man insgesamt zu viel Speicher anfordert, sondern auch wenn man Blöcke unterschiedlicher Größe in ungünstiger Reihenfolge alloziert/freigibt (siehe Artikel [[Heap-Fragmentierung]]). Aus diesem Grund sollte man malloc() auf Mikrocontrollern sehr sparsam (am besten gar nicht) verwenden.<br />
<br />
Beispiel zur Verwendung von malloc():<br />
<syntaxhighlight lang="c"><br />
#include <stdlib.h><br />
<br />
void foo(void) {<br />
// neuen speicherbereich anlegen,<br />
// platz für 10 uint16<br />
uint16_t* pBuffer = malloc(10 * sizeof(uint16_t));<br />
<br />
// darauf zugreifen, als wärs ein gewohnter Buffer<br />
pBuffer[2] = 5;<br />
<br />
// Speicher (unbedingt!) wieder freigeben<br />
free(pBuffer);<br />
}<br />
</syntaxhighlight><br />
<br />
Wenn (wie in obigem Beispiel) dynamischer Speicher nur für die Dauer einer Funktion benötigt und am Ende wieder freigegeben wird, bietet es sich an, statt malloc() '''alloca()''' zu verwenden. Der Unterschied zu malloc() ist, dass der Speicher auf dem Stack reserviert wird, und beim Verlassen der Funktion automatisch wieder freigegeben wird. Es kann somit kein Speicherleck und keine Fragmentierung entstehen.<br />
<br />
siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/malloc.html AVR Libc Home Page]: Memory Areas and Using malloc()<br />
* [https://www.mikrocontroller.net/topic/479027#5934443 Forumsbeitrag]: RAM Verbrauch auch von lokalen variablen ermitteln<br />
<br />
== Flash mit PROGMEM und pgm_read ==<br />
<br />
→ [http://nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html avr-libc: Doku zu avr/pgmspace.h]<br />
<br />
Ein Zugriff auf Konstanten im Programmspeicher ist mittels avr-gcc erst ab Version 4.7 "transparent" möglich. Um Daten aus dem Flash zu lesen, muss die AVR-Instruktion LPM (''Load from Program Memory'') erzeugt werden, bei Controllern mit mehr als 64kiB Flash auch ELPM.<br />
<br />
Dazu gibt es das AVR-spezifische GCC-Attribut <tt>progmem</tt>, mit dem eine Variablendeklaration im ''static storage''<ref>Variablen der Speicherklasse ''static storage'' haben eine unbegrenzte Lebensdauer. Beispiel für solche Variablen sind globale Variablen, aber auch static-Variablen innerhalb einer Funktion gehören dazu. Beispiele für Variablen, die nicht ''static storage'' sind: auto-Variablen ("normale" lokale Variablen), register-Variablen, durch malloc geschaffene Objekte, etc.</ref> markiert werden kann:<br />
<syntaxhighlight lang="c"><br />
const int value __attribute__((progmem)) = 1;<br />
</syntaxhighlight><br />
<br />
Effekt ist, dass die so markierte Variable nicht im RAM sondern im Flash angelegt wird. Wird durch "normalen" C-Code auf solch eine Variable zugegriffen, wird jedoch aus der gleichen Adresse aus dem RAM gelesen und nicht aus dem Flash! Das ist ein Fehler, den der Compiler aber nicht anzeigt!<br />
<br />
<syntaxhighlight lang="c"><br />
int test = value; // Fehler! PROGMEM Konstanten müssen mit den pgm_read-Funktionen gelesen werden!<br />
</syntaxhighlight><br />
<br />
Zum Lesen aus dem Flash stellt die avr-libc daher zahlreiche Makros zur Verfügung. Zudem wird das Makro <tt>PROGMEM</tt> definiert, das etwas Tipparbeit spart:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
const int value PROGMEM = 1;<br />
</syntaxhighlight><br />
<br />
<tt>progmem</tt> funktioniert im Wesentlichen wie ein Section-Attribut, das die Daten in der Section <tt>.progmem.data</tt> ablegt. Im Gegensatz zum Section-Attribut werden jedoch noch weitere Prüfungen unternommen, ab avr-gcc 4.6 etwa muss die entsprechende Variable <tt>const</tt> sein.<br />
<br />
=== Integer und float ===<br />
<br />
Zum Lesen von Skalaren stellt die avr-libc folgende Makros zu Verfügung, die jeweils ein Argument erhalten: Die 16-Bit Adresse des zu lesenden Wertes<ref>Damit ist der mögliche Speicherbereich für Flash-Konstanten auf 64kiB begrenzt. Einige pgmspace-Funktionen ermöglichen den Lesezugriff auf den gesamten Flash-Speicher, intern via Assembler-Anweisung ELPM. Die Initialisierungswerte des Speicherinhalts jenseits der 64kiB-Marke müssen dann jedoch auf anderem Weg angelegt werden, d.h. nicht per PROGMEM. Evtl. eigene Section und Linker-Optionen. Alt und nicht ganz korrekt: Die avr-libc pgmspace-Funktionen unterstützen nur die unteren 64kiB Flash bei Controllern mit mehr als 64kiB.</ref><br />
<br />
:{| {{Tabelle}}<br />
|+ Übersicht der <tt>pgm_read</tt> Funktionen aus<br/>dem Header <tt>avr/pgmspace.h</tt> der avr-libc<br />
|-<br />
! Gelesener Wert || <tt>pgm_read_xxx</tt> || Anzahl Bytes<br />
|-<br />
| <tt>uint8_t</tt> || <tt>pgm_read_byte</tt> || 1<br />
|-<br />
| <tt>uint16_t</tt> || <tt>pgm_read_word</tt> || 2<br />
|-<br />
| <tt>uint32_t</tt> || <tt>pgm_read_dword</tt> || 4<br />
|-<br />
| <tt>float</tt> || <tt>pgm_read_float</tt><ref>ab avr-libc 1.7.0</ref> || 4<br />
|}<br />
<br />
Soll ein Zeiger gelesen werden, so verwendet man <tt>pgm_read_word</tt> und castet das Ergebnis zum gewünschten Zeiger-Typ.<br />
<br />
;Beispiele:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
/* Byte */<br />
const uint8_t aByte PROGMEM = 123;<br />
<br />
/* int-Array */<br />
const int anArray[] PROGMEM = { 18, 3 ,70 };<br />
<br />
void foo (void)<br />
{<br />
/* Zeiger */<br />
static const uint8_t* const aPointer PROGMEM = &aByte;<br />
<br />
uint8_t a = pgm_read_byte (&aByte);<br />
int a2 = (int) pgm_read_word (&anArray[2]);<br />
const uint8_t* p = (const uint8_t*) pgm_read_word (&aPointer);<br />
}<br />
</syntaxhighlight><br />
<br />
=== Blöcke ===<br />
<br />
In den Flash-Funktionen der avr-libc sind keine der pgm_read_xxxx Nomenklatur folgenden Funktionen, die Speicherblöcke auslesen oder vergleichen. Die enstprechende Funktionen sind Varianten von <tt>memcpy</tt>, <tt>memcmp</tt> und heißt <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, usw. Für weitere Funktionen und deren Prototypen siehe die Dokumentation der avr-libc.<br />
<br />
=== Strings ===<br />
<br />
Strings sind in C nichts anderes als eine Abfolge von Zeichen und einem <tt>'\0'</tt> als Stringende. Der prinzipielle Weg ist daher identisch zum Lesen von Bytes, wobei auf die [[FAQ#Wie funktioniert String-Verarbeitung in C?|Besonderheiten von Strings]] wie 0-Terminierung geachtet werden muss.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
size_t my_string_length (const char *addr)<br />
{<br />
size_t length = 0;<br />
<br />
while (pgm_read_byte (addr++))<br />
{<br />
length++;<br />
}<br />
return length;<br />
}<br />
</syntaxhighlight><br />
<br />
Zur Unterstützung des Programmierers steht das Repertoire der str-Funktionen auch in jeweils eine Variante zur Verfügung, die mit dem Flash-Speicher arbeiten kann. Die Funktionsnamen tragen den Suffix <tt>_P</tt>. Darüber hinaus gibt es das Makro <tt>PSTR</tt>, das ein String-Literal im Flash-Speicher ablegt und die Adresse des Strings liefert:<br />
<br />
Die nachfolgende Funktion liefert 0 zurück, wenn string_im_ram gleich "Hallo Welt" ist. Mit strcmp (String Compare) können wir zwei Strings vergleichen. Der Rückgabewert kann hierbei folgende Werte haben:<br><br />
0 die Strings sind gleich<br />
>0 das erste ungleiche Zeichen in string_im_ram ist größer als in "Hallo Welt"<br />
<0 das erste ungleiche Zeichen in string_im_ram ist kleiner als in "Hallo Welt"<br />
<br><br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
int foo (const char *string_im_ram)<br />
{<br />
return strcmp_P (string_im_ram, PSTR ("Hallo Welt"));<br />
}<br />
</syntaxhighlight><br />
<br />
Zu beachten ist, dass <tt>PSTR</tt> nur innerhalb von Funktionen verwendet werden kann.<br />
<br />
; Array aus Strings:<br />
<br />
Arrays aus Strings im Flash-Speicher werden in zwei Schritten angelegt:<br />
<br />
# Zuerst die einzelnen Elemente des Arrays und<br />
# im Anschluss ein Array, in dem die Startaddressen der Strings abgelegt werden.<br />
<br />
Zum Auslesen wird zuerst die Adresse des gewünschten Elements aus dem Array im Flash-Speicher gelesen, die im Anschluss dazu genutzt wird, um auf das Element (den String) selbst zuzugreifen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
static const char str1[] PROGMEM = "Hund";<br />
static const char str2[] PROGMEM = "Katze";<br />
static const char str3[] PROGMEM = "Maus";<br />
<br />
const char * const array[] PROGMEM = <br />
{<br />
str1, str2, str3<br />
};<br />
<br />
// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]<br />
void read_string (char *buf, size_t i)<br />
{<br />
// Lese die Adresse des i-ten Strings aus array[]<br />
const char *parray = (const char*) pgm_read_ptr (&array[i]);<br />
<br />
// Kopiere den Inhalt der Zeichenkette vom Flash ins RAM<br />
strcpy_P (buf, parray);<br />
}<br />
</syntaxhighlight><br />
<br />
Eine weitere Möglichkeit ist, die Strings in einem 2-dimensionalen char-Array abzulegen anstatt deren Adresse in einem 1-dimensionalen Adress-Array zu speichern.<br />
<br />
Vorteil ist, dass der Code einfacher wird. Nachteil ist, dass bei unterschiedlich langen Strings Speicherplatz verschwendet wird, weil sich die Array-Dimension and der Länge des längsten Strings orientieret. Bei in etwa gleich langen Strings kann es aber sogar Speicherplatz sparen, denn es die Adressen der einzelnen Strings müssen nicht abgespeichert werden.<ref>In unserem Hund-Katze-Maus Beispiel belegt die erste Variante 22 Bytes Daten und 18 Bytes Code, die zweite Variante mit 2-dimensionalem Array belegt 18 Bytes Daten und 20 Bytes Code. Gemessen wurde mit avr-gcc 4.8 -Os für ATmega8.</ref><br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
// Die "6" ist 1 plus die Länge des längsten Strings ("Katze")<br />
const char array[][6] PROGMEM = <br />
{<br />
"Hund", "Katze", "Maus"<br />
};<br />
<br />
// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]<br />
void read_string (char *buf, size_t i)<br />
{<br />
// Kopiere den Inhalt der i-ten Zeichenkette vom Flash ins RAM<br />
strcpy_P (buf, array[i]);<br />
}<br />
</syntaxhighlight><br />
<br />
Siehe dazu auch die avr-libc FAQ: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_rom_array How do I put an array of strings completely in ROM?]<br />
<br />
=== Warum so kompliziert? ===<br />
<br />
Zu dem Thema, warum die Verabeitung von Werten aus dem Flash-Speicher so kompliziert ist, sei hier nur kurz erläutert: Die Harvard-Architektur des AVR weist getrennte Adressräume für Programm (Flash) und Datenspeicher (RAM) auf. Der C-Standard sieht keine unterschiedlichen Adressräume vor.<br />
<br />
Hat man zum Beispiel eine Funktion string_an_uart (const char* s) und übergibt an diese Funktion die Adresse einer Zeichenkette, dann weiß die Funktion nicht, ob die Adresse in den Flash-Speicher oder das RAM zeigt. Weder aus dem Pointer-Wert, also dem Zahlenwert, noch aus dem "const" kann auf den Ort der Ablage geschlossen werden.<br />
<br />
Einige AVR-Compiler bilden die Harvard-Architektur ab, indem sie in einen Pointer nicht nur die Adresse speichern, sondern auch den Ablageort wie ''Flash'' oder ''RAM''. In einem Aufruf einer Funktion wird dann bei Pointer-Parametern neben der Adresse auch der Speicherbereich, auf den der Pointer zeigt, übergeben.<br />
<br />
Dies hat jedoch auch Nachteile, denn bei jedem Zugriff über einen Zeiger muss zur ''Laufzeit'' entschieden werden, wie der Zugriff auszuführen ist und entsprechend länglicher und langsamer wird der erzeugte Code.<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitte Modules/Program Space String Utilities und Abschnitt Modules/Bootloader Support Utilities<br />
<br />
=== Datenzugriff jenseits 64 KiB ===<br />
<br />
Die Zeiger beim <tt>avr-gcc</tt> sind stets 16 Bit breit, können somit also nur 64 KiB Datenspeicher adressieren. Darauf sind auch alle Funktion der libc ausgelegt, welche auf _P enden. Funktionszeiger können beim AVR bis zu 128 KiB Programmspeicher adressieren, weil Funktionsadressen immer 16-Bit-<u>Worte</u> adressieren und nicht Bytes. Der Zugriff auf den RAM ist mit maximal 16 KiB (extern maximal 64 KiB) durch 16-Bit-Zeiger nicht begrenzt.<br />
<br />
Schlauerweise sortiert <tt>avr-gcc</tt> Flash-Konstanten und -Tabellen <i>so</i> um, dass sie an den Anfang des Flash-Speichers, gleich nach der Interrupt-Tabelle, zu liegen kommen. Somit kommt man auch auf Controllern mit mehr als 64 KByte Flash im Normalfall keine Adresse jenseits 64 KiByte erforderlich.<br />
<br />
<small>Auf Controllern mit mehr als 128 KiB Flash bekommen alle Funktionen <i>jenseits</i> 128 KiB ein <b>Trampolin</b> (Sprungbefehl aus 4 Byte) im dem Adressbereich <i>vor<(i> 128 KiB. Damit genügt für alle Funktionszeiger 16 Bit. Wird kein Zeiger benötigt, kann der Optimierer das jeweilige Trampolin entfernen.</small><br />
<br />
Um (dennoch) Zugriff jenseits von 64 KiB zu bewerkstelligen gibt es mehrere Möglichkeiten:<br />
<br />
* Address-Spaces wie <tt>__flash1</tt> oder <tt>__memx</tt>, siehe Abschnitt "[[#Jenseits von flash|Jenseits von __flash]]".<br />
* Die Funktionen bzw. Makros <tt>pgm_read_xxx_far</tt> der AVR-Libc ab Version 1.8.0, wie im folgenden beschrieben. Dafür gibt es die Funktion pgm_get_far_address(), um 32-Bit Pointer eines Objekts zu erhalten<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/pgmspace.h><br />
<br />
//===================================================================<br />
// Define an additional section, which will be placed after all others<br />
//--------------------------------------------------------------------<br />
#define FAR_SECTION __attribute__((__section__(".far_section")))<br />
//--------------------------------------------------------------------<br />
<br />
//====================================================================<br />
// Just an example<br />
//====================================================================<br />
<br />
const char MyString[] FAR_SECTION = "Hier liegt mein FAR-Teststring!";<br />
const char MyBmp64[] FAR_SECTION = {0xAA,0xBB,0xCC,0xDD,0xEE,0xFF,0x00};<br />
<br />
int main(void) {<br />
uint32_t ptr = pgm_get_far_address(MyString);<br />
char MyChar;<br />
DDRC = 0xFF;<br />
do {<br />
MyChar = pgm_read_byte_far(ptr++);<br />
PORTC = MyChar;<br />
} while(MyChar);<br />
}<br />
</syntaxhighlight><br />
<br />
D.h. man muss<br />
* Die Definition der neuen Section <tt>FAR_SECTION</tt> einfügen<br />
* Die konstanten Daten mit dieser Section kennzeichnen<br />
<br />
Dem Linker muss man über diese Section nichts mitteilen, er fügt diese automatisch nach allen bestehenden sections im Flash ein. Der Zugriff auf diese Variablen kann nur mittels direkter Pointerarithmetik erfolgen, eine Indizierung von Arrays mit variablem Index ist nicht möglich. Dabei muss die Größe des Datentyps immer manuell berücksichtigt werden, denn der Pointer ist immer ein Bytepointer!<br />
<br />
<syntaxhighlight lang="c"><br />
int n=3;<br />
MyChar = pgm_read_byte_far(pgm_get_far_address(MyBmp64)+n*sizeof(char));<br />
</syntaxhighlight><br />
<br />
Dabei gibt es einige praktische Probleme.<br />
* Beim recht alten AVR-Studio 4.18 wird die Größe des belegten FLASH-Speichers nicht korrekt angezeigt, die Daten landen aber im HEX-File.<br />
* beim moderneren Atmelstudio 6.2 sieht man in der Consolenausgabe die richtige Größe, welche von avr-size ermittelt wurde, diese wird aber dann in der 2. Ausgabe durch Atmelstudio falsch dargestellt<br />
* Die Arduino-IDE rechnet richtig, siehe dieser [https://www.mikrocontroller.net/topic/511511?goto=6568945#6568945 Forumsbeitrag].<br />
<br />
== Flash mit __flash und Embedded-C ==<br />
<br />
Ab Version 4.7 unterstützt avr-gcc ''Adress-Spaces'' gemäß dem Embedded-C Dokument ISO/IEC TR18037. Der geläufigste Adress-Space ist <tt>__flash</tt>, der im Gegensatz zu <tt>progmem</tt> kein GCC-Attribut ist, sondern ein Qualifier und damit syntaktisch ähnlich verwendet wird wie <tt>const</tt> oder <tt>volatile</tt>.<br />
<br />
GCC kennt keine eigene Option zum Aktivieren von Embedded-C, es wird als GNU-C Erweiterung behandelt. Daher müssen C-Module, die Address-Spaces verwenden, mit <tt>-std=gnu99</tt> o.ä. compiliert werden.<br />
<br />
<syntaxhighlight lang="c"><br />
static const __flash int value = 10;<br />
<br />
int get_value (void)<br />
{<br />
return value;<br />
}<br />
</syntaxhighlight><br />
<br />
# Im Gegensatz zu <tt>progmem</tt> sind keine speziellen Bibliotheksfunktionen oder -makros für den Zugriff mehr notwendig: Der Code zum Lesen der Variable ist "normales" C.<br />
# Die Variable wird im richtigen Speicherbereich (Flash) angelegt.<br />
# <tt>__flash</tt> ist nur zusammen mit read-only Objekten oder Zeigern, d.h. nur zusammen mit <tt>const</tt>, erlaubt.<br />
# Zugriffe wie im obigen Beispiel können (weg)optimiert werden. Das Beispiel entspricht einem "<tt>return 10</tt>". Es besteht keine Notwendigkeit, für <tt>value</tt> überhaupt Flash-Speicher zu reservieren.<br />
<br />
Auch Zeiger-Indirektionen sind problemlos möglich. Zu beachten ist, dass <tt>__flash</tt> auf der richtigen Seite des "<tt>*</tt>" in der Zeigerdeklaration bzw. -definition steht:<br />
* '''Rechts vom <tt>*</tt>:''' Der Zeiger selbst liegt im Flash<br />
* '''Links vom <tt>*</tt>:''' Der Zeiger enthält eine Flash-Adresse<br />
<br />
<syntaxhighlight lang="c"><br />
// val ist eine Variable im Flash<br />
const __flash int val = 42;<br />
<br />
// pval liegt auch im Flash und enthält die Adresse von val<br />
const __flash int* const __flash pval = &val;<br />
<br />
int get_val (void)<br />
{<br />
// liest den Wert von val über die in pval abgelegte Adresse<br />
return *pval;<br />
}<br />
</syntaxhighlight><br />
<br />
=== Blöcke ===<br />
<br />
Um Speicherbereiche vom Flash in den RAM zu kopieren, gibt es zwei Möglichkeiten: Zum einen können wie bei <tt>progmem</tt> beschreiben die Funktionen der avr-libc wie <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, <tt>movmem_P</tt>, etc. verwendet werden:<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
// Eine Datenstruktur<br />
typedef struct<br />
{<br />
int id;<br />
char buf[10];<br />
} data_t;<br />
<br />
extern void uart_send (const void*, size_t);<br />
<br />
void send_data (const __flash data_t *pdata)<br />
{<br />
// buf wird auf dem Stack angelegt<br />
data_t buf;<br />
<br />
// Kopiere Daten vom Flash nach buf ins RAM<br />
memcpy_P (&buf, pdata, sizeof (data_t));<br />
<br />
// Sende die Daten in buf<br />
uart_send (&buf, sizeof (data_t));<br />
}<br />
</syntaxhighlight><br />
<br />
Zum anderen kann eine Struktur auch über direktes Kopieren ins RAM geladen werden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdlib.h><br />
<br />
// Eine Datenstruktur<br />
typedef struct<br />
{<br />
int id;<br />
char buf[10];<br />
} data_t;<br />
<br />
extern void uart_send (const void*, size_t);<br />
<br />
void send_data (const __flash data_t *pdata)<br />
{<br />
// Kopiere Daten ins RAM. buf wird auf dem Stack angelegt<br />
const data_t buf = *pdata;<br />
<br />
// Verwendet die Daten in buf<br />
uart_send (&buf, sizeof (data_t));<br />
}<br />
</syntaxhighlight><br />
<br />
=== Strings ===<br />
<br />
Natürlich können auch Strings im Flash abgelegt werden und auch mit Funktionen wie <tt>strcpy_P</tt> aus der avr-libc verarbeitet werden. Zudem ist es möglich, Flash-Zeiger mit der Adresse eines String-Literals zu initialisieren:<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
#define FSTR(X) ((const __flash char[]) { X } )<br />
<br />
const __flash char * const __flash array[] = <br />
{<br />
FSTR ("Hund"), FSTR ("Katze"), FSTR ("Maus")<br />
};<br />
<br />
size_t get_len (uint8_t tier)<br />
{<br />
return strlen_P (array[tier]);<br />
}<br />
</syntaxhighlight><br />
<br />
Leider sieht der Embedded-C Draft nicht vor, String-Literale direkt in einem anderen Adress-Space als ''generic'' anzulegen, so dass hier der Umweg über <tt>FSTR</tt> genommen werden muss. Dieses Konstrukt ist nur ausserhalb von Funktionen möglich und kann daher nicht als Ersatz für <tt>PSTR</tt> aus der avr-libc dienen.<br />
<br />
Soll <tt>array</tt> ein 2-dimensonales Array sein anstatt ein 1-dimensionales Array von Zeigern, dann geht das ohne große Verrenkungen:<br />
<br />
<syntaxhighlight lang="c"><br />
// Die 6 ergibt sich aus 1 plus der Länge des längsten Strings "Katze"<br />
const __flash char array[][6] = <br />
{<br />
"Hund", "Katze", "Maus"<br />
};<br />
</syntaxhighlight><br />
<br />
Weiters besteht die Möglichkeit, <tt>array</tt> analog anzulegen, wie man es mit <tt>PROGMEM</tt> machen würde: Jeder String wird explizit angelegt und seine Adresse bei der Initialisierung von <tt>array</tt> verwendet. Dies entspricht dem ersten Beispiel eines 1-dimensionalen Zeigerarrays:<br />
<br />
<syntaxhighlight lang="c"><br />
static const __flash char strHund[] = "Hund";<br />
static const __flash char strKatze[] = "Katze";<br />
static const __flash char strMaus[] = "Maus";<br />
<br />
const __flash char * const __flash array[] = <br />
{<br />
strHund, strKatze, strMaus<br />
};<br />
</syntaxhighlight><br />
<br />
=== Casts ===<br />
<br />
Embedded C fordert, dass zwei Adress-Spaces entweder disjunkt sind – d.h. sie enthalten keine gemeinsamen Adressen – oder aber ein Space komplett im anderen enthalten ist, also eine Teilmengen-Beziehung besteht. Die Adress-Spaces von avr-gcc sind so implementiert, dass jeder Space Teilmenge jedes anderes ist. Zwar haben Spaces wie RAM und Flash physikalisch keinen Speicherbereich gemein, allerdings ermöglicht diese Implementierung das Casten von Zeigern zu unterschiedlichen Adress-Spaces<ref>Im Gegensatz zu einem Attribute wie <tt>progmem</tt> ist ein (Adress Space) Qualifier Teil des Zeiger-Typs.</ref>: <br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdbool.h><br />
<br />
char read_char (const char *address, bool data_in_flash)<br />
{<br />
if (data_in_flash)<br />
return *(const __flash char*) address;<br />
else<br />
return *address;<br />
}<br />
</syntaxhighlight><br />
<br />
Der Cast selbst erzeugt keinen zusätzlichen Code, da eine RAM-Adresse und eine Flash-Adresse die gleiche Binärdarstellung haben. Allerdings wird über den nach <tt>__flash</tt> gecasteten Zeiger anders zugegriffen, nämlich per LPM.<br />
<br />
=== Jenseits von __flash ===<br />
<br />
Ausser <tt>__flash</tt> gibt es auch folgende Address-Spaces:<br />
<br />
==== <tt>__flash</tt>''N'' ====<br />
<br />
<tt>__flash</tt>''N'' mit ''N'' = 1..5 sind fünf weitere Spaces, die analog zu <tt>__flash</tt> funktionieren und deren Zeiger ebenfalls 16 Bit breit sind. avr-gcc erwartet, dass die zugehörigen Daten, welche in die Section <tt>.progmem</tt>''N''<tt>.data</tt> abgelegt werden, so lokatiert sind, dass das high-Byte der Adresse (Bits 16..23) gerade ''N'' ist.<br />
<br />
Weil Daten- und Code-Layout höchst projektspezifisch sind, werden diese Sections im Standard Linker-Skript nicht beschrieben. Um funktionsfähigen Code zu erhalten, muss daher ein eigenes Linker-Skript zur Verfügung gestellt werden, das diese Sections beschreibt, oder es kann eine Erweiterung des Standard Skripts bereitgestellt werden falls dies möglich ist.<br />
<br />
;Beispiel: Eine Applikation, die <tt>__flash2</tt> verwendet. Die zugehörende Section <tt>.progmem2.data</tt> wird hinter <tt>.text</tt> angeordnet aber vor den Initializern für <tt>.data</tt>. Dazu wird beim Linken das ld-Skript Fragment per <tt>-Tflash12.ld</tt> angegeben, welches dann an der gewünschten Stelle in das default Skript eingefügt wird:<br />
:{| <!-- Tabelle bitte für korrekte Einrückung belassen --><br />
|-<br />
|<pre><br />
SECTIONS<br />
{<br />
.flash2 :<br />
{<br />
. = MAX (ABSOLUTE(0x20000), .);<br />
PROVIDE (__flash2_start = .);<br />
. = ALIGN(2);<br />
*(.flash2.text*)<br />
*(.progmem2.data*)<br />
PROVIDE (__flash2_end = .);<br />
<br />
ASSERT (__flash2_start == __flash2_end || __flash2_start >= ABSOLUTE(0x20000),<br />
"__flash2 data in .progmem2.data below 0x20000");<br />
ASSERT (__flash2_start == __flash2_end || __flash2_end <= ABSOLUTE(0x30000),<br />
"__flash2 data in .progmem2.data exceeds 0x30000");<br />
}<br />
}<br />
INSERT AFTER .text<br />
</pre><br />
|}<br />
<br />
==== <tt>__memx</tt> ====<br />
<br />
Dieser Address-Space implementiert 3-Byte Zeiger und unterstützt Lesen über 64KiB-Segmentgrenzen hinweg. Das MSB (Bit 23) gibt dabei an, ob der <tt>__memx</tt>-Zeiger eine Flash-Adresse enthält (Bit23 = 0) oder eine RAM-Adresse (Bit23 = 1), was folgenden Code erlaubt:<br />
<br />
<syntaxhighlight lang="c"><br />
const __memx int a_flash = 42;<br />
const int a_ram = 100;<br />
<br />
int get_a (const __memx int* pa)<br />
{<br />
return *pa;<br />
}<br />
<br />
int main (void)<br />
{<br />
return get_a (&a_flash) + get_a (&a_ram);<br />
}</syntaxhighlight><br />
<br />
Dies bedeutet, dass erst zur ''Laufzeit'' entschieden werden kann, ob <tt>get_a</tt> die Daten aus dem RAM oder aus dem Flash lesen soll, was <tt>__memx</tt> im Vergleich zu den anderen Address-Spaces langsamer macht. Ausserdem ist zu beachten, dass <tt>__memx</tt>-Zeiger zwar 24-Bit Zeiger sind, die zugrundeliegende Adress-Arithmetik jedoch gemäß dem C-Standard erfolgt, also als 16-Bit Arithmetik. Bestehende Funktion der avr-libc wie z.B. printf_P funktionieren damit ebensowenig wie printf! Wenn man <tt>__memx</tt> verwenden will, braucht man dafür eigene Funktionen.<br />
<br />
=== __flash, progmem und Portierbarkeit ===<br />
<br />
Da ab er aktuellen Compilerversion 4.7 sowohl <tt>__flash</tt> als auch <tt>PROGMEM</tt> und die <tt>pgm_read</tt>-Funktionen zur Verfügung stehen, ergibt sich die Frage, welche Variante "besser" ist und wie zwischen ihnen hin- und her zu portieren ist.<br />
<br />
Zunächst sei erwähnt, dass <tt>__flash</tt> kein Ersatz für <tt>PROGMEM</tt> ist, sondern lediglich eine Alternative dazu. Das "alte" progmem wird weiterhin mir gleicher Semantik unterstützt, so dass alter Code ohne Änderungen mit den neueren Compilerversionen übersetzbar bleibt.<br />
<br />
Von der Codegüte her dürften sich keine großen Unterschiede ergeben. Es ist nicht zu erwarten, dass die eine oder die andere Variante wesentlich besseren oder schlechteren Code erzeugt — von einer Ausnahme abgesehen: Der Wert beim Zugriff ist zur Compilezeit bekannt und kann daher eliminiert werden.<br />
<syntaxhighlight lang="c"><br />
static const __flash char x[] = { 'A', 'V', 'R' };<br />
<br />
char foo (void)<br />
{<br />
return x[2];<br />
}<br />
</syntaxhighlight><br />
Dies wird übersetzt wie "<tt>return 'R';</tt>", und das Array <tt>x[]</tt> kann komplett wegoptimiert werden und entfallen.<br />
<br />
==== progmem → __flash ====<br />
<br />
Portierung in diese Richtung bedeutet, alten Code anzupassen. Zwingend ist die Portierung nicht, da <tt>progmem</tt> weiterhin unterstützt wird.<br />
Allerdings ist eine Quelle mit <tt>__flash</tt> besser lesbar, denn der Code wird von den <tt>pgm_read</tt>-Funktionen befreit, die vor allem bei Mehrfach-Indirektion den Code ziemlich verunstalten und unleserlich machen können.<br />
Weiterer Vorteil von <tt>_flash</tt> ist, daß eine striktere Typprüfung erfolgen kann.<br />
<br />
Eine Portierung wird man in zwei Schritten vornehmen:<br />
<br />
;1. Definitionen von Flash-Variablen werden angepasst:<br />
<br />
Vorher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
static const char hund[] PROGMEM = "Hund";<br />
static const char katze[] PROGMEM = "Katze";<br />
static const char maus[] PROGMEM = "Maus";<br />
<br />
const char * const tier[] PROGMEM = <br />
{<br />
hund, katze, maus<br />
};<br />
</syntaxhighlight><br />
|}<br />
<br />
Nachher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
static const __flash char hund[] = "Hund";<br />
static const __flash char katze[] = "Katze";<br />
static const __flash char maus[] = "Maus";<br />
<br />
const __flash char * const __flash tier[] = <br />
{<br />
hund, katze, maus<br />
};<br />
</syntaxhighlight><br />
|}<br />
<br />
Der Header <tt>avr/pgmspace.h</tt> wird nicht mehr benötigt. Im Gegensatz zu <tt>progmem</tt> müssen Qualifier immer links von der definierten Variablen stehen; bei Attributen wie <tt>progmem</tt> ist das mehr oder weniger egal.<br />
<br />
Nachdem diese Anpassung erfolgreich abgeschlossen ist, folgt Schritt<br />
<br />
; 2. Der Code wird von <tt>pgm_read</tt>-Aufrufen bereinigt:<br />
<br />
Vorher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
extern const char *tier[];<br />
<br />
char first_letter (uint8_t i)<br />
{<br />
const char* ptier = (const char*) pgm_read_word (&tier[i]);<br />
return (char) pgm_read_byte (&ptier[0]);<br />
}<br />
</syntaxhighlight><br />
|}<br />
<br />
Nachher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <stdint.h><br />
<br />
extern const __flash char * const __flash tier[];<br />
<br />
char first_letter (uint8_t i)<br />
{<br />
return tier[i][0];<br />
}<br />
</syntaxhighlight><br />
|}<br />
<br />
=== Von-Neumannisierung „zu Fuß“ ===<br />
<br />
„Wenn der Prophet nicht zum Berg geht, muss der Berg zum Propheten kommen“.<br />
<br />
Bei Mikrocontrollern mit weniger als 64 KiB Gesamtspeicher ist das mit dem <tt>__flash</tt> oder <tt>PROGMEM</tt> nicht nur lästig sondern erfordert eine Vielzahl von Bibliotheksfunktionen (hier: die auf _P enden) die alle fast dasselbe machen.<br />
<br />
Neuere PIC-Mikrocontroller sowie (limitiert auf LPM) AVR xMegas verfügen bereits über eine Von-Neumannisierung von RAM und Flash in Hardware, nur bei AVRs „will der Prophet nicht zum Berg“, da geht das nicht.<br />
<br />
Hier behilft man sich mit einem Satz aus Inline-Funktionen und Makros, die je nach Bit 15 des Zeigers RAM oder Flash lesen. So setzen die Makros <tt>F(x)</tt> (x als String-Konstante) bzw, <tt>FP(x)</tt> (x als Flash-Adresse) das Bit 15 der Adresse. Die darauf ausgerichtete Bibliotheksfunktion (bspw. ein selbst geschriebener <tt>printf()</tt>-Ersatz) verarbeitet dann den Formatstring aus RAM oder Flash und kommt auch mit <tt>"%s"</tt>-Substitutionen problemlos zurecht.<br />
<br />
== Dateien direkt im Flash einbinden ==<br />
<br />
Wenn man größere Dateien direkt im Programm einbinden will, ohne sie vorher in C Quelltext umzuwandeln, muss man das mit dem Linker machen. Wie das geht steht hier.<br />
<br />
* [http://www.atmel.com/webdoc/avrlibcreferencemanual/FAQ_1faq_binarydata.html Atmel, avr gcc Dokumentation]<br />
* [http://nongnu.org/avr-libc/user-manual/FAQ.html#faq_binarydata Nongnu avr gcc Dokumentation]<br />
<br />
Wie man das dann praktisch umsetzt, sieht man in diesem Beitrag.<br />
<br />
* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056910 Forumsbeitrag]: Binärdateien mittels Linker einbinden<br />
* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056947 Forumsbeitrag]: Ein kleines Tool zum Umwandeln von Binärdateien in C-Quelltext.<br />
<br />
== Flash in der Anwendung schreiben ==<br />
<br />
Bei AVRs mit "self-programming"-Option – auch bekannt als [[Bootloader]]-Support – können Teile des Flash-Speichers vom Anwendungsprogramm beschrieben werden. Dies ist nur möglich, wenn die Schreibfunktion in einem besonderen Speicherbereich, der Boot-Section des Programmspeichers/Flash, abgelegt ist.<br />
<br />
Bei einigen kleinen AVRs gibt es keine gesonderte Boot-Section, bei diesen kann der Flashspeicher von jeder Stelle des Programms geschrieben werden. Für Details sei hier auf das jeweilige Controller-Datenblatt und die Erläuterungen zum Modul boot.h der avr-libc verwiesen. Es existieren auch Application-Notes dazu bei atmel.com, die auf avr-gcc-Code übertragbar sind.<br />
<br />
Siehe auch: <br />
* Forumsbeitrag [http://www.mikrocontroller.net/topic/163632#1561622 Daten in Programmspeicher speichern]<br />
<br />
== EEPROM ==<br />
<br />
Möchte man Werte aus einem Programm heraus so speichern, dass sie auch nach dem Abschalten der Versorgungsspannung noch erhalten bleiben und nach dem Wiederherstellen der Versorgungsspannung bei erneutem Programmstart wieder zur Verfügung stehen, dann benutzt man das EEPROM.<br />
<br />
Schreib- und Lesezugriffe auf den EEPROM-Speicher erfolgen über die im Modul eeprom.h der avr-libc definierten Funktionen. Mit diesen Funktionen können einzelne Bytes, Datenworte (16 Bit), Fließkommawerte (32 Bit, single-precision, float) und Datenblöcke geschrieben und gelesen werden.<br />
<br />
Diese Funktionen kümmern sich auch um diverse Details, die bei der Benutzung des EEPROMs normalerweise notwendig sind:<br />
* EEPROM-Operationen sind im Vergleich relativ langsam. Man muss daher darauf achten, dass eine vorhergehende Operation abgeschlossen ist, ehe die nächste Operation mit dem EEPROM gestartet wird. Die in der avr-libc implementierten Funktionen aus eeprom.h berücksichtigten dies. Soll beim Aufruf einer EEPROM-Funktion sichergestellt werden, dass diese nicht intern in einer Warteschleife auf den Abschluss der vorherigen Operation wartet, kann vorher per eeprom_is_ready testen, ob der Zugriff auf den EEPROM-Speicher sofort möglich ist.<br />
* Es ist darauf zu achten, dass die EEPROM-Funktionen nicht durch einen Interrupt unterbrochen werden. Einige Phasen des Zugriffs sind zeitkritisch und müssen in einer definierten bzw. begrenzten Anzahl von Takten durchgeführt werden. Durch einen unterbrechenden Interrupt würde diese Restriktion nicht mehr eingehalten. Auch dieses Detail wird von den avr-libc Funktionen berücksichtigt, so dass man sich als C-Programmierer nicht darum kümmern muss. Innerhalb der Funktionen werden Interrupts vor der "EEPROM-Sequenz" global deaktiviert und im Anschluss, falls vorher auch schon eingeschaltet, wieder aktiviert.<br />
<br />
Man beachte, dass der EEPROM-Speicher nur eine begrenzte Anzahl von Schreibzugriffen zulässt. Beschreibt man eine EEPROM-Zelle öfter als die im Datenblatt zugesicherte Anzahl (typisch 100.000), wird die Funktion der Zelle nicht mehr garantiert. Dies gilt für jede einzelne Zelle. <br />
<br />
Bei geschickter Programmierung (z.&nbsp;B. Ring-Puffer), bei der die zu beschreibenden Zellen regelmäßig gewechselt werden, kann man eine deutlich höhere Anzahl an Schreibzugriffen, bezogen auf den gesamten EEPROM-Speicher, erreichen. Auf jeden Fall sollte man aber eine Abschätzung über die zu erwartende Lebensdauer des EEPROM durchführen. Wird ein Wert im EEPROM im Durchschnitt nur einmal pro Woche verändert, wird die garantierte Anzahl der Schreibzyklen innerhalb der voraussichtlichen Verwendungszeit des Controllers sicherlich nicht erreicht werden. Welcher Controller ist schon 100000 / 52 = 1923 Jahre im Einsatz? In diesem Fall lohnt es sich daher nicht, erweiterte Programmfunktionen zu implementieren, mit denen die Anzahl der Schreibzugriffe minimiert wird.<br />
<br />
Eine weitere Möglichkeit, Schreibzyklen einzusparen, besteht in der Vorabprüfung, ob der zu speichernde Wert im EEPROM bereits enthalten ist und nur veränderte Werte zu schreiben. In aktuelleren Versionen der avr-libc sind bereits Funktionen enthalten, die solche Prüfungen enthalten (eeprom_update_*).<br />
<br />
Eine dritte Möglichkeit speichert alle Daten zunächst im RAM, wo sie beliebig oft beschrieben werden können. Nur beim Ausschalten oder beim Ausfall der Stromversorgung werden die Daten in den EEPROM geschrieben. Wie man das richtig macht sieht man im Artikel [[Speicher#EEPROM Schreibzugriffe minimieren | Speicher]].<br />
<br />
Lesezugriffe können beliebig oft durchgeführt werden. Sie unterliegen keinen Einschränkungen in Bezug auf deren Anzahl. <br />
<br />
=== EEMEM ===<br />
Um eine Variable im EEPROM anzulegen, stellt die avr-libc das Makro EEMEM zur Verfügung:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdint.h><br />
#include <avr/eeprom.h><br />
<br />
/* Byte */<br />
uint8_t eeFooByte EEMEM = 123;<br />
<br />
/* Wort */<br />
uint16_t eeFooWord EEMEM = 12345;<br />
<br />
/* float */<br />
float eeFooFloat EEMEM;<br />
<br />
/* Byte-Array */<br />
uint8_t eeFooByteArray1[] EEMEM = { 18, 3, 70 };<br />
uint8_t eeFooByteArray2[] EEMEM = { 30, 7, 79 };<br />
<br />
/* 16-bit unsigned short feld */<br />
uint16_t eeFooWordArray1[4] EEMEM;<br />
</syntaxhighlight><br />
<br />
Die grundsätzliche Vorgehensweise ist identisch zur Verwendung von PROGMEM. Auch hier erzeugt man sich spezielle attributierte Variablen (EEMEM erledigt das), die vom Compiler/Linker nicht wie normale Variablen behandelt werden. Compiler/Linker kümmern sich zwar darum, dass diesen Variablen eine Adresse zugewiesen wird, diese Adresse ist dann aber die Adresse der 'Variablen' im EEPROM. Um die dort gespeicherten Werte zu lesen bzw. zu schreiben, übergibt man diese Adresse an spezielle Funktionen, die die entsprechenden Werte aus dem EEPROM holen bzw. das EEPROM neu beschreiben.<br />
<br />
Die mittels EEMEM erzeugten 'Variablen' sind also mehr als Platzhalter zu verstehen, denn als echte Variablen. Es geht nur darum, im C-Programm symbolische Namen zur Verfügung zu haben, anstatt mit echten EEPROM-Adressen hantieren zu müssen, etwas, das grundsätzlich aber auch genauso gut möglich ist. Nur muss man sich in diesem Fall dann selbst darum kümmern, dass mehrere 'Variablen' ohne Überschneidung im EEPROM angeordnet werden.<br />
<br />
=== Bytes lesen/schreiben ===<br />
<br />
Die avr-libc Funktion zum Lesen eines Bytes heißt eeprom_read_byte. Parameter ist die Adresse des Bytes im EEPROM. Geschrieben wird über die Funktion eeprom_write_byte mit den Parametern Adresse und Inhalt. Anwendungsbeispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#define EEPROM_DEF 0xFF<br />
<br />
void eeprom_example (void)<br />
{<br />
uint8_t myByte;<br />
<br />
// myByte lesen (Wert = 123)<br />
myByte = eeprom_read_byte (&eeFooByte);<br />
<br />
// der Wert 99 wird im EEPROM an die Adresse der<br />
// Variablen eeFooByte geschrieben<br />
myByte = 99;<br />
eeprom_write_byte(&eeFooByte, myByte); // schreiben<br />
<br />
myByte = eeprom_read_byte (&eeFooByteArray1[1]); <br />
// myByte hat nun den Wert 3<br />
<br />
// Beispiel fuer eeprom_update_byte: die EEPROM-Zelle wird nur<br />
// dann beschrieben, wenn deren Inhalt sich vom Parameterwert<br />
// unterscheidet. In diesem Beispiel erfolgt also kein Schreib-<br />
// zugriff, da die Werte gleich sind.<br />
eeprom_update_byte(&eeFooByte, myByte);<br />
<br />
<br />
// Beispiel zur "Sicherung" gegen leeres EEPROM nach "Chip Erase"<br />
// (z. B. wenn die .eep-Datei nach Programmierung einer neuen Version<br />
// des Programms nicht in den EEPROM uebertragen wurde und EESAVE<br />
// deaktiviert ist (unprogrammed/1)<br />
// <br />
// Vorsicht: wenn EESAVE "programmed" ist, hilft diese Sicherung nicht<br />
// weiter, da die Speicheraddressen in einem neuen/erweiterten Programm<br />
// moeglicherweise verschoben wurden. An der Stelle &eeFooByte steht<br />
// dann u.U. der Wert einer anderen Variable aus einer "alten" Version.<br />
<br />
uint8_t fooByteDefault = 222;<br />
if ((myByte = eeprom_read_byte (&eeFooByte)) == EEPROM_DEF)<br />
{<br />
myByte = fooByteDefault;<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
=== Wort lesen/schreiben ===<br />
<br />
Schreiben und Lesen von Datenworten erfolgt analog zur Vorgehensweise bei Bytes:<br />
<br />
<syntaxhighlight lang="c"><br />
// lesen<br />
uint16_t myWord = eeprom_read_word (&eeFooWord);<br />
<br />
// schreiben<br />
eeprom_write_word (&eeFooWord, 2222);<br />
</syntaxhighlight><br />
<br />
=== Block lesen/schreiben ===<br />
<br />
Lesen und Schreiben von Datenblöcken erfolgt über die Funktionen <code>eeprom_read_block()</code> bzw. <code>eeprom_write_block()</code>. Die Funktionen erwarten drei Parameter: die Adresse der Quell- bzw. Zieldaten im RAM, die EEPROM-Adresse und die Länge des Datenblocks in Bytes als <code>size_t</code>.<br />
<syntaxhighlight lang="c"><br />
uint8_t myByteBuffer[3];<br />
uint16_t myWordBuffer[4];<br />
<br />
void eeprom_block_example (void)<br />
{<br />
/* Datenblock aus EEPROM lesen */<br />
<br />
/* liest 3 Bytes ab der von eeFooByteArray1 definierten EEPROM-Adresse<br />
in das RAM-Array myByteBuffer */<br />
eeprom_read_block (myByteBuffer, eeFooByteArray1, 3);<br />
<br />
/* dito mit etwas Absicherung betr. der Länge */<br />
eeprom_read_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));<br />
<br />
/* und nun mit 16-Bit Array */<br />
eeprom_read_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));<br />
<br />
/* Datenblock in EEPROM schreiben */<br />
eeprom_write_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));<br />
eeprom_write_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));<br />
}<br />
</syntaxhighlight><br />
<br />
=== Fließkommawerte lesen/schreiben ===<br />
<br />
In der avr-libc stehen auch EEPROM-Funktionen für Variablen des Typs float (Fließkommazahlen mit "einfacher" Genauigkeit) zur Verfügung.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/eeprom.h><br />
<br />
float eeFloat EEMEM = 12.34f;<br />
<br />
float void eeprom_float_example(float value)<br />
{<br />
/* float in EEPROM schreiben */<br />
eeprom_write_float(&eeFloat, value);<br />
<br />
/* float aus EEPROM lesen */<br />
return eeprom_read_float(&eeFloat);<br />
}</syntaxhighlight><br />
<br />
=== EEPROM-Speicherabbild in .eep-Datei ===<br />
<br />
Mit den zum Compiler gehörenden Werkzeugen kann der aus den Variablendeklarationen abgeleitete EEPROM-Inhalt in eine Datei geschrieben werden. Die übliche Dateiendung ist .eep, Daten im Intel Hex-Format. Damit können Standardwerte für den EEPROM-Inhalt im Quellcode definiert werden. <br />
<br />
Makefiles nach WinAVR/MFile-Vorlage enthalten bereits die notwendigen Einstellungen, siehe dazu die Erläuterungen im [[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]].<br />
<br />
Der Inhalt der eep-Datei muss ebenfalls zum Mikrocontroller übertragen werden, wenn die Initialisierungswerte aus der Deklaration vom Programm erwartet werden. Ansonsten enthält der EEPROM-Speicher nach der Übertragung des Programmers mittels ISP abhängig von der Einstellung der EESAVE-Fuse<ref>vgl. Datenblatt Abschnitt Fuse Bits</ref> nicht die korrekten Werte:<br />
; EESAVE = 0 (programmed): Die Daten im EEPROM bleiben erhalten. Werden sie nicht neu geschrieben, so enthält das EEPROM evtl. Daten, die nicht mehr zum Programm passen.<br />
; EESAVE = 1 (unprogrammed): Beim Programmieren werden die Daten im EEPROM gelöscht, also auf 0xff gesetzt.<br />
<br />
Als Sicherung kann man im Programm nochmals die Standardwerte vorhalten, beim Lesen auf 0xFF prüfen und gegebenenfalls einen Standardwert nutzen. Das geht natürlich nur, wenn 0xFF selbst nicht als Datenwert vorkommen kann.<br />
<syntaxhighlight lang="c"><br />
#define DUTY_CYCLE_DEFAULT 0x80<br />
<br />
uint8_t eeDutyCycle EEMEM; // Platzhalter für EEPROM<br />
uint8_t DutyCycle; // die echte Variable<br />
<br />
<br />
int main(void)<br />
{<br />
DutyCycle = eeprom_read_byte( &eeDutyCycle );<br />
if( DutyCycle == 0xFF ) // das allererste mal. Im EEPROM steht noch kein gültiger Wert<br />
{<br />
DutyCycle = DUTY_CYCLE_DEFAULT;<br />
eeprom_writeByte( &eeDutyCycle, DutyCycle );<br />
}<br />
<br />
...<br />
</syntaxhighlight><br />
<br />
=== Direkter Zugriff auf EEPROM-Adressen ===<br />
<br />
Will man direkt auf bestimmte EEPROM Adressen zugreifen, dann sind folgende IAR-kompatiblen Makros <tt>_EEGET</tt> und <tt>_EEPUT</tt> hilfreich, um sich die Typecasts zu ersparen.<br />
<br />
;Hinweis: Die nachfolgend gezeigten Makros und Zugriffe auf absolute Adressen sind in Normalfall nicht nötig und nur auf sehr wenige, spezielle Fälle beschränkt! Im Normalfall sollte man auf absolute Adressen möglichst nicht zugreifen und den Compiler seine Arbeit machen lassen, der verwaltet die Variablen und deren Adressen meist besser als der Programmierer. Der Zugriff auf Variablen im EEPROM sollte immer über ihren Namen erfolgen.<br />
<br />
Verwendung:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/eeprom.h><br />
<br />
_EEPUT (0x20, 128); // Byte-Wert 128 an Adresse 0x20 schreiben<br />
...<br />
uint8_t val = _EEGET (0x20); // EEPROM-Wert von Adresse 0x20 lesen<br />
</syntaxhighlight><br />
<br />
=== Was steckt dahinter? - EEPROM-Register ===<br />
Auch wenn es normalerweise keinen Grund gibt, in C selbst an den Steuerregistern herumzuschrauben - die eeprom Funktionen erledigen das alles zuverlässig - der Vollständigkeit halber der registermässige technische Unterbau.<br />
Um das EEPROM anzusteuern, sind drei Register von Bedeutung:<br />
;EEAR: Hier werden die Adressen eingetragen zum Schreiben oder Lesen. Dieses Register unterteilt sich nochmal in EEARH und EEARL, da in einem 8-Bit-Register keine 512 Adressen adressiert werden können.<br />
;EEDR: Hier werden die Daten eingetragen, die geschrieben werden sollen, bzw. es enthält die gelesenen Daten.<br />
;EECR: Ist das Kontrollregister für das EEPROM<br />
<br />
Das EECR steuert den Zugriff auf das EEPROM und ist wie folgt aufgebaut:<br />
<br />
:{| class="wikitable" style="text-align:center"<br />
|+ '''Aufbau des EECR-Registers'''<br />
|-<br />
!Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|-<br />
! Name<br />
| - || - || - ||- || EERIE || EEMWE || EEWE || EERE<br />
|-<br />
! Read/Write<br />
| R || R || R || R || R/W || R/W || R/W || R/W<br />
|-<br />
!Init Value<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''Bedeutung der Bits'''<br />
<br />
;Bit 4-7: nicht belegt<br />
<br />
;Bit 3 (EERIE): ''EEPROM Ready Interrupt Enable'': Wenn das Bit gesetzt ist und globale Interrupts erlaubt sind in Register SREG (Bit 7), wird ein Interrupt ausgelöst nach Beendigung des Schreibzyklus (EEPROM Ready Interrupt). Ist einer der beiden Bits 0, wird kein Interrupt ausgelöst.<br />
<br />
;Bit 2 EEMWE): ''EEPROM Master Write Enable'': Dieses Bit bestimmt, dass, wenn EEWE = 1 gesetzt wird (innerhalb von 4 Taktzyklen), das EEPROM beschrieben wird mit den Daten in EEDR bei Adresse EEAR. Wenn EEMWE = 0 ist und EEWE = 1 gesetzt wird, hat das keine Auswirkungen. Der Schreibvorgang wird dann nicht ausgelöst. Nach 4 Taktzyklen wird das Bit EEMWE automatisch wieder auf 0 gesetzt. Dieses Bit löst den Schreibvorgang nicht aus, es dient sozusagen als Sicherungsbit für EEWE.<br />
<br />
;Bit 1 (EEWE): ''EEPROM Write Enable'': Dieses Bit löst den Schreibvorgang aus, wenn es auf 1 gesetzt wird, sofern vorher EEMWE gesetzt wurde und seitdem nicht mehr als 4 Taktzyklen vergangen sind. Wenn der Schreibvorgang abgeschlossen ist, wird dieses Bit automatisch wieder auf 0 gesetzt und, sofern EERIE gesetzt ist, ein Interrupt ausgelöst. Ein Schreibvorgang sieht typischerweise wie folgt aus:<br />
:# EEPROM-Bereitschaft abwarten (EEWE=0) <br />
:# Adresse übergeben an EEAR<br />
:# Daten übergeben an EEDR<br />
:# Schreibvorgang auslösen in EECR mit Bit EEMWE=1 und EEWE=1<br />
:# (Optional) Warten, bis Schreibvorgang abgeschlossen ist<br />
<br />
;Bit 0 EERE: ''EEPROM Read Enable'': Wird dieses Bit auf 1 gesetzt wird das EEPROM an der Adresse in EEAR ausgelesen und die Daten in EEDR gespeichert. Das EEPROM kann nicht ausgelesen werden, wenn bereits eine Schreiboperation gestartet wurde. Es ist daher zu empfehlen, die Bereitschaft vorher zu prüfen. Das EEPROM ist lesebereit, wenn das Bit EEWE=0 ist. Ist der Lesevorgang abgeschlossen, wird das Bit wieder auf 0 gesetzt, und das EEPROM ist für neue Lese- und Schreibbefehle wieder bereit. Ein typischer Lesevorgang kann wie folgt aufgebaut sein:<br />
:# Bereitschaft zum Lesen prüfen (EEWE=0)<br />
:# Adresse übergeben an EEAR<br />
:# Lesezyklus auslösen mit EERE = 1<br />
:# Warten, bis Lesevorgang abgeschlossen EERE = 0<br />
:# Daten abholen aus EEDR<br />
<br />
= Die Nutzung von sprintf und printf =<br />
<br />
Um komfortabel, d.h. formatiert, Ausgaben auf ein Display oder die serielle Schnittstelle zu tätigen, bieten sich '''sprintf''' oder '''printf''' an. Alle *printf-Varianten sind jedoch ziemlich speicherintensiv und der Einsatz in einem Mikrocontroller mit knappem Speicher muss sorgsam abgewogen werden.<br />
<br />
Bei '''sprintf''' wird die Ausgabe zunächst in einem Puffer vorbereitet und anschließend mit einfachen Funktionen zeichenweise ausgegeben. Es liegt in der Verantwortung des Programmierers, genügend Platz im Puffer für die erwarteten Zeichen bereitzuhalten.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdio.h><br />
#include <stdint.h><br />
<br />
// ...<br />
// nicht dargestellt: Implementierung von uart_puts (vgl. Abschnitt UART)<br />
// ...<br />
<br />
uint16_t counter;<br />
<br />
// Ausgabe eines unsigned Integerwertes<br />
void uart_puti( uint16_t value )<br />
{<br />
uint8_t puffer[20];<br />
<br />
sprintf( puffer, "Zählerstand: %u", value );<br />
uart_puts( puffer );<br />
}<br />
<br />
int main()<br />
{<br />
counter = 5;<br />
<br />
uart_puti( counter );<br />
uart_puti( 42 );<br />
}<br />
</syntaxhighlight><br />
<br />
Eine weitere elegante Möglichkeit besteht darin, den STREAM stdout (Standardausgabe) auf eine eigene Ausgabefunktion umzuleiten. Dazu wird dem Ausgabemechanismus der C-Bibliothek eine neue Ausgabefunktion bekannt gemacht, deren Aufgabe es ist, ein einzelnes Zeichen auszugeben. Wohin die Ausgabe dann tatsächlich stattfindet, ist Sache der Ausgabefunktion. Im Beispiel unten wird auf UART ausgegeben. Alle anderen, höheren Funktionen wie z.&nbsp;B. '''printf''', greifen letztendlich auf diese primitive Ausgabefunktion zurück. <br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdio.h><br />
<br />
void uart_init(void);<br />
<br />
// a. Deklaration der primitiven Ausgabefunktion<br />
int uart_putchar(char c, FILE *stream);<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 1)<br />
static FILE mystdout = FDEV_SETUP_STREAM( uart_putchar, NULL, _FDEV_SETUP_WRITE );<br />
<br />
// c. Definition der Ausgabefunktion<br />
int uart_putchar( char c, FILE *stream )<br />
{<br />
if( c == '\n' )<br />
uart_putchar( '\r', stream );<br />
<br />
loop_until_bit_is_set( UCSRA, UDRE );<br />
UDR = c;<br />
return 0;<br />
}<br />
<br />
void uart_init(void)<br />
{<br />
/* hier µC spezifischen Code zur Initialisierung */<br />
/* des UART einfügen... s.o. im AVR-GCC-Tutorial */<br />
<br />
// Beispiel: <br />
//<br />
// myAVR Board 1.5 mit externem Quarz Q1 3,6864 MHz<br />
// 9600 Baud 8N1<br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
// Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt)<br />
#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)<br />
<br />
UCSRB |= (1<<TXEN) | (1<<RXEN); // UART TX und RX einschalten<br />
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1 <br />
<br />
UBRRH = (uint8_t)( UART_UBRR_CALC( UART_BAUD_RATE, F_CPU ) >> 8 );<br />
UBRRL = (uint8_t)UART_UBRR_CALC( UART_BAUD_RATE, F_CPU );<br />
}<br />
<br />
int main(void)<br />
{<br />
int16_t antwort = 42;<br />
uart_init();<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 2)<br />
stdout = &mystdout;<br />
<br />
// Anwendung<br />
printf( "Die Antwort ist %d.\n", antwort );<br />
return 0;<br />
}<br />
<br />
// Quelle: avr-libc-user-manual-1.4.3.pdf, S.74<br />
// + Ergänzungen<br />
</syntaxhighlight><br />
<br />
<br />
Sollen Fließkommazahlen ausgegeben werden, muss im Makefile eine andere (größere) Version der [[FAQ#Aktivieren_der_Floating_Point_Version_von_sprintf_beim_WinAVR_mit_AVR-Studio|printflib]] eingebunden werden.<br />
<br />
= Anmerkungen =<br />
<references/><br />
<br />
= TODO =<br />
* Aktualisierung Register- und Bitbeschreibungen an aktuelle AVR<br />
* "naked"-Funktionen [http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html][http://arduino.stackexchange.com/questions/8758/arduino-interruption-on-pin-change]<br />
<br />
[[Kategorie:avr-gcc Tutorial| ]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR-GCC-Tutorial&diff=107261AVR-GCC-Tutorial2025-01-27T15:17:25Z<p>Heha: Neuer Abschnitt</p>
<hr />
<div>Dieses Tutorial soll den Einstieg in die Programmierung von Atmel [[AVR]]-Mikrocontrollern in der Programmiersprache [[C]] mit dem freien C-Compiler [[avr-gcc]] aus der [http://gcc.gnu.org/ GNU Compiler Collection] (GCC) erleichtern.<br />
<br />
Vorausgesetzt werden Grundkenntnisse der Programmiersprache C. Diese Kenntnisse kann man sich online erarbeiten, z. B. mit dem [http://www.schellong.de/c.htm C Tutorial von Helmut Schellong] ([[C|Liste von C-Tutorials]]). Nicht erforderlich sind Vorkenntnisse in der Programmierung von Mikrocontrollern.<br />
<br />
= Vorwort =<br />
<br />
In diesem Text wird häufig auf die Standardbibliothek avr-libc verwiesen, für die es eine [http://www.nongnu.org/avr-libc/user-manual/index.html Online-Dokumentation] gibt, in der sich auch viele nützliche Informationen zum Compiler und zur Programmierung von AVR-Controllern finden. Beim Paket [[WinAVR]] gehört die avr-libc Dokumentation zum Lieferumfang und wird mitinstalliert.<br />
<br />
Der Compiler und die Standardbibliothek avr-libc werden ständig weiterentwickelt. Einige Unterschiede, die sich im Verlauf der Entwicklung ergeben haben, werden hier und im Artikel [[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen]] zwar angesprochen, Anfängern und Umsteigern sei jedoch empfohlen, eine aktuelle Versionen zu nutzen.<br />
<br />
Das ursprüngliche Tutorial stammt von Christian Schifferle, viele neue Abschnitte und aktuelle Anpassungen von Martin Thomas.<br />
<br />
Dieses Tutorial ist in [[Media:AVR-GCC-Tutorial.pdf|PDF-Form]] erhältlich (zur Zeit nur eine sehr veraltete Version).<br />
<br />
== Weiterführende Kapitel ==<br />
<br />
Um dieses riesige Tutorial etwas überschaubarer zu gestalten, wurden einige Kapitel ausgelagert, die nicht unmittelbar mit den Grundlagen von avr-gcc in Verbindung stehen. All diese Seiten gehören zur [[:Kategorie:avr-gcc Tutorial]].<br />
<br />
;UART: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der UART|Der UART]]''<br />
<br />
;ADC: → Hauptartikel: ''[[AVR-GCC-Tutorial/Analoge Ein- und Ausgabe|Analoge Ein- und Ausgabe (ADC)]]''<br />
<br />
;Timer: → Hauptartikel: ''[[AVR-GCC-Tutorial/Die Timer und Zähler des AVR|Die Timer und Zähler des AVR]]''<br />
<br />
;LCD: → Hauptartikel: ''[[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Ansteuerung]]''<br />
<br />
;Watchdog: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der Watchdog|Der Watchdog]]''<br />
<br />
;Assembler: → Hauptartikel: ''[[AVR-GCC-Tutorial/Assembler und Inline-Assembler|Assembler und Inline-Assembler]]''<br />
<br />
;alte Quellen anpassen: → Hauptartikel: ''[[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen anpassen]]''<br />
<br />
;Makefiles: → Hauptartikel: ''[[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]]'' sowie als Alternative für sehr kleine Projekte → Hauptartikel: ''[[C ohne Makefile]]''<br />
<br />
= Benötigte Werkzeuge =<br />
<br />
Um eigene Programme für AVRs mittels einer AVR-Toolchain zu erstellen wird folgende Hard- und Software benötigt:<br />
<br />
* Eine AVR-Toolchain bestehend aus avr-gcc, den avr-Binutils (Assembler, Linker, etc) und einer Standard-C Bibliothek. Üblich ist die AVR-LibC, die auch quasi in allen avr-gcc Distributionen enthalten ist.<br />
<br />
Hardware wird keine benötigt – bis auf einen PC natürlich, auf dem der Compiler ablaufen kann. Selbst ohne AVR-Hardware kann man also bereits C-Programme für AVRs schreiben, compiliern und sich das Look-and-Feel von avr-gcc sowie von IDEs wie [[Atmel Studio]], Eclipse oder leichtgewichtigeren Entwicklungsumbgebungen anschauen. Selbst das Debuggen und Simulieren ist mithilfe entsprechender Tools wie Debugger und Simulator in gewissen Grenzen möglich.<br />
<br />
Um Programme für AVRs mittels einer AVR-Toolchain zu testen, wird folgende Hard- und Software benötigt:<br />
<br />
* Platine oder Versuchsaufbau für die Aufnahme eines AVR-Controllers, der vom avr-gcc Compiler unterstützt wird.<ref>Für eine Liste der unterstützten COntroller siehe die Dokumentation des Compilers oder [http://www.nongnu.org/avr-libc/user-manual/index.html#supported_devices AVR-Libc: Supported Devices].</ref> Dieses Testboard kann durchaus auch selbst gelötet oder auf einem Steckbrett aufgebaut werden. Einige Registerbeschreibungen dieses Tutorials beziehen sich auf den inzwischen veralteten AT90S2313. Der weitaus größte Teil des Textes ist aber für alle Controller der AVR-Familie gültig. <br />
<br />
:Brauchbare Testplattformen sind auch das [[STK500]] und der [[AVR Butterfly]] von Atmel. Weitere Infos findet man in den Artikeln [[AVR#Starterkits|AVR Starterkits]] und [[AVR-Tutorial: Equipment]].<br />
<br />
* Programmiersoftware und -[[AVR In System Programmer |hardware]] z. B. PonyProg (siehe auch: [[Pony-Prog Tutorial]]) oder [[AVRDUDE]] mit [[STK200]]-Dongle oder die von Atmel verfügbare Hard- und Software ([[STK500]], Atmel AVRISP, [[AVR-Studio]]).<br />
<br />
* Nicht unbedingt erforderlich, aber zur Simulation und zum Debuggen unter MS-Windows recht nützlich: [[AVR-Studio]].<br />
<br />
* Wer unter Windows und Linux gleichermassen entwickeln will, der sollte sich die [http://www.eclipse.org/ IDE Eclipse for C/C++ Developers] und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] ansehen. Beide sind unter Windows und Linux einfach zu installieren, siehe auch [[AVR Eclipse]]. Ebenfalls unter Linux und Windows verfügbar ist die Entwicklungsumgebung [http://www.codeblocks.org/ Code::Blocks]<ref>Aktuelle, stabile Versionen sind als Nightly Builds regelmäßig im [http://forums.codeblocks.org/ Forum] verfügbar.</ref>. Innerhalb dieser Entwicklungsumgebung können ohne die Installation zusätzlicher Plugins "AVR-Projekte" angelegt werden. Für Linux gibt es auch noch das [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=25220 KontrollerLab].<br />
<br />
= Was tun, wenn's nicht klappt? =<br />
<br />
* Herausfinden, ob es tatsächlich ein avr(-gcc) spezifisches Problem ist oder nur die eigenen C-Kenntnisse einer Auffrischung bedürfen. Allgemeine C-Fragen kann man eventuell "beim freundlichen Programmierer zwei Büro-, Zimmer- oder Haustüren weiter" loswerden. Ansonsten: [[C]]-Buch (gibt's auch "gratis" online) lesen.<br />
<br />
* Die [[AVR Checkliste]] durcharbeiten.<br />
<br />
* Die '''[http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc]''' lesen, vor allem (aber nicht nur) den Abschnitt Related Pages/'''Frequently Asked Questions''' = Oft gestellte Fragen (und Antworten dazu). Z.Zt leider nur in englischer Sprache verfügbar.<br />
<br />
* Den Artikel [[AVR-GCC]] in diesem Wiki lesen.<br />
<br />
* Das [http://www.mikrocontroller.net/forum/gcc GCC-Forum auf www.mikrocontroller.net] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das avr-gcc-Forum bei [http://www.avrfreaks.net AVRfreaks] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das [http://lists.gnu.org/archive/html/avr-gcc-list/ Archiv der avr-gcc Mailing-Liste] nach vergleichbaren Problemen absuchen.<br />
<br />
* Nach Beispielcode suchen. Vor allem im ''Projects''-Bereich von [http://www.avrfreaks.net AVRfreaks] (anmelden).<br />
<br />
* Google oder yahoo befragen schadet nie.<br />
<br />
* Bei Problemen mit der Ansteuerung interner AVR-Funktionen mit C-Code: das Datenblatt des Controllers lesen (ganz und am Besten zweimal). Datenblätter sind auf den [http://www.atmel.com Atmel Webseiten] als pdf-Dateien verfügbar. Das komplette Datenblatt (complete) und nicht die Kurzfassung (summary) verwenden.<br />
<br />
* Die Beispielprogramme im [[AVR-Tutorial]] sind zwar in AVR-Assembler verfasst, Erläuterungen und Vorgehensweisen sind aber auch auf C-Programme übertragbar.<br />
<br />
* Einen Beitrag in eines der Foren oder eine Mail an die Mailing-Liste schreiben. Dabei möglichst viel Information geben: Controller, Compilerversion, genutzte Bibliotheken, Ausschnitte aus dem Quellcode oder besser ein [http://www.mikrocontroller.net/topic/72767#598986 Testprojekt] mit allen notwendigen Dateien, um das Problem nachzuvollziehen, sowie genaue Fehlermeldungen bzw. Beschreibung des Fehlverhaltens. Bei Ansteuerung externer Geräte die Beschaltung beschreiben oder skizzieren (z. B. mit [http://www.tech-chat.de/ Andys ASCII Circuit]). Siehe dazu auch: '''[http://www.tty1.net/smart-questions_de.html "Wie man Fragen richtig stellt"]'''.<br />
<br />
= Erzeugen von Maschinencode =<br />
<br />
Aus dem C-Quellcode erzeugt der avr-gcc Compiler (zusammen mit Hilfsprogrammen wie z.&nbsp;B. Präprozessor, Assembler und Linker) Maschinencode für den AVR-Controller. Üblicherweise liegt dieser Code dann im Intel Hex-Format vor ("Hex-Datei"). Die Programmiersoftware (z.&nbsp;B. [[AVRDUDE]], PonyProg oder AVRStudio/STK500-plugin) liest diese Datei ein und überträgt die enthaltene Information (den Maschinencode) in den Speicher des Controllers. Im Prinzip sind also "nur" der avr-gcc-Compiler (und wenige Hilfsprogramme) mit den "richtigen" Optionen aufzurufen, um aus C-Code eine "Hex-Datei" zu erzeugen. Grundsätzlich stehen dazu drei verschiedene Ansätze zur Verfügung:<br />
<br />
* Die Verwendung einer integrierten Entwicklungsumgebung (IDE = '''I'''ntegrated '''D'''evelopment '''E'''nvironment), bei der alle Einstellungen z.&nbsp;B. in Dialogboxen durchgeführt werden können. Unter Anderem kann AVRStudio ab Version 4.12 (kostenlos auf [http://www.atmel.com/ atmel.com]) zusammen mit WinAVR als integrierte Entwicklungsumgebung für den Compiler avr-gcc genutzt werden (dazu müssen AVRStudio und WinAVR auf dem Rechner installiert sein). Weitere IDEs (ohne Anspruch auf Vollständigkeit): [http://www.eclipse.org/ Eclipse for C/C++ Developers] (d.h. inkl. CDT) und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] (für diverse Plattformen, u.a. Linux und MS Windows, IDE und Plugin kostenlos), [http://sourceforge.net/projects/kontrollerlab KontrollerLab] (Linux/KDE, kostenlos). [http://www.atmanecl.com/EnglishSite/SoftwareEnglish.htm AtmanAvr] (MS Windows, relativ günstig), KamAVR (MS-Windows, kostenlos, wird augenscheinlich nicht mehr weiterentwickelt), [http://www.amctools.com/vmlab.htm VMLab] (MS Windows, ab Version 3.12 ebenfalls kostenlos). Integrierte Entwicklungsumgebungen unterscheiden sich stark in Ihrer Bedienung und stehen auch nicht für alle Plattformen zur Verfügung, auf denen der Compiler ausführbar ist (z.&nbsp;B. AVRStudio nur für MS-Windows). Zur Anwendung des avr-gcc Compilers mit IDEs sei hier auf deren Dokumentation verwiesen. <br />
<br />
* Die Nutzung des Programms make mit passenden Makefiles. In den folgenden Abschnitten wird die Generierung von Maschinencode für einen AVR ("hex-Datei") aus C-Quellcode ("c-Dateien") anhand von "make" und den "Makefiles" näher erläutert. Viele der darin beschriebenen Optionen findet man auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio (AVRStudio generiert ein makefile in einem Unterverzeichnis des Projektverzeichnisses). <br />
<br />
* Das Generieren des Programms ohne IDE und ohne Makefile. In diesem Fall muss die Quellcodedatei durch eine vorgefertigte Kommandofolge an den Compiler übergeben werden. Der Artikel [[C ohne Makefile]] zeigt, wie das funktioniert. Diese Vorgehensweise empfiehlt sich jedoch nur für kleine Programme, die nicht auf verschiedene Quellcodedateien verteilt sind.<br />
<br />
Beim Wechsel vom makefile-Ansatz nach WinAVR-Vorlage zu AVRStudio ist darauf zu achten, dass AVRStudio (Stand: AVRStudio Version 4.13) bei einem neuen Projekt die Optimierungsoption (vgl. Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|AVR-GCC-Tutorial/Exkurs: Makefiles]], typisch: -Os) nicht einstellt und die mathematische Bibliothek der avr-libc (libm.a, Linker-Option -lm) nicht einbindet. (Hinweis: Bei Version 4.16 wird beides bereits gesetzt). Beides ist Standard bei Verwendung von makefiles nach WinAVR-Vorlage und sollte daher auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio "manuell" eingestellt werden, um auch mit AVRStudio kompakten Code zu erzeugen.<br />
<br />
= Einführungsbeispiel =<br />
<br />
Zum Einstieg ein kleines Beispiel, an dem die Nutzung des Compilers und der Hilfsprogramme (der sogenannten ''Toolchain'') demonstriert wird. Detaillierte Erläuterungen folgen in den weiteren Abschnitten dieses Tutorials.<br />
<br />
Das Programm soll auf einem AVR Mikrocontroller einige Ausgänge ein- und andere ausschalten. Das Beispiel ist für einen ATmega16 programmiert ([http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf Datenblatt]), kann aber sinngemäß für andere Controller der AVR-Familie modifiziert werden. <br />
<br />
Ein kurzes Wort zur Hardware: Bei diesem Programm werden alle Pins von PORTB auf Ausgang gesetzt, und einige davon werden auf HIGH andere auf LOW gesetzt. Das kann je nach angeschlossener Hardware an diesen Pins kritisch sein. Am ungefährlichsten ist es, wenn nichts an den Pins angeschlossen ist und man die Funktion des Programmes durch eine Spannungsmessung mit einem Multimeter kontrolliert. Die Spannung wird dabei zwischen GND-Pin und den einzelnen Pins von PORTB gemessen.<br />
<br />
Zunächst der Quellcode der Anwendung, der in einer Text-Datei mit dem Namen ''main.c'' abgespeichert wird.<br />
<br />
<syntaxhighlight lang="c"><br />
/* Alle Zeichen zwischen Schrägstrich-Stern <br />
und Stern-Schrägstrich sind Kommentare */<br />
<br />
// Zeilenkommentare sind ebenfalls möglich<br />
// alle auf die beiden Schrägstriche folgenden<br />
// Zeichen einer Zeile sind Kommentar<br />
<br />
#include <avr/io.h> // (1)<br />
<br />
int main (void) { // (2)<br />
<br />
DDRB = 0xFF; // (3)<br />
PORTB = 0x03; // (4)<br />
<br />
while(1) { // (5)<br />
/* "leere" Schleife*/ // (6)<br />
} // (7)<br />
<br />
/* wird nie erreicht */<br />
return 0; // (8)<br />
}<br />
</syntaxhighlight><br />
<br />
# In dieser Zeile wird eine sogenannte Header-Datei eingebunden. In <code>avr/io.h</code> sind die Registernamen definiert, die im späteren Verlauf genutzt werden. Auch unter Windows wird ein&nbsp;<code>/</code> zur Kennzeichnung von Unterverzeichnissen in Include-Dateinamen verwendet und kein&nbsp;<code>\</code>.<br />
# Hier beginnt das eigentliche Programm. Jedes C-Programm beginnt mit den Anweisungen in der Funktion <code>main</code>.<br />
# Die Anschlüsse eines AVR (Pins) werden zu Blöcken zusammengefasst, einen solchen Block bezeichnet man als Port. Beim ATmega16 hat jeder Port 8 Anschlüsse, bei kleineren AVRs können einem Port auch weniger als 8 Anschlüsse zugeordnet sein. Da per Definition (Datenblatt) alle gesetzten Bits in einem Datenrichtungsregister den entsprechenden Anschluss auf Ausgang schalten, werden mit DDRB=0xff alle Anschlüsse des Ports B als Ausgänge eingestellt.<br />
# Die den ersten beiden Bits des Ports zugeordneten Anschlüsse (PB0 und PB1) werden 1, alle anderen Anschlüsse des Ports B (PB2-PB7) zu 0. Aktivierte Ausgänge (logisch 1 oder "high") liegen auf Betriebsspannung (VCC, meist 5 Volt), nicht aktivierte Ausgänge führen 0 Volt (GND, Bezugspotential). Es ist sinnvoll, sich möglichst frühzeitig eine alternative Schreibweise beizubringen, die wegen der leichteren Überprüfbarkeit und Portierbarkeit oft im weiteren Tutorial und in Forenbeiträgen benutzt wird. Die Zuordnung sieht in diesem Fall so aus, Näheres dazu im Artikel [[Bitmanipulation]]:<syntaxhighlight lang="c">PORTB = (1<<PB1) | (1<<PB0);</syntaxhighlight><br />
# ist der Beginn der sogenannte ''Hauptschleife'' (main-loop). Dies ist eine Endlosschleife, welche kontinuierlich wiederkehrende Befehle enthält.<br />
# In diesem Beispiel ist die Hauptschleife leer. Der Controller durchläuft die Schleife immer wieder, ohne dass etwas passiert. Eine solche Schleife ist notwendig, da es auf dem Controller kein Betriebssystem gibt, das nach Beendigung des Programmes die Kontrolle übernehmen könnte. Ohne diese Schleife kehrt das Programm aus <code>main</code> zurück, alle Interrupts werden deaktiviert und eine Endlosschleife betreten.<br />
# Ende der Hauptschleife und Sprung zur passenden, öffnenden Klammer, also zu 5.<br />
# ist das Programmende. Die Zeile ist nur aus Gründen der C-Kompatibilität enthalten: <syntaxhighlight lang="c">int main(void)</syntaxhighlight> besagt, dass die Funktion einen int-Wert zurückgibt. Die Anweisung wird aber nicht erreicht, da das Programm die Hauptschleife nie verlässt.<br />
<br />
Um diesen Quellcode in ein lauffähiges Programm zu übersetzen, wird hier ein Makefile genutzt. Das verwendete Makefile findet sich auf der Seite [[Beispiel Makefile]] und basiert auf der Vorlage, die in WinAVR mitgeliefert wird und wurde bereits angepasst (Controllertyp ATmega16). Man kann das Makefile bearbeiten und an andere Controller anpassen oder sich mit dem Programm MFile menügesteuert ein Makefile "zusammenklicken". Das Makefile speichert man unter dem Namen <code>Makefile</code> (ohne Endung) im selben Verzeichnis, in dem auch die Datei <code>main.c</code> mit dem Programmcode abgelegt ist. Detailliertere Erklärungen zur Funktion von Makefiles finden sich im Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|Exkurs: Makefiles]].<br />
<br />
<pre><br />
D:\beispiel>dir<br />
<br />
Verzeichnis von D:\beispiel<br />
<br />
28.11.2006 22:53 <DIR> .<br />
28.11.2006 22:53 <DIR> ..<br />
28.11.2006 20:06 118 main.c<br />
28.11.2006 20:03 16.810 Makefile<br />
2 Datei(en) 16.928 Bytes<br />
</pre><br />
<br />
Nun gibt man ''make all'' ein. Falls das mit WinAVR installierte Programmers Notepad genutzt wird, gibt es dazu einen Menüpunkt im Tools Menü. Sind alle Einstellungen korrekt, entsteht eine Datei <code>main.hex</code>, in welcher der Code für den AVR enthalten ist. <br />
<pre><br />
D:\beispiel>make all<br />
<br />
-------- begin --------<br />
avr-gcc (GCC) 3.4.6<br />
Copyright (C) 2006 Free Software Foundation, Inc.<br />
This is free software; see the source for copying conditions. There is NO<br />
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.<br />
<br />
Compiling C: main.c<br />
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -f<br />
unsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef<br />
-Wa,-adhlns=obj/main.lst -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c -<br />
o obj/main.o<br />
<br />
Linking: main.elf<br />
avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -funs<br />
igned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -W<br />
a,-adhlns=obj/main.o -std=gnu99 -Wundef -MD -MP -MF .dep/main.elf.d obj/main.o<br />
--output main.elf -Wl,-Map=main.map,--cref -lm<br />
<br />
Creating load file for Flash: main.hex<br />
avr-objcopy -O ihex -R .eeprom main.elf main.hex<br />
</pre><br />
<br />
Der Inhalt der hex-Datei kann nun zum Controller übertragen werden. Dies kann z.&nbsp;B. über In-System-Programming ([[ISP]]) erfolgen, das im [[AVR-Tutorial: Equipment]] beschrieben ist. Makefiles nach der WinAVR/MFile-Vorlage sind für die Nutzung des Programms [[AVRDUDE]] vorbereitet. Wenn man den Typ und Anschluss des Programmiergerätes richtig eingestellt hat, kann mit ''make program'' die Übertragung mittels AVRDUDE gestartet werden. Jede andere Software, die hex-Dateien lesen und zu einem AVR übertragen kann<ref>z.&nbsp;B. [[Pony-Prog_Tutorial|Ponyprog]], yapp, AVRStudio</ref>, kann natürlich ebenfalls genutzt werden.<br />
<br />
Startet man nun den Controller (Reset-Taster oder Stromzufuhr aus/an), werden vom Programm die Anschlüsse PB0 und PB1 auf 1 gesetzt. Man kann mit einem Messgerät nun an diesem Anschluss die Betriebsspannung messen oder eine [[LED]] leuchten lassen (Anode an den Pin, Vorwiderstand nicht vergessen). An den Anschlüssen PB2-PB7 misst man 0 Volt. Eine mit der Anode mit einem dieser Anschlüsse verbundene LED leuchtet nicht.<br />
<br />
= Ganzzahlige Datentypen (Integer) =<br />
<br />
Bei der Programmierung von Mikrokontrollern ist die Definition einiger ganzzahliger Datentypen sinnvoll, an denen eindeutig die Bit-Länge abgelesen werden kann.<br />
<br />
Standardisierte Datentypen werden in der Header-Datei <code>stdint.h</code> definiert, die folgendermaßen eingebunden werden kann:<br />
<syntaxhighlight lang="c">#include <stdint.h></syntaxhighlight><br />
<br />
{| {{Tabelle}}<br />
|+ '''int-Typen aus <code>stdint.h</code> (C99)'''<br/>&nbsp;<br />
|- bgcolor="#d0d0ff"<br />
!colspan="5"| Vorzeichenbehaftete int-Typen<br />
|- bgcolor="#e8e8ff"<br />
! Typname || Bit-Breite ||colspan="2"| Wertebereich<br />
|align="center| '''C-Entsprechung''' (avr-gcc)<br />
|-<br />
|<code>int8_t</code> ||align="right"| 8 || −128 ⋯ 127 || −2<sup>7</sup> ⋯ 2<sup>7</sup>−1 || <code>signed char</code><br />
|-<br />
|<code>int16_t</code> ||align="right"| 16 || −32768 ⋯ 32767 || −2<sup>15</sup> ⋯ 2<sup>15</sup>−1 || <code>signed short</code>, <code>signed int</code><br />
|-<br />
|<code>int32_t</code> ||align="right"| 32 || −2147483648 ⋯ 2147483647 || −2<sup>31</sup> ⋯ 2<sup>31</sup>−1 || <code>signed long</code><br />
|-<br />
|<code>int64_t</code> ||align="right"| 64 || −9223372036854775808 ⋯ 9223372036854775807 || −2<sup>63</sup> ⋯ 2<sup>63</sup>−1 || <code>signed long long</code><br />
|- bgcolor="#d0d0ff"<br />
!colspan="5"| Vorzeichenlose int-Typen<br />
|- bgcolor="#e8e8ff"<br />
! Typname || Bit-Breite ||colspan="2"| Wertebereich<br />
|align="center| '''C-Entsprechung''' (avr-gcc)<br />
|-<br />
|<code>uint8_t</code> ||align="right"| 8 || 0 ⋯ 255 || 0 ⋯ 2<sup>8</sup>−1 || <code>unsigned char</code><br />
|-<br />
|<code>uint16_t</code> ||align="right"| 16 || 0 ⋯ 65535 || 0 ⋯ 2<sup>16</sup>−1 || <code>unsigned short</code>, <code>unsigned int</code><br />
|-<br />
|<code>uint32_t</code> ||align="right"| 32 || 0 ⋯ 4294967295 || 0 ⋯ 2<sup>32</sup>−1 || <code>unsigned long</code><br />
|-<br />
|<code>uint64_t</code> ||align="right"| 64 || 0 ⋯ 18446744073709551615 || 0 ⋯ 2<sup>64</sup>−1 || <code>unsigned long long</code><br />
|}<br />
<br />
Neben den Typen gibt es auch Makros für die Bereichsgrenzen wie <code>INT8_MIN</code> oder <code>UINT16_MAX</code>. Siehe dazu auch: [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html Dokumentation der avr-libc: Standard Integer Types].<br />
<br />
= Grundsätzlicher Programmaufbau eines µC-Programms =<br />
<br />
Wir unterscheiden zwischen 2 verschiedenen Methoden, um ein<br />
Mikrocontroller-Programm zu schreiben, und zwar völlig unabhängig davon, in<br />
welcher Programmiersprache das Programm geschrieben wird.<br />
<br />
== Sequentieller Programmablauf ==<br />
<br />
[[Image:Sequentielle Programme.gif|left]]<br />
Bei dieser Programmiertechnik wird eine Endlosschleife programmiert, welche im<br />
Wesentlichen immer den gleichen Aufbau hat. Es wird hier nach dem sogenannten EVA-Prinzip gehandelt. EVA steht für "Eingabe, Verarbeitung, Ausgabe".<br />
{{Absatz}}<br />
<br />
== Interruptgesteuerter Programmablauf ==<br />
<br />
[[Image:Interrupt Programme.gif|left]]<br />
Bei dieser Methode werden beim Programmstart zuerst die gewünschten Interruptquellen aktiviert und dann in eine Endlosschleife gegangen, in welcher Dinge erledigt werden können, welche nicht zeitkritisch sind. Wenn ein Interrupt ausgelöst wird, so wird automatisch die zugeordnete Interruptfunktion ausgeführt.<br />
{{Absatz}}<br />
<br />
= Zugriff auf Register =<br />
<br />
Die AVR-Controller verfügen über eine Vielzahl von Registern. Die meisten<br />
davon sind sogenannte Schreib-/Leseregister. Das heißt, das Programm kann die<br />
Inhalte der Register sowohl auslesen als auch beschreiben.<br />
<br />
Register haben einen besonderen Stellenwert bei den AVR Controllern. Sie dienen dem Zugriff auf die Ports und die Schnittstellen des Controllers. Wir unterscheiden zwischen 8-Bit und 16-Bit Registern. Vorerst behandeln wir die 8-Bit Register.<br />
<br />
Einzelne Register sind bei allen AVRs vorhanden, andere wiederum nur bei bestimmten Typen. So sind beispielsweise die Register, welche für den Zugriff auf den UART notwendig sind, selbstverständlich nur bei denjenigen Modellen vorhanden, welche über einen integrierten Hardware UART bzw. USART verfügen.<br />
<br />
Die Namen der Register sind in den Headerdateien zu den entsprechenden AVR-Typen definiert. Dazu muss man den Namen der controllerspezifischen Headerdatei nicht kennen. Es reicht aus, die allgemeine Headerdatei ''avr/io.h'' einzubinden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
</syntaxhighlight><br />
<br />
Ist im Makefile der MCU-Typ z.&nbsp;B. mit dem Inhalt atmega8 definiert (und wird somit per -mmcu=atmega8 an den Compiler übergeben), wird beim Einlesen der io.h-Datei implizit ("automatisch") auch die iom8.h-Datei mit den Register-Definitionen für den ATmega8 eingelesen.<br />
<br />
<!-- Wohl besser als Anhang - spaeter... --><br />
Intern wird diese "Automatik" wie folgt realisiert: Der Controllertyp wird dem Compiler als Parameter übergeben (vgl. ''avr-gcc -c -mmcu=atmega16 [...]'' im Einführungsbeispiel). Wird ein Makefile nach der WinAVR/mfile-Vorlage verwendet, setzt man die Variable ''MCU'', der Inhalt dieser Variable wird dann an passender Stelle für die Compilerparameter verwendet. Der Compiler definiert intern eine dem mmcu-Parameter zugeordnete "Variable" (genauer: ein Makro) mit dem Namen des Controllers, vorangestelltem ''__AVR_'' und angehängten Unterstrichen (z.&nbsp;B. wird bei ''-mmcu=atmega16'' das Makro ''__AVR_ATmega16__'' definiert). Beim Einbinden der Header-Datei ''avr/io.h'' wird geprüft, ob das jeweilige Makro definiert ist und die zum Controller passende Definitionsdatei eingelesen. Zur Veranschaulichung einige Ausschnitte aus einem Makefile:<br />
<br />
<pre><br />
[...]<br />
# MCU Type ("name") setzen:<br />
MCU = atmega16<br />
[...]<br />
<br />
[...]<br />
## Verwendung des Inhalts von MCU (hier atmega16) fuer die <br />
## Compiler- und Assembler-Parameter<br />
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)<br />
ALL_CPPFLAGS = -mmcu=$(MCU) -I. -x c++ $(CPPFLAGS) $(GENDEPFLAGS)<br />
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)<br />
[...]<br />
<br />
[...]<br />
## Aufruf des Compilers:<br />
## mit den Parametern ($(ALL_CFLAGS) ist -mmcu=$(MCU)[...] = -mmcu=atmega16[...]<br />
$(OBJDIR)/%.o : %.c<br />
@echo<br />
@echo $(MSG_COMPILING) $<<br />
$(CC) -c $(ALL_CFLAGS) $< -o $@ <br />
[...]<br />
</pre><br />
<br />
Da --mmcu=atmega16 übergeben wurde, wird __AVR_ATmega16__ definiert und kann in avr/io.h zur Fallunterscheidung genutzt werden:<br />
<br />
<syntaxhighlight lang="c"><br />
// avr/io.h <br />
// (bei WinAVR-Standardinstallation in C:\WinAVR\avr\include\avr)<br />
[...]<br />
#if defined (__AVR_AT94K__)<br />
# include <avr/ioat94k.h><br />
// [...]<br />
#elif defined (__AVR_ATmega16__)<br />
// da __AVR_ATmega16__ definiert ist, wird avr/iom16.h eingebunden:<br />
# include <avr/iom16.h><br />
// [...]<br />
#else<br />
# if !defined(__COMPILING_AVR_LIBC__)<br />
# warning "device type not defined"<br />
# endif<br />
#endif<br />
</syntaxhighlight><br />
<br />
Die Beispiele in den folgenden Abschnitten demonstrieren den Zugriff auf Register anhand der Register für I/O-Ports (PORTx, DDRx, PINx), die Vorgehensweise ist jedoch für alle Register (z.&nbsp;B. die des UART, ADC, SPI) analog.<br />
<br />
== Schreiben in Register ==<br />
<br />
Zum Schreiben kann man Register einfach wie eine Variable setzen.<ref>In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Schreibzugriff über die Funktion outp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt, outp() ist nicht mehr erforderlich.</ref><br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
/* Setzt das Richtungsregister des Ports A auf 0xff <br />
(alle Pins als Ausgang, vgl. Abschnitt Zugriff auf Ports): */<br />
DDRA = 0xff; <br />
<br />
/* Setzt PortA auf 0x03, Bit 0 und 1 "high", restliche "low": */<br />
PORTA = 0x03; <br />
<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binär 00011111 = Hexadezimal 1F<br />
DDRB = 0x1F; /* direkte Zuweisung - unübersichtlich */<br />
<br />
/* Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit<br />
aber übersichtlicher und selbsterklärend: */<br />
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);<br />
<br />
while (1);<br />
}<br />
</syntaxhighlight><br />
<br />
Die ausführliche Schreibweise sollte bevorzugt verwendet werden, da dadurch die Zuweisungen selbsterklärend sind und somit der Code leichter nachvollzogen werden kann. Atmel verwendet sie auch bei Beispielen in Datenblätten und in den allermeisten Quellcodes zu Application-Notes. Mehr zu der Schreibweise mit "|" und "<<" findet man unter [[Bitmanipulation]].<br />
<br />
Der gcc C-Compiler unterstützt ab Version 4.3.0 Konstanten im Binärformat, z.&nbsp;B. DDRB&nbsp;=&nbsp;0b00011111. Diese Schreibweise ist jedoch nur in GNU-C verfügbar und nicht in ISO-C definiert. Man sollte sie daher nicht verwenden, wenn Code mit anderen ausgetauscht oder mit anderen Compilern bzw. älteren Versionen des gcc genutzt werden soll.<br />
<br />
== Verändern von Registerinhalten ==<br />
<br />
Einzelne Bits setzt und löscht man "Standard-C-konform" mittels logischer (Bit-) Operationen. <br />
<br />
<syntaxhighlight lang="c"><br />
x |= (1 << Bitnummer); // Hiermit wird ein Bit in x gesetzt<br />
x &= ~(1 << Bitnummer); // Hiermit wird ein Bit in x geloescht<br />
</syntaxhighlight><br />
<br />
Es wird jeweils nur der Zustand des angegebenen Bits geändert, der vorherige Zustand der anderen Bits bleibt erhalten. <br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
#define MEINBIT 2<br />
...<br />
PORTA |= (1 << MEINBIT); /* setzt Bit 2 an PortA auf 1 */<br />
PORTA &= ~(1 << MEINBIT); /* loescht Bit 2 an PortA */<br />
</syntaxhighlight><br />
<br />
Mit dieser Methode lassen sich auch mehrere Bits eines Registers gleichzeitig setzen und löschen.<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
DDRA &= ~( (1<<PA0) | (1<<PA3) ); /* PA0 und PA3 als Eingaenge */<br />
PORTA |= ( (1<<PA0) | (1<<PA3) ); /* Interne Pull-Up fuer beide einschalten */<br />
</syntaxhighlight><br />
<br />
Bei bestimmten AVR Registern mit Bits, die durch Beschreiben mit einer logischen 1 gelöscht werden, muss eine absolute Zuweisung benutzt werden. Ein ODER löscht in diesen Registern ALLE gesetzten Bits!<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
TIFR2 = (1<<OCF2A); // Nur Bit OCF2A löschen<br />
</syntaxhighlight><br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind nicht mehr erforderlich.<br />
<br />
Siehe auch:<br />
* [[Bitmanipulation]]<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
<br />
== Lesen aus Registern ==<br />
<br />
Zum Lesen kann man auf Register einfach wie auf eine Variable zugreifen. In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Lesezugriff über die Funktion inp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt und inp() ist nicht mehr erforderlich.<br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdint.h><br />
<br />
uint8_t foo;<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
/* kopiert den Status der Eingabepins an PortB <br />
in die Variable foo: */<br />
foo = PINB; <br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Die Abfrage der Zustände von Bits erfolgt durch Einlesen des gesamten Registerinhalts und ausblenden der Bits deren Zustand nicht von Interesse ist. Einige Beispiele zum Prüfen ob Bits gesetzt oder gelöscht sind:<br />
<br />
<syntaxhighlight lang="c"><br />
#define MEINBIT0 0 <br />
#define MEINBIT2 2<br />
<br />
uint8_t i;<br />
<br />
extern test1();<br />
<br />
// Funkion test1 aufrufen, wenn Bit 0 in Register PINA gesetzt (1) ist<br />
i = PINA; // Inhalt in Arbeitsvariable<br />
i = i & 0x01; // alle Bits bis auf Bit 0 ausblenden (bitweise und)<br />
// falls das Bit gesetzt war, hat i den Inhalt 1<br />
if ( i != 0 ) { // Ergebnis ungleich 0 (wahr)? <br />
test1(); // dann muss Bit 0 in i gesetzt sein -> Funktion aufrufen<br />
}<br />
// verkürzt:<br />
if ( ( PINA & 0x01 ) != 0 ) {<br />
test1();<br />
}<br />
// nochmals verkürzt:<br />
if ( PINA & 0x01 ) {<br />
test1();<br />
}<br />
// mit definierter Bitnummer:<br />
if ( PINA & ( 1 << MEINBIT0 ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und/oder Bit 2 gesetzt ist. (Bit 0 und 2 also Wert 5) <br />
// (Bedenke: Bit 0 hat Wert 1, Bit 1 hat Wert 2 und Bit 2 hat Wert 4)<br />
if ( PINA & 0x05 ) {<br />
test1(); // Vergleich <> 0 (wahr), also mindestens eines der Bits gesetzt<br />
}<br />
// mit definierten Bitnummern:<br />
if ( PINA & ( ( 1 << MEINBIT0 ) | ( 1 << MEINBIT2 ) ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und Bit 2 gesetzt sind<br />
if ( ( PINA & 0x05 ) == 0x05 ) { // nur wahr, wenn beide Bits gesetzt<br />
test1();<br />
}<br />
<br />
// Funktion test2() aufrufen, wenn Bit 0 gelöscht (0) ist<br />
i = PINA; // einlesen in temporäre Variable<br />
i = i & 0x01; // maskieren von Bit 0<br />
if ( i == 0 ) { // Vergleich ist wahr, wenn Bit 0 nicht gesetzt ist<br />
test2();<br />
}<br />
// analog mit not-Operator<br />
if ( !i ) {<br />
test2();<br />
}<br />
// nochmals verkürzt:<br />
if ( !( PINA & 0x01 ) ) {<br />
test2();<br />
}<br />
</syntaxhighlight><br />
<br />
== Warten auf einen bestimmten Zustand ==<br />
<br />
Es gibt in der Bibliothek avr-libc Funktionen, die warten, bis ein bestimmter Zustand eines Bits erreicht ist. Es ist allerdings normalerweise eine eher unschöne Programmiertechnik, da in diesen Funktionen "blockierend" gewartet wird. Der Programmablauf bleibt also an dieser Stelle stehen, bis das maskierte Ereignis erfolgt ist. Setzt man den [[Watchdog]] ein, muss man darauf achten, dass dieser auch noch getriggert wird (Zurücksetzen des Watchdogtimers). <br />
<br />
Die Funktion '''loop_until_bit_is_set''' wartet in einer Schleife, bis das definierte Bit gesetzt ist. Wenn das Bit beim Aufruf der Funktion bereits gesetzt ist, wird die Funktion sofort wieder verlassen. Das niederwertigste Bit hat die Bitnummer 0. <br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 2 (das dritte Bit) in Register PINA gesetzt (1) ist */<br />
<br />
#define WARTEPIN PINA<br />
#define WARTEBIT PA2<br />
<br />
// mit der avr-libc Funktion:<br />
loop_until_bit_is_set(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// _nicht_ ungleich 0 (also 0) ist.<br />
while ( !(WARTEPIN & (1 << WARTEBIT)) ) {}<br />
...<br />
</syntaxhighlight><br />
<br />
<br />
Die Funktion '''loop_until_bit_is_clear''' wartet in einer Schleife, bis das definierte Bit gelöscht ist. Wenn das Bit beim Aufruf der Funktion bereits gelöscht ist, wird die Funktion sofort wieder verlassen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 4 (das fuenfte Bit) in Register PINB geloescht (0) ist */<br />
#define WARTEPIN PINB<br />
#define WARTEBIT PB4<br />
<br />
// avr-libc-Funktion:<br />
loop_until_bit_is_clear(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// gesetzt (1) ist <br />
while ( WARTEPIN & (1<<WARTEBIT) ) {}<br />
...<br />
</syntaxhighlight><br />
<br />
Universeller und auch auf andere Plattformen besser übertragbar ist die Verwendung von C-Standardoperationen.<br />
<br />
Siehe auch: <br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
* [[Bitmanipulation]]<br />
<br />
== 16-Bit Register (ADC, ICR1, OCR1x, TCNT1, UBRR) ==<br />
<br />
Einige der Portregister in den AVR-Controllern sind 16 Bit breit. Im Datenblatt sind diese Register üblicherweise mit dem Suffix "L" (Low-Byte) und "H" (High-Byte) versehen. Die avr-libc definiert zusätzlich die meisten dieser Variablen die Bezeichnung ohne "L" oder "H". Auf diese Register kann dann direkt zugegriffen werden. Dies ist zum Beispiel der Fall für Register wie ADC oder TCNT1.<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
uint16_t foo;<br />
<br />
/* setzt die Wort-Variable foo auf den Wert der letzten AD-Wandlung */<br />
foo = ADC; <br />
</syntaxhighlight><br />
<br />
Bei anderen Registern, wie zum Beispiel Baudraten-Register, liegen High- und Low-Teil nicht direkt nebeneinander im SFR-Bereich, so dass ein 16-Bit Zugriff nicht möglich ist und der Zugriff zusammengebastelt werden muss:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
...<br />
uint16_t baud = F_CPU / (UART_BAUD_RATE * 16L) -1;<br />
<br />
UBRRH = (uint8_t) (baud >> 8);<br />
UBRRL = (uint8_t) baud;<br />
...<br />
</syntaxhighlight><br />
<br />
Bei einigen AVR-Typen wie ATmega8 oder ATmega16 teilen sich UBRRH und UCSRC die gleiche Speicher-Adresse. Damit der AVR trotzdem zwischen den beiden Registern unterscheiden kann, bestimmt das Bit7 (URSEL), welches Register tatsächlich beschrieben werden soll. ''1000 0011'' (0x83) adressiert demnach UCSRC und übergibt den Wert ''3''. Und ''0000 0011'' (0x3) adressiert UBRRH und übergibt ebenfalls den Wert ''3''. <br />
<br />
Speziell bei den 16-Bit-Timern und auch beim ADC ist es bei allen Zugriffen auf Datenregister erforderlich, dass diese Daten synchronisiert sind. Wenn z.&nbsp;B. bei einem 16-Bit-Timer das High-Byte des Zählregisters gelesen wurde und vor dem Lesezugriff auf das Low-Byte ein Überlauf des Low-Bytes stattfindet, erhält man einen völlig unsinnigen Wert. Auch die Compare-Register müssen synchron geschrieben werden, da es ansonsten zu unerwünschten Compare-Ereignissen kommen kann. <br />
<br />
Beim ADC besteht das Problem darin, dass zwischen den Zugriffen auf die beiden Teilregister eine Wandlung beendet werden kann und der ADC ein neues Ergebnis in ADCL und ADCH schreiben will, wodurch High- und Low-Byte nicht zusammenpassen.<br />
<br />
Um diese Datenmüllproduktion zu verhindern, gibt es in beiden Fällen eine Synchronisation, die jeweils durch den Zugriff auf das Low-Byte ausgelöst wird:<br />
* Bei den Timer-Registern (das gilt für alle TCNT-, OCR- und ICR-Register bei den 16-Bit-Timern) wird bei einem ''Lesezugriff'' auf das Low-Byte automatisch das High-Byte in ein temporäres Register, das ansonsten nach außen nicht sichtbar ist, geschoben. Greift man nun ''anschließend'' auf das High-Byte zu, dann wird eben dieses temporäre Register gelesen.<br />
* Bei einem ''Schreibzugriff'' auf eines der genannten Register wird das High-Byte in besagtem temporären Register zwischengespeichert und erst beim Schreiben des Low-Bytes werden ''beide'' gleichzeitig in das eigentliche Register übernommen.<br />
<br />
Das bedeutet für die Reihenfolge:<br />
* Lesezugriff: Erst Low-Byte, dann High-Byte<br />
* Schreibzugriff: Erst High-Byte, dann Low-Byte<br />
<br />
Des weiteren ist zu beachten, dass es für all diese 16-Bit-Register nur ein einziges temporäres Register gibt, so dass das Auftreten eines Interrupts, in dessen Handler ein solches Register manipuliert wird, bei einem durch ihn unterbrochenen Zugriff i.d.R. zu Datenmüll führt. 16-Bit-Zugriffe sind generell nicht atomar! Wenn mit Interrupts gearbeitet wird, kann es erforderlich sein, vor einem solchen Zugriff auf ein 16-Bit-Register die Interrupt-Bearbeitung zu deaktivieren.<br />
<br />
Beim ADC-Datenregister ADCH/ADCL ist die Synchronisierung anders gelöst. Hier wird beim Lesezugriff (ADCH/ADCL sind logischerweise read-only) auf das Low-Byte ADCL beide Teilregister für Zugriffe seitens des ADC so lange gesperrt, bis das High-Byte ADCH ausgelesen wurde. Dadurch kann der ADC nach einem Zugriff auf ADCL keinen neuen Wert in ADCH/ADCL ablegen, bis ADCH gelesen wurde. Ergebnisse von Wandlungen, die zwischen einem Zugriff auf ADCL und ADCH beendet werden, gehen verloren!<br />
<br />
Nach einem Zugriff auf ADCL muss grundsätzlich ADCH gelesen werden!<br />
<br />
In beiden Fällen – also sowohl bei den Timern als auch beim ADC – werden vom C-Compiler 16-Bit Pseudo-Register zur Verfügung gestellt (z.&nbsp;B. TCNT1H/TCNT1L → TCNT1, ADCH/ADCL → ADC bzw. ADCW), bei deren Verwendung der Compiler automatisch die richtige Zugriffsreihenfolge regelt. In C-Programmen sollten grundsätzlich diese 16-Bit-Register verwendet werden! Sollte trotzdem ein Zugriff auf ein Teilregister erforderlich sein, sind obige Angaben zu berücksichtigen.<br />
<br />
Es ist darauf zu achten, dass auch ein Zugriff auf die 16-Bit-Register vom Compiler in zwei 8-Bit-Zugriffe aufgeteilt wird und dementsprechend genauso nicht-atomar ist wie die Einzelzugriffe. Auch hier gilt, dass u.U. die Interrupt-Bearbeitung gesperrt werden muss, um Datenmüll zu vermeiden.<br />
<br />
Beim ADC gibt es für den Fall, dass eine Auflösung von 8 Bit ausreicht, die Möglichkeit, das Ergebnis "linksbündig" in ADCH/ADCL auszurichten, so dass die relevanten 8 MSB in ADCH stehen. In diesem Fall muss bzw. sollte nur ADCH ausgelesen werden.<br />
<br />
ADC und ADCW sind unterschiedliche Bezeichner für das selbe Registerpaar. Üblicherweise kann man in C-Programmen ADC verwenden, was analog zu den anderen 16-Bit-Registern benannt ist. ADCW (ADC Word) existiert nur deshalb, weil die Headerdateien auch für Assembler vorgesehen sind und es bereits einen Assembler-Befehl namens ''adc'' gibt. <br />
<br />
Im Umgang mit 16-Bit Registern siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Related Pages/Frequently Asked Questions/Nr. 8<br />
* Datenblatt Abschnitt ''Accessing 16-bit Registers''<br />
<br />
== IO-Register als Parameter und Variablen ==<br />
<br />
Um Register als Parameter für eigene Funktionen übergeben zu können, muss man sie als einen volatile uint8_t Pointer übergeben. Zum Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <util/delay.h><br />
<br />
uint8_t key_pressed (volatile uint8_t *inputreg, uint8_t inputbit)<br />
{<br />
static uint8_t last_state = 0;<br />
<br />
if (last_state == (*inputreg & (1<<inputbit)))<br />
return 0; /* keine Änderung */<br />
<br />
/* Wenn doch, warten bis etwaiges Prellen vorbei ist: */<br />
_delay_ms(20);<br />
<br />
/* Zustand für nächsten Aufruf merken: */<br />
last_state = *inputreg & (1<<inputbit);<br />
<br />
/* und den entprellten Tastendruck zurückgeben: */<br />
return *inputreg & (1<<inputbit);<br />
}<br />
<br />
/* Beispiel für einen Funktionsaufruf: */<br />
<br />
void foo (void)<br />
{<br />
uint8_t i = key_pressed (&PINB, PB1);<br />
}<br />
</syntaxhighlight><br />
<br />
Ein Aufruf der Funktion mit call by value würde Folgendes bewirken: Beim Funktionseintritt wird nur eine Kopie des momentanen Portzustandes angefertigt, die sich unabhängig vom tatsächlichen Zustand das Ports nicht mehr ändert, womit die Funktion wirkungslos wäre. Die Übergabe eines Zeigers wäre die Lösung, wenn der Compiler nicht optimieren würde. Denn dadurch wird im Programm nicht von der Hardware gelesen, sondern wieder nur von einem Abbild im Speicher. Das Ergebnis wäre das gleiche wie oben. Mit dem Schlüsselwort volatile sagt man nun dem Compiler, dass die entsprechende Variable entweder durch andere Softwareroutinen (Interrupts) oder durch die Hardware verändert werden kann.<br />
<br />
Siehe auch: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass avr-libc FAQ: "How do I pass an IO port as a parameter to a function?"]<br />
<br />
= Zugriff auf IO-Ports =<br />
<br />
Jeder AVR implementiert eine unterschiedliche Menge an GPIO-Registern<br />
(GPIO - General Purpose Input/Output). Diese Register dienen dazu:<br />
* einzustellen welche der Anschlüsse ("Beinchen") des Controllers als Ein- oder Ausgänge dienen<br />
* bei Ausgängen deren Zustand festzulegen<br />
* bei Eingängen deren Zustand zu erfassen<br />
<br />
Mittels GPIO werden digitale Zustände gesetzt und erfasst, d.h. die Spannung an einem Ausgang wird ein- oder ausgeschaltet und an einem Eingang wird erfasst, ob die anliegende Spannung über oder unter einem bestimmten Schwellwert liegt. Im Datenblatt Abschnitt Electrical Characteristics/DC Characteristics finden sich die Spannungswerte (V_OL, V_OH für Ausgänge, V_IL, V_IH für Eingänge).<br />
<br />
Die Verarbeitung von analogen Eingangswerten und die Ausgabe von Analogwerten wird in Kapitel [[AVR-GCC-Tutorial#Analoge_Ein-_und_Ausgabe|Analoge Ein- und Ausgabe]] behandelt.<br />
<br />
Die physischen Ein- und Ausgänge werden bei AVR-Controllern zu logischen Ports gruppiert.<br />
<br />
Alle Ports werden über Register gesteuert. Dazu sind jedem Port 3 Register zugeordnet:<br />
<br />
{| class="wikitable"<br />
|- <br />
! width="10%"| DDRx<br />
| Datenrichtungsregister für Port'''x'''. <br />
'''x''' entspricht '''A''', '''B''', ''' C''' usw. je nach gewünschtem Port. Bit im Register gesetzt (1) für Ausgang, Bit gelöscht (0) für Eingang.<br />
|- <br />
! PINx<br />
| Eingangsadresse für Port'''x'''. <br />
Zustand des Ports. Die Bits in PINx entsprechen dem Zustand der als Eingang definierten Portpins. Bit 1 wenn Pin "high", Bit 0 wenn Portpin low.<br />
|-<br />
! PORTx<br />
| Datenregister für Port'''x'''. <br />
Dieses Register wird verwendet, um die Ausgänge eines Ports anzusteuern. Bei Pins, die mittels DDRx auf Eingang geschaltet wurden, können über PORTx<br />
die internen Pull-Up Widerstände aktiviert oder deaktiviert werden (1 = aktiv).<br />
|}<br />
<br />
Die folgenden Beispiele gehen von einem AVR aus, der sowohl Port A als auch Port B besitzt. Sie müssen für andere AVRs (zum Beispiel ATmega8/48/88/168) entsprechend angepasst werden.<br />
<br />
== Datenrichtung bestimmen ==<br />
<br />
Zuerst muss die Datenrichtung der verwendeten Pins bestimmt werden. Um dies zu erreichen, wird das Datenrichtungsregister des entsprechenden Ports beschrieben.<br />
<br />
Für jeden Pin, der als Ausgang verwendet werden soll, muss dabei das<br />
entsprechende Bit auf dem Port gesetzt werden. Soll der Pin als Eingang<br />
verwendet werden, muss das entsprechende Bit gelöscht sein.<br />
<br />
Beispiel:<br />
Angenommen am Port B sollen die Pins 0 bis 4 als Ausgänge definiert werden, die noch verbleibenden Pins 5 bis 7 sollen als Eingänge fungieren. Dazu ist es daher notwendig, im für das Port B zuständigen Datenrichtungsregister DDRB folgende Bitkonfiguration einzutragen<br />
<br />
+---+---+---+---+---+---+---+---+<br />
| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |<br />
+---+---+---+---+---+---+---+---+<br />
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br />
<br />
In C liest sich das dann so:<br />
<br />
<syntaxhighlight lang="c"><br />
// in io.h wird u.a. DDRB definiert:<br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binaer 00011111 = Hexadezimal 1F<br />
// direkte Zuweisung - standardkonform */<br />
DDRB = 0x1F; /* <br />
<br />
// Uebersichtliche Alternative - Binaerschreibweise, aber kein ISO-C<br />
DDRB = 0b00011111;<br />
<br />
// Ausfuehrliche Schreibweise: identische Funktionalitaet, mehr Tipparbeit<br />
// aber uebersichtlicher und selbsterklaerend:<br />
DDRB |= (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4); <br />
</syntaxhighlight><br />
<br />
Die Pins 5 bis 7 werden (da 0) als Eingänge geschaltet. Weitere Beispiele:<br />
<br />
<syntaxhighlight lang="c"><br />
// Alle Pins des Ports B als Ausgang definieren:<br />
DDRB = 0xff; <br />
// Pin0 wieder auf Eingang und andere im urspruenglichen Zustand belassen:<br />
DDRB &= ~(1 << DDB0);<br />
// Pin 3 und 4 auf Eingang und andere im urspruenglichen Zustand belassen:<br />
DDRB &= ~((1 << DDB3) | (1 << DDB4));<br />
// Pin 0 und 3 wieder auf Ausgang und andere im ursprünglichen Zustand belassen:<br />
DDRB |= (1 << DDB0) | (1 << DDB3);<br />
// Alle Pins auf Eingang:<br />
DDRB = 0x00;<br />
</syntaxhighlight><br />
<br />
== Vordefinierte Bitnummern für I/O-Register ==<br />
<br />
Die Bitnummern (z.&nbsp;B. PCx, PINCx und DDCx für den Port C) sind in den io*.h-Dateien der avr-libc definiert und dienen lediglich der besseren Lesbarkeit. Man muss diese Definitionen nicht verwenden oder kann auch einfach "immer" PAx, PBx, PCx usw. nutzen, auch wenn der Zugriff auf Bits in DDRx- oder PINx-Registern erfolgt. Für den Compiler sind die Ausdrücke (1<<PC7), (1<<DDC7) und (1<<PINC7) identisch zu (1<<7) (genauer: der Präprozessor ersetzt die Ausdrücke (1<<PC7),... zu (1<<7)). Ein Ausschnitt der Definitionen für Port C eines ATmega32 aus der iom32.h-Datei zur Verdeutlichung (analog für die weiteren Ports):<br />
<br />
<syntaxhighlight lang="c"><br />
...<br />
/* PORTC */<br />
#define PC7 7<br />
#define PC6 6<br />
#define PC5 5<br />
#define PC4 4<br />
#define PC3 3<br />
#define PC2 2<br />
#define PC1 1<br />
#define PC0 0<br />
<br />
/* DDRC */<br />
#define DDC7 7<br />
#define DDC6 6<br />
#define DDC5 5<br />
#define DDC4 4<br />
#define DDC3 3<br />
#define DDC2 2<br />
#define DDC1 1<br />
#define DDC0 0<br />
<br />
/* PINC */<br />
#define PINC7 7<br />
#define PINC6 6<br />
#define PINC5 5<br />
#define PINC4 4<br />
#define PINC3 3<br />
#define PINC2 2<br />
#define PINC1 1<br />
#define PINC0 0<br />
</syntaxhighlight><br />
<br />
<br />
== Digitale Signale ==<br />
<br />
Am einfachsten ist es, digitale Signale mit dem Mikrocontroller zu erfassen bzw. auszugeben.<br />
<br />
== Ausgänge ==<br />
Will man als Ausgang definierte Pins (entsprechende DDRx-Bits = 1) auf Logisch 1 setzen, setzt man die entsprechenden Bits im Portregister.<br />
<br />
Mit dem Befehl<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB = 0x04; /* besser PORTB=(1<<PB2) */<br />
<br />
// Uebersichtliche Alternative - Binaerschreibweise<br />
PORTB = 0b00000100; /* direkte Zuweisung - uebersichtlich */<br />
<br />
</syntaxhighlight><br />
wird also der Ausgang an Pin PB2 gesetzt (Beachte, dass die Bits immer ''von 0 an'' gezählt werden, das niederwertigste Bit ist also Bitnummer 0 und nicht etwa Bitnummer 1).<br />
<br />
Man beachte, dass bei der Zuweisung mittels '''=''' immer alle Pins gleichzeitig angegeben werden. Man sollte also, wenn nur bestimmte Ausgänge geschaltet werden sollen, zuerst den aktuellen Wert des Ports einlesen und das Bit des gewünschten Ports in diesen Wert einfließen lassen. Will man also nur den dritten Pin (Bit Nr. 2) an Port B auf "high" setzen und den Status der anderen Ausgänge unverändert lassen, nutze man diese Form:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB = PORTB | 0x04; /* besser: PORTB = PORTB | ( 1<<PB2 ) */<br />
/* vereinfacht durch Nutzung des |= Operators : */<br />
PORTB |= (1<<PB2);<br />
<br />
/* auch mehrere "gleichzeitig": */<br />
PORTB |= (1<<PB4) | (1<<PB5); /* Pins PB4 und PB5 "high" */<br />
</syntaxhighlight><br />
<br />
"Ausschalten", also Ausgänge auf "low" setzen, erfolgt analog:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB &= ~(1<<PB2); /* loescht Bit 2 in PORTB und setzt damit Pin PB2 auf low */ <br />
PORTB &= ~( (1<<PB4) | (1<<PB5) ); /* Pin PB4 und Pin PB5 "low" */<br />
</syntaxhighlight><br />
Siehe auch [[Bitmanipulation]]<br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind in aktuellen Versionen der avr-libc nicht mehr enthalten und auch nicht mehr erforderlich.<br />
<br />
''Falls der Anfangszustand von Ausgängen kritisch ist, muss die Reihenfolge beachtet werden, mit der die Datenrichtung (DDRx) eingestellt und der Ausgabewert (PORTx) gesetzt wird:''<br />
<br />
Für Ausgangspins, die mit Anfangswert "high" initialisiert werden sollen:<br />
* zuerst die Bits im PORTx-Register setzen<br />
* anschließend die Datenrichtung auf Ausgang stellen<br />
<br />
Daraus ergibt sich die Abfolge für einen Pin, der bisher als Eingang mit abgeschaltetem Pull-Up konfiguriert war:<br />
* setze PORTx: interner Pull-Up aktiv<br />
* setze DDRx: Ausgang ("high")<br />
<br />
Bei der Reihenfolge erst DDRx und dann PORTx kann es zu einem kurzen "low-Puls" kommen, der auch externe Pull-Up-Widerstände "überstimmt". Die (ungünstige) Abfolge: Eingang -> setze DDRx: Ausgang (auf "low", da PORTx nach Reset 0) -> setze PORTx: Ausgang auf high. Vergleiche dazu auch das Datenblatt Abschnitt ''Configuring the Pin''.<br />
<br />
== Eingänge (Wie kommen Signale in den &micro;C) ==<br />
<br />
Die digitalen Eingangssignale können auf verschiedene Arten zu unserer Logik gelangen.<br />
<br />
=== Signalkopplung ===<br />
<br />
Am einfachsten ist es, wenn die Signale direkt aus einer anderen digitalen Schaltung übernommen werden können. Hat der Ausgang der entsprechenden Schaltung TTL-Pegel dann können wir sogar direkt den Ausgang der Schaltung mit einem Eingangspin von unserem Controller verbinden.<br />
<br />
Hat der Ausgang der anderen Schaltung keinen TTL-Pegel so müssen wir den Pegel über entsprechende Hardware (z.&nbsp;B. Optokoppler, [[Widerstand#Spannungsteiler|Spannungsteiler]], "Levelshifter" aka [[Pegelwandler]]) anpassen.<br />
<br />
Die Masse der beiden Schaltungen muss selbstverständlich miteinander verbunden werden. Der Software selber ist es natürlich letztendlich egal, wie das Signal eingespeist wird. Wir können ja ohnehin lediglich prüfen, ob an einem Pin unseres Controllers eine logische 1 (Spannung größer ca. 0,7*Vcc) oder eine logische 0 (Spannung kleiner ca. 0,2*Vcc) anliegt. Detaillierte Informationen darüber, ab welcher Spannung ein Eingang als 0 ("low") bzw. 1 ("high") erkannt wird, liefert die Tabelle DC Characteristics im Datenblatt des genutzten Controllers.<br />
<br />
{| class="wikitable" style="text-align:center; width:20em"<br />
|+ '''Logikpegel'''<br />
|-<br />
! VCC [V]<br />
! Low [V]<br />
! High [V]<br />
|-<br />
! 5<br />
| 1,0 || 3,5<br />
|-<br />
! 3,3<br />
| 0,66 || 2,3<br />
|-<br />
! 1,8<br />
| 0,36 || 1,26 <br />
|}<br />
<br />
Die Abfrage der Zustände der Portpins erfolgt direkt über den Registernamen.<br />
<br />
{{Warnung|Dabei ist wichtig, zur Abfrage der Eingänge ''nicht'' etwa Portregister '''PORTx''' zu verwenden, sondern Eingangsregister '''PINx'''. Ansonsten liest man nicht den Zustand der Eingänge, sondern den Status der internen Pull-Up-Widerstände. Die Abfrage der Pinzustände über PORTx statt PINx ist ein häufiger Fehler beim AVR-"Erstkontakt".}}<br />
<br />
Will man also die aktuellen Signalzustände von Port D abfragen und in eine Variable namens bPortD abspeichern, schreibt man folgende Befehlszeilen:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdint.h><br />
...<br />
uint8_t bPortD;<br />
...<br />
bPortD = PIND;<br />
...<br />
</syntaxhighlight><br />
<br />
Mit den C-Bitoperationen kann man den Status der Bits abfragen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
/* Fuehre Aktion aus, wenn Bit Nr. 1 (das "zweite" Bit) in PINC gesetzt (1) ist */<br />
if ( PINC & (1<<PINC1) ) {<br />
/* Aktion */<br />
}<br />
<br />
/* Fuehre Aktion aus, wenn Bit Nr. 2 (das "dritte" Bit) in PINB geloescht (0) ist */<br />
if ( !(PINB & (1<<PINB2)) ) {<br />
/* Aktion */<br />
}<br />
...<br />
</syntaxhighlight><br />
Siehe auch [[Bitmanipulation#Bits_prüfen]]<br />
<br />
=== Interne Pull-Up Widerstände ===<br />
<br />
Portpins für Ein- und Ausgänge (GPIO) eines AVR verfügen über zuschaltbare interne Pull-Up Widerstände (nominal mehrere 10kOhm, z.&nbsp;B. ATmega16 20-50kOhm). Diese können in vielen Fällen statt externer Widerstände genutzt werden.<br />
<br />
Die internen Pull-Up Widerstände von Vcc zu den einzelnen Portpins werden über das Register ''' PORTx''' aktiviert bzw. deaktiviert, wenn ein Pin als ''' Eingang''' geschaltet ist.<br />
<br />
Wird der Wert des entsprechenden Portpins auf 1 gesetzt, so ist der Pull-Up Widerstand aktiviert. Bei einem Wert von 0 ist der Pull-Up Widerstand nicht aktiv. Man sollte jeweils entweder den internen oder einen externen Pull-Up Widerstand verwenden, aber nicht beide zusammen.<br />
<br />
Im Beispiel werden alle Pins des Ports D als Eingänge geschaltet und alle Pull-Up Widerstände aktiviert. Weiterhin wird Pin PC7 als Eingang geschaltet und dessen interner Pull-Up Widerstand aktiviert, ohne die Einstellungen für die anderen Portpins (PC0-PC6) zu verändern.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
DDRD = 0x00; /* alle Pins von Port D als Eingang */<br />
PORTD = 0xff; /* interne Pull-Ups an allen Port-Pins aktivieren */<br />
...<br />
DDRC &= ~(1<<PC7); /* Pin PC7 als Eingang */<br />
PORTC |= (1<<PC7); /* internen Pull-Up an PC7 aktivieren */<br />
</syntaxhighlight><br />
<br />
=== Taster und Schalter ===<br />
<br />
Der Anschluss mechanischer Kontakte an den Mikrocontroller, ist zwischen zwei unterschiedliche Methoden zu unterscheiden: ''Active Low'' und ''Active High''.<br />
<br />
<gallery widths="300" heights="300" caption="Anschluss mechanischer Kontakte an einen µC"><br />
Image:Active Low.gif|'''Active Low:''' Bei dieser Methode wird der Kontakt zwischen den Eingangspin des Controllers und Masse geschaltet. Damit bei offenem Schalter der Controller kein undefiniertes Signal bekommt, wird zwischen die Versorgungsspannung und den Eingangspin ein sogenannter '''Pull-Up''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffnetem Schalter auf logisch 1 zu ziehen.<br />
Image:Active High.gif|'''Active High:''' Hier wird der Kontakt zwischen die Versorgungsspannung und den Eingangspin geschaltet. Damit bei offener Schalterstellung kein undefiniertes Signal am Controller ansteht, wird zwischen den Eingangspin und die Masse ein '''Pull-Down''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffneter Schalterstellung auf logisch 0 zu halten. <br />
</gallery><br />
<br />
Der Widerstandswert von Pull-Up- und Pull-Down-Widerständen ist an sich nicht kritisch. Wird er allerdings zu hoch gewählt, ist die Wirkung eventuell nicht gegeben. Als üblicher Wert haben sich 10 kOhm eingebürgert. Die AVRs verfügen an den meisten Pins über zuschaltbare interne Pull-Up Widerstände (vgl. Abschnitt [[AVR-GCC-Tutorial#Interne Pull-Up Widerstände|Interne Pull-Up Widerstände]]), welche insbesondere wie hier bei Tastern und ähnlichen Bauteilen (z.&nbsp;B. Drehgebern) statt externer Bauteile verwendet werden können. Interne Pull-Down-Widerstand sind nicht verfügbar und müssen daher in Form zusätzlicher Bauteile in die Schaltung eingefügt werden.<br />
<br />
==== Taster entprellen ====<br />
<br />
Siehe: ''[[Entprellung#Warteschleifen-Verfahren|Entprellung: Warteschleifen-Verfahren]]<br />
<br />
= Warteschleifen (delay.h) =<br />
<br />
Der Programmablauf kann verschiedene Arten von Wartefunktionen erfordern:<br />
<br />
* Warten im Sinn von Zeitvertrödeln<br />
* Warten auf einen bestimmten Zustand an den I/O-Pins<br />
* Warten auf einen bestimmten Zeitpunkt (siehe Timer)<br />
* Warten auf einen bestimmten Zählerstand (siehe Counter)<br />
<br />
Der einfachste Fall, das Zeitvertrödeln, kann in vielen Fällen und mit großer Genauigkeit anhand der avr-libc Bibliotheksfunktionen _delay_ms() und _delay_us() erledigt werden. Die Bibliotheksfunktionen sind einfachen Zählschleifen (Warteschleifen) vorzuziehen, da leere Zählschleifen ohne besondere Vorkehrungen sonst bei eingeschalteter Optimierung vom avr-gcc-Compiler wegoptimiert werden. Weiterhin sind die Bibliotheksfunktionen bereits darauf vorbereitet, die in F_CPU definierte Taktfrequenz zu verwenden. Außerdem sind die Funktionen der Bibliothek wirklich getestet.<br />
<br />
Einfach!? Schon, aber während gewartet wird, macht der µC nichts anderes mehr (abgesehen von möglicherweise auftretenden Interrupts, falls welche aktiviert sind). Die Wartefunktion blockiert den Programmablauf. Möchte man einerseits warten, um z.&nbsp;B. eine LED blinken zu lassen und gleichzeitig andere Aktionen ausführen z.&nbsp;B. weitere LED bedienen, sollten die Timer/Counter des AVR verwendet werden, siehe Artikel [[Multitasking]].<br />
<br />
Die Bibliotheksfunktionen funktionieren allerdings nur dann korrekt, wenn sie mit zur Übersetzungszeit (beim Compilieren) bekannten konstanten Werten aufgerufen werden. Der Quellcode muss mit eingeschalteter Optimierung übersetzt werden, sonst wird sehr viel Maschinencode erzeugt, und die Wartezeiten stimmen nicht mehr mit dem Parameter überein.<br />
<br />
Eine weitere Einschränkung liegt darin, daß sie möglicherweise länger warten, als erwartet, nämlich in dem Fall, daß Interrupts auftreten und die _delay...()-Funktion unterbrechen. Genau genommen warten diese nämlich nicht eine bestimmte Zeit, sondern verbrauchen eine bestimmte Anzahl von Prozessortakten. Die wiederum ist so bemessen, daß ohne Unterbrechung durch Interrupts die gewünschte Wartezeit erreicht wird.<br />
Wird das Warten aber durch eine oder mehrere ISR unterbrochen, die zusammen 1% Prozessorzeit verbrauchen, dann dauert das Warten etwa 1% länger. Bei 50% Last durch die ISR dauert das Warten doppelt solange wie gewünscht, bei 90% zehnmal solange...<br />
<br />
Abhängig von der Version der Bibliothek verhalten sich die Bibliotheksfunktionen etwas unterschiedlich.<br />
<br />
== avr-libc Versionen bis 1.6 ==<br />
<br />
Die Wartezeit der Funktion _delay_ms() ist auf 262,14ms/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 13,1ms warten. Die Wartezeit der Funktion _delay_us() ist auf 768us/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 38,4µs warten. Längere Wartezeiten müssen dann über einen mehrfachen Aufruf in einer Schleife gelöst werden.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.&nbsp;B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h> /* in älteren avr-libc Versionen <avr/delay.h> */ <br />
<br />
/*<br />
lange, variable Verzögerungszeit, Einheit in Millisekunden<br />
<br />
Die maximale Zeit pro Funktionsaufruf ist begrenzt auf <br />
262.14 ms / F_CPU in MHz (im Beispiel: <br />
262.1 / 3.6864 = max. 71 ms) <br />
<br />
Daher wird die kleine Warteschleife mehrfach aufgerufen,<br />
um auf eine längere Wartezeit zu kommen. Die zusätzliche <br />
Prüfung der Schleifenbedingung lässt die Wartezeit geringfügig<br />
ungenau werden (macht hier vielleicht 2-3ms aus).<br />
*/<br />
<br />
void long_delay(uint16_t ms)<br />
{<br />
for(; ms>0; ms--) _delay_ms(1);<br />
}<br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) // Endlosschleife<br />
{ <br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.&nbsp;B. angeschlossene LED<br />
long_delay(1000); // Eine Sekunde warten...<br />
}<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
== avr-libc Versionen ab 1.7 ==<br />
<br />
_delay_ms() kann mit einem Argument bis 6553,5 ms (= 6,5535 Sekunden) benutzt werden. Es ist nicht möglich, eine Variable als Argument zu übergeben. Wird die früher gültige Grenze von 262,14 ms/F_CPU (in MHz) überschritten, so arbeitet _delay_ms() einfach etwas ungenauer und zählt nur noch mit einer Auflösung von 1/10 ms. Eine Verzögerung von 1000,10 ms ließe sich nicht mehr von einer von 1000,19 ms unterscheiden. Ein Verlust, der sich im Allgemeinen verschmerzen lässt. Dem Programmierer wird keine Rückmeldung gegeben, dass die Funktion ggf. gröber arbeitet, d.h. wenn es darauf ankommt, bitte den Parameter wie bisher geschickt wählen.<br />
<br />
Die Funktion _delay_us() wurde ebenfalls erweitert. Wenn deren maximal als genau behandelbares Argument überschritten wird, benutzt diese intern _delay_ms(). Damit gelten in diesem Fall die _delay_ms() Einschränkungen.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus, avr-libc ab Version 1.6<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h><br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) { // Endlosschleife<br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED<br />
_delay_ms(1000); // Eine Sekunde +/-1/10000 Sekunde warten...<br />
// funktioniert nicht mit Bibliotheken vor 1.6<br />
<br />
}<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
Die _delay_ms() und die _delay_us aus '''avr-libc 1.7.0''' sind fehlerhaft. _delay_ms () läuft 4x schneller als erwartet. Abhilfe ist eine korrigierte Includedatei: [http://www.mikrocontroller.net/topic/196738#1943039]<br />
<br />
= Programmieren mit Interrupts =<br />
<br />
<div style="float:right; margin:2em;"><br />
[[Image:Interrupt Programme.gif]]<br />
</div><br />
Nachdem wir nun alles Wissenswerte für die serielle Programmerstellung<br />
gelernt haben nehmen wir jetzt ein völlig anderes Thema in Angriff, nämlich<br />
die Programmierung unter Zuhilfenahme der Interrupts des AVR.<br />
<br />
Tritt ein Interrupt auf, unterbricht (engl. interrupts) der Controller die Verarbeitung des Hauptprogramms und verzweigt zu einer Interruptroutine. Das Hauptprogramm wird also beim Eintreffen eines Interrupts unterbrochen, die Interruptroutine ausgeführt und danach erst wieder das Hauptprogramm an der Unterbrechungsstelle fortgesetzt (vgl. die Abbildung).<br />
<br />
Um Interrupts verarbeiten zu können, ist folgendes zu beachten:<br />
<br />
* Für jede aktivierte Interruptquelle ist eine Funktion zu programmieren, in der die beim Auftreten des jeweiligen Interrupts erforderlichen Verarbeitungsschritte enthalten sind. Für diese Funktion existieren verschiedene Bezeichnungen. Üblich sind die englischen Begriffe Interrupt-Handler oder Interrupt-Service-Routinen (ISR), man findet aber auch die Bezeichnungen Interruptverarbeitungs- oder -behandlungsroutine oder auch kurz Interruptroutine. Zum Beispiel wird üblicherweise in der ISR zur Verarbeitung des Empfangsinterrupts eines UARTs (UART-RX Interrupt) das empfangene Zeichen in einen Zwischenspeicher (FIFO-Buffer) kopiert, dessen Inhalt später von anderen Programmteilen geleert wird. Sofern der Zwischenspeicher ausreichend groß ist, geht also kein Zeichen verloren, auch wenn im Hauptprogramm zeitintensive Operationen durchgeführt werden.<br />
* Die benötigten Interrupts sind in den jeweiligen Funktionsbausteinen einzuschalten. Dies erfolgt über das jeweilige Aktivierungsbit (Interrupt Enable) in einem der Hardwareregister (z.B. RX(Complete)Interrupt Enable eines UARTs)<br />
* Sämtliche Interrupts werden über einen weiteren globalen Schalter aktiviert und deaktiviert. Zur Verarbeitung der Interrupts ist dieser Schalter zu aktivieren (sei(), siehe unten).<br />
<br />
Alle Punkte sind zu beachten. Fehlt z.B. die globale Aktivierung, werden Interruptroutinen auch dann nicht aufgerufen, wenn sie im Funktionsbaustein eingeschaltet sind und eine Behandlungsroutine verhanden ist.<br />
<br />
Siehe auch<br />
<br />
* [http://www.mikrocontroller.net/forum/read-1-235092.html#new Ausführlicher Thread im Forum]<br />
* Artikel [[Interrupt]]<br />
* Artikel [[Multitasking]]<br />
{{Clear}}<br />
<br />
== Anforderungen an Interrupt-Routinen ==<br />
<br />
Um unliebsamen Überraschungen vorzubeugen, sollten einige Grundregeln bei der Implementierung der Interruptroutinen beachtet werden. Interruptroutinen sollten möglichst kurz und schnell abarbeitbar sein, daraus folgt:<br />
<br />
* Keine umfangreichen Berechnungen innerhalb der Interruptroutine. (*)<br />
* Keine langen Programmschleifen.<br />
* Obwohl es möglich ist, während der Abarbeitung einer Interruptroutine andere oder sogar den gleichen Interrupt wieder zuzulassen, wird davon ohne genaue Kenntnis der internen Abläufe dringend abgeraten.<br />
<br />
Interruptroutinen (ISRs) sollten also möglichst kurz sein und keine Schleifen mit vielen Durchläufen enthalten. Längere Operationen können meist in einen "Interrupt-Teil" in einer ISR und einen "Arbeitsteil" im Hauptprogramm aufgetrennt werden. Z.B. Speichern des Zustands aller Eingänge im EEPROM in bestimmten Zeitabständen: ISR-Teil: Zeitvergleich (Timer,RTC) mit Logzeit/-intervall. Bei Übereinstimmung ein globales Flag setzen (volatile bei Flag-Deklaration nicht vergessen, s.u.). Dann im Hauptprogramm prüfen, ob das Flag gesetzt ist. Wenn ja: die Daten im EEPROM ablegen und Flag löschen.<br />
<br />
(*)<br />
Hinweis: <br />
Es gibt allerdings die seltene Situation, dass man gerade eingelesene<br />
ADC-Werte sofort verarbeiten muss. Besonders dann, wenn man mehrere Werte sehr<br />
schnell hintereinander bekommt. Dann bleibt einem nichts anderes übrig, als die<br />
Werte noch in der ISR zu verarbeiten. Kommt aber sehr selten vor und sollte<br />
durch geeignete Wahl des Systemtaktes bzw. Auswahl des Controllers vermieden werden!<br />
<br />
== Interrupt-Quellen ==<br />
<br />
Die folgenden Ereignisse können einen Interrupt auf einem AVR AT90S2313 auslösen, wobei die Reihenfolge der Auflistung auch die Priorität der Interrupts aufzeigt.<br />
<br />
* Reset<br />
* Externer Interrupt 0<br />
* Externer Interrupt 1<br />
* Timer/Counter 1 Capture Ereignis<br />
* Timer/Counter 1 Compare Match<br />
* Timer/Counter 1 Überlauf<br />
* Timer/Counter 0 Überlauf<br />
* UART Zeichen empfangen<br />
* UART Datenregister leer<br />
* UART Zeichen gesendet<br />
* Analoger Komparator<br />
<br />
Die Anzahl der möglichen Interruptquellen variiert zwischen den verschiedenen Microcontroller-Typen. Im Zweifel hilft ein Blick ins Datenblatt ("Interrupt Vectors").<br />
<br />
== Register ==<br />
<br />
Der AT90S2313 verfügt über 2 Register die mit den<br />
Interrupts zusammenhängen.<br />
<br />
{| class="wikitable"<br />
|- <br />
!width="10%"| GIMSK<br />
| '''G'''eneral '''I'''nterrupt '''M'''a'''sk''' Register.<br /><br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit <br />
| 7 || 6|| 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INT1''' || '''INT0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INT1''' (External '''Int'''errupt Request '''1''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT1'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
'''INT0''' (External '''Int'''errupt Request '''0''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT0'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
|- <br />
! GIFR<br />
| '''G'''eneral '''I'''nterrupt '''F'''lag '''R'''egister.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INTF1''' || '''INTF0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INTF1''' (External '''Int'''errupt Flag '''1''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT1'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
<br />
'''INTF0''' (External '''Int'''errupt Flag '''0''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT0'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
|- <br />
! MCUCR<br />
| '''MCU''' '''C'''ontrol '''R'''egister.<br />
<br />
Das MCU Control Register enthält Kontrollbits für allgemeine MCU-Funktionen.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''-'''|| '''-'''|| '''SE'''|| '''SM'''|| '''ISC11'''|| '''ISC10'''|| '''ISC01'''|| '''ISC00'''<br />
|- <br />
! R/W<br />
| R || R || R/W || R/W || R/W || R/W || R/W || R/W<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
<br />
|}<br />
<br />
'''SE''' ('''S'''leep '''E'''nable)<br />
:Dieses Bit muss gesetzt sein, um den Controller mit dem '''SLEEP'''-Befehl in den Schlafzustand versetzen zu können.<br />
:Um den Schlafmodus nicht irrtümlich einzuschalten, wird empfohlen, das Bit erst unmittelbar vor Ausführung des '''SLEEP'''-Befehls zu setzen.<br />
<br />
'''SM''' ('''S'''leep '''M'''ode)<br />
:Dieses Bit bestimmt über den Schlafmodus.<br />
:Ist das Bit gelöscht, so wird der '''Idle'''-Modus ausgeführt. Ist das Bit gesetzt, so wird der '''Power-Down'''-Modus ausgeführt. (für andere AVR Controller siehe Abschnitt "Sleep-Mode")<br />
<br />
'''ISC11''', '''ISC10''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''1''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT1'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
!width="10%"| ISC11 ||width="10%"| ISC10 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT1''' erzeugt einen Interrupt.<br />
<br />
Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|}<br />
<br />
'''ISC01''', '''ISC00''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''0''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT0'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
!width="10%"| ISC01 ||width="10%"| ISC00 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT0''' erzeugt einen Interrupt.<br />
<br />
Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|}<br />
<br />
|}<br />
<br />
== Allgemeines über die Interrupt-Abarbeitung ==<br />
<br />
Wenn ein Interrupt eintrifft, wird automatisch das '''Global Interrupt Enable''' Bit im Status Register '''SREG''' gelöscht und alle weiteren Interrupts unterbunden. Dieses wird automatisch wieder gesetzt, wenn die Interruptroutine beendet wird. Wenn in der Zwischenzeit weitere Interrupts eintreffen, werden die zugehörigen Interrupt-Bits gesetzt und die Interrupts bei Beendigung der laufenden Interrupt-Routine in der Reihenfolge ihrer Priorität ausgeführt. Dies kann<br />
eigentlich nur dann zu Problemen führen, wenn ein hoch priorisierter Interrupt ständig und in kurzer Folge auftritt. Dieser sperrt dann möglicherweise alle anderen Interrupts mit niedrigerer Priorität. Dies ist einer der Gründe, weshalb die Interrupt-Routinen sehr kurz gehalten werden sollen. Es ist möglich das GIE-Bit in der ISR zu setzen und so schon wieder weitere Interrupts zuzulassen - allerdings sollte man damit vorsichtig sein und genau wissen was man damit macht. Kritisch wird es vor allem wenn der gleiche Interrupt noch einmal kommt, bevor die ISR abgearbeitet ist. <br />
<br />
<!-- === Das Status-Register ===<br />
<br />
Es gilt auch zu beachten, dass das Status-Register während der Abarbeitung einer Interruptroutine nicht automatisch gesichert wird. Falls notwendig, muss dies vom Programmierer selber vorgesehen werden. --><br />
<br />
== Interrupts mit avr-gcc ==<br />
<br />
<!-- ''Anmerkung eines Nutzers: Ich habe mir das Thema hier angearbeitet und hatte am Anfang starke Probleme: Jeder Interrupt muss nochmals einzeln aktiviert werden. Es reicht nicht nur per ''sei()'' die Interrupts global zu aktiveren.'' - mthomas: Hoffentlich duch die modifizerte Einleitung etwas offensichtlicher erläutert. Ansonsten bitte per Eintrag auf die Diskussionseite nochmals melden) --> <br />
<!-- Selbstverständlich können alle interruptspezifischen Registerzugriffe wie gewohnt über I/O-Adressierung vorgenommen werden. Etwas einfacher geht es jedoch, wenn wir die vom Compiler zur Verfügung gestellten Mittel einsetzen.--><br />
Funktionen zur Interrupt-Verarbeitung werden in den Includedateien ''interrupt.h'' der avr-libc zur Verfügung gestellt (bei älterem Quellcode zusätzlich ''signal.h'').<br />
<br />
<syntaxhighlight lang="c"><br />
// fuer sei(), cli() und ISR():<br />
#include <avr/interrupt.h><br />
</syntaxhighlight><br />
<br />
Das Makro '''sei()''' schaltet die Interrupts ein. Eigentlich wird nichts anderes gemacht, als das '''Global Interrupt Enable''' Bit im Status Register gesetzt.<br />
<br />
<syntaxhighlight lang="c"><br />
sei();<br />
</syntaxhighlight><br />
<br />
Das Makro '''cli()''' schaltet die Interrupts aus, oder anders gesagt, das '''Global Interrupt Enable''' Bit im Status Register wird gelöscht.<br />
<br />
<syntaxhighlight lang="c"><br />
cli();<br />
</syntaxhighlight><br />
<br />
Oft steht man vor der Aufgabe, dass eine Codesequenz nicht unterbrochen werden darf. Es liegt dann nahe, zu Beginn dieser Sequenz ein cli() und am Ende ein sei() einzufügen. Dies ist jedoch ungünstig, wenn die Interrupts vor Aufruf der Sequenz deaktiviert waren und danach auch weiterhin deaktiviert bleiben sollen. Ein sei() würde ungeachtet des vorherigen Zustands die Interrupts aktivieren, was zu unerwünschten Seiteneffekten führen kann. Die aus dem folgenden Beispiel ersichtliche Vorgehensweise ist in solchen Fällen vorzuziehen:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <inttypes.h><br />
<br />
//...<br />
<br />
void NichtUnterbrechenBitte(void)<br />
{<br />
uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister<br />
<br />
tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) sichern<br />
cli(); // Interrupts global deaktivieren<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
/* Beispiel Anfang<br />
JTAG-Interface eines ATmega16 per Software deaktivieren <br />
und damit die JTAG-Pins an PORTC für "general I/O" nutzbar machen<br />
ohne die JTAG-Fuse-Bit zu aendern. Dazu ist eine "timed sequence"<br />
einzuhalten (vgl Datenblatt ATmega16, Stand 10/04, S. 229): <br />
Das JTD-Bit muss zweimal innerhalb von 4 Taktzyklen geschrieben <br />
werden. Ein Interrupt zwischen den beiden Schreibzugriffen wuerde <br />
die erforderliche Sequenz "brechen", das JTAG-Interface bliebe<br />
weiterhin aktiv und die IO-Pins weiterhin für JTAG reserviert. */<br />
<br />
MCUCSR |= (1<<JTD);<br />
MCUCSR |= (1<<JTD); // 2 mal in Folge ,vgl. Datenblatt fuer mehr Information<br />
<br />
/* Beispiel Ende */<br />
<br />
SREG = tmp_sreg; // Status-Register wieder herstellen <br />
// somit auch das I-Flag auf gesicherten Zustand setzen<br />
}<br />
<br />
void NichtSoGut(void)<br />
{<br />
cli();<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
sei();<br />
}<br />
<br />
<br />
int main(void)<br />
{<br />
//...<br />
<br />
cli(); <br />
// Interrupts global deaktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// auch nach Aufruf der Funktion deaktiviert<br />
<br />
sei();<br />
// Interrupts global aktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// weiterhin aktiviert<br />
//...<br />
<br />
/* Verdeutlichung der unguenstigen Vorgehensweise mit cli/sei: */<br />
cli(); <br />
// Interrupts jetzt global deaktiviert <br />
<br />
NichtSoGut();<br />
// nach Aufruf der Funktion sind Interrupts global aktiviert <br />
// dies ist mglw. ungewollt!<br />
//...<br />
<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
<!-- mt: besser so nicht(?), lieber "datenblattkonform"<br />
<br />
<font face="Courier New">'''timer_enable_int (unsigned char ints);<br /><br />
'''</font>Schaltet Timerbezogene Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle<br />
Timerinterrupts ausgeschaltet, ansonsten muss in '''ints''' angegeben werden,<br />
welche Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">timer_enable_int (1 << TOIE1));<br /><br />
</font>'''Achtung: Wenn ein Timerinterrupt eingeschaltet wird während ein<br />
anderer Timerinterrupt bereits läuft, dann müssen beide Bits angegeben werden<br />
sonst wird der andere Timerinterrupt versehentlich ausgeschaltet.<br />
<br />
<font face="Courier New">'''enable_external_int (unsigned char ints);<br /><br />
'''</font>Schaltet die externen Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle externen<br />
Interrrups ausgeschaltet, ansonsten muss in '''ints''' angegeben werden, welche<br />
Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">enable_external_int ((1<<br />
</font>'''Schaltet die externen Interrupts 0 und 1 ein.<br />
<br />
Nachdem nun die Interrupts aktiviert sind, braucht es selbstverständlich noch den auszuführenden Code, der ablaufen soll, wenn ein Interrupt eintrifft.<br />
--><br />
Zu den aktivierten Interrupts ist eine Funktion zu programmieren, deren Code aufgerufen wird, wenn der betreffende Interrupt auftritt (Interrupt-Handler, Interrupt-Service-Routine). Dazu existiert die Definition (ein Makro) '''ISR'''.<br />
<br />
=== ISR ===<br />
<br />
(''ISR()'' ersetzt bei neueren Versionen der avr-libc ''SIGNAL()''. SIGNAL sollte nicht mehr genutzt werden, zur Portierung von SIGNAL nach ISR siehe den [[AVR-GCC-Tutorial#Anhang|Anhang]].)<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
//...<br />
ISR(Vectorname) /* vormals: SIGNAL(siglabel) dabei Vectorname != siglabel ! */<br />
{<br />
/* Interrupt Code */<br />
}<br />
</syntaxhighlight><br />
<br />
Mit ''ISR'' wird eine Funktion für die Bearbeitung eines Interrupts eingeleitet. Als Argument muss dabei die Benennung des entsprechenden Interruptvektors angegeben werden. Diese sind in den jeweiligen Includedateien IOxxxx.h zu finden. Die Bezeichnung entspricht dem Namen aus dem Datenblatt, bei dem die Leerzeichen durch Unterstriche ersetzt sind und ein ''_vect'' angehängt ist.<br />
<br />
Als Beispiel ein Ausschnitt aus der Datei für den ATmega8 (bei WinAVR Standardinstallation in C:\WinAVR\avr\include\avr\iom8.h) in der neben den aktuellen Namen für ''ISR'' (*_vect) noch die Bezeichnungen für das inzwischen nicht mehr aktuelle ''SIGNAL'' (SIG_*) enthalten sind.<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
/* $Id: iom8.h,v 1.13 2005/10/30 22:11:23 joerg_wunsch Exp $ */<br />
<br />
/* avr/iom8.h - definitions for ATmega8 */<br />
//...<br />
<br />
/* Interrupt vectors */<br />
<br />
/* External Interrupt Request 0 */<br />
#define INT0_vect _VECTOR(1)<br />
#define SIG_INTERRUPT0 _VECTOR(1)<br />
<br />
/* External Interrupt Request 1 */<br />
#define INT1_vect _VECTOR(2)<br />
#define SIG_INTERRUPT1 _VECTOR(2)<br />
<br />
/* Timer/Counter2 Compare Match */<br />
#define TIMER2_COMP_vect _VECTOR(3)<br />
#define SIG_OUTPUT_COMPARE2 _VECTOR(3)<br />
<br />
/* Timer/Counter2 Overflow */<br />
#define TIMER2_OVF_vect _VECTOR(4)<br />
#define SIG_OVERFLOW2 _VECTOR(4)<br />
<br />
/* Timer/Counter1 Capture Event */<br />
#define TIMER1_CAPT_vect _VECTOR(5)<br />
#define SIG_INPUT_CAPTURE1 _VECTOR(5)<br />
<br />
/* Timer/Counter1 Compare Match A */<br />
#define TIMER1_COMPA_vect _VECTOR(6)<br />
#define SIG_OUTPUT_COMPARE1A _VECTOR(6)<br />
<br />
/* Timer/Counter1 Compare Match B */<br />
#define TIMER1_COMPB_vect _VECTOR(7)<br />
#define SIG_OUTPUT_COMPARE1B _VECTOR(7)<br />
<br />
//...<br />
</syntaxhighlight><br />
<br />
<!--Vor Nutzung von SIGNAL muss ebenfalls die Header-Datei signal.h eingebunden werden.--> <br />
Mögliche Funktionsrümpfe für Interruptfunktionen sind zum Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
/* veraltet: #include <avr/signal.h> */<br />
<br />
ISR(INT0_vect) /* veraltet: SIGNAL(SIG_INTERRUPT0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(TIMER0_OVF_vect) /* veraltet: SIGNAL(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(USART_RXC_vect) /* veraltet: SIGNAL(SIG_UART_RECV) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
// und so weiter und so fort...<br />
</syntaxhighlight><br />
<br />
Auf die korrekte Schreibweise der Vektorbezeichnung ist zu achten. Der gcc-Compiler prüft erst ab Version 4.x, ob ein Signal/Interrupt der angegebenen Bezeichnung tatsächlich in der Includedatei definiert ist und gibt andernfalls eine Warnung aus. Bei WinAVR (ab 2/2005) wurde die Überprüfung auch in den mitgelieferten Compiler der Version 3.x integriert. Aus dem gcc-Quellcode Version 3.x selbst erstellte Compiler enthalten die Prüfung nicht (vgl. [[AVR-GCC]]). <br />
<br />
Während der Ausführung der Funktion sind alle weiteren Interrupts automatisch gesperrt. Beim Verlassen der Funktion werden die Interrupts wieder zugelassen.<br />
<br />
Sollte während der Abarbeitung der Interruptroutine ein weiterer Interrupt (gleiche oder andere Interruptquelle) auftreten, so wird das entsprechende Bit im zugeordneten Interrupt Flag Register gesetzt und die entsprechende Interruptroutine automatisch nach dem Beenden der aktuellen Funktion aufgerufen.<br />
<br />
Ein Problem ergibt sich eigentlich nur dann, wenn während der Abarbeitung der aktuellen Interruptroutine mehrere gleichartige Interrupts auftreten. Die entsprechende Interruptroutine wird im Nachhinein zwar aufgerufen jedoch wissen wir nicht, ob nun der entsprechende Interrupt einmal, zweimal oder gar noch öfter aufgetreten ist. Deshalb soll hier noch einmal betont werden, dass Interruptroutinen so schnell wie nur irgend möglich wieder verlassen werden sollten.<br />
<br />
=== Unterbrechbare Interruptroutinen ===<br />
<br />
"Faustregel": im Zweifel '''ISR'''. Die nachfolgend beschriebene Methode nur dann verwenden, wenn man sich über die unterschiedliche Funktionsweise im Klaren ist.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
<br />
ISR(XXX,ISR_NOBLOCK) /* veraltet: INTERRUPT(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt-Code */<br />
}<br />
</syntaxhighlight><br />
<br />
Hierbei steht XXX für den oben beschriebenen Namen des Vektors (also z.&nbsp;B. ''TIMER0_OVF_vect''). Der Unterschied im Vergleich zu einer herkömmlichen ISR ist, dass hier beim Aufrufen der Funktion das '''Global Enable Interrupt''' Bit durch Einfügen einer SEI-Anweisung direkt wieder gesetzt und somit alle Interrupts zugelassen werden &ndash; auch XXX-Interrupts. <br />
<br />
Bei unsachgemässer Handhabung kann dies zu erheblichen Problemen durch Rekursion wie einem Stack-Overflow oder anderen unerwarteten Effekten führen und sollte wirklich nur dann eingesetzt werden, wenn man sich sicher ist, das Ganze auch im Griff zu haben.<br />
<br />
Insbesondere sollte möglichst am ISR-Anfang die auslösende IRQ-Quelle deaktiviert und erst am Ende der ISR wieder aktiviert werden. Robuster als die Verwendung einer NOBLOCK-ISR ist daher folgender ISR-Aufbau:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
<br />
ISR (XXX) <br />
{<br />
// Implementiere die ISR ohne zunaechst weitere IRQs zuzulassen<br />
<br />
<<Deaktiviere die XXX-IRQ>><br />
<br />
// Erlaube alle Interrupts (ausser XXX)<br />
sei();<br />
<br />
//... Code ...<br />
<br />
// IRQs global deaktivieren um die XXX-IRQ wieder gefahrlos <br />
// aktivieren zu koennen<br />
cli();<br />
<br />
<<Aktiviere die XXX-IRQ>><br />
}<br />
</syntaxhighlight><br />
Auf diese Weise kann sich die XXX-IRQ nicht selbst unterbrechen, was zu einer Art Endlosschleife führen würde.<br />
<br />
Siehe auch: Hinweise in [[AVR-GCC]]<br />
<br />
siehe dazu: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html<br />
<br />
== Datenaustausch mit Interrupt-Routinen ==<br />
<br />
Variablen, die sowohl in Interrupt-Routinen (ISR = Interrupt Service Routine(s)) als auch vom übrigen Programmcode geschrieben oder gelesen werden, müssen mit einem '''volatile''' deklariert werden. Damit wird dem Compiler mitgeteilt, dass der Inhalt der Variablen vor jedem Lesezugriff aus dem Speicher gelesen und nach jedem Schreibzugriff in den Speicher geschrieben wird. Ansonsten könnte der Compiler den Code so optimieren, dass der Wert der Variablen nur in Prozessorregistern zwischengespeichert wird, die nichts von der Änderung woanders mitbekommen.<br />
<br />
Zur Veranschaulichung ein Codefragment für eine Tastenentprellung mit Erkennung einer "lange gedrückten" Taste.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <stdint.h><br />
//...<br />
<br />
// Schwellwerte<br />
// Entprellung: <br />
#define CNTDEBOUNCE 10<br />
// "lange gedrueckt:"<br />
#define CNTREPEAT 200<br />
<br />
// hier z.&nbsp;B. Taste an Pin2 PortA "active low" = 0 wenn gedrueckt<br />
#define KEY_PIN PINA<br />
#define KEY_PINNO PA2<br />
<br />
// beachte: volatile! <br />
volatile uint8_t gKeyCounter;<br />
<br />
// Timer-Compare Interrupt ISR, wird z.B. alle 10ms ausgefuehrt<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
// hier wird gKeyCounter veraendert. Die übrigen<br />
// Programmteile müssen diese Aenderung "sehen":<br />
// volatile -> aktuellen Wert immer in den Speicher schreiben<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
}<br />
else {<br />
gKeyCounter = 0;<br />
}<br />
}<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
//...<br />
/* hier: Initialisierung der Ports und des Timer-Interrupts */<br />
//... <br />
// hier wird auf gKeyCounter zugegriffen. Dazu muss der in der<br />
// ISR geschriebene Wert bekannt sein:<br />
// volatile -> aktuellen Wert immer aus dem Speicher lesen<br />
if ( gKeyCounter > CNTDEBOUNCE ) { // Taste mind. 10*10 ms "prellfrei"<br />
if (gKeyCounter == CNTREPEAT) {<br />
/* hier: Code fuer "Taste lange gedrueckt" */<br />
}<br />
else {<br />
/* hier: Code fuer "Taste kurz gedrueckt" */<br />
}<br />
}<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Wird innerhalb einer ISR mehrfach auf eine mit volatile deklarierte Variable zugegriffen, wirkt sich dies ungünstig auf die Verarbeitungsgeschwindigkeit aus, da bei jedem Zugriff mit dem Speicherinhalt abgeglichen wird. Da bei AVR-Controllern ''innerhalb'' einer ISR keine Unterbrechungen zu erwarten sind, bietet es sich an, einen Zwischenspeicher in Form einer lokalen Variable zu verwenden, deren Inhalt zu Beginn und am Ende mit dem der volatile Variable synchronisiert wird. Lokale Variable werden bei eingeschalteter Optimierung mit hoher Wahrscheinlichkeit in Prozessorregistern verwaltet und der Zugriff darauf ist daher nur mit wenigen internen Operationen verbunden. Die ISR aus dem vorherigen Beispiel lässt sich so optimieren:<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter; // Uebernahme in lokale Arbeitsvariable<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (tmp_kc < CNTREPEAT) {<br />
tmp_kc++;<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc; // Zurueckschreiben<br />
}<br />
//...<br />
</syntaxhighlight><br />
<br />
Zum Vergleich die Disassemblies (Ausschnitte der "lss-Dateien", compiliert für ATmega162) im Anschluss. Man erkennt den viermaligen Zugriff auf die Speicheraddresse von ''gKeyCounter'' (hier 0x032A) in der ISR ohne "Cache"-Variable und den zweimaligen Zugriff in der Variante mit Zwischenspeicher. Im Beispiel ist der Vorteil gering, bei komplexeren Routinen kann die Zwischenspeicherung in lokalen Variablen jedoch zu deutlicheren Verbesserungen führen.<br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
876: ca 99 sbic 0x19, 2 ; 25<br />
878: 0a c0 rjmp .+20 ; 0x88e <__vector_13+0x24><br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
87a: 80 91 2a 03 lds r24, 0x032A<br />
87e: 88 3c cpi r24, 0xC8 ; 200 <br />
880: 40 f4 brcc .+16 ; 0x892 <__vector_13+0x28><br />
882: 80 91 2a 03 lds r24, 0x032A<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 02 c0 rjmp .+4 ; 0x892 <__vector_13+0x28><br />
}<br />
else {<br />
gKeyCounter = 0;<br />
88e: 10 92 2a 03 sts 0x032A, r1<br />
892: 8f 91 pop r24<br />
894: 0f 90 pop r0<br />
896: 0f be out 0x3f, r0 ; 63<br />
898: 0f 90 pop r0<br />
89a: 1f 90 pop r1<br />
89c: 18 95 reti<br />
</pre><br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter;<br />
876: 80 91 2a 03 lds r24, 0x032A<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
87a: ca 9b sbis 0x19, 2 ; 25<br />
87c: 02 c0 rjmp .+4 ; 0x882 <__vector_13+0x18><br />
87e: 80 e0 ldi r24, 0x00 ; 0<br />
880: 03 c0 rjmp .+6 ; 0x888 <__vector_13+0x1e><br />
if (tmp_kc < CNTREPEAT) {<br />
882: 88 3c cpi r24, 0xC8 ; 200<br />
884: 08 f4 brcc .+2 ; 0x888 <__vector_13+0x1e><br />
tmp_kc++;<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc;<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 8f 91 pop r24<br />
88e: 0f 90 pop r0<br />
890: 0f be out 0x3f, r0 ; 63<br />
892: 0f 90 pop r0<br />
894: 1f 90 pop r1<br />
896: 18 95 reti<br />
</pre><br />
<br />
=== volatile und Pointer ===<br />
<br />
Bei '''volatile''' in Verbindung mit Pointern ist zu beachten, ob der Pointer selbst oder die Variable, auf die der Pointer zeigt, '''volatile''' ist.<br />
<br />
<syntaxhighlight lang="c"><br />
volatile uint8_t *a; // das Ziel von a ist volatile<br />
<br />
uint8_t *volatile a; // a selbst ist volatile<br />
</syntaxhighlight><br />
<br />
Falls der Pointer volatile ist (zweiter Fall im Beispiel), ist zu beachten, dass der Wert des Pointers, also eine Speicheradresse, intern in mehr als einem Byte verwaltet wird. Lese- und Schreibzugriffe im Hauptprogramm (außerhalb von Interrupt-Routinen) sind daher so zu implementieren, dass alle Teilbytes der Adresse konsistent bleiben, vgl. dazu den folgenden Abschnitt.<br />
<br />
=== Variablen größer 1 Byte ===<br />
<br />
Bei Variablen größer ein Byte, auf die in Interrupt-Routinen und im Hauptprogramm zugegriffen wird, muss darauf geachtet werden, dass die Zugriffe auf die einzelnen Bytes außerhalb der ISR nicht durch einen Interrupt unterbrochen werden. (Allgemeinplatz: AVRs sind 8-bit Controller). Zur Veranschaulichung ein Codefragment:<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
volatile uint16_t gMyCounter16bit;<br />
//...<br />
ISR(...)<br />
{<br />
//...<br />
gMyCounter16Bit++;<br />
//...<br />
}<br />
<br />
int main(void)<br />
{<br />
uint16_t tmpCnt;<br />
//...<br />
// nicht gut: Mglw. hier ein Fehler, wenn ein Byte von MyCounter <br />
// schon in tmpCnt kopiert ist aber vor dem Kopieren des zweiten Bytes <br />
// ein Interrupt auftritt, der den Inhalt von MyCounter verändert.<br />
tmpCnt = gMyCounter16bit; <br />
<br />
<br />
// besser: Änderungen "außerhalb" verhindern -> alle "Teilbytes"<br />
// bleiben konsistent<br />
cli(); // Interrupts deaktivieren<br />
tmpCnt = gMyCounter16Bit;<br />
sei(); // wieder aktivieren<br />
<br />
// oder: vorheriger Status des globalen Interrupt-Flags bleibt erhalten<br />
uint8_t sreg_tmp;<br />
sreg_tmp = SREG; /* Sichern */<br />
cli()<br />
tmpCnt = gMyCounter16Bit;<br />
SREG = sreg_tmp; /* Wiederherstellen */<br />
<br />
// oder: mehrfach lesen, bis man konsistente Daten hat<br />
uint16_t count1 = gMyCounter16Bit;<br />
uint16_t count2 = gMyCounter16Bit;<br />
while (count1 != count2) {<br />
count1 = count2;<br />
count2 = gMyCounter16Bit;<br />
}<br />
tmpCnt = count1;<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Die avr-libc bietet ab Version 1.6.0(?) einige Hilfsfunktionen/Makros, mit der im Beispiel oben gezeigten Funktionalität, die zusätzlich auch sogenannte [http://en.wikipedia.org/wiki/Memory_barrier memory barriers] beinhalten. Diese stehen nach #include <util/atomic.h> zur Verfügung.<br />
<syntaxhighlight lang="c"><br />
//...<br />
#include <util/atomic.h><br />
//...<br />
<br />
// analog zu cli, Zugriff, sei:<br />
ATOMIC_BLOCK(ATOMIC_FORCEON) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
// oder:<br />
<br />
// analog zu Sicherung des SREG, cli, Zugriff und Zurückschreiben des SREG:<br />
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
//...<br />
</syntaxhighlight><br />
<br />
* siehe auch [http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Dokumentation der avr-libc zu atomic.h]<br />
<br />
== Interrupt-Routinen und Registerzugriffe ==<br />
<br />
Falls Register sowohl im Hauptprogramm als auch in Interrupt-Routinen verändert werden, ist darauf zu achten, dass diese Zugriffe sich nicht überlappen. Nur wenige Anweisungen lassen sich in sogenannte "atomare" Zugriffe übersetzen, die nicht von Interrupt-Routinen unterbrochen werden können. <br />
<br />
Zur Veranschaulichung eine Anweisung, bei der ein Bit und im Anschluss drei Bits in einem Register gesetzt werden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
int main(void)<br />
{<br />
//...<br />
PORTA |= (1<<PA0);<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Der Compiler übersetzt diese Anweisungen für einen ATmega128 bei Optimierungsstufe "S" nach:<br />
<br />
<div class="code"><pre><br />
...<br />
PORTA |= (1<<PA0);<br />
d2: d8 9a sbi 0x1b, 0 ; 27 (a)<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
d4: 8b b3 in r24, 0x1b ; 27 (b)<br />
d6: 8c 61 ori r24, 0x1C ; 28 (c)<br />
d8: 8b bb out 0x1b, r24 ; 27 (d)<br />
...<br />
</pre></div><br />
<br />
Das Setzen des einzelnen Bits wird bei eingeschalteter Optimierung für Register im unteren Speicherbereich in eine einzige Assembler-Anweisung (sbi) übersetzt und ist nicht anfällig für Unterbrechungen durch Interrupts. Die Anweisung zum Setzen von drei Bits wird jedoch in drei abhängige Assembler-Anweisungen übersetzt und bietet damit zwei "Angriffspunkte" für Unterbrechungen. Eine Interrupt-Routine könnte nach dem Laden des Ausgangszustands in den Zwischenspeicher (hier Register 24) den Wert des Registers ändern, z.&nbsp;B. ein Bit löschen. Damit würde der Zwischenspeicher nicht mehr mit dem tatsächlichen Zustand übereinstimmen aber dennoch nach der Bitoperation (hier ori) in das Register zurückgeschrieben. <br />
<br />
Beispiel: PORTA sei anfangs 0b00000000. Die erste Anweisung (a) setzt Bit 0 auf '''1''', PORTA ist danach 0b0000000'''1'''. Nun wird im ersten Teil der zweiten Anweisung der Portzustand in ein Register eingelesen (b). Unmittelbar darauf (vor (c)) "feuert" ein Interrupt, in dessen Interrupt-Routine Bit 0 von PORTA gelöscht wird. Nach Verlassen der Interrupt-Routine hat PORTA den Wert 0b00000000. In den beiden noch folgenden Anweisungen des Hauptprogramms wird nun der zwischengespeicherte "alte" Zustand 0b00000001 mit 0b00011100 logisch-'''ODER'''-verknüft (c) und das Ergebnis 0b00011101 in PortA geschrieben (d). Obwohl zwischenzeitlich Bit 0 gelöscht wurde, ist es nach (d) wieder gesetzt. <br />
<br />
Lösungsmöglichkeiten:<br />
* Register ohne besondere Vorkehrungen nicht in Interruptroutinen ''und'' im Hauptprogramm verändern.<br />
* Interrupts vor Veränderungen in Registern, die auch in ISRs verändert werden, deaktivieren ("cli").<br />
* Bits einzeln löschen oder setzen. sbi und cbi können nicht unterbrochen werden. Vorsicht: nur Register im unteren Speicherbereich sind mittels sbi/cbi ansprechbar. Der Compiler kann nur für diese sbi/cbi-Anweisungen generieren. Für Register außerhalb dieses Adressbereichs ("Memory-Mapped"-Register) werden auch zur Manipulation einzelner Bits abhängige Anweisungen erzeugt (lds,...,sts).<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Frequently asked Questions/Fragen Nr. 1 und 8. (Stand: avr-libc Vers. 1.0.4)<br />
<br />
== Interruptflags löschen ==<br />
<br />
Beim Löschen von Interruptflags haben AVRs eine Besonderheit, die auch im Datenblatt beschrieben ist: Es wird zum Löschen eine 1 in das betreffende Bit geschrieben. <br />
<br />
Hinweis:<br /><br />
Bei Registern mit mehreren Interrupt-Flag-Bits (wie die Timer Interrupt Flag Register) '''nicht''' die übliche bitweise VerODERung nehmen, sondern eine direkte Zuweisung machen. Da sonst weitere Flags, als nur das gewünschte, ebenfalls gelöscht werden könnten.<br /><br />
([http://www.mikrocontroller.net/topic/171148#1640133 Erklärung]).<br />
<br />
== Was macht das Hauptprogramm? ==<br />
<br />
Im einfachsten (Ausnahme-)Fall gar nichts mehr. Es ist also durchaus denkbar, ein Programm zu schreiben, welches in der main-Funktion lediglich noch die Interrupts aktiviert und dann in einer Endlosschleife verharrt. Sämtliche Funktionen werden dann in den ISRs abgearbeitet. Diese Vorgehensweise ist jedoch bei den <i>meisten</i> Anwendungen schlecht: man verschenkt eine Verarbeitungsebene und hat außerdem möglicherweise Probleme durch Interruptroutinen, die zu viel Verarbeitungszeit benötigen.<br />
<br />
Für <i>wenige</i> Anwendungen ist diese Vorgehensweise jedoch perfekt: Die Hauptschleife verkommt zu <tt>for(;;) sleep_cpu();</tt> — siehe nächster Abschnitt „Sleep“. Weiterer Vorteil: ISRs brauchen keine(!) Register retten, ein Fall für <tt>ISR(<i>name</i>,ISR_NAKED){ … reti();}</tt>. <i>So</i> können Mikrocontroller für batteriebetriebene Geräte, etwa Fernbedienungen, maximal Energie sparen.<br />
<br />
Normalerweise wird man in den Interruptroutinen nur die bei Auftreten des jeweiligen Interruptereignisses unbedingt notwendigen Operationen ausführen lassen. Alle weniger kritischen Aufgaben werden dann im Hauptprogramm abgearbeitet.<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Interrupts and Signals<br />
<br />
= Sleep-Modes =<br />
<br />
AVR Controller verfügen über eine Reihe von sogenannten [[Sleep Mode |''Sleep-Modes'']] ("Schlaf-Modi"). Diese ermöglichen es, Teile des Controllers abzuschalten. Zum Einen kann damit besonders bei Batteriebetrieb Strom gespart werden, zum Anderen können Komponenten des Controllers deaktiviert werden, die die Genauigkeit des Analog-Digital-Wandlers bzw. des Analog-Comparators negativ beeinflussen. Der Controller wird durch Interrupts aus dem Schlaf geweckt. Welche Interrupts den jeweiligen Schlafmodus beenden, ist einer Tabelle im Datenblatt des jeweiligen Controllers zu entnehmen.<br />
Die Funktionen (eigentlich Makros) der avr-libc stehen nach Einbinden der header-Datei ''sleep.h'' zur Verfügung.<br />
<br />
;set_sleep_mode (uint8_t mode): Setzt den Schlafmodus, der bei Aufruf von sleep() aktiviert wird. In sleep.h sind einige Konstanten definiert (z.&nbsp;B. SLEEP_MODE_PWR_DOWN). Die definierten Modi werden jedoch nicht alle von sämtlichten AVR-Controllern unterstützt.<br />
;sleep_enable(): Aktiviert den gesetzten Schlafmodus, versetzt den Controller aber noch nicht in den Schlafmodus<br />
;sleep_cpu(): Versetzt den Controller in den Schlafmodus .sleep_cpu wird im Prinzip durch die Assembler-Anweisung ''sleep'' ersetzt.<br />
;sleep_disable(): Deaktiviert den gesetzten Schlafmodus<br />
;sleep_mode(): Versetzt den Controller in den mit set_sleep_mode gewählten Schlafmodus. Das Makro entspricht sleep_enable()+sleep_cpu()+sleep_disable(), beinhaltet also nicht die Aktivierung von Interrupts (besser nicht benutzen).<br />
<br />
Bei Anwendung von sleep_cpu() müssen Interrupts also bereits freigeben sein (sei()), da der Controller sonst nicht mehr "aufwachen" kann. sleep_mode() ist nicht geeignet für die Verwendung in ISR Interrupt-Service-Routinen, da bei deren Abarbeitung Interrupts global deaktiviert sind und somit auch die möglichen "Aufwachinterrupts". Abhilfe: stattdessen sleep_enable(), sei(), sleep_cpu(), sleep_disable() und evtl. cli() verwenden (vgl. Dokumentation der avr-libc).<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/sleep.h><br />
<br />
int main(void)<br />
{<br />
...<br />
<br />
while (1) {<br />
...<br />
set_sleep_mode(SLEEP_MODE_PWR_DOWN);<br />
sleep_mode();<br />
<br />
// Code hier wird erst nach Auftreten eines entsprechenden<br />
// "Aufwach-Interrupts" verarbeitet<br />
...<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
In älteren Versionenen der avr-libc wurden nicht alle AVR-Controller durch die sleep-Funktionen richtig angesteuert. Mit avr-libc 1.2.0 wurde die Anzahl der unterstützten Typen jedoch deutlich erweitert. Bei nicht-unterstützten Typen erreicht man die gewünschte Funktionalität durch direkte "[[Bitmanipulation]]" der entsprechenden Register (vgl. Datenblatt) und Aufruf des Sleep-Befehls via Inline-Assembler oder sleep_cpu():<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
// Sleep-Mode "Power-Save" beim ATmega169 "manuell" aktivieren<br />
SMCR = (3<<SM0) | (1<<SE);<br />
asm volatile ("sleep"::); // alternativ sleep_cpu() aus sleep.h<br />
...<br />
</syntaxhighlight><br />
<br />
== Sleep-Modi ==<br />
Die vielen Prozessoren aus der AVR-Familie unterstützen unterschiedliche Sleep-Modi, gefächert nach Vorhandensein von Funktionsblöcken im Controller. Konkrete und verläßliche Auskunft über die tatsächlichen Gegebenheiten finden sich wie immer in den jeweiligen Datenblättern. Die Modi unterscheiden sich darin, welche Funktionsbereiche zum Energiesparen abgeschaltet werden. Davon hängt auch ab, mit welchen Mitteln der Prozessor aus der jeweiligen Schlaftiefe wieder aufgeweckt werden kann.<br />
<br />
;Idle Mode (SLEEP_MODE_IDLE): Die CPU kann durch SPI, USART, Analog Comperator, ADC, TWI, Timer, Watchdog und irgendeinen anderen Interrupt wieder aufgeweckt werden.<br />
<br />
;ADC Noise Reduction Mode (SLEEP_MODE_ADC): In diesem Modus liegt das Hauptaugenmerk darauf, die CPU soweit stillzulegen, dass der ADC möglichst keine Störungen aus dem inneren der CPU auffangen kann, die das Meßergebnis negativ beeinflussen können. Das Aufwachen aus diesem Modus kann ausgelöst werden durch den ADC, externe Interrupts, TWI, Timer und Watchdog.<br />
<br />
;Power-Down Mode (SLEEP_MODE_PWR_DOWN): In diesem Modus wird ein externer Oszillator (Quarz, Quarzoszillator), wenn vorhanden. gestoppt. Geweckt werden kann die CPU durch einen externen Level-Interrupt, TWI, Watchdog, Brown-Out-Reset.<br />
<br />
;Power-Save-Mode (SLEEP_MODE_PWR_SAVE): Power-Save ist identisch zu Power-Down mit einer Ausnahme: Ist der Timer 2 auf die Verwendung eines externen Taktes konfiguriert, so läuft dieser Timer auch im Power-Save weiter und kann die CPU mit einem Interrupt aufwecken.<br />
<br />
;Standby-Mode (SLEEP_MODE_STANDBY, SLEEP_MODE_EXT_STANDBY): Voraussetzung für den Standby-Modus ist die Verwendung eines Quarzes oder eines Quarzoszillators, also einer externen Taktquelle. Ansonsten ist dieser Modus identisch zum Power-Down Modus. Vorteil dieses Modus' ist eine kürzere Aufwachzeit.<br />
<br />
;Abschalten des Brownout Detect (BOD) während der Sleep-Phase (nur P-Typen): Zur Stromersparnis bieten die P-Typen die Möglichkeit den BOD während der Sleep-Phase abzuschalten. Bei einem Atmega88PA beispielsweise, kann dadurch der Stromverbrauch im SLEEP_MODE_PWR_SAVE mit Timer2 im Asynchronmodus mit Uhrenquarz und periodischer Selbstaufweckung um ca. 50% gesenkt werden.<br />
Das Einschalten dieser Funktion geschieht in einer Timed Sequence.<br />
<br />
<syntaxhighlight lang="c"><br />
unsigned char temp0 = MCUCR;<br />
unsigned char temp1 = MCUCR;<br />
temp0 |= (1 << BODS) | (1 << BODSE);<br />
temp1 |= (1 << BODS);<br />
MCUCR = temp0;<br />
MCUCR = temp1;<br />
sleep_cpu();<br />
</syntaxhighlight><br />
<br />
Hierbei ist unbedingt zu beachten, dass das BODS-Bit 3 Takte nach dem Setzen wieder gelöscht wird. Daher muss der Aufruf des Sleep unmittelbar nach dem Setzen erfolgen und das BODS-Bit muss jedes Mal vor einem Sleep Aufruf erneut gesetzt werden.<br />
<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Power Management and Sleep-Modes<br />
* [http://www.mikrocontroller.net/topic/96369#832712 Forenbeitrag] zur "Nichtverwendung" von sleep_mode in ISRs.<br />
<br />
= Zeiger =<br />
Zeiger (engl. ''Pointer'') sind Variablen, die die Adresse von Daten oder Funktionen enthalten und belegen 16 Bits. Die Größe hängt mit dem adressierbaren Speicherbereich zusammen und der GCC reserviert dann den entsprechenden Platz.<br />
Ggf. ist es also günstiger, Indizes auf Arrays (Listen) zu verwenden, so dass der GCC für die Zeigerarithmetik den erforderlichen RAM nur temporär benötigt.<br />
<br />
Siehe auch: [[Zeiger]]<br />
<br />
= Speicherzugriffe =<br />
<br />
Atmel AVR-Controller verfügen typisch über drei Speicher:<br />
<br />
* [[RAM]]: Im RAM (genauer statisches RAM/SRAM) wird vom gcc-Compiler Platz für Variablen reserviert. Auch der Stack befindet sich im RAM. Dieser Speicher ist "flüchtig", d.h. der Inhalt der Variablen geht beim Ausschalten oder einem Zusammenbruch der Spannungsversorgung verloren. Das bedeutet im Umkehrschluss auch, dass der RAM-Inhalt nach RESET vom Pin oder vom Watchdog erhalten bleibt! Der C-Startupcode löscht jedoch den RAM, d.h. setzt alle Bits auf 0. Dadurch erscheinen „normal definierte“ Variablen als 0. Auch Gleitkommazahlen, die schlauerweise so definiert sind, dass eine +0.0 aus lauter Nullbits besteht. Von der Löschung ausschließen kann man RAM-Variablen mit <tt>__attribute__((section(".noinit")))</tt>.<br />
<br />
* Programmspeicher: Ausgeführt als FLASH-Speicher, seitenweise wiederbeschreibbar. Darin ist das Anwendungsprogramm abgelegt.<br />
<br />
* [[EEPROM]]: Nichtflüchtiger Speicher, d.h. der einmal geschriebene Inhalt bleibt auch ohne Stromversorgung erhalten. Byte-weise schreib/lesbar. Im EEPROM werden typischerweise gerätespezifische Werte wie z.&nbsp;B. Kalibrierungswerte von Sensoren abgelegt.<br />
<br />
Einige AVRs besitzen keinen RAM-Speicher, lediglich die Register können als "Arbeitsvariablen"<br />
genutzt werden. Da die Anwendung des avr-gcc auf solch "kleinen" Controllern ohnehin selten sinnvoll ist und auch nur bei einigen RAM-losen Typen nach [http://lightner.net/avr/ATtinyAvrGcc.html "Bastelarbeiten"] möglich ist, werden diese Controller hier nicht weiter berücksichtigt. Auch EEPROM-Speicher ist nicht auf allen Typen verfügbar. Generell sollten die nachfolgenden Erläuterungen auf alle ATmega-Controller und die größeren AT90-Typen übertragbar sein. Für die Typen ATtiny2313, ATtiny26 und viele weitere der "ATtiny-Reihe" gelten die Ausführungen ebenfalls.<br />
<br />
Siehe auch:<br />
* [[Binäre Daten zum Programm hinzufügen]]<br />
== RAM ==<br />
<br />
Die Verwaltung des RAM-Speichers erfolgt durch den Compiler, im Regelfall ist beim Zugriff auf Variablen im RAM nichts Besonderes zu beachten. Die Erläuterungen in jedem brauchbaren C-Buch gelten auch für den vom avr-gcc-Compiler erzeugten Code.<br />
<br />
Um Speicher dynamisch (während der Laufzeit) zu reservieren, kann '''malloc()''' verwendet werden. malloc(size) "alloziert" (~reserviert) einen gewissen Speicherblock mit '''size''' Bytes. Ist kein Platz für den neuen Block, wird NULL (0) zurückgegeben.<br />
<br />
Wird der angelegte Block zu klein (groß), kann die Größe mit realloc() verändert werden. Den allozierten Speicherbereich kann man mit free() wieder freigeben. Wenn das Freigeben eines Blocks vergessen wird spricht man von einem "Speicherleck" (memory leak).<br />
<br />
malloc() legt Speicherblöcke im '''Heap''' an, belegt man zuviel Platz, dann wächst der Heap zu weit nach oben und überschreibt den Stack, und der Controller kommt in Teufels Küche. Das kann leider nicht nur passieren wenn man insgesamt zu viel Speicher anfordert, sondern auch wenn man Blöcke unterschiedlicher Größe in ungünstiger Reihenfolge alloziert/freigibt (siehe Artikel [[Heap-Fragmentierung]]). Aus diesem Grund sollte man malloc() auf Mikrocontrollern sehr sparsam (am besten gar nicht) verwenden.<br />
<br />
Beispiel zur Verwendung von malloc():<br />
<syntaxhighlight lang="c"><br />
#include <stdlib.h><br />
<br />
void foo(void) {<br />
// neuen speicherbereich anlegen,<br />
// platz für 10 uint16<br />
uint16_t* pBuffer = malloc(10 * sizeof(uint16_t));<br />
<br />
// darauf zugreifen, als wärs ein gewohnter Buffer<br />
pBuffer[2] = 5;<br />
<br />
// Speicher (unbedingt!) wieder freigeben<br />
free(pBuffer);<br />
}<br />
</syntaxhighlight><br />
<br />
Wenn (wie in obigem Beispiel) dynamischer Speicher nur für die Dauer einer Funktion benötigt und am Ende wieder freigegeben wird, bietet es sich an, statt malloc() '''alloca()''' zu verwenden. Der Unterschied zu malloc() ist, dass der Speicher auf dem Stack reserviert wird, und beim Verlassen der Funktion automatisch wieder freigegeben wird. Es kann somit kein Speicherleck und keine Fragmentierung entstehen.<br />
<br />
siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/malloc.html AVR Libc Home Page]: Memory Areas and Using malloc()<br />
* [https://www.mikrocontroller.net/topic/479027#5934443 Forumsbeitrag]: RAM Verbrauch auch von lokalen variablen ermitteln<br />
<br />
== Flash mit PROGMEM und pgm_read ==<br />
<br />
→ [http://nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html avr-libc: Doku zu avr/pgmspace.h]<br />
<br />
Ein Zugriff auf Konstanten im Programmspeicher ist mittels avr-gcc erst ab Version 4.7 "transparent" möglich. Um Daten aus dem Flash zu lesen, muss die AVR-Instruktion LPM (''Load from Program Memory'') erzeugt werden, bei Controllern mit mehr als 64kiB Flash auch ELPM.<br />
<br />
Dazu gibt es das AVR-spezifische GCC-Attribut <tt>progmem</tt>, mit dem eine Variablendeklaration im ''static storage''<ref>Variablen der Speicherklasse ''static storage'' haben eine unbegrenzte Lebensdauer. Beispiel für solche Variablen sind globale Variablen, aber auch static-Variablen innerhalb einer Funktion gehören dazu. Beispiele für Variablen, die nicht ''static storage'' sind: auto-Variablen ("normale" lokale Variablen), register-Variablen, durch malloc geschaffene Objekte, etc.</ref> markiert werden kann:<br />
<syntaxhighlight lang="c"><br />
const int value __attribute__((progmem)) = 1;<br />
</syntaxhighlight><br />
<br />
Effekt ist, dass die so markierte Variable nicht im RAM sondern im Flash angelegt wird. Wird durch "normalen" C-Code auf solch eine Variable zugegriffen, wird jedoch aus der gleichen Adresse aus dem RAM gelesen und nicht aus dem Flash! Das ist ein Fehler, den der Compiler aber nicht anzeigt!<br />
<br />
<syntaxhighlight lang="c"><br />
int test = value; // Fehler! PROGMEM Konstanten müssen mit den pgm_read-Funktionen gelesen werden!<br />
</syntaxhighlight><br />
<br />
Zum Lesen aus dem Flash stellt die avr-libc daher zahlreiche Makros zur Verfügung. Zudem wird das Makro <tt>PROGMEM</tt> definiert, das etwas Tipparbeit spart:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
const int value PROGMEM = 1;<br />
</syntaxhighlight><br />
<br />
<tt>progmem</tt> funktioniert im Wesentlichen wie ein Section-Attribut, das die Daten in der Section <tt>.progmem.data</tt> ablegt. Im Gegensatz zum Section-Attribut werden jedoch noch weitere Prüfungen unternommen, ab avr-gcc 4.6 etwa muss die entsprechende Variable <tt>const</tt> sein.<br />
<br />
=== Integer und float ===<br />
<br />
Zum Lesen von Skalaren stellt die avr-libc folgende Makros zu Verfügung, die jeweils ein Argument erhalten: Die 16-Bit Adresse des zu lesenden Wertes<ref>Damit ist der mögliche Speicherbereich für Flash-Konstanten auf 64kiB begrenzt. Einige pgmspace-Funktionen ermöglichen den Lesezugriff auf den gesamten Flash-Speicher, intern via Assembler-Anweisung ELPM. Die Initialisierungswerte des Speicherinhalts jenseits der 64kiB-Marke müssen dann jedoch auf anderem Weg angelegt werden, d.h. nicht per PROGMEM. Evtl. eigene Section und Linker-Optionen. Alt und nicht ganz korrekt: Die avr-libc pgmspace-Funktionen unterstützen nur die unteren 64kiB Flash bei Controllern mit mehr als 64kiB.</ref><br />
<br />
:{| {{Tabelle}}<br />
|+ Übersicht der <tt>pgm_read</tt> Funktionen aus<br/>dem Header <tt>avr/pgmspace.h</tt> der avr-libc<br />
|-<br />
! Gelesener Wert || <tt>pgm_read_xxx</tt> || Anzahl Bytes<br />
|-<br />
| <tt>uint8_t</tt> || <tt>pgm_read_byte</tt> || 1<br />
|-<br />
| <tt>uint16_t</tt> || <tt>pgm_read_word</tt> || 2<br />
|-<br />
| <tt>uint32_t</tt> || <tt>pgm_read_dword</tt> || 4<br />
|-<br />
| <tt>float</tt> || <tt>pgm_read_float</tt><ref>ab avr-libc 1.7.0</ref> || 4<br />
|}<br />
<br />
Soll ein Zeiger gelesen werden, so verwendet man <tt>pgm_read_word</tt> und castet das Ergebnis zum gewünschten Zeiger-Typ.<br />
<br />
;Beispiele:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
/* Byte */<br />
const uint8_t aByte PROGMEM = 123;<br />
<br />
/* int-Array */<br />
const int anArray[] PROGMEM = { 18, 3 ,70 };<br />
<br />
void foo (void)<br />
{<br />
/* Zeiger */<br />
static const uint8_t* const aPointer PROGMEM = &aByte;<br />
<br />
uint8_t a = pgm_read_byte (&aByte);<br />
int a2 = (int) pgm_read_word (&anArray[2]);<br />
const uint8_t* p = (const uint8_t*) pgm_read_word (&aPointer);<br />
}<br />
</syntaxhighlight><br />
<br />
=== Blöcke ===<br />
<br />
In den Flash-Funktionen der avr-libc sind keine der pgm_read_xxxx Nomenklatur folgenden Funktionen, die Speicherblöcke auslesen oder vergleichen. Die enstprechende Funktionen sind Varianten von <tt>memcpy</tt>, <tt>memcmp</tt> und heißt <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, usw. Für weitere Funktionen und deren Prototypen siehe die Dokumentation der avr-libc.<br />
<br />
=== Strings ===<br />
<br />
Strings sind in C nichts anderes als eine Abfolge von Zeichen und einem <tt>'\0'</tt> als Stringende. Der prinzipielle Weg ist daher identisch zum Lesen von Bytes, wobei auf die [[FAQ#Wie funktioniert String-Verarbeitung in C?|Besonderheiten von Strings]] wie 0-Terminierung geachtet werden muss.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
size_t my_string_length (const char *addr)<br />
{<br />
size_t length = 0;<br />
<br />
while (pgm_read_byte (addr++))<br />
{<br />
length++;<br />
}<br />
return length;<br />
}<br />
</syntaxhighlight><br />
<br />
Zur Unterstützung des Programmierers steht das Repertoire der str-Funktionen auch in jeweils eine Variante zur Verfügung, die mit dem Flash-Speicher arbeiten kann. Die Funktionsnamen tragen den Suffix <tt>_P</tt>. Darüber hinaus gibt es das Makro <tt>PSTR</tt>, das ein String-Literal im Flash-Speicher ablegt und die Adresse des Strings liefert:<br />
<br />
Die nachfolgende Funktion liefert 0 zurück, wenn string_im_ram gleich "Hallo Welt" ist. Mit strcmp (String Compare) können wir zwei Strings vergleichen. Der Rückgabewert kann hierbei folgende Werte haben:<br><br />
0 die Strings sind gleich<br />
>0 das erste ungleiche Zeichen in string_im_ram ist größer als in "Hallo Welt"<br />
<0 das erste ungleiche Zeichen in string_im_ram ist kleiner als in "Hallo Welt"<br />
<br><br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
int foo (const char *string_im_ram)<br />
{<br />
return strcmp_P (string_im_ram, PSTR ("Hallo Welt"));<br />
}<br />
</syntaxhighlight><br />
<br />
Zu beachten ist, dass <tt>PSTR</tt> nur innerhalb von Funktionen verwendet werden kann.<br />
<br />
; Array aus Strings:<br />
<br />
Arrays aus Strings im Flash-Speicher werden in zwei Schritten angelegt:<br />
<br />
# Zuerst die einzelnen Elemente des Arrays und<br />
# im Anschluss ein Array, in dem die Startaddressen der Strings abgelegt werden.<br />
<br />
Zum Auslesen wird zuerst die Adresse des gewünschten Elements aus dem Array im Flash-Speicher gelesen, die im Anschluss dazu genutzt wird, um auf das Element (den String) selbst zuzugreifen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
static const char str1[] PROGMEM = "Hund";<br />
static const char str2[] PROGMEM = "Katze";<br />
static const char str3[] PROGMEM = "Maus";<br />
<br />
const char * const array[] PROGMEM = <br />
{<br />
str1, str2, str3<br />
};<br />
<br />
// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]<br />
void read_string (char *buf, size_t i)<br />
{<br />
// Lese die Adresse des i-ten Strings aus array[]<br />
const char *parray = (const char*) pgm_read_ptr (&array[i]);<br />
<br />
// Kopiere den Inhalt der Zeichenkette vom Flash ins RAM<br />
strcpy_P (buf, parray);<br />
}<br />
</syntaxhighlight><br />
<br />
Eine weitere Möglichkeit ist, die Strings in einem 2-dimensionalen char-Array abzulegen anstatt deren Adresse in einem 1-dimensionalen Adress-Array zu speichern.<br />
<br />
Vorteil ist, dass der Code einfacher wird. Nachteil ist, dass bei unterschiedlich langen Strings Speicherplatz verschwendet wird, weil sich die Array-Dimension and der Länge des längsten Strings orientieret. Bei in etwa gleich langen Strings kann es aber sogar Speicherplatz sparen, denn es die Adressen der einzelnen Strings müssen nicht abgespeichert werden.<ref>In unserem Hund-Katze-Maus Beispiel belegt die erste Variante 22 Bytes Daten und 18 Bytes Code, die zweite Variante mit 2-dimensionalem Array belegt 18 Bytes Daten und 20 Bytes Code. Gemessen wurde mit avr-gcc 4.8 -Os für ATmega8.</ref><br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
// Die "6" ist 1 plus die Länge des längsten Strings ("Katze")<br />
const char array[][6] PROGMEM = <br />
{<br />
"Hund", "Katze", "Maus"<br />
};<br />
<br />
// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]<br />
void read_string (char *buf, size_t i)<br />
{<br />
// Kopiere den Inhalt der i-ten Zeichenkette vom Flash ins RAM<br />
strcpy_P (buf, array[i]);<br />
}<br />
</syntaxhighlight><br />
<br />
Siehe dazu auch die avr-libc FAQ: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_rom_array How do I put an array of strings completely in ROM?]<br />
<br />
=== Warum so kompliziert? ===<br />
<br />
Zu dem Thema, warum die Verabeitung von Werten aus dem Flash-Speicher so kompliziert ist, sei hier nur kurz erläutert: Die Harvard-Architektur des AVR weist getrennte Adressräume für Programm (Flash) und Datenspeicher (RAM) auf. Der C-Standard sieht keine unterschiedlichen Adressräume vor.<br />
<br />
Hat man zum Beispiel eine Funktion string_an_uart (const char* s) und übergibt an diese Funktion die Adresse einer Zeichenkette, dann weiß die Funktion nicht, ob die Adresse in den Flash-Speicher oder das RAM zeigt. Weder aus dem Pointer-Wert, also dem Zahlenwert, noch aus dem "const" kann auf den Ort der Ablage geschlossen werden.<br />
<br />
Einige AVR-Compiler bilden die Harvard-Architektur ab, indem sie in einen Pointer nicht nur die Adresse speichern, sondern auch den Ablageort wie ''Flash'' oder ''RAM''. In einem Aufruf einer Funktion wird dann bei Pointer-Parametern neben der Adresse auch der Speicherbereich, auf den der Pointer zeigt, übergeben.<br />
<br />
Dies hat jedoch auch Nachteile, denn bei jedem Zugriff über einen Zeiger muss zur ''Laufzeit'' entschieden werden, wie der Zugriff auszuführen ist und entsprechend länglicher und langsamer wird der erzeugte Code.<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitte Modules/Program Space String Utilities und Abschnitt Modules/Bootloader Support Utilities<br />
<br />
=== Datenzugriff jenseits 64 KiB ===<br />
<br />
Die Zeiger beim <tt>avr-gcc</tt> sind stets 16 Bit breit, können somit also nur 64 KiB Datenspeicher adressieren. Darauf sind auch alle Funktion der libc ausgelegt, welche auf _P enden. Funktionszeiger können beim AVR bis zu 128 KiB Programmspeicher adressieren, weil Funktionsadressen immer 16-Bit-<u>Worte</u> adressieren und nicht Bytes. Der Zugriff auf den RAM ist mit maximal 16 KiB (extern maximal 64 KiB) durch 16-Bit-Zeiger nicht begrenzt.<br />
<br />
Schlauerweise sortiert <tt>avr-gcc</tt> Flash-Konstanten und -Tabellen <i>so</i> um, dass sie an den Anfang des Flash-Speichers, gleich nach der Interrupt-Tabelle, zu liegen kommen. Somit kommt man auch auf Controllern mit mehr als 64 KByte Flash im Normalfall keine Adresse jenseits 64 KiByte erforderlich.<br />
<br />
<small>Genauso lassen sich auf Controllern mit mehr als 128 KiB Flash alle Funktionen <i>so</i> umordnen, dass solche, von denen <i>Funktionszeiger</i> benötigt werden (auch: virtuelle Methoden, tabellenoptimierte <tt>switch/case</tt>-Anweisungen), in die „unteren“ 128 KiB zu liegen kommen.</small><br />
<br />
Um (dennoch) Zugriff jenseits von 64 KiB zu bewerkstelligen gibt es mehrere Möglichkeiten:<br />
<br />
* Address-Spaces wie <tt>__flash1</tt> oder <tt>__memx</tt>, siehe Abschnitt "[[#Jenseits von flash|Jenseits von __flash]]".<br />
* Die Funktionen bzw. Makros <tt>pgm_read_xxx_far</tt> der AVR-Libc ab Version 1.8.0, wie im folgenden beschrieben. Dafür gibt es die Funktion pgm_get_far_address(), um 32-Bit Pointer eines Objekts zu erhalten<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/pgmspace.h><br />
<br />
//===================================================================<br />
// Define an additional section, which will be placed after all others<br />
//--------------------------------------------------------------------<br />
#define FAR_SECTION __attribute__((__section__(".far_section")))<br />
//--------------------------------------------------------------------<br />
<br />
//====================================================================<br />
// Just an example<br />
//====================================================================<br />
<br />
const char MyString[] FAR_SECTION = "Hier liegt mein FAR-Teststring!";<br />
const char MyBmp64[] FAR_SECTION = {0xAA,0xBB,0xCC,0xDD,0xEE,0xFF,0x00};<br />
<br />
int main(void) {<br />
uint32_t ptr = pgm_get_far_address(MyString);<br />
char MyChar;<br />
DDRC = 0xFF;<br />
do {<br />
MyChar = pgm_read_byte_far(ptr++);<br />
PORTC = MyChar;<br />
} while(MyChar);<br />
}<br />
</syntaxhighlight><br />
<br />
D.h. man muss<br />
* Die Definition der neuen Section <tt>FAR_SECTION</tt> einfügen<br />
* Die konstanten Daten mit dieser Section kennzeichnen<br />
<br />
Dem Linker muss man über diese Section nichts mitteilen, er fügt diese automatisch nach allen bestehenden sections im Flash ein. Der Zugriff auf diese Variablen kann nur mittels direkter Pointerarithmetik erfolgen, eine Indizierung von Arrays mit variablem Index ist nicht möglich. Dabei muss die Größe des Datentyps immer manuell berücksichtigt werden, denn der Pointer ist immer ein Bytepointer!<br />
<br />
<syntaxhighlight lang="c"><br />
int n=3;<br />
MyChar = pgm_read_byte_far(pgm_get_far_address(MyBmp64)+n*sizeof(char));<br />
</syntaxhighlight><br />
<br />
Dabei gibt es einige praktische Probleme.<br />
* Beim recht alten AVR-Studio 4.18 wird die Größe des belegten FLASH-Speichers nicht korrekt angezeigt, die Daten landen aber im HEX-File.<br />
* beim moderneren Atmelstudio 6.2 sieht man in der Consolenausgabe die richtige Größe, welche von avr-size ermittelt wurde, diese wird aber dann in der 2. Ausgabe durch Atmelstudio falsch dargestellt<br />
* Die Arduino-IDE rechnet richtig, siehe dieser [https://www.mikrocontroller.net/topic/511511?goto=6568945#6568945 Forumsbeitrag].<br />
<br />
== Flash mit __flash und Embedded-C ==<br />
<br />
Ab Version 4.7 unterstützt avr-gcc ''Adress-Spaces'' gemäß dem Embedded-C Dokument ISO/IEC TR18037. Der geläufigste Adress-Space ist <tt>__flash</tt>, der im Gegensatz zu <tt>progmem</tt> kein GCC-Attribut ist, sondern ein Qualifier und damit syntaktisch ähnlich verwendet wird wie <tt>const</tt> oder <tt>volatile</tt>.<br />
<br />
GCC kennt keine eigene Option zum Aktivieren von Embedded-C, es wird als GNU-C Erweiterung behandelt. Daher müssen C-Module, die Address-Spaces verwenden, mit <tt>-std=gnu99</tt> o.ä. compiliert werden.<br />
<br />
<syntaxhighlight lang="c"><br />
static const __flash int value = 10;<br />
<br />
int get_value (void)<br />
{<br />
return value;<br />
}<br />
</syntaxhighlight><br />
<br />
# Im Gegensatz zu <tt>progmem</tt> sind keine speziellen Bibliotheksfunktionen oder -makros für den Zugriff mehr notwendig: Der Code zum Lesen der Variable ist "normales" C.<br />
# Die Variable wird im richtigen Speicherbereich (Flash) angelegt.<br />
# <tt>__flash</tt> ist nur zusammen mit read-only Objekten oder Zeigern, d.h. nur zusammen mit <tt>const</tt>, erlaubt.<br />
# Zugriffe wie im obigen Beispiel können (weg)optimiert werden. Das Beispiel entspricht einem "<tt>return 10</tt>". Es besteht keine Notwendigkeit, für <tt>value</tt> überhaupt Flash-Speicher zu reservieren.<br />
<br />
Auch Zeiger-Indirektionen sind problemlos möglich. Zu beachten ist, dass <tt>__flash</tt> auf der richtigen Seite des "<tt>*</tt>" in der Zeigerdeklaration bzw. -definition steht:<br />
* '''Rechts vom <tt>*</tt>:''' Der Zeiger selbst liegt im Flash<br />
* '''Links vom <tt>*</tt>:''' Der Zeiger enthält eine Flash-Adresse<br />
<br />
<syntaxhighlight lang="c"><br />
// val ist eine Variable im Flash<br />
const __flash int val = 42;<br />
<br />
// pval liegt auch im Flash und enthält die Adresse von val<br />
const __flash int* const __flash pval = &val;<br />
<br />
int get_val (void)<br />
{<br />
// liest den Wert von val über die in pval abgelegte Adresse<br />
return *pval;<br />
}<br />
</syntaxhighlight><br />
<br />
=== Blöcke ===<br />
<br />
Um Speicherbereiche vom Flash in den RAM zu kopieren, gibt es zwei Möglichkeiten: Zum einen können wie bei <tt>progmem</tt> beschreiben die Funktionen der avr-libc wie <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, <tt>movmem_P</tt>, etc. verwendet werden:<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
// Eine Datenstruktur<br />
typedef struct<br />
{<br />
int id;<br />
char buf[10];<br />
} data_t;<br />
<br />
extern void uart_send (const void*, size_t);<br />
<br />
void send_data (const __flash data_t *pdata)<br />
{<br />
// buf wird auf dem Stack angelegt<br />
data_t buf;<br />
<br />
// Kopiere Daten vom Flash nach buf ins RAM<br />
memcpy_P (&buf, pdata, sizeof (data_t));<br />
<br />
// Sende die Daten in buf<br />
uart_send (&buf, sizeof (data_t));<br />
}<br />
</syntaxhighlight><br />
<br />
Zum anderen kann eine Struktur auch über direktes Kopieren ins RAM geladen werden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdlib.h><br />
<br />
// Eine Datenstruktur<br />
typedef struct<br />
{<br />
int id;<br />
char buf[10];<br />
} data_t;<br />
<br />
extern void uart_send (const void*, size_t);<br />
<br />
void send_data (const __flash data_t *pdata)<br />
{<br />
// Kopiere Daten ins RAM. buf wird auf dem Stack angelegt<br />
const data_t buf = *pdata;<br />
<br />
// Verwendet die Daten in buf<br />
uart_send (&buf, sizeof (data_t));<br />
}<br />
</syntaxhighlight><br />
<br />
=== Strings ===<br />
<br />
Natürlich können auch Strings im Flash abgelegt werden und auch mit Funktionen wie <tt>strcpy_P</tt> aus der avr-libc verarbeitet werden. Zudem ist es möglich, Flash-Zeiger mit der Adresse eines String-Literals zu initialisieren:<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
#define FSTR(X) ((const __flash char[]) { X } )<br />
<br />
const __flash char * const __flash array[] = <br />
{<br />
FSTR ("Hund"), FSTR ("Katze"), FSTR ("Maus")<br />
};<br />
<br />
size_t get_len (uint8_t tier)<br />
{<br />
return strlen_P (array[tier]);<br />
}<br />
</syntaxhighlight><br />
<br />
Leider sieht der Embedded-C Draft nicht vor, String-Literale direkt in einem anderen Adress-Space als ''generic'' anzulegen, so dass hier der Umweg über <tt>FSTR</tt> genommen werden muss. Dieses Konstrukt ist nur ausserhalb von Funktionen möglich und kann daher nicht als Ersatz für <tt>PSTR</tt> aus der avr-libc dienen.<br />
<br />
Soll <tt>array</tt> ein 2-dimensonales Array sein anstatt ein 1-dimensionales Array von Zeigern, dann geht das ohne große Verrenkungen:<br />
<br />
<syntaxhighlight lang="c"><br />
// Die 6 ergibt sich aus 1 plus der Länge des längsten Strings "Katze"<br />
const __flash char array[][6] = <br />
{<br />
"Hund", "Katze", "Maus"<br />
};<br />
</syntaxhighlight><br />
<br />
Weiters besteht die Möglichkeit, <tt>array</tt> analog anzulegen, wie man es mit <tt>PROGMEM</tt> machen würde: Jeder String wird explizit angelegt und seine Adresse bei der Initialisierung von <tt>array</tt> verwendet. Dies entspricht dem ersten Beispiel eines 1-dimensionalen Zeigerarrays:<br />
<br />
<syntaxhighlight lang="c"><br />
static const __flash char strHund[] = "Hund";<br />
static const __flash char strKatze[] = "Katze";<br />
static const __flash char strMaus[] = "Maus";<br />
<br />
const __flash char * const __flash array[] = <br />
{<br />
strHund, strKatze, strMaus<br />
};<br />
</syntaxhighlight><br />
<br />
=== Casts ===<br />
<br />
Embedded C fordert, dass zwei Adress-Spaces entweder disjunkt sind – d.h. sie enthalten keine gemeinsamen Adressen – oder aber ein Space komplett im anderen enthalten ist, also eine Teilmengen-Beziehung besteht. Die Adress-Spaces von avr-gcc sind so implementiert, dass jeder Space Teilmenge jedes anderes ist. Zwar haben Spaces wie RAM und Flash physikalisch keinen Speicherbereich gemein, allerdings ermöglicht diese Implementierung das Casten von Zeigern zu unterschiedlichen Adress-Spaces<ref>Im Gegensatz zu einem Attribute wie <tt>progmem</tt> ist ein (Adress Space) Qualifier Teil des Zeiger-Typs.</ref>: <br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdbool.h><br />
<br />
char read_char (const char *address, bool data_in_flash)<br />
{<br />
if (data_in_flash)<br />
return *(const __flash char*) address;<br />
else<br />
return *address;<br />
}<br />
</syntaxhighlight><br />
<br />
Der Cast selbst erzeugt keinen zusätzlichen Code, da eine RAM-Adresse und eine Flash-Adresse die gleiche Binärdarstellung haben. Allerdings wird über den nach <tt>__flash</tt> gecasteten Zeiger anders zugegriffen, nämlich per LPM.<br />
<br />
=== Jenseits von __flash ===<br />
<br />
Ausser <tt>__flash</tt> gibt es auch folgende Address-Spaces:<br />
<br />
==== <tt>__flash</tt>''N'' ====<br />
<br />
<tt>__flash</tt>''N'' mit ''N'' = 1..5 sind fünf weitere Spaces, die analog zu <tt>__flash</tt> funktionieren und deren Zeiger ebenfalls 16 Bit breit sind. avr-gcc erwartet, dass die zugehörigen Daten, welche in die Section <tt>.progmem</tt>''N''<tt>.data</tt> abgelegt werden, so lokatiert sind, dass das high-Byte der Adresse (Bits 16..23) gerade ''N'' ist.<br />
<br />
Weil Daten- und Code-Layout höchst projektspezifisch sind, werden diese Sections im Standard Linker-Skript nicht beschrieben. Um funktionsfähigen Code zu erhalten, muss daher ein eigenes Linker-Skript zur Verfügung gestellt werden, das diese Sections beschreibt, oder es kann eine Erweiterung des Standard Skripts bereitgestellt werden falls dies möglich ist.<br />
<br />
;Beispiel: Eine Applikation, die <tt>__flash2</tt> verwendet. Die zugehörende Section <tt>.progmem2.data</tt> wird hinter <tt>.text</tt> angeordnet aber vor den Initializern für <tt>.data</tt>. Dazu wird beim Linken das ld-Skript Fragment per <tt>-Tflash12.ld</tt> angegeben, welches dann an der gewünschten Stelle in das default Skript eingefügt wird:<br />
:{| <!-- Tabelle bitte für korrekte Einrückung belassen --><br />
|-<br />
|<pre><br />
SECTIONS<br />
{<br />
.flash2 :<br />
{<br />
. = MAX (ABSOLUTE(0x20000), .);<br />
PROVIDE (__flash2_start = .);<br />
. = ALIGN(2);<br />
*(.flash2.text*)<br />
*(.progmem2.data*)<br />
PROVIDE (__flash2_end = .);<br />
<br />
ASSERT (__flash2_start == __flash2_end || __flash2_start >= ABSOLUTE(0x20000),<br />
"__flash2 data in .progmem2.data below 0x20000");<br />
ASSERT (__flash2_start == __flash2_end || __flash2_end <= ABSOLUTE(0x30000),<br />
"__flash2 data in .progmem2.data exceeds 0x30000");<br />
}<br />
}<br />
INSERT AFTER .text<br />
</pre><br />
|}<br />
<br />
==== <tt>__memx</tt> ====<br />
<br />
Dieser Address-Space implementiert 3-Byte Zeiger und unterstützt Lesen über 64KiB-Segmentgrenzen hinweg. Das MSB (Bit 23) gibt dabei an, ob der <tt>__memx</tt>-Zeiger eine Flash-Adresse enthält (Bit23 = 0) oder eine RAM-Adresse (Bit23 = 1), was folgenden Code erlaubt:<br />
<br />
<syntaxhighlight lang="c"><br />
const __memx int a_flash = 42;<br />
const int a_ram = 100;<br />
<br />
int get_a (const __memx int* pa)<br />
{<br />
return *pa;<br />
}<br />
<br />
int main (void)<br />
{<br />
return get_a (&a_flash) + get_a (&a_ram);<br />
}</syntaxhighlight><br />
<br />
Dies bedeutet, dass erst zur ''Laufzeit'' entschieden werden kann, ob <tt>get_a</tt> die Daten aus dem RAM oder aus dem Flash lesen soll, was <tt>__memx</tt> im Vergleich zu den anderen Address-Spaces langsamer macht. Ausserdem ist zu beachten, dass <tt>__memx</tt>-Zeiger zwar 24-Bit Zeiger sind, die zugrundeliegende Adress-Arithmetik jedoch gemäß dem C-Standard erfolgt, also als 16-Bit Arithmetik. Bestehende Funktion der avr-libc wie z.B. printf_P funktionieren damit ebensowenig wie printf! Wenn man <tt>__memx</tt> verwenden will, braucht man dafür eigene Funktionen.<br />
<br />
=== __flash, progmem und Portierbarkeit ===<br />
<br />
Da ab er aktuellen Compilerversion 4.7 sowohl <tt>__flash</tt> als auch <tt>PROGMEM</tt> und die <tt>pgm_read</tt>-Funktionen zur Verfügung stehen, ergibt sich die Frage, welche Variante "besser" ist und wie zwischen ihnen hin- und her zu portieren ist.<br />
<br />
Zunächst sei erwähnt, dass <tt>__flash</tt> kein Ersatz für <tt>PROGMEM</tt> ist, sondern lediglich eine Alternative dazu. Das "alte" progmem wird weiterhin mir gleicher Semantik unterstützt, so dass alter Code ohne Änderungen mit den neueren Compilerversionen übersetzbar bleibt.<br />
<br />
Von der Codegüte her dürften sich keine großen Unterschiede ergeben. Es ist nicht zu erwarten, dass die eine oder die andere Variante wesentlich besseren oder schlechteren Code erzeugt — von einer Ausnahme abgesehen: Der Wert beim Zugriff ist zur Compilezeit bekannt und kann daher eliminiert werden.<br />
<syntaxhighlight lang="c"><br />
static const __flash char x[] = { 'A', 'V', 'R' };<br />
<br />
char foo (void)<br />
{<br />
return x[2];<br />
}<br />
</syntaxhighlight><br />
Dies wird übersetzt wie "<tt>return 'R';</tt>", und das Array <tt>x[]</tt> kann komplett wegoptimiert werden und entfallen.<br />
<br />
==== progmem → __flash ====<br />
<br />
Portierung in diese Richtung bedeutet, alten Code anzupassen. Zwingend ist die Portierung nicht, da <tt>progmem</tt> weiterhin unterstützt wird.<br />
Allerdings ist eine Quelle mit <tt>__flash</tt> besser lesbar, denn der Code wird von den <tt>pgm_read</tt>-Funktionen befreit, die vor allem bei Mehrfach-Indirektion den Code ziemlich verunstalten und unleserlich machen können.<br />
Weiterer Vorteil von <tt>_flash</tt> ist, daß eine striktere Typprüfung erfolgen kann.<br />
<br />
Eine Portierung wird man in zwei Schritten vornehmen:<br />
<br />
;1. Definitionen von Flash-Variablen werden angepasst:<br />
<br />
Vorher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
static const char hund[] PROGMEM = "Hund";<br />
static const char katze[] PROGMEM = "Katze";<br />
static const char maus[] PROGMEM = "Maus";<br />
<br />
const char * const tier[] PROGMEM = <br />
{<br />
hund, katze, maus<br />
};<br />
</syntaxhighlight><br />
|}<br />
<br />
Nachher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
static const __flash char hund[] = "Hund";<br />
static const __flash char katze[] = "Katze";<br />
static const __flash char maus[] = "Maus";<br />
<br />
const __flash char * const __flash tier[] = <br />
{<br />
hund, katze, maus<br />
};<br />
</syntaxhighlight><br />
|}<br />
<br />
Der Header <tt>avr/pgmspace.h</tt> wird nicht mehr benötigt. Im Gegensatz zu <tt>progmem</tt> müssen Qualifier immer links von der definierten Variablen stehen; bei Attributen wie <tt>progmem</tt> ist das mehr oder weniger egal.<br />
<br />
Nachdem diese Anpassung erfolgreich abgeschlossen ist, folgt Schritt<br />
<br />
; 2. Der Code wird von <tt>pgm_read</tt>-Aufrufen bereinigt:<br />
<br />
Vorher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
extern const char *tier[];<br />
<br />
char first_letter (uint8_t i)<br />
{<br />
const char* ptier = (const char*) pgm_read_word (&tier[i]);<br />
return (char) pgm_read_byte (&ptier[0]);<br />
}<br />
</syntaxhighlight><br />
|}<br />
<br />
Nachher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <stdint.h><br />
<br />
extern const __flash char * const __flash tier[];<br />
<br />
char first_letter (uint8_t i)<br />
{<br />
return tier[i][0];<br />
}<br />
</syntaxhighlight><br />
|}<br />
<br />
=== Von-Neumannisierung „zu Fuß“ ===<br />
<br />
„Wenn der Prophet nicht zum Berg geht, muss der Berg zum Propheten kommen“.<br />
<br />
Bei Mikrocontrollern mit weniger als 64 KiB Gesamtspeicher ist das mit dem <tt>__flash</tt> oder <tt>PROGMEM</tt> nicht nur lästig sondern erfordert eine Vielzahl von Bibliotheksfunktionen (hier: die auf _P enden) die alle fast dasselbe machen.<br />
<br />
Neuere PIC-Mikrocontroller sowie (limitiert auf LPM) AVR xMegas verfügen bereits über eine Von-Neumannisierung von RAM und Flash in Hardware, nur bei AVRs „will der Prophet nicht zum Berg“, da geht das nicht.<br />
<br />
Hier behilft man sich mit einem Satz aus Inline-Funktionen und Makros, die je nach Bit 15 des Zeigers RAM oder Flash lesen. So setzen die Makros <tt>F(x)</tt> (x als String-Konstante) bzw, <tt>FP(x)</tt> (x als Flash-Adresse) das Bit 15 der Adresse. Die darauf ausgerichtete Bibliotheksfunktion (bspw. ein selbst geschriebener <tt>printf()</tt>-Ersatz) verarbeitet dann den Formatstring aus RAM oder Flash und kommt auch mit <tt>"%s"</tt>-Substitutionen problemlos zurecht.<br />
<br />
== Dateien direkt im Flash einbinden ==<br />
<br />
Wenn man größere Dateien direkt im Programm einbinden will, ohne sie vorher in C Quelltext umzuwandeln, muss man das mit dem Linker machen. Wie das geht steht hier.<br />
<br />
* [http://www.atmel.com/webdoc/avrlibcreferencemanual/FAQ_1faq_binarydata.html Atmel, avr gcc Dokumentation]<br />
* [http://nongnu.org/avr-libc/user-manual/FAQ.html#faq_binarydata Nongnu avr gcc Dokumentation]<br />
<br />
Wie man das dann praktisch umsetzt, sieht man in diesem Beitrag.<br />
<br />
* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056910 Forumsbeitrag]: Binärdateien mittels Linker einbinden<br />
* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056947 Forumsbeitrag]: Ein kleines Tool zum Umwandeln von Binärdateien in C-Quelltext.<br />
<br />
== Flash in der Anwendung schreiben ==<br />
<br />
Bei AVRs mit "self-programming"-Option – auch bekannt als [[Bootloader]]-Support – können Teile des Flash-Speichers vom Anwendungsprogramm beschrieben werden. Dies ist nur möglich, wenn die Schreibfunktion in einem besonderen Speicherbereich, der Boot-Section des Programmspeichers/Flash, abgelegt ist.<br />
<br />
Bei einigen kleinen AVRs gibt es keine gesonderte Boot-Section, bei diesen kann der Flashspeicher von jeder Stelle des Programms geschrieben werden. Für Details sei hier auf das jeweilige Controller-Datenblatt und die Erläuterungen zum Modul boot.h der avr-libc verwiesen. Es existieren auch Application-Notes dazu bei atmel.com, die auf avr-gcc-Code übertragbar sind.<br />
<br />
Siehe auch: <br />
* Forumsbeitrag [http://www.mikrocontroller.net/topic/163632#1561622 Daten in Programmspeicher speichern]<br />
<br />
== EEPROM ==<br />
<br />
Möchte man Werte aus einem Programm heraus so speichern, dass sie auch nach dem Abschalten der Versorgungsspannung noch erhalten bleiben und nach dem Wiederherstellen der Versorgungsspannung bei erneutem Programmstart wieder zur Verfügung stehen, dann benutzt man das EEPROM.<br />
<br />
Schreib- und Lesezugriffe auf den EEPROM-Speicher erfolgen über die im Modul eeprom.h der avr-libc definierten Funktionen. Mit diesen Funktionen können einzelne Bytes, Datenworte (16 Bit), Fließkommawerte (32 Bit, single-precision, float) und Datenblöcke geschrieben und gelesen werden.<br />
<br />
Diese Funktionen kümmern sich auch um diverse Details, die bei der Benutzung des EEPROMs normalerweise notwendig sind:<br />
* EEPROM-Operationen sind im Vergleich relativ langsam. Man muss daher darauf achten, dass eine vorhergehende Operation abgeschlossen ist, ehe die nächste Operation mit dem EEPROM gestartet wird. Die in der avr-libc implementierten Funktionen aus eeprom.h berücksichtigten dies. Soll beim Aufruf einer EEPROM-Funktion sichergestellt werden, dass diese nicht intern in einer Warteschleife auf den Abschluss der vorherigen Operation wartet, kann vorher per eeprom_is_ready testen, ob der Zugriff auf den EEPROM-Speicher sofort möglich ist.<br />
* Es ist darauf zu achten, dass die EEPROM-Funktionen nicht durch einen Interrupt unterbrochen werden. Einige Phasen des Zugriffs sind zeitkritisch und müssen in einer definierten bzw. begrenzten Anzahl von Takten durchgeführt werden. Durch einen unterbrechenden Interrupt würde diese Restriktion nicht mehr eingehalten. Auch dieses Detail wird von den avr-libc Funktionen berücksichtigt, so dass man sich als C-Programmierer nicht darum kümmern muss. Innerhalb der Funktionen werden Interrupts vor der "EEPROM-Sequenz" global deaktiviert und im Anschluss, falls vorher auch schon eingeschaltet, wieder aktiviert.<br />
<br />
Man beachte, dass der EEPROM-Speicher nur eine begrenzte Anzahl von Schreibzugriffen zulässt. Beschreibt man eine EEPROM-Zelle öfter als die im Datenblatt zugesicherte Anzahl (typisch 100.000), wird die Funktion der Zelle nicht mehr garantiert. Dies gilt für jede einzelne Zelle. <br />
<br />
Bei geschickter Programmierung (z.&nbsp;B. Ring-Puffer), bei der die zu beschreibenden Zellen regelmäßig gewechselt werden, kann man eine deutlich höhere Anzahl an Schreibzugriffen, bezogen auf den gesamten EEPROM-Speicher, erreichen. Auf jeden Fall sollte man aber eine Abschätzung über die zu erwartende Lebensdauer des EEPROM durchführen. Wird ein Wert im EEPROM im Durchschnitt nur einmal pro Woche verändert, wird die garantierte Anzahl der Schreibzyklen innerhalb der voraussichtlichen Verwendungszeit des Controllers sicherlich nicht erreicht werden. Welcher Controller ist schon 100000 / 52 = 1923 Jahre im Einsatz? In diesem Fall lohnt es sich daher nicht, erweiterte Programmfunktionen zu implementieren, mit denen die Anzahl der Schreibzugriffe minimiert wird.<br />
<br />
Eine weitere Möglichkeit, Schreibzyklen einzusparen, besteht in der Vorabprüfung, ob der zu speichernde Wert im EEPROM bereits enthalten ist und nur veränderte Werte zu schreiben. In aktuelleren Versionen der avr-libc sind bereits Funktionen enthalten, die solche Prüfungen enthalten (eeprom_update_*).<br />
<br />
Eine dritte Möglichkeit speichert alle Daten zunächst im RAM, wo sie beliebig oft beschrieben werden können. Nur beim Ausschalten oder beim Ausfall der Stromversorgung werden die Daten in den EEPROM geschrieben. Wie man das richtig macht sieht man im Artikel [[Speicher#EEPROM Schreibzugriffe minimieren | Speicher]].<br />
<br />
Lesezugriffe können beliebig oft durchgeführt werden. Sie unterliegen keinen Einschränkungen in Bezug auf deren Anzahl. <br />
<br />
=== EEMEM ===<br />
Um eine Variable im EEPROM anzulegen, stellt die avr-libc das Makro EEMEM zur Verfügung:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdint.h><br />
#include <avr/eeprom.h><br />
<br />
/* Byte */<br />
uint8_t eeFooByte EEMEM = 123;<br />
<br />
/* Wort */<br />
uint16_t eeFooWord EEMEM = 12345;<br />
<br />
/* float */<br />
float eeFooFloat EEMEM;<br />
<br />
/* Byte-Array */<br />
uint8_t eeFooByteArray1[] EEMEM = { 18, 3, 70 };<br />
uint8_t eeFooByteArray2[] EEMEM = { 30, 7, 79 };<br />
<br />
/* 16-bit unsigned short feld */<br />
uint16_t eeFooWordArray1[4] EEMEM;<br />
</syntaxhighlight><br />
<br />
Die grundsätzliche Vorgehensweise ist identisch zur Verwendung von PROGMEM. Auch hier erzeugt man sich spezielle attributierte Variablen (EEMEM erledigt das), die vom Compiler/Linker nicht wie normale Variablen behandelt werden. Compiler/Linker kümmern sich zwar darum, dass diesen Variablen eine Adresse zugewiesen wird, diese Adresse ist dann aber die Adresse der 'Variablen' im EEPROM. Um die dort gespeicherten Werte zu lesen bzw. zu schreiben, übergibt man diese Adresse an spezielle Funktionen, die die entsprechenden Werte aus dem EEPROM holen bzw. das EEPROM neu beschreiben.<br />
<br />
Die mittels EEMEM erzeugten 'Variablen' sind also mehr als Platzhalter zu verstehen, denn als echte Variablen. Es geht nur darum, im C-Programm symbolische Namen zur Verfügung zu haben, anstatt mit echten EEPROM-Adressen hantieren zu müssen, etwas, das grundsätzlich aber auch genauso gut möglich ist. Nur muss man sich in diesem Fall dann selbst darum kümmern, dass mehrere 'Variablen' ohne Überschneidung im EEPROM angeordnet werden.<br />
<br />
=== Bytes lesen/schreiben ===<br />
<br />
Die avr-libc Funktion zum Lesen eines Bytes heißt eeprom_read_byte. Parameter ist die Adresse des Bytes im EEPROM. Geschrieben wird über die Funktion eeprom_write_byte mit den Parametern Adresse und Inhalt. Anwendungsbeispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#define EEPROM_DEF 0xFF<br />
<br />
void eeprom_example (void)<br />
{<br />
uint8_t myByte;<br />
<br />
// myByte lesen (Wert = 123)<br />
myByte = eeprom_read_byte (&eeFooByte);<br />
<br />
// der Wert 99 wird im EEPROM an die Adresse der<br />
// Variablen eeFooByte geschrieben<br />
myByte = 99;<br />
eeprom_write_byte(&eeFooByte, myByte); // schreiben<br />
<br />
myByte = eeprom_read_byte (&eeFooByteArray1[1]); <br />
// myByte hat nun den Wert 3<br />
<br />
// Beispiel fuer eeprom_update_byte: die EEPROM-Zelle wird nur<br />
// dann beschrieben, wenn deren Inhalt sich vom Parameterwert<br />
// unterscheidet. In diesem Beispiel erfolgt also kein Schreib-<br />
// zugriff, da die Werte gleich sind.<br />
eeprom_update_byte(&eeFooByte, myByte);<br />
<br />
<br />
// Beispiel zur "Sicherung" gegen leeres EEPROM nach "Chip Erase"<br />
// (z. B. wenn die .eep-Datei nach Programmierung einer neuen Version<br />
// des Programms nicht in den EEPROM uebertragen wurde und EESAVE<br />
// deaktiviert ist (unprogrammed/1)<br />
// <br />
// Vorsicht: wenn EESAVE "programmed" ist, hilft diese Sicherung nicht<br />
// weiter, da die Speicheraddressen in einem neuen/erweiterten Programm<br />
// moeglicherweise verschoben wurden. An der Stelle &eeFooByte steht<br />
// dann u.U. der Wert einer anderen Variable aus einer "alten" Version.<br />
<br />
uint8_t fooByteDefault = 222;<br />
if ((myByte = eeprom_read_byte (&eeFooByte)) == EEPROM_DEF)<br />
{<br />
myByte = fooByteDefault;<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
=== Wort lesen/schreiben ===<br />
<br />
Schreiben und Lesen von Datenworten erfolgt analog zur Vorgehensweise bei Bytes:<br />
<br />
<syntaxhighlight lang="c"><br />
// lesen<br />
uint16_t myWord = eeprom_read_word (&eeFooWord);<br />
<br />
// schreiben<br />
eeprom_write_word (&eeFooWord, 2222);<br />
</syntaxhighlight><br />
<br />
=== Block lesen/schreiben ===<br />
<br />
Lesen und Schreiben von Datenblöcken erfolgt über die Funktionen <code>eeprom_read_block()</code> bzw. <code>eeprom_write_block()</code>. Die Funktionen erwarten drei Parameter: die Adresse der Quell- bzw. Zieldaten im RAM, die EEPROM-Adresse und die Länge des Datenblocks in Bytes als <code>size_t</code>.<br />
<syntaxhighlight lang="c"><br />
uint8_t myByteBuffer[3];<br />
uint16_t myWordBuffer[4];<br />
<br />
void eeprom_block_example (void)<br />
{<br />
/* Datenblock aus EEPROM lesen */<br />
<br />
/* liest 3 Bytes ab der von eeFooByteArray1 definierten EEPROM-Adresse<br />
in das RAM-Array myByteBuffer */<br />
eeprom_read_block (myByteBuffer, eeFooByteArray1, 3);<br />
<br />
/* dito mit etwas Absicherung betr. der Länge */<br />
eeprom_read_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));<br />
<br />
/* und nun mit 16-Bit Array */<br />
eeprom_read_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));<br />
<br />
/* Datenblock in EEPROM schreiben */<br />
eeprom_write_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));<br />
eeprom_write_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));<br />
}<br />
</syntaxhighlight><br />
<br />
=== Fließkommawerte lesen/schreiben ===<br />
<br />
In der avr-libc stehen auch EEPROM-Funktionen für Variablen des Typs float (Fließkommazahlen mit "einfacher" Genauigkeit) zur Verfügung.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/eeprom.h><br />
<br />
float eeFloat EEMEM = 12.34f;<br />
<br />
float void eeprom_float_example(float value)<br />
{<br />
/* float in EEPROM schreiben */<br />
eeprom_write_float(&eeFloat, value);<br />
<br />
/* float aus EEPROM lesen */<br />
return eeprom_read_float(&eeFloat);<br />
}</syntaxhighlight><br />
<br />
=== EEPROM-Speicherabbild in .eep-Datei ===<br />
<br />
Mit den zum Compiler gehörenden Werkzeugen kann der aus den Variablendeklarationen abgeleitete EEPROM-Inhalt in eine Datei geschrieben werden. Die übliche Dateiendung ist .eep, Daten im Intel Hex-Format. Damit können Standardwerte für den EEPROM-Inhalt im Quellcode definiert werden. <br />
<br />
Makefiles nach WinAVR/MFile-Vorlage enthalten bereits die notwendigen Einstellungen, siehe dazu die Erläuterungen im [[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]].<br />
<br />
Der Inhalt der eep-Datei muss ebenfalls zum Mikrocontroller übertragen werden, wenn die Initialisierungswerte aus der Deklaration vom Programm erwartet werden. Ansonsten enthält der EEPROM-Speicher nach der Übertragung des Programmers mittels ISP abhängig von der Einstellung der EESAVE-Fuse<ref>vgl. Datenblatt Abschnitt Fuse Bits</ref> nicht die korrekten Werte:<br />
; EESAVE = 0 (programmed): Die Daten im EEPROM bleiben erhalten. Werden sie nicht neu geschrieben, so enthält das EEPROM evtl. Daten, die nicht mehr zum Programm passen.<br />
; EESAVE = 1 (unprogrammed): Beim Programmieren werden die Daten im EEPROM gelöscht, also auf 0xff gesetzt.<br />
<br />
Als Sicherung kann man im Programm nochmals die Standardwerte vorhalten, beim Lesen auf 0xFF prüfen und gegebenenfalls einen Standardwert nutzen. Das geht natürlich nur, wenn 0xFF selbst nicht als Datenwert vorkommen kann.<br />
<syntaxhighlight lang="c"><br />
#define DUTY_CYCLE_DEFAULT 0x80<br />
<br />
uint8_t eeDutyCycle EEMEM; // Platzhalter für EEPROM<br />
uint8_t DutyCycle; // die echte Variable<br />
<br />
<br />
int main(void)<br />
{<br />
DutyCycle = eeprom_read_byte( &eeDutyCycle );<br />
if( DutyCycle == 0xFF ) // das allererste mal. Im EEPROM steht noch kein gültiger Wert<br />
{<br />
DutyCycle = DUTY_CYCLE_DEFAULT;<br />
eeprom_writeByte( &eeDutyCycle, DutyCycle );<br />
}<br />
<br />
...<br />
</syntaxhighlight><br />
<br />
=== Direkter Zugriff auf EEPROM-Adressen ===<br />
<br />
Will man direkt auf bestimmte EEPROM Adressen zugreifen, dann sind folgende IAR-kompatiblen Makros <tt>_EEGET</tt> und <tt>_EEPUT</tt> hilfreich, um sich die Typecasts zu ersparen.<br />
<br />
;Hinweis: Die nachfolgend gezeigten Makros und Zugriffe auf absolute Adressen sind in Normalfall nicht nötig und nur auf sehr wenige, spezielle Fälle beschränkt! Im Normalfall sollte man auf absolute Adressen möglichst nicht zugreifen und den Compiler seine Arbeit machen lassen, der verwaltet die Variablen und deren Adressen meist besser als der Programmierer. Der Zugriff auf Variablen im EEPROM sollte immer über ihren Namen erfolgen.<br />
<br />
Verwendung:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/eeprom.h><br />
<br />
_EEPUT (0x20, 128); // Byte-Wert 128 an Adresse 0x20 schreiben<br />
...<br />
uint8_t val = _EEGET (0x20); // EEPROM-Wert von Adresse 0x20 lesen<br />
</syntaxhighlight><br />
<br />
=== Was steckt dahinter? - EEPROM-Register ===<br />
Auch wenn es normalerweise keinen Grund gibt, in C selbst an den Steuerregistern herumzuschrauben - die eeprom Funktionen erledigen das alles zuverlässig - der Vollständigkeit halber der registermässige technische Unterbau.<br />
Um das EEPROM anzusteuern, sind drei Register von Bedeutung:<br />
;EEAR: Hier werden die Adressen eingetragen zum Schreiben oder Lesen. Dieses Register unterteilt sich nochmal in EEARH und EEARL, da in einem 8-Bit-Register keine 512 Adressen adressiert werden können.<br />
;EEDR: Hier werden die Daten eingetragen, die geschrieben werden sollen, bzw. es enthält die gelesenen Daten.<br />
;EECR: Ist das Kontrollregister für das EEPROM<br />
<br />
Das EECR steuert den Zugriff auf das EEPROM und ist wie folgt aufgebaut:<br />
<br />
:{| class="wikitable" style="text-align:center"<br />
|+ '''Aufbau des EECR-Registers'''<br />
|-<br />
!Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|-<br />
! Name<br />
| - || - || - ||- || EERIE || EEMWE || EEWE || EERE<br />
|-<br />
! Read/Write<br />
| R || R || R || R || R/W || R/W || R/W || R/W<br />
|-<br />
!Init Value<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''Bedeutung der Bits'''<br />
<br />
;Bit 4-7: nicht belegt<br />
<br />
;Bit 3 (EERIE): ''EEPROM Ready Interrupt Enable'': Wenn das Bit gesetzt ist und globale Interrupts erlaubt sind in Register SREG (Bit 7), wird ein Interrupt ausgelöst nach Beendigung des Schreibzyklus (EEPROM Ready Interrupt). Ist einer der beiden Bits 0, wird kein Interrupt ausgelöst.<br />
<br />
;Bit 2 EEMWE): ''EEPROM Master Write Enable'': Dieses Bit bestimmt, dass, wenn EEWE = 1 gesetzt wird (innerhalb von 4 Taktzyklen), das EEPROM beschrieben wird mit den Daten in EEDR bei Adresse EEAR. Wenn EEMWE = 0 ist und EEWE = 1 gesetzt wird, hat das keine Auswirkungen. Der Schreibvorgang wird dann nicht ausgelöst. Nach 4 Taktzyklen wird das Bit EEMWE automatisch wieder auf 0 gesetzt. Dieses Bit löst den Schreibvorgang nicht aus, es dient sozusagen als Sicherungsbit für EEWE.<br />
<br />
;Bit 1 (EEWE): ''EEPROM Write Enable'': Dieses Bit löst den Schreibvorgang aus, wenn es auf 1 gesetzt wird, sofern vorher EEMWE gesetzt wurde und seitdem nicht mehr als 4 Taktzyklen vergangen sind. Wenn der Schreibvorgang abgeschlossen ist, wird dieses Bit automatisch wieder auf 0 gesetzt und, sofern EERIE gesetzt ist, ein Interrupt ausgelöst. Ein Schreibvorgang sieht typischerweise wie folgt aus:<br />
:# EEPROM-Bereitschaft abwarten (EEWE=0) <br />
:# Adresse übergeben an EEAR<br />
:# Daten übergeben an EEDR<br />
:# Schreibvorgang auslösen in EECR mit Bit EEMWE=1 und EEWE=1<br />
:# (Optional) Warten, bis Schreibvorgang abgeschlossen ist<br />
<br />
;Bit 0 EERE: ''EEPROM Read Enable'': Wird dieses Bit auf 1 gesetzt wird das EEPROM an der Adresse in EEAR ausgelesen und die Daten in EEDR gespeichert. Das EEPROM kann nicht ausgelesen werden, wenn bereits eine Schreiboperation gestartet wurde. Es ist daher zu empfehlen, die Bereitschaft vorher zu prüfen. Das EEPROM ist lesebereit, wenn das Bit EEWE=0 ist. Ist der Lesevorgang abgeschlossen, wird das Bit wieder auf 0 gesetzt, und das EEPROM ist für neue Lese- und Schreibbefehle wieder bereit. Ein typischer Lesevorgang kann wie folgt aufgebaut sein:<br />
:# Bereitschaft zum Lesen prüfen (EEWE=0)<br />
:# Adresse übergeben an EEAR<br />
:# Lesezyklus auslösen mit EERE = 1<br />
:# Warten, bis Lesevorgang abgeschlossen EERE = 0<br />
:# Daten abholen aus EEDR<br />
<br />
= Die Nutzung von sprintf und printf =<br />
<br />
Um komfortabel, d.h. formatiert, Ausgaben auf ein Display oder die serielle Schnittstelle zu tätigen, bieten sich '''sprintf''' oder '''printf''' an. Alle *printf-Varianten sind jedoch ziemlich speicherintensiv und der Einsatz in einem Mikrocontroller mit knappem Speicher muss sorgsam abgewogen werden.<br />
<br />
Bei '''sprintf''' wird die Ausgabe zunächst in einem Puffer vorbereitet und anschließend mit einfachen Funktionen zeichenweise ausgegeben. Es liegt in der Verantwortung des Programmierers, genügend Platz im Puffer für die erwarteten Zeichen bereitzuhalten.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdio.h><br />
#include <stdint.h><br />
<br />
// ...<br />
// nicht dargestellt: Implementierung von uart_puts (vgl. Abschnitt UART)<br />
// ...<br />
<br />
uint16_t counter;<br />
<br />
// Ausgabe eines unsigned Integerwertes<br />
void uart_puti( uint16_t value )<br />
{<br />
uint8_t puffer[20];<br />
<br />
sprintf( puffer, "Zählerstand: %u", value );<br />
uart_puts( puffer );<br />
}<br />
<br />
int main()<br />
{<br />
counter = 5;<br />
<br />
uart_puti( counter );<br />
uart_puti( 42 );<br />
}<br />
</syntaxhighlight><br />
<br />
Eine weitere elegante Möglichkeit besteht darin, den STREAM stdout (Standardausgabe) auf eine eigene Ausgabefunktion umzuleiten. Dazu wird dem Ausgabemechanismus der C-Bibliothek eine neue Ausgabefunktion bekannt gemacht, deren Aufgabe es ist, ein einzelnes Zeichen auszugeben. Wohin die Ausgabe dann tatsächlich stattfindet, ist Sache der Ausgabefunktion. Im Beispiel unten wird auf UART ausgegeben. Alle anderen, höheren Funktionen wie z.&nbsp;B. '''printf''', greifen letztendlich auf diese primitive Ausgabefunktion zurück. <br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdio.h><br />
<br />
void uart_init(void);<br />
<br />
// a. Deklaration der primitiven Ausgabefunktion<br />
int uart_putchar(char c, FILE *stream);<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 1)<br />
static FILE mystdout = FDEV_SETUP_STREAM( uart_putchar, NULL, _FDEV_SETUP_WRITE );<br />
<br />
// c. Definition der Ausgabefunktion<br />
int uart_putchar( char c, FILE *stream )<br />
{<br />
if( c == '\n' )<br />
uart_putchar( '\r', stream );<br />
<br />
loop_until_bit_is_set( UCSRA, UDRE );<br />
UDR = c;<br />
return 0;<br />
}<br />
<br />
void uart_init(void)<br />
{<br />
/* hier µC spezifischen Code zur Initialisierung */<br />
/* des UART einfügen... s.o. im AVR-GCC-Tutorial */<br />
<br />
// Beispiel: <br />
//<br />
// myAVR Board 1.5 mit externem Quarz Q1 3,6864 MHz<br />
// 9600 Baud 8N1<br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
// Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt)<br />
#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)<br />
<br />
UCSRB |= (1<<TXEN) | (1<<RXEN); // UART TX und RX einschalten<br />
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1 <br />
<br />
UBRRH = (uint8_t)( UART_UBRR_CALC( UART_BAUD_RATE, F_CPU ) >> 8 );<br />
UBRRL = (uint8_t)UART_UBRR_CALC( UART_BAUD_RATE, F_CPU );<br />
}<br />
<br />
int main(void)<br />
{<br />
int16_t antwort = 42;<br />
uart_init();<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 2)<br />
stdout = &mystdout;<br />
<br />
// Anwendung<br />
printf( "Die Antwort ist %d.\n", antwort );<br />
return 0;<br />
}<br />
<br />
// Quelle: avr-libc-user-manual-1.4.3.pdf, S.74<br />
// + Ergänzungen<br />
</syntaxhighlight><br />
<br />
<br />
Sollen Fließkommazahlen ausgegeben werden, muss im Makefile eine andere (größere) Version der [[FAQ#Aktivieren_der_Floating_Point_Version_von_sprintf_beim_WinAVR_mit_AVR-Studio|printflib]] eingebunden werden.<br />
<br />
= Anmerkungen =<br />
<references/><br />
<br />
= TODO =<br />
* Aktualisierung Register- und Bitbeschreibungen an aktuelle AVR<br />
* "naked"-Funktionen [http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html][http://arduino.stackexchange.com/questions/8758/arduino-interruption-on-pin-change]<br />
<br />
[[Kategorie:avr-gcc Tutorial| ]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR-GCC-Tutorial&diff=107260AVR-GCC-Tutorial2025-01-27T14:57:55Z<p>Heha: /* Datenzugriff >64kiB */</p>
<hr />
<div>Dieses Tutorial soll den Einstieg in die Programmierung von Atmel [[AVR]]-Mikrocontrollern in der Programmiersprache [[C]] mit dem freien C-Compiler [[avr-gcc]] aus der [http://gcc.gnu.org/ GNU Compiler Collection] (GCC) erleichtern.<br />
<br />
Vorausgesetzt werden Grundkenntnisse der Programmiersprache C. Diese Kenntnisse kann man sich online erarbeiten, z. B. mit dem [http://www.schellong.de/c.htm C Tutorial von Helmut Schellong] ([[C|Liste von C-Tutorials]]). Nicht erforderlich sind Vorkenntnisse in der Programmierung von Mikrocontrollern.<br />
<br />
= Vorwort =<br />
<br />
In diesem Text wird häufig auf die Standardbibliothek avr-libc verwiesen, für die es eine [http://www.nongnu.org/avr-libc/user-manual/index.html Online-Dokumentation] gibt, in der sich auch viele nützliche Informationen zum Compiler und zur Programmierung von AVR-Controllern finden. Beim Paket [[WinAVR]] gehört die avr-libc Dokumentation zum Lieferumfang und wird mitinstalliert.<br />
<br />
Der Compiler und die Standardbibliothek avr-libc werden ständig weiterentwickelt. Einige Unterschiede, die sich im Verlauf der Entwicklung ergeben haben, werden hier und im Artikel [[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen]] zwar angesprochen, Anfängern und Umsteigern sei jedoch empfohlen, eine aktuelle Versionen zu nutzen.<br />
<br />
Das ursprüngliche Tutorial stammt von Christian Schifferle, viele neue Abschnitte und aktuelle Anpassungen von Martin Thomas.<br />
<br />
Dieses Tutorial ist in [[Media:AVR-GCC-Tutorial.pdf|PDF-Form]] erhältlich (zur Zeit nur eine sehr veraltete Version).<br />
<br />
== Weiterführende Kapitel ==<br />
<br />
Um dieses riesige Tutorial etwas überschaubarer zu gestalten, wurden einige Kapitel ausgelagert, die nicht unmittelbar mit den Grundlagen von avr-gcc in Verbindung stehen. All diese Seiten gehören zur [[:Kategorie:avr-gcc Tutorial]].<br />
<br />
;UART: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der UART|Der UART]]''<br />
<br />
;ADC: → Hauptartikel: ''[[AVR-GCC-Tutorial/Analoge Ein- und Ausgabe|Analoge Ein- und Ausgabe (ADC)]]''<br />
<br />
;Timer: → Hauptartikel: ''[[AVR-GCC-Tutorial/Die Timer und Zähler des AVR|Die Timer und Zähler des AVR]]''<br />
<br />
;LCD: → Hauptartikel: ''[[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Ansteuerung]]''<br />
<br />
;Watchdog: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der Watchdog|Der Watchdog]]''<br />
<br />
;Assembler: → Hauptartikel: ''[[AVR-GCC-Tutorial/Assembler und Inline-Assembler|Assembler und Inline-Assembler]]''<br />
<br />
;alte Quellen anpassen: → Hauptartikel: ''[[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen anpassen]]''<br />
<br />
;Makefiles: → Hauptartikel: ''[[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]]'' sowie als Alternative für sehr kleine Projekte → Hauptartikel: ''[[C ohne Makefile]]''<br />
<br />
= Benötigte Werkzeuge =<br />
<br />
Um eigene Programme für AVRs mittels einer AVR-Toolchain zu erstellen wird folgende Hard- und Software benötigt:<br />
<br />
* Eine AVR-Toolchain bestehend aus avr-gcc, den avr-Binutils (Assembler, Linker, etc) und einer Standard-C Bibliothek. Üblich ist die AVR-LibC, die auch quasi in allen avr-gcc Distributionen enthalten ist.<br />
<br />
Hardware wird keine benötigt – bis auf einen PC natürlich, auf dem der Compiler ablaufen kann. Selbst ohne AVR-Hardware kann man also bereits C-Programme für AVRs schreiben, compiliern und sich das Look-and-Feel von avr-gcc sowie von IDEs wie [[Atmel Studio]], Eclipse oder leichtgewichtigeren Entwicklungsumbgebungen anschauen. Selbst das Debuggen und Simulieren ist mithilfe entsprechender Tools wie Debugger und Simulator in gewissen Grenzen möglich.<br />
<br />
Um Programme für AVRs mittels einer AVR-Toolchain zu testen, wird folgende Hard- und Software benötigt:<br />
<br />
* Platine oder Versuchsaufbau für die Aufnahme eines AVR-Controllers, der vom avr-gcc Compiler unterstützt wird.<ref>Für eine Liste der unterstützten COntroller siehe die Dokumentation des Compilers oder [http://www.nongnu.org/avr-libc/user-manual/index.html#supported_devices AVR-Libc: Supported Devices].</ref> Dieses Testboard kann durchaus auch selbst gelötet oder auf einem Steckbrett aufgebaut werden. Einige Registerbeschreibungen dieses Tutorials beziehen sich auf den inzwischen veralteten AT90S2313. Der weitaus größte Teil des Textes ist aber für alle Controller der AVR-Familie gültig. <br />
<br />
:Brauchbare Testplattformen sind auch das [[STK500]] und der [[AVR Butterfly]] von Atmel. Weitere Infos findet man in den Artikeln [[AVR#Starterkits|AVR Starterkits]] und [[AVR-Tutorial: Equipment]].<br />
<br />
* Programmiersoftware und -[[AVR In System Programmer |hardware]] z. B. PonyProg (siehe auch: [[Pony-Prog Tutorial]]) oder [[AVRDUDE]] mit [[STK200]]-Dongle oder die von Atmel verfügbare Hard- und Software ([[STK500]], Atmel AVRISP, [[AVR-Studio]]).<br />
<br />
* Nicht unbedingt erforderlich, aber zur Simulation und zum Debuggen unter MS-Windows recht nützlich: [[AVR-Studio]].<br />
<br />
* Wer unter Windows und Linux gleichermassen entwickeln will, der sollte sich die [http://www.eclipse.org/ IDE Eclipse for C/C++ Developers] und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] ansehen. Beide sind unter Windows und Linux einfach zu installieren, siehe auch [[AVR Eclipse]]. Ebenfalls unter Linux und Windows verfügbar ist die Entwicklungsumgebung [http://www.codeblocks.org/ Code::Blocks]<ref>Aktuelle, stabile Versionen sind als Nightly Builds regelmäßig im [http://forums.codeblocks.org/ Forum] verfügbar.</ref>. Innerhalb dieser Entwicklungsumgebung können ohne die Installation zusätzlicher Plugins "AVR-Projekte" angelegt werden. Für Linux gibt es auch noch das [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=25220 KontrollerLab].<br />
<br />
= Was tun, wenn's nicht klappt? =<br />
<br />
* Herausfinden, ob es tatsächlich ein avr(-gcc) spezifisches Problem ist oder nur die eigenen C-Kenntnisse einer Auffrischung bedürfen. Allgemeine C-Fragen kann man eventuell "beim freundlichen Programmierer zwei Büro-, Zimmer- oder Haustüren weiter" loswerden. Ansonsten: [[C]]-Buch (gibt's auch "gratis" online) lesen.<br />
<br />
* Die [[AVR Checkliste]] durcharbeiten.<br />
<br />
* Die '''[http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc]''' lesen, vor allem (aber nicht nur) den Abschnitt Related Pages/'''Frequently Asked Questions''' = Oft gestellte Fragen (und Antworten dazu). Z.Zt leider nur in englischer Sprache verfügbar.<br />
<br />
* Den Artikel [[AVR-GCC]] in diesem Wiki lesen.<br />
<br />
* Das [http://www.mikrocontroller.net/forum/gcc GCC-Forum auf www.mikrocontroller.net] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das avr-gcc-Forum bei [http://www.avrfreaks.net AVRfreaks] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das [http://lists.gnu.org/archive/html/avr-gcc-list/ Archiv der avr-gcc Mailing-Liste] nach vergleichbaren Problemen absuchen.<br />
<br />
* Nach Beispielcode suchen. Vor allem im ''Projects''-Bereich von [http://www.avrfreaks.net AVRfreaks] (anmelden).<br />
<br />
* Google oder yahoo befragen schadet nie.<br />
<br />
* Bei Problemen mit der Ansteuerung interner AVR-Funktionen mit C-Code: das Datenblatt des Controllers lesen (ganz und am Besten zweimal). Datenblätter sind auf den [http://www.atmel.com Atmel Webseiten] als pdf-Dateien verfügbar. Das komplette Datenblatt (complete) und nicht die Kurzfassung (summary) verwenden.<br />
<br />
* Die Beispielprogramme im [[AVR-Tutorial]] sind zwar in AVR-Assembler verfasst, Erläuterungen und Vorgehensweisen sind aber auch auf C-Programme übertragbar.<br />
<br />
* Einen Beitrag in eines der Foren oder eine Mail an die Mailing-Liste schreiben. Dabei möglichst viel Information geben: Controller, Compilerversion, genutzte Bibliotheken, Ausschnitte aus dem Quellcode oder besser ein [http://www.mikrocontroller.net/topic/72767#598986 Testprojekt] mit allen notwendigen Dateien, um das Problem nachzuvollziehen, sowie genaue Fehlermeldungen bzw. Beschreibung des Fehlverhaltens. Bei Ansteuerung externer Geräte die Beschaltung beschreiben oder skizzieren (z. B. mit [http://www.tech-chat.de/ Andys ASCII Circuit]). Siehe dazu auch: '''[http://www.tty1.net/smart-questions_de.html "Wie man Fragen richtig stellt"]'''.<br />
<br />
= Erzeugen von Maschinencode =<br />
<br />
Aus dem C-Quellcode erzeugt der avr-gcc Compiler (zusammen mit Hilfsprogrammen wie z.&nbsp;B. Präprozessor, Assembler und Linker) Maschinencode für den AVR-Controller. Üblicherweise liegt dieser Code dann im Intel Hex-Format vor ("Hex-Datei"). Die Programmiersoftware (z.&nbsp;B. [[AVRDUDE]], PonyProg oder AVRStudio/STK500-plugin) liest diese Datei ein und überträgt die enthaltene Information (den Maschinencode) in den Speicher des Controllers. Im Prinzip sind also "nur" der avr-gcc-Compiler (und wenige Hilfsprogramme) mit den "richtigen" Optionen aufzurufen, um aus C-Code eine "Hex-Datei" zu erzeugen. Grundsätzlich stehen dazu drei verschiedene Ansätze zur Verfügung:<br />
<br />
* Die Verwendung einer integrierten Entwicklungsumgebung (IDE = '''I'''ntegrated '''D'''evelopment '''E'''nvironment), bei der alle Einstellungen z.&nbsp;B. in Dialogboxen durchgeführt werden können. Unter Anderem kann AVRStudio ab Version 4.12 (kostenlos auf [http://www.atmel.com/ atmel.com]) zusammen mit WinAVR als integrierte Entwicklungsumgebung für den Compiler avr-gcc genutzt werden (dazu müssen AVRStudio und WinAVR auf dem Rechner installiert sein). Weitere IDEs (ohne Anspruch auf Vollständigkeit): [http://www.eclipse.org/ Eclipse for C/C++ Developers] (d.h. inkl. CDT) und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] (für diverse Plattformen, u.a. Linux und MS Windows, IDE und Plugin kostenlos), [http://sourceforge.net/projects/kontrollerlab KontrollerLab] (Linux/KDE, kostenlos). [http://www.atmanecl.com/EnglishSite/SoftwareEnglish.htm AtmanAvr] (MS Windows, relativ günstig), KamAVR (MS-Windows, kostenlos, wird augenscheinlich nicht mehr weiterentwickelt), [http://www.amctools.com/vmlab.htm VMLab] (MS Windows, ab Version 3.12 ebenfalls kostenlos). Integrierte Entwicklungsumgebungen unterscheiden sich stark in Ihrer Bedienung und stehen auch nicht für alle Plattformen zur Verfügung, auf denen der Compiler ausführbar ist (z.&nbsp;B. AVRStudio nur für MS-Windows). Zur Anwendung des avr-gcc Compilers mit IDEs sei hier auf deren Dokumentation verwiesen. <br />
<br />
* Die Nutzung des Programms make mit passenden Makefiles. In den folgenden Abschnitten wird die Generierung von Maschinencode für einen AVR ("hex-Datei") aus C-Quellcode ("c-Dateien") anhand von "make" und den "Makefiles" näher erläutert. Viele der darin beschriebenen Optionen findet man auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio (AVRStudio generiert ein makefile in einem Unterverzeichnis des Projektverzeichnisses). <br />
<br />
* Das Generieren des Programms ohne IDE und ohne Makefile. In diesem Fall muss die Quellcodedatei durch eine vorgefertigte Kommandofolge an den Compiler übergeben werden. Der Artikel [[C ohne Makefile]] zeigt, wie das funktioniert. Diese Vorgehensweise empfiehlt sich jedoch nur für kleine Programme, die nicht auf verschiedene Quellcodedateien verteilt sind.<br />
<br />
Beim Wechsel vom makefile-Ansatz nach WinAVR-Vorlage zu AVRStudio ist darauf zu achten, dass AVRStudio (Stand: AVRStudio Version 4.13) bei einem neuen Projekt die Optimierungsoption (vgl. Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|AVR-GCC-Tutorial/Exkurs: Makefiles]], typisch: -Os) nicht einstellt und die mathematische Bibliothek der avr-libc (libm.a, Linker-Option -lm) nicht einbindet. (Hinweis: Bei Version 4.16 wird beides bereits gesetzt). Beides ist Standard bei Verwendung von makefiles nach WinAVR-Vorlage und sollte daher auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio "manuell" eingestellt werden, um auch mit AVRStudio kompakten Code zu erzeugen.<br />
<br />
= Einführungsbeispiel =<br />
<br />
Zum Einstieg ein kleines Beispiel, an dem die Nutzung des Compilers und der Hilfsprogramme (der sogenannten ''Toolchain'') demonstriert wird. Detaillierte Erläuterungen folgen in den weiteren Abschnitten dieses Tutorials.<br />
<br />
Das Programm soll auf einem AVR Mikrocontroller einige Ausgänge ein- und andere ausschalten. Das Beispiel ist für einen ATmega16 programmiert ([http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf Datenblatt]), kann aber sinngemäß für andere Controller der AVR-Familie modifiziert werden. <br />
<br />
Ein kurzes Wort zur Hardware: Bei diesem Programm werden alle Pins von PORTB auf Ausgang gesetzt, und einige davon werden auf HIGH andere auf LOW gesetzt. Das kann je nach angeschlossener Hardware an diesen Pins kritisch sein. Am ungefährlichsten ist es, wenn nichts an den Pins angeschlossen ist und man die Funktion des Programmes durch eine Spannungsmessung mit einem Multimeter kontrolliert. Die Spannung wird dabei zwischen GND-Pin und den einzelnen Pins von PORTB gemessen.<br />
<br />
Zunächst der Quellcode der Anwendung, der in einer Text-Datei mit dem Namen ''main.c'' abgespeichert wird.<br />
<br />
<syntaxhighlight lang="c"><br />
/* Alle Zeichen zwischen Schrägstrich-Stern <br />
und Stern-Schrägstrich sind Kommentare */<br />
<br />
// Zeilenkommentare sind ebenfalls möglich<br />
// alle auf die beiden Schrägstriche folgenden<br />
// Zeichen einer Zeile sind Kommentar<br />
<br />
#include <avr/io.h> // (1)<br />
<br />
int main (void) { // (2)<br />
<br />
DDRB = 0xFF; // (3)<br />
PORTB = 0x03; // (4)<br />
<br />
while(1) { // (5)<br />
/* "leere" Schleife*/ // (6)<br />
} // (7)<br />
<br />
/* wird nie erreicht */<br />
return 0; // (8)<br />
}<br />
</syntaxhighlight><br />
<br />
# In dieser Zeile wird eine sogenannte Header-Datei eingebunden. In <code>avr/io.h</code> sind die Registernamen definiert, die im späteren Verlauf genutzt werden. Auch unter Windows wird ein&nbsp;<code>/</code> zur Kennzeichnung von Unterverzeichnissen in Include-Dateinamen verwendet und kein&nbsp;<code>\</code>.<br />
# Hier beginnt das eigentliche Programm. Jedes C-Programm beginnt mit den Anweisungen in der Funktion <code>main</code>.<br />
# Die Anschlüsse eines AVR (Pins) werden zu Blöcken zusammengefasst, einen solchen Block bezeichnet man als Port. Beim ATmega16 hat jeder Port 8 Anschlüsse, bei kleineren AVRs können einem Port auch weniger als 8 Anschlüsse zugeordnet sein. Da per Definition (Datenblatt) alle gesetzten Bits in einem Datenrichtungsregister den entsprechenden Anschluss auf Ausgang schalten, werden mit DDRB=0xff alle Anschlüsse des Ports B als Ausgänge eingestellt.<br />
# Die den ersten beiden Bits des Ports zugeordneten Anschlüsse (PB0 und PB1) werden 1, alle anderen Anschlüsse des Ports B (PB2-PB7) zu 0. Aktivierte Ausgänge (logisch 1 oder "high") liegen auf Betriebsspannung (VCC, meist 5 Volt), nicht aktivierte Ausgänge führen 0 Volt (GND, Bezugspotential). Es ist sinnvoll, sich möglichst frühzeitig eine alternative Schreibweise beizubringen, die wegen der leichteren Überprüfbarkeit und Portierbarkeit oft im weiteren Tutorial und in Forenbeiträgen benutzt wird. Die Zuordnung sieht in diesem Fall so aus, Näheres dazu im Artikel [[Bitmanipulation]]:<syntaxhighlight lang="c">PORTB = (1<<PB1) | (1<<PB0);</syntaxhighlight><br />
# ist der Beginn der sogenannte ''Hauptschleife'' (main-loop). Dies ist eine Endlosschleife, welche kontinuierlich wiederkehrende Befehle enthält.<br />
# In diesem Beispiel ist die Hauptschleife leer. Der Controller durchläuft die Schleife immer wieder, ohne dass etwas passiert. Eine solche Schleife ist notwendig, da es auf dem Controller kein Betriebssystem gibt, das nach Beendigung des Programmes die Kontrolle übernehmen könnte. Ohne diese Schleife kehrt das Programm aus <code>main</code> zurück, alle Interrupts werden deaktiviert und eine Endlosschleife betreten.<br />
# Ende der Hauptschleife und Sprung zur passenden, öffnenden Klammer, also zu 5.<br />
# ist das Programmende. Die Zeile ist nur aus Gründen der C-Kompatibilität enthalten: <syntaxhighlight lang="c">int main(void)</syntaxhighlight> besagt, dass die Funktion einen int-Wert zurückgibt. Die Anweisung wird aber nicht erreicht, da das Programm die Hauptschleife nie verlässt.<br />
<br />
Um diesen Quellcode in ein lauffähiges Programm zu übersetzen, wird hier ein Makefile genutzt. Das verwendete Makefile findet sich auf der Seite [[Beispiel Makefile]] und basiert auf der Vorlage, die in WinAVR mitgeliefert wird und wurde bereits angepasst (Controllertyp ATmega16). Man kann das Makefile bearbeiten und an andere Controller anpassen oder sich mit dem Programm MFile menügesteuert ein Makefile "zusammenklicken". Das Makefile speichert man unter dem Namen <code>Makefile</code> (ohne Endung) im selben Verzeichnis, in dem auch die Datei <code>main.c</code> mit dem Programmcode abgelegt ist. Detailliertere Erklärungen zur Funktion von Makefiles finden sich im Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|Exkurs: Makefiles]].<br />
<br />
<pre><br />
D:\beispiel>dir<br />
<br />
Verzeichnis von D:\beispiel<br />
<br />
28.11.2006 22:53 <DIR> .<br />
28.11.2006 22:53 <DIR> ..<br />
28.11.2006 20:06 118 main.c<br />
28.11.2006 20:03 16.810 Makefile<br />
2 Datei(en) 16.928 Bytes<br />
</pre><br />
<br />
Nun gibt man ''make all'' ein. Falls das mit WinAVR installierte Programmers Notepad genutzt wird, gibt es dazu einen Menüpunkt im Tools Menü. Sind alle Einstellungen korrekt, entsteht eine Datei <code>main.hex</code>, in welcher der Code für den AVR enthalten ist. <br />
<pre><br />
D:\beispiel>make all<br />
<br />
-------- begin --------<br />
avr-gcc (GCC) 3.4.6<br />
Copyright (C) 2006 Free Software Foundation, Inc.<br />
This is free software; see the source for copying conditions. There is NO<br />
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.<br />
<br />
Compiling C: main.c<br />
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -f<br />
unsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef<br />
-Wa,-adhlns=obj/main.lst -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c -<br />
o obj/main.o<br />
<br />
Linking: main.elf<br />
avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -funs<br />
igned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -W<br />
a,-adhlns=obj/main.o -std=gnu99 -Wundef -MD -MP -MF .dep/main.elf.d obj/main.o<br />
--output main.elf -Wl,-Map=main.map,--cref -lm<br />
<br />
Creating load file for Flash: main.hex<br />
avr-objcopy -O ihex -R .eeprom main.elf main.hex<br />
</pre><br />
<br />
Der Inhalt der hex-Datei kann nun zum Controller übertragen werden. Dies kann z.&nbsp;B. über In-System-Programming ([[ISP]]) erfolgen, das im [[AVR-Tutorial: Equipment]] beschrieben ist. Makefiles nach der WinAVR/MFile-Vorlage sind für die Nutzung des Programms [[AVRDUDE]] vorbereitet. Wenn man den Typ und Anschluss des Programmiergerätes richtig eingestellt hat, kann mit ''make program'' die Übertragung mittels AVRDUDE gestartet werden. Jede andere Software, die hex-Dateien lesen und zu einem AVR übertragen kann<ref>z.&nbsp;B. [[Pony-Prog_Tutorial|Ponyprog]], yapp, AVRStudio</ref>, kann natürlich ebenfalls genutzt werden.<br />
<br />
Startet man nun den Controller (Reset-Taster oder Stromzufuhr aus/an), werden vom Programm die Anschlüsse PB0 und PB1 auf 1 gesetzt. Man kann mit einem Messgerät nun an diesem Anschluss die Betriebsspannung messen oder eine [[LED]] leuchten lassen (Anode an den Pin, Vorwiderstand nicht vergessen). An den Anschlüssen PB2-PB7 misst man 0 Volt. Eine mit der Anode mit einem dieser Anschlüsse verbundene LED leuchtet nicht.<br />
<br />
= Ganzzahlige Datentypen (Integer) =<br />
<br />
Bei der Programmierung von Mikrokontrollern ist die Definition einiger ganzzahliger Datentypen sinnvoll, an denen eindeutig die Bit-Länge abgelesen werden kann.<br />
<br />
Standardisierte Datentypen werden in der Header-Datei <code>stdint.h</code> definiert, die folgendermaßen eingebunden werden kann:<br />
<syntaxhighlight lang="c">#include <stdint.h></syntaxhighlight><br />
<br />
{| {{Tabelle}}<br />
|+ '''int-Typen aus <code>stdint.h</code> (C99)'''<br/>&nbsp;<br />
|- bgcolor="#d0d0ff"<br />
!colspan="5"| Vorzeichenbehaftete int-Typen<br />
|- bgcolor="#e8e8ff"<br />
! Typname || Bit-Breite ||colspan="2"| Wertebereich<br />
|align="center| '''C-Entsprechung''' (avr-gcc)<br />
|-<br />
|<code>int8_t</code> ||align="right"| 8 || −128 ⋯ 127 || −2<sup>7</sup> ⋯ 2<sup>7</sup>−1 || <code>signed char</code><br />
|-<br />
|<code>int16_t</code> ||align="right"| 16 || −32768 ⋯ 32767 || −2<sup>15</sup> ⋯ 2<sup>15</sup>−1 || <code>signed short</code>, <code>signed int</code><br />
|-<br />
|<code>int32_t</code> ||align="right"| 32 || −2147483648 ⋯ 2147483647 || −2<sup>31</sup> ⋯ 2<sup>31</sup>−1 || <code>signed long</code><br />
|-<br />
|<code>int64_t</code> ||align="right"| 64 || −9223372036854775808 ⋯ 9223372036854775807 || −2<sup>63</sup> ⋯ 2<sup>63</sup>−1 || <code>signed long long</code><br />
|- bgcolor="#d0d0ff"<br />
!colspan="5"| Vorzeichenlose int-Typen<br />
|- bgcolor="#e8e8ff"<br />
! Typname || Bit-Breite ||colspan="2"| Wertebereich<br />
|align="center| '''C-Entsprechung''' (avr-gcc)<br />
|-<br />
|<code>uint8_t</code> ||align="right"| 8 || 0 ⋯ 255 || 0 ⋯ 2<sup>8</sup>−1 || <code>unsigned char</code><br />
|-<br />
|<code>uint16_t</code> ||align="right"| 16 || 0 ⋯ 65535 || 0 ⋯ 2<sup>16</sup>−1 || <code>unsigned short</code>, <code>unsigned int</code><br />
|-<br />
|<code>uint32_t</code> ||align="right"| 32 || 0 ⋯ 4294967295 || 0 ⋯ 2<sup>32</sup>−1 || <code>unsigned long</code><br />
|-<br />
|<code>uint64_t</code> ||align="right"| 64 || 0 ⋯ 18446744073709551615 || 0 ⋯ 2<sup>64</sup>−1 || <code>unsigned long long</code><br />
|}<br />
<br />
Neben den Typen gibt es auch Makros für die Bereichsgrenzen wie <code>INT8_MIN</code> oder <code>UINT16_MAX</code>. Siehe dazu auch: [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html Dokumentation der avr-libc: Standard Integer Types].<br />
<br />
= Grundsätzlicher Programmaufbau eines µC-Programms =<br />
<br />
Wir unterscheiden zwischen 2 verschiedenen Methoden, um ein<br />
Mikrocontroller-Programm zu schreiben, und zwar völlig unabhängig davon, in<br />
welcher Programmiersprache das Programm geschrieben wird.<br />
<br />
== Sequentieller Programmablauf ==<br />
<br />
[[Image:Sequentielle Programme.gif|left]]<br />
Bei dieser Programmiertechnik wird eine Endlosschleife programmiert, welche im<br />
Wesentlichen immer den gleichen Aufbau hat. Es wird hier nach dem sogenannten EVA-Prinzip gehandelt. EVA steht für "Eingabe, Verarbeitung, Ausgabe".<br />
{{Absatz}}<br />
<br />
== Interruptgesteuerter Programmablauf ==<br />
<br />
[[Image:Interrupt Programme.gif|left]]<br />
Bei dieser Methode werden beim Programmstart zuerst die gewünschten Interruptquellen aktiviert und dann in eine Endlosschleife gegangen, in welcher Dinge erledigt werden können, welche nicht zeitkritisch sind. Wenn ein Interrupt ausgelöst wird, so wird automatisch die zugeordnete Interruptfunktion ausgeführt.<br />
{{Absatz}}<br />
<br />
= Zugriff auf Register =<br />
<br />
Die AVR-Controller verfügen über eine Vielzahl von Registern. Die meisten<br />
davon sind sogenannte Schreib-/Leseregister. Das heißt, das Programm kann die<br />
Inhalte der Register sowohl auslesen als auch beschreiben.<br />
<br />
Register haben einen besonderen Stellenwert bei den AVR Controllern. Sie dienen dem Zugriff auf die Ports und die Schnittstellen des Controllers. Wir unterscheiden zwischen 8-Bit und 16-Bit Registern. Vorerst behandeln wir die 8-Bit Register.<br />
<br />
Einzelne Register sind bei allen AVRs vorhanden, andere wiederum nur bei bestimmten Typen. So sind beispielsweise die Register, welche für den Zugriff auf den UART notwendig sind, selbstverständlich nur bei denjenigen Modellen vorhanden, welche über einen integrierten Hardware UART bzw. USART verfügen.<br />
<br />
Die Namen der Register sind in den Headerdateien zu den entsprechenden AVR-Typen definiert. Dazu muss man den Namen der controllerspezifischen Headerdatei nicht kennen. Es reicht aus, die allgemeine Headerdatei ''avr/io.h'' einzubinden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
</syntaxhighlight><br />
<br />
Ist im Makefile der MCU-Typ z.&nbsp;B. mit dem Inhalt atmega8 definiert (und wird somit per -mmcu=atmega8 an den Compiler übergeben), wird beim Einlesen der io.h-Datei implizit ("automatisch") auch die iom8.h-Datei mit den Register-Definitionen für den ATmega8 eingelesen.<br />
<br />
<!-- Wohl besser als Anhang - spaeter... --><br />
Intern wird diese "Automatik" wie folgt realisiert: Der Controllertyp wird dem Compiler als Parameter übergeben (vgl. ''avr-gcc -c -mmcu=atmega16 [...]'' im Einführungsbeispiel). Wird ein Makefile nach der WinAVR/mfile-Vorlage verwendet, setzt man die Variable ''MCU'', der Inhalt dieser Variable wird dann an passender Stelle für die Compilerparameter verwendet. Der Compiler definiert intern eine dem mmcu-Parameter zugeordnete "Variable" (genauer: ein Makro) mit dem Namen des Controllers, vorangestelltem ''__AVR_'' und angehängten Unterstrichen (z.&nbsp;B. wird bei ''-mmcu=atmega16'' das Makro ''__AVR_ATmega16__'' definiert). Beim Einbinden der Header-Datei ''avr/io.h'' wird geprüft, ob das jeweilige Makro definiert ist und die zum Controller passende Definitionsdatei eingelesen. Zur Veranschaulichung einige Ausschnitte aus einem Makefile:<br />
<br />
<pre><br />
[...]<br />
# MCU Type ("name") setzen:<br />
MCU = atmega16<br />
[...]<br />
<br />
[...]<br />
## Verwendung des Inhalts von MCU (hier atmega16) fuer die <br />
## Compiler- und Assembler-Parameter<br />
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)<br />
ALL_CPPFLAGS = -mmcu=$(MCU) -I. -x c++ $(CPPFLAGS) $(GENDEPFLAGS)<br />
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)<br />
[...]<br />
<br />
[...]<br />
## Aufruf des Compilers:<br />
## mit den Parametern ($(ALL_CFLAGS) ist -mmcu=$(MCU)[...] = -mmcu=atmega16[...]<br />
$(OBJDIR)/%.o : %.c<br />
@echo<br />
@echo $(MSG_COMPILING) $<<br />
$(CC) -c $(ALL_CFLAGS) $< -o $@ <br />
[...]<br />
</pre><br />
<br />
Da --mmcu=atmega16 übergeben wurde, wird __AVR_ATmega16__ definiert und kann in avr/io.h zur Fallunterscheidung genutzt werden:<br />
<br />
<syntaxhighlight lang="c"><br />
// avr/io.h <br />
// (bei WinAVR-Standardinstallation in C:\WinAVR\avr\include\avr)<br />
[...]<br />
#if defined (__AVR_AT94K__)<br />
# include <avr/ioat94k.h><br />
// [...]<br />
#elif defined (__AVR_ATmega16__)<br />
// da __AVR_ATmega16__ definiert ist, wird avr/iom16.h eingebunden:<br />
# include <avr/iom16.h><br />
// [...]<br />
#else<br />
# if !defined(__COMPILING_AVR_LIBC__)<br />
# warning "device type not defined"<br />
# endif<br />
#endif<br />
</syntaxhighlight><br />
<br />
Die Beispiele in den folgenden Abschnitten demonstrieren den Zugriff auf Register anhand der Register für I/O-Ports (PORTx, DDRx, PINx), die Vorgehensweise ist jedoch für alle Register (z.&nbsp;B. die des UART, ADC, SPI) analog.<br />
<br />
== Schreiben in Register ==<br />
<br />
Zum Schreiben kann man Register einfach wie eine Variable setzen.<ref>In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Schreibzugriff über die Funktion outp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt, outp() ist nicht mehr erforderlich.</ref><br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
/* Setzt das Richtungsregister des Ports A auf 0xff <br />
(alle Pins als Ausgang, vgl. Abschnitt Zugriff auf Ports): */<br />
DDRA = 0xff; <br />
<br />
/* Setzt PortA auf 0x03, Bit 0 und 1 "high", restliche "low": */<br />
PORTA = 0x03; <br />
<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binär 00011111 = Hexadezimal 1F<br />
DDRB = 0x1F; /* direkte Zuweisung - unübersichtlich */<br />
<br />
/* Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit<br />
aber übersichtlicher und selbsterklärend: */<br />
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);<br />
<br />
while (1);<br />
}<br />
</syntaxhighlight><br />
<br />
Die ausführliche Schreibweise sollte bevorzugt verwendet werden, da dadurch die Zuweisungen selbsterklärend sind und somit der Code leichter nachvollzogen werden kann. Atmel verwendet sie auch bei Beispielen in Datenblätten und in den allermeisten Quellcodes zu Application-Notes. Mehr zu der Schreibweise mit "|" und "<<" findet man unter [[Bitmanipulation]].<br />
<br />
Der gcc C-Compiler unterstützt ab Version 4.3.0 Konstanten im Binärformat, z.&nbsp;B. DDRB&nbsp;=&nbsp;0b00011111. Diese Schreibweise ist jedoch nur in GNU-C verfügbar und nicht in ISO-C definiert. Man sollte sie daher nicht verwenden, wenn Code mit anderen ausgetauscht oder mit anderen Compilern bzw. älteren Versionen des gcc genutzt werden soll.<br />
<br />
== Verändern von Registerinhalten ==<br />
<br />
Einzelne Bits setzt und löscht man "Standard-C-konform" mittels logischer (Bit-) Operationen. <br />
<br />
<syntaxhighlight lang="c"><br />
x |= (1 << Bitnummer); // Hiermit wird ein Bit in x gesetzt<br />
x &= ~(1 << Bitnummer); // Hiermit wird ein Bit in x geloescht<br />
</syntaxhighlight><br />
<br />
Es wird jeweils nur der Zustand des angegebenen Bits geändert, der vorherige Zustand der anderen Bits bleibt erhalten. <br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
#define MEINBIT 2<br />
...<br />
PORTA |= (1 << MEINBIT); /* setzt Bit 2 an PortA auf 1 */<br />
PORTA &= ~(1 << MEINBIT); /* loescht Bit 2 an PortA */<br />
</syntaxhighlight><br />
<br />
Mit dieser Methode lassen sich auch mehrere Bits eines Registers gleichzeitig setzen und löschen.<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
DDRA &= ~( (1<<PA0) | (1<<PA3) ); /* PA0 und PA3 als Eingaenge */<br />
PORTA |= ( (1<<PA0) | (1<<PA3) ); /* Interne Pull-Up fuer beide einschalten */<br />
</syntaxhighlight><br />
<br />
Bei bestimmten AVR Registern mit Bits, die durch Beschreiben mit einer logischen 1 gelöscht werden, muss eine absolute Zuweisung benutzt werden. Ein ODER löscht in diesen Registern ALLE gesetzten Bits!<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
TIFR2 = (1<<OCF2A); // Nur Bit OCF2A löschen<br />
</syntaxhighlight><br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind nicht mehr erforderlich.<br />
<br />
Siehe auch:<br />
* [[Bitmanipulation]]<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
<br />
== Lesen aus Registern ==<br />
<br />
Zum Lesen kann man auf Register einfach wie auf eine Variable zugreifen. In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Lesezugriff über die Funktion inp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt und inp() ist nicht mehr erforderlich.<br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdint.h><br />
<br />
uint8_t foo;<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
/* kopiert den Status der Eingabepins an PortB <br />
in die Variable foo: */<br />
foo = PINB; <br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Die Abfrage der Zustände von Bits erfolgt durch Einlesen des gesamten Registerinhalts und ausblenden der Bits deren Zustand nicht von Interesse ist. Einige Beispiele zum Prüfen ob Bits gesetzt oder gelöscht sind:<br />
<br />
<syntaxhighlight lang="c"><br />
#define MEINBIT0 0 <br />
#define MEINBIT2 2<br />
<br />
uint8_t i;<br />
<br />
extern test1();<br />
<br />
// Funkion test1 aufrufen, wenn Bit 0 in Register PINA gesetzt (1) ist<br />
i = PINA; // Inhalt in Arbeitsvariable<br />
i = i & 0x01; // alle Bits bis auf Bit 0 ausblenden (bitweise und)<br />
// falls das Bit gesetzt war, hat i den Inhalt 1<br />
if ( i != 0 ) { // Ergebnis ungleich 0 (wahr)? <br />
test1(); // dann muss Bit 0 in i gesetzt sein -> Funktion aufrufen<br />
}<br />
// verkürzt:<br />
if ( ( PINA & 0x01 ) != 0 ) {<br />
test1();<br />
}<br />
// nochmals verkürzt:<br />
if ( PINA & 0x01 ) {<br />
test1();<br />
}<br />
// mit definierter Bitnummer:<br />
if ( PINA & ( 1 << MEINBIT0 ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und/oder Bit 2 gesetzt ist. (Bit 0 und 2 also Wert 5) <br />
// (Bedenke: Bit 0 hat Wert 1, Bit 1 hat Wert 2 und Bit 2 hat Wert 4)<br />
if ( PINA & 0x05 ) {<br />
test1(); // Vergleich <> 0 (wahr), also mindestens eines der Bits gesetzt<br />
}<br />
// mit definierten Bitnummern:<br />
if ( PINA & ( ( 1 << MEINBIT0 ) | ( 1 << MEINBIT2 ) ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und Bit 2 gesetzt sind<br />
if ( ( PINA & 0x05 ) == 0x05 ) { // nur wahr, wenn beide Bits gesetzt<br />
test1();<br />
}<br />
<br />
// Funktion test2() aufrufen, wenn Bit 0 gelöscht (0) ist<br />
i = PINA; // einlesen in temporäre Variable<br />
i = i & 0x01; // maskieren von Bit 0<br />
if ( i == 0 ) { // Vergleich ist wahr, wenn Bit 0 nicht gesetzt ist<br />
test2();<br />
}<br />
// analog mit not-Operator<br />
if ( !i ) {<br />
test2();<br />
}<br />
// nochmals verkürzt:<br />
if ( !( PINA & 0x01 ) ) {<br />
test2();<br />
}<br />
</syntaxhighlight><br />
<br />
== Warten auf einen bestimmten Zustand ==<br />
<br />
Es gibt in der Bibliothek avr-libc Funktionen, die warten, bis ein bestimmter Zustand eines Bits erreicht ist. Es ist allerdings normalerweise eine eher unschöne Programmiertechnik, da in diesen Funktionen "blockierend" gewartet wird. Der Programmablauf bleibt also an dieser Stelle stehen, bis das maskierte Ereignis erfolgt ist. Setzt man den [[Watchdog]] ein, muss man darauf achten, dass dieser auch noch getriggert wird (Zurücksetzen des Watchdogtimers). <br />
<br />
Die Funktion '''loop_until_bit_is_set''' wartet in einer Schleife, bis das definierte Bit gesetzt ist. Wenn das Bit beim Aufruf der Funktion bereits gesetzt ist, wird die Funktion sofort wieder verlassen. Das niederwertigste Bit hat die Bitnummer 0. <br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 2 (das dritte Bit) in Register PINA gesetzt (1) ist */<br />
<br />
#define WARTEPIN PINA<br />
#define WARTEBIT PA2<br />
<br />
// mit der avr-libc Funktion:<br />
loop_until_bit_is_set(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// _nicht_ ungleich 0 (also 0) ist.<br />
while ( !(WARTEPIN & (1 << WARTEBIT)) ) {}<br />
...<br />
</syntaxhighlight><br />
<br />
<br />
Die Funktion '''loop_until_bit_is_clear''' wartet in einer Schleife, bis das definierte Bit gelöscht ist. Wenn das Bit beim Aufruf der Funktion bereits gelöscht ist, wird die Funktion sofort wieder verlassen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 4 (das fuenfte Bit) in Register PINB geloescht (0) ist */<br />
#define WARTEPIN PINB<br />
#define WARTEBIT PB4<br />
<br />
// avr-libc-Funktion:<br />
loop_until_bit_is_clear(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// gesetzt (1) ist <br />
while ( WARTEPIN & (1<<WARTEBIT) ) {}<br />
...<br />
</syntaxhighlight><br />
<br />
Universeller und auch auf andere Plattformen besser übertragbar ist die Verwendung von C-Standardoperationen.<br />
<br />
Siehe auch: <br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
* [[Bitmanipulation]]<br />
<br />
== 16-Bit Register (ADC, ICR1, OCR1x, TCNT1, UBRR) ==<br />
<br />
Einige der Portregister in den AVR-Controllern sind 16 Bit breit. Im Datenblatt sind diese Register üblicherweise mit dem Suffix "L" (Low-Byte) und "H" (High-Byte) versehen. Die avr-libc definiert zusätzlich die meisten dieser Variablen die Bezeichnung ohne "L" oder "H". Auf diese Register kann dann direkt zugegriffen werden. Dies ist zum Beispiel der Fall für Register wie ADC oder TCNT1.<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
uint16_t foo;<br />
<br />
/* setzt die Wort-Variable foo auf den Wert der letzten AD-Wandlung */<br />
foo = ADC; <br />
</syntaxhighlight><br />
<br />
Bei anderen Registern, wie zum Beispiel Baudraten-Register, liegen High- und Low-Teil nicht direkt nebeneinander im SFR-Bereich, so dass ein 16-Bit Zugriff nicht möglich ist und der Zugriff zusammengebastelt werden muss:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
...<br />
uint16_t baud = F_CPU / (UART_BAUD_RATE * 16L) -1;<br />
<br />
UBRRH = (uint8_t) (baud >> 8);<br />
UBRRL = (uint8_t) baud;<br />
...<br />
</syntaxhighlight><br />
<br />
Bei einigen AVR-Typen wie ATmega8 oder ATmega16 teilen sich UBRRH und UCSRC die gleiche Speicher-Adresse. Damit der AVR trotzdem zwischen den beiden Registern unterscheiden kann, bestimmt das Bit7 (URSEL), welches Register tatsächlich beschrieben werden soll. ''1000 0011'' (0x83) adressiert demnach UCSRC und übergibt den Wert ''3''. Und ''0000 0011'' (0x3) adressiert UBRRH und übergibt ebenfalls den Wert ''3''. <br />
<br />
Speziell bei den 16-Bit-Timern und auch beim ADC ist es bei allen Zugriffen auf Datenregister erforderlich, dass diese Daten synchronisiert sind. Wenn z.&nbsp;B. bei einem 16-Bit-Timer das High-Byte des Zählregisters gelesen wurde und vor dem Lesezugriff auf das Low-Byte ein Überlauf des Low-Bytes stattfindet, erhält man einen völlig unsinnigen Wert. Auch die Compare-Register müssen synchron geschrieben werden, da es ansonsten zu unerwünschten Compare-Ereignissen kommen kann. <br />
<br />
Beim ADC besteht das Problem darin, dass zwischen den Zugriffen auf die beiden Teilregister eine Wandlung beendet werden kann und der ADC ein neues Ergebnis in ADCL und ADCH schreiben will, wodurch High- und Low-Byte nicht zusammenpassen.<br />
<br />
Um diese Datenmüllproduktion zu verhindern, gibt es in beiden Fällen eine Synchronisation, die jeweils durch den Zugriff auf das Low-Byte ausgelöst wird:<br />
* Bei den Timer-Registern (das gilt für alle TCNT-, OCR- und ICR-Register bei den 16-Bit-Timern) wird bei einem ''Lesezugriff'' auf das Low-Byte automatisch das High-Byte in ein temporäres Register, das ansonsten nach außen nicht sichtbar ist, geschoben. Greift man nun ''anschließend'' auf das High-Byte zu, dann wird eben dieses temporäre Register gelesen.<br />
* Bei einem ''Schreibzugriff'' auf eines der genannten Register wird das High-Byte in besagtem temporären Register zwischengespeichert und erst beim Schreiben des Low-Bytes werden ''beide'' gleichzeitig in das eigentliche Register übernommen.<br />
<br />
Das bedeutet für die Reihenfolge:<br />
* Lesezugriff: Erst Low-Byte, dann High-Byte<br />
* Schreibzugriff: Erst High-Byte, dann Low-Byte<br />
<br />
Des weiteren ist zu beachten, dass es für all diese 16-Bit-Register nur ein einziges temporäres Register gibt, so dass das Auftreten eines Interrupts, in dessen Handler ein solches Register manipuliert wird, bei einem durch ihn unterbrochenen Zugriff i.d.R. zu Datenmüll führt. 16-Bit-Zugriffe sind generell nicht atomar! Wenn mit Interrupts gearbeitet wird, kann es erforderlich sein, vor einem solchen Zugriff auf ein 16-Bit-Register die Interrupt-Bearbeitung zu deaktivieren.<br />
<br />
Beim ADC-Datenregister ADCH/ADCL ist die Synchronisierung anders gelöst. Hier wird beim Lesezugriff (ADCH/ADCL sind logischerweise read-only) auf das Low-Byte ADCL beide Teilregister für Zugriffe seitens des ADC so lange gesperrt, bis das High-Byte ADCH ausgelesen wurde. Dadurch kann der ADC nach einem Zugriff auf ADCL keinen neuen Wert in ADCH/ADCL ablegen, bis ADCH gelesen wurde. Ergebnisse von Wandlungen, die zwischen einem Zugriff auf ADCL und ADCH beendet werden, gehen verloren!<br />
<br />
Nach einem Zugriff auf ADCL muss grundsätzlich ADCH gelesen werden!<br />
<br />
In beiden Fällen – also sowohl bei den Timern als auch beim ADC – werden vom C-Compiler 16-Bit Pseudo-Register zur Verfügung gestellt (z.&nbsp;B. TCNT1H/TCNT1L → TCNT1, ADCH/ADCL → ADC bzw. ADCW), bei deren Verwendung der Compiler automatisch die richtige Zugriffsreihenfolge regelt. In C-Programmen sollten grundsätzlich diese 16-Bit-Register verwendet werden! Sollte trotzdem ein Zugriff auf ein Teilregister erforderlich sein, sind obige Angaben zu berücksichtigen.<br />
<br />
Es ist darauf zu achten, dass auch ein Zugriff auf die 16-Bit-Register vom Compiler in zwei 8-Bit-Zugriffe aufgeteilt wird und dementsprechend genauso nicht-atomar ist wie die Einzelzugriffe. Auch hier gilt, dass u.U. die Interrupt-Bearbeitung gesperrt werden muss, um Datenmüll zu vermeiden.<br />
<br />
Beim ADC gibt es für den Fall, dass eine Auflösung von 8 Bit ausreicht, die Möglichkeit, das Ergebnis "linksbündig" in ADCH/ADCL auszurichten, so dass die relevanten 8 MSB in ADCH stehen. In diesem Fall muss bzw. sollte nur ADCH ausgelesen werden.<br />
<br />
ADC und ADCW sind unterschiedliche Bezeichner für das selbe Registerpaar. Üblicherweise kann man in C-Programmen ADC verwenden, was analog zu den anderen 16-Bit-Registern benannt ist. ADCW (ADC Word) existiert nur deshalb, weil die Headerdateien auch für Assembler vorgesehen sind und es bereits einen Assembler-Befehl namens ''adc'' gibt. <br />
<br />
Im Umgang mit 16-Bit Registern siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Related Pages/Frequently Asked Questions/Nr. 8<br />
* Datenblatt Abschnitt ''Accessing 16-bit Registers''<br />
<br />
== IO-Register als Parameter und Variablen ==<br />
<br />
Um Register als Parameter für eigene Funktionen übergeben zu können, muss man sie als einen volatile uint8_t Pointer übergeben. Zum Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <util/delay.h><br />
<br />
uint8_t key_pressed (volatile uint8_t *inputreg, uint8_t inputbit)<br />
{<br />
static uint8_t last_state = 0;<br />
<br />
if (last_state == (*inputreg & (1<<inputbit)))<br />
return 0; /* keine Änderung */<br />
<br />
/* Wenn doch, warten bis etwaiges Prellen vorbei ist: */<br />
_delay_ms(20);<br />
<br />
/* Zustand für nächsten Aufruf merken: */<br />
last_state = *inputreg & (1<<inputbit);<br />
<br />
/* und den entprellten Tastendruck zurückgeben: */<br />
return *inputreg & (1<<inputbit);<br />
}<br />
<br />
/* Beispiel für einen Funktionsaufruf: */<br />
<br />
void foo (void)<br />
{<br />
uint8_t i = key_pressed (&PINB, PB1);<br />
}<br />
</syntaxhighlight><br />
<br />
Ein Aufruf der Funktion mit call by value würde Folgendes bewirken: Beim Funktionseintritt wird nur eine Kopie des momentanen Portzustandes angefertigt, die sich unabhängig vom tatsächlichen Zustand das Ports nicht mehr ändert, womit die Funktion wirkungslos wäre. Die Übergabe eines Zeigers wäre die Lösung, wenn der Compiler nicht optimieren würde. Denn dadurch wird im Programm nicht von der Hardware gelesen, sondern wieder nur von einem Abbild im Speicher. Das Ergebnis wäre das gleiche wie oben. Mit dem Schlüsselwort volatile sagt man nun dem Compiler, dass die entsprechende Variable entweder durch andere Softwareroutinen (Interrupts) oder durch die Hardware verändert werden kann.<br />
<br />
Siehe auch: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass avr-libc FAQ: "How do I pass an IO port as a parameter to a function?"]<br />
<br />
= Zugriff auf IO-Ports =<br />
<br />
Jeder AVR implementiert eine unterschiedliche Menge an GPIO-Registern<br />
(GPIO - General Purpose Input/Output). Diese Register dienen dazu:<br />
* einzustellen welche der Anschlüsse ("Beinchen") des Controllers als Ein- oder Ausgänge dienen<br />
* bei Ausgängen deren Zustand festzulegen<br />
* bei Eingängen deren Zustand zu erfassen<br />
<br />
Mittels GPIO werden digitale Zustände gesetzt und erfasst, d.h. die Spannung an einem Ausgang wird ein- oder ausgeschaltet und an einem Eingang wird erfasst, ob die anliegende Spannung über oder unter einem bestimmten Schwellwert liegt. Im Datenblatt Abschnitt Electrical Characteristics/DC Characteristics finden sich die Spannungswerte (V_OL, V_OH für Ausgänge, V_IL, V_IH für Eingänge).<br />
<br />
Die Verarbeitung von analogen Eingangswerten und die Ausgabe von Analogwerten wird in Kapitel [[AVR-GCC-Tutorial#Analoge_Ein-_und_Ausgabe|Analoge Ein- und Ausgabe]] behandelt.<br />
<br />
Die physischen Ein- und Ausgänge werden bei AVR-Controllern zu logischen Ports gruppiert.<br />
<br />
Alle Ports werden über Register gesteuert. Dazu sind jedem Port 3 Register zugeordnet:<br />
<br />
{| class="wikitable"<br />
|- <br />
! width="10%"| DDRx<br />
| Datenrichtungsregister für Port'''x'''. <br />
'''x''' entspricht '''A''', '''B''', ''' C''' usw. je nach gewünschtem Port. Bit im Register gesetzt (1) für Ausgang, Bit gelöscht (0) für Eingang.<br />
|- <br />
! PINx<br />
| Eingangsadresse für Port'''x'''. <br />
Zustand des Ports. Die Bits in PINx entsprechen dem Zustand der als Eingang definierten Portpins. Bit 1 wenn Pin "high", Bit 0 wenn Portpin low.<br />
|-<br />
! PORTx<br />
| Datenregister für Port'''x'''. <br />
Dieses Register wird verwendet, um die Ausgänge eines Ports anzusteuern. Bei Pins, die mittels DDRx auf Eingang geschaltet wurden, können über PORTx<br />
die internen Pull-Up Widerstände aktiviert oder deaktiviert werden (1 = aktiv).<br />
|}<br />
<br />
Die folgenden Beispiele gehen von einem AVR aus, der sowohl Port A als auch Port B besitzt. Sie müssen für andere AVRs (zum Beispiel ATmega8/48/88/168) entsprechend angepasst werden.<br />
<br />
== Datenrichtung bestimmen ==<br />
<br />
Zuerst muss die Datenrichtung der verwendeten Pins bestimmt werden. Um dies zu erreichen, wird das Datenrichtungsregister des entsprechenden Ports beschrieben.<br />
<br />
Für jeden Pin, der als Ausgang verwendet werden soll, muss dabei das<br />
entsprechende Bit auf dem Port gesetzt werden. Soll der Pin als Eingang<br />
verwendet werden, muss das entsprechende Bit gelöscht sein.<br />
<br />
Beispiel:<br />
Angenommen am Port B sollen die Pins 0 bis 4 als Ausgänge definiert werden, die noch verbleibenden Pins 5 bis 7 sollen als Eingänge fungieren. Dazu ist es daher notwendig, im für das Port B zuständigen Datenrichtungsregister DDRB folgende Bitkonfiguration einzutragen<br />
<br />
+---+---+---+---+---+---+---+---+<br />
| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |<br />
+---+---+---+---+---+---+---+---+<br />
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br />
<br />
In C liest sich das dann so:<br />
<br />
<syntaxhighlight lang="c"><br />
// in io.h wird u.a. DDRB definiert:<br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binaer 00011111 = Hexadezimal 1F<br />
// direkte Zuweisung - standardkonform */<br />
DDRB = 0x1F; /* <br />
<br />
// Uebersichtliche Alternative - Binaerschreibweise, aber kein ISO-C<br />
DDRB = 0b00011111;<br />
<br />
// Ausfuehrliche Schreibweise: identische Funktionalitaet, mehr Tipparbeit<br />
// aber uebersichtlicher und selbsterklaerend:<br />
DDRB |= (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4); <br />
</syntaxhighlight><br />
<br />
Die Pins 5 bis 7 werden (da 0) als Eingänge geschaltet. Weitere Beispiele:<br />
<br />
<syntaxhighlight lang="c"><br />
// Alle Pins des Ports B als Ausgang definieren:<br />
DDRB = 0xff; <br />
// Pin0 wieder auf Eingang und andere im urspruenglichen Zustand belassen:<br />
DDRB &= ~(1 << DDB0);<br />
// Pin 3 und 4 auf Eingang und andere im urspruenglichen Zustand belassen:<br />
DDRB &= ~((1 << DDB3) | (1 << DDB4));<br />
// Pin 0 und 3 wieder auf Ausgang und andere im ursprünglichen Zustand belassen:<br />
DDRB |= (1 << DDB0) | (1 << DDB3);<br />
// Alle Pins auf Eingang:<br />
DDRB = 0x00;<br />
</syntaxhighlight><br />
<br />
== Vordefinierte Bitnummern für I/O-Register ==<br />
<br />
Die Bitnummern (z.&nbsp;B. PCx, PINCx und DDCx für den Port C) sind in den io*.h-Dateien der avr-libc definiert und dienen lediglich der besseren Lesbarkeit. Man muss diese Definitionen nicht verwenden oder kann auch einfach "immer" PAx, PBx, PCx usw. nutzen, auch wenn der Zugriff auf Bits in DDRx- oder PINx-Registern erfolgt. Für den Compiler sind die Ausdrücke (1<<PC7), (1<<DDC7) und (1<<PINC7) identisch zu (1<<7) (genauer: der Präprozessor ersetzt die Ausdrücke (1<<PC7),... zu (1<<7)). Ein Ausschnitt der Definitionen für Port C eines ATmega32 aus der iom32.h-Datei zur Verdeutlichung (analog für die weiteren Ports):<br />
<br />
<syntaxhighlight lang="c"><br />
...<br />
/* PORTC */<br />
#define PC7 7<br />
#define PC6 6<br />
#define PC5 5<br />
#define PC4 4<br />
#define PC3 3<br />
#define PC2 2<br />
#define PC1 1<br />
#define PC0 0<br />
<br />
/* DDRC */<br />
#define DDC7 7<br />
#define DDC6 6<br />
#define DDC5 5<br />
#define DDC4 4<br />
#define DDC3 3<br />
#define DDC2 2<br />
#define DDC1 1<br />
#define DDC0 0<br />
<br />
/* PINC */<br />
#define PINC7 7<br />
#define PINC6 6<br />
#define PINC5 5<br />
#define PINC4 4<br />
#define PINC3 3<br />
#define PINC2 2<br />
#define PINC1 1<br />
#define PINC0 0<br />
</syntaxhighlight><br />
<br />
<br />
== Digitale Signale ==<br />
<br />
Am einfachsten ist es, digitale Signale mit dem Mikrocontroller zu erfassen bzw. auszugeben.<br />
<br />
== Ausgänge ==<br />
Will man als Ausgang definierte Pins (entsprechende DDRx-Bits = 1) auf Logisch 1 setzen, setzt man die entsprechenden Bits im Portregister.<br />
<br />
Mit dem Befehl<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB = 0x04; /* besser PORTB=(1<<PB2) */<br />
<br />
// Uebersichtliche Alternative - Binaerschreibweise<br />
PORTB = 0b00000100; /* direkte Zuweisung - uebersichtlich */<br />
<br />
</syntaxhighlight><br />
wird also der Ausgang an Pin PB2 gesetzt (Beachte, dass die Bits immer ''von 0 an'' gezählt werden, das niederwertigste Bit ist also Bitnummer 0 und nicht etwa Bitnummer 1).<br />
<br />
Man beachte, dass bei der Zuweisung mittels '''=''' immer alle Pins gleichzeitig angegeben werden. Man sollte also, wenn nur bestimmte Ausgänge geschaltet werden sollen, zuerst den aktuellen Wert des Ports einlesen und das Bit des gewünschten Ports in diesen Wert einfließen lassen. Will man also nur den dritten Pin (Bit Nr. 2) an Port B auf "high" setzen und den Status der anderen Ausgänge unverändert lassen, nutze man diese Form:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB = PORTB | 0x04; /* besser: PORTB = PORTB | ( 1<<PB2 ) */<br />
/* vereinfacht durch Nutzung des |= Operators : */<br />
PORTB |= (1<<PB2);<br />
<br />
/* auch mehrere "gleichzeitig": */<br />
PORTB |= (1<<PB4) | (1<<PB5); /* Pins PB4 und PB5 "high" */<br />
</syntaxhighlight><br />
<br />
"Ausschalten", also Ausgänge auf "low" setzen, erfolgt analog:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB &= ~(1<<PB2); /* loescht Bit 2 in PORTB und setzt damit Pin PB2 auf low */ <br />
PORTB &= ~( (1<<PB4) | (1<<PB5) ); /* Pin PB4 und Pin PB5 "low" */<br />
</syntaxhighlight><br />
Siehe auch [[Bitmanipulation]]<br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind in aktuellen Versionen der avr-libc nicht mehr enthalten und auch nicht mehr erforderlich.<br />
<br />
''Falls der Anfangszustand von Ausgängen kritisch ist, muss die Reihenfolge beachtet werden, mit der die Datenrichtung (DDRx) eingestellt und der Ausgabewert (PORTx) gesetzt wird:''<br />
<br />
Für Ausgangspins, die mit Anfangswert "high" initialisiert werden sollen:<br />
* zuerst die Bits im PORTx-Register setzen<br />
* anschließend die Datenrichtung auf Ausgang stellen<br />
<br />
Daraus ergibt sich die Abfolge für einen Pin, der bisher als Eingang mit abgeschaltetem Pull-Up konfiguriert war:<br />
* setze PORTx: interner Pull-Up aktiv<br />
* setze DDRx: Ausgang ("high")<br />
<br />
Bei der Reihenfolge erst DDRx und dann PORTx kann es zu einem kurzen "low-Puls" kommen, der auch externe Pull-Up-Widerstände "überstimmt". Die (ungünstige) Abfolge: Eingang -> setze DDRx: Ausgang (auf "low", da PORTx nach Reset 0) -> setze PORTx: Ausgang auf high. Vergleiche dazu auch das Datenblatt Abschnitt ''Configuring the Pin''.<br />
<br />
== Eingänge (Wie kommen Signale in den &micro;C) ==<br />
<br />
Die digitalen Eingangssignale können auf verschiedene Arten zu unserer Logik gelangen.<br />
<br />
=== Signalkopplung ===<br />
<br />
Am einfachsten ist es, wenn die Signale direkt aus einer anderen digitalen Schaltung übernommen werden können. Hat der Ausgang der entsprechenden Schaltung TTL-Pegel dann können wir sogar direkt den Ausgang der Schaltung mit einem Eingangspin von unserem Controller verbinden.<br />
<br />
Hat der Ausgang der anderen Schaltung keinen TTL-Pegel so müssen wir den Pegel über entsprechende Hardware (z.&nbsp;B. Optokoppler, [[Widerstand#Spannungsteiler|Spannungsteiler]], "Levelshifter" aka [[Pegelwandler]]) anpassen.<br />
<br />
Die Masse der beiden Schaltungen muss selbstverständlich miteinander verbunden werden. Der Software selber ist es natürlich letztendlich egal, wie das Signal eingespeist wird. Wir können ja ohnehin lediglich prüfen, ob an einem Pin unseres Controllers eine logische 1 (Spannung größer ca. 0,7*Vcc) oder eine logische 0 (Spannung kleiner ca. 0,2*Vcc) anliegt. Detaillierte Informationen darüber, ab welcher Spannung ein Eingang als 0 ("low") bzw. 1 ("high") erkannt wird, liefert die Tabelle DC Characteristics im Datenblatt des genutzten Controllers.<br />
<br />
{| class="wikitable" style="text-align:center; width:20em"<br />
|+ '''Logikpegel'''<br />
|-<br />
! VCC [V]<br />
! Low [V]<br />
! High [V]<br />
|-<br />
! 5<br />
| 1,0 || 3,5<br />
|-<br />
! 3,3<br />
| 0,66 || 2,3<br />
|-<br />
! 1,8<br />
| 0,36 || 1,26 <br />
|}<br />
<br />
Die Abfrage der Zustände der Portpins erfolgt direkt über den Registernamen.<br />
<br />
{{Warnung|Dabei ist wichtig, zur Abfrage der Eingänge ''nicht'' etwa Portregister '''PORTx''' zu verwenden, sondern Eingangsregister '''PINx'''. Ansonsten liest man nicht den Zustand der Eingänge, sondern den Status der internen Pull-Up-Widerstände. Die Abfrage der Pinzustände über PORTx statt PINx ist ein häufiger Fehler beim AVR-"Erstkontakt".}}<br />
<br />
Will man also die aktuellen Signalzustände von Port D abfragen und in eine Variable namens bPortD abspeichern, schreibt man folgende Befehlszeilen:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdint.h><br />
...<br />
uint8_t bPortD;<br />
...<br />
bPortD = PIND;<br />
...<br />
</syntaxhighlight><br />
<br />
Mit den C-Bitoperationen kann man den Status der Bits abfragen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
/* Fuehre Aktion aus, wenn Bit Nr. 1 (das "zweite" Bit) in PINC gesetzt (1) ist */<br />
if ( PINC & (1<<PINC1) ) {<br />
/* Aktion */<br />
}<br />
<br />
/* Fuehre Aktion aus, wenn Bit Nr. 2 (das "dritte" Bit) in PINB geloescht (0) ist */<br />
if ( !(PINB & (1<<PINB2)) ) {<br />
/* Aktion */<br />
}<br />
...<br />
</syntaxhighlight><br />
Siehe auch [[Bitmanipulation#Bits_prüfen]]<br />
<br />
=== Interne Pull-Up Widerstände ===<br />
<br />
Portpins für Ein- und Ausgänge (GPIO) eines AVR verfügen über zuschaltbare interne Pull-Up Widerstände (nominal mehrere 10kOhm, z.&nbsp;B. ATmega16 20-50kOhm). Diese können in vielen Fällen statt externer Widerstände genutzt werden.<br />
<br />
Die internen Pull-Up Widerstände von Vcc zu den einzelnen Portpins werden über das Register ''' PORTx''' aktiviert bzw. deaktiviert, wenn ein Pin als ''' Eingang''' geschaltet ist.<br />
<br />
Wird der Wert des entsprechenden Portpins auf 1 gesetzt, so ist der Pull-Up Widerstand aktiviert. Bei einem Wert von 0 ist der Pull-Up Widerstand nicht aktiv. Man sollte jeweils entweder den internen oder einen externen Pull-Up Widerstand verwenden, aber nicht beide zusammen.<br />
<br />
Im Beispiel werden alle Pins des Ports D als Eingänge geschaltet und alle Pull-Up Widerstände aktiviert. Weiterhin wird Pin PC7 als Eingang geschaltet und dessen interner Pull-Up Widerstand aktiviert, ohne die Einstellungen für die anderen Portpins (PC0-PC6) zu verändern.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
DDRD = 0x00; /* alle Pins von Port D als Eingang */<br />
PORTD = 0xff; /* interne Pull-Ups an allen Port-Pins aktivieren */<br />
...<br />
DDRC &= ~(1<<PC7); /* Pin PC7 als Eingang */<br />
PORTC |= (1<<PC7); /* internen Pull-Up an PC7 aktivieren */<br />
</syntaxhighlight><br />
<br />
=== Taster und Schalter ===<br />
<br />
Der Anschluss mechanischer Kontakte an den Mikrocontroller, ist zwischen zwei unterschiedliche Methoden zu unterscheiden: ''Active Low'' und ''Active High''.<br />
<br />
<gallery widths="300" heights="300" caption="Anschluss mechanischer Kontakte an einen µC"><br />
Image:Active Low.gif|'''Active Low:''' Bei dieser Methode wird der Kontakt zwischen den Eingangspin des Controllers und Masse geschaltet. Damit bei offenem Schalter der Controller kein undefiniertes Signal bekommt, wird zwischen die Versorgungsspannung und den Eingangspin ein sogenannter '''Pull-Up''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffnetem Schalter auf logisch 1 zu ziehen.<br />
Image:Active High.gif|'''Active High:''' Hier wird der Kontakt zwischen die Versorgungsspannung und den Eingangspin geschaltet. Damit bei offener Schalterstellung kein undefiniertes Signal am Controller ansteht, wird zwischen den Eingangspin und die Masse ein '''Pull-Down''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffneter Schalterstellung auf logisch 0 zu halten. <br />
</gallery><br />
<br />
Der Widerstandswert von Pull-Up- und Pull-Down-Widerständen ist an sich nicht kritisch. Wird er allerdings zu hoch gewählt, ist die Wirkung eventuell nicht gegeben. Als üblicher Wert haben sich 10 kOhm eingebürgert. Die AVRs verfügen an den meisten Pins über zuschaltbare interne Pull-Up Widerstände (vgl. Abschnitt [[AVR-GCC-Tutorial#Interne Pull-Up Widerstände|Interne Pull-Up Widerstände]]), welche insbesondere wie hier bei Tastern und ähnlichen Bauteilen (z.&nbsp;B. Drehgebern) statt externer Bauteile verwendet werden können. Interne Pull-Down-Widerstand sind nicht verfügbar und müssen daher in Form zusätzlicher Bauteile in die Schaltung eingefügt werden.<br />
<br />
==== Taster entprellen ====<br />
<br />
Siehe: ''[[Entprellung#Warteschleifen-Verfahren|Entprellung: Warteschleifen-Verfahren]]<br />
<br />
= Warteschleifen (delay.h) =<br />
<br />
Der Programmablauf kann verschiedene Arten von Wartefunktionen erfordern:<br />
<br />
* Warten im Sinn von Zeitvertrödeln<br />
* Warten auf einen bestimmten Zustand an den I/O-Pins<br />
* Warten auf einen bestimmten Zeitpunkt (siehe Timer)<br />
* Warten auf einen bestimmten Zählerstand (siehe Counter)<br />
<br />
Der einfachste Fall, das Zeitvertrödeln, kann in vielen Fällen und mit großer Genauigkeit anhand der avr-libc Bibliotheksfunktionen _delay_ms() und _delay_us() erledigt werden. Die Bibliotheksfunktionen sind einfachen Zählschleifen (Warteschleifen) vorzuziehen, da leere Zählschleifen ohne besondere Vorkehrungen sonst bei eingeschalteter Optimierung vom avr-gcc-Compiler wegoptimiert werden. Weiterhin sind die Bibliotheksfunktionen bereits darauf vorbereitet, die in F_CPU definierte Taktfrequenz zu verwenden. Außerdem sind die Funktionen der Bibliothek wirklich getestet.<br />
<br />
Einfach!? Schon, aber während gewartet wird, macht der µC nichts anderes mehr (abgesehen von möglicherweise auftretenden Interrupts, falls welche aktiviert sind). Die Wartefunktion blockiert den Programmablauf. Möchte man einerseits warten, um z.&nbsp;B. eine LED blinken zu lassen und gleichzeitig andere Aktionen ausführen z.&nbsp;B. weitere LED bedienen, sollten die Timer/Counter des AVR verwendet werden, siehe Artikel [[Multitasking]].<br />
<br />
Die Bibliotheksfunktionen funktionieren allerdings nur dann korrekt, wenn sie mit zur Übersetzungszeit (beim Compilieren) bekannten konstanten Werten aufgerufen werden. Der Quellcode muss mit eingeschalteter Optimierung übersetzt werden, sonst wird sehr viel Maschinencode erzeugt, und die Wartezeiten stimmen nicht mehr mit dem Parameter überein.<br />
<br />
Eine weitere Einschränkung liegt darin, daß sie möglicherweise länger warten, als erwartet, nämlich in dem Fall, daß Interrupts auftreten und die _delay...()-Funktion unterbrechen. Genau genommen warten diese nämlich nicht eine bestimmte Zeit, sondern verbrauchen eine bestimmte Anzahl von Prozessortakten. Die wiederum ist so bemessen, daß ohne Unterbrechung durch Interrupts die gewünschte Wartezeit erreicht wird.<br />
Wird das Warten aber durch eine oder mehrere ISR unterbrochen, die zusammen 1% Prozessorzeit verbrauchen, dann dauert das Warten etwa 1% länger. Bei 50% Last durch die ISR dauert das Warten doppelt solange wie gewünscht, bei 90% zehnmal solange...<br />
<br />
Abhängig von der Version der Bibliothek verhalten sich die Bibliotheksfunktionen etwas unterschiedlich.<br />
<br />
== avr-libc Versionen bis 1.6 ==<br />
<br />
Die Wartezeit der Funktion _delay_ms() ist auf 262,14ms/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 13,1ms warten. Die Wartezeit der Funktion _delay_us() ist auf 768us/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 38,4µs warten. Längere Wartezeiten müssen dann über einen mehrfachen Aufruf in einer Schleife gelöst werden.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.&nbsp;B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h> /* in älteren avr-libc Versionen <avr/delay.h> */ <br />
<br />
/*<br />
lange, variable Verzögerungszeit, Einheit in Millisekunden<br />
<br />
Die maximale Zeit pro Funktionsaufruf ist begrenzt auf <br />
262.14 ms / F_CPU in MHz (im Beispiel: <br />
262.1 / 3.6864 = max. 71 ms) <br />
<br />
Daher wird die kleine Warteschleife mehrfach aufgerufen,<br />
um auf eine längere Wartezeit zu kommen. Die zusätzliche <br />
Prüfung der Schleifenbedingung lässt die Wartezeit geringfügig<br />
ungenau werden (macht hier vielleicht 2-3ms aus).<br />
*/<br />
<br />
void long_delay(uint16_t ms)<br />
{<br />
for(; ms>0; ms--) _delay_ms(1);<br />
}<br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) // Endlosschleife<br />
{ <br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.&nbsp;B. angeschlossene LED<br />
long_delay(1000); // Eine Sekunde warten...<br />
}<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
== avr-libc Versionen ab 1.7 ==<br />
<br />
_delay_ms() kann mit einem Argument bis 6553,5 ms (= 6,5535 Sekunden) benutzt werden. Es ist nicht möglich, eine Variable als Argument zu übergeben. Wird die früher gültige Grenze von 262,14 ms/F_CPU (in MHz) überschritten, so arbeitet _delay_ms() einfach etwas ungenauer und zählt nur noch mit einer Auflösung von 1/10 ms. Eine Verzögerung von 1000,10 ms ließe sich nicht mehr von einer von 1000,19 ms unterscheiden. Ein Verlust, der sich im Allgemeinen verschmerzen lässt. Dem Programmierer wird keine Rückmeldung gegeben, dass die Funktion ggf. gröber arbeitet, d.h. wenn es darauf ankommt, bitte den Parameter wie bisher geschickt wählen.<br />
<br />
Die Funktion _delay_us() wurde ebenfalls erweitert. Wenn deren maximal als genau behandelbares Argument überschritten wird, benutzt diese intern _delay_ms(). Damit gelten in diesem Fall die _delay_ms() Einschränkungen.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus, avr-libc ab Version 1.6<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h><br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) { // Endlosschleife<br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED<br />
_delay_ms(1000); // Eine Sekunde +/-1/10000 Sekunde warten...<br />
// funktioniert nicht mit Bibliotheken vor 1.6<br />
<br />
}<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
Die _delay_ms() und die _delay_us aus '''avr-libc 1.7.0''' sind fehlerhaft. _delay_ms () läuft 4x schneller als erwartet. Abhilfe ist eine korrigierte Includedatei: [http://www.mikrocontroller.net/topic/196738#1943039]<br />
<br />
= Programmieren mit Interrupts =<br />
<br />
<div style="float:right; margin:2em;"><br />
[[Image:Interrupt Programme.gif]]<br />
</div><br />
Nachdem wir nun alles Wissenswerte für die serielle Programmerstellung<br />
gelernt haben nehmen wir jetzt ein völlig anderes Thema in Angriff, nämlich<br />
die Programmierung unter Zuhilfenahme der Interrupts des AVR.<br />
<br />
Tritt ein Interrupt auf, unterbricht (engl. interrupts) der Controller die Verarbeitung des Hauptprogramms und verzweigt zu einer Interruptroutine. Das Hauptprogramm wird also beim Eintreffen eines Interrupts unterbrochen, die Interruptroutine ausgeführt und danach erst wieder das Hauptprogramm an der Unterbrechungsstelle fortgesetzt (vgl. die Abbildung).<br />
<br />
Um Interrupts verarbeiten zu können, ist folgendes zu beachten:<br />
<br />
* Für jede aktivierte Interruptquelle ist eine Funktion zu programmieren, in der die beim Auftreten des jeweiligen Interrupts erforderlichen Verarbeitungsschritte enthalten sind. Für diese Funktion existieren verschiedene Bezeichnungen. Üblich sind die englischen Begriffe Interrupt-Handler oder Interrupt-Service-Routinen (ISR), man findet aber auch die Bezeichnungen Interruptverarbeitungs- oder -behandlungsroutine oder auch kurz Interruptroutine. Zum Beispiel wird üblicherweise in der ISR zur Verarbeitung des Empfangsinterrupts eines UARTs (UART-RX Interrupt) das empfangene Zeichen in einen Zwischenspeicher (FIFO-Buffer) kopiert, dessen Inhalt später von anderen Programmteilen geleert wird. Sofern der Zwischenspeicher ausreichend groß ist, geht also kein Zeichen verloren, auch wenn im Hauptprogramm zeitintensive Operationen durchgeführt werden.<br />
* Die benötigten Interrupts sind in den jeweiligen Funktionsbausteinen einzuschalten. Dies erfolgt über das jeweilige Aktivierungsbit (Interrupt Enable) in einem der Hardwareregister (z.B. RX(Complete)Interrupt Enable eines UARTs)<br />
* Sämtliche Interrupts werden über einen weiteren globalen Schalter aktiviert und deaktiviert. Zur Verarbeitung der Interrupts ist dieser Schalter zu aktivieren (sei(), siehe unten).<br />
<br />
Alle Punkte sind zu beachten. Fehlt z.B. die globale Aktivierung, werden Interruptroutinen auch dann nicht aufgerufen, wenn sie im Funktionsbaustein eingeschaltet sind und eine Behandlungsroutine verhanden ist.<br />
<br />
Siehe auch<br />
<br />
* [http://www.mikrocontroller.net/forum/read-1-235092.html#new Ausführlicher Thread im Forum]<br />
* Artikel [[Interrupt]]<br />
* Artikel [[Multitasking]]<br />
{{Clear}}<br />
<br />
== Anforderungen an Interrupt-Routinen ==<br />
<br />
Um unliebsamen Überraschungen vorzubeugen, sollten einige Grundregeln bei der Implementierung der Interruptroutinen beachtet werden. Interruptroutinen sollten möglichst kurz und schnell abarbeitbar sein, daraus folgt:<br />
<br />
* Keine umfangreichen Berechnungen innerhalb der Interruptroutine. (*)<br />
* Keine langen Programmschleifen.<br />
* Obwohl es möglich ist, während der Abarbeitung einer Interruptroutine andere oder sogar den gleichen Interrupt wieder zuzulassen, wird davon ohne genaue Kenntnis der internen Abläufe dringend abgeraten.<br />
<br />
Interruptroutinen (ISRs) sollten also möglichst kurz sein und keine Schleifen mit vielen Durchläufen enthalten. Längere Operationen können meist in einen "Interrupt-Teil" in einer ISR und einen "Arbeitsteil" im Hauptprogramm aufgetrennt werden. Z.B. Speichern des Zustands aller Eingänge im EEPROM in bestimmten Zeitabständen: ISR-Teil: Zeitvergleich (Timer,RTC) mit Logzeit/-intervall. Bei Übereinstimmung ein globales Flag setzen (volatile bei Flag-Deklaration nicht vergessen, s.u.). Dann im Hauptprogramm prüfen, ob das Flag gesetzt ist. Wenn ja: die Daten im EEPROM ablegen und Flag löschen.<br />
<br />
(*)<br />
Hinweis: <br />
Es gibt allerdings die seltene Situation, dass man gerade eingelesene<br />
ADC-Werte sofort verarbeiten muss. Besonders dann, wenn man mehrere Werte sehr<br />
schnell hintereinander bekommt. Dann bleibt einem nichts anderes übrig, als die<br />
Werte noch in der ISR zu verarbeiten. Kommt aber sehr selten vor und sollte<br />
durch geeignete Wahl des Systemtaktes bzw. Auswahl des Controllers vermieden werden!<br />
<br />
== Interrupt-Quellen ==<br />
<br />
Die folgenden Ereignisse können einen Interrupt auf einem AVR AT90S2313 auslösen, wobei die Reihenfolge der Auflistung auch die Priorität der Interrupts aufzeigt.<br />
<br />
* Reset<br />
* Externer Interrupt 0<br />
* Externer Interrupt 1<br />
* Timer/Counter 1 Capture Ereignis<br />
* Timer/Counter 1 Compare Match<br />
* Timer/Counter 1 Überlauf<br />
* Timer/Counter 0 Überlauf<br />
* UART Zeichen empfangen<br />
* UART Datenregister leer<br />
* UART Zeichen gesendet<br />
* Analoger Komparator<br />
<br />
Die Anzahl der möglichen Interruptquellen variiert zwischen den verschiedenen Microcontroller-Typen. Im Zweifel hilft ein Blick ins Datenblatt ("Interrupt Vectors").<br />
<br />
== Register ==<br />
<br />
Der AT90S2313 verfügt über 2 Register die mit den<br />
Interrupts zusammenhängen.<br />
<br />
{| class="wikitable"<br />
|- <br />
!width="10%"| GIMSK<br />
| '''G'''eneral '''I'''nterrupt '''M'''a'''sk''' Register.<br /><br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit <br />
| 7 || 6|| 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INT1''' || '''INT0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INT1''' (External '''Int'''errupt Request '''1''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT1'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
'''INT0''' (External '''Int'''errupt Request '''0''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT0'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
|- <br />
! GIFR<br />
| '''G'''eneral '''I'''nterrupt '''F'''lag '''R'''egister.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INTF1''' || '''INTF0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INTF1''' (External '''Int'''errupt Flag '''1''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT1'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
<br />
'''INTF0''' (External '''Int'''errupt Flag '''0''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT0'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
|- <br />
! MCUCR<br />
| '''MCU''' '''C'''ontrol '''R'''egister.<br />
<br />
Das MCU Control Register enthält Kontrollbits für allgemeine MCU-Funktionen.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''-'''|| '''-'''|| '''SE'''|| '''SM'''|| '''ISC11'''|| '''ISC10'''|| '''ISC01'''|| '''ISC00'''<br />
|- <br />
! R/W<br />
| R || R || R/W || R/W || R/W || R/W || R/W || R/W<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
<br />
|}<br />
<br />
'''SE''' ('''S'''leep '''E'''nable)<br />
:Dieses Bit muss gesetzt sein, um den Controller mit dem '''SLEEP'''-Befehl in den Schlafzustand versetzen zu können.<br />
:Um den Schlafmodus nicht irrtümlich einzuschalten, wird empfohlen, das Bit erst unmittelbar vor Ausführung des '''SLEEP'''-Befehls zu setzen.<br />
<br />
'''SM''' ('''S'''leep '''M'''ode)<br />
:Dieses Bit bestimmt über den Schlafmodus.<br />
:Ist das Bit gelöscht, so wird der '''Idle'''-Modus ausgeführt. Ist das Bit gesetzt, so wird der '''Power-Down'''-Modus ausgeführt. (für andere AVR Controller siehe Abschnitt "Sleep-Mode")<br />
<br />
'''ISC11''', '''ISC10''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''1''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT1'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
!width="10%"| ISC11 ||width="10%"| ISC10 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT1''' erzeugt einen Interrupt.<br />
<br />
Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|}<br />
<br />
'''ISC01''', '''ISC00''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''0''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT0'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
!width="10%"| ISC01 ||width="10%"| ISC00 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT0''' erzeugt einen Interrupt.<br />
<br />
Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|}<br />
<br />
|}<br />
<br />
== Allgemeines über die Interrupt-Abarbeitung ==<br />
<br />
Wenn ein Interrupt eintrifft, wird automatisch das '''Global Interrupt Enable''' Bit im Status Register '''SREG''' gelöscht und alle weiteren Interrupts unterbunden. Dieses wird automatisch wieder gesetzt, wenn die Interruptroutine beendet wird. Wenn in der Zwischenzeit weitere Interrupts eintreffen, werden die zugehörigen Interrupt-Bits gesetzt und die Interrupts bei Beendigung der laufenden Interrupt-Routine in der Reihenfolge ihrer Priorität ausgeführt. Dies kann<br />
eigentlich nur dann zu Problemen führen, wenn ein hoch priorisierter Interrupt ständig und in kurzer Folge auftritt. Dieser sperrt dann möglicherweise alle anderen Interrupts mit niedrigerer Priorität. Dies ist einer der Gründe, weshalb die Interrupt-Routinen sehr kurz gehalten werden sollen. Es ist möglich das GIE-Bit in der ISR zu setzen und so schon wieder weitere Interrupts zuzulassen - allerdings sollte man damit vorsichtig sein und genau wissen was man damit macht. Kritisch wird es vor allem wenn der gleiche Interrupt noch einmal kommt, bevor die ISR abgearbeitet ist. <br />
<br />
<!-- === Das Status-Register ===<br />
<br />
Es gilt auch zu beachten, dass das Status-Register während der Abarbeitung einer Interruptroutine nicht automatisch gesichert wird. Falls notwendig, muss dies vom Programmierer selber vorgesehen werden. --><br />
<br />
== Interrupts mit avr-gcc ==<br />
<br />
<!-- ''Anmerkung eines Nutzers: Ich habe mir das Thema hier angearbeitet und hatte am Anfang starke Probleme: Jeder Interrupt muss nochmals einzeln aktiviert werden. Es reicht nicht nur per ''sei()'' die Interrupts global zu aktiveren.'' - mthomas: Hoffentlich duch die modifizerte Einleitung etwas offensichtlicher erläutert. Ansonsten bitte per Eintrag auf die Diskussionseite nochmals melden) --> <br />
<!-- Selbstverständlich können alle interruptspezifischen Registerzugriffe wie gewohnt über I/O-Adressierung vorgenommen werden. Etwas einfacher geht es jedoch, wenn wir die vom Compiler zur Verfügung gestellten Mittel einsetzen.--><br />
Funktionen zur Interrupt-Verarbeitung werden in den Includedateien ''interrupt.h'' der avr-libc zur Verfügung gestellt (bei älterem Quellcode zusätzlich ''signal.h'').<br />
<br />
<syntaxhighlight lang="c"><br />
// fuer sei(), cli() und ISR():<br />
#include <avr/interrupt.h><br />
</syntaxhighlight><br />
<br />
Das Makro '''sei()''' schaltet die Interrupts ein. Eigentlich wird nichts anderes gemacht, als das '''Global Interrupt Enable''' Bit im Status Register gesetzt.<br />
<br />
<syntaxhighlight lang="c"><br />
sei();<br />
</syntaxhighlight><br />
<br />
Das Makro '''cli()''' schaltet die Interrupts aus, oder anders gesagt, das '''Global Interrupt Enable''' Bit im Status Register wird gelöscht.<br />
<br />
<syntaxhighlight lang="c"><br />
cli();<br />
</syntaxhighlight><br />
<br />
Oft steht man vor der Aufgabe, dass eine Codesequenz nicht unterbrochen werden darf. Es liegt dann nahe, zu Beginn dieser Sequenz ein cli() und am Ende ein sei() einzufügen. Dies ist jedoch ungünstig, wenn die Interrupts vor Aufruf der Sequenz deaktiviert waren und danach auch weiterhin deaktiviert bleiben sollen. Ein sei() würde ungeachtet des vorherigen Zustands die Interrupts aktivieren, was zu unerwünschten Seiteneffekten führen kann. Die aus dem folgenden Beispiel ersichtliche Vorgehensweise ist in solchen Fällen vorzuziehen:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <inttypes.h><br />
<br />
//...<br />
<br />
void NichtUnterbrechenBitte(void)<br />
{<br />
uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister<br />
<br />
tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) sichern<br />
cli(); // Interrupts global deaktivieren<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
/* Beispiel Anfang<br />
JTAG-Interface eines ATmega16 per Software deaktivieren <br />
und damit die JTAG-Pins an PORTC für "general I/O" nutzbar machen<br />
ohne die JTAG-Fuse-Bit zu aendern. Dazu ist eine "timed sequence"<br />
einzuhalten (vgl Datenblatt ATmega16, Stand 10/04, S. 229): <br />
Das JTD-Bit muss zweimal innerhalb von 4 Taktzyklen geschrieben <br />
werden. Ein Interrupt zwischen den beiden Schreibzugriffen wuerde <br />
die erforderliche Sequenz "brechen", das JTAG-Interface bliebe<br />
weiterhin aktiv und die IO-Pins weiterhin für JTAG reserviert. */<br />
<br />
MCUCSR |= (1<<JTD);<br />
MCUCSR |= (1<<JTD); // 2 mal in Folge ,vgl. Datenblatt fuer mehr Information<br />
<br />
/* Beispiel Ende */<br />
<br />
SREG = tmp_sreg; // Status-Register wieder herstellen <br />
// somit auch das I-Flag auf gesicherten Zustand setzen<br />
}<br />
<br />
void NichtSoGut(void)<br />
{<br />
cli();<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
sei();<br />
}<br />
<br />
<br />
int main(void)<br />
{<br />
//...<br />
<br />
cli(); <br />
// Interrupts global deaktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// auch nach Aufruf der Funktion deaktiviert<br />
<br />
sei();<br />
// Interrupts global aktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// weiterhin aktiviert<br />
//...<br />
<br />
/* Verdeutlichung der unguenstigen Vorgehensweise mit cli/sei: */<br />
cli(); <br />
// Interrupts jetzt global deaktiviert <br />
<br />
NichtSoGut();<br />
// nach Aufruf der Funktion sind Interrupts global aktiviert <br />
// dies ist mglw. ungewollt!<br />
//...<br />
<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
<!-- mt: besser so nicht(?), lieber "datenblattkonform"<br />
<br />
<font face="Courier New">'''timer_enable_int (unsigned char ints);<br /><br />
'''</font>Schaltet Timerbezogene Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle<br />
Timerinterrupts ausgeschaltet, ansonsten muss in '''ints''' angegeben werden,<br />
welche Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">timer_enable_int (1 << TOIE1));<br /><br />
</font>'''Achtung: Wenn ein Timerinterrupt eingeschaltet wird während ein<br />
anderer Timerinterrupt bereits läuft, dann müssen beide Bits angegeben werden<br />
sonst wird der andere Timerinterrupt versehentlich ausgeschaltet.<br />
<br />
<font face="Courier New">'''enable_external_int (unsigned char ints);<br /><br />
'''</font>Schaltet die externen Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle externen<br />
Interrrups ausgeschaltet, ansonsten muss in '''ints''' angegeben werden, welche<br />
Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">enable_external_int ((1<<br />
</font>'''Schaltet die externen Interrupts 0 und 1 ein.<br />
<br />
Nachdem nun die Interrupts aktiviert sind, braucht es selbstverständlich noch den auszuführenden Code, der ablaufen soll, wenn ein Interrupt eintrifft.<br />
--><br />
Zu den aktivierten Interrupts ist eine Funktion zu programmieren, deren Code aufgerufen wird, wenn der betreffende Interrupt auftritt (Interrupt-Handler, Interrupt-Service-Routine). Dazu existiert die Definition (ein Makro) '''ISR'''.<br />
<br />
=== ISR ===<br />
<br />
(''ISR()'' ersetzt bei neueren Versionen der avr-libc ''SIGNAL()''. SIGNAL sollte nicht mehr genutzt werden, zur Portierung von SIGNAL nach ISR siehe den [[AVR-GCC-Tutorial#Anhang|Anhang]].)<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
//...<br />
ISR(Vectorname) /* vormals: SIGNAL(siglabel) dabei Vectorname != siglabel ! */<br />
{<br />
/* Interrupt Code */<br />
}<br />
</syntaxhighlight><br />
<br />
Mit ''ISR'' wird eine Funktion für die Bearbeitung eines Interrupts eingeleitet. Als Argument muss dabei die Benennung des entsprechenden Interruptvektors angegeben werden. Diese sind in den jeweiligen Includedateien IOxxxx.h zu finden. Die Bezeichnung entspricht dem Namen aus dem Datenblatt, bei dem die Leerzeichen durch Unterstriche ersetzt sind und ein ''_vect'' angehängt ist.<br />
<br />
Als Beispiel ein Ausschnitt aus der Datei für den ATmega8 (bei WinAVR Standardinstallation in C:\WinAVR\avr\include\avr\iom8.h) in der neben den aktuellen Namen für ''ISR'' (*_vect) noch die Bezeichnungen für das inzwischen nicht mehr aktuelle ''SIGNAL'' (SIG_*) enthalten sind.<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
/* $Id: iom8.h,v 1.13 2005/10/30 22:11:23 joerg_wunsch Exp $ */<br />
<br />
/* avr/iom8.h - definitions for ATmega8 */<br />
//...<br />
<br />
/* Interrupt vectors */<br />
<br />
/* External Interrupt Request 0 */<br />
#define INT0_vect _VECTOR(1)<br />
#define SIG_INTERRUPT0 _VECTOR(1)<br />
<br />
/* External Interrupt Request 1 */<br />
#define INT1_vect _VECTOR(2)<br />
#define SIG_INTERRUPT1 _VECTOR(2)<br />
<br />
/* Timer/Counter2 Compare Match */<br />
#define TIMER2_COMP_vect _VECTOR(3)<br />
#define SIG_OUTPUT_COMPARE2 _VECTOR(3)<br />
<br />
/* Timer/Counter2 Overflow */<br />
#define TIMER2_OVF_vect _VECTOR(4)<br />
#define SIG_OVERFLOW2 _VECTOR(4)<br />
<br />
/* Timer/Counter1 Capture Event */<br />
#define TIMER1_CAPT_vect _VECTOR(5)<br />
#define SIG_INPUT_CAPTURE1 _VECTOR(5)<br />
<br />
/* Timer/Counter1 Compare Match A */<br />
#define TIMER1_COMPA_vect _VECTOR(6)<br />
#define SIG_OUTPUT_COMPARE1A _VECTOR(6)<br />
<br />
/* Timer/Counter1 Compare Match B */<br />
#define TIMER1_COMPB_vect _VECTOR(7)<br />
#define SIG_OUTPUT_COMPARE1B _VECTOR(7)<br />
<br />
//...<br />
</syntaxhighlight><br />
<br />
<!--Vor Nutzung von SIGNAL muss ebenfalls die Header-Datei signal.h eingebunden werden.--> <br />
Mögliche Funktionsrümpfe für Interruptfunktionen sind zum Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
/* veraltet: #include <avr/signal.h> */<br />
<br />
ISR(INT0_vect) /* veraltet: SIGNAL(SIG_INTERRUPT0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(TIMER0_OVF_vect) /* veraltet: SIGNAL(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(USART_RXC_vect) /* veraltet: SIGNAL(SIG_UART_RECV) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
// und so weiter und so fort...<br />
</syntaxhighlight><br />
<br />
Auf die korrekte Schreibweise der Vektorbezeichnung ist zu achten. Der gcc-Compiler prüft erst ab Version 4.x, ob ein Signal/Interrupt der angegebenen Bezeichnung tatsächlich in der Includedatei definiert ist und gibt andernfalls eine Warnung aus. Bei WinAVR (ab 2/2005) wurde die Überprüfung auch in den mitgelieferten Compiler der Version 3.x integriert. Aus dem gcc-Quellcode Version 3.x selbst erstellte Compiler enthalten die Prüfung nicht (vgl. [[AVR-GCC]]). <br />
<br />
Während der Ausführung der Funktion sind alle weiteren Interrupts automatisch gesperrt. Beim Verlassen der Funktion werden die Interrupts wieder zugelassen.<br />
<br />
Sollte während der Abarbeitung der Interruptroutine ein weiterer Interrupt (gleiche oder andere Interruptquelle) auftreten, so wird das entsprechende Bit im zugeordneten Interrupt Flag Register gesetzt und die entsprechende Interruptroutine automatisch nach dem Beenden der aktuellen Funktion aufgerufen.<br />
<br />
Ein Problem ergibt sich eigentlich nur dann, wenn während der Abarbeitung der aktuellen Interruptroutine mehrere gleichartige Interrupts auftreten. Die entsprechende Interruptroutine wird im Nachhinein zwar aufgerufen jedoch wissen wir nicht, ob nun der entsprechende Interrupt einmal, zweimal oder gar noch öfter aufgetreten ist. Deshalb soll hier noch einmal betont werden, dass Interruptroutinen so schnell wie nur irgend möglich wieder verlassen werden sollten.<br />
<br />
=== Unterbrechbare Interruptroutinen ===<br />
<br />
"Faustregel": im Zweifel '''ISR'''. Die nachfolgend beschriebene Methode nur dann verwenden, wenn man sich über die unterschiedliche Funktionsweise im Klaren ist.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
<br />
ISR(XXX,ISR_NOBLOCK) /* veraltet: INTERRUPT(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt-Code */<br />
}<br />
</syntaxhighlight><br />
<br />
Hierbei steht XXX für den oben beschriebenen Namen des Vektors (also z.&nbsp;B. ''TIMER0_OVF_vect''). Der Unterschied im Vergleich zu einer herkömmlichen ISR ist, dass hier beim Aufrufen der Funktion das '''Global Enable Interrupt''' Bit durch Einfügen einer SEI-Anweisung direkt wieder gesetzt und somit alle Interrupts zugelassen werden &ndash; auch XXX-Interrupts. <br />
<br />
Bei unsachgemässer Handhabung kann dies zu erheblichen Problemen durch Rekursion wie einem Stack-Overflow oder anderen unerwarteten Effekten führen und sollte wirklich nur dann eingesetzt werden, wenn man sich sicher ist, das Ganze auch im Griff zu haben.<br />
<br />
Insbesondere sollte möglichst am ISR-Anfang die auslösende IRQ-Quelle deaktiviert und erst am Ende der ISR wieder aktiviert werden. Robuster als die Verwendung einer NOBLOCK-ISR ist daher folgender ISR-Aufbau:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
<br />
ISR (XXX) <br />
{<br />
// Implementiere die ISR ohne zunaechst weitere IRQs zuzulassen<br />
<br />
<<Deaktiviere die XXX-IRQ>><br />
<br />
// Erlaube alle Interrupts (ausser XXX)<br />
sei();<br />
<br />
//... Code ...<br />
<br />
// IRQs global deaktivieren um die XXX-IRQ wieder gefahrlos <br />
// aktivieren zu koennen<br />
cli();<br />
<br />
<<Aktiviere die XXX-IRQ>><br />
}<br />
</syntaxhighlight><br />
Auf diese Weise kann sich die XXX-IRQ nicht selbst unterbrechen, was zu einer Art Endlosschleife führen würde.<br />
<br />
Siehe auch: Hinweise in [[AVR-GCC]]<br />
<br />
siehe dazu: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html<br />
<br />
== Datenaustausch mit Interrupt-Routinen ==<br />
<br />
Variablen, die sowohl in Interrupt-Routinen (ISR = Interrupt Service Routine(s)) als auch vom übrigen Programmcode geschrieben oder gelesen werden, müssen mit einem '''volatile''' deklariert werden. Damit wird dem Compiler mitgeteilt, dass der Inhalt der Variablen vor jedem Lesezugriff aus dem Speicher gelesen und nach jedem Schreibzugriff in den Speicher geschrieben wird. Ansonsten könnte der Compiler den Code so optimieren, dass der Wert der Variablen nur in Prozessorregistern zwischengespeichert wird, die nichts von der Änderung woanders mitbekommen.<br />
<br />
Zur Veranschaulichung ein Codefragment für eine Tastenentprellung mit Erkennung einer "lange gedrückten" Taste.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <stdint.h><br />
//...<br />
<br />
// Schwellwerte<br />
// Entprellung: <br />
#define CNTDEBOUNCE 10<br />
// "lange gedrueckt:"<br />
#define CNTREPEAT 200<br />
<br />
// hier z.&nbsp;B. Taste an Pin2 PortA "active low" = 0 wenn gedrueckt<br />
#define KEY_PIN PINA<br />
#define KEY_PINNO PA2<br />
<br />
// beachte: volatile! <br />
volatile uint8_t gKeyCounter;<br />
<br />
// Timer-Compare Interrupt ISR, wird z.B. alle 10ms ausgefuehrt<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
// hier wird gKeyCounter veraendert. Die übrigen<br />
// Programmteile müssen diese Aenderung "sehen":<br />
// volatile -> aktuellen Wert immer in den Speicher schreiben<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
}<br />
else {<br />
gKeyCounter = 0;<br />
}<br />
}<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
//...<br />
/* hier: Initialisierung der Ports und des Timer-Interrupts */<br />
//... <br />
// hier wird auf gKeyCounter zugegriffen. Dazu muss der in der<br />
// ISR geschriebene Wert bekannt sein:<br />
// volatile -> aktuellen Wert immer aus dem Speicher lesen<br />
if ( gKeyCounter > CNTDEBOUNCE ) { // Taste mind. 10*10 ms "prellfrei"<br />
if (gKeyCounter == CNTREPEAT) {<br />
/* hier: Code fuer "Taste lange gedrueckt" */<br />
}<br />
else {<br />
/* hier: Code fuer "Taste kurz gedrueckt" */<br />
}<br />
}<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Wird innerhalb einer ISR mehrfach auf eine mit volatile deklarierte Variable zugegriffen, wirkt sich dies ungünstig auf die Verarbeitungsgeschwindigkeit aus, da bei jedem Zugriff mit dem Speicherinhalt abgeglichen wird. Da bei AVR-Controllern ''innerhalb'' einer ISR keine Unterbrechungen zu erwarten sind, bietet es sich an, einen Zwischenspeicher in Form einer lokalen Variable zu verwenden, deren Inhalt zu Beginn und am Ende mit dem der volatile Variable synchronisiert wird. Lokale Variable werden bei eingeschalteter Optimierung mit hoher Wahrscheinlichkeit in Prozessorregistern verwaltet und der Zugriff darauf ist daher nur mit wenigen internen Operationen verbunden. Die ISR aus dem vorherigen Beispiel lässt sich so optimieren:<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter; // Uebernahme in lokale Arbeitsvariable<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (tmp_kc < CNTREPEAT) {<br />
tmp_kc++;<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc; // Zurueckschreiben<br />
}<br />
//...<br />
</syntaxhighlight><br />
<br />
Zum Vergleich die Disassemblies (Ausschnitte der "lss-Dateien", compiliert für ATmega162) im Anschluss. Man erkennt den viermaligen Zugriff auf die Speicheraddresse von ''gKeyCounter'' (hier 0x032A) in der ISR ohne "Cache"-Variable und den zweimaligen Zugriff in der Variante mit Zwischenspeicher. Im Beispiel ist der Vorteil gering, bei komplexeren Routinen kann die Zwischenspeicherung in lokalen Variablen jedoch zu deutlicheren Verbesserungen führen.<br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
876: ca 99 sbic 0x19, 2 ; 25<br />
878: 0a c0 rjmp .+20 ; 0x88e <__vector_13+0x24><br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
87a: 80 91 2a 03 lds r24, 0x032A<br />
87e: 88 3c cpi r24, 0xC8 ; 200 <br />
880: 40 f4 brcc .+16 ; 0x892 <__vector_13+0x28><br />
882: 80 91 2a 03 lds r24, 0x032A<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 02 c0 rjmp .+4 ; 0x892 <__vector_13+0x28><br />
}<br />
else {<br />
gKeyCounter = 0;<br />
88e: 10 92 2a 03 sts 0x032A, r1<br />
892: 8f 91 pop r24<br />
894: 0f 90 pop r0<br />
896: 0f be out 0x3f, r0 ; 63<br />
898: 0f 90 pop r0<br />
89a: 1f 90 pop r1<br />
89c: 18 95 reti<br />
</pre><br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter;<br />
876: 80 91 2a 03 lds r24, 0x032A<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
87a: ca 9b sbis 0x19, 2 ; 25<br />
87c: 02 c0 rjmp .+4 ; 0x882 <__vector_13+0x18><br />
87e: 80 e0 ldi r24, 0x00 ; 0<br />
880: 03 c0 rjmp .+6 ; 0x888 <__vector_13+0x1e><br />
if (tmp_kc < CNTREPEAT) {<br />
882: 88 3c cpi r24, 0xC8 ; 200<br />
884: 08 f4 brcc .+2 ; 0x888 <__vector_13+0x1e><br />
tmp_kc++;<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc;<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 8f 91 pop r24<br />
88e: 0f 90 pop r0<br />
890: 0f be out 0x3f, r0 ; 63<br />
892: 0f 90 pop r0<br />
894: 1f 90 pop r1<br />
896: 18 95 reti<br />
</pre><br />
<br />
=== volatile und Pointer ===<br />
<br />
Bei '''volatile''' in Verbindung mit Pointern ist zu beachten, ob der Pointer selbst oder die Variable, auf die der Pointer zeigt, '''volatile''' ist.<br />
<br />
<syntaxhighlight lang="c"><br />
volatile uint8_t *a; // das Ziel von a ist volatile<br />
<br />
uint8_t *volatile a; // a selbst ist volatile<br />
</syntaxhighlight><br />
<br />
Falls der Pointer volatile ist (zweiter Fall im Beispiel), ist zu beachten, dass der Wert des Pointers, also eine Speicheradresse, intern in mehr als einem Byte verwaltet wird. Lese- und Schreibzugriffe im Hauptprogramm (außerhalb von Interrupt-Routinen) sind daher so zu implementieren, dass alle Teilbytes der Adresse konsistent bleiben, vgl. dazu den folgenden Abschnitt.<br />
<br />
=== Variablen größer 1 Byte ===<br />
<br />
Bei Variablen größer ein Byte, auf die in Interrupt-Routinen und im Hauptprogramm zugegriffen wird, muss darauf geachtet werden, dass die Zugriffe auf die einzelnen Bytes außerhalb der ISR nicht durch einen Interrupt unterbrochen werden. (Allgemeinplatz: AVRs sind 8-bit Controller). Zur Veranschaulichung ein Codefragment:<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
volatile uint16_t gMyCounter16bit;<br />
//...<br />
ISR(...)<br />
{<br />
//...<br />
gMyCounter16Bit++;<br />
//...<br />
}<br />
<br />
int main(void)<br />
{<br />
uint16_t tmpCnt;<br />
//...<br />
// nicht gut: Mglw. hier ein Fehler, wenn ein Byte von MyCounter <br />
// schon in tmpCnt kopiert ist aber vor dem Kopieren des zweiten Bytes <br />
// ein Interrupt auftritt, der den Inhalt von MyCounter verändert.<br />
tmpCnt = gMyCounter16bit; <br />
<br />
<br />
// besser: Änderungen "außerhalb" verhindern -> alle "Teilbytes"<br />
// bleiben konsistent<br />
cli(); // Interrupts deaktivieren<br />
tmpCnt = gMyCounter16Bit;<br />
sei(); // wieder aktivieren<br />
<br />
// oder: vorheriger Status des globalen Interrupt-Flags bleibt erhalten<br />
uint8_t sreg_tmp;<br />
sreg_tmp = SREG; /* Sichern */<br />
cli()<br />
tmpCnt = gMyCounter16Bit;<br />
SREG = sreg_tmp; /* Wiederherstellen */<br />
<br />
// oder: mehrfach lesen, bis man konsistente Daten hat<br />
uint16_t count1 = gMyCounter16Bit;<br />
uint16_t count2 = gMyCounter16Bit;<br />
while (count1 != count2) {<br />
count1 = count2;<br />
count2 = gMyCounter16Bit;<br />
}<br />
tmpCnt = count1;<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Die avr-libc bietet ab Version 1.6.0(?) einige Hilfsfunktionen/Makros, mit der im Beispiel oben gezeigten Funktionalität, die zusätzlich auch sogenannte [http://en.wikipedia.org/wiki/Memory_barrier memory barriers] beinhalten. Diese stehen nach #include <util/atomic.h> zur Verfügung.<br />
<syntaxhighlight lang="c"><br />
//...<br />
#include <util/atomic.h><br />
//...<br />
<br />
// analog zu cli, Zugriff, sei:<br />
ATOMIC_BLOCK(ATOMIC_FORCEON) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
// oder:<br />
<br />
// analog zu Sicherung des SREG, cli, Zugriff und Zurückschreiben des SREG:<br />
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
//...<br />
</syntaxhighlight><br />
<br />
* siehe auch [http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Dokumentation der avr-libc zu atomic.h]<br />
<br />
== Interrupt-Routinen und Registerzugriffe ==<br />
<br />
Falls Register sowohl im Hauptprogramm als auch in Interrupt-Routinen verändert werden, ist darauf zu achten, dass diese Zugriffe sich nicht überlappen. Nur wenige Anweisungen lassen sich in sogenannte "atomare" Zugriffe übersetzen, die nicht von Interrupt-Routinen unterbrochen werden können. <br />
<br />
Zur Veranschaulichung eine Anweisung, bei der ein Bit und im Anschluss drei Bits in einem Register gesetzt werden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
int main(void)<br />
{<br />
//...<br />
PORTA |= (1<<PA0);<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Der Compiler übersetzt diese Anweisungen für einen ATmega128 bei Optimierungsstufe "S" nach:<br />
<br />
<div class="code"><pre><br />
...<br />
PORTA |= (1<<PA0);<br />
d2: d8 9a sbi 0x1b, 0 ; 27 (a)<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
d4: 8b b3 in r24, 0x1b ; 27 (b)<br />
d6: 8c 61 ori r24, 0x1C ; 28 (c)<br />
d8: 8b bb out 0x1b, r24 ; 27 (d)<br />
...<br />
</pre></div><br />
<br />
Das Setzen des einzelnen Bits wird bei eingeschalteter Optimierung für Register im unteren Speicherbereich in eine einzige Assembler-Anweisung (sbi) übersetzt und ist nicht anfällig für Unterbrechungen durch Interrupts. Die Anweisung zum Setzen von drei Bits wird jedoch in drei abhängige Assembler-Anweisungen übersetzt und bietet damit zwei "Angriffspunkte" für Unterbrechungen. Eine Interrupt-Routine könnte nach dem Laden des Ausgangszustands in den Zwischenspeicher (hier Register 24) den Wert des Registers ändern, z.&nbsp;B. ein Bit löschen. Damit würde der Zwischenspeicher nicht mehr mit dem tatsächlichen Zustand übereinstimmen aber dennoch nach der Bitoperation (hier ori) in das Register zurückgeschrieben. <br />
<br />
Beispiel: PORTA sei anfangs 0b00000000. Die erste Anweisung (a) setzt Bit 0 auf '''1''', PORTA ist danach 0b0000000'''1'''. Nun wird im ersten Teil der zweiten Anweisung der Portzustand in ein Register eingelesen (b). Unmittelbar darauf (vor (c)) "feuert" ein Interrupt, in dessen Interrupt-Routine Bit 0 von PORTA gelöscht wird. Nach Verlassen der Interrupt-Routine hat PORTA den Wert 0b00000000. In den beiden noch folgenden Anweisungen des Hauptprogramms wird nun der zwischengespeicherte "alte" Zustand 0b00000001 mit 0b00011100 logisch-'''ODER'''-verknüft (c) und das Ergebnis 0b00011101 in PortA geschrieben (d). Obwohl zwischenzeitlich Bit 0 gelöscht wurde, ist es nach (d) wieder gesetzt. <br />
<br />
Lösungsmöglichkeiten:<br />
* Register ohne besondere Vorkehrungen nicht in Interruptroutinen ''und'' im Hauptprogramm verändern.<br />
* Interrupts vor Veränderungen in Registern, die auch in ISRs verändert werden, deaktivieren ("cli").<br />
* Bits einzeln löschen oder setzen. sbi und cbi können nicht unterbrochen werden. Vorsicht: nur Register im unteren Speicherbereich sind mittels sbi/cbi ansprechbar. Der Compiler kann nur für diese sbi/cbi-Anweisungen generieren. Für Register außerhalb dieses Adressbereichs ("Memory-Mapped"-Register) werden auch zur Manipulation einzelner Bits abhängige Anweisungen erzeugt (lds,...,sts).<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Frequently asked Questions/Fragen Nr. 1 und 8. (Stand: avr-libc Vers. 1.0.4)<br />
<br />
== Interruptflags löschen ==<br />
<br />
Beim Löschen von Interruptflags haben AVRs eine Besonderheit, die auch im Datenblatt beschrieben ist: Es wird zum Löschen eine 1 in das betreffende Bit geschrieben. <br />
<br />
Hinweis:<br /><br />
Bei Registern mit mehreren Interrupt-Flag-Bits (wie die Timer Interrupt Flag Register) '''nicht''' die übliche bitweise VerODERung nehmen, sondern eine direkte Zuweisung machen. Da sonst weitere Flags, als nur das gewünschte, ebenfalls gelöscht werden könnten.<br /><br />
([http://www.mikrocontroller.net/topic/171148#1640133 Erklärung]).<br />
<br />
== Was macht das Hauptprogramm? ==<br />
<br />
Im einfachsten (Ausnahme-)Fall gar nichts mehr. Es ist also durchaus denkbar, ein Programm zu schreiben, welches in der main-Funktion lediglich noch die Interrupts aktiviert und dann in einer Endlosschleife verharrt. Sämtliche Funktionen werden dann in den ISRs abgearbeitet. Diese Vorgehensweise ist jedoch bei den <i>meisten</i> Anwendungen schlecht: man verschenkt eine Verarbeitungsebene und hat außerdem möglicherweise Probleme durch Interruptroutinen, die zu viel Verarbeitungszeit benötigen.<br />
<br />
Für <i>wenige</i> Anwendungen ist diese Vorgehensweise jedoch perfekt: Die Hauptschleife verkommt zu <tt>for(;;) sleep_cpu();</tt> — siehe nächster Abschnitt „Sleep“. Weiterer Vorteil: ISRs brauchen keine(!) Register retten, ein Fall für <tt>ISR(<i>name</i>,ISR_NAKED){ … reti();}</tt>. <i>So</i> können Mikrocontroller für batteriebetriebene Geräte, etwa Fernbedienungen, maximal Energie sparen.<br />
<br />
Normalerweise wird man in den Interruptroutinen nur die bei Auftreten des jeweiligen Interruptereignisses unbedingt notwendigen Operationen ausführen lassen. Alle weniger kritischen Aufgaben werden dann im Hauptprogramm abgearbeitet.<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Interrupts and Signals<br />
<br />
= Sleep-Modes =<br />
<br />
AVR Controller verfügen über eine Reihe von sogenannten [[Sleep Mode |''Sleep-Modes'']] ("Schlaf-Modi"). Diese ermöglichen es, Teile des Controllers abzuschalten. Zum Einen kann damit besonders bei Batteriebetrieb Strom gespart werden, zum Anderen können Komponenten des Controllers deaktiviert werden, die die Genauigkeit des Analog-Digital-Wandlers bzw. des Analog-Comparators negativ beeinflussen. Der Controller wird durch Interrupts aus dem Schlaf geweckt. Welche Interrupts den jeweiligen Schlafmodus beenden, ist einer Tabelle im Datenblatt des jeweiligen Controllers zu entnehmen.<br />
Die Funktionen (eigentlich Makros) der avr-libc stehen nach Einbinden der header-Datei ''sleep.h'' zur Verfügung.<br />
<br />
;set_sleep_mode (uint8_t mode): Setzt den Schlafmodus, der bei Aufruf von sleep() aktiviert wird. In sleep.h sind einige Konstanten definiert (z.&nbsp;B. SLEEP_MODE_PWR_DOWN). Die definierten Modi werden jedoch nicht alle von sämtlichten AVR-Controllern unterstützt.<br />
;sleep_enable(): Aktiviert den gesetzten Schlafmodus, versetzt den Controller aber noch nicht in den Schlafmodus<br />
;sleep_cpu(): Versetzt den Controller in den Schlafmodus .sleep_cpu wird im Prinzip durch die Assembler-Anweisung ''sleep'' ersetzt.<br />
;sleep_disable(): Deaktiviert den gesetzten Schlafmodus<br />
;sleep_mode(): Versetzt den Controller in den mit set_sleep_mode gewählten Schlafmodus. Das Makro entspricht sleep_enable()+sleep_cpu()+sleep_disable(), beinhaltet also nicht die Aktivierung von Interrupts (besser nicht benutzen).<br />
<br />
Bei Anwendung von sleep_cpu() müssen Interrupts also bereits freigeben sein (sei()), da der Controller sonst nicht mehr "aufwachen" kann. sleep_mode() ist nicht geeignet für die Verwendung in ISR Interrupt-Service-Routinen, da bei deren Abarbeitung Interrupts global deaktiviert sind und somit auch die möglichen "Aufwachinterrupts". Abhilfe: stattdessen sleep_enable(), sei(), sleep_cpu(), sleep_disable() und evtl. cli() verwenden (vgl. Dokumentation der avr-libc).<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/sleep.h><br />
<br />
int main(void)<br />
{<br />
...<br />
<br />
while (1) {<br />
...<br />
set_sleep_mode(SLEEP_MODE_PWR_DOWN);<br />
sleep_mode();<br />
<br />
// Code hier wird erst nach Auftreten eines entsprechenden<br />
// "Aufwach-Interrupts" verarbeitet<br />
...<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
In älteren Versionenen der avr-libc wurden nicht alle AVR-Controller durch die sleep-Funktionen richtig angesteuert. Mit avr-libc 1.2.0 wurde die Anzahl der unterstützten Typen jedoch deutlich erweitert. Bei nicht-unterstützten Typen erreicht man die gewünschte Funktionalität durch direkte "[[Bitmanipulation]]" der entsprechenden Register (vgl. Datenblatt) und Aufruf des Sleep-Befehls via Inline-Assembler oder sleep_cpu():<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
// Sleep-Mode "Power-Save" beim ATmega169 "manuell" aktivieren<br />
SMCR = (3<<SM0) | (1<<SE);<br />
asm volatile ("sleep"::); // alternativ sleep_cpu() aus sleep.h<br />
...<br />
</syntaxhighlight><br />
<br />
== Sleep-Modi ==<br />
Die vielen Prozessoren aus der AVR-Familie unterstützen unterschiedliche Sleep-Modi, gefächert nach Vorhandensein von Funktionsblöcken im Controller. Konkrete und verläßliche Auskunft über die tatsächlichen Gegebenheiten finden sich wie immer in den jeweiligen Datenblättern. Die Modi unterscheiden sich darin, welche Funktionsbereiche zum Energiesparen abgeschaltet werden. Davon hängt auch ab, mit welchen Mitteln der Prozessor aus der jeweiligen Schlaftiefe wieder aufgeweckt werden kann.<br />
<br />
;Idle Mode (SLEEP_MODE_IDLE): Die CPU kann durch SPI, USART, Analog Comperator, ADC, TWI, Timer, Watchdog und irgendeinen anderen Interrupt wieder aufgeweckt werden.<br />
<br />
;ADC Noise Reduction Mode (SLEEP_MODE_ADC): In diesem Modus liegt das Hauptaugenmerk darauf, die CPU soweit stillzulegen, dass der ADC möglichst keine Störungen aus dem inneren der CPU auffangen kann, die das Meßergebnis negativ beeinflussen können. Das Aufwachen aus diesem Modus kann ausgelöst werden durch den ADC, externe Interrupts, TWI, Timer und Watchdog.<br />
<br />
;Power-Down Mode (SLEEP_MODE_PWR_DOWN): In diesem Modus wird ein externer Oszillator (Quarz, Quarzoszillator), wenn vorhanden. gestoppt. Geweckt werden kann die CPU durch einen externen Level-Interrupt, TWI, Watchdog, Brown-Out-Reset.<br />
<br />
;Power-Save-Mode (SLEEP_MODE_PWR_SAVE): Power-Save ist identisch zu Power-Down mit einer Ausnahme: Ist der Timer 2 auf die Verwendung eines externen Taktes konfiguriert, so läuft dieser Timer auch im Power-Save weiter und kann die CPU mit einem Interrupt aufwecken.<br />
<br />
;Standby-Mode (SLEEP_MODE_STANDBY, SLEEP_MODE_EXT_STANDBY): Voraussetzung für den Standby-Modus ist die Verwendung eines Quarzes oder eines Quarzoszillators, also einer externen Taktquelle. Ansonsten ist dieser Modus identisch zum Power-Down Modus. Vorteil dieses Modus' ist eine kürzere Aufwachzeit.<br />
<br />
;Abschalten des Brownout Detect (BOD) während der Sleep-Phase (nur P-Typen): Zur Stromersparnis bieten die P-Typen die Möglichkeit den BOD während der Sleep-Phase abzuschalten. Bei einem Atmega88PA beispielsweise, kann dadurch der Stromverbrauch im SLEEP_MODE_PWR_SAVE mit Timer2 im Asynchronmodus mit Uhrenquarz und periodischer Selbstaufweckung um ca. 50% gesenkt werden.<br />
Das Einschalten dieser Funktion geschieht in einer Timed Sequence.<br />
<br />
<syntaxhighlight lang="c"><br />
unsigned char temp0 = MCUCR;<br />
unsigned char temp1 = MCUCR;<br />
temp0 |= (1 << BODS) | (1 << BODSE);<br />
temp1 |= (1 << BODS);<br />
MCUCR = temp0;<br />
MCUCR = temp1;<br />
sleep_cpu();<br />
</syntaxhighlight><br />
<br />
Hierbei ist unbedingt zu beachten, dass das BODS-Bit 3 Takte nach dem Setzen wieder gelöscht wird. Daher muss der Aufruf des Sleep unmittelbar nach dem Setzen erfolgen und das BODS-Bit muss jedes Mal vor einem Sleep Aufruf erneut gesetzt werden.<br />
<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Power Management and Sleep-Modes<br />
* [http://www.mikrocontroller.net/topic/96369#832712 Forenbeitrag] zur "Nichtverwendung" von sleep_mode in ISRs.<br />
<br />
= Zeiger =<br />
Zeiger (engl. ''Pointer'') sind Variablen, die die Adresse von Daten oder Funktionen enthalten und belegen 16 Bits. Die Größe hängt mit dem adressierbaren Speicherbereich zusammen und der GCC reserviert dann den entsprechenden Platz.<br />
Ggf. ist es also günstiger, Indizes auf Arrays (Listen) zu verwenden, so dass der GCC für die Zeigerarithmetik den erforderlichen RAM nur temporär benötigt.<br />
<br />
Siehe auch: [[Zeiger]]<br />
<br />
= Speicherzugriffe =<br />
<br />
Atmel AVR-Controller verfügen typisch über drei Speicher:<br />
<br />
* [[RAM]]: Im RAM (genauer statisches RAM/SRAM) wird vom gcc-Compiler Platz für Variablen reserviert. Auch der Stack befindet sich im RAM. Dieser Speicher ist "flüchtig", d.h. der Inhalt der Variablen geht beim Ausschalten oder einem Zusammenbruch der Spannungsversorgung verloren. Das bedeutet im Umkehrschluss auch, dass der RAM-Inhalt nach RESET vom Pin oder vom Watchdog erhalten bleibt! Der C-Startupcode löscht jedoch den RAM, d.h. setzt alle Bits auf 0. Dadurch erscheinen „normal definierte“ Variablen als 0. Auch Gleitkommazahlen, die schlauerweise so definiert sind, dass eine +0.0 aus lauter Nullbits besteht. Von der Löschung ausschließen kann man RAM-Variablen mit <tt>__attribute__((section(".noinit")))</tt>.<br />
<br />
* Programmspeicher: Ausgeführt als FLASH-Speicher, seitenweise wiederbeschreibbar. Darin ist das Anwendungsprogramm abgelegt.<br />
<br />
* [[EEPROM]]: Nichtflüchtiger Speicher, d.h. der einmal geschriebene Inhalt bleibt auch ohne Stromversorgung erhalten. Byte-weise schreib/lesbar. Im EEPROM werden typischerweise gerätespezifische Werte wie z.&nbsp;B. Kalibrierungswerte von Sensoren abgelegt.<br />
<br />
Einige AVRs besitzen keinen RAM-Speicher, lediglich die Register können als "Arbeitsvariablen"<br />
genutzt werden. Da die Anwendung des avr-gcc auf solch "kleinen" Controllern ohnehin selten sinnvoll ist und auch nur bei einigen RAM-losen Typen nach [http://lightner.net/avr/ATtinyAvrGcc.html "Bastelarbeiten"] möglich ist, werden diese Controller hier nicht weiter berücksichtigt. Auch EEPROM-Speicher ist nicht auf allen Typen verfügbar. Generell sollten die nachfolgenden Erläuterungen auf alle ATmega-Controller und die größeren AT90-Typen übertragbar sein. Für die Typen ATtiny2313, ATtiny26 und viele weitere der "ATtiny-Reihe" gelten die Ausführungen ebenfalls.<br />
<br />
Siehe auch:<br />
* [[Binäre Daten zum Programm hinzufügen]]<br />
== RAM ==<br />
<br />
Die Verwaltung des RAM-Speichers erfolgt durch den Compiler, im Regelfall ist beim Zugriff auf Variablen im RAM nichts Besonderes zu beachten. Die Erläuterungen in jedem brauchbaren C-Buch gelten auch für den vom avr-gcc-Compiler erzeugten Code.<br />
<br />
Um Speicher dynamisch (während der Laufzeit) zu reservieren, kann '''malloc()''' verwendet werden. malloc(size) "alloziert" (~reserviert) einen gewissen Speicherblock mit '''size''' Bytes. Ist kein Platz für den neuen Block, wird NULL (0) zurückgegeben.<br />
<br />
Wird der angelegte Block zu klein (groß), kann die Größe mit realloc() verändert werden. Den allozierten Speicherbereich kann man mit free() wieder freigeben. Wenn das Freigeben eines Blocks vergessen wird spricht man von einem "Speicherleck" (memory leak).<br />
<br />
malloc() legt Speicherblöcke im '''Heap''' an, belegt man zuviel Platz, dann wächst der Heap zu weit nach oben und überschreibt den Stack, und der Controller kommt in Teufels Küche. Das kann leider nicht nur passieren wenn man insgesamt zu viel Speicher anfordert, sondern auch wenn man Blöcke unterschiedlicher Größe in ungünstiger Reihenfolge alloziert/freigibt (siehe Artikel [[Heap-Fragmentierung]]). Aus diesem Grund sollte man malloc() auf Mikrocontrollern sehr sparsam (am besten gar nicht) verwenden.<br />
<br />
Beispiel zur Verwendung von malloc():<br />
<syntaxhighlight lang="c"><br />
#include <stdlib.h><br />
<br />
void foo(void) {<br />
// neuen speicherbereich anlegen,<br />
// platz für 10 uint16<br />
uint16_t* pBuffer = malloc(10 * sizeof(uint16_t));<br />
<br />
// darauf zugreifen, als wärs ein gewohnter Buffer<br />
pBuffer[2] = 5;<br />
<br />
// Speicher (unbedingt!) wieder freigeben<br />
free(pBuffer);<br />
}<br />
</syntaxhighlight><br />
<br />
Wenn (wie in obigem Beispiel) dynamischer Speicher nur für die Dauer einer Funktion benötigt und am Ende wieder freigegeben wird, bietet es sich an, statt malloc() '''alloca()''' zu verwenden. Der Unterschied zu malloc() ist, dass der Speicher auf dem Stack reserviert wird, und beim Verlassen der Funktion automatisch wieder freigegeben wird. Es kann somit kein Speicherleck und keine Fragmentierung entstehen.<br />
<br />
siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/malloc.html AVR Libc Home Page]: Memory Areas and Using malloc()<br />
* [https://www.mikrocontroller.net/topic/479027#5934443 Forumsbeitrag]: RAM Verbrauch auch von lokalen variablen ermitteln<br />
<br />
== Flash mit PROGMEM und pgm_read ==<br />
<br />
→ [http://nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html avr-libc: Doku zu avr/pgmspace.h]<br />
<br />
Ein Zugriff auf Konstanten im Programmspeicher ist mittels avr-gcc erst ab Version 4.7 "transparent" möglich. Um Daten aus dem Flash zu lesen, muss die AVR-Instruktion LPM (''Load from Program Memory'') erzeugt werden, bei Controllern mit mehr als 64kiB Flash auch ELPM.<br />
<br />
Dazu gibt es das AVR-spezifische GCC-Attribut <tt>progmem</tt>, mit dem eine Variablendeklaration im ''static storage''<ref>Variablen der Speicherklasse ''static storage'' haben eine unbegrenzte Lebensdauer. Beispiel für solche Variablen sind globale Variablen, aber auch static-Variablen innerhalb einer Funktion gehören dazu. Beispiele für Variablen, die nicht ''static storage'' sind: auto-Variablen ("normale" lokale Variablen), register-Variablen, durch malloc geschaffene Objekte, etc.</ref> markiert werden kann:<br />
<syntaxhighlight lang="c"><br />
const int value __attribute__((progmem)) = 1;<br />
</syntaxhighlight><br />
<br />
Effekt ist, dass die so markierte Variable nicht im RAM sondern im Flash angelegt wird. Wird durch "normalen" C-Code auf solch eine Variable zugegriffen, wird jedoch aus der gleichen Adresse aus dem RAM gelesen und nicht aus dem Flash! Das ist ein Fehler, den der Compiler aber nicht anzeigt!<br />
<br />
<syntaxhighlight lang="c"><br />
int test = value; // Fehler! PROGMEM Konstanten müssen mit den pgm_read-Funktionen gelesen werden!<br />
</syntaxhighlight><br />
<br />
Zum Lesen aus dem Flash stellt die avr-libc daher zahlreiche Makros zur Verfügung. Zudem wird das Makro <tt>PROGMEM</tt> definiert, das etwas Tipparbeit spart:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
const int value PROGMEM = 1;<br />
</syntaxhighlight><br />
<br />
<tt>progmem</tt> funktioniert im Wesentlichen wie ein Section-Attribut, das die Daten in der Section <tt>.progmem.data</tt> ablegt. Im Gegensatz zum Section-Attribut werden jedoch noch weitere Prüfungen unternommen, ab avr-gcc 4.6 etwa muss die entsprechende Variable <tt>const</tt> sein.<br />
<br />
=== Integer und float ===<br />
<br />
Zum Lesen von Skalaren stellt die avr-libc folgende Makros zu Verfügung, die jeweils ein Argument erhalten: Die 16-Bit Adresse des zu lesenden Wertes<ref>Damit ist der mögliche Speicherbereich für Flash-Konstanten auf 64kiB begrenzt. Einige pgmspace-Funktionen ermöglichen den Lesezugriff auf den gesamten Flash-Speicher, intern via Assembler-Anweisung ELPM. Die Initialisierungswerte des Speicherinhalts jenseits der 64kiB-Marke müssen dann jedoch auf anderem Weg angelegt werden, d.h. nicht per PROGMEM. Evtl. eigene Section und Linker-Optionen. Alt und nicht ganz korrekt: Die avr-libc pgmspace-Funktionen unterstützen nur die unteren 64kiB Flash bei Controllern mit mehr als 64kiB.</ref><br />
<br />
:{| {{Tabelle}}<br />
|+ Übersicht der <tt>pgm_read</tt> Funktionen aus<br/>dem Header <tt>avr/pgmspace.h</tt> der avr-libc<br />
|-<br />
! Gelesener Wert || <tt>pgm_read_xxx</tt> || Anzahl Bytes<br />
|-<br />
| <tt>uint8_t</tt> || <tt>pgm_read_byte</tt> || 1<br />
|-<br />
| <tt>uint16_t</tt> || <tt>pgm_read_word</tt> || 2<br />
|-<br />
| <tt>uint32_t</tt> || <tt>pgm_read_dword</tt> || 4<br />
|-<br />
| <tt>float</tt> || <tt>pgm_read_float</tt><ref>ab avr-libc 1.7.0</ref> || 4<br />
|}<br />
<br />
Soll ein Zeiger gelesen werden, so verwendet man <tt>pgm_read_word</tt> und castet das Ergebnis zum gewünschten Zeiger-Typ.<br />
<br />
;Beispiele:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
/* Byte */<br />
const uint8_t aByte PROGMEM = 123;<br />
<br />
/* int-Array */<br />
const int anArray[] PROGMEM = { 18, 3 ,70 };<br />
<br />
void foo (void)<br />
{<br />
/* Zeiger */<br />
static const uint8_t* const aPointer PROGMEM = &aByte;<br />
<br />
uint8_t a = pgm_read_byte (&aByte);<br />
int a2 = (int) pgm_read_word (&anArray[2]);<br />
const uint8_t* p = (const uint8_t*) pgm_read_word (&aPointer);<br />
}<br />
</syntaxhighlight><br />
<br />
=== Blöcke ===<br />
<br />
In den Flash-Funktionen der avr-libc sind keine der pgm_read_xxxx Nomenklatur folgenden Funktionen, die Speicherblöcke auslesen oder vergleichen. Die enstprechende Funktionen sind Varianten von <tt>memcpy</tt>, <tt>memcmp</tt> und heißt <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, usw. Für weitere Funktionen und deren Prototypen siehe die Dokumentation der avr-libc.<br />
<br />
=== Strings ===<br />
<br />
Strings sind in C nichts anderes als eine Abfolge von Zeichen und einem <tt>'\0'</tt> als Stringende. Der prinzipielle Weg ist daher identisch zum Lesen von Bytes, wobei auf die [[FAQ#Wie funktioniert String-Verarbeitung in C?|Besonderheiten von Strings]] wie 0-Terminierung geachtet werden muss.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
size_t my_string_length (const char *addr)<br />
{<br />
size_t length = 0;<br />
<br />
while (pgm_read_byte (addr++))<br />
{<br />
length++;<br />
}<br />
return length;<br />
}<br />
</syntaxhighlight><br />
<br />
Zur Unterstützung des Programmierers steht das Repertoire der str-Funktionen auch in jeweils eine Variante zur Verfügung, die mit dem Flash-Speicher arbeiten kann. Die Funktionsnamen tragen den Suffix <tt>_P</tt>. Darüber hinaus gibt es das Makro <tt>PSTR</tt>, das ein String-Literal im Flash-Speicher ablegt und die Adresse des Strings liefert:<br />
<br />
Die nachfolgende Funktion liefert 0 zurück, wenn string_im_ram gleich "Hallo Welt" ist. Mit strcmp (String Compare) können wir zwei Strings vergleichen. Der Rückgabewert kann hierbei folgende Werte haben:<br><br />
0 die Strings sind gleich<br />
>0 das erste ungleiche Zeichen in string_im_ram ist größer als in "Hallo Welt"<br />
<0 das erste ungleiche Zeichen in string_im_ram ist kleiner als in "Hallo Welt"<br />
<br><br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
int foo (const char *string_im_ram)<br />
{<br />
return strcmp_P (string_im_ram, PSTR ("Hallo Welt"));<br />
}<br />
</syntaxhighlight><br />
<br />
Zu beachten ist, dass <tt>PSTR</tt> nur innerhalb von Funktionen verwendet werden kann.<br />
<br />
; Array aus Strings:<br />
<br />
Arrays aus Strings im Flash-Speicher werden in zwei Schritten angelegt:<br />
<br />
# Zuerst die einzelnen Elemente des Arrays und<br />
# im Anschluss ein Array, in dem die Startaddressen der Strings abgelegt werden.<br />
<br />
Zum Auslesen wird zuerst die Adresse des gewünschten Elements aus dem Array im Flash-Speicher gelesen, die im Anschluss dazu genutzt wird, um auf das Element (den String) selbst zuzugreifen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
static const char str1[] PROGMEM = "Hund";<br />
static const char str2[] PROGMEM = "Katze";<br />
static const char str3[] PROGMEM = "Maus";<br />
<br />
const char * const array[] PROGMEM = <br />
{<br />
str1, str2, str3<br />
};<br />
<br />
// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]<br />
void read_string (char *buf, size_t i)<br />
{<br />
// Lese die Adresse des i-ten Strings aus array[]<br />
const char *parray = (const char*) pgm_read_ptr (&array[i]);<br />
<br />
// Kopiere den Inhalt der Zeichenkette vom Flash ins RAM<br />
strcpy_P (buf, parray);<br />
}<br />
</syntaxhighlight><br />
<br />
Eine weitere Möglichkeit ist, die Strings in einem 2-dimensionalen char-Array abzulegen anstatt deren Adresse in einem 1-dimensionalen Adress-Array zu speichern.<br />
<br />
Vorteil ist, dass der Code einfacher wird. Nachteil ist, dass bei unterschiedlich langen Strings Speicherplatz verschwendet wird, weil sich die Array-Dimension and der Länge des längsten Strings orientieret. Bei in etwa gleich langen Strings kann es aber sogar Speicherplatz sparen, denn es die Adressen der einzelnen Strings müssen nicht abgespeichert werden.<ref>In unserem Hund-Katze-Maus Beispiel belegt die erste Variante 22 Bytes Daten und 18 Bytes Code, die zweite Variante mit 2-dimensionalem Array belegt 18 Bytes Daten und 20 Bytes Code. Gemessen wurde mit avr-gcc 4.8 -Os für ATmega8.</ref><br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
// Die "6" ist 1 plus die Länge des längsten Strings ("Katze")<br />
const char array[][6] PROGMEM = <br />
{<br />
"Hund", "Katze", "Maus"<br />
};<br />
<br />
// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]<br />
void read_string (char *buf, size_t i)<br />
{<br />
// Kopiere den Inhalt der i-ten Zeichenkette vom Flash ins RAM<br />
strcpy_P (buf, array[i]);<br />
}<br />
</syntaxhighlight><br />
<br />
Siehe dazu auch die avr-libc FAQ: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_rom_array How do I put an array of strings completely in ROM?]<br />
<br />
=== Warum so kompliziert? ===<br />
<br />
Zu dem Thema, warum die Verabeitung von Werten aus dem Flash-Speicher so kompliziert ist, sei hier nur kurz erläutert: Die Harvard-Architektur des AVR weist getrennte Adressräume für Programm (Flash) und Datenspeicher (RAM) auf. Der C-Standard sieht keine unterschiedlichen Adressräume vor.<br />
<br />
Hat man zum Beispiel eine Funktion string_an_uart (const char* s) und übergibt an diese Funktion die Adresse einer Zeichenkette, dann weiß die Funktion nicht, ob die Adresse in den Flash-Speicher oder das RAM zeigt. Weder aus dem Pointer-Wert, also dem Zahlenwert, noch aus dem "const" kann auf den Ort der Ablage geschlossen werden.<br />
<br />
Einige AVR-Compiler bilden die Harvard-Architektur ab, indem sie in einen Pointer nicht nur die Adresse speichern, sondern auch den Ablageort wie ''Flash'' oder ''RAM''. In einem Aufruf einer Funktion wird dann bei Pointer-Parametern neben der Adresse auch der Speicherbereich, auf den der Pointer zeigt, übergeben.<br />
<br />
Dies hat jedoch auch Nachteile, denn bei jedem Zugriff über einen Zeiger muss zur ''Laufzeit'' entschieden werden, wie der Zugriff auszuführen ist und entsprechend länglicher und langsamer wird der erzeugte Code.<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitte Modules/Program Space String Utilities und Abschnitt Modules/Bootloader Support Utilities<br />
<br />
=== Datenzugriff jenseits 64 KiB ===<br />
<br />
Die Zeiger beim <tt>avr-gcc</tt> sind stets 16 Bit breit, können somit also nur 64 KiB Datenspeicher adressieren. Darauf sind auch alle Funktion der libc ausgelegt, welche auf _P enden. Funktionszeiger können beim AVR bis zu 128 KiB Programmspeicher adressieren, weil Funktionsadressen immer 16-Bit-<u>Worte</u> adressieren und nicht Bytes. Der Zugriff auf den RAM ist mit maximal 16 KiB (extern maximal 64 KiB) durch 16-Bit-Zeiger nicht begrenzt.<br />
<br />
Schlauerweise sortiert <tt>avr-gcc</tt> Flash-Konstanten und -Tabellen <i>so</i> um, dass sie an den Anfang des Flash-Speichers, gleich nach der Interrupt-Tabelle, zu liegen kommen. Somit kommt man auch auf Controllern mit mehr als 64 KByte Flash im Normalfall keine Adresse jenseits 64 KiByte erforderlich.<br />
<br />
<small>Genauso lassen sich auf Controllern mit mehr als 128 KiB Flash alle Funktionen <i>so</i> umordnen, dass solche, von denen <i>Funktionszeiger</i> benötigt werden (auch: virtuelle Methoden, tabellenoptimierte <tt>switch/case</tt>-Anweisungen), in die „unteren“ 128 KiB zu liegen kommen.</small><br />
<br />
Um (dennoch) Zugriff jenseits von 64 KiB zu bewerkstelligen gibt es mehrere Möglichkeiten:<br />
<br />
* Address-Spaces wie <tt>__flash1</tt> oder <tt>__memx</tt>, siehe Abschnitt "[[#Jenseits von flash|Jenseits von __flash]]".<br />
* Die Funktionen bzw. Makros <tt>pgm_read_xxx_far</tt> der AVR-Libc ab Version 1.8.0, wie im folgenden beschrieben. Dafür gibt es die Funktion pgm_get_far_address(), um 32-Bit Pointer eines Objekts zu erhalten<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/pgmspace.h><br />
<br />
//===================================================================<br />
// Define an additional section, which will be placed after all others<br />
//--------------------------------------------------------------------<br />
#define FAR_SECTION __attribute__((__section__(".far_section")))<br />
//--------------------------------------------------------------------<br />
<br />
//====================================================================<br />
// Just an example<br />
//====================================================================<br />
<br />
const char MyString[] FAR_SECTION = "Hier liegt mein FAR-Teststring!";<br />
const char MyBmp64[] FAR_SECTION = {0xAA,0xBB,0xCC,0xDD,0xEE,0xFF,0x00};<br />
<br />
int main(void) {<br />
uint32_t ptr = pgm_get_far_address(MyString);<br />
char MyChar;<br />
DDRC = 0xFF;<br />
do {<br />
MyChar = pgm_read_byte_far(ptr++);<br />
PORTC = MyChar;<br />
} while(MyChar);<br />
}<br />
</syntaxhighlight><br />
<br />
D.h. man muss<br />
* Die Definition der neuen Section <tt>FAR_SECTION</tt> einfügen<br />
* Die konstanten Daten mit dieser Section kennzeichnen<br />
<br />
Dem Linker muss man über diese Section nichts mitteilen, er fügt diese automatisch nach allen bestehenden sections im Flash ein. Der Zugriff auf diese Variablen kann nur mittels direkter Pointerarithmetik erfolgen, eine Indizierung von Arrays mit variablem Index ist nicht möglich. Dabei muss die Größe des Datentyps immer manuell berücksichtigt werden, denn der Pointer ist immer ein Bytepointer!<br />
<br />
<syntaxhighlight lang="c"><br />
int n=3;<br />
MyChar = pgm_read_byte_far(pgm_get_far_address(MyBmp64)+n*sizeof(char));<br />
</syntaxhighlight><br />
<br />
Dabei gibt es einige praktische Probleme.<br />
* Beim recht alten AVR-Studio 4.18 wird die Größe des belegten FLASH-Speichers nicht korrekt angezeigt, die Daten landen aber im HEX-File.<br />
* beim moderneren Atmelstudio 6.2 sieht man in der Consolenausgabe die richtige Größe, welche von avr-size ermittelt wurde, diese wird aber dann in der 2. Ausgabe durch Atmelstudio falsch dargestellt<br />
* Die Arduino-IDE rechnet richtig, siehe dieser [https://www.mikrocontroller.net/topic/511511?goto=6568945#6568945 Forumsbeitrag].<br />
<br />
== Flash mit __flash und Embedded-C ==<br />
<br />
Ab Version 4.7 unterstützt avr-gcc ''Adress-Spaces'' gemäß dem Embedded-C Dokument ISO/IEC TR18037. Der geläufigste Adress-Space ist <tt>__flash</tt>, der im Gegensatz zu <tt>progmem</tt> kein GCC-Attribut ist, sondern ein Qualifier und damit syntaktisch ähnlich verwendet wird wie <tt>const</tt> oder <tt>volatile</tt>.<br />
<br />
GCC kennt keine eigene Option zum Aktivieren von Embedded-C, es wird als GNU-C Erweiterung behandelt. Daher müssen C-Module, die Address-Spaces verwenden, mit <tt>-std=gnu99</tt> o.ä. compiliert werden.<br />
<br />
<syntaxhighlight lang="c"><br />
static const __flash int value = 10;<br />
<br />
int get_value (void)<br />
{<br />
return value;<br />
}<br />
</syntaxhighlight><br />
<br />
# Im Gegensatz zu <tt>progmem</tt> sind keine speziellen Bibliotheksfunktionen oder -makros für den Zugriff mehr notwendig: Der Code zum Lesen der Variable ist "normales" C.<br />
# Die Variable wird im richtigen Speicherbereich (Flash) angelegt.<br />
# <tt>__flash</tt> ist nur zusammen mit read-only Objekten oder Zeigern, d.h. nur zusammen mit <tt>const</tt>, erlaubt.<br />
# Zugriffe wie im obigen Beispiel können (weg)optimiert werden. Das Beispiel entspricht einem "<tt>return 10</tt>". Es besteht keine Notwendigkeit, für <tt>value</tt> überhaupt Flash-Speicher zu reservieren.<br />
<br />
Auch Zeiger-Indirektionen sind problemlos möglich. Zu beachten ist, dass <tt>__flash</tt> auf der richtigen Seite des "<tt>*</tt>" in der Zeigerdeklaration bzw. -definition steht:<br />
* '''Rechts vom <tt>*</tt>:''' Der Zeiger selbst liegt im Flash<br />
* '''Links vom <tt>*</tt>:''' Der Zeiger enthält eine Flash-Adresse<br />
<br />
<syntaxhighlight lang="c"><br />
// val ist eine Variable im Flash<br />
const __flash int val = 42;<br />
<br />
// pval liegt auch im Flash und enthält die Adresse von val<br />
const __flash int* const __flash pval = &val;<br />
<br />
int get_val (void)<br />
{<br />
// liest den Wert von val über die in pval abgelegte Adresse<br />
return *pval;<br />
}<br />
</syntaxhighlight><br />
<br />
=== Blöcke ===<br />
<br />
Um Speicherbereiche vom Flash in den RAM zu kopieren, gibt es zwei Möglichkeiten: Zum einen können wie bei <tt>progmem</tt> beschreiben die Funktionen der avr-libc wie <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, <tt>movmem_P</tt>, etc. verwendet werden:<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
// Eine Datenstruktur<br />
typedef struct<br />
{<br />
int id;<br />
char buf[10];<br />
} data_t;<br />
<br />
extern void uart_send (const void*, size_t);<br />
<br />
void send_data (const __flash data_t *pdata)<br />
{<br />
// buf wird auf dem Stack angelegt<br />
data_t buf;<br />
<br />
// Kopiere Daten vom Flash nach buf ins RAM<br />
memcpy_P (&buf, pdata, sizeof (data_t));<br />
<br />
// Sende die Daten in buf<br />
uart_send (&buf, sizeof (data_t));<br />
}<br />
</syntaxhighlight><br />
<br />
Zum anderen kann eine Struktur auch über direktes Kopieren ins RAM geladen werden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdlib.h><br />
<br />
// Eine Datenstruktur<br />
typedef struct<br />
{<br />
int id;<br />
char buf[10];<br />
} data_t;<br />
<br />
extern void uart_send (const void*, size_t);<br />
<br />
void send_data (const __flash data_t *pdata)<br />
{<br />
// Kopiere Daten ins RAM. buf wird auf dem Stack angelegt<br />
const data_t buf = *pdata;<br />
<br />
// Verwendet die Daten in buf<br />
uart_send (&buf, sizeof (data_t));<br />
}<br />
</syntaxhighlight><br />
<br />
=== Strings ===<br />
<br />
Natürlich können auch Strings im Flash abgelegt werden und auch mit Funktionen wie <tt>strcpy_P</tt> aus der avr-libc verarbeitet werden. Zudem ist es möglich, Flash-Zeiger mit der Adresse eines String-Literals zu initialisieren:<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
#define FSTR(X) ((const __flash char[]) { X } )<br />
<br />
const __flash char * const __flash array[] = <br />
{<br />
FSTR ("Hund"), FSTR ("Katze"), FSTR ("Maus")<br />
};<br />
<br />
size_t get_len (uint8_t tier)<br />
{<br />
return strlen_P (array[tier]);<br />
}<br />
</syntaxhighlight><br />
<br />
Leider sieht der Embedded-C Draft nicht vor, String-Literale direkt in einem anderen Adress-Space als ''generic'' anzulegen, so dass hier der Umweg über <tt>FSTR</tt> genommen werden muss. Dieses Konstrukt ist nur ausserhalb von Funktionen möglich und kann daher nicht als Ersatz für <tt>PSTR</tt> aus der avr-libc dienen.<br />
<br />
Soll <tt>array</tt> ein 2-dimensonales Array sein anstatt ein 1-dimensionales Array von Zeigern, dann geht das ohne große Verrenkungen:<br />
<br />
<syntaxhighlight lang="c"><br />
// Die 6 ergibt sich aus 1 plus der Länge des längsten Strings "Katze"<br />
const __flash char array[][6] = <br />
{<br />
"Hund", "Katze", "Maus"<br />
};<br />
</syntaxhighlight><br />
<br />
Weiters besteht die Möglichkeit, <tt>array</tt> analog anzulegen, wie man es mit <tt>PROGMEM</tt> machen würde: Jeder String wird explizit angelegt und seine Adresse bei der Initialisierung von <tt>array</tt> verwendet. Dies entspricht dem ersten Beispiel eines 1-dimensionalen Zeigerarrays:<br />
<br />
<syntaxhighlight lang="c"><br />
static const __flash char strHund[] = "Hund";<br />
static const __flash char strKatze[] = "Katze";<br />
static const __flash char strMaus[] = "Maus";<br />
<br />
const __flash char * const __flash array[] = <br />
{<br />
strHund, strKatze, strMaus<br />
};<br />
</syntaxhighlight><br />
<br />
=== Casts ===<br />
<br />
Embedded C fordert, dass zwei Adress-Spaces entweder disjunkt sind – d.h. sie enthalten keine gemeinsamen Adressen – oder aber ein Space komplett im anderen enthalten ist, also eine Teilmengen-Beziehung besteht. Die Adress-Spaces von avr-gcc sind so implementiert, dass jeder Space Teilmenge jedes anderes ist. Zwar haben Spaces wie RAM und Flash physikalisch keinen Speicherbereich gemein, allerdings ermöglicht diese Implementierung das Casten von Zeigern zu unterschiedlichen Adress-Spaces<ref>Im Gegensatz zu einem Attribute wie <tt>progmem</tt> ist ein (Adress Space) Qualifier Teil des Zeiger-Typs.</ref>: <br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdbool.h><br />
<br />
char read_char (const char *address, bool data_in_flash)<br />
{<br />
if (data_in_flash)<br />
return *(const __flash char*) address;<br />
else<br />
return *address;<br />
}<br />
</syntaxhighlight><br />
<br />
Der Cast selbst erzeugt keinen zusätzlichen Code, da eine RAM-Adresse und eine Flash-Adresse die gleiche Binärdarstellung haben. Allerdings wird über den nach <tt>__flash</tt> gecasteten Zeiger anders zugegriffen, nämlich per LPM.<br />
<br />
=== Jenseits von __flash ===<br />
<br />
Ausser <tt>__flash</tt> gibt es auch folgende Address-Spaces:<br />
<br />
==== <tt>__flash</tt>''N'' ====<br />
<br />
<tt>__flash</tt>''N'' mit ''N'' = 1..5 sind fünf weitere Spaces, die analog zu <tt>__flash</tt> funktionieren und deren Zeiger ebenfalls 16 Bit breit sind. avr-gcc erwartet, dass die zugehörigen Daten, welche in die Section <tt>.progmem</tt>''N''<tt>.data</tt> abgelegt werden, so lokatiert sind, dass das high-Byte der Adresse (Bits 16..23) gerade ''N'' ist.<br />
<br />
Weil Daten- und Code-Layout höchst projektspezifisch sind, werden diese Sections im Standard Linker-Skript nicht beschrieben. Um funktionsfähigen Code zu erhalten, muss daher ein eigenes Linker-Skript zur Verfügung gestellt werden, das diese Sections beschreibt, oder es kann eine Erweiterung des Standard Skripts bereitgestellt werden falls dies möglich ist.<br />
<br />
;Beispiel: Eine Applikation, die <tt>__flash2</tt> verwendet. Die zugehörende Section <tt>.progmem2.data</tt> wird hinter <tt>.text</tt> angeordnet aber vor den Initializern für <tt>.data</tt>. Dazu wird beim Linken das ld-Skript Fragment per <tt>-Tflash12.ld</tt> angegeben, welches dann an der gewünschten Stelle in das default Skript eingefügt wird:<br />
:{| <!-- Tabelle bitte für korrekte Einrückung belassen --><br />
|-<br />
|<pre><br />
SECTIONS<br />
{<br />
.flash2 :<br />
{<br />
. = MAX (ABSOLUTE(0x20000), .);<br />
PROVIDE (__flash2_start = .);<br />
. = ALIGN(2);<br />
*(.flash2.text*)<br />
*(.progmem2.data*)<br />
PROVIDE (__flash2_end = .);<br />
<br />
ASSERT (__flash2_start == __flash2_end || __flash2_start >= ABSOLUTE(0x20000),<br />
"__flash2 data in .progmem2.data below 0x20000");<br />
ASSERT (__flash2_start == __flash2_end || __flash2_end <= ABSOLUTE(0x30000),<br />
"__flash2 data in .progmem2.data exceeds 0x30000");<br />
}<br />
}<br />
INSERT AFTER .text<br />
</pre><br />
|}<br />
<br />
==== <tt>__memx</tt> ====<br />
<br />
Dieser Address-Space implementiert 3-Byte Zeiger und unterstützt Lesen über 64KiB-Segmentgrenzen hinweg. Das MSB (Bit 23) gibt dabei an, ob der <tt>__memx</tt>-Zeiger eine Flash-Adresse enthält (Bit23 = 0) oder eine RAM-Adresse (Bit23 = 1), was folgenden Code erlaubt:<br />
<br />
<syntaxhighlight lang="c"><br />
const __memx int a_flash = 42;<br />
const int a_ram = 100;<br />
<br />
int get_a (const __memx int* pa)<br />
{<br />
return *pa;<br />
}<br />
<br />
int main (void)<br />
{<br />
return get_a (&a_flash) + get_a (&a_ram);<br />
}</syntaxhighlight><br />
<br />
Dies bedeutet, dass erst zur ''Laufzeit'' entschieden werden kann, ob <tt>get_a</tt> die Daten aus dem RAM oder aus dem Flash lesen soll, was <tt>__memx</tt> im Vergleich zu den anderen Address-Spaces langsamer macht. Ausserdem ist zu beachten, dass <tt>__memx</tt>-Zeiger zwar 24-Bit Zeiger sind, die zugrundeliegende Adress-Arithmetik jedoch gemäß dem C-Standard erfolgt, also als 16-Bit Arithmetik. Bestehende Funktion der avr-libc wie z.B. printf_P funktionieren damit ebensowenig wie printf! Wenn man <tt>__memx</tt> verwenden will, braucht man dafür eigene Funktionen.<br />
<br />
=== __flash, progmem und Portierbarkeit ===<br />
<br />
Da ab er aktuellen Compilerversion 4.7 sowohl <tt>__flash</tt> als auch <tt>PROGMEM</tt> und die <tt>pgm_read</tt>-Funktionen zur Verfügung stehen, ergibt sich die Frage, welche Variante "besser" ist und wie zwischen ihnen hin- und her zu portieren ist.<br />
<br />
Zunächst sei erwähnt, dass <tt>__flash</tt> kein Ersatz für <tt>PROGMEM</tt> ist, sondern lediglich eine Alternative dazu. Das "alte" progmem wird weiterhin mir gleicher Semantik unterstützt, so dass alter Code ohne Änderungen mit den neueren Compilerversionen übersetzbar bleibt.<br />
<br />
Von der Codegüte her dürften sich keine großen Unterschiede ergeben. Es ist nicht zu erwarten, dass die eine oder die andere Variante wesentlich besseren oder schlechteren Code erzeugt — von einer Ausnahme abgesehen: Der Wert beim Zugriff ist zur Compilezeit bekannt und kann daher eliminiert werden.<br />
<syntaxhighlight lang="c"><br />
static const __flash char x[] = { 'A', 'V', 'R' };<br />
<br />
char foo (void)<br />
{<br />
return x[2];<br />
}<br />
</syntaxhighlight><br />
Dies wird übersetzt wie "<tt>return 'R';</tt>", und das Array <tt>x[]</tt> kann komplett wegoptimiert werden und entfallen.<br />
<br />
==== progmem → __flash ====<br />
<br />
Portierung in diese Richtung bedeutet, alten Code anzupassen. Zwingend ist die Portierung nicht, da <tt>progmem</tt> weiterhin unterstützt wird.<br />
Allerdings ist eine Quelle mit <tt>__flash</tt> besser lesbar, denn der Code wird von den <tt>pgm_read</tt>-Funktionen befreit, die vor allem bei Mehrfach-Indirektion den Code ziemlich verunstalten und unleserlich machen können.<br />
Weiterer Vorteil von <tt>_flash</tt> ist, daß eine striktere Typprüfung erfolgen kann.<br />
<br />
Eine Portierung wird man in zwei Schritten vornehmen:<br />
<br />
;1. Definitionen von Flash-Variablen werden angepasst:<br />
<br />
Vorher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
static const char hund[] PROGMEM = "Hund";<br />
static const char katze[] PROGMEM = "Katze";<br />
static const char maus[] PROGMEM = "Maus";<br />
<br />
const char * const tier[] PROGMEM = <br />
{<br />
hund, katze, maus<br />
};<br />
</syntaxhighlight><br />
|}<br />
<br />
Nachher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
static const __flash char hund[] = "Hund";<br />
static const __flash char katze[] = "Katze";<br />
static const __flash char maus[] = "Maus";<br />
<br />
const __flash char * const __flash tier[] = <br />
{<br />
hund, katze, maus<br />
};<br />
</syntaxhighlight><br />
|}<br />
<br />
Der Header <tt>avr/pgmspace.h</tt> wird nicht mehr benötigt. Im Gegensatz zu <tt>progmem</tt> müssen Qualifier immer links von der definierten Variablen stehen; bei Attributen wie <tt>progmem</tt> ist das mehr oder weniger egal.<br />
<br />
Nachdem diese Anpassung erfolgreich abgeschlossen ist, folgt Schritt<br />
<br />
; 2. Der Code wird von <tt>pgm_read</tt>-Aufrufen bereinigt:<br />
<br />
Vorher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
extern const char *tier[];<br />
<br />
char first_letter (uint8_t i)<br />
{<br />
const char* ptier = (const char*) pgm_read_word (&tier[i]);<br />
return (char) pgm_read_byte (&ptier[0]);<br />
}<br />
</syntaxhighlight><br />
|}<br />
<br />
Nachher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <stdint.h><br />
<br />
extern const __flash char * const __flash tier[];<br />
<br />
char first_letter (uint8_t i)<br />
{<br />
return tier[i][0];<br />
}<br />
</syntaxhighlight><br />
|}<br />
<br />
== Dateien direkt im Flash einbinden ==<br />
<br />
Wenn man größere Dateien direkt im Programm einbinden will, ohne sie vorher in C Quelltext umzuwandeln, muss man das mit dem Linker machen. Wie das geht steht hier.<br />
<br />
* [http://www.atmel.com/webdoc/avrlibcreferencemanual/FAQ_1faq_binarydata.html Atmel, avr gcc Dokumentation]<br />
* [http://nongnu.org/avr-libc/user-manual/FAQ.html#faq_binarydata Nongnu avr gcc Dokumentation]<br />
<br />
Wie man das dann praktisch umsetzt, sieht man in diesem Beitrag.<br />
<br />
* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056910 Forumsbeitrag]: Binärdateien mittels Linker einbinden<br />
* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056947 Forumsbeitrag]: Ein kleines Tool zum Umwandeln von Binärdateien in C-Quelltext.<br />
<br />
== Flash in der Anwendung schreiben ==<br />
<br />
Bei AVRs mit "self-programming"-Option – auch bekannt als [[Bootloader]]-Support – können Teile des Flash-Speichers vom Anwendungsprogramm beschrieben werden. Dies ist nur möglich, wenn die Schreibfunktion in einem besonderen Speicherbereich, der Boot-Section des Programmspeichers/Flash, abgelegt ist.<br />
<br />
Bei einigen kleinen AVRs gibt es keine gesonderte Boot-Section, bei diesen kann der Flashspeicher von jeder Stelle des Programms geschrieben werden. Für Details sei hier auf das jeweilige Controller-Datenblatt und die Erläuterungen zum Modul boot.h der avr-libc verwiesen. Es existieren auch Application-Notes dazu bei atmel.com, die auf avr-gcc-Code übertragbar sind.<br />
<br />
Siehe auch: <br />
* Forumsbeitrag [http://www.mikrocontroller.net/topic/163632#1561622 Daten in Programmspeicher speichern]<br />
<br />
== EEPROM ==<br />
<br />
Möchte man Werte aus einem Programm heraus so speichern, dass sie auch nach dem Abschalten der Versorgungsspannung noch erhalten bleiben und nach dem Wiederherstellen der Versorgungsspannung bei erneutem Programmstart wieder zur Verfügung stehen, dann benutzt man das EEPROM.<br />
<br />
Schreib- und Lesezugriffe auf den EEPROM-Speicher erfolgen über die im Modul eeprom.h der avr-libc definierten Funktionen. Mit diesen Funktionen können einzelne Bytes, Datenworte (16 Bit), Fließkommawerte (32 Bit, single-precision, float) und Datenblöcke geschrieben und gelesen werden.<br />
<br />
Diese Funktionen kümmern sich auch um diverse Details, die bei der Benutzung des EEPROMs normalerweise notwendig sind:<br />
* EEPROM-Operationen sind im Vergleich relativ langsam. Man muss daher darauf achten, dass eine vorhergehende Operation abgeschlossen ist, ehe die nächste Operation mit dem EEPROM gestartet wird. Die in der avr-libc implementierten Funktionen aus eeprom.h berücksichtigten dies. Soll beim Aufruf einer EEPROM-Funktion sichergestellt werden, dass diese nicht intern in einer Warteschleife auf den Abschluss der vorherigen Operation wartet, kann vorher per eeprom_is_ready testen, ob der Zugriff auf den EEPROM-Speicher sofort möglich ist.<br />
* Es ist darauf zu achten, dass die EEPROM-Funktionen nicht durch einen Interrupt unterbrochen werden. Einige Phasen des Zugriffs sind zeitkritisch und müssen in einer definierten bzw. begrenzten Anzahl von Takten durchgeführt werden. Durch einen unterbrechenden Interrupt würde diese Restriktion nicht mehr eingehalten. Auch dieses Detail wird von den avr-libc Funktionen berücksichtigt, so dass man sich als C-Programmierer nicht darum kümmern muss. Innerhalb der Funktionen werden Interrupts vor der "EEPROM-Sequenz" global deaktiviert und im Anschluss, falls vorher auch schon eingeschaltet, wieder aktiviert.<br />
<br />
Man beachte, dass der EEPROM-Speicher nur eine begrenzte Anzahl von Schreibzugriffen zulässt. Beschreibt man eine EEPROM-Zelle öfter als die im Datenblatt zugesicherte Anzahl (typisch 100.000), wird die Funktion der Zelle nicht mehr garantiert. Dies gilt für jede einzelne Zelle. <br />
<br />
Bei geschickter Programmierung (z.&nbsp;B. Ring-Puffer), bei der die zu beschreibenden Zellen regelmäßig gewechselt werden, kann man eine deutlich höhere Anzahl an Schreibzugriffen, bezogen auf den gesamten EEPROM-Speicher, erreichen. Auf jeden Fall sollte man aber eine Abschätzung über die zu erwartende Lebensdauer des EEPROM durchführen. Wird ein Wert im EEPROM im Durchschnitt nur einmal pro Woche verändert, wird die garantierte Anzahl der Schreibzyklen innerhalb der voraussichtlichen Verwendungszeit des Controllers sicherlich nicht erreicht werden. Welcher Controller ist schon 100000 / 52 = 1923 Jahre im Einsatz? In diesem Fall lohnt es sich daher nicht, erweiterte Programmfunktionen zu implementieren, mit denen die Anzahl der Schreibzugriffe minimiert wird.<br />
<br />
Eine weitere Möglichkeit, Schreibzyklen einzusparen, besteht in der Vorabprüfung, ob der zu speichernde Wert im EEPROM bereits enthalten ist und nur veränderte Werte zu schreiben. In aktuelleren Versionen der avr-libc sind bereits Funktionen enthalten, die solche Prüfungen enthalten (eeprom_update_*).<br />
<br />
Eine dritte Möglichkeit speichert alle Daten zunächst im RAM, wo sie beliebig oft beschrieben werden können. Nur beim Ausschalten oder beim Ausfall der Stromversorgung werden die Daten in den EEPROM geschrieben. Wie man das richtig macht sieht man im Artikel [[Speicher#EEPROM Schreibzugriffe minimieren | Speicher]].<br />
<br />
Lesezugriffe können beliebig oft durchgeführt werden. Sie unterliegen keinen Einschränkungen in Bezug auf deren Anzahl. <br />
<br />
=== EEMEM ===<br />
Um eine Variable im EEPROM anzulegen, stellt die avr-libc das Makro EEMEM zur Verfügung:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdint.h><br />
#include <avr/eeprom.h><br />
<br />
/* Byte */<br />
uint8_t eeFooByte EEMEM = 123;<br />
<br />
/* Wort */<br />
uint16_t eeFooWord EEMEM = 12345;<br />
<br />
/* float */<br />
float eeFooFloat EEMEM;<br />
<br />
/* Byte-Array */<br />
uint8_t eeFooByteArray1[] EEMEM = { 18, 3, 70 };<br />
uint8_t eeFooByteArray2[] EEMEM = { 30, 7, 79 };<br />
<br />
/* 16-bit unsigned short feld */<br />
uint16_t eeFooWordArray1[4] EEMEM;<br />
</syntaxhighlight><br />
<br />
Die grundsätzliche Vorgehensweise ist identisch zur Verwendung von PROGMEM. Auch hier erzeugt man sich spezielle attributierte Variablen (EEMEM erledigt das), die vom Compiler/Linker nicht wie normale Variablen behandelt werden. Compiler/Linker kümmern sich zwar darum, dass diesen Variablen eine Adresse zugewiesen wird, diese Adresse ist dann aber die Adresse der 'Variablen' im EEPROM. Um die dort gespeicherten Werte zu lesen bzw. zu schreiben, übergibt man diese Adresse an spezielle Funktionen, die die entsprechenden Werte aus dem EEPROM holen bzw. das EEPROM neu beschreiben.<br />
<br />
Die mittels EEMEM erzeugten 'Variablen' sind also mehr als Platzhalter zu verstehen, denn als echte Variablen. Es geht nur darum, im C-Programm symbolische Namen zur Verfügung zu haben, anstatt mit echten EEPROM-Adressen hantieren zu müssen, etwas, das grundsätzlich aber auch genauso gut möglich ist. Nur muss man sich in diesem Fall dann selbst darum kümmern, dass mehrere 'Variablen' ohne Überschneidung im EEPROM angeordnet werden.<br />
<br />
=== Bytes lesen/schreiben ===<br />
<br />
Die avr-libc Funktion zum Lesen eines Bytes heißt eeprom_read_byte. Parameter ist die Adresse des Bytes im EEPROM. Geschrieben wird über die Funktion eeprom_write_byte mit den Parametern Adresse und Inhalt. Anwendungsbeispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#define EEPROM_DEF 0xFF<br />
<br />
void eeprom_example (void)<br />
{<br />
uint8_t myByte;<br />
<br />
// myByte lesen (Wert = 123)<br />
myByte = eeprom_read_byte (&eeFooByte);<br />
<br />
// der Wert 99 wird im EEPROM an die Adresse der<br />
// Variablen eeFooByte geschrieben<br />
myByte = 99;<br />
eeprom_write_byte(&eeFooByte, myByte); // schreiben<br />
<br />
myByte = eeprom_read_byte (&eeFooByteArray1[1]); <br />
// myByte hat nun den Wert 3<br />
<br />
// Beispiel fuer eeprom_update_byte: die EEPROM-Zelle wird nur<br />
// dann beschrieben, wenn deren Inhalt sich vom Parameterwert<br />
// unterscheidet. In diesem Beispiel erfolgt also kein Schreib-<br />
// zugriff, da die Werte gleich sind.<br />
eeprom_update_byte(&eeFooByte, myByte);<br />
<br />
<br />
// Beispiel zur "Sicherung" gegen leeres EEPROM nach "Chip Erase"<br />
// (z. B. wenn die .eep-Datei nach Programmierung einer neuen Version<br />
// des Programms nicht in den EEPROM uebertragen wurde und EESAVE<br />
// deaktiviert ist (unprogrammed/1)<br />
// <br />
// Vorsicht: wenn EESAVE "programmed" ist, hilft diese Sicherung nicht<br />
// weiter, da die Speicheraddressen in einem neuen/erweiterten Programm<br />
// moeglicherweise verschoben wurden. An der Stelle &eeFooByte steht<br />
// dann u.U. der Wert einer anderen Variable aus einer "alten" Version.<br />
<br />
uint8_t fooByteDefault = 222;<br />
if ((myByte = eeprom_read_byte (&eeFooByte)) == EEPROM_DEF)<br />
{<br />
myByte = fooByteDefault;<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
=== Wort lesen/schreiben ===<br />
<br />
Schreiben und Lesen von Datenworten erfolgt analog zur Vorgehensweise bei Bytes:<br />
<br />
<syntaxhighlight lang="c"><br />
// lesen<br />
uint16_t myWord = eeprom_read_word (&eeFooWord);<br />
<br />
// schreiben<br />
eeprom_write_word (&eeFooWord, 2222);<br />
</syntaxhighlight><br />
<br />
=== Block lesen/schreiben ===<br />
<br />
Lesen und Schreiben von Datenblöcken erfolgt über die Funktionen <code>eeprom_read_block()</code> bzw. <code>eeprom_write_block()</code>. Die Funktionen erwarten drei Parameter: die Adresse der Quell- bzw. Zieldaten im RAM, die EEPROM-Adresse und die Länge des Datenblocks in Bytes als <code>size_t</code>.<br />
<syntaxhighlight lang="c"><br />
uint8_t myByteBuffer[3];<br />
uint16_t myWordBuffer[4];<br />
<br />
void eeprom_block_example (void)<br />
{<br />
/* Datenblock aus EEPROM lesen */<br />
<br />
/* liest 3 Bytes ab der von eeFooByteArray1 definierten EEPROM-Adresse<br />
in das RAM-Array myByteBuffer */<br />
eeprom_read_block (myByteBuffer, eeFooByteArray1, 3);<br />
<br />
/* dito mit etwas Absicherung betr. der Länge */<br />
eeprom_read_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));<br />
<br />
/* und nun mit 16-Bit Array */<br />
eeprom_read_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));<br />
<br />
/* Datenblock in EEPROM schreiben */<br />
eeprom_write_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));<br />
eeprom_write_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));<br />
}<br />
</syntaxhighlight><br />
<br />
=== Fließkommawerte lesen/schreiben ===<br />
<br />
In der avr-libc stehen auch EEPROM-Funktionen für Variablen des Typs float (Fließkommazahlen mit "einfacher" Genauigkeit) zur Verfügung.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/eeprom.h><br />
<br />
float eeFloat EEMEM = 12.34f;<br />
<br />
float void eeprom_float_example(float value)<br />
{<br />
/* float in EEPROM schreiben */<br />
eeprom_write_float(&eeFloat, value);<br />
<br />
/* float aus EEPROM lesen */<br />
return eeprom_read_float(&eeFloat);<br />
}</syntaxhighlight><br />
<br />
=== EEPROM-Speicherabbild in .eep-Datei ===<br />
<br />
Mit den zum Compiler gehörenden Werkzeugen kann der aus den Variablendeklarationen abgeleitete EEPROM-Inhalt in eine Datei geschrieben werden. Die übliche Dateiendung ist .eep, Daten im Intel Hex-Format. Damit können Standardwerte für den EEPROM-Inhalt im Quellcode definiert werden. <br />
<br />
Makefiles nach WinAVR/MFile-Vorlage enthalten bereits die notwendigen Einstellungen, siehe dazu die Erläuterungen im [[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]].<br />
<br />
Der Inhalt der eep-Datei muss ebenfalls zum Mikrocontroller übertragen werden, wenn die Initialisierungswerte aus der Deklaration vom Programm erwartet werden. Ansonsten enthält der EEPROM-Speicher nach der Übertragung des Programmers mittels ISP abhängig von der Einstellung der EESAVE-Fuse<ref>vgl. Datenblatt Abschnitt Fuse Bits</ref> nicht die korrekten Werte:<br />
; EESAVE = 0 (programmed): Die Daten im EEPROM bleiben erhalten. Werden sie nicht neu geschrieben, so enthält das EEPROM evtl. Daten, die nicht mehr zum Programm passen.<br />
; EESAVE = 1 (unprogrammed): Beim Programmieren werden die Daten im EEPROM gelöscht, also auf 0xff gesetzt.<br />
<br />
Als Sicherung kann man im Programm nochmals die Standardwerte vorhalten, beim Lesen auf 0xFF prüfen und gegebenenfalls einen Standardwert nutzen. Das geht natürlich nur, wenn 0xFF selbst nicht als Datenwert vorkommen kann.<br />
<syntaxhighlight lang="c"><br />
#define DUTY_CYCLE_DEFAULT 0x80<br />
<br />
uint8_t eeDutyCycle EEMEM; // Platzhalter für EEPROM<br />
uint8_t DutyCycle; // die echte Variable<br />
<br />
<br />
int main(void)<br />
{<br />
DutyCycle = eeprom_read_byte( &eeDutyCycle );<br />
if( DutyCycle == 0xFF ) // das allererste mal. Im EEPROM steht noch kein gültiger Wert<br />
{<br />
DutyCycle = DUTY_CYCLE_DEFAULT;<br />
eeprom_writeByte( &eeDutyCycle, DutyCycle );<br />
}<br />
<br />
...<br />
</syntaxhighlight><br />
<br />
=== Direkter Zugriff auf EEPROM-Adressen ===<br />
<br />
Will man direkt auf bestimmte EEPROM Adressen zugreifen, dann sind folgende IAR-kompatiblen Makros <tt>_EEGET</tt> und <tt>_EEPUT</tt> hilfreich, um sich die Typecasts zu ersparen.<br />
<br />
;Hinweis: Die nachfolgend gezeigten Makros und Zugriffe auf absolute Adressen sind in Normalfall nicht nötig und nur auf sehr wenige, spezielle Fälle beschränkt! Im Normalfall sollte man auf absolute Adressen möglichst nicht zugreifen und den Compiler seine Arbeit machen lassen, der verwaltet die Variablen und deren Adressen meist besser als der Programmierer. Der Zugriff auf Variablen im EEPROM sollte immer über ihren Namen erfolgen.<br />
<br />
Verwendung:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/eeprom.h><br />
<br />
_EEPUT (0x20, 128); // Byte-Wert 128 an Adresse 0x20 schreiben<br />
...<br />
uint8_t val = _EEGET (0x20); // EEPROM-Wert von Adresse 0x20 lesen<br />
</syntaxhighlight><br />
<br />
=== Was steckt dahinter? - EEPROM-Register ===<br />
Auch wenn es normalerweise keinen Grund gibt, in C selbst an den Steuerregistern herumzuschrauben - die eeprom Funktionen erledigen das alles zuverlässig - der Vollständigkeit halber der registermässige technische Unterbau.<br />
Um das EEPROM anzusteuern, sind drei Register von Bedeutung:<br />
;EEAR: Hier werden die Adressen eingetragen zum Schreiben oder Lesen. Dieses Register unterteilt sich nochmal in EEARH und EEARL, da in einem 8-Bit-Register keine 512 Adressen adressiert werden können.<br />
;EEDR: Hier werden die Daten eingetragen, die geschrieben werden sollen, bzw. es enthält die gelesenen Daten.<br />
;EECR: Ist das Kontrollregister für das EEPROM<br />
<br />
Das EECR steuert den Zugriff auf das EEPROM und ist wie folgt aufgebaut:<br />
<br />
:{| class="wikitable" style="text-align:center"<br />
|+ '''Aufbau des EECR-Registers'''<br />
|-<br />
!Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|-<br />
! Name<br />
| - || - || - ||- || EERIE || EEMWE || EEWE || EERE<br />
|-<br />
! Read/Write<br />
| R || R || R || R || R/W || R/W || R/W || R/W<br />
|-<br />
!Init Value<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''Bedeutung der Bits'''<br />
<br />
;Bit 4-7: nicht belegt<br />
<br />
;Bit 3 (EERIE): ''EEPROM Ready Interrupt Enable'': Wenn das Bit gesetzt ist und globale Interrupts erlaubt sind in Register SREG (Bit 7), wird ein Interrupt ausgelöst nach Beendigung des Schreibzyklus (EEPROM Ready Interrupt). Ist einer der beiden Bits 0, wird kein Interrupt ausgelöst.<br />
<br />
;Bit 2 EEMWE): ''EEPROM Master Write Enable'': Dieses Bit bestimmt, dass, wenn EEWE = 1 gesetzt wird (innerhalb von 4 Taktzyklen), das EEPROM beschrieben wird mit den Daten in EEDR bei Adresse EEAR. Wenn EEMWE = 0 ist und EEWE = 1 gesetzt wird, hat das keine Auswirkungen. Der Schreibvorgang wird dann nicht ausgelöst. Nach 4 Taktzyklen wird das Bit EEMWE automatisch wieder auf 0 gesetzt. Dieses Bit löst den Schreibvorgang nicht aus, es dient sozusagen als Sicherungsbit für EEWE.<br />
<br />
;Bit 1 (EEWE): ''EEPROM Write Enable'': Dieses Bit löst den Schreibvorgang aus, wenn es auf 1 gesetzt wird, sofern vorher EEMWE gesetzt wurde und seitdem nicht mehr als 4 Taktzyklen vergangen sind. Wenn der Schreibvorgang abgeschlossen ist, wird dieses Bit automatisch wieder auf 0 gesetzt und, sofern EERIE gesetzt ist, ein Interrupt ausgelöst. Ein Schreibvorgang sieht typischerweise wie folgt aus:<br />
:# EEPROM-Bereitschaft abwarten (EEWE=0) <br />
:# Adresse übergeben an EEAR<br />
:# Daten übergeben an EEDR<br />
:# Schreibvorgang auslösen in EECR mit Bit EEMWE=1 und EEWE=1<br />
:# (Optional) Warten, bis Schreibvorgang abgeschlossen ist<br />
<br />
;Bit 0 EERE: ''EEPROM Read Enable'': Wird dieses Bit auf 1 gesetzt wird das EEPROM an der Adresse in EEAR ausgelesen und die Daten in EEDR gespeichert. Das EEPROM kann nicht ausgelesen werden, wenn bereits eine Schreiboperation gestartet wurde. Es ist daher zu empfehlen, die Bereitschaft vorher zu prüfen. Das EEPROM ist lesebereit, wenn das Bit EEWE=0 ist. Ist der Lesevorgang abgeschlossen, wird das Bit wieder auf 0 gesetzt, und das EEPROM ist für neue Lese- und Schreibbefehle wieder bereit. Ein typischer Lesevorgang kann wie folgt aufgebaut sein:<br />
:# Bereitschaft zum Lesen prüfen (EEWE=0)<br />
:# Adresse übergeben an EEAR<br />
:# Lesezyklus auslösen mit EERE = 1<br />
:# Warten, bis Lesevorgang abgeschlossen EERE = 0<br />
:# Daten abholen aus EEDR<br />
<br />
= Die Nutzung von sprintf und printf =<br />
<br />
Um komfortabel, d.h. formatiert, Ausgaben auf ein Display oder die serielle Schnittstelle zu tätigen, bieten sich '''sprintf''' oder '''printf''' an. Alle *printf-Varianten sind jedoch ziemlich speicherintensiv und der Einsatz in einem Mikrocontroller mit knappem Speicher muss sorgsam abgewogen werden.<br />
<br />
Bei '''sprintf''' wird die Ausgabe zunächst in einem Puffer vorbereitet und anschließend mit einfachen Funktionen zeichenweise ausgegeben. Es liegt in der Verantwortung des Programmierers, genügend Platz im Puffer für die erwarteten Zeichen bereitzuhalten.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdio.h><br />
#include <stdint.h><br />
<br />
// ...<br />
// nicht dargestellt: Implementierung von uart_puts (vgl. Abschnitt UART)<br />
// ...<br />
<br />
uint16_t counter;<br />
<br />
// Ausgabe eines unsigned Integerwertes<br />
void uart_puti( uint16_t value )<br />
{<br />
uint8_t puffer[20];<br />
<br />
sprintf( puffer, "Zählerstand: %u", value );<br />
uart_puts( puffer );<br />
}<br />
<br />
int main()<br />
{<br />
counter = 5;<br />
<br />
uart_puti( counter );<br />
uart_puti( 42 );<br />
}<br />
</syntaxhighlight><br />
<br />
Eine weitere elegante Möglichkeit besteht darin, den STREAM stdout (Standardausgabe) auf eine eigene Ausgabefunktion umzuleiten. Dazu wird dem Ausgabemechanismus der C-Bibliothek eine neue Ausgabefunktion bekannt gemacht, deren Aufgabe es ist, ein einzelnes Zeichen auszugeben. Wohin die Ausgabe dann tatsächlich stattfindet, ist Sache der Ausgabefunktion. Im Beispiel unten wird auf UART ausgegeben. Alle anderen, höheren Funktionen wie z.&nbsp;B. '''printf''', greifen letztendlich auf diese primitive Ausgabefunktion zurück. <br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdio.h><br />
<br />
void uart_init(void);<br />
<br />
// a. Deklaration der primitiven Ausgabefunktion<br />
int uart_putchar(char c, FILE *stream);<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 1)<br />
static FILE mystdout = FDEV_SETUP_STREAM( uart_putchar, NULL, _FDEV_SETUP_WRITE );<br />
<br />
// c. Definition der Ausgabefunktion<br />
int uart_putchar( char c, FILE *stream )<br />
{<br />
if( c == '\n' )<br />
uart_putchar( '\r', stream );<br />
<br />
loop_until_bit_is_set( UCSRA, UDRE );<br />
UDR = c;<br />
return 0;<br />
}<br />
<br />
void uart_init(void)<br />
{<br />
/* hier µC spezifischen Code zur Initialisierung */<br />
/* des UART einfügen... s.o. im AVR-GCC-Tutorial */<br />
<br />
// Beispiel: <br />
//<br />
// myAVR Board 1.5 mit externem Quarz Q1 3,6864 MHz<br />
// 9600 Baud 8N1<br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
// Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt)<br />
#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)<br />
<br />
UCSRB |= (1<<TXEN) | (1<<RXEN); // UART TX und RX einschalten<br />
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1 <br />
<br />
UBRRH = (uint8_t)( UART_UBRR_CALC( UART_BAUD_RATE, F_CPU ) >> 8 );<br />
UBRRL = (uint8_t)UART_UBRR_CALC( UART_BAUD_RATE, F_CPU );<br />
}<br />
<br />
int main(void)<br />
{<br />
int16_t antwort = 42;<br />
uart_init();<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 2)<br />
stdout = &mystdout;<br />
<br />
// Anwendung<br />
printf( "Die Antwort ist %d.\n", antwort );<br />
return 0;<br />
}<br />
<br />
// Quelle: avr-libc-user-manual-1.4.3.pdf, S.74<br />
// + Ergänzungen<br />
</syntaxhighlight><br />
<br />
<br />
Sollen Fließkommazahlen ausgegeben werden, muss im Makefile eine andere (größere) Version der [[FAQ#Aktivieren_der_Floating_Point_Version_von_sprintf_beim_WinAVR_mit_AVR-Studio|printflib]] eingebunden werden.<br />
<br />
= Anmerkungen =<br />
<references/><br />
<br />
= TODO =<br />
* Aktualisierung Register- und Bitbeschreibungen an aktuelle AVR<br />
* "naked"-Funktionen [http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html][http://arduino.stackexchange.com/questions/8758/arduino-interruption-on-pin-change]<br />
<br />
[[Kategorie:avr-gcc Tutorial| ]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR-GCC-Tutorial&diff=107259AVR-GCC-Tutorial2025-01-27T14:46:00Z<p>Heha: /* Speicherzugriffe */</p>
<hr />
<div>Dieses Tutorial soll den Einstieg in die Programmierung von Atmel [[AVR]]-Mikrocontrollern in der Programmiersprache [[C]] mit dem freien C-Compiler [[avr-gcc]] aus der [http://gcc.gnu.org/ GNU Compiler Collection] (GCC) erleichtern.<br />
<br />
Vorausgesetzt werden Grundkenntnisse der Programmiersprache C. Diese Kenntnisse kann man sich online erarbeiten, z. B. mit dem [http://www.schellong.de/c.htm C Tutorial von Helmut Schellong] ([[C|Liste von C-Tutorials]]). Nicht erforderlich sind Vorkenntnisse in der Programmierung von Mikrocontrollern.<br />
<br />
= Vorwort =<br />
<br />
In diesem Text wird häufig auf die Standardbibliothek avr-libc verwiesen, für die es eine [http://www.nongnu.org/avr-libc/user-manual/index.html Online-Dokumentation] gibt, in der sich auch viele nützliche Informationen zum Compiler und zur Programmierung von AVR-Controllern finden. Beim Paket [[WinAVR]] gehört die avr-libc Dokumentation zum Lieferumfang und wird mitinstalliert.<br />
<br />
Der Compiler und die Standardbibliothek avr-libc werden ständig weiterentwickelt. Einige Unterschiede, die sich im Verlauf der Entwicklung ergeben haben, werden hier und im Artikel [[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen]] zwar angesprochen, Anfängern und Umsteigern sei jedoch empfohlen, eine aktuelle Versionen zu nutzen.<br />
<br />
Das ursprüngliche Tutorial stammt von Christian Schifferle, viele neue Abschnitte und aktuelle Anpassungen von Martin Thomas.<br />
<br />
Dieses Tutorial ist in [[Media:AVR-GCC-Tutorial.pdf|PDF-Form]] erhältlich (zur Zeit nur eine sehr veraltete Version).<br />
<br />
== Weiterführende Kapitel ==<br />
<br />
Um dieses riesige Tutorial etwas überschaubarer zu gestalten, wurden einige Kapitel ausgelagert, die nicht unmittelbar mit den Grundlagen von avr-gcc in Verbindung stehen. All diese Seiten gehören zur [[:Kategorie:avr-gcc Tutorial]].<br />
<br />
;UART: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der UART|Der UART]]''<br />
<br />
;ADC: → Hauptartikel: ''[[AVR-GCC-Tutorial/Analoge Ein- und Ausgabe|Analoge Ein- und Ausgabe (ADC)]]''<br />
<br />
;Timer: → Hauptartikel: ''[[AVR-GCC-Tutorial/Die Timer und Zähler des AVR|Die Timer und Zähler des AVR]]''<br />
<br />
;LCD: → Hauptartikel: ''[[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Ansteuerung]]''<br />
<br />
;Watchdog: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der Watchdog|Der Watchdog]]''<br />
<br />
;Assembler: → Hauptartikel: ''[[AVR-GCC-Tutorial/Assembler und Inline-Assembler|Assembler und Inline-Assembler]]''<br />
<br />
;alte Quellen anpassen: → Hauptartikel: ''[[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen anpassen]]''<br />
<br />
;Makefiles: → Hauptartikel: ''[[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]]'' sowie als Alternative für sehr kleine Projekte → Hauptartikel: ''[[C ohne Makefile]]''<br />
<br />
= Benötigte Werkzeuge =<br />
<br />
Um eigene Programme für AVRs mittels einer AVR-Toolchain zu erstellen wird folgende Hard- und Software benötigt:<br />
<br />
* Eine AVR-Toolchain bestehend aus avr-gcc, den avr-Binutils (Assembler, Linker, etc) und einer Standard-C Bibliothek. Üblich ist die AVR-LibC, die auch quasi in allen avr-gcc Distributionen enthalten ist.<br />
<br />
Hardware wird keine benötigt – bis auf einen PC natürlich, auf dem der Compiler ablaufen kann. Selbst ohne AVR-Hardware kann man also bereits C-Programme für AVRs schreiben, compiliern und sich das Look-and-Feel von avr-gcc sowie von IDEs wie [[Atmel Studio]], Eclipse oder leichtgewichtigeren Entwicklungsumbgebungen anschauen. Selbst das Debuggen und Simulieren ist mithilfe entsprechender Tools wie Debugger und Simulator in gewissen Grenzen möglich.<br />
<br />
Um Programme für AVRs mittels einer AVR-Toolchain zu testen, wird folgende Hard- und Software benötigt:<br />
<br />
* Platine oder Versuchsaufbau für die Aufnahme eines AVR-Controllers, der vom avr-gcc Compiler unterstützt wird.<ref>Für eine Liste der unterstützten COntroller siehe die Dokumentation des Compilers oder [http://www.nongnu.org/avr-libc/user-manual/index.html#supported_devices AVR-Libc: Supported Devices].</ref> Dieses Testboard kann durchaus auch selbst gelötet oder auf einem Steckbrett aufgebaut werden. Einige Registerbeschreibungen dieses Tutorials beziehen sich auf den inzwischen veralteten AT90S2313. Der weitaus größte Teil des Textes ist aber für alle Controller der AVR-Familie gültig. <br />
<br />
:Brauchbare Testplattformen sind auch das [[STK500]] und der [[AVR Butterfly]] von Atmel. Weitere Infos findet man in den Artikeln [[AVR#Starterkits|AVR Starterkits]] und [[AVR-Tutorial: Equipment]].<br />
<br />
* Programmiersoftware und -[[AVR In System Programmer |hardware]] z. B. PonyProg (siehe auch: [[Pony-Prog Tutorial]]) oder [[AVRDUDE]] mit [[STK200]]-Dongle oder die von Atmel verfügbare Hard- und Software ([[STK500]], Atmel AVRISP, [[AVR-Studio]]).<br />
<br />
* Nicht unbedingt erforderlich, aber zur Simulation und zum Debuggen unter MS-Windows recht nützlich: [[AVR-Studio]].<br />
<br />
* Wer unter Windows und Linux gleichermassen entwickeln will, der sollte sich die [http://www.eclipse.org/ IDE Eclipse for C/C++ Developers] und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] ansehen. Beide sind unter Windows und Linux einfach zu installieren, siehe auch [[AVR Eclipse]]. Ebenfalls unter Linux und Windows verfügbar ist die Entwicklungsumgebung [http://www.codeblocks.org/ Code::Blocks]<ref>Aktuelle, stabile Versionen sind als Nightly Builds regelmäßig im [http://forums.codeblocks.org/ Forum] verfügbar.</ref>. Innerhalb dieser Entwicklungsumgebung können ohne die Installation zusätzlicher Plugins "AVR-Projekte" angelegt werden. Für Linux gibt es auch noch das [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=25220 KontrollerLab].<br />
<br />
= Was tun, wenn's nicht klappt? =<br />
<br />
* Herausfinden, ob es tatsächlich ein avr(-gcc) spezifisches Problem ist oder nur die eigenen C-Kenntnisse einer Auffrischung bedürfen. Allgemeine C-Fragen kann man eventuell "beim freundlichen Programmierer zwei Büro-, Zimmer- oder Haustüren weiter" loswerden. Ansonsten: [[C]]-Buch (gibt's auch "gratis" online) lesen.<br />
<br />
* Die [[AVR Checkliste]] durcharbeiten.<br />
<br />
* Die '''[http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc]''' lesen, vor allem (aber nicht nur) den Abschnitt Related Pages/'''Frequently Asked Questions''' = Oft gestellte Fragen (und Antworten dazu). Z.Zt leider nur in englischer Sprache verfügbar.<br />
<br />
* Den Artikel [[AVR-GCC]] in diesem Wiki lesen.<br />
<br />
* Das [http://www.mikrocontroller.net/forum/gcc GCC-Forum auf www.mikrocontroller.net] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das avr-gcc-Forum bei [http://www.avrfreaks.net AVRfreaks] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das [http://lists.gnu.org/archive/html/avr-gcc-list/ Archiv der avr-gcc Mailing-Liste] nach vergleichbaren Problemen absuchen.<br />
<br />
* Nach Beispielcode suchen. Vor allem im ''Projects''-Bereich von [http://www.avrfreaks.net AVRfreaks] (anmelden).<br />
<br />
* Google oder yahoo befragen schadet nie.<br />
<br />
* Bei Problemen mit der Ansteuerung interner AVR-Funktionen mit C-Code: das Datenblatt des Controllers lesen (ganz und am Besten zweimal). Datenblätter sind auf den [http://www.atmel.com Atmel Webseiten] als pdf-Dateien verfügbar. Das komplette Datenblatt (complete) und nicht die Kurzfassung (summary) verwenden.<br />
<br />
* Die Beispielprogramme im [[AVR-Tutorial]] sind zwar in AVR-Assembler verfasst, Erläuterungen und Vorgehensweisen sind aber auch auf C-Programme übertragbar.<br />
<br />
* Einen Beitrag in eines der Foren oder eine Mail an die Mailing-Liste schreiben. Dabei möglichst viel Information geben: Controller, Compilerversion, genutzte Bibliotheken, Ausschnitte aus dem Quellcode oder besser ein [http://www.mikrocontroller.net/topic/72767#598986 Testprojekt] mit allen notwendigen Dateien, um das Problem nachzuvollziehen, sowie genaue Fehlermeldungen bzw. Beschreibung des Fehlverhaltens. Bei Ansteuerung externer Geräte die Beschaltung beschreiben oder skizzieren (z. B. mit [http://www.tech-chat.de/ Andys ASCII Circuit]). Siehe dazu auch: '''[http://www.tty1.net/smart-questions_de.html "Wie man Fragen richtig stellt"]'''.<br />
<br />
= Erzeugen von Maschinencode =<br />
<br />
Aus dem C-Quellcode erzeugt der avr-gcc Compiler (zusammen mit Hilfsprogrammen wie z.&nbsp;B. Präprozessor, Assembler und Linker) Maschinencode für den AVR-Controller. Üblicherweise liegt dieser Code dann im Intel Hex-Format vor ("Hex-Datei"). Die Programmiersoftware (z.&nbsp;B. [[AVRDUDE]], PonyProg oder AVRStudio/STK500-plugin) liest diese Datei ein und überträgt die enthaltene Information (den Maschinencode) in den Speicher des Controllers. Im Prinzip sind also "nur" der avr-gcc-Compiler (und wenige Hilfsprogramme) mit den "richtigen" Optionen aufzurufen, um aus C-Code eine "Hex-Datei" zu erzeugen. Grundsätzlich stehen dazu drei verschiedene Ansätze zur Verfügung:<br />
<br />
* Die Verwendung einer integrierten Entwicklungsumgebung (IDE = '''I'''ntegrated '''D'''evelopment '''E'''nvironment), bei der alle Einstellungen z.&nbsp;B. in Dialogboxen durchgeführt werden können. Unter Anderem kann AVRStudio ab Version 4.12 (kostenlos auf [http://www.atmel.com/ atmel.com]) zusammen mit WinAVR als integrierte Entwicklungsumgebung für den Compiler avr-gcc genutzt werden (dazu müssen AVRStudio und WinAVR auf dem Rechner installiert sein). Weitere IDEs (ohne Anspruch auf Vollständigkeit): [http://www.eclipse.org/ Eclipse for C/C++ Developers] (d.h. inkl. CDT) und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] (für diverse Plattformen, u.a. Linux und MS Windows, IDE und Plugin kostenlos), [http://sourceforge.net/projects/kontrollerlab KontrollerLab] (Linux/KDE, kostenlos). [http://www.atmanecl.com/EnglishSite/SoftwareEnglish.htm AtmanAvr] (MS Windows, relativ günstig), KamAVR (MS-Windows, kostenlos, wird augenscheinlich nicht mehr weiterentwickelt), [http://www.amctools.com/vmlab.htm VMLab] (MS Windows, ab Version 3.12 ebenfalls kostenlos). Integrierte Entwicklungsumgebungen unterscheiden sich stark in Ihrer Bedienung und stehen auch nicht für alle Plattformen zur Verfügung, auf denen der Compiler ausführbar ist (z.&nbsp;B. AVRStudio nur für MS-Windows). Zur Anwendung des avr-gcc Compilers mit IDEs sei hier auf deren Dokumentation verwiesen. <br />
<br />
* Die Nutzung des Programms make mit passenden Makefiles. In den folgenden Abschnitten wird die Generierung von Maschinencode für einen AVR ("hex-Datei") aus C-Quellcode ("c-Dateien") anhand von "make" und den "Makefiles" näher erläutert. Viele der darin beschriebenen Optionen findet man auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio (AVRStudio generiert ein makefile in einem Unterverzeichnis des Projektverzeichnisses). <br />
<br />
* Das Generieren des Programms ohne IDE und ohne Makefile. In diesem Fall muss die Quellcodedatei durch eine vorgefertigte Kommandofolge an den Compiler übergeben werden. Der Artikel [[C ohne Makefile]] zeigt, wie das funktioniert. Diese Vorgehensweise empfiehlt sich jedoch nur für kleine Programme, die nicht auf verschiedene Quellcodedateien verteilt sind.<br />
<br />
Beim Wechsel vom makefile-Ansatz nach WinAVR-Vorlage zu AVRStudio ist darauf zu achten, dass AVRStudio (Stand: AVRStudio Version 4.13) bei einem neuen Projekt die Optimierungsoption (vgl. Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|AVR-GCC-Tutorial/Exkurs: Makefiles]], typisch: -Os) nicht einstellt und die mathematische Bibliothek der avr-libc (libm.a, Linker-Option -lm) nicht einbindet. (Hinweis: Bei Version 4.16 wird beides bereits gesetzt). Beides ist Standard bei Verwendung von makefiles nach WinAVR-Vorlage und sollte daher auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio "manuell" eingestellt werden, um auch mit AVRStudio kompakten Code zu erzeugen.<br />
<br />
= Einführungsbeispiel =<br />
<br />
Zum Einstieg ein kleines Beispiel, an dem die Nutzung des Compilers und der Hilfsprogramme (der sogenannten ''Toolchain'') demonstriert wird. Detaillierte Erläuterungen folgen in den weiteren Abschnitten dieses Tutorials.<br />
<br />
Das Programm soll auf einem AVR Mikrocontroller einige Ausgänge ein- und andere ausschalten. Das Beispiel ist für einen ATmega16 programmiert ([http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf Datenblatt]), kann aber sinngemäß für andere Controller der AVR-Familie modifiziert werden. <br />
<br />
Ein kurzes Wort zur Hardware: Bei diesem Programm werden alle Pins von PORTB auf Ausgang gesetzt, und einige davon werden auf HIGH andere auf LOW gesetzt. Das kann je nach angeschlossener Hardware an diesen Pins kritisch sein. Am ungefährlichsten ist es, wenn nichts an den Pins angeschlossen ist und man die Funktion des Programmes durch eine Spannungsmessung mit einem Multimeter kontrolliert. Die Spannung wird dabei zwischen GND-Pin und den einzelnen Pins von PORTB gemessen.<br />
<br />
Zunächst der Quellcode der Anwendung, der in einer Text-Datei mit dem Namen ''main.c'' abgespeichert wird.<br />
<br />
<syntaxhighlight lang="c"><br />
/* Alle Zeichen zwischen Schrägstrich-Stern <br />
und Stern-Schrägstrich sind Kommentare */<br />
<br />
// Zeilenkommentare sind ebenfalls möglich<br />
// alle auf die beiden Schrägstriche folgenden<br />
// Zeichen einer Zeile sind Kommentar<br />
<br />
#include <avr/io.h> // (1)<br />
<br />
int main (void) { // (2)<br />
<br />
DDRB = 0xFF; // (3)<br />
PORTB = 0x03; // (4)<br />
<br />
while(1) { // (5)<br />
/* "leere" Schleife*/ // (6)<br />
} // (7)<br />
<br />
/* wird nie erreicht */<br />
return 0; // (8)<br />
}<br />
</syntaxhighlight><br />
<br />
# In dieser Zeile wird eine sogenannte Header-Datei eingebunden. In <code>avr/io.h</code> sind die Registernamen definiert, die im späteren Verlauf genutzt werden. Auch unter Windows wird ein&nbsp;<code>/</code> zur Kennzeichnung von Unterverzeichnissen in Include-Dateinamen verwendet und kein&nbsp;<code>\</code>.<br />
# Hier beginnt das eigentliche Programm. Jedes C-Programm beginnt mit den Anweisungen in der Funktion <code>main</code>.<br />
# Die Anschlüsse eines AVR (Pins) werden zu Blöcken zusammengefasst, einen solchen Block bezeichnet man als Port. Beim ATmega16 hat jeder Port 8 Anschlüsse, bei kleineren AVRs können einem Port auch weniger als 8 Anschlüsse zugeordnet sein. Da per Definition (Datenblatt) alle gesetzten Bits in einem Datenrichtungsregister den entsprechenden Anschluss auf Ausgang schalten, werden mit DDRB=0xff alle Anschlüsse des Ports B als Ausgänge eingestellt.<br />
# Die den ersten beiden Bits des Ports zugeordneten Anschlüsse (PB0 und PB1) werden 1, alle anderen Anschlüsse des Ports B (PB2-PB7) zu 0. Aktivierte Ausgänge (logisch 1 oder "high") liegen auf Betriebsspannung (VCC, meist 5 Volt), nicht aktivierte Ausgänge führen 0 Volt (GND, Bezugspotential). Es ist sinnvoll, sich möglichst frühzeitig eine alternative Schreibweise beizubringen, die wegen der leichteren Überprüfbarkeit und Portierbarkeit oft im weiteren Tutorial und in Forenbeiträgen benutzt wird. Die Zuordnung sieht in diesem Fall so aus, Näheres dazu im Artikel [[Bitmanipulation]]:<syntaxhighlight lang="c">PORTB = (1<<PB1) | (1<<PB0);</syntaxhighlight><br />
# ist der Beginn der sogenannte ''Hauptschleife'' (main-loop). Dies ist eine Endlosschleife, welche kontinuierlich wiederkehrende Befehle enthält.<br />
# In diesem Beispiel ist die Hauptschleife leer. Der Controller durchläuft die Schleife immer wieder, ohne dass etwas passiert. Eine solche Schleife ist notwendig, da es auf dem Controller kein Betriebssystem gibt, das nach Beendigung des Programmes die Kontrolle übernehmen könnte. Ohne diese Schleife kehrt das Programm aus <code>main</code> zurück, alle Interrupts werden deaktiviert und eine Endlosschleife betreten.<br />
# Ende der Hauptschleife und Sprung zur passenden, öffnenden Klammer, also zu 5.<br />
# ist das Programmende. Die Zeile ist nur aus Gründen der C-Kompatibilität enthalten: <syntaxhighlight lang="c">int main(void)</syntaxhighlight> besagt, dass die Funktion einen int-Wert zurückgibt. Die Anweisung wird aber nicht erreicht, da das Programm die Hauptschleife nie verlässt.<br />
<br />
Um diesen Quellcode in ein lauffähiges Programm zu übersetzen, wird hier ein Makefile genutzt. Das verwendete Makefile findet sich auf der Seite [[Beispiel Makefile]] und basiert auf der Vorlage, die in WinAVR mitgeliefert wird und wurde bereits angepasst (Controllertyp ATmega16). Man kann das Makefile bearbeiten und an andere Controller anpassen oder sich mit dem Programm MFile menügesteuert ein Makefile "zusammenklicken". Das Makefile speichert man unter dem Namen <code>Makefile</code> (ohne Endung) im selben Verzeichnis, in dem auch die Datei <code>main.c</code> mit dem Programmcode abgelegt ist. Detailliertere Erklärungen zur Funktion von Makefiles finden sich im Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|Exkurs: Makefiles]].<br />
<br />
<pre><br />
D:\beispiel>dir<br />
<br />
Verzeichnis von D:\beispiel<br />
<br />
28.11.2006 22:53 <DIR> .<br />
28.11.2006 22:53 <DIR> ..<br />
28.11.2006 20:06 118 main.c<br />
28.11.2006 20:03 16.810 Makefile<br />
2 Datei(en) 16.928 Bytes<br />
</pre><br />
<br />
Nun gibt man ''make all'' ein. Falls das mit WinAVR installierte Programmers Notepad genutzt wird, gibt es dazu einen Menüpunkt im Tools Menü. Sind alle Einstellungen korrekt, entsteht eine Datei <code>main.hex</code>, in welcher der Code für den AVR enthalten ist. <br />
<pre><br />
D:\beispiel>make all<br />
<br />
-------- begin --------<br />
avr-gcc (GCC) 3.4.6<br />
Copyright (C) 2006 Free Software Foundation, Inc.<br />
This is free software; see the source for copying conditions. There is NO<br />
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.<br />
<br />
Compiling C: main.c<br />
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -f<br />
unsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef<br />
-Wa,-adhlns=obj/main.lst -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c -<br />
o obj/main.o<br />
<br />
Linking: main.elf<br />
avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -funs<br />
igned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -W<br />
a,-adhlns=obj/main.o -std=gnu99 -Wundef -MD -MP -MF .dep/main.elf.d obj/main.o<br />
--output main.elf -Wl,-Map=main.map,--cref -lm<br />
<br />
Creating load file for Flash: main.hex<br />
avr-objcopy -O ihex -R .eeprom main.elf main.hex<br />
</pre><br />
<br />
Der Inhalt der hex-Datei kann nun zum Controller übertragen werden. Dies kann z.&nbsp;B. über In-System-Programming ([[ISP]]) erfolgen, das im [[AVR-Tutorial: Equipment]] beschrieben ist. Makefiles nach der WinAVR/MFile-Vorlage sind für die Nutzung des Programms [[AVRDUDE]] vorbereitet. Wenn man den Typ und Anschluss des Programmiergerätes richtig eingestellt hat, kann mit ''make program'' die Übertragung mittels AVRDUDE gestartet werden. Jede andere Software, die hex-Dateien lesen und zu einem AVR übertragen kann<ref>z.&nbsp;B. [[Pony-Prog_Tutorial|Ponyprog]], yapp, AVRStudio</ref>, kann natürlich ebenfalls genutzt werden.<br />
<br />
Startet man nun den Controller (Reset-Taster oder Stromzufuhr aus/an), werden vom Programm die Anschlüsse PB0 und PB1 auf 1 gesetzt. Man kann mit einem Messgerät nun an diesem Anschluss die Betriebsspannung messen oder eine [[LED]] leuchten lassen (Anode an den Pin, Vorwiderstand nicht vergessen). An den Anschlüssen PB2-PB7 misst man 0 Volt. Eine mit der Anode mit einem dieser Anschlüsse verbundene LED leuchtet nicht.<br />
<br />
= Ganzzahlige Datentypen (Integer) =<br />
<br />
Bei der Programmierung von Mikrokontrollern ist die Definition einiger ganzzahliger Datentypen sinnvoll, an denen eindeutig die Bit-Länge abgelesen werden kann.<br />
<br />
Standardisierte Datentypen werden in der Header-Datei <code>stdint.h</code> definiert, die folgendermaßen eingebunden werden kann:<br />
<syntaxhighlight lang="c">#include <stdint.h></syntaxhighlight><br />
<br />
{| {{Tabelle}}<br />
|+ '''int-Typen aus <code>stdint.h</code> (C99)'''<br/>&nbsp;<br />
|- bgcolor="#d0d0ff"<br />
!colspan="5"| Vorzeichenbehaftete int-Typen<br />
|- bgcolor="#e8e8ff"<br />
! Typname || Bit-Breite ||colspan="2"| Wertebereich<br />
|align="center| '''C-Entsprechung''' (avr-gcc)<br />
|-<br />
|<code>int8_t</code> ||align="right"| 8 || −128 ⋯ 127 || −2<sup>7</sup> ⋯ 2<sup>7</sup>−1 || <code>signed char</code><br />
|-<br />
|<code>int16_t</code> ||align="right"| 16 || −32768 ⋯ 32767 || −2<sup>15</sup> ⋯ 2<sup>15</sup>−1 || <code>signed short</code>, <code>signed int</code><br />
|-<br />
|<code>int32_t</code> ||align="right"| 32 || −2147483648 ⋯ 2147483647 || −2<sup>31</sup> ⋯ 2<sup>31</sup>−1 || <code>signed long</code><br />
|-<br />
|<code>int64_t</code> ||align="right"| 64 || −9223372036854775808 ⋯ 9223372036854775807 || −2<sup>63</sup> ⋯ 2<sup>63</sup>−1 || <code>signed long long</code><br />
|- bgcolor="#d0d0ff"<br />
!colspan="5"| Vorzeichenlose int-Typen<br />
|- bgcolor="#e8e8ff"<br />
! Typname || Bit-Breite ||colspan="2"| Wertebereich<br />
|align="center| '''C-Entsprechung''' (avr-gcc)<br />
|-<br />
|<code>uint8_t</code> ||align="right"| 8 || 0 ⋯ 255 || 0 ⋯ 2<sup>8</sup>−1 || <code>unsigned char</code><br />
|-<br />
|<code>uint16_t</code> ||align="right"| 16 || 0 ⋯ 65535 || 0 ⋯ 2<sup>16</sup>−1 || <code>unsigned short</code>, <code>unsigned int</code><br />
|-<br />
|<code>uint32_t</code> ||align="right"| 32 || 0 ⋯ 4294967295 || 0 ⋯ 2<sup>32</sup>−1 || <code>unsigned long</code><br />
|-<br />
|<code>uint64_t</code> ||align="right"| 64 || 0 ⋯ 18446744073709551615 || 0 ⋯ 2<sup>64</sup>−1 || <code>unsigned long long</code><br />
|}<br />
<br />
Neben den Typen gibt es auch Makros für die Bereichsgrenzen wie <code>INT8_MIN</code> oder <code>UINT16_MAX</code>. Siehe dazu auch: [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html Dokumentation der avr-libc: Standard Integer Types].<br />
<br />
= Grundsätzlicher Programmaufbau eines µC-Programms =<br />
<br />
Wir unterscheiden zwischen 2 verschiedenen Methoden, um ein<br />
Mikrocontroller-Programm zu schreiben, und zwar völlig unabhängig davon, in<br />
welcher Programmiersprache das Programm geschrieben wird.<br />
<br />
== Sequentieller Programmablauf ==<br />
<br />
[[Image:Sequentielle Programme.gif|left]]<br />
Bei dieser Programmiertechnik wird eine Endlosschleife programmiert, welche im<br />
Wesentlichen immer den gleichen Aufbau hat. Es wird hier nach dem sogenannten EVA-Prinzip gehandelt. EVA steht für "Eingabe, Verarbeitung, Ausgabe".<br />
{{Absatz}}<br />
<br />
== Interruptgesteuerter Programmablauf ==<br />
<br />
[[Image:Interrupt Programme.gif|left]]<br />
Bei dieser Methode werden beim Programmstart zuerst die gewünschten Interruptquellen aktiviert und dann in eine Endlosschleife gegangen, in welcher Dinge erledigt werden können, welche nicht zeitkritisch sind. Wenn ein Interrupt ausgelöst wird, so wird automatisch die zugeordnete Interruptfunktion ausgeführt.<br />
{{Absatz}}<br />
<br />
= Zugriff auf Register =<br />
<br />
Die AVR-Controller verfügen über eine Vielzahl von Registern. Die meisten<br />
davon sind sogenannte Schreib-/Leseregister. Das heißt, das Programm kann die<br />
Inhalte der Register sowohl auslesen als auch beschreiben.<br />
<br />
Register haben einen besonderen Stellenwert bei den AVR Controllern. Sie dienen dem Zugriff auf die Ports und die Schnittstellen des Controllers. Wir unterscheiden zwischen 8-Bit und 16-Bit Registern. Vorerst behandeln wir die 8-Bit Register.<br />
<br />
Einzelne Register sind bei allen AVRs vorhanden, andere wiederum nur bei bestimmten Typen. So sind beispielsweise die Register, welche für den Zugriff auf den UART notwendig sind, selbstverständlich nur bei denjenigen Modellen vorhanden, welche über einen integrierten Hardware UART bzw. USART verfügen.<br />
<br />
Die Namen der Register sind in den Headerdateien zu den entsprechenden AVR-Typen definiert. Dazu muss man den Namen der controllerspezifischen Headerdatei nicht kennen. Es reicht aus, die allgemeine Headerdatei ''avr/io.h'' einzubinden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
</syntaxhighlight><br />
<br />
Ist im Makefile der MCU-Typ z.&nbsp;B. mit dem Inhalt atmega8 definiert (und wird somit per -mmcu=atmega8 an den Compiler übergeben), wird beim Einlesen der io.h-Datei implizit ("automatisch") auch die iom8.h-Datei mit den Register-Definitionen für den ATmega8 eingelesen.<br />
<br />
<!-- Wohl besser als Anhang - spaeter... --><br />
Intern wird diese "Automatik" wie folgt realisiert: Der Controllertyp wird dem Compiler als Parameter übergeben (vgl. ''avr-gcc -c -mmcu=atmega16 [...]'' im Einführungsbeispiel). Wird ein Makefile nach der WinAVR/mfile-Vorlage verwendet, setzt man die Variable ''MCU'', der Inhalt dieser Variable wird dann an passender Stelle für die Compilerparameter verwendet. Der Compiler definiert intern eine dem mmcu-Parameter zugeordnete "Variable" (genauer: ein Makro) mit dem Namen des Controllers, vorangestelltem ''__AVR_'' und angehängten Unterstrichen (z.&nbsp;B. wird bei ''-mmcu=atmega16'' das Makro ''__AVR_ATmega16__'' definiert). Beim Einbinden der Header-Datei ''avr/io.h'' wird geprüft, ob das jeweilige Makro definiert ist und die zum Controller passende Definitionsdatei eingelesen. Zur Veranschaulichung einige Ausschnitte aus einem Makefile:<br />
<br />
<pre><br />
[...]<br />
# MCU Type ("name") setzen:<br />
MCU = atmega16<br />
[...]<br />
<br />
[...]<br />
## Verwendung des Inhalts von MCU (hier atmega16) fuer die <br />
## Compiler- und Assembler-Parameter<br />
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)<br />
ALL_CPPFLAGS = -mmcu=$(MCU) -I. -x c++ $(CPPFLAGS) $(GENDEPFLAGS)<br />
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)<br />
[...]<br />
<br />
[...]<br />
## Aufruf des Compilers:<br />
## mit den Parametern ($(ALL_CFLAGS) ist -mmcu=$(MCU)[...] = -mmcu=atmega16[...]<br />
$(OBJDIR)/%.o : %.c<br />
@echo<br />
@echo $(MSG_COMPILING) $<<br />
$(CC) -c $(ALL_CFLAGS) $< -o $@ <br />
[...]<br />
</pre><br />
<br />
Da --mmcu=atmega16 übergeben wurde, wird __AVR_ATmega16__ definiert und kann in avr/io.h zur Fallunterscheidung genutzt werden:<br />
<br />
<syntaxhighlight lang="c"><br />
// avr/io.h <br />
// (bei WinAVR-Standardinstallation in C:\WinAVR\avr\include\avr)<br />
[...]<br />
#if defined (__AVR_AT94K__)<br />
# include <avr/ioat94k.h><br />
// [...]<br />
#elif defined (__AVR_ATmega16__)<br />
// da __AVR_ATmega16__ definiert ist, wird avr/iom16.h eingebunden:<br />
# include <avr/iom16.h><br />
// [...]<br />
#else<br />
# if !defined(__COMPILING_AVR_LIBC__)<br />
# warning "device type not defined"<br />
# endif<br />
#endif<br />
</syntaxhighlight><br />
<br />
Die Beispiele in den folgenden Abschnitten demonstrieren den Zugriff auf Register anhand der Register für I/O-Ports (PORTx, DDRx, PINx), die Vorgehensweise ist jedoch für alle Register (z.&nbsp;B. die des UART, ADC, SPI) analog.<br />
<br />
== Schreiben in Register ==<br />
<br />
Zum Schreiben kann man Register einfach wie eine Variable setzen.<ref>In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Schreibzugriff über die Funktion outp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt, outp() ist nicht mehr erforderlich.</ref><br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
/* Setzt das Richtungsregister des Ports A auf 0xff <br />
(alle Pins als Ausgang, vgl. Abschnitt Zugriff auf Ports): */<br />
DDRA = 0xff; <br />
<br />
/* Setzt PortA auf 0x03, Bit 0 und 1 "high", restliche "low": */<br />
PORTA = 0x03; <br />
<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binär 00011111 = Hexadezimal 1F<br />
DDRB = 0x1F; /* direkte Zuweisung - unübersichtlich */<br />
<br />
/* Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit<br />
aber übersichtlicher und selbsterklärend: */<br />
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);<br />
<br />
while (1);<br />
}<br />
</syntaxhighlight><br />
<br />
Die ausführliche Schreibweise sollte bevorzugt verwendet werden, da dadurch die Zuweisungen selbsterklärend sind und somit der Code leichter nachvollzogen werden kann. Atmel verwendet sie auch bei Beispielen in Datenblätten und in den allermeisten Quellcodes zu Application-Notes. Mehr zu der Schreibweise mit "|" und "<<" findet man unter [[Bitmanipulation]].<br />
<br />
Der gcc C-Compiler unterstützt ab Version 4.3.0 Konstanten im Binärformat, z.&nbsp;B. DDRB&nbsp;=&nbsp;0b00011111. Diese Schreibweise ist jedoch nur in GNU-C verfügbar und nicht in ISO-C definiert. Man sollte sie daher nicht verwenden, wenn Code mit anderen ausgetauscht oder mit anderen Compilern bzw. älteren Versionen des gcc genutzt werden soll.<br />
<br />
== Verändern von Registerinhalten ==<br />
<br />
Einzelne Bits setzt und löscht man "Standard-C-konform" mittels logischer (Bit-) Operationen. <br />
<br />
<syntaxhighlight lang="c"><br />
x |= (1 << Bitnummer); // Hiermit wird ein Bit in x gesetzt<br />
x &= ~(1 << Bitnummer); // Hiermit wird ein Bit in x geloescht<br />
</syntaxhighlight><br />
<br />
Es wird jeweils nur der Zustand des angegebenen Bits geändert, der vorherige Zustand der anderen Bits bleibt erhalten. <br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
#define MEINBIT 2<br />
...<br />
PORTA |= (1 << MEINBIT); /* setzt Bit 2 an PortA auf 1 */<br />
PORTA &= ~(1 << MEINBIT); /* loescht Bit 2 an PortA */<br />
</syntaxhighlight><br />
<br />
Mit dieser Methode lassen sich auch mehrere Bits eines Registers gleichzeitig setzen und löschen.<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
DDRA &= ~( (1<<PA0) | (1<<PA3) ); /* PA0 und PA3 als Eingaenge */<br />
PORTA |= ( (1<<PA0) | (1<<PA3) ); /* Interne Pull-Up fuer beide einschalten */<br />
</syntaxhighlight><br />
<br />
Bei bestimmten AVR Registern mit Bits, die durch Beschreiben mit einer logischen 1 gelöscht werden, muss eine absolute Zuweisung benutzt werden. Ein ODER löscht in diesen Registern ALLE gesetzten Bits!<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
TIFR2 = (1<<OCF2A); // Nur Bit OCF2A löschen<br />
</syntaxhighlight><br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind nicht mehr erforderlich.<br />
<br />
Siehe auch:<br />
* [[Bitmanipulation]]<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
<br />
== Lesen aus Registern ==<br />
<br />
Zum Lesen kann man auf Register einfach wie auf eine Variable zugreifen. In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Lesezugriff über die Funktion inp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt und inp() ist nicht mehr erforderlich.<br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdint.h><br />
<br />
uint8_t foo;<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
/* kopiert den Status der Eingabepins an PortB <br />
in die Variable foo: */<br />
foo = PINB; <br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Die Abfrage der Zustände von Bits erfolgt durch Einlesen des gesamten Registerinhalts und ausblenden der Bits deren Zustand nicht von Interesse ist. Einige Beispiele zum Prüfen ob Bits gesetzt oder gelöscht sind:<br />
<br />
<syntaxhighlight lang="c"><br />
#define MEINBIT0 0 <br />
#define MEINBIT2 2<br />
<br />
uint8_t i;<br />
<br />
extern test1();<br />
<br />
// Funkion test1 aufrufen, wenn Bit 0 in Register PINA gesetzt (1) ist<br />
i = PINA; // Inhalt in Arbeitsvariable<br />
i = i & 0x01; // alle Bits bis auf Bit 0 ausblenden (bitweise und)<br />
// falls das Bit gesetzt war, hat i den Inhalt 1<br />
if ( i != 0 ) { // Ergebnis ungleich 0 (wahr)? <br />
test1(); // dann muss Bit 0 in i gesetzt sein -> Funktion aufrufen<br />
}<br />
// verkürzt:<br />
if ( ( PINA & 0x01 ) != 0 ) {<br />
test1();<br />
}<br />
// nochmals verkürzt:<br />
if ( PINA & 0x01 ) {<br />
test1();<br />
}<br />
// mit definierter Bitnummer:<br />
if ( PINA & ( 1 << MEINBIT0 ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und/oder Bit 2 gesetzt ist. (Bit 0 und 2 also Wert 5) <br />
// (Bedenke: Bit 0 hat Wert 1, Bit 1 hat Wert 2 und Bit 2 hat Wert 4)<br />
if ( PINA & 0x05 ) {<br />
test1(); // Vergleich <> 0 (wahr), also mindestens eines der Bits gesetzt<br />
}<br />
// mit definierten Bitnummern:<br />
if ( PINA & ( ( 1 << MEINBIT0 ) | ( 1 << MEINBIT2 ) ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und Bit 2 gesetzt sind<br />
if ( ( PINA & 0x05 ) == 0x05 ) { // nur wahr, wenn beide Bits gesetzt<br />
test1();<br />
}<br />
<br />
// Funktion test2() aufrufen, wenn Bit 0 gelöscht (0) ist<br />
i = PINA; // einlesen in temporäre Variable<br />
i = i & 0x01; // maskieren von Bit 0<br />
if ( i == 0 ) { // Vergleich ist wahr, wenn Bit 0 nicht gesetzt ist<br />
test2();<br />
}<br />
// analog mit not-Operator<br />
if ( !i ) {<br />
test2();<br />
}<br />
// nochmals verkürzt:<br />
if ( !( PINA & 0x01 ) ) {<br />
test2();<br />
}<br />
</syntaxhighlight><br />
<br />
== Warten auf einen bestimmten Zustand ==<br />
<br />
Es gibt in der Bibliothek avr-libc Funktionen, die warten, bis ein bestimmter Zustand eines Bits erreicht ist. Es ist allerdings normalerweise eine eher unschöne Programmiertechnik, da in diesen Funktionen "blockierend" gewartet wird. Der Programmablauf bleibt also an dieser Stelle stehen, bis das maskierte Ereignis erfolgt ist. Setzt man den [[Watchdog]] ein, muss man darauf achten, dass dieser auch noch getriggert wird (Zurücksetzen des Watchdogtimers). <br />
<br />
Die Funktion '''loop_until_bit_is_set''' wartet in einer Schleife, bis das definierte Bit gesetzt ist. Wenn das Bit beim Aufruf der Funktion bereits gesetzt ist, wird die Funktion sofort wieder verlassen. Das niederwertigste Bit hat die Bitnummer 0. <br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 2 (das dritte Bit) in Register PINA gesetzt (1) ist */<br />
<br />
#define WARTEPIN PINA<br />
#define WARTEBIT PA2<br />
<br />
// mit der avr-libc Funktion:<br />
loop_until_bit_is_set(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// _nicht_ ungleich 0 (also 0) ist.<br />
while ( !(WARTEPIN & (1 << WARTEBIT)) ) {}<br />
...<br />
</syntaxhighlight><br />
<br />
<br />
Die Funktion '''loop_until_bit_is_clear''' wartet in einer Schleife, bis das definierte Bit gelöscht ist. Wenn das Bit beim Aufruf der Funktion bereits gelöscht ist, wird die Funktion sofort wieder verlassen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 4 (das fuenfte Bit) in Register PINB geloescht (0) ist */<br />
#define WARTEPIN PINB<br />
#define WARTEBIT PB4<br />
<br />
// avr-libc-Funktion:<br />
loop_until_bit_is_clear(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// gesetzt (1) ist <br />
while ( WARTEPIN & (1<<WARTEBIT) ) {}<br />
...<br />
</syntaxhighlight><br />
<br />
Universeller und auch auf andere Plattformen besser übertragbar ist die Verwendung von C-Standardoperationen.<br />
<br />
Siehe auch: <br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
* [[Bitmanipulation]]<br />
<br />
== 16-Bit Register (ADC, ICR1, OCR1x, TCNT1, UBRR) ==<br />
<br />
Einige der Portregister in den AVR-Controllern sind 16 Bit breit. Im Datenblatt sind diese Register üblicherweise mit dem Suffix "L" (Low-Byte) und "H" (High-Byte) versehen. Die avr-libc definiert zusätzlich die meisten dieser Variablen die Bezeichnung ohne "L" oder "H". Auf diese Register kann dann direkt zugegriffen werden. Dies ist zum Beispiel der Fall für Register wie ADC oder TCNT1.<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
uint16_t foo;<br />
<br />
/* setzt die Wort-Variable foo auf den Wert der letzten AD-Wandlung */<br />
foo = ADC; <br />
</syntaxhighlight><br />
<br />
Bei anderen Registern, wie zum Beispiel Baudraten-Register, liegen High- und Low-Teil nicht direkt nebeneinander im SFR-Bereich, so dass ein 16-Bit Zugriff nicht möglich ist und der Zugriff zusammengebastelt werden muss:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
...<br />
uint16_t baud = F_CPU / (UART_BAUD_RATE * 16L) -1;<br />
<br />
UBRRH = (uint8_t) (baud >> 8);<br />
UBRRL = (uint8_t) baud;<br />
...<br />
</syntaxhighlight><br />
<br />
Bei einigen AVR-Typen wie ATmega8 oder ATmega16 teilen sich UBRRH und UCSRC die gleiche Speicher-Adresse. Damit der AVR trotzdem zwischen den beiden Registern unterscheiden kann, bestimmt das Bit7 (URSEL), welches Register tatsächlich beschrieben werden soll. ''1000 0011'' (0x83) adressiert demnach UCSRC und übergibt den Wert ''3''. Und ''0000 0011'' (0x3) adressiert UBRRH und übergibt ebenfalls den Wert ''3''. <br />
<br />
Speziell bei den 16-Bit-Timern und auch beim ADC ist es bei allen Zugriffen auf Datenregister erforderlich, dass diese Daten synchronisiert sind. Wenn z.&nbsp;B. bei einem 16-Bit-Timer das High-Byte des Zählregisters gelesen wurde und vor dem Lesezugriff auf das Low-Byte ein Überlauf des Low-Bytes stattfindet, erhält man einen völlig unsinnigen Wert. Auch die Compare-Register müssen synchron geschrieben werden, da es ansonsten zu unerwünschten Compare-Ereignissen kommen kann. <br />
<br />
Beim ADC besteht das Problem darin, dass zwischen den Zugriffen auf die beiden Teilregister eine Wandlung beendet werden kann und der ADC ein neues Ergebnis in ADCL und ADCH schreiben will, wodurch High- und Low-Byte nicht zusammenpassen.<br />
<br />
Um diese Datenmüllproduktion zu verhindern, gibt es in beiden Fällen eine Synchronisation, die jeweils durch den Zugriff auf das Low-Byte ausgelöst wird:<br />
* Bei den Timer-Registern (das gilt für alle TCNT-, OCR- und ICR-Register bei den 16-Bit-Timern) wird bei einem ''Lesezugriff'' auf das Low-Byte automatisch das High-Byte in ein temporäres Register, das ansonsten nach außen nicht sichtbar ist, geschoben. Greift man nun ''anschließend'' auf das High-Byte zu, dann wird eben dieses temporäre Register gelesen.<br />
* Bei einem ''Schreibzugriff'' auf eines der genannten Register wird das High-Byte in besagtem temporären Register zwischengespeichert und erst beim Schreiben des Low-Bytes werden ''beide'' gleichzeitig in das eigentliche Register übernommen.<br />
<br />
Das bedeutet für die Reihenfolge:<br />
* Lesezugriff: Erst Low-Byte, dann High-Byte<br />
* Schreibzugriff: Erst High-Byte, dann Low-Byte<br />
<br />
Des weiteren ist zu beachten, dass es für all diese 16-Bit-Register nur ein einziges temporäres Register gibt, so dass das Auftreten eines Interrupts, in dessen Handler ein solches Register manipuliert wird, bei einem durch ihn unterbrochenen Zugriff i.d.R. zu Datenmüll führt. 16-Bit-Zugriffe sind generell nicht atomar! Wenn mit Interrupts gearbeitet wird, kann es erforderlich sein, vor einem solchen Zugriff auf ein 16-Bit-Register die Interrupt-Bearbeitung zu deaktivieren.<br />
<br />
Beim ADC-Datenregister ADCH/ADCL ist die Synchronisierung anders gelöst. Hier wird beim Lesezugriff (ADCH/ADCL sind logischerweise read-only) auf das Low-Byte ADCL beide Teilregister für Zugriffe seitens des ADC so lange gesperrt, bis das High-Byte ADCH ausgelesen wurde. Dadurch kann der ADC nach einem Zugriff auf ADCL keinen neuen Wert in ADCH/ADCL ablegen, bis ADCH gelesen wurde. Ergebnisse von Wandlungen, die zwischen einem Zugriff auf ADCL und ADCH beendet werden, gehen verloren!<br />
<br />
Nach einem Zugriff auf ADCL muss grundsätzlich ADCH gelesen werden!<br />
<br />
In beiden Fällen – also sowohl bei den Timern als auch beim ADC – werden vom C-Compiler 16-Bit Pseudo-Register zur Verfügung gestellt (z.&nbsp;B. TCNT1H/TCNT1L → TCNT1, ADCH/ADCL → ADC bzw. ADCW), bei deren Verwendung der Compiler automatisch die richtige Zugriffsreihenfolge regelt. In C-Programmen sollten grundsätzlich diese 16-Bit-Register verwendet werden! Sollte trotzdem ein Zugriff auf ein Teilregister erforderlich sein, sind obige Angaben zu berücksichtigen.<br />
<br />
Es ist darauf zu achten, dass auch ein Zugriff auf die 16-Bit-Register vom Compiler in zwei 8-Bit-Zugriffe aufgeteilt wird und dementsprechend genauso nicht-atomar ist wie die Einzelzugriffe. Auch hier gilt, dass u.U. die Interrupt-Bearbeitung gesperrt werden muss, um Datenmüll zu vermeiden.<br />
<br />
Beim ADC gibt es für den Fall, dass eine Auflösung von 8 Bit ausreicht, die Möglichkeit, das Ergebnis "linksbündig" in ADCH/ADCL auszurichten, so dass die relevanten 8 MSB in ADCH stehen. In diesem Fall muss bzw. sollte nur ADCH ausgelesen werden.<br />
<br />
ADC und ADCW sind unterschiedliche Bezeichner für das selbe Registerpaar. Üblicherweise kann man in C-Programmen ADC verwenden, was analog zu den anderen 16-Bit-Registern benannt ist. ADCW (ADC Word) existiert nur deshalb, weil die Headerdateien auch für Assembler vorgesehen sind und es bereits einen Assembler-Befehl namens ''adc'' gibt. <br />
<br />
Im Umgang mit 16-Bit Registern siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Related Pages/Frequently Asked Questions/Nr. 8<br />
* Datenblatt Abschnitt ''Accessing 16-bit Registers''<br />
<br />
== IO-Register als Parameter und Variablen ==<br />
<br />
Um Register als Parameter für eigene Funktionen übergeben zu können, muss man sie als einen volatile uint8_t Pointer übergeben. Zum Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <util/delay.h><br />
<br />
uint8_t key_pressed (volatile uint8_t *inputreg, uint8_t inputbit)<br />
{<br />
static uint8_t last_state = 0;<br />
<br />
if (last_state == (*inputreg & (1<<inputbit)))<br />
return 0; /* keine Änderung */<br />
<br />
/* Wenn doch, warten bis etwaiges Prellen vorbei ist: */<br />
_delay_ms(20);<br />
<br />
/* Zustand für nächsten Aufruf merken: */<br />
last_state = *inputreg & (1<<inputbit);<br />
<br />
/* und den entprellten Tastendruck zurückgeben: */<br />
return *inputreg & (1<<inputbit);<br />
}<br />
<br />
/* Beispiel für einen Funktionsaufruf: */<br />
<br />
void foo (void)<br />
{<br />
uint8_t i = key_pressed (&PINB, PB1);<br />
}<br />
</syntaxhighlight><br />
<br />
Ein Aufruf der Funktion mit call by value würde Folgendes bewirken: Beim Funktionseintritt wird nur eine Kopie des momentanen Portzustandes angefertigt, die sich unabhängig vom tatsächlichen Zustand das Ports nicht mehr ändert, womit die Funktion wirkungslos wäre. Die Übergabe eines Zeigers wäre die Lösung, wenn der Compiler nicht optimieren würde. Denn dadurch wird im Programm nicht von der Hardware gelesen, sondern wieder nur von einem Abbild im Speicher. Das Ergebnis wäre das gleiche wie oben. Mit dem Schlüsselwort volatile sagt man nun dem Compiler, dass die entsprechende Variable entweder durch andere Softwareroutinen (Interrupts) oder durch die Hardware verändert werden kann.<br />
<br />
Siehe auch: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass avr-libc FAQ: "How do I pass an IO port as a parameter to a function?"]<br />
<br />
= Zugriff auf IO-Ports =<br />
<br />
Jeder AVR implementiert eine unterschiedliche Menge an GPIO-Registern<br />
(GPIO - General Purpose Input/Output). Diese Register dienen dazu:<br />
* einzustellen welche der Anschlüsse ("Beinchen") des Controllers als Ein- oder Ausgänge dienen<br />
* bei Ausgängen deren Zustand festzulegen<br />
* bei Eingängen deren Zustand zu erfassen<br />
<br />
Mittels GPIO werden digitale Zustände gesetzt und erfasst, d.h. die Spannung an einem Ausgang wird ein- oder ausgeschaltet und an einem Eingang wird erfasst, ob die anliegende Spannung über oder unter einem bestimmten Schwellwert liegt. Im Datenblatt Abschnitt Electrical Characteristics/DC Characteristics finden sich die Spannungswerte (V_OL, V_OH für Ausgänge, V_IL, V_IH für Eingänge).<br />
<br />
Die Verarbeitung von analogen Eingangswerten und die Ausgabe von Analogwerten wird in Kapitel [[AVR-GCC-Tutorial#Analoge_Ein-_und_Ausgabe|Analoge Ein- und Ausgabe]] behandelt.<br />
<br />
Die physischen Ein- und Ausgänge werden bei AVR-Controllern zu logischen Ports gruppiert.<br />
<br />
Alle Ports werden über Register gesteuert. Dazu sind jedem Port 3 Register zugeordnet:<br />
<br />
{| class="wikitable"<br />
|- <br />
! width="10%"| DDRx<br />
| Datenrichtungsregister für Port'''x'''. <br />
'''x''' entspricht '''A''', '''B''', ''' C''' usw. je nach gewünschtem Port. Bit im Register gesetzt (1) für Ausgang, Bit gelöscht (0) für Eingang.<br />
|- <br />
! PINx<br />
| Eingangsadresse für Port'''x'''. <br />
Zustand des Ports. Die Bits in PINx entsprechen dem Zustand der als Eingang definierten Portpins. Bit 1 wenn Pin "high", Bit 0 wenn Portpin low.<br />
|-<br />
! PORTx<br />
| Datenregister für Port'''x'''. <br />
Dieses Register wird verwendet, um die Ausgänge eines Ports anzusteuern. Bei Pins, die mittels DDRx auf Eingang geschaltet wurden, können über PORTx<br />
die internen Pull-Up Widerstände aktiviert oder deaktiviert werden (1 = aktiv).<br />
|}<br />
<br />
Die folgenden Beispiele gehen von einem AVR aus, der sowohl Port A als auch Port B besitzt. Sie müssen für andere AVRs (zum Beispiel ATmega8/48/88/168) entsprechend angepasst werden.<br />
<br />
== Datenrichtung bestimmen ==<br />
<br />
Zuerst muss die Datenrichtung der verwendeten Pins bestimmt werden. Um dies zu erreichen, wird das Datenrichtungsregister des entsprechenden Ports beschrieben.<br />
<br />
Für jeden Pin, der als Ausgang verwendet werden soll, muss dabei das<br />
entsprechende Bit auf dem Port gesetzt werden. Soll der Pin als Eingang<br />
verwendet werden, muss das entsprechende Bit gelöscht sein.<br />
<br />
Beispiel:<br />
Angenommen am Port B sollen die Pins 0 bis 4 als Ausgänge definiert werden, die noch verbleibenden Pins 5 bis 7 sollen als Eingänge fungieren. Dazu ist es daher notwendig, im für das Port B zuständigen Datenrichtungsregister DDRB folgende Bitkonfiguration einzutragen<br />
<br />
+---+---+---+---+---+---+---+---+<br />
| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |<br />
+---+---+---+---+---+---+---+---+<br />
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br />
<br />
In C liest sich das dann so:<br />
<br />
<syntaxhighlight lang="c"><br />
// in io.h wird u.a. DDRB definiert:<br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binaer 00011111 = Hexadezimal 1F<br />
// direkte Zuweisung - standardkonform */<br />
DDRB = 0x1F; /* <br />
<br />
// Uebersichtliche Alternative - Binaerschreibweise, aber kein ISO-C<br />
DDRB = 0b00011111;<br />
<br />
// Ausfuehrliche Schreibweise: identische Funktionalitaet, mehr Tipparbeit<br />
// aber uebersichtlicher und selbsterklaerend:<br />
DDRB |= (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4); <br />
</syntaxhighlight><br />
<br />
Die Pins 5 bis 7 werden (da 0) als Eingänge geschaltet. Weitere Beispiele:<br />
<br />
<syntaxhighlight lang="c"><br />
// Alle Pins des Ports B als Ausgang definieren:<br />
DDRB = 0xff; <br />
// Pin0 wieder auf Eingang und andere im urspruenglichen Zustand belassen:<br />
DDRB &= ~(1 << DDB0);<br />
// Pin 3 und 4 auf Eingang und andere im urspruenglichen Zustand belassen:<br />
DDRB &= ~((1 << DDB3) | (1 << DDB4));<br />
// Pin 0 und 3 wieder auf Ausgang und andere im ursprünglichen Zustand belassen:<br />
DDRB |= (1 << DDB0) | (1 << DDB3);<br />
// Alle Pins auf Eingang:<br />
DDRB = 0x00;<br />
</syntaxhighlight><br />
<br />
== Vordefinierte Bitnummern für I/O-Register ==<br />
<br />
Die Bitnummern (z.&nbsp;B. PCx, PINCx und DDCx für den Port C) sind in den io*.h-Dateien der avr-libc definiert und dienen lediglich der besseren Lesbarkeit. Man muss diese Definitionen nicht verwenden oder kann auch einfach "immer" PAx, PBx, PCx usw. nutzen, auch wenn der Zugriff auf Bits in DDRx- oder PINx-Registern erfolgt. Für den Compiler sind die Ausdrücke (1<<PC7), (1<<DDC7) und (1<<PINC7) identisch zu (1<<7) (genauer: der Präprozessor ersetzt die Ausdrücke (1<<PC7),... zu (1<<7)). Ein Ausschnitt der Definitionen für Port C eines ATmega32 aus der iom32.h-Datei zur Verdeutlichung (analog für die weiteren Ports):<br />
<br />
<syntaxhighlight lang="c"><br />
...<br />
/* PORTC */<br />
#define PC7 7<br />
#define PC6 6<br />
#define PC5 5<br />
#define PC4 4<br />
#define PC3 3<br />
#define PC2 2<br />
#define PC1 1<br />
#define PC0 0<br />
<br />
/* DDRC */<br />
#define DDC7 7<br />
#define DDC6 6<br />
#define DDC5 5<br />
#define DDC4 4<br />
#define DDC3 3<br />
#define DDC2 2<br />
#define DDC1 1<br />
#define DDC0 0<br />
<br />
/* PINC */<br />
#define PINC7 7<br />
#define PINC6 6<br />
#define PINC5 5<br />
#define PINC4 4<br />
#define PINC3 3<br />
#define PINC2 2<br />
#define PINC1 1<br />
#define PINC0 0<br />
</syntaxhighlight><br />
<br />
<br />
== Digitale Signale ==<br />
<br />
Am einfachsten ist es, digitale Signale mit dem Mikrocontroller zu erfassen bzw. auszugeben.<br />
<br />
== Ausgänge ==<br />
Will man als Ausgang definierte Pins (entsprechende DDRx-Bits = 1) auf Logisch 1 setzen, setzt man die entsprechenden Bits im Portregister.<br />
<br />
Mit dem Befehl<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB = 0x04; /* besser PORTB=(1<<PB2) */<br />
<br />
// Uebersichtliche Alternative - Binaerschreibweise<br />
PORTB = 0b00000100; /* direkte Zuweisung - uebersichtlich */<br />
<br />
</syntaxhighlight><br />
wird also der Ausgang an Pin PB2 gesetzt (Beachte, dass die Bits immer ''von 0 an'' gezählt werden, das niederwertigste Bit ist also Bitnummer 0 und nicht etwa Bitnummer 1).<br />
<br />
Man beachte, dass bei der Zuweisung mittels '''=''' immer alle Pins gleichzeitig angegeben werden. Man sollte also, wenn nur bestimmte Ausgänge geschaltet werden sollen, zuerst den aktuellen Wert des Ports einlesen und das Bit des gewünschten Ports in diesen Wert einfließen lassen. Will man also nur den dritten Pin (Bit Nr. 2) an Port B auf "high" setzen und den Status der anderen Ausgänge unverändert lassen, nutze man diese Form:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB = PORTB | 0x04; /* besser: PORTB = PORTB | ( 1<<PB2 ) */<br />
/* vereinfacht durch Nutzung des |= Operators : */<br />
PORTB |= (1<<PB2);<br />
<br />
/* auch mehrere "gleichzeitig": */<br />
PORTB |= (1<<PB4) | (1<<PB5); /* Pins PB4 und PB5 "high" */<br />
</syntaxhighlight><br />
<br />
"Ausschalten", also Ausgänge auf "low" setzen, erfolgt analog:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB &= ~(1<<PB2); /* loescht Bit 2 in PORTB und setzt damit Pin PB2 auf low */ <br />
PORTB &= ~( (1<<PB4) | (1<<PB5) ); /* Pin PB4 und Pin PB5 "low" */<br />
</syntaxhighlight><br />
Siehe auch [[Bitmanipulation]]<br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind in aktuellen Versionen der avr-libc nicht mehr enthalten und auch nicht mehr erforderlich.<br />
<br />
''Falls der Anfangszustand von Ausgängen kritisch ist, muss die Reihenfolge beachtet werden, mit der die Datenrichtung (DDRx) eingestellt und der Ausgabewert (PORTx) gesetzt wird:''<br />
<br />
Für Ausgangspins, die mit Anfangswert "high" initialisiert werden sollen:<br />
* zuerst die Bits im PORTx-Register setzen<br />
* anschließend die Datenrichtung auf Ausgang stellen<br />
<br />
Daraus ergibt sich die Abfolge für einen Pin, der bisher als Eingang mit abgeschaltetem Pull-Up konfiguriert war:<br />
* setze PORTx: interner Pull-Up aktiv<br />
* setze DDRx: Ausgang ("high")<br />
<br />
Bei der Reihenfolge erst DDRx und dann PORTx kann es zu einem kurzen "low-Puls" kommen, der auch externe Pull-Up-Widerstände "überstimmt". Die (ungünstige) Abfolge: Eingang -> setze DDRx: Ausgang (auf "low", da PORTx nach Reset 0) -> setze PORTx: Ausgang auf high. Vergleiche dazu auch das Datenblatt Abschnitt ''Configuring the Pin''.<br />
<br />
== Eingänge (Wie kommen Signale in den &micro;C) ==<br />
<br />
Die digitalen Eingangssignale können auf verschiedene Arten zu unserer Logik gelangen.<br />
<br />
=== Signalkopplung ===<br />
<br />
Am einfachsten ist es, wenn die Signale direkt aus einer anderen digitalen Schaltung übernommen werden können. Hat der Ausgang der entsprechenden Schaltung TTL-Pegel dann können wir sogar direkt den Ausgang der Schaltung mit einem Eingangspin von unserem Controller verbinden.<br />
<br />
Hat der Ausgang der anderen Schaltung keinen TTL-Pegel so müssen wir den Pegel über entsprechende Hardware (z.&nbsp;B. Optokoppler, [[Widerstand#Spannungsteiler|Spannungsteiler]], "Levelshifter" aka [[Pegelwandler]]) anpassen.<br />
<br />
Die Masse der beiden Schaltungen muss selbstverständlich miteinander verbunden werden. Der Software selber ist es natürlich letztendlich egal, wie das Signal eingespeist wird. Wir können ja ohnehin lediglich prüfen, ob an einem Pin unseres Controllers eine logische 1 (Spannung größer ca. 0,7*Vcc) oder eine logische 0 (Spannung kleiner ca. 0,2*Vcc) anliegt. Detaillierte Informationen darüber, ab welcher Spannung ein Eingang als 0 ("low") bzw. 1 ("high") erkannt wird, liefert die Tabelle DC Characteristics im Datenblatt des genutzten Controllers.<br />
<br />
{| class="wikitable" style="text-align:center; width:20em"<br />
|+ '''Logikpegel'''<br />
|-<br />
! VCC [V]<br />
! Low [V]<br />
! High [V]<br />
|-<br />
! 5<br />
| 1,0 || 3,5<br />
|-<br />
! 3,3<br />
| 0,66 || 2,3<br />
|-<br />
! 1,8<br />
| 0,36 || 1,26 <br />
|}<br />
<br />
Die Abfrage der Zustände der Portpins erfolgt direkt über den Registernamen.<br />
<br />
{{Warnung|Dabei ist wichtig, zur Abfrage der Eingänge ''nicht'' etwa Portregister '''PORTx''' zu verwenden, sondern Eingangsregister '''PINx'''. Ansonsten liest man nicht den Zustand der Eingänge, sondern den Status der internen Pull-Up-Widerstände. Die Abfrage der Pinzustände über PORTx statt PINx ist ein häufiger Fehler beim AVR-"Erstkontakt".}}<br />
<br />
Will man also die aktuellen Signalzustände von Port D abfragen und in eine Variable namens bPortD abspeichern, schreibt man folgende Befehlszeilen:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdint.h><br />
...<br />
uint8_t bPortD;<br />
...<br />
bPortD = PIND;<br />
...<br />
</syntaxhighlight><br />
<br />
Mit den C-Bitoperationen kann man den Status der Bits abfragen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
/* Fuehre Aktion aus, wenn Bit Nr. 1 (das "zweite" Bit) in PINC gesetzt (1) ist */<br />
if ( PINC & (1<<PINC1) ) {<br />
/* Aktion */<br />
}<br />
<br />
/* Fuehre Aktion aus, wenn Bit Nr. 2 (das "dritte" Bit) in PINB geloescht (0) ist */<br />
if ( !(PINB & (1<<PINB2)) ) {<br />
/* Aktion */<br />
}<br />
...<br />
</syntaxhighlight><br />
Siehe auch [[Bitmanipulation#Bits_prüfen]]<br />
<br />
=== Interne Pull-Up Widerstände ===<br />
<br />
Portpins für Ein- und Ausgänge (GPIO) eines AVR verfügen über zuschaltbare interne Pull-Up Widerstände (nominal mehrere 10kOhm, z.&nbsp;B. ATmega16 20-50kOhm). Diese können in vielen Fällen statt externer Widerstände genutzt werden.<br />
<br />
Die internen Pull-Up Widerstände von Vcc zu den einzelnen Portpins werden über das Register ''' PORTx''' aktiviert bzw. deaktiviert, wenn ein Pin als ''' Eingang''' geschaltet ist.<br />
<br />
Wird der Wert des entsprechenden Portpins auf 1 gesetzt, so ist der Pull-Up Widerstand aktiviert. Bei einem Wert von 0 ist der Pull-Up Widerstand nicht aktiv. Man sollte jeweils entweder den internen oder einen externen Pull-Up Widerstand verwenden, aber nicht beide zusammen.<br />
<br />
Im Beispiel werden alle Pins des Ports D als Eingänge geschaltet und alle Pull-Up Widerstände aktiviert. Weiterhin wird Pin PC7 als Eingang geschaltet und dessen interner Pull-Up Widerstand aktiviert, ohne die Einstellungen für die anderen Portpins (PC0-PC6) zu verändern.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
DDRD = 0x00; /* alle Pins von Port D als Eingang */<br />
PORTD = 0xff; /* interne Pull-Ups an allen Port-Pins aktivieren */<br />
...<br />
DDRC &= ~(1<<PC7); /* Pin PC7 als Eingang */<br />
PORTC |= (1<<PC7); /* internen Pull-Up an PC7 aktivieren */<br />
</syntaxhighlight><br />
<br />
=== Taster und Schalter ===<br />
<br />
Der Anschluss mechanischer Kontakte an den Mikrocontroller, ist zwischen zwei unterschiedliche Methoden zu unterscheiden: ''Active Low'' und ''Active High''.<br />
<br />
<gallery widths="300" heights="300" caption="Anschluss mechanischer Kontakte an einen µC"><br />
Image:Active Low.gif|'''Active Low:''' Bei dieser Methode wird der Kontakt zwischen den Eingangspin des Controllers und Masse geschaltet. Damit bei offenem Schalter der Controller kein undefiniertes Signal bekommt, wird zwischen die Versorgungsspannung und den Eingangspin ein sogenannter '''Pull-Up''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffnetem Schalter auf logisch 1 zu ziehen.<br />
Image:Active High.gif|'''Active High:''' Hier wird der Kontakt zwischen die Versorgungsspannung und den Eingangspin geschaltet. Damit bei offener Schalterstellung kein undefiniertes Signal am Controller ansteht, wird zwischen den Eingangspin und die Masse ein '''Pull-Down''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffneter Schalterstellung auf logisch 0 zu halten. <br />
</gallery><br />
<br />
Der Widerstandswert von Pull-Up- und Pull-Down-Widerständen ist an sich nicht kritisch. Wird er allerdings zu hoch gewählt, ist die Wirkung eventuell nicht gegeben. Als üblicher Wert haben sich 10 kOhm eingebürgert. Die AVRs verfügen an den meisten Pins über zuschaltbare interne Pull-Up Widerstände (vgl. Abschnitt [[AVR-GCC-Tutorial#Interne Pull-Up Widerstände|Interne Pull-Up Widerstände]]), welche insbesondere wie hier bei Tastern und ähnlichen Bauteilen (z.&nbsp;B. Drehgebern) statt externer Bauteile verwendet werden können. Interne Pull-Down-Widerstand sind nicht verfügbar und müssen daher in Form zusätzlicher Bauteile in die Schaltung eingefügt werden.<br />
<br />
==== Taster entprellen ====<br />
<br />
Siehe: ''[[Entprellung#Warteschleifen-Verfahren|Entprellung: Warteschleifen-Verfahren]]<br />
<br />
= Warteschleifen (delay.h) =<br />
<br />
Der Programmablauf kann verschiedene Arten von Wartefunktionen erfordern:<br />
<br />
* Warten im Sinn von Zeitvertrödeln<br />
* Warten auf einen bestimmten Zustand an den I/O-Pins<br />
* Warten auf einen bestimmten Zeitpunkt (siehe Timer)<br />
* Warten auf einen bestimmten Zählerstand (siehe Counter)<br />
<br />
Der einfachste Fall, das Zeitvertrödeln, kann in vielen Fällen und mit großer Genauigkeit anhand der avr-libc Bibliotheksfunktionen _delay_ms() und _delay_us() erledigt werden. Die Bibliotheksfunktionen sind einfachen Zählschleifen (Warteschleifen) vorzuziehen, da leere Zählschleifen ohne besondere Vorkehrungen sonst bei eingeschalteter Optimierung vom avr-gcc-Compiler wegoptimiert werden. Weiterhin sind die Bibliotheksfunktionen bereits darauf vorbereitet, die in F_CPU definierte Taktfrequenz zu verwenden. Außerdem sind die Funktionen der Bibliothek wirklich getestet.<br />
<br />
Einfach!? Schon, aber während gewartet wird, macht der µC nichts anderes mehr (abgesehen von möglicherweise auftretenden Interrupts, falls welche aktiviert sind). Die Wartefunktion blockiert den Programmablauf. Möchte man einerseits warten, um z.&nbsp;B. eine LED blinken zu lassen und gleichzeitig andere Aktionen ausführen z.&nbsp;B. weitere LED bedienen, sollten die Timer/Counter des AVR verwendet werden, siehe Artikel [[Multitasking]].<br />
<br />
Die Bibliotheksfunktionen funktionieren allerdings nur dann korrekt, wenn sie mit zur Übersetzungszeit (beim Compilieren) bekannten konstanten Werten aufgerufen werden. Der Quellcode muss mit eingeschalteter Optimierung übersetzt werden, sonst wird sehr viel Maschinencode erzeugt, und die Wartezeiten stimmen nicht mehr mit dem Parameter überein.<br />
<br />
Eine weitere Einschränkung liegt darin, daß sie möglicherweise länger warten, als erwartet, nämlich in dem Fall, daß Interrupts auftreten und die _delay...()-Funktion unterbrechen. Genau genommen warten diese nämlich nicht eine bestimmte Zeit, sondern verbrauchen eine bestimmte Anzahl von Prozessortakten. Die wiederum ist so bemessen, daß ohne Unterbrechung durch Interrupts die gewünschte Wartezeit erreicht wird.<br />
Wird das Warten aber durch eine oder mehrere ISR unterbrochen, die zusammen 1% Prozessorzeit verbrauchen, dann dauert das Warten etwa 1% länger. Bei 50% Last durch die ISR dauert das Warten doppelt solange wie gewünscht, bei 90% zehnmal solange...<br />
<br />
Abhängig von der Version der Bibliothek verhalten sich die Bibliotheksfunktionen etwas unterschiedlich.<br />
<br />
== avr-libc Versionen bis 1.6 ==<br />
<br />
Die Wartezeit der Funktion _delay_ms() ist auf 262,14ms/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 13,1ms warten. Die Wartezeit der Funktion _delay_us() ist auf 768us/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 38,4µs warten. Längere Wartezeiten müssen dann über einen mehrfachen Aufruf in einer Schleife gelöst werden.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.&nbsp;B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h> /* in älteren avr-libc Versionen <avr/delay.h> */ <br />
<br />
/*<br />
lange, variable Verzögerungszeit, Einheit in Millisekunden<br />
<br />
Die maximale Zeit pro Funktionsaufruf ist begrenzt auf <br />
262.14 ms / F_CPU in MHz (im Beispiel: <br />
262.1 / 3.6864 = max. 71 ms) <br />
<br />
Daher wird die kleine Warteschleife mehrfach aufgerufen,<br />
um auf eine längere Wartezeit zu kommen. Die zusätzliche <br />
Prüfung der Schleifenbedingung lässt die Wartezeit geringfügig<br />
ungenau werden (macht hier vielleicht 2-3ms aus).<br />
*/<br />
<br />
void long_delay(uint16_t ms)<br />
{<br />
for(; ms>0; ms--) _delay_ms(1);<br />
}<br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) // Endlosschleife<br />
{ <br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.&nbsp;B. angeschlossene LED<br />
long_delay(1000); // Eine Sekunde warten...<br />
}<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
== avr-libc Versionen ab 1.7 ==<br />
<br />
_delay_ms() kann mit einem Argument bis 6553,5 ms (= 6,5535 Sekunden) benutzt werden. Es ist nicht möglich, eine Variable als Argument zu übergeben. Wird die früher gültige Grenze von 262,14 ms/F_CPU (in MHz) überschritten, so arbeitet _delay_ms() einfach etwas ungenauer und zählt nur noch mit einer Auflösung von 1/10 ms. Eine Verzögerung von 1000,10 ms ließe sich nicht mehr von einer von 1000,19 ms unterscheiden. Ein Verlust, der sich im Allgemeinen verschmerzen lässt. Dem Programmierer wird keine Rückmeldung gegeben, dass die Funktion ggf. gröber arbeitet, d.h. wenn es darauf ankommt, bitte den Parameter wie bisher geschickt wählen.<br />
<br />
Die Funktion _delay_us() wurde ebenfalls erweitert. Wenn deren maximal als genau behandelbares Argument überschritten wird, benutzt diese intern _delay_ms(). Damit gelten in diesem Fall die _delay_ms() Einschränkungen.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus, avr-libc ab Version 1.6<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h><br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) { // Endlosschleife<br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED<br />
_delay_ms(1000); // Eine Sekunde +/-1/10000 Sekunde warten...<br />
// funktioniert nicht mit Bibliotheken vor 1.6<br />
<br />
}<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
Die _delay_ms() und die _delay_us aus '''avr-libc 1.7.0''' sind fehlerhaft. _delay_ms () läuft 4x schneller als erwartet. Abhilfe ist eine korrigierte Includedatei: [http://www.mikrocontroller.net/topic/196738#1943039]<br />
<br />
= Programmieren mit Interrupts =<br />
<br />
<div style="float:right; margin:2em;"><br />
[[Image:Interrupt Programme.gif]]<br />
</div><br />
Nachdem wir nun alles Wissenswerte für die serielle Programmerstellung<br />
gelernt haben nehmen wir jetzt ein völlig anderes Thema in Angriff, nämlich<br />
die Programmierung unter Zuhilfenahme der Interrupts des AVR.<br />
<br />
Tritt ein Interrupt auf, unterbricht (engl. interrupts) der Controller die Verarbeitung des Hauptprogramms und verzweigt zu einer Interruptroutine. Das Hauptprogramm wird also beim Eintreffen eines Interrupts unterbrochen, die Interruptroutine ausgeführt und danach erst wieder das Hauptprogramm an der Unterbrechungsstelle fortgesetzt (vgl. die Abbildung).<br />
<br />
Um Interrupts verarbeiten zu können, ist folgendes zu beachten:<br />
<br />
* Für jede aktivierte Interruptquelle ist eine Funktion zu programmieren, in der die beim Auftreten des jeweiligen Interrupts erforderlichen Verarbeitungsschritte enthalten sind. Für diese Funktion existieren verschiedene Bezeichnungen. Üblich sind die englischen Begriffe Interrupt-Handler oder Interrupt-Service-Routinen (ISR), man findet aber auch die Bezeichnungen Interruptverarbeitungs- oder -behandlungsroutine oder auch kurz Interruptroutine. Zum Beispiel wird üblicherweise in der ISR zur Verarbeitung des Empfangsinterrupts eines UARTs (UART-RX Interrupt) das empfangene Zeichen in einen Zwischenspeicher (FIFO-Buffer) kopiert, dessen Inhalt später von anderen Programmteilen geleert wird. Sofern der Zwischenspeicher ausreichend groß ist, geht also kein Zeichen verloren, auch wenn im Hauptprogramm zeitintensive Operationen durchgeführt werden.<br />
* Die benötigten Interrupts sind in den jeweiligen Funktionsbausteinen einzuschalten. Dies erfolgt über das jeweilige Aktivierungsbit (Interrupt Enable) in einem der Hardwareregister (z.B. RX(Complete)Interrupt Enable eines UARTs)<br />
* Sämtliche Interrupts werden über einen weiteren globalen Schalter aktiviert und deaktiviert. Zur Verarbeitung der Interrupts ist dieser Schalter zu aktivieren (sei(), siehe unten).<br />
<br />
Alle Punkte sind zu beachten. Fehlt z.B. die globale Aktivierung, werden Interruptroutinen auch dann nicht aufgerufen, wenn sie im Funktionsbaustein eingeschaltet sind und eine Behandlungsroutine verhanden ist.<br />
<br />
Siehe auch<br />
<br />
* [http://www.mikrocontroller.net/forum/read-1-235092.html#new Ausführlicher Thread im Forum]<br />
* Artikel [[Interrupt]]<br />
* Artikel [[Multitasking]]<br />
{{Clear}}<br />
<br />
== Anforderungen an Interrupt-Routinen ==<br />
<br />
Um unliebsamen Überraschungen vorzubeugen, sollten einige Grundregeln bei der Implementierung der Interruptroutinen beachtet werden. Interruptroutinen sollten möglichst kurz und schnell abarbeitbar sein, daraus folgt:<br />
<br />
* Keine umfangreichen Berechnungen innerhalb der Interruptroutine. (*)<br />
* Keine langen Programmschleifen.<br />
* Obwohl es möglich ist, während der Abarbeitung einer Interruptroutine andere oder sogar den gleichen Interrupt wieder zuzulassen, wird davon ohne genaue Kenntnis der internen Abläufe dringend abgeraten.<br />
<br />
Interruptroutinen (ISRs) sollten also möglichst kurz sein und keine Schleifen mit vielen Durchläufen enthalten. Längere Operationen können meist in einen "Interrupt-Teil" in einer ISR und einen "Arbeitsteil" im Hauptprogramm aufgetrennt werden. Z.B. Speichern des Zustands aller Eingänge im EEPROM in bestimmten Zeitabständen: ISR-Teil: Zeitvergleich (Timer,RTC) mit Logzeit/-intervall. Bei Übereinstimmung ein globales Flag setzen (volatile bei Flag-Deklaration nicht vergessen, s.u.). Dann im Hauptprogramm prüfen, ob das Flag gesetzt ist. Wenn ja: die Daten im EEPROM ablegen und Flag löschen.<br />
<br />
(*)<br />
Hinweis: <br />
Es gibt allerdings die seltene Situation, dass man gerade eingelesene<br />
ADC-Werte sofort verarbeiten muss. Besonders dann, wenn man mehrere Werte sehr<br />
schnell hintereinander bekommt. Dann bleibt einem nichts anderes übrig, als die<br />
Werte noch in der ISR zu verarbeiten. Kommt aber sehr selten vor und sollte<br />
durch geeignete Wahl des Systemtaktes bzw. Auswahl des Controllers vermieden werden!<br />
<br />
== Interrupt-Quellen ==<br />
<br />
Die folgenden Ereignisse können einen Interrupt auf einem AVR AT90S2313 auslösen, wobei die Reihenfolge der Auflistung auch die Priorität der Interrupts aufzeigt.<br />
<br />
* Reset<br />
* Externer Interrupt 0<br />
* Externer Interrupt 1<br />
* Timer/Counter 1 Capture Ereignis<br />
* Timer/Counter 1 Compare Match<br />
* Timer/Counter 1 Überlauf<br />
* Timer/Counter 0 Überlauf<br />
* UART Zeichen empfangen<br />
* UART Datenregister leer<br />
* UART Zeichen gesendet<br />
* Analoger Komparator<br />
<br />
Die Anzahl der möglichen Interruptquellen variiert zwischen den verschiedenen Microcontroller-Typen. Im Zweifel hilft ein Blick ins Datenblatt ("Interrupt Vectors").<br />
<br />
== Register ==<br />
<br />
Der AT90S2313 verfügt über 2 Register die mit den<br />
Interrupts zusammenhängen.<br />
<br />
{| class="wikitable"<br />
|- <br />
!width="10%"| GIMSK<br />
| '''G'''eneral '''I'''nterrupt '''M'''a'''sk''' Register.<br /><br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit <br />
| 7 || 6|| 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INT1''' || '''INT0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INT1''' (External '''Int'''errupt Request '''1''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT1'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
'''INT0''' (External '''Int'''errupt Request '''0''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT0'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
|- <br />
! GIFR<br />
| '''G'''eneral '''I'''nterrupt '''F'''lag '''R'''egister.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INTF1''' || '''INTF0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INTF1''' (External '''Int'''errupt Flag '''1''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT1'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
<br />
'''INTF0''' (External '''Int'''errupt Flag '''0''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT0'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
|- <br />
! MCUCR<br />
| '''MCU''' '''C'''ontrol '''R'''egister.<br />
<br />
Das MCU Control Register enthält Kontrollbits für allgemeine MCU-Funktionen.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''-'''|| '''-'''|| '''SE'''|| '''SM'''|| '''ISC11'''|| '''ISC10'''|| '''ISC01'''|| '''ISC00'''<br />
|- <br />
! R/W<br />
| R || R || R/W || R/W || R/W || R/W || R/W || R/W<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
<br />
|}<br />
<br />
'''SE''' ('''S'''leep '''E'''nable)<br />
:Dieses Bit muss gesetzt sein, um den Controller mit dem '''SLEEP'''-Befehl in den Schlafzustand versetzen zu können.<br />
:Um den Schlafmodus nicht irrtümlich einzuschalten, wird empfohlen, das Bit erst unmittelbar vor Ausführung des '''SLEEP'''-Befehls zu setzen.<br />
<br />
'''SM''' ('''S'''leep '''M'''ode)<br />
:Dieses Bit bestimmt über den Schlafmodus.<br />
:Ist das Bit gelöscht, so wird der '''Idle'''-Modus ausgeführt. Ist das Bit gesetzt, so wird der '''Power-Down'''-Modus ausgeführt. (für andere AVR Controller siehe Abschnitt "Sleep-Mode")<br />
<br />
'''ISC11''', '''ISC10''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''1''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT1'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
!width="10%"| ISC11 ||width="10%"| ISC10 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT1''' erzeugt einen Interrupt.<br />
<br />
Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|}<br />
<br />
'''ISC01''', '''ISC00''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''0''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT0'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
!width="10%"| ISC01 ||width="10%"| ISC00 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT0''' erzeugt einen Interrupt.<br />
<br />
Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|}<br />
<br />
|}<br />
<br />
== Allgemeines über die Interrupt-Abarbeitung ==<br />
<br />
Wenn ein Interrupt eintrifft, wird automatisch das '''Global Interrupt Enable''' Bit im Status Register '''SREG''' gelöscht und alle weiteren Interrupts unterbunden. Dieses wird automatisch wieder gesetzt, wenn die Interruptroutine beendet wird. Wenn in der Zwischenzeit weitere Interrupts eintreffen, werden die zugehörigen Interrupt-Bits gesetzt und die Interrupts bei Beendigung der laufenden Interrupt-Routine in der Reihenfolge ihrer Priorität ausgeführt. Dies kann<br />
eigentlich nur dann zu Problemen führen, wenn ein hoch priorisierter Interrupt ständig und in kurzer Folge auftritt. Dieser sperrt dann möglicherweise alle anderen Interrupts mit niedrigerer Priorität. Dies ist einer der Gründe, weshalb die Interrupt-Routinen sehr kurz gehalten werden sollen. Es ist möglich das GIE-Bit in der ISR zu setzen und so schon wieder weitere Interrupts zuzulassen - allerdings sollte man damit vorsichtig sein und genau wissen was man damit macht. Kritisch wird es vor allem wenn der gleiche Interrupt noch einmal kommt, bevor die ISR abgearbeitet ist. <br />
<br />
<!-- === Das Status-Register ===<br />
<br />
Es gilt auch zu beachten, dass das Status-Register während der Abarbeitung einer Interruptroutine nicht automatisch gesichert wird. Falls notwendig, muss dies vom Programmierer selber vorgesehen werden. --><br />
<br />
== Interrupts mit avr-gcc ==<br />
<br />
<!-- ''Anmerkung eines Nutzers: Ich habe mir das Thema hier angearbeitet und hatte am Anfang starke Probleme: Jeder Interrupt muss nochmals einzeln aktiviert werden. Es reicht nicht nur per ''sei()'' die Interrupts global zu aktiveren.'' - mthomas: Hoffentlich duch die modifizerte Einleitung etwas offensichtlicher erläutert. Ansonsten bitte per Eintrag auf die Diskussionseite nochmals melden) --> <br />
<!-- Selbstverständlich können alle interruptspezifischen Registerzugriffe wie gewohnt über I/O-Adressierung vorgenommen werden. Etwas einfacher geht es jedoch, wenn wir die vom Compiler zur Verfügung gestellten Mittel einsetzen.--><br />
Funktionen zur Interrupt-Verarbeitung werden in den Includedateien ''interrupt.h'' der avr-libc zur Verfügung gestellt (bei älterem Quellcode zusätzlich ''signal.h'').<br />
<br />
<syntaxhighlight lang="c"><br />
// fuer sei(), cli() und ISR():<br />
#include <avr/interrupt.h><br />
</syntaxhighlight><br />
<br />
Das Makro '''sei()''' schaltet die Interrupts ein. Eigentlich wird nichts anderes gemacht, als das '''Global Interrupt Enable''' Bit im Status Register gesetzt.<br />
<br />
<syntaxhighlight lang="c"><br />
sei();<br />
</syntaxhighlight><br />
<br />
Das Makro '''cli()''' schaltet die Interrupts aus, oder anders gesagt, das '''Global Interrupt Enable''' Bit im Status Register wird gelöscht.<br />
<br />
<syntaxhighlight lang="c"><br />
cli();<br />
</syntaxhighlight><br />
<br />
Oft steht man vor der Aufgabe, dass eine Codesequenz nicht unterbrochen werden darf. Es liegt dann nahe, zu Beginn dieser Sequenz ein cli() und am Ende ein sei() einzufügen. Dies ist jedoch ungünstig, wenn die Interrupts vor Aufruf der Sequenz deaktiviert waren und danach auch weiterhin deaktiviert bleiben sollen. Ein sei() würde ungeachtet des vorherigen Zustands die Interrupts aktivieren, was zu unerwünschten Seiteneffekten führen kann. Die aus dem folgenden Beispiel ersichtliche Vorgehensweise ist in solchen Fällen vorzuziehen:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <inttypes.h><br />
<br />
//...<br />
<br />
void NichtUnterbrechenBitte(void)<br />
{<br />
uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister<br />
<br />
tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) sichern<br />
cli(); // Interrupts global deaktivieren<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
/* Beispiel Anfang<br />
JTAG-Interface eines ATmega16 per Software deaktivieren <br />
und damit die JTAG-Pins an PORTC für "general I/O" nutzbar machen<br />
ohne die JTAG-Fuse-Bit zu aendern. Dazu ist eine "timed sequence"<br />
einzuhalten (vgl Datenblatt ATmega16, Stand 10/04, S. 229): <br />
Das JTD-Bit muss zweimal innerhalb von 4 Taktzyklen geschrieben <br />
werden. Ein Interrupt zwischen den beiden Schreibzugriffen wuerde <br />
die erforderliche Sequenz "brechen", das JTAG-Interface bliebe<br />
weiterhin aktiv und die IO-Pins weiterhin für JTAG reserviert. */<br />
<br />
MCUCSR |= (1<<JTD);<br />
MCUCSR |= (1<<JTD); // 2 mal in Folge ,vgl. Datenblatt fuer mehr Information<br />
<br />
/* Beispiel Ende */<br />
<br />
SREG = tmp_sreg; // Status-Register wieder herstellen <br />
// somit auch das I-Flag auf gesicherten Zustand setzen<br />
}<br />
<br />
void NichtSoGut(void)<br />
{<br />
cli();<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
sei();<br />
}<br />
<br />
<br />
int main(void)<br />
{<br />
//...<br />
<br />
cli(); <br />
// Interrupts global deaktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// auch nach Aufruf der Funktion deaktiviert<br />
<br />
sei();<br />
// Interrupts global aktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// weiterhin aktiviert<br />
//...<br />
<br />
/* Verdeutlichung der unguenstigen Vorgehensweise mit cli/sei: */<br />
cli(); <br />
// Interrupts jetzt global deaktiviert <br />
<br />
NichtSoGut();<br />
// nach Aufruf der Funktion sind Interrupts global aktiviert <br />
// dies ist mglw. ungewollt!<br />
//...<br />
<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
<!-- mt: besser so nicht(?), lieber "datenblattkonform"<br />
<br />
<font face="Courier New">'''timer_enable_int (unsigned char ints);<br /><br />
'''</font>Schaltet Timerbezogene Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle<br />
Timerinterrupts ausgeschaltet, ansonsten muss in '''ints''' angegeben werden,<br />
welche Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">timer_enable_int (1 << TOIE1));<br /><br />
</font>'''Achtung: Wenn ein Timerinterrupt eingeschaltet wird während ein<br />
anderer Timerinterrupt bereits läuft, dann müssen beide Bits angegeben werden<br />
sonst wird der andere Timerinterrupt versehentlich ausgeschaltet.<br />
<br />
<font face="Courier New">'''enable_external_int (unsigned char ints);<br /><br />
'''</font>Schaltet die externen Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle externen<br />
Interrrups ausgeschaltet, ansonsten muss in '''ints''' angegeben werden, welche<br />
Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">enable_external_int ((1<<br />
</font>'''Schaltet die externen Interrupts 0 und 1 ein.<br />
<br />
Nachdem nun die Interrupts aktiviert sind, braucht es selbstverständlich noch den auszuführenden Code, der ablaufen soll, wenn ein Interrupt eintrifft.<br />
--><br />
Zu den aktivierten Interrupts ist eine Funktion zu programmieren, deren Code aufgerufen wird, wenn der betreffende Interrupt auftritt (Interrupt-Handler, Interrupt-Service-Routine). Dazu existiert die Definition (ein Makro) '''ISR'''.<br />
<br />
=== ISR ===<br />
<br />
(''ISR()'' ersetzt bei neueren Versionen der avr-libc ''SIGNAL()''. SIGNAL sollte nicht mehr genutzt werden, zur Portierung von SIGNAL nach ISR siehe den [[AVR-GCC-Tutorial#Anhang|Anhang]].)<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
//...<br />
ISR(Vectorname) /* vormals: SIGNAL(siglabel) dabei Vectorname != siglabel ! */<br />
{<br />
/* Interrupt Code */<br />
}<br />
</syntaxhighlight><br />
<br />
Mit ''ISR'' wird eine Funktion für die Bearbeitung eines Interrupts eingeleitet. Als Argument muss dabei die Benennung des entsprechenden Interruptvektors angegeben werden. Diese sind in den jeweiligen Includedateien IOxxxx.h zu finden. Die Bezeichnung entspricht dem Namen aus dem Datenblatt, bei dem die Leerzeichen durch Unterstriche ersetzt sind und ein ''_vect'' angehängt ist.<br />
<br />
Als Beispiel ein Ausschnitt aus der Datei für den ATmega8 (bei WinAVR Standardinstallation in C:\WinAVR\avr\include\avr\iom8.h) in der neben den aktuellen Namen für ''ISR'' (*_vect) noch die Bezeichnungen für das inzwischen nicht mehr aktuelle ''SIGNAL'' (SIG_*) enthalten sind.<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
/* $Id: iom8.h,v 1.13 2005/10/30 22:11:23 joerg_wunsch Exp $ */<br />
<br />
/* avr/iom8.h - definitions for ATmega8 */<br />
//...<br />
<br />
/* Interrupt vectors */<br />
<br />
/* External Interrupt Request 0 */<br />
#define INT0_vect _VECTOR(1)<br />
#define SIG_INTERRUPT0 _VECTOR(1)<br />
<br />
/* External Interrupt Request 1 */<br />
#define INT1_vect _VECTOR(2)<br />
#define SIG_INTERRUPT1 _VECTOR(2)<br />
<br />
/* Timer/Counter2 Compare Match */<br />
#define TIMER2_COMP_vect _VECTOR(3)<br />
#define SIG_OUTPUT_COMPARE2 _VECTOR(3)<br />
<br />
/* Timer/Counter2 Overflow */<br />
#define TIMER2_OVF_vect _VECTOR(4)<br />
#define SIG_OVERFLOW2 _VECTOR(4)<br />
<br />
/* Timer/Counter1 Capture Event */<br />
#define TIMER1_CAPT_vect _VECTOR(5)<br />
#define SIG_INPUT_CAPTURE1 _VECTOR(5)<br />
<br />
/* Timer/Counter1 Compare Match A */<br />
#define TIMER1_COMPA_vect _VECTOR(6)<br />
#define SIG_OUTPUT_COMPARE1A _VECTOR(6)<br />
<br />
/* Timer/Counter1 Compare Match B */<br />
#define TIMER1_COMPB_vect _VECTOR(7)<br />
#define SIG_OUTPUT_COMPARE1B _VECTOR(7)<br />
<br />
//...<br />
</syntaxhighlight><br />
<br />
<!--Vor Nutzung von SIGNAL muss ebenfalls die Header-Datei signal.h eingebunden werden.--> <br />
Mögliche Funktionsrümpfe für Interruptfunktionen sind zum Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
/* veraltet: #include <avr/signal.h> */<br />
<br />
ISR(INT0_vect) /* veraltet: SIGNAL(SIG_INTERRUPT0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(TIMER0_OVF_vect) /* veraltet: SIGNAL(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(USART_RXC_vect) /* veraltet: SIGNAL(SIG_UART_RECV) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
// und so weiter und so fort...<br />
</syntaxhighlight><br />
<br />
Auf die korrekte Schreibweise der Vektorbezeichnung ist zu achten. Der gcc-Compiler prüft erst ab Version 4.x, ob ein Signal/Interrupt der angegebenen Bezeichnung tatsächlich in der Includedatei definiert ist und gibt andernfalls eine Warnung aus. Bei WinAVR (ab 2/2005) wurde die Überprüfung auch in den mitgelieferten Compiler der Version 3.x integriert. Aus dem gcc-Quellcode Version 3.x selbst erstellte Compiler enthalten die Prüfung nicht (vgl. [[AVR-GCC]]). <br />
<br />
Während der Ausführung der Funktion sind alle weiteren Interrupts automatisch gesperrt. Beim Verlassen der Funktion werden die Interrupts wieder zugelassen.<br />
<br />
Sollte während der Abarbeitung der Interruptroutine ein weiterer Interrupt (gleiche oder andere Interruptquelle) auftreten, so wird das entsprechende Bit im zugeordneten Interrupt Flag Register gesetzt und die entsprechende Interruptroutine automatisch nach dem Beenden der aktuellen Funktion aufgerufen.<br />
<br />
Ein Problem ergibt sich eigentlich nur dann, wenn während der Abarbeitung der aktuellen Interruptroutine mehrere gleichartige Interrupts auftreten. Die entsprechende Interruptroutine wird im Nachhinein zwar aufgerufen jedoch wissen wir nicht, ob nun der entsprechende Interrupt einmal, zweimal oder gar noch öfter aufgetreten ist. Deshalb soll hier noch einmal betont werden, dass Interruptroutinen so schnell wie nur irgend möglich wieder verlassen werden sollten.<br />
<br />
=== Unterbrechbare Interruptroutinen ===<br />
<br />
"Faustregel": im Zweifel '''ISR'''. Die nachfolgend beschriebene Methode nur dann verwenden, wenn man sich über die unterschiedliche Funktionsweise im Klaren ist.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
<br />
ISR(XXX,ISR_NOBLOCK) /* veraltet: INTERRUPT(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt-Code */<br />
}<br />
</syntaxhighlight><br />
<br />
Hierbei steht XXX für den oben beschriebenen Namen des Vektors (also z.&nbsp;B. ''TIMER0_OVF_vect''). Der Unterschied im Vergleich zu einer herkömmlichen ISR ist, dass hier beim Aufrufen der Funktion das '''Global Enable Interrupt''' Bit durch Einfügen einer SEI-Anweisung direkt wieder gesetzt und somit alle Interrupts zugelassen werden &ndash; auch XXX-Interrupts. <br />
<br />
Bei unsachgemässer Handhabung kann dies zu erheblichen Problemen durch Rekursion wie einem Stack-Overflow oder anderen unerwarteten Effekten führen und sollte wirklich nur dann eingesetzt werden, wenn man sich sicher ist, das Ganze auch im Griff zu haben.<br />
<br />
Insbesondere sollte möglichst am ISR-Anfang die auslösende IRQ-Quelle deaktiviert und erst am Ende der ISR wieder aktiviert werden. Robuster als die Verwendung einer NOBLOCK-ISR ist daher folgender ISR-Aufbau:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
<br />
ISR (XXX) <br />
{<br />
// Implementiere die ISR ohne zunaechst weitere IRQs zuzulassen<br />
<br />
<<Deaktiviere die XXX-IRQ>><br />
<br />
// Erlaube alle Interrupts (ausser XXX)<br />
sei();<br />
<br />
//... Code ...<br />
<br />
// IRQs global deaktivieren um die XXX-IRQ wieder gefahrlos <br />
// aktivieren zu koennen<br />
cli();<br />
<br />
<<Aktiviere die XXX-IRQ>><br />
}<br />
</syntaxhighlight><br />
Auf diese Weise kann sich die XXX-IRQ nicht selbst unterbrechen, was zu einer Art Endlosschleife führen würde.<br />
<br />
Siehe auch: Hinweise in [[AVR-GCC]]<br />
<br />
siehe dazu: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html<br />
<br />
== Datenaustausch mit Interrupt-Routinen ==<br />
<br />
Variablen, die sowohl in Interrupt-Routinen (ISR = Interrupt Service Routine(s)) als auch vom übrigen Programmcode geschrieben oder gelesen werden, müssen mit einem '''volatile''' deklariert werden. Damit wird dem Compiler mitgeteilt, dass der Inhalt der Variablen vor jedem Lesezugriff aus dem Speicher gelesen und nach jedem Schreibzugriff in den Speicher geschrieben wird. Ansonsten könnte der Compiler den Code so optimieren, dass der Wert der Variablen nur in Prozessorregistern zwischengespeichert wird, die nichts von der Änderung woanders mitbekommen.<br />
<br />
Zur Veranschaulichung ein Codefragment für eine Tastenentprellung mit Erkennung einer "lange gedrückten" Taste.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <stdint.h><br />
//...<br />
<br />
// Schwellwerte<br />
// Entprellung: <br />
#define CNTDEBOUNCE 10<br />
// "lange gedrueckt:"<br />
#define CNTREPEAT 200<br />
<br />
// hier z.&nbsp;B. Taste an Pin2 PortA "active low" = 0 wenn gedrueckt<br />
#define KEY_PIN PINA<br />
#define KEY_PINNO PA2<br />
<br />
// beachte: volatile! <br />
volatile uint8_t gKeyCounter;<br />
<br />
// Timer-Compare Interrupt ISR, wird z.B. alle 10ms ausgefuehrt<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
// hier wird gKeyCounter veraendert. Die übrigen<br />
// Programmteile müssen diese Aenderung "sehen":<br />
// volatile -> aktuellen Wert immer in den Speicher schreiben<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
}<br />
else {<br />
gKeyCounter = 0;<br />
}<br />
}<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
//...<br />
/* hier: Initialisierung der Ports und des Timer-Interrupts */<br />
//... <br />
// hier wird auf gKeyCounter zugegriffen. Dazu muss der in der<br />
// ISR geschriebene Wert bekannt sein:<br />
// volatile -> aktuellen Wert immer aus dem Speicher lesen<br />
if ( gKeyCounter > CNTDEBOUNCE ) { // Taste mind. 10*10 ms "prellfrei"<br />
if (gKeyCounter == CNTREPEAT) {<br />
/* hier: Code fuer "Taste lange gedrueckt" */<br />
}<br />
else {<br />
/* hier: Code fuer "Taste kurz gedrueckt" */<br />
}<br />
}<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Wird innerhalb einer ISR mehrfach auf eine mit volatile deklarierte Variable zugegriffen, wirkt sich dies ungünstig auf die Verarbeitungsgeschwindigkeit aus, da bei jedem Zugriff mit dem Speicherinhalt abgeglichen wird. Da bei AVR-Controllern ''innerhalb'' einer ISR keine Unterbrechungen zu erwarten sind, bietet es sich an, einen Zwischenspeicher in Form einer lokalen Variable zu verwenden, deren Inhalt zu Beginn und am Ende mit dem der volatile Variable synchronisiert wird. Lokale Variable werden bei eingeschalteter Optimierung mit hoher Wahrscheinlichkeit in Prozessorregistern verwaltet und der Zugriff darauf ist daher nur mit wenigen internen Operationen verbunden. Die ISR aus dem vorherigen Beispiel lässt sich so optimieren:<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter; // Uebernahme in lokale Arbeitsvariable<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (tmp_kc < CNTREPEAT) {<br />
tmp_kc++;<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc; // Zurueckschreiben<br />
}<br />
//...<br />
</syntaxhighlight><br />
<br />
Zum Vergleich die Disassemblies (Ausschnitte der "lss-Dateien", compiliert für ATmega162) im Anschluss. Man erkennt den viermaligen Zugriff auf die Speicheraddresse von ''gKeyCounter'' (hier 0x032A) in der ISR ohne "Cache"-Variable und den zweimaligen Zugriff in der Variante mit Zwischenspeicher. Im Beispiel ist der Vorteil gering, bei komplexeren Routinen kann die Zwischenspeicherung in lokalen Variablen jedoch zu deutlicheren Verbesserungen führen.<br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
876: ca 99 sbic 0x19, 2 ; 25<br />
878: 0a c0 rjmp .+20 ; 0x88e <__vector_13+0x24><br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
87a: 80 91 2a 03 lds r24, 0x032A<br />
87e: 88 3c cpi r24, 0xC8 ; 200 <br />
880: 40 f4 brcc .+16 ; 0x892 <__vector_13+0x28><br />
882: 80 91 2a 03 lds r24, 0x032A<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 02 c0 rjmp .+4 ; 0x892 <__vector_13+0x28><br />
}<br />
else {<br />
gKeyCounter = 0;<br />
88e: 10 92 2a 03 sts 0x032A, r1<br />
892: 8f 91 pop r24<br />
894: 0f 90 pop r0<br />
896: 0f be out 0x3f, r0 ; 63<br />
898: 0f 90 pop r0<br />
89a: 1f 90 pop r1<br />
89c: 18 95 reti<br />
</pre><br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter;<br />
876: 80 91 2a 03 lds r24, 0x032A<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
87a: ca 9b sbis 0x19, 2 ; 25<br />
87c: 02 c0 rjmp .+4 ; 0x882 <__vector_13+0x18><br />
87e: 80 e0 ldi r24, 0x00 ; 0<br />
880: 03 c0 rjmp .+6 ; 0x888 <__vector_13+0x1e><br />
if (tmp_kc < CNTREPEAT) {<br />
882: 88 3c cpi r24, 0xC8 ; 200<br />
884: 08 f4 brcc .+2 ; 0x888 <__vector_13+0x1e><br />
tmp_kc++;<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc;<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 8f 91 pop r24<br />
88e: 0f 90 pop r0<br />
890: 0f be out 0x3f, r0 ; 63<br />
892: 0f 90 pop r0<br />
894: 1f 90 pop r1<br />
896: 18 95 reti<br />
</pre><br />
<br />
=== volatile und Pointer ===<br />
<br />
Bei '''volatile''' in Verbindung mit Pointern ist zu beachten, ob der Pointer selbst oder die Variable, auf die der Pointer zeigt, '''volatile''' ist.<br />
<br />
<syntaxhighlight lang="c"><br />
volatile uint8_t *a; // das Ziel von a ist volatile<br />
<br />
uint8_t *volatile a; // a selbst ist volatile<br />
</syntaxhighlight><br />
<br />
Falls der Pointer volatile ist (zweiter Fall im Beispiel), ist zu beachten, dass der Wert des Pointers, also eine Speicheradresse, intern in mehr als einem Byte verwaltet wird. Lese- und Schreibzugriffe im Hauptprogramm (außerhalb von Interrupt-Routinen) sind daher so zu implementieren, dass alle Teilbytes der Adresse konsistent bleiben, vgl. dazu den folgenden Abschnitt.<br />
<br />
=== Variablen größer 1 Byte ===<br />
<br />
Bei Variablen größer ein Byte, auf die in Interrupt-Routinen und im Hauptprogramm zugegriffen wird, muss darauf geachtet werden, dass die Zugriffe auf die einzelnen Bytes außerhalb der ISR nicht durch einen Interrupt unterbrochen werden. (Allgemeinplatz: AVRs sind 8-bit Controller). Zur Veranschaulichung ein Codefragment:<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
volatile uint16_t gMyCounter16bit;<br />
//...<br />
ISR(...)<br />
{<br />
//...<br />
gMyCounter16Bit++;<br />
//...<br />
}<br />
<br />
int main(void)<br />
{<br />
uint16_t tmpCnt;<br />
//...<br />
// nicht gut: Mglw. hier ein Fehler, wenn ein Byte von MyCounter <br />
// schon in tmpCnt kopiert ist aber vor dem Kopieren des zweiten Bytes <br />
// ein Interrupt auftritt, der den Inhalt von MyCounter verändert.<br />
tmpCnt = gMyCounter16bit; <br />
<br />
<br />
// besser: Änderungen "außerhalb" verhindern -> alle "Teilbytes"<br />
// bleiben konsistent<br />
cli(); // Interrupts deaktivieren<br />
tmpCnt = gMyCounter16Bit;<br />
sei(); // wieder aktivieren<br />
<br />
// oder: vorheriger Status des globalen Interrupt-Flags bleibt erhalten<br />
uint8_t sreg_tmp;<br />
sreg_tmp = SREG; /* Sichern */<br />
cli()<br />
tmpCnt = gMyCounter16Bit;<br />
SREG = sreg_tmp; /* Wiederherstellen */<br />
<br />
// oder: mehrfach lesen, bis man konsistente Daten hat<br />
uint16_t count1 = gMyCounter16Bit;<br />
uint16_t count2 = gMyCounter16Bit;<br />
while (count1 != count2) {<br />
count1 = count2;<br />
count2 = gMyCounter16Bit;<br />
}<br />
tmpCnt = count1;<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Die avr-libc bietet ab Version 1.6.0(?) einige Hilfsfunktionen/Makros, mit der im Beispiel oben gezeigten Funktionalität, die zusätzlich auch sogenannte [http://en.wikipedia.org/wiki/Memory_barrier memory barriers] beinhalten. Diese stehen nach #include <util/atomic.h> zur Verfügung.<br />
<syntaxhighlight lang="c"><br />
//...<br />
#include <util/atomic.h><br />
//...<br />
<br />
// analog zu cli, Zugriff, sei:<br />
ATOMIC_BLOCK(ATOMIC_FORCEON) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
// oder:<br />
<br />
// analog zu Sicherung des SREG, cli, Zugriff und Zurückschreiben des SREG:<br />
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
//...<br />
</syntaxhighlight><br />
<br />
* siehe auch [http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Dokumentation der avr-libc zu atomic.h]<br />
<br />
== Interrupt-Routinen und Registerzugriffe ==<br />
<br />
Falls Register sowohl im Hauptprogramm als auch in Interrupt-Routinen verändert werden, ist darauf zu achten, dass diese Zugriffe sich nicht überlappen. Nur wenige Anweisungen lassen sich in sogenannte "atomare" Zugriffe übersetzen, die nicht von Interrupt-Routinen unterbrochen werden können. <br />
<br />
Zur Veranschaulichung eine Anweisung, bei der ein Bit und im Anschluss drei Bits in einem Register gesetzt werden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
int main(void)<br />
{<br />
//...<br />
PORTA |= (1<<PA0);<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Der Compiler übersetzt diese Anweisungen für einen ATmega128 bei Optimierungsstufe "S" nach:<br />
<br />
<div class="code"><pre><br />
...<br />
PORTA |= (1<<PA0);<br />
d2: d8 9a sbi 0x1b, 0 ; 27 (a)<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
d4: 8b b3 in r24, 0x1b ; 27 (b)<br />
d6: 8c 61 ori r24, 0x1C ; 28 (c)<br />
d8: 8b bb out 0x1b, r24 ; 27 (d)<br />
...<br />
</pre></div><br />
<br />
Das Setzen des einzelnen Bits wird bei eingeschalteter Optimierung für Register im unteren Speicherbereich in eine einzige Assembler-Anweisung (sbi) übersetzt und ist nicht anfällig für Unterbrechungen durch Interrupts. Die Anweisung zum Setzen von drei Bits wird jedoch in drei abhängige Assembler-Anweisungen übersetzt und bietet damit zwei "Angriffspunkte" für Unterbrechungen. Eine Interrupt-Routine könnte nach dem Laden des Ausgangszustands in den Zwischenspeicher (hier Register 24) den Wert des Registers ändern, z.&nbsp;B. ein Bit löschen. Damit würde der Zwischenspeicher nicht mehr mit dem tatsächlichen Zustand übereinstimmen aber dennoch nach der Bitoperation (hier ori) in das Register zurückgeschrieben. <br />
<br />
Beispiel: PORTA sei anfangs 0b00000000. Die erste Anweisung (a) setzt Bit 0 auf '''1''', PORTA ist danach 0b0000000'''1'''. Nun wird im ersten Teil der zweiten Anweisung der Portzustand in ein Register eingelesen (b). Unmittelbar darauf (vor (c)) "feuert" ein Interrupt, in dessen Interrupt-Routine Bit 0 von PORTA gelöscht wird. Nach Verlassen der Interrupt-Routine hat PORTA den Wert 0b00000000. In den beiden noch folgenden Anweisungen des Hauptprogramms wird nun der zwischengespeicherte "alte" Zustand 0b00000001 mit 0b00011100 logisch-'''ODER'''-verknüft (c) und das Ergebnis 0b00011101 in PortA geschrieben (d). Obwohl zwischenzeitlich Bit 0 gelöscht wurde, ist es nach (d) wieder gesetzt. <br />
<br />
Lösungsmöglichkeiten:<br />
* Register ohne besondere Vorkehrungen nicht in Interruptroutinen ''und'' im Hauptprogramm verändern.<br />
* Interrupts vor Veränderungen in Registern, die auch in ISRs verändert werden, deaktivieren ("cli").<br />
* Bits einzeln löschen oder setzen. sbi und cbi können nicht unterbrochen werden. Vorsicht: nur Register im unteren Speicherbereich sind mittels sbi/cbi ansprechbar. Der Compiler kann nur für diese sbi/cbi-Anweisungen generieren. Für Register außerhalb dieses Adressbereichs ("Memory-Mapped"-Register) werden auch zur Manipulation einzelner Bits abhängige Anweisungen erzeugt (lds,...,sts).<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Frequently asked Questions/Fragen Nr. 1 und 8. (Stand: avr-libc Vers. 1.0.4)<br />
<br />
== Interruptflags löschen ==<br />
<br />
Beim Löschen von Interruptflags haben AVRs eine Besonderheit, die auch im Datenblatt beschrieben ist: Es wird zum Löschen eine 1 in das betreffende Bit geschrieben. <br />
<br />
Hinweis:<br /><br />
Bei Registern mit mehreren Interrupt-Flag-Bits (wie die Timer Interrupt Flag Register) '''nicht''' die übliche bitweise VerODERung nehmen, sondern eine direkte Zuweisung machen. Da sonst weitere Flags, als nur das gewünschte, ebenfalls gelöscht werden könnten.<br /><br />
([http://www.mikrocontroller.net/topic/171148#1640133 Erklärung]).<br />
<br />
== Was macht das Hauptprogramm? ==<br />
<br />
Im einfachsten (Ausnahme-)Fall gar nichts mehr. Es ist also durchaus denkbar, ein Programm zu schreiben, welches in der main-Funktion lediglich noch die Interrupts aktiviert und dann in einer Endlosschleife verharrt. Sämtliche Funktionen werden dann in den ISRs abgearbeitet. Diese Vorgehensweise ist jedoch bei den <i>meisten</i> Anwendungen schlecht: man verschenkt eine Verarbeitungsebene und hat außerdem möglicherweise Probleme durch Interruptroutinen, die zu viel Verarbeitungszeit benötigen.<br />
<br />
Für <i>wenige</i> Anwendungen ist diese Vorgehensweise jedoch perfekt: Die Hauptschleife verkommt zu <tt>for(;;) sleep_cpu();</tt> — siehe nächster Abschnitt „Sleep“. Weiterer Vorteil: ISRs brauchen keine(!) Register retten, ein Fall für <tt>ISR(<i>name</i>,ISR_NAKED){ … reti();}</tt>. <i>So</i> können Mikrocontroller für batteriebetriebene Geräte, etwa Fernbedienungen, maximal Energie sparen.<br />
<br />
Normalerweise wird man in den Interruptroutinen nur die bei Auftreten des jeweiligen Interruptereignisses unbedingt notwendigen Operationen ausführen lassen. Alle weniger kritischen Aufgaben werden dann im Hauptprogramm abgearbeitet.<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Interrupts and Signals<br />
<br />
= Sleep-Modes =<br />
<br />
AVR Controller verfügen über eine Reihe von sogenannten [[Sleep Mode |''Sleep-Modes'']] ("Schlaf-Modi"). Diese ermöglichen es, Teile des Controllers abzuschalten. Zum Einen kann damit besonders bei Batteriebetrieb Strom gespart werden, zum Anderen können Komponenten des Controllers deaktiviert werden, die die Genauigkeit des Analog-Digital-Wandlers bzw. des Analog-Comparators negativ beeinflussen. Der Controller wird durch Interrupts aus dem Schlaf geweckt. Welche Interrupts den jeweiligen Schlafmodus beenden, ist einer Tabelle im Datenblatt des jeweiligen Controllers zu entnehmen.<br />
Die Funktionen (eigentlich Makros) der avr-libc stehen nach Einbinden der header-Datei ''sleep.h'' zur Verfügung.<br />
<br />
;set_sleep_mode (uint8_t mode): Setzt den Schlafmodus, der bei Aufruf von sleep() aktiviert wird. In sleep.h sind einige Konstanten definiert (z.&nbsp;B. SLEEP_MODE_PWR_DOWN). Die definierten Modi werden jedoch nicht alle von sämtlichten AVR-Controllern unterstützt.<br />
;sleep_enable(): Aktiviert den gesetzten Schlafmodus, versetzt den Controller aber noch nicht in den Schlafmodus<br />
;sleep_cpu(): Versetzt den Controller in den Schlafmodus .sleep_cpu wird im Prinzip durch die Assembler-Anweisung ''sleep'' ersetzt.<br />
;sleep_disable(): Deaktiviert den gesetzten Schlafmodus<br />
;sleep_mode(): Versetzt den Controller in den mit set_sleep_mode gewählten Schlafmodus. Das Makro entspricht sleep_enable()+sleep_cpu()+sleep_disable(), beinhaltet also nicht die Aktivierung von Interrupts (besser nicht benutzen).<br />
<br />
Bei Anwendung von sleep_cpu() müssen Interrupts also bereits freigeben sein (sei()), da der Controller sonst nicht mehr "aufwachen" kann. sleep_mode() ist nicht geeignet für die Verwendung in ISR Interrupt-Service-Routinen, da bei deren Abarbeitung Interrupts global deaktiviert sind und somit auch die möglichen "Aufwachinterrupts". Abhilfe: stattdessen sleep_enable(), sei(), sleep_cpu(), sleep_disable() und evtl. cli() verwenden (vgl. Dokumentation der avr-libc).<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/sleep.h><br />
<br />
int main(void)<br />
{<br />
...<br />
<br />
while (1) {<br />
...<br />
set_sleep_mode(SLEEP_MODE_PWR_DOWN);<br />
sleep_mode();<br />
<br />
// Code hier wird erst nach Auftreten eines entsprechenden<br />
// "Aufwach-Interrupts" verarbeitet<br />
...<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
In älteren Versionenen der avr-libc wurden nicht alle AVR-Controller durch die sleep-Funktionen richtig angesteuert. Mit avr-libc 1.2.0 wurde die Anzahl der unterstützten Typen jedoch deutlich erweitert. Bei nicht-unterstützten Typen erreicht man die gewünschte Funktionalität durch direkte "[[Bitmanipulation]]" der entsprechenden Register (vgl. Datenblatt) und Aufruf des Sleep-Befehls via Inline-Assembler oder sleep_cpu():<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
// Sleep-Mode "Power-Save" beim ATmega169 "manuell" aktivieren<br />
SMCR = (3<<SM0) | (1<<SE);<br />
asm volatile ("sleep"::); // alternativ sleep_cpu() aus sleep.h<br />
...<br />
</syntaxhighlight><br />
<br />
== Sleep-Modi ==<br />
Die vielen Prozessoren aus der AVR-Familie unterstützen unterschiedliche Sleep-Modi, gefächert nach Vorhandensein von Funktionsblöcken im Controller. Konkrete und verläßliche Auskunft über die tatsächlichen Gegebenheiten finden sich wie immer in den jeweiligen Datenblättern. Die Modi unterscheiden sich darin, welche Funktionsbereiche zum Energiesparen abgeschaltet werden. Davon hängt auch ab, mit welchen Mitteln der Prozessor aus der jeweiligen Schlaftiefe wieder aufgeweckt werden kann.<br />
<br />
;Idle Mode (SLEEP_MODE_IDLE): Die CPU kann durch SPI, USART, Analog Comperator, ADC, TWI, Timer, Watchdog und irgendeinen anderen Interrupt wieder aufgeweckt werden.<br />
<br />
;ADC Noise Reduction Mode (SLEEP_MODE_ADC): In diesem Modus liegt das Hauptaugenmerk darauf, die CPU soweit stillzulegen, dass der ADC möglichst keine Störungen aus dem inneren der CPU auffangen kann, die das Meßergebnis negativ beeinflussen können. Das Aufwachen aus diesem Modus kann ausgelöst werden durch den ADC, externe Interrupts, TWI, Timer und Watchdog.<br />
<br />
;Power-Down Mode (SLEEP_MODE_PWR_DOWN): In diesem Modus wird ein externer Oszillator (Quarz, Quarzoszillator), wenn vorhanden. gestoppt. Geweckt werden kann die CPU durch einen externen Level-Interrupt, TWI, Watchdog, Brown-Out-Reset.<br />
<br />
;Power-Save-Mode (SLEEP_MODE_PWR_SAVE): Power-Save ist identisch zu Power-Down mit einer Ausnahme: Ist der Timer 2 auf die Verwendung eines externen Taktes konfiguriert, so läuft dieser Timer auch im Power-Save weiter und kann die CPU mit einem Interrupt aufwecken.<br />
<br />
;Standby-Mode (SLEEP_MODE_STANDBY, SLEEP_MODE_EXT_STANDBY): Voraussetzung für den Standby-Modus ist die Verwendung eines Quarzes oder eines Quarzoszillators, also einer externen Taktquelle. Ansonsten ist dieser Modus identisch zum Power-Down Modus. Vorteil dieses Modus' ist eine kürzere Aufwachzeit.<br />
<br />
;Abschalten des Brownout Detect (BOD) während der Sleep-Phase (nur P-Typen): Zur Stromersparnis bieten die P-Typen die Möglichkeit den BOD während der Sleep-Phase abzuschalten. Bei einem Atmega88PA beispielsweise, kann dadurch der Stromverbrauch im SLEEP_MODE_PWR_SAVE mit Timer2 im Asynchronmodus mit Uhrenquarz und periodischer Selbstaufweckung um ca. 50% gesenkt werden.<br />
Das Einschalten dieser Funktion geschieht in einer Timed Sequence.<br />
<br />
<syntaxhighlight lang="c"><br />
unsigned char temp0 = MCUCR;<br />
unsigned char temp1 = MCUCR;<br />
temp0 |= (1 << BODS) | (1 << BODSE);<br />
temp1 |= (1 << BODS);<br />
MCUCR = temp0;<br />
MCUCR = temp1;<br />
sleep_cpu();<br />
</syntaxhighlight><br />
<br />
Hierbei ist unbedingt zu beachten, dass das BODS-Bit 3 Takte nach dem Setzen wieder gelöscht wird. Daher muss der Aufruf des Sleep unmittelbar nach dem Setzen erfolgen und das BODS-Bit muss jedes Mal vor einem Sleep Aufruf erneut gesetzt werden.<br />
<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Power Management and Sleep-Modes<br />
* [http://www.mikrocontroller.net/topic/96369#832712 Forenbeitrag] zur "Nichtverwendung" von sleep_mode in ISRs.<br />
<br />
= Zeiger =<br />
Zeiger (engl. ''Pointer'') sind Variablen, die die Adresse von Daten oder Funktionen enthalten und belegen 16 Bits. Die Größe hängt mit dem adressierbaren Speicherbereich zusammen und der GCC reserviert dann den entsprechenden Platz.<br />
Ggf. ist es also günstiger, Indizes auf Arrays (Listen) zu verwenden, so dass der GCC für die Zeigerarithmetik den erforderlichen RAM nur temporär benötigt.<br />
<br />
Siehe auch: [[Zeiger]]<br />
<br />
= Speicherzugriffe =<br />
<br />
Atmel AVR-Controller verfügen typisch über drei Speicher:<br />
<br />
* [[RAM]]: Im RAM (genauer statisches RAM/SRAM) wird vom gcc-Compiler Platz für Variablen reserviert. Auch der Stack befindet sich im RAM. Dieser Speicher ist "flüchtig", d.h. der Inhalt der Variablen geht beim Ausschalten oder einem Zusammenbruch der Spannungsversorgung verloren. Das bedeutet im Umkehrschluss auch, dass der RAM-Inhalt nach RESET vom Pin oder vom Watchdog erhalten bleibt! Der C-Startupcode löscht jedoch den RAM, d.h. setzt alle Bits auf 0. Dadurch erscheinen „normal definierte“ Variablen als 0. Auch Gleitkommazahlen, die schlauerweise so definiert sind, dass eine +0.0 aus lauter Nullbits besteht. Von der Löschung ausschließen kann man RAM-Variablen mit <tt>__attribute__((section(".noinit")))</tt>.<br />
<br />
* Programmspeicher: Ausgeführt als FLASH-Speicher, seitenweise wiederbeschreibbar. Darin ist das Anwendungsprogramm abgelegt.<br />
<br />
* [[EEPROM]]: Nichtflüchtiger Speicher, d.h. der einmal geschriebene Inhalt bleibt auch ohne Stromversorgung erhalten. Byte-weise schreib/lesbar. Im EEPROM werden typischerweise gerätespezifische Werte wie z.&nbsp;B. Kalibrierungswerte von Sensoren abgelegt.<br />
<br />
Einige AVRs besitzen keinen RAM-Speicher, lediglich die Register können als "Arbeitsvariablen"<br />
genutzt werden. Da die Anwendung des avr-gcc auf solch "kleinen" Controllern ohnehin selten sinnvoll ist und auch nur bei einigen RAM-losen Typen nach [http://lightner.net/avr/ATtinyAvrGcc.html "Bastelarbeiten"] möglich ist, werden diese Controller hier nicht weiter berücksichtigt. Auch EEPROM-Speicher ist nicht auf allen Typen verfügbar. Generell sollten die nachfolgenden Erläuterungen auf alle ATmega-Controller und die größeren AT90-Typen übertragbar sein. Für die Typen ATtiny2313, ATtiny26 und viele weitere der "ATtiny-Reihe" gelten die Ausführungen ebenfalls.<br />
<br />
Siehe auch:<br />
* [[Binäre Daten zum Programm hinzufügen]]<br />
== RAM ==<br />
<br />
Die Verwaltung des RAM-Speichers erfolgt durch den Compiler, im Regelfall ist beim Zugriff auf Variablen im RAM nichts Besonderes zu beachten. Die Erläuterungen in jedem brauchbaren C-Buch gelten auch für den vom avr-gcc-Compiler erzeugten Code.<br />
<br />
Um Speicher dynamisch (während der Laufzeit) zu reservieren, kann '''malloc()''' verwendet werden. malloc(size) "alloziert" (~reserviert) einen gewissen Speicherblock mit '''size''' Bytes. Ist kein Platz für den neuen Block, wird NULL (0) zurückgegeben.<br />
<br />
Wird der angelegte Block zu klein (groß), kann die Größe mit realloc() verändert werden. Den allozierten Speicherbereich kann man mit free() wieder freigeben. Wenn das Freigeben eines Blocks vergessen wird spricht man von einem "Speicherleck" (memory leak).<br />
<br />
malloc() legt Speicherblöcke im '''Heap''' an, belegt man zuviel Platz, dann wächst der Heap zu weit nach oben und überschreibt den Stack, und der Controller kommt in Teufels Küche. Das kann leider nicht nur passieren wenn man insgesamt zu viel Speicher anfordert, sondern auch wenn man Blöcke unterschiedlicher Größe in ungünstiger Reihenfolge alloziert/freigibt (siehe Artikel [[Heap-Fragmentierung]]). Aus diesem Grund sollte man malloc() auf Mikrocontrollern sehr sparsam (am besten gar nicht) verwenden.<br />
<br />
Beispiel zur Verwendung von malloc():<br />
<syntaxhighlight lang="c"><br />
#include <stdlib.h><br />
<br />
void foo(void) {<br />
// neuen speicherbereich anlegen,<br />
// platz für 10 uint16<br />
uint16_t* pBuffer = malloc(10 * sizeof(uint16_t));<br />
<br />
// darauf zugreifen, als wärs ein gewohnter Buffer<br />
pBuffer[2] = 5;<br />
<br />
// Speicher (unbedingt!) wieder freigeben<br />
free(pBuffer);<br />
}<br />
</syntaxhighlight><br />
<br />
Wenn (wie in obigem Beispiel) dynamischer Speicher nur für die Dauer einer Funktion benötigt und am Ende wieder freigegeben wird, bietet es sich an, statt malloc() '''alloca()''' zu verwenden. Der Unterschied zu malloc() ist, dass der Speicher auf dem Stack reserviert wird, und beim Verlassen der Funktion automatisch wieder freigegeben wird. Es kann somit kein Speicherleck und keine Fragmentierung entstehen.<br />
<br />
siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/malloc.html AVR Libc Home Page]: Memory Areas and Using malloc()<br />
* [https://www.mikrocontroller.net/topic/479027#5934443 Forumsbeitrag]: RAM Verbrauch auch von lokalen variablen ermitteln<br />
<br />
== Flash mit PROGMEM und pgm_read ==<br />
<br />
→ [http://nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html avr-libc: Doku zu avr/pgmspace.h]<br />
<br />
Ein Zugriff auf Konstanten im Programmspeicher ist mittels avr-gcc erst ab Version 4.7 "transparent" möglich. Um Daten aus dem Flash zu lesen, muss die AVR-Instruktion LPM (''Load from Program Memory'') erzeugt werden, bei Controllern mit mehr als 64kiB Flash auch ELPM.<br />
<br />
Dazu gibt es das AVR-spezifische GCC-Attribut <tt>progmem</tt>, mit dem eine Variablendeklaration im ''static storage''<ref>Variablen der Speicherklasse ''static storage'' haben eine unbegrenzte Lebensdauer. Beispiel für solche Variablen sind globale Variablen, aber auch static-Variablen innerhalb einer Funktion gehören dazu. Beispiele für Variablen, die nicht ''static storage'' sind: auto-Variablen ("normale" lokale Variablen), register-Variablen, durch malloc geschaffene Objekte, etc.</ref> markiert werden kann:<br />
<syntaxhighlight lang="c"><br />
const int value __attribute__((progmem)) = 1;<br />
</syntaxhighlight><br />
<br />
Effekt ist, dass die so markierte Variable nicht im RAM sondern im Flash angelegt wird. Wird durch "normalen" C-Code auf solch eine Variable zugegriffen, wird jedoch aus der gleichen Adresse aus dem RAM gelesen und nicht aus dem Flash! Das ist ein Fehler, den der Compiler aber nicht anzeigt!<br />
<br />
<syntaxhighlight lang="c"><br />
int test = value; // Fehler! PROGMEM Konstanten müssen mit den pgm_read-Funktionen gelesen werden!<br />
</syntaxhighlight><br />
<br />
Zum Lesen aus dem Flash stellt die avr-libc daher zahlreiche Makros zur Verfügung. Zudem wird das Makro <tt>PROGMEM</tt> definiert, das etwas Tipparbeit spart:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
const int value PROGMEM = 1;<br />
</syntaxhighlight><br />
<br />
<tt>progmem</tt> funktioniert im Wesentlichen wie ein Section-Attribut, das die Daten in der Section <tt>.progmem.data</tt> ablegt. Im Gegensatz zum Section-Attribut werden jedoch noch weitere Prüfungen unternommen, ab avr-gcc 4.6 etwa muss die entsprechende Variable <tt>const</tt> sein.<br />
<br />
=== Integer und float ===<br />
<br />
Zum Lesen von Skalaren stellt die avr-libc folgende Makros zu Verfügung, die jeweils ein Argument erhalten: Die 16-Bit Adresse des zu lesenden Wertes<ref>Damit ist der mögliche Speicherbereich für Flash-Konstanten auf 64kiB begrenzt. Einige pgmspace-Funktionen ermöglichen den Lesezugriff auf den gesamten Flash-Speicher, intern via Assembler-Anweisung ELPM. Die Initialisierungswerte des Speicherinhalts jenseits der 64kiB-Marke müssen dann jedoch auf anderem Weg angelegt werden, d.h. nicht per PROGMEM. Evtl. eigene Section und Linker-Optionen. Alt und nicht ganz korrekt: Die avr-libc pgmspace-Funktionen unterstützen nur die unteren 64kiB Flash bei Controllern mit mehr als 64kiB.</ref><br />
<br />
:{| {{Tabelle}}<br />
|+ Übersicht der <tt>pgm_read</tt> Funktionen aus<br/>dem Header <tt>avr/pgmspace.h</tt> der avr-libc<br />
|-<br />
! Gelesener Wert || <tt>pgm_read_xxx</tt> || Anzahl Bytes<br />
|-<br />
| <tt>uint8_t</tt> || <tt>pgm_read_byte</tt> || 1<br />
|-<br />
| <tt>uint16_t</tt> || <tt>pgm_read_word</tt> || 2<br />
|-<br />
| <tt>uint32_t</tt> || <tt>pgm_read_dword</tt> || 4<br />
|-<br />
| <tt>float</tt> || <tt>pgm_read_float</tt><ref>ab avr-libc 1.7.0</ref> || 4<br />
|}<br />
<br />
Soll ein Zeiger gelesen werden, so verwendet man <tt>pgm_read_word</tt> und castet das Ergebnis zum gewünschten Zeiger-Typ.<br />
<br />
;Beispiele:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
/* Byte */<br />
const uint8_t aByte PROGMEM = 123;<br />
<br />
/* int-Array */<br />
const int anArray[] PROGMEM = { 18, 3 ,70 };<br />
<br />
void foo (void)<br />
{<br />
/* Zeiger */<br />
static const uint8_t* const aPointer PROGMEM = &aByte;<br />
<br />
uint8_t a = pgm_read_byte (&aByte);<br />
int a2 = (int) pgm_read_word (&anArray[2]);<br />
const uint8_t* p = (const uint8_t*) pgm_read_word (&aPointer);<br />
}<br />
</syntaxhighlight><br />
<br />
=== Blöcke ===<br />
<br />
In den Flash-Funktionen der avr-libc sind keine der pgm_read_xxxx Nomenklatur folgenden Funktionen, die Speicherblöcke auslesen oder vergleichen. Die enstprechende Funktionen sind Varianten von <tt>memcpy</tt>, <tt>memcmp</tt> und heißt <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, usw. Für weitere Funktionen und deren Prototypen siehe die Dokumentation der avr-libc.<br />
<br />
=== Strings ===<br />
<br />
Strings sind in C nichts anderes als eine Abfolge von Zeichen und einem <tt>'\0'</tt> als Stringende. Der prinzipielle Weg ist daher identisch zum Lesen von Bytes, wobei auf die [[FAQ#Wie funktioniert String-Verarbeitung in C?|Besonderheiten von Strings]] wie 0-Terminierung geachtet werden muss.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
size_t my_string_length (const char *addr)<br />
{<br />
size_t length = 0;<br />
<br />
while (pgm_read_byte (addr++))<br />
{<br />
length++;<br />
}<br />
return length;<br />
}<br />
</syntaxhighlight><br />
<br />
Zur Unterstützung des Programmierers steht das Repertoire der str-Funktionen auch in jeweils eine Variante zur Verfügung, die mit dem Flash-Speicher arbeiten kann. Die Funktionsnamen tragen den Suffix <tt>_P</tt>. Darüber hinaus gibt es das Makro <tt>PSTR</tt>, das ein String-Literal im Flash-Speicher ablegt und die Adresse des Strings liefert:<br />
<br />
Die nachfolgende Funktion liefert 0 zurück, wenn string_im_ram gleich "Hallo Welt" ist. Mit strcmp (String Compare) können wir zwei Strings vergleichen. Der Rückgabewert kann hierbei folgende Werte haben:<br><br />
0 die Strings sind gleich<br />
>0 das erste ungleiche Zeichen in string_im_ram ist größer als in "Hallo Welt"<br />
<0 das erste ungleiche Zeichen in string_im_ram ist kleiner als in "Hallo Welt"<br />
<br><br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
int foo (const char *string_im_ram)<br />
{<br />
return strcmp_P (string_im_ram, PSTR ("Hallo Welt"));<br />
}<br />
</syntaxhighlight><br />
<br />
Zu beachten ist, dass <tt>PSTR</tt> nur innerhalb von Funktionen verwendet werden kann.<br />
<br />
; Array aus Strings:<br />
<br />
Arrays aus Strings im Flash-Speicher werden in zwei Schritten angelegt:<br />
<br />
# Zuerst die einzelnen Elemente des Arrays und<br />
# im Anschluss ein Array, in dem die Startaddressen der Strings abgelegt werden.<br />
<br />
Zum Auslesen wird zuerst die Adresse des gewünschten Elements aus dem Array im Flash-Speicher gelesen, die im Anschluss dazu genutzt wird, um auf das Element (den String) selbst zuzugreifen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
static const char str1[] PROGMEM = "Hund";<br />
static const char str2[] PROGMEM = "Katze";<br />
static const char str3[] PROGMEM = "Maus";<br />
<br />
const char * const array[] PROGMEM = <br />
{<br />
str1, str2, str3<br />
};<br />
<br />
// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]<br />
void read_string (char *buf, size_t i)<br />
{<br />
// Lese die Adresse des i-ten Strings aus array[]<br />
const char *parray = (const char*) pgm_read_ptr (&array[i]);<br />
<br />
// Kopiere den Inhalt der Zeichenkette vom Flash ins RAM<br />
strcpy_P (buf, parray);<br />
}<br />
</syntaxhighlight><br />
<br />
Eine weitere Möglichkeit ist, die Strings in einem 2-dimensionalen char-Array abzulegen anstatt deren Adresse in einem 1-dimensionalen Adress-Array zu speichern.<br />
<br />
Vorteil ist, dass der Code einfacher wird. Nachteil ist, dass bei unterschiedlich langen Strings Speicherplatz verschwendet wird, weil sich die Array-Dimension and der Länge des längsten Strings orientieret. Bei in etwa gleich langen Strings kann es aber sogar Speicherplatz sparen, denn es die Adressen der einzelnen Strings müssen nicht abgespeichert werden.<ref>In unserem Hund-Katze-Maus Beispiel belegt die erste Variante 22 Bytes Daten und 18 Bytes Code, die zweite Variante mit 2-dimensionalem Array belegt 18 Bytes Daten und 20 Bytes Code. Gemessen wurde mit avr-gcc 4.8 -Os für ATmega8.</ref><br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
// Die "6" ist 1 plus die Länge des längsten Strings ("Katze")<br />
const char array[][6] PROGMEM = <br />
{<br />
"Hund", "Katze", "Maus"<br />
};<br />
<br />
// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]<br />
void read_string (char *buf, size_t i)<br />
{<br />
// Kopiere den Inhalt der i-ten Zeichenkette vom Flash ins RAM<br />
strcpy_P (buf, array[i]);<br />
}<br />
</syntaxhighlight><br />
<br />
Siehe dazu auch die avr-libc FAQ: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_rom_array How do I put an array of strings completely in ROM?]<br />
<br />
=== Warum so kompliziert? ===<br />
<br />
Zu dem Thema, warum die Verabeitung von Werten aus dem Flash-Speicher so kompliziert ist, sei hier nur kurz erläutert: Die Harvard-Architektur des AVR weist getrennte Adressräume für Programm (Flash) und Datenspeicher (RAM) auf. Der C-Standard sieht keine unterschiedlichen Adressräume vor.<br />
<br />
Hat man zum Beispiel eine Funktion string_an_uart (const char* s) und übergibt an diese Funktion die Adresse einer Zeichenkette, dann weiß die Funktion nicht, ob die Adresse in den Flash-Speicher oder das RAM zeigt. Weder aus dem Pointer-Wert, also dem Zahlenwert, noch aus dem "const" kann auf den Ort der Ablage geschlossen werden.<br />
<br />
Einige AVR-Compiler bilden die Harvard-Architektur ab, indem sie in einen Pointer nicht nur die Adresse speichern, sondern auch den Ablageort wie ''Flash'' oder ''RAM''. In einem Aufruf einer Funktion wird dann bei Pointer-Parametern neben der Adresse auch der Speicherbereich, auf den der Pointer zeigt, übergeben.<br />
<br />
Dies hat jedoch auch Nachteile, denn bei jedem Zugriff über einen Zeiger muss zur ''Laufzeit'' entschieden werden, wie der Zugriff auszuführen ist und entsprechend länglicher und langsamer wird der erzeugte Code.<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitte Modules/Program Space String Utilities und Abschnitt Modules/Bootloader Support Utilities<br />
<br />
=== Datenzugriff >64kiB ===<br />
<br />
Die Zeiger beim avr-gcc sind nur 16 Bit breit, können somit also nur 64kiB Datenspeicher adressieren. Darauf sind auch alle Funktion der libc ausgelegt, welche auf _P enden. Als Funktionspointer können sie beim AVR bis zu 128 kiB Programmspeicher adressieren, weil Funktionsadressen immer 16-Bit Worte adressieren und nicht Bytes. Der Zugriff auf den RAM ist mit maximal 16kiB durch 16 Bit Poiinter nicht begrenzt. Um Zugriff jenseits von 64KiB zu bewerkstelligen gibt es mehrere Möglichkeiten:<br />
<br />
* Address-Spaces wie <tt>__flash1</tt> oder <tt>__memx</tt>, siehe Abschnitt "[[#Jenseits von flash|Jenseits von __flash]]".<br />
* Die Funktionen bzw. Makros <tt>pgm_read_xxx_far</tt> der AVR-Libc ab Version 1.8.0, wie im folgenden beschrieben. Dafür gibt es die Funktion pgm_get_far_address(), um 32-Bit Pointer eines Objekts zu erhalten<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/pgmspace.h><br />
<br />
//===================================================================<br />
// Define an additional section, which will be placed after all others<br />
//--------------------------------------------------------------------<br />
#define FAR_SECTION __attribute__((__section__(".far_section")))<br />
//--------------------------------------------------------------------<br />
<br />
//====================================================================<br />
// Just an example<br />
//====================================================================<br />
<br />
const char MyString[] FAR_SECTION = "Hier liegt mein FAR-Teststring!";<br />
const char MyBmp64[] FAR_SECTION = {0xAA,0xBB,0xCC,0xDD,0xEE,0xFF,0x00};<br />
<br />
int main(void) {<br />
uint32_t ptr = pgm_get_far_address(MyString);<br />
char MyChar;<br />
DDRC = 0xFF;<br />
do {<br />
MyChar = pgm_read_byte_far(ptr++);<br />
PORTC = MyChar;<br />
} while(MyChar);<br />
}<br />
</syntaxhighlight><br />
<br />
D.h. man muss<br />
* Die Definition der neuen Section <tt>FAR_SECTION</tt> einfügen<br />
* Die konstanten Daten mit dieser Section kennzeichnen<br />
<br />
Dem Linker muss man über diese Section nichts mitteilen, er fügt diese automatisch nach allen bestehenden sections im Flash ein. Der Zugriff auf diese Variablen kann nur mittels direkter Pointerarithmetik erfolgen, eine Indizierung von Arrays mit variablem Index ist nicht möglich. Dabei muss die Größe des Datentyps immer manuell berücksichtigt werden, denn der Pointer ist immer ein Bytepointer!<br />
<br />
<syntaxhighlight lang="c"><br />
int n=3;<br />
MyChar = pgm_read_byte_far(pgm_get_far_address(MyBmp64)+n*sizeof(char));<br />
</syntaxhighlight><br />
<br />
Dabei gibt es einige praktische Probleme.<br />
* Beim recht alten AVR-Studio 4.18 wird die Größe des belegten FLASH-Speichers nicht korrekt angezeigt, die Daten landen aber im HEX-File.<br />
* beim moderneren Atmelstudio 6.2 sieht man in der Consolenausgabe die richtige Größe, welche von avr-size ermittelt wurde, diese wird aber dann in der 2. Ausgabe durch Atmelstudio falsch dargestellt<br />
* Die Arduino-IDE rechnet richtig, siehe dieser [https://www.mikrocontroller.net/topic/511511?goto=6568945#6568945 Forumsbeitrag].<br />
<br />
== Flash mit __flash und Embedded-C ==<br />
<br />
Ab Version 4.7 unterstützt avr-gcc ''Adress-Spaces'' gemäß dem Embedded-C Dokument ISO/IEC TR18037. Der geläufigste Adress-Space ist <tt>__flash</tt>, der im Gegensatz zu <tt>progmem</tt> kein GCC-Attribut ist, sondern ein Qualifier und damit syntaktisch ähnlich verwendet wird wie <tt>const</tt> oder <tt>volatile</tt>.<br />
<br />
GCC kennt keine eigene Option zum Aktivieren von Embedded-C, es wird als GNU-C Erweiterung behandelt. Daher müssen C-Module, die Address-Spaces verwenden, mit <tt>-std=gnu99</tt> o.ä. compiliert werden.<br />
<br />
<syntaxhighlight lang="c"><br />
static const __flash int value = 10;<br />
<br />
int get_value (void)<br />
{<br />
return value;<br />
}<br />
</syntaxhighlight><br />
<br />
# Im Gegensatz zu <tt>progmem</tt> sind keine speziellen Bibliotheksfunktionen oder -makros für den Zugriff mehr notwendig: Der Code zum Lesen der Variable ist "normales" C.<br />
# Die Variable wird im richtigen Speicherbereich (Flash) angelegt.<br />
# <tt>__flash</tt> ist nur zusammen mit read-only Objekten oder Zeigern, d.h. nur zusammen mit <tt>const</tt>, erlaubt.<br />
# Zugriffe wie im obigen Beispiel können (weg)optimiert werden. Das Beispiel entspricht einem "<tt>return 10</tt>". Es besteht keine Notwendigkeit, für <tt>value</tt> überhaupt Flash-Speicher zu reservieren.<br />
<br />
Auch Zeiger-Indirektionen sind problemlos möglich. Zu beachten ist, dass <tt>__flash</tt> auf der richtigen Seite des "<tt>*</tt>" in der Zeigerdeklaration bzw. -definition steht:<br />
* '''Rechts vom <tt>*</tt>:''' Der Zeiger selbst liegt im Flash<br />
* '''Links vom <tt>*</tt>:''' Der Zeiger enthält eine Flash-Adresse<br />
<br />
<syntaxhighlight lang="c"><br />
// val ist eine Variable im Flash<br />
const __flash int val = 42;<br />
<br />
// pval liegt auch im Flash und enthält die Adresse von val<br />
const __flash int* const __flash pval = &val;<br />
<br />
int get_val (void)<br />
{<br />
// liest den Wert von val über die in pval abgelegte Adresse<br />
return *pval;<br />
}<br />
</syntaxhighlight><br />
<br />
=== Blöcke ===<br />
<br />
Um Speicherbereiche vom Flash in den RAM zu kopieren, gibt es zwei Möglichkeiten: Zum einen können wie bei <tt>progmem</tt> beschreiben die Funktionen der avr-libc wie <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, <tt>movmem_P</tt>, etc. verwendet werden:<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
// Eine Datenstruktur<br />
typedef struct<br />
{<br />
int id;<br />
char buf[10];<br />
} data_t;<br />
<br />
extern void uart_send (const void*, size_t);<br />
<br />
void send_data (const __flash data_t *pdata)<br />
{<br />
// buf wird auf dem Stack angelegt<br />
data_t buf;<br />
<br />
// Kopiere Daten vom Flash nach buf ins RAM<br />
memcpy_P (&buf, pdata, sizeof (data_t));<br />
<br />
// Sende die Daten in buf<br />
uart_send (&buf, sizeof (data_t));<br />
}<br />
</syntaxhighlight><br />
<br />
Zum anderen kann eine Struktur auch über direktes Kopieren ins RAM geladen werden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdlib.h><br />
<br />
// Eine Datenstruktur<br />
typedef struct<br />
{<br />
int id;<br />
char buf[10];<br />
} data_t;<br />
<br />
extern void uart_send (const void*, size_t);<br />
<br />
void send_data (const __flash data_t *pdata)<br />
{<br />
// Kopiere Daten ins RAM. buf wird auf dem Stack angelegt<br />
const data_t buf = *pdata;<br />
<br />
// Verwendet die Daten in buf<br />
uart_send (&buf, sizeof (data_t));<br />
}<br />
</syntaxhighlight><br />
<br />
=== Strings ===<br />
<br />
Natürlich können auch Strings im Flash abgelegt werden und auch mit Funktionen wie <tt>strcpy_P</tt> aus der avr-libc verarbeitet werden. Zudem ist es möglich, Flash-Zeiger mit der Adresse eines String-Literals zu initialisieren:<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
#define FSTR(X) ((const __flash char[]) { X } )<br />
<br />
const __flash char * const __flash array[] = <br />
{<br />
FSTR ("Hund"), FSTR ("Katze"), FSTR ("Maus")<br />
};<br />
<br />
size_t get_len (uint8_t tier)<br />
{<br />
return strlen_P (array[tier]);<br />
}<br />
</syntaxhighlight><br />
<br />
Leider sieht der Embedded-C Draft nicht vor, String-Literale direkt in einem anderen Adress-Space als ''generic'' anzulegen, so dass hier der Umweg über <tt>FSTR</tt> genommen werden muss. Dieses Konstrukt ist nur ausserhalb von Funktionen möglich und kann daher nicht als Ersatz für <tt>PSTR</tt> aus der avr-libc dienen.<br />
<br />
Soll <tt>array</tt> ein 2-dimensonales Array sein anstatt ein 1-dimensionales Array von Zeigern, dann geht das ohne große Verrenkungen:<br />
<br />
<syntaxhighlight lang="c"><br />
// Die 6 ergibt sich aus 1 plus der Länge des längsten Strings "Katze"<br />
const __flash char array[][6] = <br />
{<br />
"Hund", "Katze", "Maus"<br />
};<br />
</syntaxhighlight><br />
<br />
Weiters besteht die Möglichkeit, <tt>array</tt> analog anzulegen, wie man es mit <tt>PROGMEM</tt> machen würde: Jeder String wird explizit angelegt und seine Adresse bei der Initialisierung von <tt>array</tt> verwendet. Dies entspricht dem ersten Beispiel eines 1-dimensionalen Zeigerarrays:<br />
<br />
<syntaxhighlight lang="c"><br />
static const __flash char strHund[] = "Hund";<br />
static const __flash char strKatze[] = "Katze";<br />
static const __flash char strMaus[] = "Maus";<br />
<br />
const __flash char * const __flash array[] = <br />
{<br />
strHund, strKatze, strMaus<br />
};<br />
</syntaxhighlight><br />
<br />
=== Casts ===<br />
<br />
Embedded C fordert, dass zwei Adress-Spaces entweder disjunkt sind – d.h. sie enthalten keine gemeinsamen Adressen – oder aber ein Space komplett im anderen enthalten ist, also eine Teilmengen-Beziehung besteht. Die Adress-Spaces von avr-gcc sind so implementiert, dass jeder Space Teilmenge jedes anderes ist. Zwar haben Spaces wie RAM und Flash physikalisch keinen Speicherbereich gemein, allerdings ermöglicht diese Implementierung das Casten von Zeigern zu unterschiedlichen Adress-Spaces<ref>Im Gegensatz zu einem Attribute wie <tt>progmem</tt> ist ein (Adress Space) Qualifier Teil des Zeiger-Typs.</ref>: <br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdbool.h><br />
<br />
char read_char (const char *address, bool data_in_flash)<br />
{<br />
if (data_in_flash)<br />
return *(const __flash char*) address;<br />
else<br />
return *address;<br />
}<br />
</syntaxhighlight><br />
<br />
Der Cast selbst erzeugt keinen zusätzlichen Code, da eine RAM-Adresse und eine Flash-Adresse die gleiche Binärdarstellung haben. Allerdings wird über den nach <tt>__flash</tt> gecasteten Zeiger anders zugegriffen, nämlich per LPM.<br />
<br />
=== Jenseits von __flash ===<br />
<br />
Ausser <tt>__flash</tt> gibt es auch folgende Address-Spaces:<br />
<br />
==== <tt>__flash</tt>''N'' ====<br />
<br />
<tt>__flash</tt>''N'' mit ''N'' = 1..5 sind fünf weitere Spaces, die analog zu <tt>__flash</tt> funktionieren und deren Zeiger ebenfalls 16 Bit breit sind. avr-gcc erwartet, dass die zugehörigen Daten, welche in die Section <tt>.progmem</tt>''N''<tt>.data</tt> abgelegt werden, so lokatiert sind, dass das high-Byte der Adresse (Bits 16..23) gerade ''N'' ist.<br />
<br />
Weil Daten- und Code-Layout höchst projektspezifisch sind, werden diese Sections im Standard Linker-Skript nicht beschrieben. Um funktionsfähigen Code zu erhalten, muss daher ein eigenes Linker-Skript zur Verfügung gestellt werden, das diese Sections beschreibt, oder es kann eine Erweiterung des Standard Skripts bereitgestellt werden falls dies möglich ist.<br />
<br />
;Beispiel: Eine Applikation, die <tt>__flash2</tt> verwendet. Die zugehörende Section <tt>.progmem2.data</tt> wird hinter <tt>.text</tt> angeordnet aber vor den Initializern für <tt>.data</tt>. Dazu wird beim Linken das ld-Skript Fragment per <tt>-Tflash12.ld</tt> angegeben, welches dann an der gewünschten Stelle in das default Skript eingefügt wird:<br />
:{| <!-- Tabelle bitte für korrekte Einrückung belassen --><br />
|-<br />
|<pre><br />
SECTIONS<br />
{<br />
.flash2 :<br />
{<br />
. = MAX (ABSOLUTE(0x20000), .);<br />
PROVIDE (__flash2_start = .);<br />
. = ALIGN(2);<br />
*(.flash2.text*)<br />
*(.progmem2.data*)<br />
PROVIDE (__flash2_end = .);<br />
<br />
ASSERT (__flash2_start == __flash2_end || __flash2_start >= ABSOLUTE(0x20000),<br />
"__flash2 data in .progmem2.data below 0x20000");<br />
ASSERT (__flash2_start == __flash2_end || __flash2_end <= ABSOLUTE(0x30000),<br />
"__flash2 data in .progmem2.data exceeds 0x30000");<br />
}<br />
}<br />
INSERT AFTER .text<br />
</pre><br />
|}<br />
<br />
==== <tt>__memx</tt> ====<br />
<br />
Dieser Address-Space implementiert 3-Byte Zeiger und unterstützt Lesen über 64KiB-Segmentgrenzen hinweg. Das MSB (Bit 23) gibt dabei an, ob der <tt>__memx</tt>-Zeiger eine Flash-Adresse enthält (Bit23 = 0) oder eine RAM-Adresse (Bit23 = 1), was folgenden Code erlaubt:<br />
<br />
<syntaxhighlight lang="c"><br />
const __memx int a_flash = 42;<br />
const int a_ram = 100;<br />
<br />
int get_a (const __memx int* pa)<br />
{<br />
return *pa;<br />
}<br />
<br />
int main (void)<br />
{<br />
return get_a (&a_flash) + get_a (&a_ram);<br />
}</syntaxhighlight><br />
<br />
Dies bedeutet, dass erst zur ''Laufzeit'' entschieden werden kann, ob <tt>get_a</tt> die Daten aus dem RAM oder aus dem Flash lesen soll, was <tt>__memx</tt> im Vergleich zu den anderen Address-Spaces langsamer macht. Ausserdem ist zu beachten, dass <tt>__memx</tt>-Zeiger zwar 24-Bit Zeiger sind, die zugrundeliegende Adress-Arithmetik jedoch gemäß dem C-Standard erfolgt, also als 16-Bit Arithmetik. Bestehende Funktion der avr-libc wie z.B. printf_P funktionieren damit ebensowenig wie printf! Wenn man <tt>__memx</tt> verwenden will, braucht man dafür eigene Funktionen.<br />
<br />
=== __flash, progmem und Portierbarkeit ===<br />
<br />
Da ab er aktuellen Compilerversion 4.7 sowohl <tt>__flash</tt> als auch <tt>PROGMEM</tt> und die <tt>pgm_read</tt>-Funktionen zur Verfügung stehen, ergibt sich die Frage, welche Variante "besser" ist und wie zwischen ihnen hin- und her zu portieren ist.<br />
<br />
Zunächst sei erwähnt, dass <tt>__flash</tt> kein Ersatz für <tt>PROGMEM</tt> ist, sondern lediglich eine Alternative dazu. Das "alte" progmem wird weiterhin mir gleicher Semantik unterstützt, so dass alter Code ohne Änderungen mit den neueren Compilerversionen übersetzbar bleibt.<br />
<br />
Von der Codegüte her dürften sich keine großen Unterschiede ergeben. Es ist nicht zu erwarten, dass die eine oder die andere Variante wesentlich besseren oder schlechteren Code erzeugt — von einer Ausnahme abgesehen: Der Wert beim Zugriff ist zur Compilezeit bekannt und kann daher eliminiert werden.<br />
<syntaxhighlight lang="c"><br />
static const __flash char x[] = { 'A', 'V', 'R' };<br />
<br />
char foo (void)<br />
{<br />
return x[2];<br />
}<br />
</syntaxhighlight><br />
Dies wird übersetzt wie "<tt>return 'R';</tt>", und das Array <tt>x[]</tt> kann komplett wegoptimiert werden und entfallen.<br />
<br />
==== progmem → __flash ====<br />
<br />
Portierung in diese Richtung bedeutet, alten Code anzupassen. Zwingend ist die Portierung nicht, da <tt>progmem</tt> weiterhin unterstützt wird.<br />
Allerdings ist eine Quelle mit <tt>__flash</tt> besser lesbar, denn der Code wird von den <tt>pgm_read</tt>-Funktionen befreit, die vor allem bei Mehrfach-Indirektion den Code ziemlich verunstalten und unleserlich machen können.<br />
Weiterer Vorteil von <tt>_flash</tt> ist, daß eine striktere Typprüfung erfolgen kann.<br />
<br />
Eine Portierung wird man in zwei Schritten vornehmen:<br />
<br />
;1. Definitionen von Flash-Variablen werden angepasst:<br />
<br />
Vorher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
static const char hund[] PROGMEM = "Hund";<br />
static const char katze[] PROGMEM = "Katze";<br />
static const char maus[] PROGMEM = "Maus";<br />
<br />
const char * const tier[] PROGMEM = <br />
{<br />
hund, katze, maus<br />
};<br />
</syntaxhighlight><br />
|}<br />
<br />
Nachher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
static const __flash char hund[] = "Hund";<br />
static const __flash char katze[] = "Katze";<br />
static const __flash char maus[] = "Maus";<br />
<br />
const __flash char * const __flash tier[] = <br />
{<br />
hund, katze, maus<br />
};<br />
</syntaxhighlight><br />
|}<br />
<br />
Der Header <tt>avr/pgmspace.h</tt> wird nicht mehr benötigt. Im Gegensatz zu <tt>progmem</tt> müssen Qualifier immer links von der definierten Variablen stehen; bei Attributen wie <tt>progmem</tt> ist das mehr oder weniger egal.<br />
<br />
Nachdem diese Anpassung erfolgreich abgeschlossen ist, folgt Schritt<br />
<br />
; 2. Der Code wird von <tt>pgm_read</tt>-Aufrufen bereinigt:<br />
<br />
Vorher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
extern const char *tier[];<br />
<br />
char first_letter (uint8_t i)<br />
{<br />
const char* ptier = (const char*) pgm_read_word (&tier[i]);<br />
return (char) pgm_read_byte (&ptier[0]);<br />
}<br />
</syntaxhighlight><br />
|}<br />
<br />
Nachher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <stdint.h><br />
<br />
extern const __flash char * const __flash tier[];<br />
<br />
char first_letter (uint8_t i)<br />
{<br />
return tier[i][0];<br />
}<br />
</syntaxhighlight><br />
|}<br />
<br />
== Dateien direkt im Flash einbinden ==<br />
<br />
Wenn man größere Dateien direkt im Programm einbinden will, ohne sie vorher in C Quelltext umzuwandeln, muss man das mit dem Linker machen. Wie das geht steht hier.<br />
<br />
* [http://www.atmel.com/webdoc/avrlibcreferencemanual/FAQ_1faq_binarydata.html Atmel, avr gcc Dokumentation]<br />
* [http://nongnu.org/avr-libc/user-manual/FAQ.html#faq_binarydata Nongnu avr gcc Dokumentation]<br />
<br />
Wie man das dann praktisch umsetzt, sieht man in diesem Beitrag.<br />
<br />
* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056910 Forumsbeitrag]: Binärdateien mittels Linker einbinden<br />
* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056947 Forumsbeitrag]: Ein kleines Tool zum Umwandeln von Binärdateien in C-Quelltext.<br />
<br />
== Flash in der Anwendung schreiben ==<br />
<br />
Bei AVRs mit "self-programming"-Option – auch bekannt als [[Bootloader]]-Support – können Teile des Flash-Speichers vom Anwendungsprogramm beschrieben werden. Dies ist nur möglich, wenn die Schreibfunktion in einem besonderen Speicherbereich, der Boot-Section des Programmspeichers/Flash, abgelegt ist.<br />
<br />
Bei einigen kleinen AVRs gibt es keine gesonderte Boot-Section, bei diesen kann der Flashspeicher von jeder Stelle des Programms geschrieben werden. Für Details sei hier auf das jeweilige Controller-Datenblatt und die Erläuterungen zum Modul boot.h der avr-libc verwiesen. Es existieren auch Application-Notes dazu bei atmel.com, die auf avr-gcc-Code übertragbar sind.<br />
<br />
Siehe auch: <br />
* Forumsbeitrag [http://www.mikrocontroller.net/topic/163632#1561622 Daten in Programmspeicher speichern]<br />
<br />
== EEPROM ==<br />
<br />
Möchte man Werte aus einem Programm heraus so speichern, dass sie auch nach dem Abschalten der Versorgungsspannung noch erhalten bleiben und nach dem Wiederherstellen der Versorgungsspannung bei erneutem Programmstart wieder zur Verfügung stehen, dann benutzt man das EEPROM.<br />
<br />
Schreib- und Lesezugriffe auf den EEPROM-Speicher erfolgen über die im Modul eeprom.h der avr-libc definierten Funktionen. Mit diesen Funktionen können einzelne Bytes, Datenworte (16 Bit), Fließkommawerte (32 Bit, single-precision, float) und Datenblöcke geschrieben und gelesen werden.<br />
<br />
Diese Funktionen kümmern sich auch um diverse Details, die bei der Benutzung des EEPROMs normalerweise notwendig sind:<br />
* EEPROM-Operationen sind im Vergleich relativ langsam. Man muss daher darauf achten, dass eine vorhergehende Operation abgeschlossen ist, ehe die nächste Operation mit dem EEPROM gestartet wird. Die in der avr-libc implementierten Funktionen aus eeprom.h berücksichtigten dies. Soll beim Aufruf einer EEPROM-Funktion sichergestellt werden, dass diese nicht intern in einer Warteschleife auf den Abschluss der vorherigen Operation wartet, kann vorher per eeprom_is_ready testen, ob der Zugriff auf den EEPROM-Speicher sofort möglich ist.<br />
* Es ist darauf zu achten, dass die EEPROM-Funktionen nicht durch einen Interrupt unterbrochen werden. Einige Phasen des Zugriffs sind zeitkritisch und müssen in einer definierten bzw. begrenzten Anzahl von Takten durchgeführt werden. Durch einen unterbrechenden Interrupt würde diese Restriktion nicht mehr eingehalten. Auch dieses Detail wird von den avr-libc Funktionen berücksichtigt, so dass man sich als C-Programmierer nicht darum kümmern muss. Innerhalb der Funktionen werden Interrupts vor der "EEPROM-Sequenz" global deaktiviert und im Anschluss, falls vorher auch schon eingeschaltet, wieder aktiviert.<br />
<br />
Man beachte, dass der EEPROM-Speicher nur eine begrenzte Anzahl von Schreibzugriffen zulässt. Beschreibt man eine EEPROM-Zelle öfter als die im Datenblatt zugesicherte Anzahl (typisch 100.000), wird die Funktion der Zelle nicht mehr garantiert. Dies gilt für jede einzelne Zelle. <br />
<br />
Bei geschickter Programmierung (z.&nbsp;B. Ring-Puffer), bei der die zu beschreibenden Zellen regelmäßig gewechselt werden, kann man eine deutlich höhere Anzahl an Schreibzugriffen, bezogen auf den gesamten EEPROM-Speicher, erreichen. Auf jeden Fall sollte man aber eine Abschätzung über die zu erwartende Lebensdauer des EEPROM durchführen. Wird ein Wert im EEPROM im Durchschnitt nur einmal pro Woche verändert, wird die garantierte Anzahl der Schreibzyklen innerhalb der voraussichtlichen Verwendungszeit des Controllers sicherlich nicht erreicht werden. Welcher Controller ist schon 100000 / 52 = 1923 Jahre im Einsatz? In diesem Fall lohnt es sich daher nicht, erweiterte Programmfunktionen zu implementieren, mit denen die Anzahl der Schreibzugriffe minimiert wird.<br />
<br />
Eine weitere Möglichkeit, Schreibzyklen einzusparen, besteht in der Vorabprüfung, ob der zu speichernde Wert im EEPROM bereits enthalten ist und nur veränderte Werte zu schreiben. In aktuelleren Versionen der avr-libc sind bereits Funktionen enthalten, die solche Prüfungen enthalten (eeprom_update_*).<br />
<br />
Eine dritte Möglichkeit speichert alle Daten zunächst im RAM, wo sie beliebig oft beschrieben werden können. Nur beim Ausschalten oder beim Ausfall der Stromversorgung werden die Daten in den EEPROM geschrieben. Wie man das richtig macht sieht man im Artikel [[Speicher#EEPROM Schreibzugriffe minimieren | Speicher]].<br />
<br />
Lesezugriffe können beliebig oft durchgeführt werden. Sie unterliegen keinen Einschränkungen in Bezug auf deren Anzahl. <br />
<br />
=== EEMEM ===<br />
Um eine Variable im EEPROM anzulegen, stellt die avr-libc das Makro EEMEM zur Verfügung:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdint.h><br />
#include <avr/eeprom.h><br />
<br />
/* Byte */<br />
uint8_t eeFooByte EEMEM = 123;<br />
<br />
/* Wort */<br />
uint16_t eeFooWord EEMEM = 12345;<br />
<br />
/* float */<br />
float eeFooFloat EEMEM;<br />
<br />
/* Byte-Array */<br />
uint8_t eeFooByteArray1[] EEMEM = { 18, 3, 70 };<br />
uint8_t eeFooByteArray2[] EEMEM = { 30, 7, 79 };<br />
<br />
/* 16-bit unsigned short feld */<br />
uint16_t eeFooWordArray1[4] EEMEM;<br />
</syntaxhighlight><br />
<br />
Die grundsätzliche Vorgehensweise ist identisch zur Verwendung von PROGMEM. Auch hier erzeugt man sich spezielle attributierte Variablen (EEMEM erledigt das), die vom Compiler/Linker nicht wie normale Variablen behandelt werden. Compiler/Linker kümmern sich zwar darum, dass diesen Variablen eine Adresse zugewiesen wird, diese Adresse ist dann aber die Adresse der 'Variablen' im EEPROM. Um die dort gespeicherten Werte zu lesen bzw. zu schreiben, übergibt man diese Adresse an spezielle Funktionen, die die entsprechenden Werte aus dem EEPROM holen bzw. das EEPROM neu beschreiben.<br />
<br />
Die mittels EEMEM erzeugten 'Variablen' sind also mehr als Platzhalter zu verstehen, denn als echte Variablen. Es geht nur darum, im C-Programm symbolische Namen zur Verfügung zu haben, anstatt mit echten EEPROM-Adressen hantieren zu müssen, etwas, das grundsätzlich aber auch genauso gut möglich ist. Nur muss man sich in diesem Fall dann selbst darum kümmern, dass mehrere 'Variablen' ohne Überschneidung im EEPROM angeordnet werden.<br />
<br />
=== Bytes lesen/schreiben ===<br />
<br />
Die avr-libc Funktion zum Lesen eines Bytes heißt eeprom_read_byte. Parameter ist die Adresse des Bytes im EEPROM. Geschrieben wird über die Funktion eeprom_write_byte mit den Parametern Adresse und Inhalt. Anwendungsbeispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#define EEPROM_DEF 0xFF<br />
<br />
void eeprom_example (void)<br />
{<br />
uint8_t myByte;<br />
<br />
// myByte lesen (Wert = 123)<br />
myByte = eeprom_read_byte (&eeFooByte);<br />
<br />
// der Wert 99 wird im EEPROM an die Adresse der<br />
// Variablen eeFooByte geschrieben<br />
myByte = 99;<br />
eeprom_write_byte(&eeFooByte, myByte); // schreiben<br />
<br />
myByte = eeprom_read_byte (&eeFooByteArray1[1]); <br />
// myByte hat nun den Wert 3<br />
<br />
// Beispiel fuer eeprom_update_byte: die EEPROM-Zelle wird nur<br />
// dann beschrieben, wenn deren Inhalt sich vom Parameterwert<br />
// unterscheidet. In diesem Beispiel erfolgt also kein Schreib-<br />
// zugriff, da die Werte gleich sind.<br />
eeprom_update_byte(&eeFooByte, myByte);<br />
<br />
<br />
// Beispiel zur "Sicherung" gegen leeres EEPROM nach "Chip Erase"<br />
// (z. B. wenn die .eep-Datei nach Programmierung einer neuen Version<br />
// des Programms nicht in den EEPROM uebertragen wurde und EESAVE<br />
// deaktiviert ist (unprogrammed/1)<br />
// <br />
// Vorsicht: wenn EESAVE "programmed" ist, hilft diese Sicherung nicht<br />
// weiter, da die Speicheraddressen in einem neuen/erweiterten Programm<br />
// moeglicherweise verschoben wurden. An der Stelle &eeFooByte steht<br />
// dann u.U. der Wert einer anderen Variable aus einer "alten" Version.<br />
<br />
uint8_t fooByteDefault = 222;<br />
if ((myByte = eeprom_read_byte (&eeFooByte)) == EEPROM_DEF)<br />
{<br />
myByte = fooByteDefault;<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
=== Wort lesen/schreiben ===<br />
<br />
Schreiben und Lesen von Datenworten erfolgt analog zur Vorgehensweise bei Bytes:<br />
<br />
<syntaxhighlight lang="c"><br />
// lesen<br />
uint16_t myWord = eeprom_read_word (&eeFooWord);<br />
<br />
// schreiben<br />
eeprom_write_word (&eeFooWord, 2222);<br />
</syntaxhighlight><br />
<br />
=== Block lesen/schreiben ===<br />
<br />
Lesen und Schreiben von Datenblöcken erfolgt über die Funktionen <code>eeprom_read_block()</code> bzw. <code>eeprom_write_block()</code>. Die Funktionen erwarten drei Parameter: die Adresse der Quell- bzw. Zieldaten im RAM, die EEPROM-Adresse und die Länge des Datenblocks in Bytes als <code>size_t</code>.<br />
<syntaxhighlight lang="c"><br />
uint8_t myByteBuffer[3];<br />
uint16_t myWordBuffer[4];<br />
<br />
void eeprom_block_example (void)<br />
{<br />
/* Datenblock aus EEPROM lesen */<br />
<br />
/* liest 3 Bytes ab der von eeFooByteArray1 definierten EEPROM-Adresse<br />
in das RAM-Array myByteBuffer */<br />
eeprom_read_block (myByteBuffer, eeFooByteArray1, 3);<br />
<br />
/* dito mit etwas Absicherung betr. der Länge */<br />
eeprom_read_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));<br />
<br />
/* und nun mit 16-Bit Array */<br />
eeprom_read_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));<br />
<br />
/* Datenblock in EEPROM schreiben */<br />
eeprom_write_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));<br />
eeprom_write_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));<br />
}<br />
</syntaxhighlight><br />
<br />
=== Fließkommawerte lesen/schreiben ===<br />
<br />
In der avr-libc stehen auch EEPROM-Funktionen für Variablen des Typs float (Fließkommazahlen mit "einfacher" Genauigkeit) zur Verfügung.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/eeprom.h><br />
<br />
float eeFloat EEMEM = 12.34f;<br />
<br />
float void eeprom_float_example(float value)<br />
{<br />
/* float in EEPROM schreiben */<br />
eeprom_write_float(&eeFloat, value);<br />
<br />
/* float aus EEPROM lesen */<br />
return eeprom_read_float(&eeFloat);<br />
}</syntaxhighlight><br />
<br />
=== EEPROM-Speicherabbild in .eep-Datei ===<br />
<br />
Mit den zum Compiler gehörenden Werkzeugen kann der aus den Variablendeklarationen abgeleitete EEPROM-Inhalt in eine Datei geschrieben werden. Die übliche Dateiendung ist .eep, Daten im Intel Hex-Format. Damit können Standardwerte für den EEPROM-Inhalt im Quellcode definiert werden. <br />
<br />
Makefiles nach WinAVR/MFile-Vorlage enthalten bereits die notwendigen Einstellungen, siehe dazu die Erläuterungen im [[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]].<br />
<br />
Der Inhalt der eep-Datei muss ebenfalls zum Mikrocontroller übertragen werden, wenn die Initialisierungswerte aus der Deklaration vom Programm erwartet werden. Ansonsten enthält der EEPROM-Speicher nach der Übertragung des Programmers mittels ISP abhängig von der Einstellung der EESAVE-Fuse<ref>vgl. Datenblatt Abschnitt Fuse Bits</ref> nicht die korrekten Werte:<br />
; EESAVE = 0 (programmed): Die Daten im EEPROM bleiben erhalten. Werden sie nicht neu geschrieben, so enthält das EEPROM evtl. Daten, die nicht mehr zum Programm passen.<br />
; EESAVE = 1 (unprogrammed): Beim Programmieren werden die Daten im EEPROM gelöscht, also auf 0xff gesetzt.<br />
<br />
Als Sicherung kann man im Programm nochmals die Standardwerte vorhalten, beim Lesen auf 0xFF prüfen und gegebenenfalls einen Standardwert nutzen. Das geht natürlich nur, wenn 0xFF selbst nicht als Datenwert vorkommen kann.<br />
<syntaxhighlight lang="c"><br />
#define DUTY_CYCLE_DEFAULT 0x80<br />
<br />
uint8_t eeDutyCycle EEMEM; // Platzhalter für EEPROM<br />
uint8_t DutyCycle; // die echte Variable<br />
<br />
<br />
int main(void)<br />
{<br />
DutyCycle = eeprom_read_byte( &eeDutyCycle );<br />
if( DutyCycle == 0xFF ) // das allererste mal. Im EEPROM steht noch kein gültiger Wert<br />
{<br />
DutyCycle = DUTY_CYCLE_DEFAULT;<br />
eeprom_writeByte( &eeDutyCycle, DutyCycle );<br />
}<br />
<br />
...<br />
</syntaxhighlight><br />
<br />
=== Direkter Zugriff auf EEPROM-Adressen ===<br />
<br />
Will man direkt auf bestimmte EEPROM Adressen zugreifen, dann sind folgende IAR-kompatiblen Makros <tt>_EEGET</tt> und <tt>_EEPUT</tt> hilfreich, um sich die Typecasts zu ersparen.<br />
<br />
;Hinweis: Die nachfolgend gezeigten Makros und Zugriffe auf absolute Adressen sind in Normalfall nicht nötig und nur auf sehr wenige, spezielle Fälle beschränkt! Im Normalfall sollte man auf absolute Adressen möglichst nicht zugreifen und den Compiler seine Arbeit machen lassen, der verwaltet die Variablen und deren Adressen meist besser als der Programmierer. Der Zugriff auf Variablen im EEPROM sollte immer über ihren Namen erfolgen.<br />
<br />
Verwendung:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/eeprom.h><br />
<br />
_EEPUT (0x20, 128); // Byte-Wert 128 an Adresse 0x20 schreiben<br />
...<br />
uint8_t val = _EEGET (0x20); // EEPROM-Wert von Adresse 0x20 lesen<br />
</syntaxhighlight><br />
<br />
=== Was steckt dahinter? - EEPROM-Register ===<br />
Auch wenn es normalerweise keinen Grund gibt, in C selbst an den Steuerregistern herumzuschrauben - die eeprom Funktionen erledigen das alles zuverlässig - der Vollständigkeit halber der registermässige technische Unterbau.<br />
Um das EEPROM anzusteuern, sind drei Register von Bedeutung:<br />
;EEAR: Hier werden die Adressen eingetragen zum Schreiben oder Lesen. Dieses Register unterteilt sich nochmal in EEARH und EEARL, da in einem 8-Bit-Register keine 512 Adressen adressiert werden können.<br />
;EEDR: Hier werden die Daten eingetragen, die geschrieben werden sollen, bzw. es enthält die gelesenen Daten.<br />
;EECR: Ist das Kontrollregister für das EEPROM<br />
<br />
Das EECR steuert den Zugriff auf das EEPROM und ist wie folgt aufgebaut:<br />
<br />
:{| class="wikitable" style="text-align:center"<br />
|+ '''Aufbau des EECR-Registers'''<br />
|-<br />
!Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|-<br />
! Name<br />
| - || - || - ||- || EERIE || EEMWE || EEWE || EERE<br />
|-<br />
! Read/Write<br />
| R || R || R || R || R/W || R/W || R/W || R/W<br />
|-<br />
!Init Value<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''Bedeutung der Bits'''<br />
<br />
;Bit 4-7: nicht belegt<br />
<br />
;Bit 3 (EERIE): ''EEPROM Ready Interrupt Enable'': Wenn das Bit gesetzt ist und globale Interrupts erlaubt sind in Register SREG (Bit 7), wird ein Interrupt ausgelöst nach Beendigung des Schreibzyklus (EEPROM Ready Interrupt). Ist einer der beiden Bits 0, wird kein Interrupt ausgelöst.<br />
<br />
;Bit 2 EEMWE): ''EEPROM Master Write Enable'': Dieses Bit bestimmt, dass, wenn EEWE = 1 gesetzt wird (innerhalb von 4 Taktzyklen), das EEPROM beschrieben wird mit den Daten in EEDR bei Adresse EEAR. Wenn EEMWE = 0 ist und EEWE = 1 gesetzt wird, hat das keine Auswirkungen. Der Schreibvorgang wird dann nicht ausgelöst. Nach 4 Taktzyklen wird das Bit EEMWE automatisch wieder auf 0 gesetzt. Dieses Bit löst den Schreibvorgang nicht aus, es dient sozusagen als Sicherungsbit für EEWE.<br />
<br />
;Bit 1 (EEWE): ''EEPROM Write Enable'': Dieses Bit löst den Schreibvorgang aus, wenn es auf 1 gesetzt wird, sofern vorher EEMWE gesetzt wurde und seitdem nicht mehr als 4 Taktzyklen vergangen sind. Wenn der Schreibvorgang abgeschlossen ist, wird dieses Bit automatisch wieder auf 0 gesetzt und, sofern EERIE gesetzt ist, ein Interrupt ausgelöst. Ein Schreibvorgang sieht typischerweise wie folgt aus:<br />
:# EEPROM-Bereitschaft abwarten (EEWE=0) <br />
:# Adresse übergeben an EEAR<br />
:# Daten übergeben an EEDR<br />
:# Schreibvorgang auslösen in EECR mit Bit EEMWE=1 und EEWE=1<br />
:# (Optional) Warten, bis Schreibvorgang abgeschlossen ist<br />
<br />
;Bit 0 EERE: ''EEPROM Read Enable'': Wird dieses Bit auf 1 gesetzt wird das EEPROM an der Adresse in EEAR ausgelesen und die Daten in EEDR gespeichert. Das EEPROM kann nicht ausgelesen werden, wenn bereits eine Schreiboperation gestartet wurde. Es ist daher zu empfehlen, die Bereitschaft vorher zu prüfen. Das EEPROM ist lesebereit, wenn das Bit EEWE=0 ist. Ist der Lesevorgang abgeschlossen, wird das Bit wieder auf 0 gesetzt, und das EEPROM ist für neue Lese- und Schreibbefehle wieder bereit. Ein typischer Lesevorgang kann wie folgt aufgebaut sein:<br />
:# Bereitschaft zum Lesen prüfen (EEWE=0)<br />
:# Adresse übergeben an EEAR<br />
:# Lesezyklus auslösen mit EERE = 1<br />
:# Warten, bis Lesevorgang abgeschlossen EERE = 0<br />
:# Daten abholen aus EEDR<br />
<br />
= Die Nutzung von sprintf und printf =<br />
<br />
Um komfortabel, d.h. formatiert, Ausgaben auf ein Display oder die serielle Schnittstelle zu tätigen, bieten sich '''sprintf''' oder '''printf''' an. Alle *printf-Varianten sind jedoch ziemlich speicherintensiv und der Einsatz in einem Mikrocontroller mit knappem Speicher muss sorgsam abgewogen werden.<br />
<br />
Bei '''sprintf''' wird die Ausgabe zunächst in einem Puffer vorbereitet und anschließend mit einfachen Funktionen zeichenweise ausgegeben. Es liegt in der Verantwortung des Programmierers, genügend Platz im Puffer für die erwarteten Zeichen bereitzuhalten.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdio.h><br />
#include <stdint.h><br />
<br />
// ...<br />
// nicht dargestellt: Implementierung von uart_puts (vgl. Abschnitt UART)<br />
// ...<br />
<br />
uint16_t counter;<br />
<br />
// Ausgabe eines unsigned Integerwertes<br />
void uart_puti( uint16_t value )<br />
{<br />
uint8_t puffer[20];<br />
<br />
sprintf( puffer, "Zählerstand: %u", value );<br />
uart_puts( puffer );<br />
}<br />
<br />
int main()<br />
{<br />
counter = 5;<br />
<br />
uart_puti( counter );<br />
uart_puti( 42 );<br />
}<br />
</syntaxhighlight><br />
<br />
Eine weitere elegante Möglichkeit besteht darin, den STREAM stdout (Standardausgabe) auf eine eigene Ausgabefunktion umzuleiten. Dazu wird dem Ausgabemechanismus der C-Bibliothek eine neue Ausgabefunktion bekannt gemacht, deren Aufgabe es ist, ein einzelnes Zeichen auszugeben. Wohin die Ausgabe dann tatsächlich stattfindet, ist Sache der Ausgabefunktion. Im Beispiel unten wird auf UART ausgegeben. Alle anderen, höheren Funktionen wie z.&nbsp;B. '''printf''', greifen letztendlich auf diese primitive Ausgabefunktion zurück. <br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdio.h><br />
<br />
void uart_init(void);<br />
<br />
// a. Deklaration der primitiven Ausgabefunktion<br />
int uart_putchar(char c, FILE *stream);<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 1)<br />
static FILE mystdout = FDEV_SETUP_STREAM( uart_putchar, NULL, _FDEV_SETUP_WRITE );<br />
<br />
// c. Definition der Ausgabefunktion<br />
int uart_putchar( char c, FILE *stream )<br />
{<br />
if( c == '\n' )<br />
uart_putchar( '\r', stream );<br />
<br />
loop_until_bit_is_set( UCSRA, UDRE );<br />
UDR = c;<br />
return 0;<br />
}<br />
<br />
void uart_init(void)<br />
{<br />
/* hier µC spezifischen Code zur Initialisierung */<br />
/* des UART einfügen... s.o. im AVR-GCC-Tutorial */<br />
<br />
// Beispiel: <br />
//<br />
// myAVR Board 1.5 mit externem Quarz Q1 3,6864 MHz<br />
// 9600 Baud 8N1<br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
// Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt)<br />
#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)<br />
<br />
UCSRB |= (1<<TXEN) | (1<<RXEN); // UART TX und RX einschalten<br />
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1 <br />
<br />
UBRRH = (uint8_t)( UART_UBRR_CALC( UART_BAUD_RATE, F_CPU ) >> 8 );<br />
UBRRL = (uint8_t)UART_UBRR_CALC( UART_BAUD_RATE, F_CPU );<br />
}<br />
<br />
int main(void)<br />
{<br />
int16_t antwort = 42;<br />
uart_init();<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 2)<br />
stdout = &mystdout;<br />
<br />
// Anwendung<br />
printf( "Die Antwort ist %d.\n", antwort );<br />
return 0;<br />
}<br />
<br />
// Quelle: avr-libc-user-manual-1.4.3.pdf, S.74<br />
// + Ergänzungen<br />
</syntaxhighlight><br />
<br />
<br />
Sollen Fließkommazahlen ausgegeben werden, muss im Makefile eine andere (größere) Version der [[FAQ#Aktivieren_der_Floating_Point_Version_von_sprintf_beim_WinAVR_mit_AVR-Studio|printflib]] eingebunden werden.<br />
<br />
= Anmerkungen =<br />
<references/><br />
<br />
= TODO =<br />
* Aktualisierung Register- und Bitbeschreibungen an aktuelle AVR<br />
* "naked"-Funktionen [http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html][http://arduino.stackexchange.com/questions/8758/arduino-interruption-on-pin-change]<br />
<br />
[[Kategorie:avr-gcc Tutorial| ]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR-GCC-Tutorial&diff=107258AVR-GCC-Tutorial2025-01-27T14:34:56Z<p>Heha: /* Was macht das Hauptprogramm? */</p>
<hr />
<div>Dieses Tutorial soll den Einstieg in die Programmierung von Atmel [[AVR]]-Mikrocontrollern in der Programmiersprache [[C]] mit dem freien C-Compiler [[avr-gcc]] aus der [http://gcc.gnu.org/ GNU Compiler Collection] (GCC) erleichtern.<br />
<br />
Vorausgesetzt werden Grundkenntnisse der Programmiersprache C. Diese Kenntnisse kann man sich online erarbeiten, z. B. mit dem [http://www.schellong.de/c.htm C Tutorial von Helmut Schellong] ([[C|Liste von C-Tutorials]]). Nicht erforderlich sind Vorkenntnisse in der Programmierung von Mikrocontrollern.<br />
<br />
= Vorwort =<br />
<br />
In diesem Text wird häufig auf die Standardbibliothek avr-libc verwiesen, für die es eine [http://www.nongnu.org/avr-libc/user-manual/index.html Online-Dokumentation] gibt, in der sich auch viele nützliche Informationen zum Compiler und zur Programmierung von AVR-Controllern finden. Beim Paket [[WinAVR]] gehört die avr-libc Dokumentation zum Lieferumfang und wird mitinstalliert.<br />
<br />
Der Compiler und die Standardbibliothek avr-libc werden ständig weiterentwickelt. Einige Unterschiede, die sich im Verlauf der Entwicklung ergeben haben, werden hier und im Artikel [[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen]] zwar angesprochen, Anfängern und Umsteigern sei jedoch empfohlen, eine aktuelle Versionen zu nutzen.<br />
<br />
Das ursprüngliche Tutorial stammt von Christian Schifferle, viele neue Abschnitte und aktuelle Anpassungen von Martin Thomas.<br />
<br />
Dieses Tutorial ist in [[Media:AVR-GCC-Tutorial.pdf|PDF-Form]] erhältlich (zur Zeit nur eine sehr veraltete Version).<br />
<br />
== Weiterführende Kapitel ==<br />
<br />
Um dieses riesige Tutorial etwas überschaubarer zu gestalten, wurden einige Kapitel ausgelagert, die nicht unmittelbar mit den Grundlagen von avr-gcc in Verbindung stehen. All diese Seiten gehören zur [[:Kategorie:avr-gcc Tutorial]].<br />
<br />
;UART: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der UART|Der UART]]''<br />
<br />
;ADC: → Hauptartikel: ''[[AVR-GCC-Tutorial/Analoge Ein- und Ausgabe|Analoge Ein- und Ausgabe (ADC)]]''<br />
<br />
;Timer: → Hauptartikel: ''[[AVR-GCC-Tutorial/Die Timer und Zähler des AVR|Die Timer und Zähler des AVR]]''<br />
<br />
;LCD: → Hauptartikel: ''[[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Ansteuerung]]''<br />
<br />
;Watchdog: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der Watchdog|Der Watchdog]]''<br />
<br />
;Assembler: → Hauptartikel: ''[[AVR-GCC-Tutorial/Assembler und Inline-Assembler|Assembler und Inline-Assembler]]''<br />
<br />
;alte Quellen anpassen: → Hauptartikel: ''[[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen anpassen]]''<br />
<br />
;Makefiles: → Hauptartikel: ''[[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]]'' sowie als Alternative für sehr kleine Projekte → Hauptartikel: ''[[C ohne Makefile]]''<br />
<br />
= Benötigte Werkzeuge =<br />
<br />
Um eigene Programme für AVRs mittels einer AVR-Toolchain zu erstellen wird folgende Hard- und Software benötigt:<br />
<br />
* Eine AVR-Toolchain bestehend aus avr-gcc, den avr-Binutils (Assembler, Linker, etc) und einer Standard-C Bibliothek. Üblich ist die AVR-LibC, die auch quasi in allen avr-gcc Distributionen enthalten ist.<br />
<br />
Hardware wird keine benötigt – bis auf einen PC natürlich, auf dem der Compiler ablaufen kann. Selbst ohne AVR-Hardware kann man also bereits C-Programme für AVRs schreiben, compiliern und sich das Look-and-Feel von avr-gcc sowie von IDEs wie [[Atmel Studio]], Eclipse oder leichtgewichtigeren Entwicklungsumbgebungen anschauen. Selbst das Debuggen und Simulieren ist mithilfe entsprechender Tools wie Debugger und Simulator in gewissen Grenzen möglich.<br />
<br />
Um Programme für AVRs mittels einer AVR-Toolchain zu testen, wird folgende Hard- und Software benötigt:<br />
<br />
* Platine oder Versuchsaufbau für die Aufnahme eines AVR-Controllers, der vom avr-gcc Compiler unterstützt wird.<ref>Für eine Liste der unterstützten COntroller siehe die Dokumentation des Compilers oder [http://www.nongnu.org/avr-libc/user-manual/index.html#supported_devices AVR-Libc: Supported Devices].</ref> Dieses Testboard kann durchaus auch selbst gelötet oder auf einem Steckbrett aufgebaut werden. Einige Registerbeschreibungen dieses Tutorials beziehen sich auf den inzwischen veralteten AT90S2313. Der weitaus größte Teil des Textes ist aber für alle Controller der AVR-Familie gültig. <br />
<br />
:Brauchbare Testplattformen sind auch das [[STK500]] und der [[AVR Butterfly]] von Atmel. Weitere Infos findet man in den Artikeln [[AVR#Starterkits|AVR Starterkits]] und [[AVR-Tutorial: Equipment]].<br />
<br />
* Programmiersoftware und -[[AVR In System Programmer |hardware]] z. B. PonyProg (siehe auch: [[Pony-Prog Tutorial]]) oder [[AVRDUDE]] mit [[STK200]]-Dongle oder die von Atmel verfügbare Hard- und Software ([[STK500]], Atmel AVRISP, [[AVR-Studio]]).<br />
<br />
* Nicht unbedingt erforderlich, aber zur Simulation und zum Debuggen unter MS-Windows recht nützlich: [[AVR-Studio]].<br />
<br />
* Wer unter Windows und Linux gleichermassen entwickeln will, der sollte sich die [http://www.eclipse.org/ IDE Eclipse for C/C++ Developers] und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] ansehen. Beide sind unter Windows und Linux einfach zu installieren, siehe auch [[AVR Eclipse]]. Ebenfalls unter Linux und Windows verfügbar ist die Entwicklungsumgebung [http://www.codeblocks.org/ Code::Blocks]<ref>Aktuelle, stabile Versionen sind als Nightly Builds regelmäßig im [http://forums.codeblocks.org/ Forum] verfügbar.</ref>. Innerhalb dieser Entwicklungsumgebung können ohne die Installation zusätzlicher Plugins "AVR-Projekte" angelegt werden. Für Linux gibt es auch noch das [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=25220 KontrollerLab].<br />
<br />
= Was tun, wenn's nicht klappt? =<br />
<br />
* Herausfinden, ob es tatsächlich ein avr(-gcc) spezifisches Problem ist oder nur die eigenen C-Kenntnisse einer Auffrischung bedürfen. Allgemeine C-Fragen kann man eventuell "beim freundlichen Programmierer zwei Büro-, Zimmer- oder Haustüren weiter" loswerden. Ansonsten: [[C]]-Buch (gibt's auch "gratis" online) lesen.<br />
<br />
* Die [[AVR Checkliste]] durcharbeiten.<br />
<br />
* Die '''[http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc]''' lesen, vor allem (aber nicht nur) den Abschnitt Related Pages/'''Frequently Asked Questions''' = Oft gestellte Fragen (und Antworten dazu). Z.Zt leider nur in englischer Sprache verfügbar.<br />
<br />
* Den Artikel [[AVR-GCC]] in diesem Wiki lesen.<br />
<br />
* Das [http://www.mikrocontroller.net/forum/gcc GCC-Forum auf www.mikrocontroller.net] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das avr-gcc-Forum bei [http://www.avrfreaks.net AVRfreaks] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das [http://lists.gnu.org/archive/html/avr-gcc-list/ Archiv der avr-gcc Mailing-Liste] nach vergleichbaren Problemen absuchen.<br />
<br />
* Nach Beispielcode suchen. Vor allem im ''Projects''-Bereich von [http://www.avrfreaks.net AVRfreaks] (anmelden).<br />
<br />
* Google oder yahoo befragen schadet nie.<br />
<br />
* Bei Problemen mit der Ansteuerung interner AVR-Funktionen mit C-Code: das Datenblatt des Controllers lesen (ganz und am Besten zweimal). Datenblätter sind auf den [http://www.atmel.com Atmel Webseiten] als pdf-Dateien verfügbar. Das komplette Datenblatt (complete) und nicht die Kurzfassung (summary) verwenden.<br />
<br />
* Die Beispielprogramme im [[AVR-Tutorial]] sind zwar in AVR-Assembler verfasst, Erläuterungen und Vorgehensweisen sind aber auch auf C-Programme übertragbar.<br />
<br />
* Einen Beitrag in eines der Foren oder eine Mail an die Mailing-Liste schreiben. Dabei möglichst viel Information geben: Controller, Compilerversion, genutzte Bibliotheken, Ausschnitte aus dem Quellcode oder besser ein [http://www.mikrocontroller.net/topic/72767#598986 Testprojekt] mit allen notwendigen Dateien, um das Problem nachzuvollziehen, sowie genaue Fehlermeldungen bzw. Beschreibung des Fehlverhaltens. Bei Ansteuerung externer Geräte die Beschaltung beschreiben oder skizzieren (z. B. mit [http://www.tech-chat.de/ Andys ASCII Circuit]). Siehe dazu auch: '''[http://www.tty1.net/smart-questions_de.html "Wie man Fragen richtig stellt"]'''.<br />
<br />
= Erzeugen von Maschinencode =<br />
<br />
Aus dem C-Quellcode erzeugt der avr-gcc Compiler (zusammen mit Hilfsprogrammen wie z.&nbsp;B. Präprozessor, Assembler und Linker) Maschinencode für den AVR-Controller. Üblicherweise liegt dieser Code dann im Intel Hex-Format vor ("Hex-Datei"). Die Programmiersoftware (z.&nbsp;B. [[AVRDUDE]], PonyProg oder AVRStudio/STK500-plugin) liest diese Datei ein und überträgt die enthaltene Information (den Maschinencode) in den Speicher des Controllers. Im Prinzip sind also "nur" der avr-gcc-Compiler (und wenige Hilfsprogramme) mit den "richtigen" Optionen aufzurufen, um aus C-Code eine "Hex-Datei" zu erzeugen. Grundsätzlich stehen dazu drei verschiedene Ansätze zur Verfügung:<br />
<br />
* Die Verwendung einer integrierten Entwicklungsumgebung (IDE = '''I'''ntegrated '''D'''evelopment '''E'''nvironment), bei der alle Einstellungen z.&nbsp;B. in Dialogboxen durchgeführt werden können. Unter Anderem kann AVRStudio ab Version 4.12 (kostenlos auf [http://www.atmel.com/ atmel.com]) zusammen mit WinAVR als integrierte Entwicklungsumgebung für den Compiler avr-gcc genutzt werden (dazu müssen AVRStudio und WinAVR auf dem Rechner installiert sein). Weitere IDEs (ohne Anspruch auf Vollständigkeit): [http://www.eclipse.org/ Eclipse for C/C++ Developers] (d.h. inkl. CDT) und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] (für diverse Plattformen, u.a. Linux und MS Windows, IDE und Plugin kostenlos), [http://sourceforge.net/projects/kontrollerlab KontrollerLab] (Linux/KDE, kostenlos). [http://www.atmanecl.com/EnglishSite/SoftwareEnglish.htm AtmanAvr] (MS Windows, relativ günstig), KamAVR (MS-Windows, kostenlos, wird augenscheinlich nicht mehr weiterentwickelt), [http://www.amctools.com/vmlab.htm VMLab] (MS Windows, ab Version 3.12 ebenfalls kostenlos). Integrierte Entwicklungsumgebungen unterscheiden sich stark in Ihrer Bedienung und stehen auch nicht für alle Plattformen zur Verfügung, auf denen der Compiler ausführbar ist (z.&nbsp;B. AVRStudio nur für MS-Windows). Zur Anwendung des avr-gcc Compilers mit IDEs sei hier auf deren Dokumentation verwiesen. <br />
<br />
* Die Nutzung des Programms make mit passenden Makefiles. In den folgenden Abschnitten wird die Generierung von Maschinencode für einen AVR ("hex-Datei") aus C-Quellcode ("c-Dateien") anhand von "make" und den "Makefiles" näher erläutert. Viele der darin beschriebenen Optionen findet man auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio (AVRStudio generiert ein makefile in einem Unterverzeichnis des Projektverzeichnisses). <br />
<br />
* Das Generieren des Programms ohne IDE und ohne Makefile. In diesem Fall muss die Quellcodedatei durch eine vorgefertigte Kommandofolge an den Compiler übergeben werden. Der Artikel [[C ohne Makefile]] zeigt, wie das funktioniert. Diese Vorgehensweise empfiehlt sich jedoch nur für kleine Programme, die nicht auf verschiedene Quellcodedateien verteilt sind.<br />
<br />
Beim Wechsel vom makefile-Ansatz nach WinAVR-Vorlage zu AVRStudio ist darauf zu achten, dass AVRStudio (Stand: AVRStudio Version 4.13) bei einem neuen Projekt die Optimierungsoption (vgl. Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|AVR-GCC-Tutorial/Exkurs: Makefiles]], typisch: -Os) nicht einstellt und die mathematische Bibliothek der avr-libc (libm.a, Linker-Option -lm) nicht einbindet. (Hinweis: Bei Version 4.16 wird beides bereits gesetzt). Beides ist Standard bei Verwendung von makefiles nach WinAVR-Vorlage und sollte daher auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio "manuell" eingestellt werden, um auch mit AVRStudio kompakten Code zu erzeugen.<br />
<br />
= Einführungsbeispiel =<br />
<br />
Zum Einstieg ein kleines Beispiel, an dem die Nutzung des Compilers und der Hilfsprogramme (der sogenannten ''Toolchain'') demonstriert wird. Detaillierte Erläuterungen folgen in den weiteren Abschnitten dieses Tutorials.<br />
<br />
Das Programm soll auf einem AVR Mikrocontroller einige Ausgänge ein- und andere ausschalten. Das Beispiel ist für einen ATmega16 programmiert ([http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf Datenblatt]), kann aber sinngemäß für andere Controller der AVR-Familie modifiziert werden. <br />
<br />
Ein kurzes Wort zur Hardware: Bei diesem Programm werden alle Pins von PORTB auf Ausgang gesetzt, und einige davon werden auf HIGH andere auf LOW gesetzt. Das kann je nach angeschlossener Hardware an diesen Pins kritisch sein. Am ungefährlichsten ist es, wenn nichts an den Pins angeschlossen ist und man die Funktion des Programmes durch eine Spannungsmessung mit einem Multimeter kontrolliert. Die Spannung wird dabei zwischen GND-Pin und den einzelnen Pins von PORTB gemessen.<br />
<br />
Zunächst der Quellcode der Anwendung, der in einer Text-Datei mit dem Namen ''main.c'' abgespeichert wird.<br />
<br />
<syntaxhighlight lang="c"><br />
/* Alle Zeichen zwischen Schrägstrich-Stern <br />
und Stern-Schrägstrich sind Kommentare */<br />
<br />
// Zeilenkommentare sind ebenfalls möglich<br />
// alle auf die beiden Schrägstriche folgenden<br />
// Zeichen einer Zeile sind Kommentar<br />
<br />
#include <avr/io.h> // (1)<br />
<br />
int main (void) { // (2)<br />
<br />
DDRB = 0xFF; // (3)<br />
PORTB = 0x03; // (4)<br />
<br />
while(1) { // (5)<br />
/* "leere" Schleife*/ // (6)<br />
} // (7)<br />
<br />
/* wird nie erreicht */<br />
return 0; // (8)<br />
}<br />
</syntaxhighlight><br />
<br />
# In dieser Zeile wird eine sogenannte Header-Datei eingebunden. In <code>avr/io.h</code> sind die Registernamen definiert, die im späteren Verlauf genutzt werden. Auch unter Windows wird ein&nbsp;<code>/</code> zur Kennzeichnung von Unterverzeichnissen in Include-Dateinamen verwendet und kein&nbsp;<code>\</code>.<br />
# Hier beginnt das eigentliche Programm. Jedes C-Programm beginnt mit den Anweisungen in der Funktion <code>main</code>.<br />
# Die Anschlüsse eines AVR (Pins) werden zu Blöcken zusammengefasst, einen solchen Block bezeichnet man als Port. Beim ATmega16 hat jeder Port 8 Anschlüsse, bei kleineren AVRs können einem Port auch weniger als 8 Anschlüsse zugeordnet sein. Da per Definition (Datenblatt) alle gesetzten Bits in einem Datenrichtungsregister den entsprechenden Anschluss auf Ausgang schalten, werden mit DDRB=0xff alle Anschlüsse des Ports B als Ausgänge eingestellt.<br />
# Die den ersten beiden Bits des Ports zugeordneten Anschlüsse (PB0 und PB1) werden 1, alle anderen Anschlüsse des Ports B (PB2-PB7) zu 0. Aktivierte Ausgänge (logisch 1 oder "high") liegen auf Betriebsspannung (VCC, meist 5 Volt), nicht aktivierte Ausgänge führen 0 Volt (GND, Bezugspotential). Es ist sinnvoll, sich möglichst frühzeitig eine alternative Schreibweise beizubringen, die wegen der leichteren Überprüfbarkeit und Portierbarkeit oft im weiteren Tutorial und in Forenbeiträgen benutzt wird. Die Zuordnung sieht in diesem Fall so aus, Näheres dazu im Artikel [[Bitmanipulation]]:<syntaxhighlight lang="c">PORTB = (1<<PB1) | (1<<PB0);</syntaxhighlight><br />
# ist der Beginn der sogenannte ''Hauptschleife'' (main-loop). Dies ist eine Endlosschleife, welche kontinuierlich wiederkehrende Befehle enthält.<br />
# In diesem Beispiel ist die Hauptschleife leer. Der Controller durchläuft die Schleife immer wieder, ohne dass etwas passiert. Eine solche Schleife ist notwendig, da es auf dem Controller kein Betriebssystem gibt, das nach Beendigung des Programmes die Kontrolle übernehmen könnte. Ohne diese Schleife kehrt das Programm aus <code>main</code> zurück, alle Interrupts werden deaktiviert und eine Endlosschleife betreten.<br />
# Ende der Hauptschleife und Sprung zur passenden, öffnenden Klammer, also zu 5.<br />
# ist das Programmende. Die Zeile ist nur aus Gründen der C-Kompatibilität enthalten: <syntaxhighlight lang="c">int main(void)</syntaxhighlight> besagt, dass die Funktion einen int-Wert zurückgibt. Die Anweisung wird aber nicht erreicht, da das Programm die Hauptschleife nie verlässt.<br />
<br />
Um diesen Quellcode in ein lauffähiges Programm zu übersetzen, wird hier ein Makefile genutzt. Das verwendete Makefile findet sich auf der Seite [[Beispiel Makefile]] und basiert auf der Vorlage, die in WinAVR mitgeliefert wird und wurde bereits angepasst (Controllertyp ATmega16). Man kann das Makefile bearbeiten und an andere Controller anpassen oder sich mit dem Programm MFile menügesteuert ein Makefile "zusammenklicken". Das Makefile speichert man unter dem Namen <code>Makefile</code> (ohne Endung) im selben Verzeichnis, in dem auch die Datei <code>main.c</code> mit dem Programmcode abgelegt ist. Detailliertere Erklärungen zur Funktion von Makefiles finden sich im Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|Exkurs: Makefiles]].<br />
<br />
<pre><br />
D:\beispiel>dir<br />
<br />
Verzeichnis von D:\beispiel<br />
<br />
28.11.2006 22:53 <DIR> .<br />
28.11.2006 22:53 <DIR> ..<br />
28.11.2006 20:06 118 main.c<br />
28.11.2006 20:03 16.810 Makefile<br />
2 Datei(en) 16.928 Bytes<br />
</pre><br />
<br />
Nun gibt man ''make all'' ein. Falls das mit WinAVR installierte Programmers Notepad genutzt wird, gibt es dazu einen Menüpunkt im Tools Menü. Sind alle Einstellungen korrekt, entsteht eine Datei <code>main.hex</code>, in welcher der Code für den AVR enthalten ist. <br />
<pre><br />
D:\beispiel>make all<br />
<br />
-------- begin --------<br />
avr-gcc (GCC) 3.4.6<br />
Copyright (C) 2006 Free Software Foundation, Inc.<br />
This is free software; see the source for copying conditions. There is NO<br />
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.<br />
<br />
Compiling C: main.c<br />
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -f<br />
unsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef<br />
-Wa,-adhlns=obj/main.lst -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c -<br />
o obj/main.o<br />
<br />
Linking: main.elf<br />
avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -funs<br />
igned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -W<br />
a,-adhlns=obj/main.o -std=gnu99 -Wundef -MD -MP -MF .dep/main.elf.d obj/main.o<br />
--output main.elf -Wl,-Map=main.map,--cref -lm<br />
<br />
Creating load file for Flash: main.hex<br />
avr-objcopy -O ihex -R .eeprom main.elf main.hex<br />
</pre><br />
<br />
Der Inhalt der hex-Datei kann nun zum Controller übertragen werden. Dies kann z.&nbsp;B. über In-System-Programming ([[ISP]]) erfolgen, das im [[AVR-Tutorial: Equipment]] beschrieben ist. Makefiles nach der WinAVR/MFile-Vorlage sind für die Nutzung des Programms [[AVRDUDE]] vorbereitet. Wenn man den Typ und Anschluss des Programmiergerätes richtig eingestellt hat, kann mit ''make program'' die Übertragung mittels AVRDUDE gestartet werden. Jede andere Software, die hex-Dateien lesen und zu einem AVR übertragen kann<ref>z.&nbsp;B. [[Pony-Prog_Tutorial|Ponyprog]], yapp, AVRStudio</ref>, kann natürlich ebenfalls genutzt werden.<br />
<br />
Startet man nun den Controller (Reset-Taster oder Stromzufuhr aus/an), werden vom Programm die Anschlüsse PB0 und PB1 auf 1 gesetzt. Man kann mit einem Messgerät nun an diesem Anschluss die Betriebsspannung messen oder eine [[LED]] leuchten lassen (Anode an den Pin, Vorwiderstand nicht vergessen). An den Anschlüssen PB2-PB7 misst man 0 Volt. Eine mit der Anode mit einem dieser Anschlüsse verbundene LED leuchtet nicht.<br />
<br />
= Ganzzahlige Datentypen (Integer) =<br />
<br />
Bei der Programmierung von Mikrokontrollern ist die Definition einiger ganzzahliger Datentypen sinnvoll, an denen eindeutig die Bit-Länge abgelesen werden kann.<br />
<br />
Standardisierte Datentypen werden in der Header-Datei <code>stdint.h</code> definiert, die folgendermaßen eingebunden werden kann:<br />
<syntaxhighlight lang="c">#include <stdint.h></syntaxhighlight><br />
<br />
{| {{Tabelle}}<br />
|+ '''int-Typen aus <code>stdint.h</code> (C99)'''<br/>&nbsp;<br />
|- bgcolor="#d0d0ff"<br />
!colspan="5"| Vorzeichenbehaftete int-Typen<br />
|- bgcolor="#e8e8ff"<br />
! Typname || Bit-Breite ||colspan="2"| Wertebereich<br />
|align="center| '''C-Entsprechung''' (avr-gcc)<br />
|-<br />
|<code>int8_t</code> ||align="right"| 8 || −128 ⋯ 127 || −2<sup>7</sup> ⋯ 2<sup>7</sup>−1 || <code>signed char</code><br />
|-<br />
|<code>int16_t</code> ||align="right"| 16 || −32768 ⋯ 32767 || −2<sup>15</sup> ⋯ 2<sup>15</sup>−1 || <code>signed short</code>, <code>signed int</code><br />
|-<br />
|<code>int32_t</code> ||align="right"| 32 || −2147483648 ⋯ 2147483647 || −2<sup>31</sup> ⋯ 2<sup>31</sup>−1 || <code>signed long</code><br />
|-<br />
|<code>int64_t</code> ||align="right"| 64 || −9223372036854775808 ⋯ 9223372036854775807 || −2<sup>63</sup> ⋯ 2<sup>63</sup>−1 || <code>signed long long</code><br />
|- bgcolor="#d0d0ff"<br />
!colspan="5"| Vorzeichenlose int-Typen<br />
|- bgcolor="#e8e8ff"<br />
! Typname || Bit-Breite ||colspan="2"| Wertebereich<br />
|align="center| '''C-Entsprechung''' (avr-gcc)<br />
|-<br />
|<code>uint8_t</code> ||align="right"| 8 || 0 ⋯ 255 || 0 ⋯ 2<sup>8</sup>−1 || <code>unsigned char</code><br />
|-<br />
|<code>uint16_t</code> ||align="right"| 16 || 0 ⋯ 65535 || 0 ⋯ 2<sup>16</sup>−1 || <code>unsigned short</code>, <code>unsigned int</code><br />
|-<br />
|<code>uint32_t</code> ||align="right"| 32 || 0 ⋯ 4294967295 || 0 ⋯ 2<sup>32</sup>−1 || <code>unsigned long</code><br />
|-<br />
|<code>uint64_t</code> ||align="right"| 64 || 0 ⋯ 18446744073709551615 || 0 ⋯ 2<sup>64</sup>−1 || <code>unsigned long long</code><br />
|}<br />
<br />
Neben den Typen gibt es auch Makros für die Bereichsgrenzen wie <code>INT8_MIN</code> oder <code>UINT16_MAX</code>. Siehe dazu auch: [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html Dokumentation der avr-libc: Standard Integer Types].<br />
<br />
= Grundsätzlicher Programmaufbau eines µC-Programms =<br />
<br />
Wir unterscheiden zwischen 2 verschiedenen Methoden, um ein<br />
Mikrocontroller-Programm zu schreiben, und zwar völlig unabhängig davon, in<br />
welcher Programmiersprache das Programm geschrieben wird.<br />
<br />
== Sequentieller Programmablauf ==<br />
<br />
[[Image:Sequentielle Programme.gif|left]]<br />
Bei dieser Programmiertechnik wird eine Endlosschleife programmiert, welche im<br />
Wesentlichen immer den gleichen Aufbau hat. Es wird hier nach dem sogenannten EVA-Prinzip gehandelt. EVA steht für "Eingabe, Verarbeitung, Ausgabe".<br />
{{Absatz}}<br />
<br />
== Interruptgesteuerter Programmablauf ==<br />
<br />
[[Image:Interrupt Programme.gif|left]]<br />
Bei dieser Methode werden beim Programmstart zuerst die gewünschten Interruptquellen aktiviert und dann in eine Endlosschleife gegangen, in welcher Dinge erledigt werden können, welche nicht zeitkritisch sind. Wenn ein Interrupt ausgelöst wird, so wird automatisch die zugeordnete Interruptfunktion ausgeführt.<br />
{{Absatz}}<br />
<br />
= Zugriff auf Register =<br />
<br />
Die AVR-Controller verfügen über eine Vielzahl von Registern. Die meisten<br />
davon sind sogenannte Schreib-/Leseregister. Das heißt, das Programm kann die<br />
Inhalte der Register sowohl auslesen als auch beschreiben.<br />
<br />
Register haben einen besonderen Stellenwert bei den AVR Controllern. Sie dienen dem Zugriff auf die Ports und die Schnittstellen des Controllers. Wir unterscheiden zwischen 8-Bit und 16-Bit Registern. Vorerst behandeln wir die 8-Bit Register.<br />
<br />
Einzelne Register sind bei allen AVRs vorhanden, andere wiederum nur bei bestimmten Typen. So sind beispielsweise die Register, welche für den Zugriff auf den UART notwendig sind, selbstverständlich nur bei denjenigen Modellen vorhanden, welche über einen integrierten Hardware UART bzw. USART verfügen.<br />
<br />
Die Namen der Register sind in den Headerdateien zu den entsprechenden AVR-Typen definiert. Dazu muss man den Namen der controllerspezifischen Headerdatei nicht kennen. Es reicht aus, die allgemeine Headerdatei ''avr/io.h'' einzubinden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
</syntaxhighlight><br />
<br />
Ist im Makefile der MCU-Typ z.&nbsp;B. mit dem Inhalt atmega8 definiert (und wird somit per -mmcu=atmega8 an den Compiler übergeben), wird beim Einlesen der io.h-Datei implizit ("automatisch") auch die iom8.h-Datei mit den Register-Definitionen für den ATmega8 eingelesen.<br />
<br />
<!-- Wohl besser als Anhang - spaeter... --><br />
Intern wird diese "Automatik" wie folgt realisiert: Der Controllertyp wird dem Compiler als Parameter übergeben (vgl. ''avr-gcc -c -mmcu=atmega16 [...]'' im Einführungsbeispiel). Wird ein Makefile nach der WinAVR/mfile-Vorlage verwendet, setzt man die Variable ''MCU'', der Inhalt dieser Variable wird dann an passender Stelle für die Compilerparameter verwendet. Der Compiler definiert intern eine dem mmcu-Parameter zugeordnete "Variable" (genauer: ein Makro) mit dem Namen des Controllers, vorangestelltem ''__AVR_'' und angehängten Unterstrichen (z.&nbsp;B. wird bei ''-mmcu=atmega16'' das Makro ''__AVR_ATmega16__'' definiert). Beim Einbinden der Header-Datei ''avr/io.h'' wird geprüft, ob das jeweilige Makro definiert ist und die zum Controller passende Definitionsdatei eingelesen. Zur Veranschaulichung einige Ausschnitte aus einem Makefile:<br />
<br />
<pre><br />
[...]<br />
# MCU Type ("name") setzen:<br />
MCU = atmega16<br />
[...]<br />
<br />
[...]<br />
## Verwendung des Inhalts von MCU (hier atmega16) fuer die <br />
## Compiler- und Assembler-Parameter<br />
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)<br />
ALL_CPPFLAGS = -mmcu=$(MCU) -I. -x c++ $(CPPFLAGS) $(GENDEPFLAGS)<br />
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)<br />
[...]<br />
<br />
[...]<br />
## Aufruf des Compilers:<br />
## mit den Parametern ($(ALL_CFLAGS) ist -mmcu=$(MCU)[...] = -mmcu=atmega16[...]<br />
$(OBJDIR)/%.o : %.c<br />
@echo<br />
@echo $(MSG_COMPILING) $<<br />
$(CC) -c $(ALL_CFLAGS) $< -o $@ <br />
[...]<br />
</pre><br />
<br />
Da --mmcu=atmega16 übergeben wurde, wird __AVR_ATmega16__ definiert und kann in avr/io.h zur Fallunterscheidung genutzt werden:<br />
<br />
<syntaxhighlight lang="c"><br />
// avr/io.h <br />
// (bei WinAVR-Standardinstallation in C:\WinAVR\avr\include\avr)<br />
[...]<br />
#if defined (__AVR_AT94K__)<br />
# include <avr/ioat94k.h><br />
// [...]<br />
#elif defined (__AVR_ATmega16__)<br />
// da __AVR_ATmega16__ definiert ist, wird avr/iom16.h eingebunden:<br />
# include <avr/iom16.h><br />
// [...]<br />
#else<br />
# if !defined(__COMPILING_AVR_LIBC__)<br />
# warning "device type not defined"<br />
# endif<br />
#endif<br />
</syntaxhighlight><br />
<br />
Die Beispiele in den folgenden Abschnitten demonstrieren den Zugriff auf Register anhand der Register für I/O-Ports (PORTx, DDRx, PINx), die Vorgehensweise ist jedoch für alle Register (z.&nbsp;B. die des UART, ADC, SPI) analog.<br />
<br />
== Schreiben in Register ==<br />
<br />
Zum Schreiben kann man Register einfach wie eine Variable setzen.<ref>In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Schreibzugriff über die Funktion outp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt, outp() ist nicht mehr erforderlich.</ref><br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
/* Setzt das Richtungsregister des Ports A auf 0xff <br />
(alle Pins als Ausgang, vgl. Abschnitt Zugriff auf Ports): */<br />
DDRA = 0xff; <br />
<br />
/* Setzt PortA auf 0x03, Bit 0 und 1 "high", restliche "low": */<br />
PORTA = 0x03; <br />
<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binär 00011111 = Hexadezimal 1F<br />
DDRB = 0x1F; /* direkte Zuweisung - unübersichtlich */<br />
<br />
/* Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit<br />
aber übersichtlicher und selbsterklärend: */<br />
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);<br />
<br />
while (1);<br />
}<br />
</syntaxhighlight><br />
<br />
Die ausführliche Schreibweise sollte bevorzugt verwendet werden, da dadurch die Zuweisungen selbsterklärend sind und somit der Code leichter nachvollzogen werden kann. Atmel verwendet sie auch bei Beispielen in Datenblätten und in den allermeisten Quellcodes zu Application-Notes. Mehr zu der Schreibweise mit "|" und "<<" findet man unter [[Bitmanipulation]].<br />
<br />
Der gcc C-Compiler unterstützt ab Version 4.3.0 Konstanten im Binärformat, z.&nbsp;B. DDRB&nbsp;=&nbsp;0b00011111. Diese Schreibweise ist jedoch nur in GNU-C verfügbar und nicht in ISO-C definiert. Man sollte sie daher nicht verwenden, wenn Code mit anderen ausgetauscht oder mit anderen Compilern bzw. älteren Versionen des gcc genutzt werden soll.<br />
<br />
== Verändern von Registerinhalten ==<br />
<br />
Einzelne Bits setzt und löscht man "Standard-C-konform" mittels logischer (Bit-) Operationen. <br />
<br />
<syntaxhighlight lang="c"><br />
x |= (1 << Bitnummer); // Hiermit wird ein Bit in x gesetzt<br />
x &= ~(1 << Bitnummer); // Hiermit wird ein Bit in x geloescht<br />
</syntaxhighlight><br />
<br />
Es wird jeweils nur der Zustand des angegebenen Bits geändert, der vorherige Zustand der anderen Bits bleibt erhalten. <br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
#define MEINBIT 2<br />
...<br />
PORTA |= (1 << MEINBIT); /* setzt Bit 2 an PortA auf 1 */<br />
PORTA &= ~(1 << MEINBIT); /* loescht Bit 2 an PortA */<br />
</syntaxhighlight><br />
<br />
Mit dieser Methode lassen sich auch mehrere Bits eines Registers gleichzeitig setzen und löschen.<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
DDRA &= ~( (1<<PA0) | (1<<PA3) ); /* PA0 und PA3 als Eingaenge */<br />
PORTA |= ( (1<<PA0) | (1<<PA3) ); /* Interne Pull-Up fuer beide einschalten */<br />
</syntaxhighlight><br />
<br />
Bei bestimmten AVR Registern mit Bits, die durch Beschreiben mit einer logischen 1 gelöscht werden, muss eine absolute Zuweisung benutzt werden. Ein ODER löscht in diesen Registern ALLE gesetzten Bits!<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
TIFR2 = (1<<OCF2A); // Nur Bit OCF2A löschen<br />
</syntaxhighlight><br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind nicht mehr erforderlich.<br />
<br />
Siehe auch:<br />
* [[Bitmanipulation]]<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
<br />
== Lesen aus Registern ==<br />
<br />
Zum Lesen kann man auf Register einfach wie auf eine Variable zugreifen. In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Lesezugriff über die Funktion inp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt und inp() ist nicht mehr erforderlich.<br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdint.h><br />
<br />
uint8_t foo;<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
/* kopiert den Status der Eingabepins an PortB <br />
in die Variable foo: */<br />
foo = PINB; <br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Die Abfrage der Zustände von Bits erfolgt durch Einlesen des gesamten Registerinhalts und ausblenden der Bits deren Zustand nicht von Interesse ist. Einige Beispiele zum Prüfen ob Bits gesetzt oder gelöscht sind:<br />
<br />
<syntaxhighlight lang="c"><br />
#define MEINBIT0 0 <br />
#define MEINBIT2 2<br />
<br />
uint8_t i;<br />
<br />
extern test1();<br />
<br />
// Funkion test1 aufrufen, wenn Bit 0 in Register PINA gesetzt (1) ist<br />
i = PINA; // Inhalt in Arbeitsvariable<br />
i = i & 0x01; // alle Bits bis auf Bit 0 ausblenden (bitweise und)<br />
// falls das Bit gesetzt war, hat i den Inhalt 1<br />
if ( i != 0 ) { // Ergebnis ungleich 0 (wahr)? <br />
test1(); // dann muss Bit 0 in i gesetzt sein -> Funktion aufrufen<br />
}<br />
// verkürzt:<br />
if ( ( PINA & 0x01 ) != 0 ) {<br />
test1();<br />
}<br />
// nochmals verkürzt:<br />
if ( PINA & 0x01 ) {<br />
test1();<br />
}<br />
// mit definierter Bitnummer:<br />
if ( PINA & ( 1 << MEINBIT0 ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und/oder Bit 2 gesetzt ist. (Bit 0 und 2 also Wert 5) <br />
// (Bedenke: Bit 0 hat Wert 1, Bit 1 hat Wert 2 und Bit 2 hat Wert 4)<br />
if ( PINA & 0x05 ) {<br />
test1(); // Vergleich <> 0 (wahr), also mindestens eines der Bits gesetzt<br />
}<br />
// mit definierten Bitnummern:<br />
if ( PINA & ( ( 1 << MEINBIT0 ) | ( 1 << MEINBIT2 ) ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und Bit 2 gesetzt sind<br />
if ( ( PINA & 0x05 ) == 0x05 ) { // nur wahr, wenn beide Bits gesetzt<br />
test1();<br />
}<br />
<br />
// Funktion test2() aufrufen, wenn Bit 0 gelöscht (0) ist<br />
i = PINA; // einlesen in temporäre Variable<br />
i = i & 0x01; // maskieren von Bit 0<br />
if ( i == 0 ) { // Vergleich ist wahr, wenn Bit 0 nicht gesetzt ist<br />
test2();<br />
}<br />
// analog mit not-Operator<br />
if ( !i ) {<br />
test2();<br />
}<br />
// nochmals verkürzt:<br />
if ( !( PINA & 0x01 ) ) {<br />
test2();<br />
}<br />
</syntaxhighlight><br />
<br />
== Warten auf einen bestimmten Zustand ==<br />
<br />
Es gibt in der Bibliothek avr-libc Funktionen, die warten, bis ein bestimmter Zustand eines Bits erreicht ist. Es ist allerdings normalerweise eine eher unschöne Programmiertechnik, da in diesen Funktionen "blockierend" gewartet wird. Der Programmablauf bleibt also an dieser Stelle stehen, bis das maskierte Ereignis erfolgt ist. Setzt man den [[Watchdog]] ein, muss man darauf achten, dass dieser auch noch getriggert wird (Zurücksetzen des Watchdogtimers). <br />
<br />
Die Funktion '''loop_until_bit_is_set''' wartet in einer Schleife, bis das definierte Bit gesetzt ist. Wenn das Bit beim Aufruf der Funktion bereits gesetzt ist, wird die Funktion sofort wieder verlassen. Das niederwertigste Bit hat die Bitnummer 0. <br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 2 (das dritte Bit) in Register PINA gesetzt (1) ist */<br />
<br />
#define WARTEPIN PINA<br />
#define WARTEBIT PA2<br />
<br />
// mit der avr-libc Funktion:<br />
loop_until_bit_is_set(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// _nicht_ ungleich 0 (also 0) ist.<br />
while ( !(WARTEPIN & (1 << WARTEBIT)) ) {}<br />
...<br />
</syntaxhighlight><br />
<br />
<br />
Die Funktion '''loop_until_bit_is_clear''' wartet in einer Schleife, bis das definierte Bit gelöscht ist. Wenn das Bit beim Aufruf der Funktion bereits gelöscht ist, wird die Funktion sofort wieder verlassen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 4 (das fuenfte Bit) in Register PINB geloescht (0) ist */<br />
#define WARTEPIN PINB<br />
#define WARTEBIT PB4<br />
<br />
// avr-libc-Funktion:<br />
loop_until_bit_is_clear(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// gesetzt (1) ist <br />
while ( WARTEPIN & (1<<WARTEBIT) ) {}<br />
...<br />
</syntaxhighlight><br />
<br />
Universeller und auch auf andere Plattformen besser übertragbar ist die Verwendung von C-Standardoperationen.<br />
<br />
Siehe auch: <br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
* [[Bitmanipulation]]<br />
<br />
== 16-Bit Register (ADC, ICR1, OCR1x, TCNT1, UBRR) ==<br />
<br />
Einige der Portregister in den AVR-Controllern sind 16 Bit breit. Im Datenblatt sind diese Register üblicherweise mit dem Suffix "L" (Low-Byte) und "H" (High-Byte) versehen. Die avr-libc definiert zusätzlich die meisten dieser Variablen die Bezeichnung ohne "L" oder "H". Auf diese Register kann dann direkt zugegriffen werden. Dies ist zum Beispiel der Fall für Register wie ADC oder TCNT1.<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
uint16_t foo;<br />
<br />
/* setzt die Wort-Variable foo auf den Wert der letzten AD-Wandlung */<br />
foo = ADC; <br />
</syntaxhighlight><br />
<br />
Bei anderen Registern, wie zum Beispiel Baudraten-Register, liegen High- und Low-Teil nicht direkt nebeneinander im SFR-Bereich, so dass ein 16-Bit Zugriff nicht möglich ist und der Zugriff zusammengebastelt werden muss:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
...<br />
uint16_t baud = F_CPU / (UART_BAUD_RATE * 16L) -1;<br />
<br />
UBRRH = (uint8_t) (baud >> 8);<br />
UBRRL = (uint8_t) baud;<br />
...<br />
</syntaxhighlight><br />
<br />
Bei einigen AVR-Typen wie ATmega8 oder ATmega16 teilen sich UBRRH und UCSRC die gleiche Speicher-Adresse. Damit der AVR trotzdem zwischen den beiden Registern unterscheiden kann, bestimmt das Bit7 (URSEL), welches Register tatsächlich beschrieben werden soll. ''1000 0011'' (0x83) adressiert demnach UCSRC und übergibt den Wert ''3''. Und ''0000 0011'' (0x3) adressiert UBRRH und übergibt ebenfalls den Wert ''3''. <br />
<br />
Speziell bei den 16-Bit-Timern und auch beim ADC ist es bei allen Zugriffen auf Datenregister erforderlich, dass diese Daten synchronisiert sind. Wenn z.&nbsp;B. bei einem 16-Bit-Timer das High-Byte des Zählregisters gelesen wurde und vor dem Lesezugriff auf das Low-Byte ein Überlauf des Low-Bytes stattfindet, erhält man einen völlig unsinnigen Wert. Auch die Compare-Register müssen synchron geschrieben werden, da es ansonsten zu unerwünschten Compare-Ereignissen kommen kann. <br />
<br />
Beim ADC besteht das Problem darin, dass zwischen den Zugriffen auf die beiden Teilregister eine Wandlung beendet werden kann und der ADC ein neues Ergebnis in ADCL und ADCH schreiben will, wodurch High- und Low-Byte nicht zusammenpassen.<br />
<br />
Um diese Datenmüllproduktion zu verhindern, gibt es in beiden Fällen eine Synchronisation, die jeweils durch den Zugriff auf das Low-Byte ausgelöst wird:<br />
* Bei den Timer-Registern (das gilt für alle TCNT-, OCR- und ICR-Register bei den 16-Bit-Timern) wird bei einem ''Lesezugriff'' auf das Low-Byte automatisch das High-Byte in ein temporäres Register, das ansonsten nach außen nicht sichtbar ist, geschoben. Greift man nun ''anschließend'' auf das High-Byte zu, dann wird eben dieses temporäre Register gelesen.<br />
* Bei einem ''Schreibzugriff'' auf eines der genannten Register wird das High-Byte in besagtem temporären Register zwischengespeichert und erst beim Schreiben des Low-Bytes werden ''beide'' gleichzeitig in das eigentliche Register übernommen.<br />
<br />
Das bedeutet für die Reihenfolge:<br />
* Lesezugriff: Erst Low-Byte, dann High-Byte<br />
* Schreibzugriff: Erst High-Byte, dann Low-Byte<br />
<br />
Des weiteren ist zu beachten, dass es für all diese 16-Bit-Register nur ein einziges temporäres Register gibt, so dass das Auftreten eines Interrupts, in dessen Handler ein solches Register manipuliert wird, bei einem durch ihn unterbrochenen Zugriff i.d.R. zu Datenmüll führt. 16-Bit-Zugriffe sind generell nicht atomar! Wenn mit Interrupts gearbeitet wird, kann es erforderlich sein, vor einem solchen Zugriff auf ein 16-Bit-Register die Interrupt-Bearbeitung zu deaktivieren.<br />
<br />
Beim ADC-Datenregister ADCH/ADCL ist die Synchronisierung anders gelöst. Hier wird beim Lesezugriff (ADCH/ADCL sind logischerweise read-only) auf das Low-Byte ADCL beide Teilregister für Zugriffe seitens des ADC so lange gesperrt, bis das High-Byte ADCH ausgelesen wurde. Dadurch kann der ADC nach einem Zugriff auf ADCL keinen neuen Wert in ADCH/ADCL ablegen, bis ADCH gelesen wurde. Ergebnisse von Wandlungen, die zwischen einem Zugriff auf ADCL und ADCH beendet werden, gehen verloren!<br />
<br />
Nach einem Zugriff auf ADCL muss grundsätzlich ADCH gelesen werden!<br />
<br />
In beiden Fällen – also sowohl bei den Timern als auch beim ADC – werden vom C-Compiler 16-Bit Pseudo-Register zur Verfügung gestellt (z.&nbsp;B. TCNT1H/TCNT1L → TCNT1, ADCH/ADCL → ADC bzw. ADCW), bei deren Verwendung der Compiler automatisch die richtige Zugriffsreihenfolge regelt. In C-Programmen sollten grundsätzlich diese 16-Bit-Register verwendet werden! Sollte trotzdem ein Zugriff auf ein Teilregister erforderlich sein, sind obige Angaben zu berücksichtigen.<br />
<br />
Es ist darauf zu achten, dass auch ein Zugriff auf die 16-Bit-Register vom Compiler in zwei 8-Bit-Zugriffe aufgeteilt wird und dementsprechend genauso nicht-atomar ist wie die Einzelzugriffe. Auch hier gilt, dass u.U. die Interrupt-Bearbeitung gesperrt werden muss, um Datenmüll zu vermeiden.<br />
<br />
Beim ADC gibt es für den Fall, dass eine Auflösung von 8 Bit ausreicht, die Möglichkeit, das Ergebnis "linksbündig" in ADCH/ADCL auszurichten, so dass die relevanten 8 MSB in ADCH stehen. In diesem Fall muss bzw. sollte nur ADCH ausgelesen werden.<br />
<br />
ADC und ADCW sind unterschiedliche Bezeichner für das selbe Registerpaar. Üblicherweise kann man in C-Programmen ADC verwenden, was analog zu den anderen 16-Bit-Registern benannt ist. ADCW (ADC Word) existiert nur deshalb, weil die Headerdateien auch für Assembler vorgesehen sind und es bereits einen Assembler-Befehl namens ''adc'' gibt. <br />
<br />
Im Umgang mit 16-Bit Registern siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Related Pages/Frequently Asked Questions/Nr. 8<br />
* Datenblatt Abschnitt ''Accessing 16-bit Registers''<br />
<br />
== IO-Register als Parameter und Variablen ==<br />
<br />
Um Register als Parameter für eigene Funktionen übergeben zu können, muss man sie als einen volatile uint8_t Pointer übergeben. Zum Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <util/delay.h><br />
<br />
uint8_t key_pressed (volatile uint8_t *inputreg, uint8_t inputbit)<br />
{<br />
static uint8_t last_state = 0;<br />
<br />
if (last_state == (*inputreg & (1<<inputbit)))<br />
return 0; /* keine Änderung */<br />
<br />
/* Wenn doch, warten bis etwaiges Prellen vorbei ist: */<br />
_delay_ms(20);<br />
<br />
/* Zustand für nächsten Aufruf merken: */<br />
last_state = *inputreg & (1<<inputbit);<br />
<br />
/* und den entprellten Tastendruck zurückgeben: */<br />
return *inputreg & (1<<inputbit);<br />
}<br />
<br />
/* Beispiel für einen Funktionsaufruf: */<br />
<br />
void foo (void)<br />
{<br />
uint8_t i = key_pressed (&PINB, PB1);<br />
}<br />
</syntaxhighlight><br />
<br />
Ein Aufruf der Funktion mit call by value würde Folgendes bewirken: Beim Funktionseintritt wird nur eine Kopie des momentanen Portzustandes angefertigt, die sich unabhängig vom tatsächlichen Zustand das Ports nicht mehr ändert, womit die Funktion wirkungslos wäre. Die Übergabe eines Zeigers wäre die Lösung, wenn der Compiler nicht optimieren würde. Denn dadurch wird im Programm nicht von der Hardware gelesen, sondern wieder nur von einem Abbild im Speicher. Das Ergebnis wäre das gleiche wie oben. Mit dem Schlüsselwort volatile sagt man nun dem Compiler, dass die entsprechende Variable entweder durch andere Softwareroutinen (Interrupts) oder durch die Hardware verändert werden kann.<br />
<br />
Siehe auch: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass avr-libc FAQ: "How do I pass an IO port as a parameter to a function?"]<br />
<br />
= Zugriff auf IO-Ports =<br />
<br />
Jeder AVR implementiert eine unterschiedliche Menge an GPIO-Registern<br />
(GPIO - General Purpose Input/Output). Diese Register dienen dazu:<br />
* einzustellen welche der Anschlüsse ("Beinchen") des Controllers als Ein- oder Ausgänge dienen<br />
* bei Ausgängen deren Zustand festzulegen<br />
* bei Eingängen deren Zustand zu erfassen<br />
<br />
Mittels GPIO werden digitale Zustände gesetzt und erfasst, d.h. die Spannung an einem Ausgang wird ein- oder ausgeschaltet und an einem Eingang wird erfasst, ob die anliegende Spannung über oder unter einem bestimmten Schwellwert liegt. Im Datenblatt Abschnitt Electrical Characteristics/DC Characteristics finden sich die Spannungswerte (V_OL, V_OH für Ausgänge, V_IL, V_IH für Eingänge).<br />
<br />
Die Verarbeitung von analogen Eingangswerten und die Ausgabe von Analogwerten wird in Kapitel [[AVR-GCC-Tutorial#Analoge_Ein-_und_Ausgabe|Analoge Ein- und Ausgabe]] behandelt.<br />
<br />
Die physischen Ein- und Ausgänge werden bei AVR-Controllern zu logischen Ports gruppiert.<br />
<br />
Alle Ports werden über Register gesteuert. Dazu sind jedem Port 3 Register zugeordnet:<br />
<br />
{| class="wikitable"<br />
|- <br />
! width="10%"| DDRx<br />
| Datenrichtungsregister für Port'''x'''. <br />
'''x''' entspricht '''A''', '''B''', ''' C''' usw. je nach gewünschtem Port. Bit im Register gesetzt (1) für Ausgang, Bit gelöscht (0) für Eingang.<br />
|- <br />
! PINx<br />
| Eingangsadresse für Port'''x'''. <br />
Zustand des Ports. Die Bits in PINx entsprechen dem Zustand der als Eingang definierten Portpins. Bit 1 wenn Pin "high", Bit 0 wenn Portpin low.<br />
|-<br />
! PORTx<br />
| Datenregister für Port'''x'''. <br />
Dieses Register wird verwendet, um die Ausgänge eines Ports anzusteuern. Bei Pins, die mittels DDRx auf Eingang geschaltet wurden, können über PORTx<br />
die internen Pull-Up Widerstände aktiviert oder deaktiviert werden (1 = aktiv).<br />
|}<br />
<br />
Die folgenden Beispiele gehen von einem AVR aus, der sowohl Port A als auch Port B besitzt. Sie müssen für andere AVRs (zum Beispiel ATmega8/48/88/168) entsprechend angepasst werden.<br />
<br />
== Datenrichtung bestimmen ==<br />
<br />
Zuerst muss die Datenrichtung der verwendeten Pins bestimmt werden. Um dies zu erreichen, wird das Datenrichtungsregister des entsprechenden Ports beschrieben.<br />
<br />
Für jeden Pin, der als Ausgang verwendet werden soll, muss dabei das<br />
entsprechende Bit auf dem Port gesetzt werden. Soll der Pin als Eingang<br />
verwendet werden, muss das entsprechende Bit gelöscht sein.<br />
<br />
Beispiel:<br />
Angenommen am Port B sollen die Pins 0 bis 4 als Ausgänge definiert werden, die noch verbleibenden Pins 5 bis 7 sollen als Eingänge fungieren. Dazu ist es daher notwendig, im für das Port B zuständigen Datenrichtungsregister DDRB folgende Bitkonfiguration einzutragen<br />
<br />
+---+---+---+---+---+---+---+---+<br />
| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |<br />
+---+---+---+---+---+---+---+---+<br />
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br />
<br />
In C liest sich das dann so:<br />
<br />
<syntaxhighlight lang="c"><br />
// in io.h wird u.a. DDRB definiert:<br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binaer 00011111 = Hexadezimal 1F<br />
// direkte Zuweisung - standardkonform */<br />
DDRB = 0x1F; /* <br />
<br />
// Uebersichtliche Alternative - Binaerschreibweise, aber kein ISO-C<br />
DDRB = 0b00011111;<br />
<br />
// Ausfuehrliche Schreibweise: identische Funktionalitaet, mehr Tipparbeit<br />
// aber uebersichtlicher und selbsterklaerend:<br />
DDRB |= (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4); <br />
</syntaxhighlight><br />
<br />
Die Pins 5 bis 7 werden (da 0) als Eingänge geschaltet. Weitere Beispiele:<br />
<br />
<syntaxhighlight lang="c"><br />
// Alle Pins des Ports B als Ausgang definieren:<br />
DDRB = 0xff; <br />
// Pin0 wieder auf Eingang und andere im urspruenglichen Zustand belassen:<br />
DDRB &= ~(1 << DDB0);<br />
// Pin 3 und 4 auf Eingang und andere im urspruenglichen Zustand belassen:<br />
DDRB &= ~((1 << DDB3) | (1 << DDB4));<br />
// Pin 0 und 3 wieder auf Ausgang und andere im ursprünglichen Zustand belassen:<br />
DDRB |= (1 << DDB0) | (1 << DDB3);<br />
// Alle Pins auf Eingang:<br />
DDRB = 0x00;<br />
</syntaxhighlight><br />
<br />
== Vordefinierte Bitnummern für I/O-Register ==<br />
<br />
Die Bitnummern (z.&nbsp;B. PCx, PINCx und DDCx für den Port C) sind in den io*.h-Dateien der avr-libc definiert und dienen lediglich der besseren Lesbarkeit. Man muss diese Definitionen nicht verwenden oder kann auch einfach "immer" PAx, PBx, PCx usw. nutzen, auch wenn der Zugriff auf Bits in DDRx- oder PINx-Registern erfolgt. Für den Compiler sind die Ausdrücke (1<<PC7), (1<<DDC7) und (1<<PINC7) identisch zu (1<<7) (genauer: der Präprozessor ersetzt die Ausdrücke (1<<PC7),... zu (1<<7)). Ein Ausschnitt der Definitionen für Port C eines ATmega32 aus der iom32.h-Datei zur Verdeutlichung (analog für die weiteren Ports):<br />
<br />
<syntaxhighlight lang="c"><br />
...<br />
/* PORTC */<br />
#define PC7 7<br />
#define PC6 6<br />
#define PC5 5<br />
#define PC4 4<br />
#define PC3 3<br />
#define PC2 2<br />
#define PC1 1<br />
#define PC0 0<br />
<br />
/* DDRC */<br />
#define DDC7 7<br />
#define DDC6 6<br />
#define DDC5 5<br />
#define DDC4 4<br />
#define DDC3 3<br />
#define DDC2 2<br />
#define DDC1 1<br />
#define DDC0 0<br />
<br />
/* PINC */<br />
#define PINC7 7<br />
#define PINC6 6<br />
#define PINC5 5<br />
#define PINC4 4<br />
#define PINC3 3<br />
#define PINC2 2<br />
#define PINC1 1<br />
#define PINC0 0<br />
</syntaxhighlight><br />
<br />
<br />
== Digitale Signale ==<br />
<br />
Am einfachsten ist es, digitale Signale mit dem Mikrocontroller zu erfassen bzw. auszugeben.<br />
<br />
== Ausgänge ==<br />
Will man als Ausgang definierte Pins (entsprechende DDRx-Bits = 1) auf Logisch 1 setzen, setzt man die entsprechenden Bits im Portregister.<br />
<br />
Mit dem Befehl<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB = 0x04; /* besser PORTB=(1<<PB2) */<br />
<br />
// Uebersichtliche Alternative - Binaerschreibweise<br />
PORTB = 0b00000100; /* direkte Zuweisung - uebersichtlich */<br />
<br />
</syntaxhighlight><br />
wird also der Ausgang an Pin PB2 gesetzt (Beachte, dass die Bits immer ''von 0 an'' gezählt werden, das niederwertigste Bit ist also Bitnummer 0 und nicht etwa Bitnummer 1).<br />
<br />
Man beachte, dass bei der Zuweisung mittels '''=''' immer alle Pins gleichzeitig angegeben werden. Man sollte also, wenn nur bestimmte Ausgänge geschaltet werden sollen, zuerst den aktuellen Wert des Ports einlesen und das Bit des gewünschten Ports in diesen Wert einfließen lassen. Will man also nur den dritten Pin (Bit Nr. 2) an Port B auf "high" setzen und den Status der anderen Ausgänge unverändert lassen, nutze man diese Form:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB = PORTB | 0x04; /* besser: PORTB = PORTB | ( 1<<PB2 ) */<br />
/* vereinfacht durch Nutzung des |= Operators : */<br />
PORTB |= (1<<PB2);<br />
<br />
/* auch mehrere "gleichzeitig": */<br />
PORTB |= (1<<PB4) | (1<<PB5); /* Pins PB4 und PB5 "high" */<br />
</syntaxhighlight><br />
<br />
"Ausschalten", also Ausgänge auf "low" setzen, erfolgt analog:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB &= ~(1<<PB2); /* loescht Bit 2 in PORTB und setzt damit Pin PB2 auf low */ <br />
PORTB &= ~( (1<<PB4) | (1<<PB5) ); /* Pin PB4 und Pin PB5 "low" */<br />
</syntaxhighlight><br />
Siehe auch [[Bitmanipulation]]<br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind in aktuellen Versionen der avr-libc nicht mehr enthalten und auch nicht mehr erforderlich.<br />
<br />
''Falls der Anfangszustand von Ausgängen kritisch ist, muss die Reihenfolge beachtet werden, mit der die Datenrichtung (DDRx) eingestellt und der Ausgabewert (PORTx) gesetzt wird:''<br />
<br />
Für Ausgangspins, die mit Anfangswert "high" initialisiert werden sollen:<br />
* zuerst die Bits im PORTx-Register setzen<br />
* anschließend die Datenrichtung auf Ausgang stellen<br />
<br />
Daraus ergibt sich die Abfolge für einen Pin, der bisher als Eingang mit abgeschaltetem Pull-Up konfiguriert war:<br />
* setze PORTx: interner Pull-Up aktiv<br />
* setze DDRx: Ausgang ("high")<br />
<br />
Bei der Reihenfolge erst DDRx und dann PORTx kann es zu einem kurzen "low-Puls" kommen, der auch externe Pull-Up-Widerstände "überstimmt". Die (ungünstige) Abfolge: Eingang -> setze DDRx: Ausgang (auf "low", da PORTx nach Reset 0) -> setze PORTx: Ausgang auf high. Vergleiche dazu auch das Datenblatt Abschnitt ''Configuring the Pin''.<br />
<br />
== Eingänge (Wie kommen Signale in den &micro;C) ==<br />
<br />
Die digitalen Eingangssignale können auf verschiedene Arten zu unserer Logik gelangen.<br />
<br />
=== Signalkopplung ===<br />
<br />
Am einfachsten ist es, wenn die Signale direkt aus einer anderen digitalen Schaltung übernommen werden können. Hat der Ausgang der entsprechenden Schaltung TTL-Pegel dann können wir sogar direkt den Ausgang der Schaltung mit einem Eingangspin von unserem Controller verbinden.<br />
<br />
Hat der Ausgang der anderen Schaltung keinen TTL-Pegel so müssen wir den Pegel über entsprechende Hardware (z.&nbsp;B. Optokoppler, [[Widerstand#Spannungsteiler|Spannungsteiler]], "Levelshifter" aka [[Pegelwandler]]) anpassen.<br />
<br />
Die Masse der beiden Schaltungen muss selbstverständlich miteinander verbunden werden. Der Software selber ist es natürlich letztendlich egal, wie das Signal eingespeist wird. Wir können ja ohnehin lediglich prüfen, ob an einem Pin unseres Controllers eine logische 1 (Spannung größer ca. 0,7*Vcc) oder eine logische 0 (Spannung kleiner ca. 0,2*Vcc) anliegt. Detaillierte Informationen darüber, ab welcher Spannung ein Eingang als 0 ("low") bzw. 1 ("high") erkannt wird, liefert die Tabelle DC Characteristics im Datenblatt des genutzten Controllers.<br />
<br />
{| class="wikitable" style="text-align:center; width:20em"<br />
|+ '''Logikpegel'''<br />
|-<br />
! VCC [V]<br />
! Low [V]<br />
! High [V]<br />
|-<br />
! 5<br />
| 1,0 || 3,5<br />
|-<br />
! 3,3<br />
| 0,66 || 2,3<br />
|-<br />
! 1,8<br />
| 0,36 || 1,26 <br />
|}<br />
<br />
Die Abfrage der Zustände der Portpins erfolgt direkt über den Registernamen.<br />
<br />
{{Warnung|Dabei ist wichtig, zur Abfrage der Eingänge ''nicht'' etwa Portregister '''PORTx''' zu verwenden, sondern Eingangsregister '''PINx'''. Ansonsten liest man nicht den Zustand der Eingänge, sondern den Status der internen Pull-Up-Widerstände. Die Abfrage der Pinzustände über PORTx statt PINx ist ein häufiger Fehler beim AVR-"Erstkontakt".}}<br />
<br />
Will man also die aktuellen Signalzustände von Port D abfragen und in eine Variable namens bPortD abspeichern, schreibt man folgende Befehlszeilen:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdint.h><br />
...<br />
uint8_t bPortD;<br />
...<br />
bPortD = PIND;<br />
...<br />
</syntaxhighlight><br />
<br />
Mit den C-Bitoperationen kann man den Status der Bits abfragen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
/* Fuehre Aktion aus, wenn Bit Nr. 1 (das "zweite" Bit) in PINC gesetzt (1) ist */<br />
if ( PINC & (1<<PINC1) ) {<br />
/* Aktion */<br />
}<br />
<br />
/* Fuehre Aktion aus, wenn Bit Nr. 2 (das "dritte" Bit) in PINB geloescht (0) ist */<br />
if ( !(PINB & (1<<PINB2)) ) {<br />
/* Aktion */<br />
}<br />
...<br />
</syntaxhighlight><br />
Siehe auch [[Bitmanipulation#Bits_prüfen]]<br />
<br />
=== Interne Pull-Up Widerstände ===<br />
<br />
Portpins für Ein- und Ausgänge (GPIO) eines AVR verfügen über zuschaltbare interne Pull-Up Widerstände (nominal mehrere 10kOhm, z.&nbsp;B. ATmega16 20-50kOhm). Diese können in vielen Fällen statt externer Widerstände genutzt werden.<br />
<br />
Die internen Pull-Up Widerstände von Vcc zu den einzelnen Portpins werden über das Register ''' PORTx''' aktiviert bzw. deaktiviert, wenn ein Pin als ''' Eingang''' geschaltet ist.<br />
<br />
Wird der Wert des entsprechenden Portpins auf 1 gesetzt, so ist der Pull-Up Widerstand aktiviert. Bei einem Wert von 0 ist der Pull-Up Widerstand nicht aktiv. Man sollte jeweils entweder den internen oder einen externen Pull-Up Widerstand verwenden, aber nicht beide zusammen.<br />
<br />
Im Beispiel werden alle Pins des Ports D als Eingänge geschaltet und alle Pull-Up Widerstände aktiviert. Weiterhin wird Pin PC7 als Eingang geschaltet und dessen interner Pull-Up Widerstand aktiviert, ohne die Einstellungen für die anderen Portpins (PC0-PC6) zu verändern.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
DDRD = 0x00; /* alle Pins von Port D als Eingang */<br />
PORTD = 0xff; /* interne Pull-Ups an allen Port-Pins aktivieren */<br />
...<br />
DDRC &= ~(1<<PC7); /* Pin PC7 als Eingang */<br />
PORTC |= (1<<PC7); /* internen Pull-Up an PC7 aktivieren */<br />
</syntaxhighlight><br />
<br />
=== Taster und Schalter ===<br />
<br />
Der Anschluss mechanischer Kontakte an den Mikrocontroller, ist zwischen zwei unterschiedliche Methoden zu unterscheiden: ''Active Low'' und ''Active High''.<br />
<br />
<gallery widths="300" heights="300" caption="Anschluss mechanischer Kontakte an einen µC"><br />
Image:Active Low.gif|'''Active Low:''' Bei dieser Methode wird der Kontakt zwischen den Eingangspin des Controllers und Masse geschaltet. Damit bei offenem Schalter der Controller kein undefiniertes Signal bekommt, wird zwischen die Versorgungsspannung und den Eingangspin ein sogenannter '''Pull-Up''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffnetem Schalter auf logisch 1 zu ziehen.<br />
Image:Active High.gif|'''Active High:''' Hier wird der Kontakt zwischen die Versorgungsspannung und den Eingangspin geschaltet. Damit bei offener Schalterstellung kein undefiniertes Signal am Controller ansteht, wird zwischen den Eingangspin und die Masse ein '''Pull-Down''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffneter Schalterstellung auf logisch 0 zu halten. <br />
</gallery><br />
<br />
Der Widerstandswert von Pull-Up- und Pull-Down-Widerständen ist an sich nicht kritisch. Wird er allerdings zu hoch gewählt, ist die Wirkung eventuell nicht gegeben. Als üblicher Wert haben sich 10 kOhm eingebürgert. Die AVRs verfügen an den meisten Pins über zuschaltbare interne Pull-Up Widerstände (vgl. Abschnitt [[AVR-GCC-Tutorial#Interne Pull-Up Widerstände|Interne Pull-Up Widerstände]]), welche insbesondere wie hier bei Tastern und ähnlichen Bauteilen (z.&nbsp;B. Drehgebern) statt externer Bauteile verwendet werden können. Interne Pull-Down-Widerstand sind nicht verfügbar und müssen daher in Form zusätzlicher Bauteile in die Schaltung eingefügt werden.<br />
<br />
==== Taster entprellen ====<br />
<br />
Siehe: ''[[Entprellung#Warteschleifen-Verfahren|Entprellung: Warteschleifen-Verfahren]]<br />
<br />
= Warteschleifen (delay.h) =<br />
<br />
Der Programmablauf kann verschiedene Arten von Wartefunktionen erfordern:<br />
<br />
* Warten im Sinn von Zeitvertrödeln<br />
* Warten auf einen bestimmten Zustand an den I/O-Pins<br />
* Warten auf einen bestimmten Zeitpunkt (siehe Timer)<br />
* Warten auf einen bestimmten Zählerstand (siehe Counter)<br />
<br />
Der einfachste Fall, das Zeitvertrödeln, kann in vielen Fällen und mit großer Genauigkeit anhand der avr-libc Bibliotheksfunktionen _delay_ms() und _delay_us() erledigt werden. Die Bibliotheksfunktionen sind einfachen Zählschleifen (Warteschleifen) vorzuziehen, da leere Zählschleifen ohne besondere Vorkehrungen sonst bei eingeschalteter Optimierung vom avr-gcc-Compiler wegoptimiert werden. Weiterhin sind die Bibliotheksfunktionen bereits darauf vorbereitet, die in F_CPU definierte Taktfrequenz zu verwenden. Außerdem sind die Funktionen der Bibliothek wirklich getestet.<br />
<br />
Einfach!? Schon, aber während gewartet wird, macht der µC nichts anderes mehr (abgesehen von möglicherweise auftretenden Interrupts, falls welche aktiviert sind). Die Wartefunktion blockiert den Programmablauf. Möchte man einerseits warten, um z.&nbsp;B. eine LED blinken zu lassen und gleichzeitig andere Aktionen ausführen z.&nbsp;B. weitere LED bedienen, sollten die Timer/Counter des AVR verwendet werden, siehe Artikel [[Multitasking]].<br />
<br />
Die Bibliotheksfunktionen funktionieren allerdings nur dann korrekt, wenn sie mit zur Übersetzungszeit (beim Compilieren) bekannten konstanten Werten aufgerufen werden. Der Quellcode muss mit eingeschalteter Optimierung übersetzt werden, sonst wird sehr viel Maschinencode erzeugt, und die Wartezeiten stimmen nicht mehr mit dem Parameter überein.<br />
<br />
Eine weitere Einschränkung liegt darin, daß sie möglicherweise länger warten, als erwartet, nämlich in dem Fall, daß Interrupts auftreten und die _delay...()-Funktion unterbrechen. Genau genommen warten diese nämlich nicht eine bestimmte Zeit, sondern verbrauchen eine bestimmte Anzahl von Prozessortakten. Die wiederum ist so bemessen, daß ohne Unterbrechung durch Interrupts die gewünschte Wartezeit erreicht wird.<br />
Wird das Warten aber durch eine oder mehrere ISR unterbrochen, die zusammen 1% Prozessorzeit verbrauchen, dann dauert das Warten etwa 1% länger. Bei 50% Last durch die ISR dauert das Warten doppelt solange wie gewünscht, bei 90% zehnmal solange...<br />
<br />
Abhängig von der Version der Bibliothek verhalten sich die Bibliotheksfunktionen etwas unterschiedlich.<br />
<br />
== avr-libc Versionen bis 1.6 ==<br />
<br />
Die Wartezeit der Funktion _delay_ms() ist auf 262,14ms/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 13,1ms warten. Die Wartezeit der Funktion _delay_us() ist auf 768us/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 38,4µs warten. Längere Wartezeiten müssen dann über einen mehrfachen Aufruf in einer Schleife gelöst werden.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.&nbsp;B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h> /* in älteren avr-libc Versionen <avr/delay.h> */ <br />
<br />
/*<br />
lange, variable Verzögerungszeit, Einheit in Millisekunden<br />
<br />
Die maximale Zeit pro Funktionsaufruf ist begrenzt auf <br />
262.14 ms / F_CPU in MHz (im Beispiel: <br />
262.1 / 3.6864 = max. 71 ms) <br />
<br />
Daher wird die kleine Warteschleife mehrfach aufgerufen,<br />
um auf eine längere Wartezeit zu kommen. Die zusätzliche <br />
Prüfung der Schleifenbedingung lässt die Wartezeit geringfügig<br />
ungenau werden (macht hier vielleicht 2-3ms aus).<br />
*/<br />
<br />
void long_delay(uint16_t ms)<br />
{<br />
for(; ms>0; ms--) _delay_ms(1);<br />
}<br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) // Endlosschleife<br />
{ <br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.&nbsp;B. angeschlossene LED<br />
long_delay(1000); // Eine Sekunde warten...<br />
}<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
== avr-libc Versionen ab 1.7 ==<br />
<br />
_delay_ms() kann mit einem Argument bis 6553,5 ms (= 6,5535 Sekunden) benutzt werden. Es ist nicht möglich, eine Variable als Argument zu übergeben. Wird die früher gültige Grenze von 262,14 ms/F_CPU (in MHz) überschritten, so arbeitet _delay_ms() einfach etwas ungenauer und zählt nur noch mit einer Auflösung von 1/10 ms. Eine Verzögerung von 1000,10 ms ließe sich nicht mehr von einer von 1000,19 ms unterscheiden. Ein Verlust, der sich im Allgemeinen verschmerzen lässt. Dem Programmierer wird keine Rückmeldung gegeben, dass die Funktion ggf. gröber arbeitet, d.h. wenn es darauf ankommt, bitte den Parameter wie bisher geschickt wählen.<br />
<br />
Die Funktion _delay_us() wurde ebenfalls erweitert. Wenn deren maximal als genau behandelbares Argument überschritten wird, benutzt diese intern _delay_ms(). Damit gelten in diesem Fall die _delay_ms() Einschränkungen.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus, avr-libc ab Version 1.6<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h><br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) { // Endlosschleife<br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED<br />
_delay_ms(1000); // Eine Sekunde +/-1/10000 Sekunde warten...<br />
// funktioniert nicht mit Bibliotheken vor 1.6<br />
<br />
}<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
Die _delay_ms() und die _delay_us aus '''avr-libc 1.7.0''' sind fehlerhaft. _delay_ms () läuft 4x schneller als erwartet. Abhilfe ist eine korrigierte Includedatei: [http://www.mikrocontroller.net/topic/196738#1943039]<br />
<br />
= Programmieren mit Interrupts =<br />
<br />
<div style="float:right; margin:2em;"><br />
[[Image:Interrupt Programme.gif]]<br />
</div><br />
Nachdem wir nun alles Wissenswerte für die serielle Programmerstellung<br />
gelernt haben nehmen wir jetzt ein völlig anderes Thema in Angriff, nämlich<br />
die Programmierung unter Zuhilfenahme der Interrupts des AVR.<br />
<br />
Tritt ein Interrupt auf, unterbricht (engl. interrupts) der Controller die Verarbeitung des Hauptprogramms und verzweigt zu einer Interruptroutine. Das Hauptprogramm wird also beim Eintreffen eines Interrupts unterbrochen, die Interruptroutine ausgeführt und danach erst wieder das Hauptprogramm an der Unterbrechungsstelle fortgesetzt (vgl. die Abbildung).<br />
<br />
Um Interrupts verarbeiten zu können, ist folgendes zu beachten:<br />
<br />
* Für jede aktivierte Interruptquelle ist eine Funktion zu programmieren, in der die beim Auftreten des jeweiligen Interrupts erforderlichen Verarbeitungsschritte enthalten sind. Für diese Funktion existieren verschiedene Bezeichnungen. Üblich sind die englischen Begriffe Interrupt-Handler oder Interrupt-Service-Routinen (ISR), man findet aber auch die Bezeichnungen Interruptverarbeitungs- oder -behandlungsroutine oder auch kurz Interruptroutine. Zum Beispiel wird üblicherweise in der ISR zur Verarbeitung des Empfangsinterrupts eines UARTs (UART-RX Interrupt) das empfangene Zeichen in einen Zwischenspeicher (FIFO-Buffer) kopiert, dessen Inhalt später von anderen Programmteilen geleert wird. Sofern der Zwischenspeicher ausreichend groß ist, geht also kein Zeichen verloren, auch wenn im Hauptprogramm zeitintensive Operationen durchgeführt werden.<br />
* Die benötigten Interrupts sind in den jeweiligen Funktionsbausteinen einzuschalten. Dies erfolgt über das jeweilige Aktivierungsbit (Interrupt Enable) in einem der Hardwareregister (z.B. RX(Complete)Interrupt Enable eines UARTs)<br />
* Sämtliche Interrupts werden über einen weiteren globalen Schalter aktiviert und deaktiviert. Zur Verarbeitung der Interrupts ist dieser Schalter zu aktivieren (sei(), siehe unten).<br />
<br />
Alle Punkte sind zu beachten. Fehlt z.B. die globale Aktivierung, werden Interruptroutinen auch dann nicht aufgerufen, wenn sie im Funktionsbaustein eingeschaltet sind und eine Behandlungsroutine verhanden ist.<br />
<br />
Siehe auch<br />
<br />
* [http://www.mikrocontroller.net/forum/read-1-235092.html#new Ausführlicher Thread im Forum]<br />
* Artikel [[Interrupt]]<br />
* Artikel [[Multitasking]]<br />
{{Clear}}<br />
<br />
== Anforderungen an Interrupt-Routinen ==<br />
<br />
Um unliebsamen Überraschungen vorzubeugen, sollten einige Grundregeln bei der Implementierung der Interruptroutinen beachtet werden. Interruptroutinen sollten möglichst kurz und schnell abarbeitbar sein, daraus folgt:<br />
<br />
* Keine umfangreichen Berechnungen innerhalb der Interruptroutine. (*)<br />
* Keine langen Programmschleifen.<br />
* Obwohl es möglich ist, während der Abarbeitung einer Interruptroutine andere oder sogar den gleichen Interrupt wieder zuzulassen, wird davon ohne genaue Kenntnis der internen Abläufe dringend abgeraten.<br />
<br />
Interruptroutinen (ISRs) sollten also möglichst kurz sein und keine Schleifen mit vielen Durchläufen enthalten. Längere Operationen können meist in einen "Interrupt-Teil" in einer ISR und einen "Arbeitsteil" im Hauptprogramm aufgetrennt werden. Z.B. Speichern des Zustands aller Eingänge im EEPROM in bestimmten Zeitabständen: ISR-Teil: Zeitvergleich (Timer,RTC) mit Logzeit/-intervall. Bei Übereinstimmung ein globales Flag setzen (volatile bei Flag-Deklaration nicht vergessen, s.u.). Dann im Hauptprogramm prüfen, ob das Flag gesetzt ist. Wenn ja: die Daten im EEPROM ablegen und Flag löschen.<br />
<br />
(*)<br />
Hinweis: <br />
Es gibt allerdings die seltene Situation, dass man gerade eingelesene<br />
ADC-Werte sofort verarbeiten muss. Besonders dann, wenn man mehrere Werte sehr<br />
schnell hintereinander bekommt. Dann bleibt einem nichts anderes übrig, als die<br />
Werte noch in der ISR zu verarbeiten. Kommt aber sehr selten vor und sollte<br />
durch geeignete Wahl des Systemtaktes bzw. Auswahl des Controllers vermieden werden!<br />
<br />
== Interrupt-Quellen ==<br />
<br />
Die folgenden Ereignisse können einen Interrupt auf einem AVR AT90S2313 auslösen, wobei die Reihenfolge der Auflistung auch die Priorität der Interrupts aufzeigt.<br />
<br />
* Reset<br />
* Externer Interrupt 0<br />
* Externer Interrupt 1<br />
* Timer/Counter 1 Capture Ereignis<br />
* Timer/Counter 1 Compare Match<br />
* Timer/Counter 1 Überlauf<br />
* Timer/Counter 0 Überlauf<br />
* UART Zeichen empfangen<br />
* UART Datenregister leer<br />
* UART Zeichen gesendet<br />
* Analoger Komparator<br />
<br />
Die Anzahl der möglichen Interruptquellen variiert zwischen den verschiedenen Microcontroller-Typen. Im Zweifel hilft ein Blick ins Datenblatt ("Interrupt Vectors").<br />
<br />
== Register ==<br />
<br />
Der AT90S2313 verfügt über 2 Register die mit den<br />
Interrupts zusammenhängen.<br />
<br />
{| class="wikitable"<br />
|- <br />
!width="10%"| GIMSK<br />
| '''G'''eneral '''I'''nterrupt '''M'''a'''sk''' Register.<br /><br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit <br />
| 7 || 6|| 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INT1''' || '''INT0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INT1''' (External '''Int'''errupt Request '''1''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT1'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
'''INT0''' (External '''Int'''errupt Request '''0''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT0'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
|- <br />
! GIFR<br />
| '''G'''eneral '''I'''nterrupt '''F'''lag '''R'''egister.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INTF1''' || '''INTF0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INTF1''' (External '''Int'''errupt Flag '''1''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT1'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
<br />
'''INTF0''' (External '''Int'''errupt Flag '''0''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT0'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
|- <br />
! MCUCR<br />
| '''MCU''' '''C'''ontrol '''R'''egister.<br />
<br />
Das MCU Control Register enthält Kontrollbits für allgemeine MCU-Funktionen.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''-'''|| '''-'''|| '''SE'''|| '''SM'''|| '''ISC11'''|| '''ISC10'''|| '''ISC01'''|| '''ISC00'''<br />
|- <br />
! R/W<br />
| R || R || R/W || R/W || R/W || R/W || R/W || R/W<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
<br />
|}<br />
<br />
'''SE''' ('''S'''leep '''E'''nable)<br />
:Dieses Bit muss gesetzt sein, um den Controller mit dem '''SLEEP'''-Befehl in den Schlafzustand versetzen zu können.<br />
:Um den Schlafmodus nicht irrtümlich einzuschalten, wird empfohlen, das Bit erst unmittelbar vor Ausführung des '''SLEEP'''-Befehls zu setzen.<br />
<br />
'''SM''' ('''S'''leep '''M'''ode)<br />
:Dieses Bit bestimmt über den Schlafmodus.<br />
:Ist das Bit gelöscht, so wird der '''Idle'''-Modus ausgeführt. Ist das Bit gesetzt, so wird der '''Power-Down'''-Modus ausgeführt. (für andere AVR Controller siehe Abschnitt "Sleep-Mode")<br />
<br />
'''ISC11''', '''ISC10''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''1''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT1'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
!width="10%"| ISC11 ||width="10%"| ISC10 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT1''' erzeugt einen Interrupt.<br />
<br />
Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|}<br />
<br />
'''ISC01''', '''ISC00''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''0''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT0'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
!width="10%"| ISC01 ||width="10%"| ISC00 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT0''' erzeugt einen Interrupt.<br />
<br />
Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|}<br />
<br />
|}<br />
<br />
== Allgemeines über die Interrupt-Abarbeitung ==<br />
<br />
Wenn ein Interrupt eintrifft, wird automatisch das '''Global Interrupt Enable''' Bit im Status Register '''SREG''' gelöscht und alle weiteren Interrupts unterbunden. Dieses wird automatisch wieder gesetzt, wenn die Interruptroutine beendet wird. Wenn in der Zwischenzeit weitere Interrupts eintreffen, werden die zugehörigen Interrupt-Bits gesetzt und die Interrupts bei Beendigung der laufenden Interrupt-Routine in der Reihenfolge ihrer Priorität ausgeführt. Dies kann<br />
eigentlich nur dann zu Problemen führen, wenn ein hoch priorisierter Interrupt ständig und in kurzer Folge auftritt. Dieser sperrt dann möglicherweise alle anderen Interrupts mit niedrigerer Priorität. Dies ist einer der Gründe, weshalb die Interrupt-Routinen sehr kurz gehalten werden sollen. Es ist möglich das GIE-Bit in der ISR zu setzen und so schon wieder weitere Interrupts zuzulassen - allerdings sollte man damit vorsichtig sein und genau wissen was man damit macht. Kritisch wird es vor allem wenn der gleiche Interrupt noch einmal kommt, bevor die ISR abgearbeitet ist. <br />
<br />
<!-- === Das Status-Register ===<br />
<br />
Es gilt auch zu beachten, dass das Status-Register während der Abarbeitung einer Interruptroutine nicht automatisch gesichert wird. Falls notwendig, muss dies vom Programmierer selber vorgesehen werden. --><br />
<br />
== Interrupts mit avr-gcc ==<br />
<br />
<!-- ''Anmerkung eines Nutzers: Ich habe mir das Thema hier angearbeitet und hatte am Anfang starke Probleme: Jeder Interrupt muss nochmals einzeln aktiviert werden. Es reicht nicht nur per ''sei()'' die Interrupts global zu aktiveren.'' - mthomas: Hoffentlich duch die modifizerte Einleitung etwas offensichtlicher erläutert. Ansonsten bitte per Eintrag auf die Diskussionseite nochmals melden) --> <br />
<!-- Selbstverständlich können alle interruptspezifischen Registerzugriffe wie gewohnt über I/O-Adressierung vorgenommen werden. Etwas einfacher geht es jedoch, wenn wir die vom Compiler zur Verfügung gestellten Mittel einsetzen.--><br />
Funktionen zur Interrupt-Verarbeitung werden in den Includedateien ''interrupt.h'' der avr-libc zur Verfügung gestellt (bei älterem Quellcode zusätzlich ''signal.h'').<br />
<br />
<syntaxhighlight lang="c"><br />
// fuer sei(), cli() und ISR():<br />
#include <avr/interrupt.h><br />
</syntaxhighlight><br />
<br />
Das Makro '''sei()''' schaltet die Interrupts ein. Eigentlich wird nichts anderes gemacht, als das '''Global Interrupt Enable''' Bit im Status Register gesetzt.<br />
<br />
<syntaxhighlight lang="c"><br />
sei();<br />
</syntaxhighlight><br />
<br />
Das Makro '''cli()''' schaltet die Interrupts aus, oder anders gesagt, das '''Global Interrupt Enable''' Bit im Status Register wird gelöscht.<br />
<br />
<syntaxhighlight lang="c"><br />
cli();<br />
</syntaxhighlight><br />
<br />
Oft steht man vor der Aufgabe, dass eine Codesequenz nicht unterbrochen werden darf. Es liegt dann nahe, zu Beginn dieser Sequenz ein cli() und am Ende ein sei() einzufügen. Dies ist jedoch ungünstig, wenn die Interrupts vor Aufruf der Sequenz deaktiviert waren und danach auch weiterhin deaktiviert bleiben sollen. Ein sei() würde ungeachtet des vorherigen Zustands die Interrupts aktivieren, was zu unerwünschten Seiteneffekten führen kann. Die aus dem folgenden Beispiel ersichtliche Vorgehensweise ist in solchen Fällen vorzuziehen:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <inttypes.h><br />
<br />
//...<br />
<br />
void NichtUnterbrechenBitte(void)<br />
{<br />
uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister<br />
<br />
tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) sichern<br />
cli(); // Interrupts global deaktivieren<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
/* Beispiel Anfang<br />
JTAG-Interface eines ATmega16 per Software deaktivieren <br />
und damit die JTAG-Pins an PORTC für "general I/O" nutzbar machen<br />
ohne die JTAG-Fuse-Bit zu aendern. Dazu ist eine "timed sequence"<br />
einzuhalten (vgl Datenblatt ATmega16, Stand 10/04, S. 229): <br />
Das JTD-Bit muss zweimal innerhalb von 4 Taktzyklen geschrieben <br />
werden. Ein Interrupt zwischen den beiden Schreibzugriffen wuerde <br />
die erforderliche Sequenz "brechen", das JTAG-Interface bliebe<br />
weiterhin aktiv und die IO-Pins weiterhin für JTAG reserviert. */<br />
<br />
MCUCSR |= (1<<JTD);<br />
MCUCSR |= (1<<JTD); // 2 mal in Folge ,vgl. Datenblatt fuer mehr Information<br />
<br />
/* Beispiel Ende */<br />
<br />
SREG = tmp_sreg; // Status-Register wieder herstellen <br />
// somit auch das I-Flag auf gesicherten Zustand setzen<br />
}<br />
<br />
void NichtSoGut(void)<br />
{<br />
cli();<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
sei();<br />
}<br />
<br />
<br />
int main(void)<br />
{<br />
//...<br />
<br />
cli(); <br />
// Interrupts global deaktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// auch nach Aufruf der Funktion deaktiviert<br />
<br />
sei();<br />
// Interrupts global aktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// weiterhin aktiviert<br />
//...<br />
<br />
/* Verdeutlichung der unguenstigen Vorgehensweise mit cli/sei: */<br />
cli(); <br />
// Interrupts jetzt global deaktiviert <br />
<br />
NichtSoGut();<br />
// nach Aufruf der Funktion sind Interrupts global aktiviert <br />
// dies ist mglw. ungewollt!<br />
//...<br />
<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
<!-- mt: besser so nicht(?), lieber "datenblattkonform"<br />
<br />
<font face="Courier New">'''timer_enable_int (unsigned char ints);<br /><br />
'''</font>Schaltet Timerbezogene Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle<br />
Timerinterrupts ausgeschaltet, ansonsten muss in '''ints''' angegeben werden,<br />
welche Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">timer_enable_int (1 << TOIE1));<br /><br />
</font>'''Achtung: Wenn ein Timerinterrupt eingeschaltet wird während ein<br />
anderer Timerinterrupt bereits läuft, dann müssen beide Bits angegeben werden<br />
sonst wird der andere Timerinterrupt versehentlich ausgeschaltet.<br />
<br />
<font face="Courier New">'''enable_external_int (unsigned char ints);<br /><br />
'''</font>Schaltet die externen Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle externen<br />
Interrrups ausgeschaltet, ansonsten muss in '''ints''' angegeben werden, welche<br />
Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">enable_external_int ((1<<br />
</font>'''Schaltet die externen Interrupts 0 und 1 ein.<br />
<br />
Nachdem nun die Interrupts aktiviert sind, braucht es selbstverständlich noch den auszuführenden Code, der ablaufen soll, wenn ein Interrupt eintrifft.<br />
--><br />
Zu den aktivierten Interrupts ist eine Funktion zu programmieren, deren Code aufgerufen wird, wenn der betreffende Interrupt auftritt (Interrupt-Handler, Interrupt-Service-Routine). Dazu existiert die Definition (ein Makro) '''ISR'''.<br />
<br />
=== ISR ===<br />
<br />
(''ISR()'' ersetzt bei neueren Versionen der avr-libc ''SIGNAL()''. SIGNAL sollte nicht mehr genutzt werden, zur Portierung von SIGNAL nach ISR siehe den [[AVR-GCC-Tutorial#Anhang|Anhang]].)<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
//...<br />
ISR(Vectorname) /* vormals: SIGNAL(siglabel) dabei Vectorname != siglabel ! */<br />
{<br />
/* Interrupt Code */<br />
}<br />
</syntaxhighlight><br />
<br />
Mit ''ISR'' wird eine Funktion für die Bearbeitung eines Interrupts eingeleitet. Als Argument muss dabei die Benennung des entsprechenden Interruptvektors angegeben werden. Diese sind in den jeweiligen Includedateien IOxxxx.h zu finden. Die Bezeichnung entspricht dem Namen aus dem Datenblatt, bei dem die Leerzeichen durch Unterstriche ersetzt sind und ein ''_vect'' angehängt ist.<br />
<br />
Als Beispiel ein Ausschnitt aus der Datei für den ATmega8 (bei WinAVR Standardinstallation in C:\WinAVR\avr\include\avr\iom8.h) in der neben den aktuellen Namen für ''ISR'' (*_vect) noch die Bezeichnungen für das inzwischen nicht mehr aktuelle ''SIGNAL'' (SIG_*) enthalten sind.<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
/* $Id: iom8.h,v 1.13 2005/10/30 22:11:23 joerg_wunsch Exp $ */<br />
<br />
/* avr/iom8.h - definitions for ATmega8 */<br />
//...<br />
<br />
/* Interrupt vectors */<br />
<br />
/* External Interrupt Request 0 */<br />
#define INT0_vect _VECTOR(1)<br />
#define SIG_INTERRUPT0 _VECTOR(1)<br />
<br />
/* External Interrupt Request 1 */<br />
#define INT1_vect _VECTOR(2)<br />
#define SIG_INTERRUPT1 _VECTOR(2)<br />
<br />
/* Timer/Counter2 Compare Match */<br />
#define TIMER2_COMP_vect _VECTOR(3)<br />
#define SIG_OUTPUT_COMPARE2 _VECTOR(3)<br />
<br />
/* Timer/Counter2 Overflow */<br />
#define TIMER2_OVF_vect _VECTOR(4)<br />
#define SIG_OVERFLOW2 _VECTOR(4)<br />
<br />
/* Timer/Counter1 Capture Event */<br />
#define TIMER1_CAPT_vect _VECTOR(5)<br />
#define SIG_INPUT_CAPTURE1 _VECTOR(5)<br />
<br />
/* Timer/Counter1 Compare Match A */<br />
#define TIMER1_COMPA_vect _VECTOR(6)<br />
#define SIG_OUTPUT_COMPARE1A _VECTOR(6)<br />
<br />
/* Timer/Counter1 Compare Match B */<br />
#define TIMER1_COMPB_vect _VECTOR(7)<br />
#define SIG_OUTPUT_COMPARE1B _VECTOR(7)<br />
<br />
//...<br />
</syntaxhighlight><br />
<br />
<!--Vor Nutzung von SIGNAL muss ebenfalls die Header-Datei signal.h eingebunden werden.--> <br />
Mögliche Funktionsrümpfe für Interruptfunktionen sind zum Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
/* veraltet: #include <avr/signal.h> */<br />
<br />
ISR(INT0_vect) /* veraltet: SIGNAL(SIG_INTERRUPT0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(TIMER0_OVF_vect) /* veraltet: SIGNAL(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(USART_RXC_vect) /* veraltet: SIGNAL(SIG_UART_RECV) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
// und so weiter und so fort...<br />
</syntaxhighlight><br />
<br />
Auf die korrekte Schreibweise der Vektorbezeichnung ist zu achten. Der gcc-Compiler prüft erst ab Version 4.x, ob ein Signal/Interrupt der angegebenen Bezeichnung tatsächlich in der Includedatei definiert ist und gibt andernfalls eine Warnung aus. Bei WinAVR (ab 2/2005) wurde die Überprüfung auch in den mitgelieferten Compiler der Version 3.x integriert. Aus dem gcc-Quellcode Version 3.x selbst erstellte Compiler enthalten die Prüfung nicht (vgl. [[AVR-GCC]]). <br />
<br />
Während der Ausführung der Funktion sind alle weiteren Interrupts automatisch gesperrt. Beim Verlassen der Funktion werden die Interrupts wieder zugelassen.<br />
<br />
Sollte während der Abarbeitung der Interruptroutine ein weiterer Interrupt (gleiche oder andere Interruptquelle) auftreten, so wird das entsprechende Bit im zugeordneten Interrupt Flag Register gesetzt und die entsprechende Interruptroutine automatisch nach dem Beenden der aktuellen Funktion aufgerufen.<br />
<br />
Ein Problem ergibt sich eigentlich nur dann, wenn während der Abarbeitung der aktuellen Interruptroutine mehrere gleichartige Interrupts auftreten. Die entsprechende Interruptroutine wird im Nachhinein zwar aufgerufen jedoch wissen wir nicht, ob nun der entsprechende Interrupt einmal, zweimal oder gar noch öfter aufgetreten ist. Deshalb soll hier noch einmal betont werden, dass Interruptroutinen so schnell wie nur irgend möglich wieder verlassen werden sollten.<br />
<br />
=== Unterbrechbare Interruptroutinen ===<br />
<br />
"Faustregel": im Zweifel '''ISR'''. Die nachfolgend beschriebene Methode nur dann verwenden, wenn man sich über die unterschiedliche Funktionsweise im Klaren ist.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
<br />
ISR(XXX,ISR_NOBLOCK) /* veraltet: INTERRUPT(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt-Code */<br />
}<br />
</syntaxhighlight><br />
<br />
Hierbei steht XXX für den oben beschriebenen Namen des Vektors (also z.&nbsp;B. ''TIMER0_OVF_vect''). Der Unterschied im Vergleich zu einer herkömmlichen ISR ist, dass hier beim Aufrufen der Funktion das '''Global Enable Interrupt''' Bit durch Einfügen einer SEI-Anweisung direkt wieder gesetzt und somit alle Interrupts zugelassen werden &ndash; auch XXX-Interrupts. <br />
<br />
Bei unsachgemässer Handhabung kann dies zu erheblichen Problemen durch Rekursion wie einem Stack-Overflow oder anderen unerwarteten Effekten führen und sollte wirklich nur dann eingesetzt werden, wenn man sich sicher ist, das Ganze auch im Griff zu haben.<br />
<br />
Insbesondere sollte möglichst am ISR-Anfang die auslösende IRQ-Quelle deaktiviert und erst am Ende der ISR wieder aktiviert werden. Robuster als die Verwendung einer NOBLOCK-ISR ist daher folgender ISR-Aufbau:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
<br />
ISR (XXX) <br />
{<br />
// Implementiere die ISR ohne zunaechst weitere IRQs zuzulassen<br />
<br />
<<Deaktiviere die XXX-IRQ>><br />
<br />
// Erlaube alle Interrupts (ausser XXX)<br />
sei();<br />
<br />
//... Code ...<br />
<br />
// IRQs global deaktivieren um die XXX-IRQ wieder gefahrlos <br />
// aktivieren zu koennen<br />
cli();<br />
<br />
<<Aktiviere die XXX-IRQ>><br />
}<br />
</syntaxhighlight><br />
Auf diese Weise kann sich die XXX-IRQ nicht selbst unterbrechen, was zu einer Art Endlosschleife führen würde.<br />
<br />
Siehe auch: Hinweise in [[AVR-GCC]]<br />
<br />
siehe dazu: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html<br />
<br />
== Datenaustausch mit Interrupt-Routinen ==<br />
<br />
Variablen, die sowohl in Interrupt-Routinen (ISR = Interrupt Service Routine(s)) als auch vom übrigen Programmcode geschrieben oder gelesen werden, müssen mit einem '''volatile''' deklariert werden. Damit wird dem Compiler mitgeteilt, dass der Inhalt der Variablen vor jedem Lesezugriff aus dem Speicher gelesen und nach jedem Schreibzugriff in den Speicher geschrieben wird. Ansonsten könnte der Compiler den Code so optimieren, dass der Wert der Variablen nur in Prozessorregistern zwischengespeichert wird, die nichts von der Änderung woanders mitbekommen.<br />
<br />
Zur Veranschaulichung ein Codefragment für eine Tastenentprellung mit Erkennung einer "lange gedrückten" Taste.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <stdint.h><br />
//...<br />
<br />
// Schwellwerte<br />
// Entprellung: <br />
#define CNTDEBOUNCE 10<br />
// "lange gedrueckt:"<br />
#define CNTREPEAT 200<br />
<br />
// hier z.&nbsp;B. Taste an Pin2 PortA "active low" = 0 wenn gedrueckt<br />
#define KEY_PIN PINA<br />
#define KEY_PINNO PA2<br />
<br />
// beachte: volatile! <br />
volatile uint8_t gKeyCounter;<br />
<br />
// Timer-Compare Interrupt ISR, wird z.B. alle 10ms ausgefuehrt<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
// hier wird gKeyCounter veraendert. Die übrigen<br />
// Programmteile müssen diese Aenderung "sehen":<br />
// volatile -> aktuellen Wert immer in den Speicher schreiben<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
}<br />
else {<br />
gKeyCounter = 0;<br />
}<br />
}<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
//...<br />
/* hier: Initialisierung der Ports und des Timer-Interrupts */<br />
//... <br />
// hier wird auf gKeyCounter zugegriffen. Dazu muss der in der<br />
// ISR geschriebene Wert bekannt sein:<br />
// volatile -> aktuellen Wert immer aus dem Speicher lesen<br />
if ( gKeyCounter > CNTDEBOUNCE ) { // Taste mind. 10*10 ms "prellfrei"<br />
if (gKeyCounter == CNTREPEAT) {<br />
/* hier: Code fuer "Taste lange gedrueckt" */<br />
}<br />
else {<br />
/* hier: Code fuer "Taste kurz gedrueckt" */<br />
}<br />
}<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Wird innerhalb einer ISR mehrfach auf eine mit volatile deklarierte Variable zugegriffen, wirkt sich dies ungünstig auf die Verarbeitungsgeschwindigkeit aus, da bei jedem Zugriff mit dem Speicherinhalt abgeglichen wird. Da bei AVR-Controllern ''innerhalb'' einer ISR keine Unterbrechungen zu erwarten sind, bietet es sich an, einen Zwischenspeicher in Form einer lokalen Variable zu verwenden, deren Inhalt zu Beginn und am Ende mit dem der volatile Variable synchronisiert wird. Lokale Variable werden bei eingeschalteter Optimierung mit hoher Wahrscheinlichkeit in Prozessorregistern verwaltet und der Zugriff darauf ist daher nur mit wenigen internen Operationen verbunden. Die ISR aus dem vorherigen Beispiel lässt sich so optimieren:<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter; // Uebernahme in lokale Arbeitsvariable<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (tmp_kc < CNTREPEAT) {<br />
tmp_kc++;<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc; // Zurueckschreiben<br />
}<br />
//...<br />
</syntaxhighlight><br />
<br />
Zum Vergleich die Disassemblies (Ausschnitte der "lss-Dateien", compiliert für ATmega162) im Anschluss. Man erkennt den viermaligen Zugriff auf die Speicheraddresse von ''gKeyCounter'' (hier 0x032A) in der ISR ohne "Cache"-Variable und den zweimaligen Zugriff in der Variante mit Zwischenspeicher. Im Beispiel ist der Vorteil gering, bei komplexeren Routinen kann die Zwischenspeicherung in lokalen Variablen jedoch zu deutlicheren Verbesserungen führen.<br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
876: ca 99 sbic 0x19, 2 ; 25<br />
878: 0a c0 rjmp .+20 ; 0x88e <__vector_13+0x24><br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
87a: 80 91 2a 03 lds r24, 0x032A<br />
87e: 88 3c cpi r24, 0xC8 ; 200 <br />
880: 40 f4 brcc .+16 ; 0x892 <__vector_13+0x28><br />
882: 80 91 2a 03 lds r24, 0x032A<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 02 c0 rjmp .+4 ; 0x892 <__vector_13+0x28><br />
}<br />
else {<br />
gKeyCounter = 0;<br />
88e: 10 92 2a 03 sts 0x032A, r1<br />
892: 8f 91 pop r24<br />
894: 0f 90 pop r0<br />
896: 0f be out 0x3f, r0 ; 63<br />
898: 0f 90 pop r0<br />
89a: 1f 90 pop r1<br />
89c: 18 95 reti<br />
</pre><br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter;<br />
876: 80 91 2a 03 lds r24, 0x032A<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
87a: ca 9b sbis 0x19, 2 ; 25<br />
87c: 02 c0 rjmp .+4 ; 0x882 <__vector_13+0x18><br />
87e: 80 e0 ldi r24, 0x00 ; 0<br />
880: 03 c0 rjmp .+6 ; 0x888 <__vector_13+0x1e><br />
if (tmp_kc < CNTREPEAT) {<br />
882: 88 3c cpi r24, 0xC8 ; 200<br />
884: 08 f4 brcc .+2 ; 0x888 <__vector_13+0x1e><br />
tmp_kc++;<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc;<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 8f 91 pop r24<br />
88e: 0f 90 pop r0<br />
890: 0f be out 0x3f, r0 ; 63<br />
892: 0f 90 pop r0<br />
894: 1f 90 pop r1<br />
896: 18 95 reti<br />
</pre><br />
<br />
=== volatile und Pointer ===<br />
<br />
Bei '''volatile''' in Verbindung mit Pointern ist zu beachten, ob der Pointer selbst oder die Variable, auf die der Pointer zeigt, '''volatile''' ist.<br />
<br />
<syntaxhighlight lang="c"><br />
volatile uint8_t *a; // das Ziel von a ist volatile<br />
<br />
uint8_t *volatile a; // a selbst ist volatile<br />
</syntaxhighlight><br />
<br />
Falls der Pointer volatile ist (zweiter Fall im Beispiel), ist zu beachten, dass der Wert des Pointers, also eine Speicheradresse, intern in mehr als einem Byte verwaltet wird. Lese- und Schreibzugriffe im Hauptprogramm (außerhalb von Interrupt-Routinen) sind daher so zu implementieren, dass alle Teilbytes der Adresse konsistent bleiben, vgl. dazu den folgenden Abschnitt.<br />
<br />
=== Variablen größer 1 Byte ===<br />
<br />
Bei Variablen größer ein Byte, auf die in Interrupt-Routinen und im Hauptprogramm zugegriffen wird, muss darauf geachtet werden, dass die Zugriffe auf die einzelnen Bytes außerhalb der ISR nicht durch einen Interrupt unterbrochen werden. (Allgemeinplatz: AVRs sind 8-bit Controller). Zur Veranschaulichung ein Codefragment:<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
volatile uint16_t gMyCounter16bit;<br />
//...<br />
ISR(...)<br />
{<br />
//...<br />
gMyCounter16Bit++;<br />
//...<br />
}<br />
<br />
int main(void)<br />
{<br />
uint16_t tmpCnt;<br />
//...<br />
// nicht gut: Mglw. hier ein Fehler, wenn ein Byte von MyCounter <br />
// schon in tmpCnt kopiert ist aber vor dem Kopieren des zweiten Bytes <br />
// ein Interrupt auftritt, der den Inhalt von MyCounter verändert.<br />
tmpCnt = gMyCounter16bit; <br />
<br />
<br />
// besser: Änderungen "außerhalb" verhindern -> alle "Teilbytes"<br />
// bleiben konsistent<br />
cli(); // Interrupts deaktivieren<br />
tmpCnt = gMyCounter16Bit;<br />
sei(); // wieder aktivieren<br />
<br />
// oder: vorheriger Status des globalen Interrupt-Flags bleibt erhalten<br />
uint8_t sreg_tmp;<br />
sreg_tmp = SREG; /* Sichern */<br />
cli()<br />
tmpCnt = gMyCounter16Bit;<br />
SREG = sreg_tmp; /* Wiederherstellen */<br />
<br />
// oder: mehrfach lesen, bis man konsistente Daten hat<br />
uint16_t count1 = gMyCounter16Bit;<br />
uint16_t count2 = gMyCounter16Bit;<br />
while (count1 != count2) {<br />
count1 = count2;<br />
count2 = gMyCounter16Bit;<br />
}<br />
tmpCnt = count1;<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Die avr-libc bietet ab Version 1.6.0(?) einige Hilfsfunktionen/Makros, mit der im Beispiel oben gezeigten Funktionalität, die zusätzlich auch sogenannte [http://en.wikipedia.org/wiki/Memory_barrier memory barriers] beinhalten. Diese stehen nach #include <util/atomic.h> zur Verfügung.<br />
<syntaxhighlight lang="c"><br />
//...<br />
#include <util/atomic.h><br />
//...<br />
<br />
// analog zu cli, Zugriff, sei:<br />
ATOMIC_BLOCK(ATOMIC_FORCEON) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
// oder:<br />
<br />
// analog zu Sicherung des SREG, cli, Zugriff und Zurückschreiben des SREG:<br />
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
//...<br />
</syntaxhighlight><br />
<br />
* siehe auch [http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Dokumentation der avr-libc zu atomic.h]<br />
<br />
== Interrupt-Routinen und Registerzugriffe ==<br />
<br />
Falls Register sowohl im Hauptprogramm als auch in Interrupt-Routinen verändert werden, ist darauf zu achten, dass diese Zugriffe sich nicht überlappen. Nur wenige Anweisungen lassen sich in sogenannte "atomare" Zugriffe übersetzen, die nicht von Interrupt-Routinen unterbrochen werden können. <br />
<br />
Zur Veranschaulichung eine Anweisung, bei der ein Bit und im Anschluss drei Bits in einem Register gesetzt werden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
int main(void)<br />
{<br />
//...<br />
PORTA |= (1<<PA0);<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Der Compiler übersetzt diese Anweisungen für einen ATmega128 bei Optimierungsstufe "S" nach:<br />
<br />
<div class="code"><pre><br />
...<br />
PORTA |= (1<<PA0);<br />
d2: d8 9a sbi 0x1b, 0 ; 27 (a)<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
d4: 8b b3 in r24, 0x1b ; 27 (b)<br />
d6: 8c 61 ori r24, 0x1C ; 28 (c)<br />
d8: 8b bb out 0x1b, r24 ; 27 (d)<br />
...<br />
</pre></div><br />
<br />
Das Setzen des einzelnen Bits wird bei eingeschalteter Optimierung für Register im unteren Speicherbereich in eine einzige Assembler-Anweisung (sbi) übersetzt und ist nicht anfällig für Unterbrechungen durch Interrupts. Die Anweisung zum Setzen von drei Bits wird jedoch in drei abhängige Assembler-Anweisungen übersetzt und bietet damit zwei "Angriffspunkte" für Unterbrechungen. Eine Interrupt-Routine könnte nach dem Laden des Ausgangszustands in den Zwischenspeicher (hier Register 24) den Wert des Registers ändern, z.&nbsp;B. ein Bit löschen. Damit würde der Zwischenspeicher nicht mehr mit dem tatsächlichen Zustand übereinstimmen aber dennoch nach der Bitoperation (hier ori) in das Register zurückgeschrieben. <br />
<br />
Beispiel: PORTA sei anfangs 0b00000000. Die erste Anweisung (a) setzt Bit 0 auf '''1''', PORTA ist danach 0b0000000'''1'''. Nun wird im ersten Teil der zweiten Anweisung der Portzustand in ein Register eingelesen (b). Unmittelbar darauf (vor (c)) "feuert" ein Interrupt, in dessen Interrupt-Routine Bit 0 von PORTA gelöscht wird. Nach Verlassen der Interrupt-Routine hat PORTA den Wert 0b00000000. In den beiden noch folgenden Anweisungen des Hauptprogramms wird nun der zwischengespeicherte "alte" Zustand 0b00000001 mit 0b00011100 logisch-'''ODER'''-verknüft (c) und das Ergebnis 0b00011101 in PortA geschrieben (d). Obwohl zwischenzeitlich Bit 0 gelöscht wurde, ist es nach (d) wieder gesetzt. <br />
<br />
Lösungsmöglichkeiten:<br />
* Register ohne besondere Vorkehrungen nicht in Interruptroutinen ''und'' im Hauptprogramm verändern.<br />
* Interrupts vor Veränderungen in Registern, die auch in ISRs verändert werden, deaktivieren ("cli").<br />
* Bits einzeln löschen oder setzen. sbi und cbi können nicht unterbrochen werden. Vorsicht: nur Register im unteren Speicherbereich sind mittels sbi/cbi ansprechbar. Der Compiler kann nur für diese sbi/cbi-Anweisungen generieren. Für Register außerhalb dieses Adressbereichs ("Memory-Mapped"-Register) werden auch zur Manipulation einzelner Bits abhängige Anweisungen erzeugt (lds,...,sts).<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Frequently asked Questions/Fragen Nr. 1 und 8. (Stand: avr-libc Vers. 1.0.4)<br />
<br />
== Interruptflags löschen ==<br />
<br />
Beim Löschen von Interruptflags haben AVRs eine Besonderheit, die auch im Datenblatt beschrieben ist: Es wird zum Löschen eine 1 in das betreffende Bit geschrieben. <br />
<br />
Hinweis:<br /><br />
Bei Registern mit mehreren Interrupt-Flag-Bits (wie die Timer Interrupt Flag Register) '''nicht''' die übliche bitweise VerODERung nehmen, sondern eine direkte Zuweisung machen. Da sonst weitere Flags, als nur das gewünschte, ebenfalls gelöscht werden könnten.<br /><br />
([http://www.mikrocontroller.net/topic/171148#1640133 Erklärung]).<br />
<br />
== Was macht das Hauptprogramm? ==<br />
<br />
Im einfachsten (Ausnahme-)Fall gar nichts mehr. Es ist also durchaus denkbar, ein Programm zu schreiben, welches in der main-Funktion lediglich noch die Interrupts aktiviert und dann in einer Endlosschleife verharrt. Sämtliche Funktionen werden dann in den ISRs abgearbeitet. Diese Vorgehensweise ist jedoch bei den <i>meisten</i> Anwendungen schlecht: man verschenkt eine Verarbeitungsebene und hat außerdem möglicherweise Probleme durch Interruptroutinen, die zu viel Verarbeitungszeit benötigen.<br />
<br />
Für <i>wenige</i> Anwendungen ist diese Vorgehensweise jedoch perfekt: Die Hauptschleife verkommt zu <tt>for(;;) sleep_cpu();</tt> — siehe nächster Abschnitt „Sleep“. Weiterer Vorteil: ISRs brauchen keine(!) Register retten, ein Fall für <tt>ISR(<i>name</i>,ISR_NAKED){ … reti();}</tt>. <i>So</i> können Mikrocontroller für batteriebetriebene Geräte, etwa Fernbedienungen, maximal Energie sparen.<br />
<br />
Normalerweise wird man in den Interruptroutinen nur die bei Auftreten des jeweiligen Interruptereignisses unbedingt notwendigen Operationen ausführen lassen. Alle weniger kritischen Aufgaben werden dann im Hauptprogramm abgearbeitet.<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Interrupts and Signals<br />
<br />
= Sleep-Modes =<br />
<br />
AVR Controller verfügen über eine Reihe von sogenannten [[Sleep Mode |''Sleep-Modes'']] ("Schlaf-Modi"). Diese ermöglichen es, Teile des Controllers abzuschalten. Zum Einen kann damit besonders bei Batteriebetrieb Strom gespart werden, zum Anderen können Komponenten des Controllers deaktiviert werden, die die Genauigkeit des Analog-Digital-Wandlers bzw. des Analog-Comparators negativ beeinflussen. Der Controller wird durch Interrupts aus dem Schlaf geweckt. Welche Interrupts den jeweiligen Schlafmodus beenden, ist einer Tabelle im Datenblatt des jeweiligen Controllers zu entnehmen.<br />
Die Funktionen (eigentlich Makros) der avr-libc stehen nach Einbinden der header-Datei ''sleep.h'' zur Verfügung.<br />
<br />
;set_sleep_mode (uint8_t mode): Setzt den Schlafmodus, der bei Aufruf von sleep() aktiviert wird. In sleep.h sind einige Konstanten definiert (z.&nbsp;B. SLEEP_MODE_PWR_DOWN). Die definierten Modi werden jedoch nicht alle von sämtlichten AVR-Controllern unterstützt.<br />
;sleep_enable(): Aktiviert den gesetzten Schlafmodus, versetzt den Controller aber noch nicht in den Schlafmodus<br />
;sleep_cpu(): Versetzt den Controller in den Schlafmodus .sleep_cpu wird im Prinzip durch die Assembler-Anweisung ''sleep'' ersetzt.<br />
;sleep_disable(): Deaktiviert den gesetzten Schlafmodus<br />
;sleep_mode(): Versetzt den Controller in den mit set_sleep_mode gewählten Schlafmodus. Das Makro entspricht sleep_enable()+sleep_cpu()+sleep_disable(), beinhaltet also nicht die Aktivierung von Interrupts (besser nicht benutzen).<br />
<br />
Bei Anwendung von sleep_cpu() müssen Interrupts also bereits freigeben sein (sei()), da der Controller sonst nicht mehr "aufwachen" kann. sleep_mode() ist nicht geeignet für die Verwendung in ISR Interrupt-Service-Routinen, da bei deren Abarbeitung Interrupts global deaktiviert sind und somit auch die möglichen "Aufwachinterrupts". Abhilfe: stattdessen sleep_enable(), sei(), sleep_cpu(), sleep_disable() und evtl. cli() verwenden (vgl. Dokumentation der avr-libc).<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/sleep.h><br />
<br />
int main(void)<br />
{<br />
...<br />
<br />
while (1) {<br />
...<br />
set_sleep_mode(SLEEP_MODE_PWR_DOWN);<br />
sleep_mode();<br />
<br />
// Code hier wird erst nach Auftreten eines entsprechenden<br />
// "Aufwach-Interrupts" verarbeitet<br />
...<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
In älteren Versionenen der avr-libc wurden nicht alle AVR-Controller durch die sleep-Funktionen richtig angesteuert. Mit avr-libc 1.2.0 wurde die Anzahl der unterstützten Typen jedoch deutlich erweitert. Bei nicht-unterstützten Typen erreicht man die gewünschte Funktionalität durch direkte "[[Bitmanipulation]]" der entsprechenden Register (vgl. Datenblatt) und Aufruf des Sleep-Befehls via Inline-Assembler oder sleep_cpu():<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
// Sleep-Mode "Power-Save" beim ATmega169 "manuell" aktivieren<br />
SMCR = (3<<SM0) | (1<<SE);<br />
asm volatile ("sleep"::); // alternativ sleep_cpu() aus sleep.h<br />
...<br />
</syntaxhighlight><br />
<br />
== Sleep-Modi ==<br />
Die vielen Prozessoren aus der AVR-Familie unterstützen unterschiedliche Sleep-Modi, gefächert nach Vorhandensein von Funktionsblöcken im Controller. Konkrete und verläßliche Auskunft über die tatsächlichen Gegebenheiten finden sich wie immer in den jeweiligen Datenblättern. Die Modi unterscheiden sich darin, welche Funktionsbereiche zum Energiesparen abgeschaltet werden. Davon hängt auch ab, mit welchen Mitteln der Prozessor aus der jeweiligen Schlaftiefe wieder aufgeweckt werden kann.<br />
<br />
;Idle Mode (SLEEP_MODE_IDLE): Die CPU kann durch SPI, USART, Analog Comperator, ADC, TWI, Timer, Watchdog und irgendeinen anderen Interrupt wieder aufgeweckt werden.<br />
<br />
;ADC Noise Reduction Mode (SLEEP_MODE_ADC): In diesem Modus liegt das Hauptaugenmerk darauf, die CPU soweit stillzulegen, dass der ADC möglichst keine Störungen aus dem inneren der CPU auffangen kann, die das Meßergebnis negativ beeinflussen können. Das Aufwachen aus diesem Modus kann ausgelöst werden durch den ADC, externe Interrupts, TWI, Timer und Watchdog.<br />
<br />
;Power-Down Mode (SLEEP_MODE_PWR_DOWN): In diesem Modus wird ein externer Oszillator (Quarz, Quarzoszillator), wenn vorhanden. gestoppt. Geweckt werden kann die CPU durch einen externen Level-Interrupt, TWI, Watchdog, Brown-Out-Reset.<br />
<br />
;Power-Save-Mode (SLEEP_MODE_PWR_SAVE): Power-Save ist identisch zu Power-Down mit einer Ausnahme: Ist der Timer 2 auf die Verwendung eines externen Taktes konfiguriert, so läuft dieser Timer auch im Power-Save weiter und kann die CPU mit einem Interrupt aufwecken.<br />
<br />
;Standby-Mode (SLEEP_MODE_STANDBY, SLEEP_MODE_EXT_STANDBY): Voraussetzung für den Standby-Modus ist die Verwendung eines Quarzes oder eines Quarzoszillators, also einer externen Taktquelle. Ansonsten ist dieser Modus identisch zum Power-Down Modus. Vorteil dieses Modus' ist eine kürzere Aufwachzeit.<br />
<br />
;Abschalten des Brownout Detect (BOD) während der Sleep-Phase (nur P-Typen): Zur Stromersparnis bieten die P-Typen die Möglichkeit den BOD während der Sleep-Phase abzuschalten. Bei einem Atmega88PA beispielsweise, kann dadurch der Stromverbrauch im SLEEP_MODE_PWR_SAVE mit Timer2 im Asynchronmodus mit Uhrenquarz und periodischer Selbstaufweckung um ca. 50% gesenkt werden.<br />
Das Einschalten dieser Funktion geschieht in einer Timed Sequence.<br />
<br />
<syntaxhighlight lang="c"><br />
unsigned char temp0 = MCUCR;<br />
unsigned char temp1 = MCUCR;<br />
temp0 |= (1 << BODS) | (1 << BODSE);<br />
temp1 |= (1 << BODS);<br />
MCUCR = temp0;<br />
MCUCR = temp1;<br />
sleep_cpu();<br />
</syntaxhighlight><br />
<br />
Hierbei ist unbedingt zu beachten, dass das BODS-Bit 3 Takte nach dem Setzen wieder gelöscht wird. Daher muss der Aufruf des Sleep unmittelbar nach dem Setzen erfolgen und das BODS-Bit muss jedes Mal vor einem Sleep Aufruf erneut gesetzt werden.<br />
<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Power Management and Sleep-Modes<br />
* [http://www.mikrocontroller.net/topic/96369#832712 Forenbeitrag] zur "Nichtverwendung" von sleep_mode in ISRs.<br />
<br />
= Zeiger =<br />
Zeiger (engl. ''Pointer'') sind Variablen, die die Adresse von Daten oder Funktionen enthalten und belegen 16 Bits. Die Größe hängt mit dem adressierbaren Speicherbereich zusammen und der GCC reserviert dann den entsprechenden Platz.<br />
Ggf. ist es also günstiger, Indizes auf Arrays (Listen) zu verwenden, so dass der GCC für die Zeigerarithmetik den erforderlichen RAM nur temporär benötigt.<br />
<br />
Siehe auch: [[Zeiger]]<br />
<br />
= Speicherzugriffe =<br />
<br />
Atmel AVR-Controller verfügen typisch über drei Speicher:<br />
<br />
* [[RAM]]: Im RAM (genauer statisches RAM/SRAM) wird vom gcc-Compiler Platz für Variablen reserviert. Auch der Stack befindet sich im RAM. Dieser Speicher ist "flüchtig", d.h. der Inhalt der Variablen geht beim Ausschalten oder einem Zusammenbruch der Spannungsversorgung verloren.<br />
<br />
* Programmspeicher: Ausgeführt als FLASH-Speicher, seitenweise wiederbeschreibbar. Darin ist das Anwendungsprogramm abgelegt.<br />
<br />
* [[EEPROM]]: Nichtflüchtiger Speicher, d.h. der einmal geschriebene Inhalt bleibt auch ohne Stromversorgung erhalten. Byte-weise schreib/lesbar. Im EEPROM werden typischerweise gerätespezifische Werte wie z.&nbsp;B. Kalibrierungswerte von Sensoren abgelegt.<br />
<br />
Einige AVRs besitzen keinen RAM-Speicher, lediglich die Register können als "Arbeitsvariablen"<br />
genutzt werden. Da die Anwendung des avr-gcc auf solch "kleinen" Controllern ohnehin selten sinnvoll ist und auch nur bei einigen RAM-losen Typen nach [http://lightner.net/avr/ATtinyAvrGcc.html "Bastelarbeiten"] möglich ist, werden diese Controller hier nicht weiter berücksichtigt. Auch EEPROM-Speicher ist nicht auf allen Typen verfügbar. Generell sollten die nachfolgenden Erläuterungen auf alle ATmega-Controller und die größeren AT90-Typen übertragbar sein. Für die Typen ATtiny2313, ATtiny26 und viele weitere der "ATtiny-Reihe" gelten die Ausführungen ebenfalls.<br />
<br />
Siehe auch:<br />
* [[Binäre Daten zum Programm hinzufügen]]<br />
== RAM ==<br />
<br />
Die Verwaltung des RAM-Speichers erfolgt durch den Compiler, im Regelfall ist beim Zugriff auf Variablen im RAM nichts Besonderes zu beachten. Die Erläuterungen in jedem brauchbaren C-Buch gelten auch für den vom avr-gcc-Compiler erzeugten Code.<br />
<br />
Um Speicher dynamisch (während der Laufzeit) zu reservieren, kann '''malloc()''' verwendet werden. malloc(size) "alloziert" (~reserviert) einen gewissen Speicherblock mit '''size''' Bytes. Ist kein Platz für den neuen Block, wird NULL (0) zurückgegeben.<br />
<br />
Wird der angelegte Block zu klein (groß), kann die Größe mit realloc() verändert werden. Den allozierten Speicherbereich kann man mit free() wieder freigeben. Wenn das Freigeben eines Blocks vergessen wird spricht man von einem "Speicherleck" (memory leak).<br />
<br />
malloc() legt Speicherblöcke im '''Heap''' an, belegt man zuviel Platz, dann wächst der Heap zu weit nach oben und überschreibt den Stack, und der Controller kommt in Teufels Küche. Das kann leider nicht nur passieren wenn man insgesamt zu viel Speicher anfordert, sondern auch wenn man Blöcke unterschiedlicher Größe in ungünstiger Reihenfolge alloziert/freigibt (siehe Artikel [[Heap-Fragmentierung]]). Aus diesem Grund sollte man malloc() auf Mikrocontrollern sehr sparsam (am besten gar nicht) verwenden.<br />
<br />
Beispiel zur Verwendung von malloc():<br />
<syntaxhighlight lang="c"><br />
#include <stdlib.h><br />
<br />
void foo(void) {<br />
// neuen speicherbereich anlegen,<br />
// platz für 10 uint16<br />
uint16_t* pBuffer = malloc(10 * sizeof(uint16_t));<br />
<br />
// darauf zugreifen, als wärs ein gewohnter Buffer<br />
pBuffer[2] = 5;<br />
<br />
// Speicher (unbedingt!) wieder freigeben<br />
free(pBuffer);<br />
}<br />
</syntaxhighlight><br />
<br />
Wenn (wie in obigem Beispiel) dynamischer Speicher nur für die Dauer einer Funktion benötigt und am Ende wieder freigegeben wird, bietet es sich an, statt malloc() '''alloca()''' zu verwenden. Der Unterschied zu malloc() ist, dass der Speicher auf dem Stack reserviert wird, und beim Verlassen der Funktion automatisch wieder freigegeben wird. Es kann somit kein Speicherleck und keine Fragmentierung entstehen.<br />
<br />
siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/malloc.html AVR Libc Home Page]: Memory Areas and Using malloc()<br />
* [https://www.mikrocontroller.net/topic/479027#5934443 Forumsbeitrag]: RAM Verbrauch auch von lokalen variablen ermitteln<br />
<br />
== Flash mit PROGMEM und pgm_read ==<br />
<br />
→ [http://nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html avr-libc: Doku zu avr/pgmspace.h]<br />
<br />
Ein Zugriff auf Konstanten im Programmspeicher ist mittels avr-gcc erst ab Version 4.7 "transparent" möglich. Um Daten aus dem Flash zu lesen, muss die AVR-Instruktion LPM (''Load from Program Memory'') erzeugt werden, bei Controllern mit mehr als 64kiB Flash auch ELPM.<br />
<br />
Dazu gibt es das AVR-spezifische GCC-Attribut <tt>progmem</tt>, mit dem eine Variablendeklaration im ''static storage''<ref>Variablen der Speicherklasse ''static storage'' haben eine unbegrenzte Lebensdauer. Beispiel für solche Variablen sind globale Variablen, aber auch static-Variablen innerhalb einer Funktion gehören dazu. Beispiele für Variablen, die nicht ''static storage'' sind: auto-Variablen ("normale" lokale Variablen), register-Variablen, durch malloc geschaffene Objekte, etc.</ref> markiert werden kann:<br />
<syntaxhighlight lang="c"><br />
const int value __attribute__((progmem)) = 1;<br />
</syntaxhighlight><br />
<br />
Effekt ist, dass die so markierte Variable nicht im RAM sondern im Flash angelegt wird. Wird durch "normalen" C-Code auf solch eine Variable zugegriffen, wird jedoch aus der gleichen Adresse aus dem RAM gelesen und nicht aus dem Flash! Das ist ein Fehler, den der Compiler aber nicht anzeigt!<br />
<br />
<syntaxhighlight lang="c"><br />
int test = value; // Fehler! PROGMEM Konstanten müssen mit den pgm_read-Funktionen gelesen werden!<br />
</syntaxhighlight><br />
<br />
Zum Lesen aus dem Flash stellt die avr-libc daher zahlreiche Makros zur Verfügung. Zudem wird das Makro <tt>PROGMEM</tt> definiert, das etwas Tipparbeit spart:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
const int value PROGMEM = 1;<br />
</syntaxhighlight><br />
<br />
<tt>progmem</tt> funktioniert im Wesentlichen wie ein Section-Attribut, das die Daten in der Section <tt>.progmem.data</tt> ablegt. Im Gegensatz zum Section-Attribut werden jedoch noch weitere Prüfungen unternommen, ab avr-gcc 4.6 etwa muss die entsprechende Variable <tt>const</tt> sein.<br />
<br />
=== Integer und float ===<br />
<br />
Zum Lesen von Skalaren stellt die avr-libc folgende Makros zu Verfügung, die jeweils ein Argument erhalten: Die 16-Bit Adresse des zu lesenden Wertes<ref>Damit ist der mögliche Speicherbereich für Flash-Konstanten auf 64kiB begrenzt. Einige pgmspace-Funktionen ermöglichen den Lesezugriff auf den gesamten Flash-Speicher, intern via Assembler-Anweisung ELPM. Die Initialisierungswerte des Speicherinhalts jenseits der 64kiB-Marke müssen dann jedoch auf anderem Weg angelegt werden, d.h. nicht per PROGMEM. Evtl. eigene Section und Linker-Optionen. Alt und nicht ganz korrekt: Die avr-libc pgmspace-Funktionen unterstützen nur die unteren 64kiB Flash bei Controllern mit mehr als 64kiB.</ref><br />
<br />
:{| {{Tabelle}}<br />
|+ Übersicht der <tt>pgm_read</tt> Funktionen aus<br/>dem Header <tt>avr/pgmspace.h</tt> der avr-libc<br />
|-<br />
! Gelesener Wert || <tt>pgm_read_xxx</tt> || Anzahl Bytes<br />
|-<br />
| <tt>uint8_t</tt> || <tt>pgm_read_byte</tt> || 1<br />
|-<br />
| <tt>uint16_t</tt> || <tt>pgm_read_word</tt> || 2<br />
|-<br />
| <tt>uint32_t</tt> || <tt>pgm_read_dword</tt> || 4<br />
|-<br />
| <tt>float</tt> || <tt>pgm_read_float</tt><ref>ab avr-libc 1.7.0</ref> || 4<br />
|}<br />
<br />
Soll ein Zeiger gelesen werden, so verwendet man <tt>pgm_read_word</tt> und castet das Ergebnis zum gewünschten Zeiger-Typ.<br />
<br />
;Beispiele:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
/* Byte */<br />
const uint8_t aByte PROGMEM = 123;<br />
<br />
/* int-Array */<br />
const int anArray[] PROGMEM = { 18, 3 ,70 };<br />
<br />
void foo (void)<br />
{<br />
/* Zeiger */<br />
static const uint8_t* const aPointer PROGMEM = &aByte;<br />
<br />
uint8_t a = pgm_read_byte (&aByte);<br />
int a2 = (int) pgm_read_word (&anArray[2]);<br />
const uint8_t* p = (const uint8_t*) pgm_read_word (&aPointer);<br />
}<br />
</syntaxhighlight><br />
<br />
=== Blöcke ===<br />
<br />
In den Flash-Funktionen der avr-libc sind keine der pgm_read_xxxx Nomenklatur folgenden Funktionen, die Speicherblöcke auslesen oder vergleichen. Die enstprechende Funktionen sind Varianten von <tt>memcpy</tt>, <tt>memcmp</tt> und heißt <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, usw. Für weitere Funktionen und deren Prototypen siehe die Dokumentation der avr-libc.<br />
<br />
=== Strings ===<br />
<br />
Strings sind in C nichts anderes als eine Abfolge von Zeichen und einem <tt>'\0'</tt> als Stringende. Der prinzipielle Weg ist daher identisch zum Lesen von Bytes, wobei auf die [[FAQ#Wie funktioniert String-Verarbeitung in C?|Besonderheiten von Strings]] wie 0-Terminierung geachtet werden muss.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
size_t my_string_length (const char *addr)<br />
{<br />
size_t length = 0;<br />
<br />
while (pgm_read_byte (addr++))<br />
{<br />
length++;<br />
}<br />
return length;<br />
}<br />
</syntaxhighlight><br />
<br />
Zur Unterstützung des Programmierers steht das Repertoire der str-Funktionen auch in jeweils eine Variante zur Verfügung, die mit dem Flash-Speicher arbeiten kann. Die Funktionsnamen tragen den Suffix <tt>_P</tt>. Darüber hinaus gibt es das Makro <tt>PSTR</tt>, das ein String-Literal im Flash-Speicher ablegt und die Adresse des Strings liefert:<br />
<br />
Die nachfolgende Funktion liefert 0 zurück, wenn string_im_ram gleich "Hallo Welt" ist. Mit strcmp (String Compare) können wir zwei Strings vergleichen. Der Rückgabewert kann hierbei folgende Werte haben:<br><br />
0 die Strings sind gleich<br />
>0 das erste ungleiche Zeichen in string_im_ram ist größer als in "Hallo Welt"<br />
<0 das erste ungleiche Zeichen in string_im_ram ist kleiner als in "Hallo Welt"<br />
<br><br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
int foo (const char *string_im_ram)<br />
{<br />
return strcmp_P (string_im_ram, PSTR ("Hallo Welt"));<br />
}<br />
</syntaxhighlight><br />
<br />
Zu beachten ist, dass <tt>PSTR</tt> nur innerhalb von Funktionen verwendet werden kann.<br />
<br />
; Array aus Strings:<br />
<br />
Arrays aus Strings im Flash-Speicher werden in zwei Schritten angelegt:<br />
<br />
# Zuerst die einzelnen Elemente des Arrays und<br />
# im Anschluss ein Array, in dem die Startaddressen der Strings abgelegt werden.<br />
<br />
Zum Auslesen wird zuerst die Adresse des gewünschten Elements aus dem Array im Flash-Speicher gelesen, die im Anschluss dazu genutzt wird, um auf das Element (den String) selbst zuzugreifen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
static const char str1[] PROGMEM = "Hund";<br />
static const char str2[] PROGMEM = "Katze";<br />
static const char str3[] PROGMEM = "Maus";<br />
<br />
const char * const array[] PROGMEM = <br />
{<br />
str1, str2, str3<br />
};<br />
<br />
// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]<br />
void read_string (char *buf, size_t i)<br />
{<br />
// Lese die Adresse des i-ten Strings aus array[]<br />
const char *parray = (const char*) pgm_read_ptr (&array[i]);<br />
<br />
// Kopiere den Inhalt der Zeichenkette vom Flash ins RAM<br />
strcpy_P (buf, parray);<br />
}<br />
</syntaxhighlight><br />
<br />
Eine weitere Möglichkeit ist, die Strings in einem 2-dimensionalen char-Array abzulegen anstatt deren Adresse in einem 1-dimensionalen Adress-Array zu speichern.<br />
<br />
Vorteil ist, dass der Code einfacher wird. Nachteil ist, dass bei unterschiedlich langen Strings Speicherplatz verschwendet wird, weil sich die Array-Dimension and der Länge des längsten Strings orientieret. Bei in etwa gleich langen Strings kann es aber sogar Speicherplatz sparen, denn es die Adressen der einzelnen Strings müssen nicht abgespeichert werden.<ref>In unserem Hund-Katze-Maus Beispiel belegt die erste Variante 22 Bytes Daten und 18 Bytes Code, die zweite Variante mit 2-dimensionalem Array belegt 18 Bytes Daten und 20 Bytes Code. Gemessen wurde mit avr-gcc 4.8 -Os für ATmega8.</ref><br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
// Die "6" ist 1 plus die Länge des längsten Strings ("Katze")<br />
const char array[][6] PROGMEM = <br />
{<br />
"Hund", "Katze", "Maus"<br />
};<br />
<br />
// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]<br />
void read_string (char *buf, size_t i)<br />
{<br />
// Kopiere den Inhalt der i-ten Zeichenkette vom Flash ins RAM<br />
strcpy_P (buf, array[i]);<br />
}<br />
</syntaxhighlight><br />
<br />
Siehe dazu auch die avr-libc FAQ: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_rom_array How do I put an array of strings completely in ROM?]<br />
<br />
=== Warum so kompliziert? ===<br />
<br />
Zu dem Thema, warum die Verabeitung von Werten aus dem Flash-Speicher so kompliziert ist, sei hier nur kurz erläutert: Die Harvard-Architektur des AVR weist getrennte Adressräume für Programm (Flash) und Datenspeicher (RAM) auf. Der C-Standard sieht keine unterschiedlichen Adressräume vor.<br />
<br />
Hat man zum Beispiel eine Funktion string_an_uart (const char* s) und übergibt an diese Funktion die Adresse einer Zeichenkette, dann weiß die Funktion nicht, ob die Adresse in den Flash-Speicher oder das RAM zeigt. Weder aus dem Pointer-Wert, also dem Zahlenwert, noch aus dem "const" kann auf den Ort der Ablage geschlossen werden.<br />
<br />
Einige AVR-Compiler bilden die Harvard-Architektur ab, indem sie in einen Pointer nicht nur die Adresse speichern, sondern auch den Ablageort wie ''Flash'' oder ''RAM''. In einem Aufruf einer Funktion wird dann bei Pointer-Parametern neben der Adresse auch der Speicherbereich, auf den der Pointer zeigt, übergeben.<br />
<br />
Dies hat jedoch auch Nachteile, denn bei jedem Zugriff über einen Zeiger muss zur ''Laufzeit'' entschieden werden, wie der Zugriff auszuführen ist und entsprechend länglicher und langsamer wird der erzeugte Code.<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitte Modules/Program Space String Utilities und Abschnitt Modules/Bootloader Support Utilities<br />
<br />
=== Datenzugriff >64kiB ===<br />
<br />
Die Zeiger beim avr-gcc sind nur 16 Bit breit, können somit also nur 64kiB Datenspeicher adressieren. Darauf sind auch alle Funktion der libc ausgelegt, welche auf _P enden. Als Funktionspointer können sie beim AVR bis zu 128 kiB Programmspeicher adressieren, weil Funktionsadressen immer 16-Bit Worte adressieren und nicht Bytes. Der Zugriff auf den RAM ist mit maximal 16kiB durch 16 Bit Poiinter nicht begrenzt. Um Zugriff jenseits von 64KiB zu bewerkstelligen gibt es mehrere Möglichkeiten:<br />
<br />
* Address-Spaces wie <tt>__flash1</tt> oder <tt>__memx</tt>, siehe Abschnitt "[[#Jenseits von flash|Jenseits von __flash]]".<br />
* Die Funktionen bzw. Makros <tt>pgm_read_xxx_far</tt> der AVR-Libc ab Version 1.8.0, wie im folgenden beschrieben. Dafür gibt es die Funktion pgm_get_far_address(), um 32-Bit Pointer eines Objekts zu erhalten<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/pgmspace.h><br />
<br />
//===================================================================<br />
// Define an additional section, which will be placed after all others<br />
//--------------------------------------------------------------------<br />
#define FAR_SECTION __attribute__((__section__(".far_section")))<br />
//--------------------------------------------------------------------<br />
<br />
//====================================================================<br />
// Just an example<br />
//====================================================================<br />
<br />
const char MyString[] FAR_SECTION = "Hier liegt mein FAR-Teststring!";<br />
const char MyBmp64[] FAR_SECTION = {0xAA,0xBB,0xCC,0xDD,0xEE,0xFF,0x00};<br />
<br />
int main(void) {<br />
uint32_t ptr = pgm_get_far_address(MyString);<br />
char MyChar;<br />
DDRC = 0xFF;<br />
do {<br />
MyChar = pgm_read_byte_far(ptr++);<br />
PORTC = MyChar;<br />
} while(MyChar);<br />
}<br />
</syntaxhighlight><br />
<br />
D.h. man muss<br />
* Die Definition der neuen Section <tt>FAR_SECTION</tt> einfügen<br />
* Die konstanten Daten mit dieser Section kennzeichnen<br />
<br />
Dem Linker muss man über diese Section nichts mitteilen, er fügt diese automatisch nach allen bestehenden sections im Flash ein. Der Zugriff auf diese Variablen kann nur mittels direkter Pointerarithmetik erfolgen, eine Indizierung von Arrays mit variablem Index ist nicht möglich. Dabei muss die Größe des Datentyps immer manuell berücksichtigt werden, denn der Pointer ist immer ein Bytepointer!<br />
<br />
<syntaxhighlight lang="c"><br />
int n=3;<br />
MyChar = pgm_read_byte_far(pgm_get_far_address(MyBmp64)+n*sizeof(char));<br />
</syntaxhighlight><br />
<br />
Dabei gibt es einige praktische Probleme.<br />
* Beim recht alten AVR-Studio 4.18 wird die Größe des belegten FLASH-Speichers nicht korrekt angezeigt, die Daten landen aber im HEX-File.<br />
* beim moderneren Atmelstudio 6.2 sieht man in der Consolenausgabe die richtige Größe, welche von avr-size ermittelt wurde, diese wird aber dann in der 2. Ausgabe durch Atmelstudio falsch dargestellt<br />
* Die Arduino-IDE rechnet richtig, siehe dieser [https://www.mikrocontroller.net/topic/511511?goto=6568945#6568945 Forumsbeitrag].<br />
<br />
== Flash mit __flash und Embedded-C ==<br />
<br />
Ab Version 4.7 unterstützt avr-gcc ''Adress-Spaces'' gemäß dem Embedded-C Dokument ISO/IEC TR18037. Der geläufigste Adress-Space ist <tt>__flash</tt>, der im Gegensatz zu <tt>progmem</tt> kein GCC-Attribut ist, sondern ein Qualifier und damit syntaktisch ähnlich verwendet wird wie <tt>const</tt> oder <tt>volatile</tt>.<br />
<br />
GCC kennt keine eigene Option zum Aktivieren von Embedded-C, es wird als GNU-C Erweiterung behandelt. Daher müssen C-Module, die Address-Spaces verwenden, mit <tt>-std=gnu99</tt> o.ä. compiliert werden.<br />
<br />
<syntaxhighlight lang="c"><br />
static const __flash int value = 10;<br />
<br />
int get_value (void)<br />
{<br />
return value;<br />
}<br />
</syntaxhighlight><br />
<br />
# Im Gegensatz zu <tt>progmem</tt> sind keine speziellen Bibliotheksfunktionen oder -makros für den Zugriff mehr notwendig: Der Code zum Lesen der Variable ist "normales" C.<br />
# Die Variable wird im richtigen Speicherbereich (Flash) angelegt.<br />
# <tt>__flash</tt> ist nur zusammen mit read-only Objekten oder Zeigern, d.h. nur zusammen mit <tt>const</tt>, erlaubt.<br />
# Zugriffe wie im obigen Beispiel können (weg)optimiert werden. Das Beispiel entspricht einem "<tt>return 10</tt>". Es besteht keine Notwendigkeit, für <tt>value</tt> überhaupt Flash-Speicher zu reservieren.<br />
<br />
Auch Zeiger-Indirektionen sind problemlos möglich. Zu beachten ist, dass <tt>__flash</tt> auf der richtigen Seite des "<tt>*</tt>" in der Zeigerdeklaration bzw. -definition steht:<br />
* '''Rechts vom <tt>*</tt>:''' Der Zeiger selbst liegt im Flash<br />
* '''Links vom <tt>*</tt>:''' Der Zeiger enthält eine Flash-Adresse<br />
<br />
<syntaxhighlight lang="c"><br />
// val ist eine Variable im Flash<br />
const __flash int val = 42;<br />
<br />
// pval liegt auch im Flash und enthält die Adresse von val<br />
const __flash int* const __flash pval = &val;<br />
<br />
int get_val (void)<br />
{<br />
// liest den Wert von val über die in pval abgelegte Adresse<br />
return *pval;<br />
}<br />
</syntaxhighlight><br />
<br />
=== Blöcke ===<br />
<br />
Um Speicherbereiche vom Flash in den RAM zu kopieren, gibt es zwei Möglichkeiten: Zum einen können wie bei <tt>progmem</tt> beschreiben die Funktionen der avr-libc wie <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, <tt>movmem_P</tt>, etc. verwendet werden:<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
// Eine Datenstruktur<br />
typedef struct<br />
{<br />
int id;<br />
char buf[10];<br />
} data_t;<br />
<br />
extern void uart_send (const void*, size_t);<br />
<br />
void send_data (const __flash data_t *pdata)<br />
{<br />
// buf wird auf dem Stack angelegt<br />
data_t buf;<br />
<br />
// Kopiere Daten vom Flash nach buf ins RAM<br />
memcpy_P (&buf, pdata, sizeof (data_t));<br />
<br />
// Sende die Daten in buf<br />
uart_send (&buf, sizeof (data_t));<br />
}<br />
</syntaxhighlight><br />
<br />
Zum anderen kann eine Struktur auch über direktes Kopieren ins RAM geladen werden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdlib.h><br />
<br />
// Eine Datenstruktur<br />
typedef struct<br />
{<br />
int id;<br />
char buf[10];<br />
} data_t;<br />
<br />
extern void uart_send (const void*, size_t);<br />
<br />
void send_data (const __flash data_t *pdata)<br />
{<br />
// Kopiere Daten ins RAM. buf wird auf dem Stack angelegt<br />
const data_t buf = *pdata;<br />
<br />
// Verwendet die Daten in buf<br />
uart_send (&buf, sizeof (data_t));<br />
}<br />
</syntaxhighlight><br />
<br />
=== Strings ===<br />
<br />
Natürlich können auch Strings im Flash abgelegt werden und auch mit Funktionen wie <tt>strcpy_P</tt> aus der avr-libc verarbeitet werden. Zudem ist es möglich, Flash-Zeiger mit der Adresse eines String-Literals zu initialisieren:<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
#define FSTR(X) ((const __flash char[]) { X } )<br />
<br />
const __flash char * const __flash array[] = <br />
{<br />
FSTR ("Hund"), FSTR ("Katze"), FSTR ("Maus")<br />
};<br />
<br />
size_t get_len (uint8_t tier)<br />
{<br />
return strlen_P (array[tier]);<br />
}<br />
</syntaxhighlight><br />
<br />
Leider sieht der Embedded-C Draft nicht vor, String-Literale direkt in einem anderen Adress-Space als ''generic'' anzulegen, so dass hier der Umweg über <tt>FSTR</tt> genommen werden muss. Dieses Konstrukt ist nur ausserhalb von Funktionen möglich und kann daher nicht als Ersatz für <tt>PSTR</tt> aus der avr-libc dienen.<br />
<br />
Soll <tt>array</tt> ein 2-dimensonales Array sein anstatt ein 1-dimensionales Array von Zeigern, dann geht das ohne große Verrenkungen:<br />
<br />
<syntaxhighlight lang="c"><br />
// Die 6 ergibt sich aus 1 plus der Länge des längsten Strings "Katze"<br />
const __flash char array[][6] = <br />
{<br />
"Hund", "Katze", "Maus"<br />
};<br />
</syntaxhighlight><br />
<br />
Weiters besteht die Möglichkeit, <tt>array</tt> analog anzulegen, wie man es mit <tt>PROGMEM</tt> machen würde: Jeder String wird explizit angelegt und seine Adresse bei der Initialisierung von <tt>array</tt> verwendet. Dies entspricht dem ersten Beispiel eines 1-dimensionalen Zeigerarrays:<br />
<br />
<syntaxhighlight lang="c"><br />
static const __flash char strHund[] = "Hund";<br />
static const __flash char strKatze[] = "Katze";<br />
static const __flash char strMaus[] = "Maus";<br />
<br />
const __flash char * const __flash array[] = <br />
{<br />
strHund, strKatze, strMaus<br />
};<br />
</syntaxhighlight><br />
<br />
=== Casts ===<br />
<br />
Embedded C fordert, dass zwei Adress-Spaces entweder disjunkt sind – d.h. sie enthalten keine gemeinsamen Adressen – oder aber ein Space komplett im anderen enthalten ist, also eine Teilmengen-Beziehung besteht. Die Adress-Spaces von avr-gcc sind so implementiert, dass jeder Space Teilmenge jedes anderes ist. Zwar haben Spaces wie RAM und Flash physikalisch keinen Speicherbereich gemein, allerdings ermöglicht diese Implementierung das Casten von Zeigern zu unterschiedlichen Adress-Spaces<ref>Im Gegensatz zu einem Attribute wie <tt>progmem</tt> ist ein (Adress Space) Qualifier Teil des Zeiger-Typs.</ref>: <br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdbool.h><br />
<br />
char read_char (const char *address, bool data_in_flash)<br />
{<br />
if (data_in_flash)<br />
return *(const __flash char*) address;<br />
else<br />
return *address;<br />
}<br />
</syntaxhighlight><br />
<br />
Der Cast selbst erzeugt keinen zusätzlichen Code, da eine RAM-Adresse und eine Flash-Adresse die gleiche Binärdarstellung haben. Allerdings wird über den nach <tt>__flash</tt> gecasteten Zeiger anders zugegriffen, nämlich per LPM.<br />
<br />
=== Jenseits von __flash ===<br />
<br />
Ausser <tt>__flash</tt> gibt es auch folgende Address-Spaces:<br />
<br />
==== <tt>__flash</tt>''N'' ====<br />
<br />
<tt>__flash</tt>''N'' mit ''N'' = 1..5 sind fünf weitere Spaces, die analog zu <tt>__flash</tt> funktionieren und deren Zeiger ebenfalls 16 Bit breit sind. avr-gcc erwartet, dass die zugehörigen Daten, welche in die Section <tt>.progmem</tt>''N''<tt>.data</tt> abgelegt werden, so lokatiert sind, dass das high-Byte der Adresse (Bits 16..23) gerade ''N'' ist.<br />
<br />
Weil Daten- und Code-Layout höchst projektspezifisch sind, werden diese Sections im Standard Linker-Skript nicht beschrieben. Um funktionsfähigen Code zu erhalten, muss daher ein eigenes Linker-Skript zur Verfügung gestellt werden, das diese Sections beschreibt, oder es kann eine Erweiterung des Standard Skripts bereitgestellt werden falls dies möglich ist.<br />
<br />
;Beispiel: Eine Applikation, die <tt>__flash2</tt> verwendet. Die zugehörende Section <tt>.progmem2.data</tt> wird hinter <tt>.text</tt> angeordnet aber vor den Initializern für <tt>.data</tt>. Dazu wird beim Linken das ld-Skript Fragment per <tt>-Tflash12.ld</tt> angegeben, welches dann an der gewünschten Stelle in das default Skript eingefügt wird:<br />
:{| <!-- Tabelle bitte für korrekte Einrückung belassen --><br />
|-<br />
|<pre><br />
SECTIONS<br />
{<br />
.flash2 :<br />
{<br />
. = MAX (ABSOLUTE(0x20000), .);<br />
PROVIDE (__flash2_start = .);<br />
. = ALIGN(2);<br />
*(.flash2.text*)<br />
*(.progmem2.data*)<br />
PROVIDE (__flash2_end = .);<br />
<br />
ASSERT (__flash2_start == __flash2_end || __flash2_start >= ABSOLUTE(0x20000),<br />
"__flash2 data in .progmem2.data below 0x20000");<br />
ASSERT (__flash2_start == __flash2_end || __flash2_end <= ABSOLUTE(0x30000),<br />
"__flash2 data in .progmem2.data exceeds 0x30000");<br />
}<br />
}<br />
INSERT AFTER .text<br />
</pre><br />
|}<br />
<br />
==== <tt>__memx</tt> ====<br />
<br />
Dieser Address-Space implementiert 3-Byte Zeiger und unterstützt Lesen über 64KiB-Segmentgrenzen hinweg. Das MSB (Bit 23) gibt dabei an, ob der <tt>__memx</tt>-Zeiger eine Flash-Adresse enthält (Bit23 = 0) oder eine RAM-Adresse (Bit23 = 1), was folgenden Code erlaubt:<br />
<br />
<syntaxhighlight lang="c"><br />
const __memx int a_flash = 42;<br />
const int a_ram = 100;<br />
<br />
int get_a (const __memx int* pa)<br />
{<br />
return *pa;<br />
}<br />
<br />
int main (void)<br />
{<br />
return get_a (&a_flash) + get_a (&a_ram);<br />
}</syntaxhighlight><br />
<br />
Dies bedeutet, dass erst zur ''Laufzeit'' entschieden werden kann, ob <tt>get_a</tt> die Daten aus dem RAM oder aus dem Flash lesen soll, was <tt>__memx</tt> im Vergleich zu den anderen Address-Spaces langsamer macht. Ausserdem ist zu beachten, dass <tt>__memx</tt>-Zeiger zwar 24-Bit Zeiger sind, die zugrundeliegende Adress-Arithmetik jedoch gemäß dem C-Standard erfolgt, also als 16-Bit Arithmetik. Bestehende Funktion der avr-libc wie z.B. printf_P funktionieren damit ebensowenig wie printf! Wenn man <tt>__memx</tt> verwenden will, braucht man dafür eigene Funktionen.<br />
<br />
=== __flash, progmem und Portierbarkeit ===<br />
<br />
Da ab er aktuellen Compilerversion 4.7 sowohl <tt>__flash</tt> als auch <tt>PROGMEM</tt> und die <tt>pgm_read</tt>-Funktionen zur Verfügung stehen, ergibt sich die Frage, welche Variante "besser" ist und wie zwischen ihnen hin- und her zu portieren ist.<br />
<br />
Zunächst sei erwähnt, dass <tt>__flash</tt> kein Ersatz für <tt>PROGMEM</tt> ist, sondern lediglich eine Alternative dazu. Das "alte" progmem wird weiterhin mir gleicher Semantik unterstützt, so dass alter Code ohne Änderungen mit den neueren Compilerversionen übersetzbar bleibt.<br />
<br />
Von der Codegüte her dürften sich keine großen Unterschiede ergeben. Es ist nicht zu erwarten, dass die eine oder die andere Variante wesentlich besseren oder schlechteren Code erzeugt — von einer Ausnahme abgesehen: Der Wert beim Zugriff ist zur Compilezeit bekannt und kann daher eliminiert werden.<br />
<syntaxhighlight lang="c"><br />
static const __flash char x[] = { 'A', 'V', 'R' };<br />
<br />
char foo (void)<br />
{<br />
return x[2];<br />
}<br />
</syntaxhighlight><br />
Dies wird übersetzt wie "<tt>return 'R';</tt>", und das Array <tt>x[]</tt> kann komplett wegoptimiert werden und entfallen.<br />
<br />
==== progmem → __flash ====<br />
<br />
Portierung in diese Richtung bedeutet, alten Code anzupassen. Zwingend ist die Portierung nicht, da <tt>progmem</tt> weiterhin unterstützt wird.<br />
Allerdings ist eine Quelle mit <tt>__flash</tt> besser lesbar, denn der Code wird von den <tt>pgm_read</tt>-Funktionen befreit, die vor allem bei Mehrfach-Indirektion den Code ziemlich verunstalten und unleserlich machen können.<br />
Weiterer Vorteil von <tt>_flash</tt> ist, daß eine striktere Typprüfung erfolgen kann.<br />
<br />
Eine Portierung wird man in zwei Schritten vornehmen:<br />
<br />
;1. Definitionen von Flash-Variablen werden angepasst:<br />
<br />
Vorher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
static const char hund[] PROGMEM = "Hund";<br />
static const char katze[] PROGMEM = "Katze";<br />
static const char maus[] PROGMEM = "Maus";<br />
<br />
const char * const tier[] PROGMEM = <br />
{<br />
hund, katze, maus<br />
};<br />
</syntaxhighlight><br />
|}<br />
<br />
Nachher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
static const __flash char hund[] = "Hund";<br />
static const __flash char katze[] = "Katze";<br />
static const __flash char maus[] = "Maus";<br />
<br />
const __flash char * const __flash tier[] = <br />
{<br />
hund, katze, maus<br />
};<br />
</syntaxhighlight><br />
|}<br />
<br />
Der Header <tt>avr/pgmspace.h</tt> wird nicht mehr benötigt. Im Gegensatz zu <tt>progmem</tt> müssen Qualifier immer links von der definierten Variablen stehen; bei Attributen wie <tt>progmem</tt> ist das mehr oder weniger egal.<br />
<br />
Nachdem diese Anpassung erfolgreich abgeschlossen ist, folgt Schritt<br />
<br />
; 2. Der Code wird von <tt>pgm_read</tt>-Aufrufen bereinigt:<br />
<br />
Vorher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
extern const char *tier[];<br />
<br />
char first_letter (uint8_t i)<br />
{<br />
const char* ptier = (const char*) pgm_read_word (&tier[i]);<br />
return (char) pgm_read_byte (&ptier[0]);<br />
}<br />
</syntaxhighlight><br />
|}<br />
<br />
Nachher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <stdint.h><br />
<br />
extern const __flash char * const __flash tier[];<br />
<br />
char first_letter (uint8_t i)<br />
{<br />
return tier[i][0];<br />
}<br />
</syntaxhighlight><br />
|}<br />
<br />
== Dateien direkt im Flash einbinden ==<br />
<br />
Wenn man größere Dateien direkt im Programm einbinden will, ohne sie vorher in C Quelltext umzuwandeln, muss man das mit dem Linker machen. Wie das geht steht hier.<br />
<br />
* [http://www.atmel.com/webdoc/avrlibcreferencemanual/FAQ_1faq_binarydata.html Atmel, avr gcc Dokumentation]<br />
* [http://nongnu.org/avr-libc/user-manual/FAQ.html#faq_binarydata Nongnu avr gcc Dokumentation]<br />
<br />
Wie man das dann praktisch umsetzt, sieht man in diesem Beitrag.<br />
<br />
* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056910 Forumsbeitrag]: Binärdateien mittels Linker einbinden<br />
* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056947 Forumsbeitrag]: Ein kleines Tool zum Umwandeln von Binärdateien in C-Quelltext.<br />
<br />
== Flash in der Anwendung schreiben ==<br />
<br />
Bei AVRs mit "self-programming"-Option – auch bekannt als [[Bootloader]]-Support – können Teile des Flash-Speichers vom Anwendungsprogramm beschrieben werden. Dies ist nur möglich, wenn die Schreibfunktion in einem besonderen Speicherbereich, der Boot-Section des Programmspeichers/Flash, abgelegt ist.<br />
<br />
Bei einigen kleinen AVRs gibt es keine gesonderte Boot-Section, bei diesen kann der Flashspeicher von jeder Stelle des Programms geschrieben werden. Für Details sei hier auf das jeweilige Controller-Datenblatt und die Erläuterungen zum Modul boot.h der avr-libc verwiesen. Es existieren auch Application-Notes dazu bei atmel.com, die auf avr-gcc-Code übertragbar sind.<br />
<br />
Siehe auch: <br />
* Forumsbeitrag [http://www.mikrocontroller.net/topic/163632#1561622 Daten in Programmspeicher speichern]<br />
<br />
== EEPROM ==<br />
<br />
Möchte man Werte aus einem Programm heraus so speichern, dass sie auch nach dem Abschalten der Versorgungsspannung noch erhalten bleiben und nach dem Wiederherstellen der Versorgungsspannung bei erneutem Programmstart wieder zur Verfügung stehen, dann benutzt man das EEPROM.<br />
<br />
Schreib- und Lesezugriffe auf den EEPROM-Speicher erfolgen über die im Modul eeprom.h der avr-libc definierten Funktionen. Mit diesen Funktionen können einzelne Bytes, Datenworte (16 Bit), Fließkommawerte (32 Bit, single-precision, float) und Datenblöcke geschrieben und gelesen werden.<br />
<br />
Diese Funktionen kümmern sich auch um diverse Details, die bei der Benutzung des EEPROMs normalerweise notwendig sind:<br />
* EEPROM-Operationen sind im Vergleich relativ langsam. Man muss daher darauf achten, dass eine vorhergehende Operation abgeschlossen ist, ehe die nächste Operation mit dem EEPROM gestartet wird. Die in der avr-libc implementierten Funktionen aus eeprom.h berücksichtigten dies. Soll beim Aufruf einer EEPROM-Funktion sichergestellt werden, dass diese nicht intern in einer Warteschleife auf den Abschluss der vorherigen Operation wartet, kann vorher per eeprom_is_ready testen, ob der Zugriff auf den EEPROM-Speicher sofort möglich ist.<br />
* Es ist darauf zu achten, dass die EEPROM-Funktionen nicht durch einen Interrupt unterbrochen werden. Einige Phasen des Zugriffs sind zeitkritisch und müssen in einer definierten bzw. begrenzten Anzahl von Takten durchgeführt werden. Durch einen unterbrechenden Interrupt würde diese Restriktion nicht mehr eingehalten. Auch dieses Detail wird von den avr-libc Funktionen berücksichtigt, so dass man sich als C-Programmierer nicht darum kümmern muss. Innerhalb der Funktionen werden Interrupts vor der "EEPROM-Sequenz" global deaktiviert und im Anschluss, falls vorher auch schon eingeschaltet, wieder aktiviert.<br />
<br />
Man beachte, dass der EEPROM-Speicher nur eine begrenzte Anzahl von Schreibzugriffen zulässt. Beschreibt man eine EEPROM-Zelle öfter als die im Datenblatt zugesicherte Anzahl (typisch 100.000), wird die Funktion der Zelle nicht mehr garantiert. Dies gilt für jede einzelne Zelle. <br />
<br />
Bei geschickter Programmierung (z.&nbsp;B. Ring-Puffer), bei der die zu beschreibenden Zellen regelmäßig gewechselt werden, kann man eine deutlich höhere Anzahl an Schreibzugriffen, bezogen auf den gesamten EEPROM-Speicher, erreichen. Auf jeden Fall sollte man aber eine Abschätzung über die zu erwartende Lebensdauer des EEPROM durchführen. Wird ein Wert im EEPROM im Durchschnitt nur einmal pro Woche verändert, wird die garantierte Anzahl der Schreibzyklen innerhalb der voraussichtlichen Verwendungszeit des Controllers sicherlich nicht erreicht werden. Welcher Controller ist schon 100000 / 52 = 1923 Jahre im Einsatz? In diesem Fall lohnt es sich daher nicht, erweiterte Programmfunktionen zu implementieren, mit denen die Anzahl der Schreibzugriffe minimiert wird.<br />
<br />
Eine weitere Möglichkeit, Schreibzyklen einzusparen, besteht in der Vorabprüfung, ob der zu speichernde Wert im EEPROM bereits enthalten ist und nur veränderte Werte zu schreiben. In aktuelleren Versionen der avr-libc sind bereits Funktionen enthalten, die solche Prüfungen enthalten (eeprom_update_*).<br />
<br />
Eine dritte Möglichkeit speichert alle Daten zunächst im RAM, wo sie beliebig oft beschrieben werden können. Nur beim Ausschalten oder beim Ausfall der Stromversorgung werden die Daten in den EEPROM geschrieben. Wie man das richtig macht sieht man im Artikel [[Speicher#EEPROM Schreibzugriffe minimieren | Speicher]].<br />
<br />
Lesezugriffe können beliebig oft durchgeführt werden. Sie unterliegen keinen Einschränkungen in Bezug auf deren Anzahl. <br />
<br />
=== EEMEM ===<br />
Um eine Variable im EEPROM anzulegen, stellt die avr-libc das Makro EEMEM zur Verfügung:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdint.h><br />
#include <avr/eeprom.h><br />
<br />
/* Byte */<br />
uint8_t eeFooByte EEMEM = 123;<br />
<br />
/* Wort */<br />
uint16_t eeFooWord EEMEM = 12345;<br />
<br />
/* float */<br />
float eeFooFloat EEMEM;<br />
<br />
/* Byte-Array */<br />
uint8_t eeFooByteArray1[] EEMEM = { 18, 3, 70 };<br />
uint8_t eeFooByteArray2[] EEMEM = { 30, 7, 79 };<br />
<br />
/* 16-bit unsigned short feld */<br />
uint16_t eeFooWordArray1[4] EEMEM;<br />
</syntaxhighlight><br />
<br />
Die grundsätzliche Vorgehensweise ist identisch zur Verwendung von PROGMEM. Auch hier erzeugt man sich spezielle attributierte Variablen (EEMEM erledigt das), die vom Compiler/Linker nicht wie normale Variablen behandelt werden. Compiler/Linker kümmern sich zwar darum, dass diesen Variablen eine Adresse zugewiesen wird, diese Adresse ist dann aber die Adresse der 'Variablen' im EEPROM. Um die dort gespeicherten Werte zu lesen bzw. zu schreiben, übergibt man diese Adresse an spezielle Funktionen, die die entsprechenden Werte aus dem EEPROM holen bzw. das EEPROM neu beschreiben.<br />
<br />
Die mittels EEMEM erzeugten 'Variablen' sind also mehr als Platzhalter zu verstehen, denn als echte Variablen. Es geht nur darum, im C-Programm symbolische Namen zur Verfügung zu haben, anstatt mit echten EEPROM-Adressen hantieren zu müssen, etwas, das grundsätzlich aber auch genauso gut möglich ist. Nur muss man sich in diesem Fall dann selbst darum kümmern, dass mehrere 'Variablen' ohne Überschneidung im EEPROM angeordnet werden.<br />
<br />
=== Bytes lesen/schreiben ===<br />
<br />
Die avr-libc Funktion zum Lesen eines Bytes heißt eeprom_read_byte. Parameter ist die Adresse des Bytes im EEPROM. Geschrieben wird über die Funktion eeprom_write_byte mit den Parametern Adresse und Inhalt. Anwendungsbeispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#define EEPROM_DEF 0xFF<br />
<br />
void eeprom_example (void)<br />
{<br />
uint8_t myByte;<br />
<br />
// myByte lesen (Wert = 123)<br />
myByte = eeprom_read_byte (&eeFooByte);<br />
<br />
// der Wert 99 wird im EEPROM an die Adresse der<br />
// Variablen eeFooByte geschrieben<br />
myByte = 99;<br />
eeprom_write_byte(&eeFooByte, myByte); // schreiben<br />
<br />
myByte = eeprom_read_byte (&eeFooByteArray1[1]); <br />
// myByte hat nun den Wert 3<br />
<br />
// Beispiel fuer eeprom_update_byte: die EEPROM-Zelle wird nur<br />
// dann beschrieben, wenn deren Inhalt sich vom Parameterwert<br />
// unterscheidet. In diesem Beispiel erfolgt also kein Schreib-<br />
// zugriff, da die Werte gleich sind.<br />
eeprom_update_byte(&eeFooByte, myByte);<br />
<br />
<br />
// Beispiel zur "Sicherung" gegen leeres EEPROM nach "Chip Erase"<br />
// (z. B. wenn die .eep-Datei nach Programmierung einer neuen Version<br />
// des Programms nicht in den EEPROM uebertragen wurde und EESAVE<br />
// deaktiviert ist (unprogrammed/1)<br />
// <br />
// Vorsicht: wenn EESAVE "programmed" ist, hilft diese Sicherung nicht<br />
// weiter, da die Speicheraddressen in einem neuen/erweiterten Programm<br />
// moeglicherweise verschoben wurden. An der Stelle &eeFooByte steht<br />
// dann u.U. der Wert einer anderen Variable aus einer "alten" Version.<br />
<br />
uint8_t fooByteDefault = 222;<br />
if ((myByte = eeprom_read_byte (&eeFooByte)) == EEPROM_DEF)<br />
{<br />
myByte = fooByteDefault;<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
=== Wort lesen/schreiben ===<br />
<br />
Schreiben und Lesen von Datenworten erfolgt analog zur Vorgehensweise bei Bytes:<br />
<br />
<syntaxhighlight lang="c"><br />
// lesen<br />
uint16_t myWord = eeprom_read_word (&eeFooWord);<br />
<br />
// schreiben<br />
eeprom_write_word (&eeFooWord, 2222);<br />
</syntaxhighlight><br />
<br />
=== Block lesen/schreiben ===<br />
<br />
Lesen und Schreiben von Datenblöcken erfolgt über die Funktionen <code>eeprom_read_block()</code> bzw. <code>eeprom_write_block()</code>. Die Funktionen erwarten drei Parameter: die Adresse der Quell- bzw. Zieldaten im RAM, die EEPROM-Adresse und die Länge des Datenblocks in Bytes als <code>size_t</code>.<br />
<syntaxhighlight lang="c"><br />
uint8_t myByteBuffer[3];<br />
uint16_t myWordBuffer[4];<br />
<br />
void eeprom_block_example (void)<br />
{<br />
/* Datenblock aus EEPROM lesen */<br />
<br />
/* liest 3 Bytes ab der von eeFooByteArray1 definierten EEPROM-Adresse<br />
in das RAM-Array myByteBuffer */<br />
eeprom_read_block (myByteBuffer, eeFooByteArray1, 3);<br />
<br />
/* dito mit etwas Absicherung betr. der Länge */<br />
eeprom_read_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));<br />
<br />
/* und nun mit 16-Bit Array */<br />
eeprom_read_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));<br />
<br />
/* Datenblock in EEPROM schreiben */<br />
eeprom_write_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));<br />
eeprom_write_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));<br />
}<br />
</syntaxhighlight><br />
<br />
=== Fließkommawerte lesen/schreiben ===<br />
<br />
In der avr-libc stehen auch EEPROM-Funktionen für Variablen des Typs float (Fließkommazahlen mit "einfacher" Genauigkeit) zur Verfügung.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/eeprom.h><br />
<br />
float eeFloat EEMEM = 12.34f;<br />
<br />
float void eeprom_float_example(float value)<br />
{<br />
/* float in EEPROM schreiben */<br />
eeprom_write_float(&eeFloat, value);<br />
<br />
/* float aus EEPROM lesen */<br />
return eeprom_read_float(&eeFloat);<br />
}</syntaxhighlight><br />
<br />
=== EEPROM-Speicherabbild in .eep-Datei ===<br />
<br />
Mit den zum Compiler gehörenden Werkzeugen kann der aus den Variablendeklarationen abgeleitete EEPROM-Inhalt in eine Datei geschrieben werden. Die übliche Dateiendung ist .eep, Daten im Intel Hex-Format. Damit können Standardwerte für den EEPROM-Inhalt im Quellcode definiert werden. <br />
<br />
Makefiles nach WinAVR/MFile-Vorlage enthalten bereits die notwendigen Einstellungen, siehe dazu die Erläuterungen im [[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]].<br />
<br />
Der Inhalt der eep-Datei muss ebenfalls zum Mikrocontroller übertragen werden, wenn die Initialisierungswerte aus der Deklaration vom Programm erwartet werden. Ansonsten enthält der EEPROM-Speicher nach der Übertragung des Programmers mittels ISP abhängig von der Einstellung der EESAVE-Fuse<ref>vgl. Datenblatt Abschnitt Fuse Bits</ref> nicht die korrekten Werte:<br />
; EESAVE = 0 (programmed): Die Daten im EEPROM bleiben erhalten. Werden sie nicht neu geschrieben, so enthält das EEPROM evtl. Daten, die nicht mehr zum Programm passen.<br />
; EESAVE = 1 (unprogrammed): Beim Programmieren werden die Daten im EEPROM gelöscht, also auf 0xff gesetzt.<br />
<br />
Als Sicherung kann man im Programm nochmals die Standardwerte vorhalten, beim Lesen auf 0xFF prüfen und gegebenenfalls einen Standardwert nutzen. Das geht natürlich nur, wenn 0xFF selbst nicht als Datenwert vorkommen kann.<br />
<syntaxhighlight lang="c"><br />
#define DUTY_CYCLE_DEFAULT 0x80<br />
<br />
uint8_t eeDutyCycle EEMEM; // Platzhalter für EEPROM<br />
uint8_t DutyCycle; // die echte Variable<br />
<br />
<br />
int main(void)<br />
{<br />
DutyCycle = eeprom_read_byte( &eeDutyCycle );<br />
if( DutyCycle == 0xFF ) // das allererste mal. Im EEPROM steht noch kein gültiger Wert<br />
{<br />
DutyCycle = DUTY_CYCLE_DEFAULT;<br />
eeprom_writeByte( &eeDutyCycle, DutyCycle );<br />
}<br />
<br />
...<br />
</syntaxhighlight><br />
<br />
=== Direkter Zugriff auf EEPROM-Adressen ===<br />
<br />
Will man direkt auf bestimmte EEPROM Adressen zugreifen, dann sind folgende IAR-kompatiblen Makros <tt>_EEGET</tt> und <tt>_EEPUT</tt> hilfreich, um sich die Typecasts zu ersparen.<br />
<br />
;Hinweis: Die nachfolgend gezeigten Makros und Zugriffe auf absolute Adressen sind in Normalfall nicht nötig und nur auf sehr wenige, spezielle Fälle beschränkt! Im Normalfall sollte man auf absolute Adressen möglichst nicht zugreifen und den Compiler seine Arbeit machen lassen, der verwaltet die Variablen und deren Adressen meist besser als der Programmierer. Der Zugriff auf Variablen im EEPROM sollte immer über ihren Namen erfolgen.<br />
<br />
Verwendung:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/eeprom.h><br />
<br />
_EEPUT (0x20, 128); // Byte-Wert 128 an Adresse 0x20 schreiben<br />
...<br />
uint8_t val = _EEGET (0x20); // EEPROM-Wert von Adresse 0x20 lesen<br />
</syntaxhighlight><br />
<br />
=== Was steckt dahinter? - EEPROM-Register ===<br />
Auch wenn es normalerweise keinen Grund gibt, in C selbst an den Steuerregistern herumzuschrauben - die eeprom Funktionen erledigen das alles zuverlässig - der Vollständigkeit halber der registermässige technische Unterbau.<br />
Um das EEPROM anzusteuern, sind drei Register von Bedeutung:<br />
;EEAR: Hier werden die Adressen eingetragen zum Schreiben oder Lesen. Dieses Register unterteilt sich nochmal in EEARH und EEARL, da in einem 8-Bit-Register keine 512 Adressen adressiert werden können.<br />
;EEDR: Hier werden die Daten eingetragen, die geschrieben werden sollen, bzw. es enthält die gelesenen Daten.<br />
;EECR: Ist das Kontrollregister für das EEPROM<br />
<br />
Das EECR steuert den Zugriff auf das EEPROM und ist wie folgt aufgebaut:<br />
<br />
:{| class="wikitable" style="text-align:center"<br />
|+ '''Aufbau des EECR-Registers'''<br />
|-<br />
!Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|-<br />
! Name<br />
| - || - || - ||- || EERIE || EEMWE || EEWE || EERE<br />
|-<br />
! Read/Write<br />
| R || R || R || R || R/W || R/W || R/W || R/W<br />
|-<br />
!Init Value<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''Bedeutung der Bits'''<br />
<br />
;Bit 4-7: nicht belegt<br />
<br />
;Bit 3 (EERIE): ''EEPROM Ready Interrupt Enable'': Wenn das Bit gesetzt ist und globale Interrupts erlaubt sind in Register SREG (Bit 7), wird ein Interrupt ausgelöst nach Beendigung des Schreibzyklus (EEPROM Ready Interrupt). Ist einer der beiden Bits 0, wird kein Interrupt ausgelöst.<br />
<br />
;Bit 2 EEMWE): ''EEPROM Master Write Enable'': Dieses Bit bestimmt, dass, wenn EEWE = 1 gesetzt wird (innerhalb von 4 Taktzyklen), das EEPROM beschrieben wird mit den Daten in EEDR bei Adresse EEAR. Wenn EEMWE = 0 ist und EEWE = 1 gesetzt wird, hat das keine Auswirkungen. Der Schreibvorgang wird dann nicht ausgelöst. Nach 4 Taktzyklen wird das Bit EEMWE automatisch wieder auf 0 gesetzt. Dieses Bit löst den Schreibvorgang nicht aus, es dient sozusagen als Sicherungsbit für EEWE.<br />
<br />
;Bit 1 (EEWE): ''EEPROM Write Enable'': Dieses Bit löst den Schreibvorgang aus, wenn es auf 1 gesetzt wird, sofern vorher EEMWE gesetzt wurde und seitdem nicht mehr als 4 Taktzyklen vergangen sind. Wenn der Schreibvorgang abgeschlossen ist, wird dieses Bit automatisch wieder auf 0 gesetzt und, sofern EERIE gesetzt ist, ein Interrupt ausgelöst. Ein Schreibvorgang sieht typischerweise wie folgt aus:<br />
:# EEPROM-Bereitschaft abwarten (EEWE=0) <br />
:# Adresse übergeben an EEAR<br />
:# Daten übergeben an EEDR<br />
:# Schreibvorgang auslösen in EECR mit Bit EEMWE=1 und EEWE=1<br />
:# (Optional) Warten, bis Schreibvorgang abgeschlossen ist<br />
<br />
;Bit 0 EERE: ''EEPROM Read Enable'': Wird dieses Bit auf 1 gesetzt wird das EEPROM an der Adresse in EEAR ausgelesen und die Daten in EEDR gespeichert. Das EEPROM kann nicht ausgelesen werden, wenn bereits eine Schreiboperation gestartet wurde. Es ist daher zu empfehlen, die Bereitschaft vorher zu prüfen. Das EEPROM ist lesebereit, wenn das Bit EEWE=0 ist. Ist der Lesevorgang abgeschlossen, wird das Bit wieder auf 0 gesetzt, und das EEPROM ist für neue Lese- und Schreibbefehle wieder bereit. Ein typischer Lesevorgang kann wie folgt aufgebaut sein:<br />
:# Bereitschaft zum Lesen prüfen (EEWE=0)<br />
:# Adresse übergeben an EEAR<br />
:# Lesezyklus auslösen mit EERE = 1<br />
:# Warten, bis Lesevorgang abgeschlossen EERE = 0<br />
:# Daten abholen aus EEDR<br />
<br />
= Die Nutzung von sprintf und printf =<br />
<br />
Um komfortabel, d.h. formatiert, Ausgaben auf ein Display oder die serielle Schnittstelle zu tätigen, bieten sich '''sprintf''' oder '''printf''' an. Alle *printf-Varianten sind jedoch ziemlich speicherintensiv und der Einsatz in einem Mikrocontroller mit knappem Speicher muss sorgsam abgewogen werden.<br />
<br />
Bei '''sprintf''' wird die Ausgabe zunächst in einem Puffer vorbereitet und anschließend mit einfachen Funktionen zeichenweise ausgegeben. Es liegt in der Verantwortung des Programmierers, genügend Platz im Puffer für die erwarteten Zeichen bereitzuhalten.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdio.h><br />
#include <stdint.h><br />
<br />
// ...<br />
// nicht dargestellt: Implementierung von uart_puts (vgl. Abschnitt UART)<br />
// ...<br />
<br />
uint16_t counter;<br />
<br />
// Ausgabe eines unsigned Integerwertes<br />
void uart_puti( uint16_t value )<br />
{<br />
uint8_t puffer[20];<br />
<br />
sprintf( puffer, "Zählerstand: %u", value );<br />
uart_puts( puffer );<br />
}<br />
<br />
int main()<br />
{<br />
counter = 5;<br />
<br />
uart_puti( counter );<br />
uart_puti( 42 );<br />
}<br />
</syntaxhighlight><br />
<br />
Eine weitere elegante Möglichkeit besteht darin, den STREAM stdout (Standardausgabe) auf eine eigene Ausgabefunktion umzuleiten. Dazu wird dem Ausgabemechanismus der C-Bibliothek eine neue Ausgabefunktion bekannt gemacht, deren Aufgabe es ist, ein einzelnes Zeichen auszugeben. Wohin die Ausgabe dann tatsächlich stattfindet, ist Sache der Ausgabefunktion. Im Beispiel unten wird auf UART ausgegeben. Alle anderen, höheren Funktionen wie z.&nbsp;B. '''printf''', greifen letztendlich auf diese primitive Ausgabefunktion zurück. <br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdio.h><br />
<br />
void uart_init(void);<br />
<br />
// a. Deklaration der primitiven Ausgabefunktion<br />
int uart_putchar(char c, FILE *stream);<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 1)<br />
static FILE mystdout = FDEV_SETUP_STREAM( uart_putchar, NULL, _FDEV_SETUP_WRITE );<br />
<br />
// c. Definition der Ausgabefunktion<br />
int uart_putchar( char c, FILE *stream )<br />
{<br />
if( c == '\n' )<br />
uart_putchar( '\r', stream );<br />
<br />
loop_until_bit_is_set( UCSRA, UDRE );<br />
UDR = c;<br />
return 0;<br />
}<br />
<br />
void uart_init(void)<br />
{<br />
/* hier µC spezifischen Code zur Initialisierung */<br />
/* des UART einfügen... s.o. im AVR-GCC-Tutorial */<br />
<br />
// Beispiel: <br />
//<br />
// myAVR Board 1.5 mit externem Quarz Q1 3,6864 MHz<br />
// 9600 Baud 8N1<br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
// Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt)<br />
#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)<br />
<br />
UCSRB |= (1<<TXEN) | (1<<RXEN); // UART TX und RX einschalten<br />
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1 <br />
<br />
UBRRH = (uint8_t)( UART_UBRR_CALC( UART_BAUD_RATE, F_CPU ) >> 8 );<br />
UBRRL = (uint8_t)UART_UBRR_CALC( UART_BAUD_RATE, F_CPU );<br />
}<br />
<br />
int main(void)<br />
{<br />
int16_t antwort = 42;<br />
uart_init();<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 2)<br />
stdout = &mystdout;<br />
<br />
// Anwendung<br />
printf( "Die Antwort ist %d.\n", antwort );<br />
return 0;<br />
}<br />
<br />
// Quelle: avr-libc-user-manual-1.4.3.pdf, S.74<br />
// + Ergänzungen<br />
</syntaxhighlight><br />
<br />
<br />
Sollen Fließkommazahlen ausgegeben werden, muss im Makefile eine andere (größere) Version der [[FAQ#Aktivieren_der_Floating_Point_Version_von_sprintf_beim_WinAVR_mit_AVR-Studio|printflib]] eingebunden werden.<br />
<br />
= Anmerkungen =<br />
<references/><br />
<br />
= TODO =<br />
* Aktualisierung Register- und Bitbeschreibungen an aktuelle AVR<br />
* "naked"-Funktionen [http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html][http://arduino.stackexchange.com/questions/8758/arduino-interruption-on-pin-change]<br />
<br />
[[Kategorie:avr-gcc Tutorial| ]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR-GCC-Tutorial&diff=107257AVR-GCC-Tutorial2025-01-27T14:30:59Z<p>Heha: /* Was macht das Hauptprogramm? */</p>
<hr />
<div>Dieses Tutorial soll den Einstieg in die Programmierung von Atmel [[AVR]]-Mikrocontrollern in der Programmiersprache [[C]] mit dem freien C-Compiler [[avr-gcc]] aus der [http://gcc.gnu.org/ GNU Compiler Collection] (GCC) erleichtern.<br />
<br />
Vorausgesetzt werden Grundkenntnisse der Programmiersprache C. Diese Kenntnisse kann man sich online erarbeiten, z. B. mit dem [http://www.schellong.de/c.htm C Tutorial von Helmut Schellong] ([[C|Liste von C-Tutorials]]). Nicht erforderlich sind Vorkenntnisse in der Programmierung von Mikrocontrollern.<br />
<br />
= Vorwort =<br />
<br />
In diesem Text wird häufig auf die Standardbibliothek avr-libc verwiesen, für die es eine [http://www.nongnu.org/avr-libc/user-manual/index.html Online-Dokumentation] gibt, in der sich auch viele nützliche Informationen zum Compiler und zur Programmierung von AVR-Controllern finden. Beim Paket [[WinAVR]] gehört die avr-libc Dokumentation zum Lieferumfang und wird mitinstalliert.<br />
<br />
Der Compiler und die Standardbibliothek avr-libc werden ständig weiterentwickelt. Einige Unterschiede, die sich im Verlauf der Entwicklung ergeben haben, werden hier und im Artikel [[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen]] zwar angesprochen, Anfängern und Umsteigern sei jedoch empfohlen, eine aktuelle Versionen zu nutzen.<br />
<br />
Das ursprüngliche Tutorial stammt von Christian Schifferle, viele neue Abschnitte und aktuelle Anpassungen von Martin Thomas.<br />
<br />
Dieses Tutorial ist in [[Media:AVR-GCC-Tutorial.pdf|PDF-Form]] erhältlich (zur Zeit nur eine sehr veraltete Version).<br />
<br />
== Weiterführende Kapitel ==<br />
<br />
Um dieses riesige Tutorial etwas überschaubarer zu gestalten, wurden einige Kapitel ausgelagert, die nicht unmittelbar mit den Grundlagen von avr-gcc in Verbindung stehen. All diese Seiten gehören zur [[:Kategorie:avr-gcc Tutorial]].<br />
<br />
;UART: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der UART|Der UART]]''<br />
<br />
;ADC: → Hauptartikel: ''[[AVR-GCC-Tutorial/Analoge Ein- und Ausgabe|Analoge Ein- und Ausgabe (ADC)]]''<br />
<br />
;Timer: → Hauptartikel: ''[[AVR-GCC-Tutorial/Die Timer und Zähler des AVR|Die Timer und Zähler des AVR]]''<br />
<br />
;LCD: → Hauptartikel: ''[[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Ansteuerung]]''<br />
<br />
;Watchdog: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der Watchdog|Der Watchdog]]''<br />
<br />
;Assembler: → Hauptartikel: ''[[AVR-GCC-Tutorial/Assembler und Inline-Assembler|Assembler und Inline-Assembler]]''<br />
<br />
;alte Quellen anpassen: → Hauptartikel: ''[[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen anpassen]]''<br />
<br />
;Makefiles: → Hauptartikel: ''[[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]]'' sowie als Alternative für sehr kleine Projekte → Hauptartikel: ''[[C ohne Makefile]]''<br />
<br />
= Benötigte Werkzeuge =<br />
<br />
Um eigene Programme für AVRs mittels einer AVR-Toolchain zu erstellen wird folgende Hard- und Software benötigt:<br />
<br />
* Eine AVR-Toolchain bestehend aus avr-gcc, den avr-Binutils (Assembler, Linker, etc) und einer Standard-C Bibliothek. Üblich ist die AVR-LibC, die auch quasi in allen avr-gcc Distributionen enthalten ist.<br />
<br />
Hardware wird keine benötigt – bis auf einen PC natürlich, auf dem der Compiler ablaufen kann. Selbst ohne AVR-Hardware kann man also bereits C-Programme für AVRs schreiben, compiliern und sich das Look-and-Feel von avr-gcc sowie von IDEs wie [[Atmel Studio]], Eclipse oder leichtgewichtigeren Entwicklungsumbgebungen anschauen. Selbst das Debuggen und Simulieren ist mithilfe entsprechender Tools wie Debugger und Simulator in gewissen Grenzen möglich.<br />
<br />
Um Programme für AVRs mittels einer AVR-Toolchain zu testen, wird folgende Hard- und Software benötigt:<br />
<br />
* Platine oder Versuchsaufbau für die Aufnahme eines AVR-Controllers, der vom avr-gcc Compiler unterstützt wird.<ref>Für eine Liste der unterstützten COntroller siehe die Dokumentation des Compilers oder [http://www.nongnu.org/avr-libc/user-manual/index.html#supported_devices AVR-Libc: Supported Devices].</ref> Dieses Testboard kann durchaus auch selbst gelötet oder auf einem Steckbrett aufgebaut werden. Einige Registerbeschreibungen dieses Tutorials beziehen sich auf den inzwischen veralteten AT90S2313. Der weitaus größte Teil des Textes ist aber für alle Controller der AVR-Familie gültig. <br />
<br />
:Brauchbare Testplattformen sind auch das [[STK500]] und der [[AVR Butterfly]] von Atmel. Weitere Infos findet man in den Artikeln [[AVR#Starterkits|AVR Starterkits]] und [[AVR-Tutorial: Equipment]].<br />
<br />
* Programmiersoftware und -[[AVR In System Programmer |hardware]] z. B. PonyProg (siehe auch: [[Pony-Prog Tutorial]]) oder [[AVRDUDE]] mit [[STK200]]-Dongle oder die von Atmel verfügbare Hard- und Software ([[STK500]], Atmel AVRISP, [[AVR-Studio]]).<br />
<br />
* Nicht unbedingt erforderlich, aber zur Simulation und zum Debuggen unter MS-Windows recht nützlich: [[AVR-Studio]].<br />
<br />
* Wer unter Windows und Linux gleichermassen entwickeln will, der sollte sich die [http://www.eclipse.org/ IDE Eclipse for C/C++ Developers] und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] ansehen. Beide sind unter Windows und Linux einfach zu installieren, siehe auch [[AVR Eclipse]]. Ebenfalls unter Linux und Windows verfügbar ist die Entwicklungsumgebung [http://www.codeblocks.org/ Code::Blocks]<ref>Aktuelle, stabile Versionen sind als Nightly Builds regelmäßig im [http://forums.codeblocks.org/ Forum] verfügbar.</ref>. Innerhalb dieser Entwicklungsumgebung können ohne die Installation zusätzlicher Plugins "AVR-Projekte" angelegt werden. Für Linux gibt es auch noch das [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=25220 KontrollerLab].<br />
<br />
= Was tun, wenn's nicht klappt? =<br />
<br />
* Herausfinden, ob es tatsächlich ein avr(-gcc) spezifisches Problem ist oder nur die eigenen C-Kenntnisse einer Auffrischung bedürfen. Allgemeine C-Fragen kann man eventuell "beim freundlichen Programmierer zwei Büro-, Zimmer- oder Haustüren weiter" loswerden. Ansonsten: [[C]]-Buch (gibt's auch "gratis" online) lesen.<br />
<br />
* Die [[AVR Checkliste]] durcharbeiten.<br />
<br />
* Die '''[http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc]''' lesen, vor allem (aber nicht nur) den Abschnitt Related Pages/'''Frequently Asked Questions''' = Oft gestellte Fragen (und Antworten dazu). Z.Zt leider nur in englischer Sprache verfügbar.<br />
<br />
* Den Artikel [[AVR-GCC]] in diesem Wiki lesen.<br />
<br />
* Das [http://www.mikrocontroller.net/forum/gcc GCC-Forum auf www.mikrocontroller.net] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das avr-gcc-Forum bei [http://www.avrfreaks.net AVRfreaks] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das [http://lists.gnu.org/archive/html/avr-gcc-list/ Archiv der avr-gcc Mailing-Liste] nach vergleichbaren Problemen absuchen.<br />
<br />
* Nach Beispielcode suchen. Vor allem im ''Projects''-Bereich von [http://www.avrfreaks.net AVRfreaks] (anmelden).<br />
<br />
* Google oder yahoo befragen schadet nie.<br />
<br />
* Bei Problemen mit der Ansteuerung interner AVR-Funktionen mit C-Code: das Datenblatt des Controllers lesen (ganz und am Besten zweimal). Datenblätter sind auf den [http://www.atmel.com Atmel Webseiten] als pdf-Dateien verfügbar. Das komplette Datenblatt (complete) und nicht die Kurzfassung (summary) verwenden.<br />
<br />
* Die Beispielprogramme im [[AVR-Tutorial]] sind zwar in AVR-Assembler verfasst, Erläuterungen und Vorgehensweisen sind aber auch auf C-Programme übertragbar.<br />
<br />
* Einen Beitrag in eines der Foren oder eine Mail an die Mailing-Liste schreiben. Dabei möglichst viel Information geben: Controller, Compilerversion, genutzte Bibliotheken, Ausschnitte aus dem Quellcode oder besser ein [http://www.mikrocontroller.net/topic/72767#598986 Testprojekt] mit allen notwendigen Dateien, um das Problem nachzuvollziehen, sowie genaue Fehlermeldungen bzw. Beschreibung des Fehlverhaltens. Bei Ansteuerung externer Geräte die Beschaltung beschreiben oder skizzieren (z. B. mit [http://www.tech-chat.de/ Andys ASCII Circuit]). Siehe dazu auch: '''[http://www.tty1.net/smart-questions_de.html "Wie man Fragen richtig stellt"]'''.<br />
<br />
= Erzeugen von Maschinencode =<br />
<br />
Aus dem C-Quellcode erzeugt der avr-gcc Compiler (zusammen mit Hilfsprogrammen wie z.&nbsp;B. Präprozessor, Assembler und Linker) Maschinencode für den AVR-Controller. Üblicherweise liegt dieser Code dann im Intel Hex-Format vor ("Hex-Datei"). Die Programmiersoftware (z.&nbsp;B. [[AVRDUDE]], PonyProg oder AVRStudio/STK500-plugin) liest diese Datei ein und überträgt die enthaltene Information (den Maschinencode) in den Speicher des Controllers. Im Prinzip sind also "nur" der avr-gcc-Compiler (und wenige Hilfsprogramme) mit den "richtigen" Optionen aufzurufen, um aus C-Code eine "Hex-Datei" zu erzeugen. Grundsätzlich stehen dazu drei verschiedene Ansätze zur Verfügung:<br />
<br />
* Die Verwendung einer integrierten Entwicklungsumgebung (IDE = '''I'''ntegrated '''D'''evelopment '''E'''nvironment), bei der alle Einstellungen z.&nbsp;B. in Dialogboxen durchgeführt werden können. Unter Anderem kann AVRStudio ab Version 4.12 (kostenlos auf [http://www.atmel.com/ atmel.com]) zusammen mit WinAVR als integrierte Entwicklungsumgebung für den Compiler avr-gcc genutzt werden (dazu müssen AVRStudio und WinAVR auf dem Rechner installiert sein). Weitere IDEs (ohne Anspruch auf Vollständigkeit): [http://www.eclipse.org/ Eclipse for C/C++ Developers] (d.h. inkl. CDT) und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] (für diverse Plattformen, u.a. Linux und MS Windows, IDE und Plugin kostenlos), [http://sourceforge.net/projects/kontrollerlab KontrollerLab] (Linux/KDE, kostenlos). [http://www.atmanecl.com/EnglishSite/SoftwareEnglish.htm AtmanAvr] (MS Windows, relativ günstig), KamAVR (MS-Windows, kostenlos, wird augenscheinlich nicht mehr weiterentwickelt), [http://www.amctools.com/vmlab.htm VMLab] (MS Windows, ab Version 3.12 ebenfalls kostenlos). Integrierte Entwicklungsumgebungen unterscheiden sich stark in Ihrer Bedienung und stehen auch nicht für alle Plattformen zur Verfügung, auf denen der Compiler ausführbar ist (z.&nbsp;B. AVRStudio nur für MS-Windows). Zur Anwendung des avr-gcc Compilers mit IDEs sei hier auf deren Dokumentation verwiesen. <br />
<br />
* Die Nutzung des Programms make mit passenden Makefiles. In den folgenden Abschnitten wird die Generierung von Maschinencode für einen AVR ("hex-Datei") aus C-Quellcode ("c-Dateien") anhand von "make" und den "Makefiles" näher erläutert. Viele der darin beschriebenen Optionen findet man auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio (AVRStudio generiert ein makefile in einem Unterverzeichnis des Projektverzeichnisses). <br />
<br />
* Das Generieren des Programms ohne IDE und ohne Makefile. In diesem Fall muss die Quellcodedatei durch eine vorgefertigte Kommandofolge an den Compiler übergeben werden. Der Artikel [[C ohne Makefile]] zeigt, wie das funktioniert. Diese Vorgehensweise empfiehlt sich jedoch nur für kleine Programme, die nicht auf verschiedene Quellcodedateien verteilt sind.<br />
<br />
Beim Wechsel vom makefile-Ansatz nach WinAVR-Vorlage zu AVRStudio ist darauf zu achten, dass AVRStudio (Stand: AVRStudio Version 4.13) bei einem neuen Projekt die Optimierungsoption (vgl. Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|AVR-GCC-Tutorial/Exkurs: Makefiles]], typisch: -Os) nicht einstellt und die mathematische Bibliothek der avr-libc (libm.a, Linker-Option -lm) nicht einbindet. (Hinweis: Bei Version 4.16 wird beides bereits gesetzt). Beides ist Standard bei Verwendung von makefiles nach WinAVR-Vorlage und sollte daher auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio "manuell" eingestellt werden, um auch mit AVRStudio kompakten Code zu erzeugen.<br />
<br />
= Einführungsbeispiel =<br />
<br />
Zum Einstieg ein kleines Beispiel, an dem die Nutzung des Compilers und der Hilfsprogramme (der sogenannten ''Toolchain'') demonstriert wird. Detaillierte Erläuterungen folgen in den weiteren Abschnitten dieses Tutorials.<br />
<br />
Das Programm soll auf einem AVR Mikrocontroller einige Ausgänge ein- und andere ausschalten. Das Beispiel ist für einen ATmega16 programmiert ([http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf Datenblatt]), kann aber sinngemäß für andere Controller der AVR-Familie modifiziert werden. <br />
<br />
Ein kurzes Wort zur Hardware: Bei diesem Programm werden alle Pins von PORTB auf Ausgang gesetzt, und einige davon werden auf HIGH andere auf LOW gesetzt. Das kann je nach angeschlossener Hardware an diesen Pins kritisch sein. Am ungefährlichsten ist es, wenn nichts an den Pins angeschlossen ist und man die Funktion des Programmes durch eine Spannungsmessung mit einem Multimeter kontrolliert. Die Spannung wird dabei zwischen GND-Pin und den einzelnen Pins von PORTB gemessen.<br />
<br />
Zunächst der Quellcode der Anwendung, der in einer Text-Datei mit dem Namen ''main.c'' abgespeichert wird.<br />
<br />
<syntaxhighlight lang="c"><br />
/* Alle Zeichen zwischen Schrägstrich-Stern <br />
und Stern-Schrägstrich sind Kommentare */<br />
<br />
// Zeilenkommentare sind ebenfalls möglich<br />
// alle auf die beiden Schrägstriche folgenden<br />
// Zeichen einer Zeile sind Kommentar<br />
<br />
#include <avr/io.h> // (1)<br />
<br />
int main (void) { // (2)<br />
<br />
DDRB = 0xFF; // (3)<br />
PORTB = 0x03; // (4)<br />
<br />
while(1) { // (5)<br />
/* "leere" Schleife*/ // (6)<br />
} // (7)<br />
<br />
/* wird nie erreicht */<br />
return 0; // (8)<br />
}<br />
</syntaxhighlight><br />
<br />
# In dieser Zeile wird eine sogenannte Header-Datei eingebunden. In <code>avr/io.h</code> sind die Registernamen definiert, die im späteren Verlauf genutzt werden. Auch unter Windows wird ein&nbsp;<code>/</code> zur Kennzeichnung von Unterverzeichnissen in Include-Dateinamen verwendet und kein&nbsp;<code>\</code>.<br />
# Hier beginnt das eigentliche Programm. Jedes C-Programm beginnt mit den Anweisungen in der Funktion <code>main</code>.<br />
# Die Anschlüsse eines AVR (Pins) werden zu Blöcken zusammengefasst, einen solchen Block bezeichnet man als Port. Beim ATmega16 hat jeder Port 8 Anschlüsse, bei kleineren AVRs können einem Port auch weniger als 8 Anschlüsse zugeordnet sein. Da per Definition (Datenblatt) alle gesetzten Bits in einem Datenrichtungsregister den entsprechenden Anschluss auf Ausgang schalten, werden mit DDRB=0xff alle Anschlüsse des Ports B als Ausgänge eingestellt.<br />
# Die den ersten beiden Bits des Ports zugeordneten Anschlüsse (PB0 und PB1) werden 1, alle anderen Anschlüsse des Ports B (PB2-PB7) zu 0. Aktivierte Ausgänge (logisch 1 oder "high") liegen auf Betriebsspannung (VCC, meist 5 Volt), nicht aktivierte Ausgänge führen 0 Volt (GND, Bezugspotential). Es ist sinnvoll, sich möglichst frühzeitig eine alternative Schreibweise beizubringen, die wegen der leichteren Überprüfbarkeit und Portierbarkeit oft im weiteren Tutorial und in Forenbeiträgen benutzt wird. Die Zuordnung sieht in diesem Fall so aus, Näheres dazu im Artikel [[Bitmanipulation]]:<syntaxhighlight lang="c">PORTB = (1<<PB1) | (1<<PB0);</syntaxhighlight><br />
# ist der Beginn der sogenannte ''Hauptschleife'' (main-loop). Dies ist eine Endlosschleife, welche kontinuierlich wiederkehrende Befehle enthält.<br />
# In diesem Beispiel ist die Hauptschleife leer. Der Controller durchläuft die Schleife immer wieder, ohne dass etwas passiert. Eine solche Schleife ist notwendig, da es auf dem Controller kein Betriebssystem gibt, das nach Beendigung des Programmes die Kontrolle übernehmen könnte. Ohne diese Schleife kehrt das Programm aus <code>main</code> zurück, alle Interrupts werden deaktiviert und eine Endlosschleife betreten.<br />
# Ende der Hauptschleife und Sprung zur passenden, öffnenden Klammer, also zu 5.<br />
# ist das Programmende. Die Zeile ist nur aus Gründen der C-Kompatibilität enthalten: <syntaxhighlight lang="c">int main(void)</syntaxhighlight> besagt, dass die Funktion einen int-Wert zurückgibt. Die Anweisung wird aber nicht erreicht, da das Programm die Hauptschleife nie verlässt.<br />
<br />
Um diesen Quellcode in ein lauffähiges Programm zu übersetzen, wird hier ein Makefile genutzt. Das verwendete Makefile findet sich auf der Seite [[Beispiel Makefile]] und basiert auf der Vorlage, die in WinAVR mitgeliefert wird und wurde bereits angepasst (Controllertyp ATmega16). Man kann das Makefile bearbeiten und an andere Controller anpassen oder sich mit dem Programm MFile menügesteuert ein Makefile "zusammenklicken". Das Makefile speichert man unter dem Namen <code>Makefile</code> (ohne Endung) im selben Verzeichnis, in dem auch die Datei <code>main.c</code> mit dem Programmcode abgelegt ist. Detailliertere Erklärungen zur Funktion von Makefiles finden sich im Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|Exkurs: Makefiles]].<br />
<br />
<pre><br />
D:\beispiel>dir<br />
<br />
Verzeichnis von D:\beispiel<br />
<br />
28.11.2006 22:53 <DIR> .<br />
28.11.2006 22:53 <DIR> ..<br />
28.11.2006 20:06 118 main.c<br />
28.11.2006 20:03 16.810 Makefile<br />
2 Datei(en) 16.928 Bytes<br />
</pre><br />
<br />
Nun gibt man ''make all'' ein. Falls das mit WinAVR installierte Programmers Notepad genutzt wird, gibt es dazu einen Menüpunkt im Tools Menü. Sind alle Einstellungen korrekt, entsteht eine Datei <code>main.hex</code>, in welcher der Code für den AVR enthalten ist. <br />
<pre><br />
D:\beispiel>make all<br />
<br />
-------- begin --------<br />
avr-gcc (GCC) 3.4.6<br />
Copyright (C) 2006 Free Software Foundation, Inc.<br />
This is free software; see the source for copying conditions. There is NO<br />
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.<br />
<br />
Compiling C: main.c<br />
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -f<br />
unsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef<br />
-Wa,-adhlns=obj/main.lst -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c -<br />
o obj/main.o<br />
<br />
Linking: main.elf<br />
avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -funs<br />
igned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -W<br />
a,-adhlns=obj/main.o -std=gnu99 -Wundef -MD -MP -MF .dep/main.elf.d obj/main.o<br />
--output main.elf -Wl,-Map=main.map,--cref -lm<br />
<br />
Creating load file for Flash: main.hex<br />
avr-objcopy -O ihex -R .eeprom main.elf main.hex<br />
</pre><br />
<br />
Der Inhalt der hex-Datei kann nun zum Controller übertragen werden. Dies kann z.&nbsp;B. über In-System-Programming ([[ISP]]) erfolgen, das im [[AVR-Tutorial: Equipment]] beschrieben ist. Makefiles nach der WinAVR/MFile-Vorlage sind für die Nutzung des Programms [[AVRDUDE]] vorbereitet. Wenn man den Typ und Anschluss des Programmiergerätes richtig eingestellt hat, kann mit ''make program'' die Übertragung mittels AVRDUDE gestartet werden. Jede andere Software, die hex-Dateien lesen und zu einem AVR übertragen kann<ref>z.&nbsp;B. [[Pony-Prog_Tutorial|Ponyprog]], yapp, AVRStudio</ref>, kann natürlich ebenfalls genutzt werden.<br />
<br />
Startet man nun den Controller (Reset-Taster oder Stromzufuhr aus/an), werden vom Programm die Anschlüsse PB0 und PB1 auf 1 gesetzt. Man kann mit einem Messgerät nun an diesem Anschluss die Betriebsspannung messen oder eine [[LED]] leuchten lassen (Anode an den Pin, Vorwiderstand nicht vergessen). An den Anschlüssen PB2-PB7 misst man 0 Volt. Eine mit der Anode mit einem dieser Anschlüsse verbundene LED leuchtet nicht.<br />
<br />
= Ganzzahlige Datentypen (Integer) =<br />
<br />
Bei der Programmierung von Mikrokontrollern ist die Definition einiger ganzzahliger Datentypen sinnvoll, an denen eindeutig die Bit-Länge abgelesen werden kann.<br />
<br />
Standardisierte Datentypen werden in der Header-Datei <code>stdint.h</code> definiert, die folgendermaßen eingebunden werden kann:<br />
<syntaxhighlight lang="c">#include <stdint.h></syntaxhighlight><br />
<br />
{| {{Tabelle}}<br />
|+ '''int-Typen aus <code>stdint.h</code> (C99)'''<br/>&nbsp;<br />
|- bgcolor="#d0d0ff"<br />
!colspan="5"| Vorzeichenbehaftete int-Typen<br />
|- bgcolor="#e8e8ff"<br />
! Typname || Bit-Breite ||colspan="2"| Wertebereich<br />
|align="center| '''C-Entsprechung''' (avr-gcc)<br />
|-<br />
|<code>int8_t</code> ||align="right"| 8 || −128 ⋯ 127 || −2<sup>7</sup> ⋯ 2<sup>7</sup>−1 || <code>signed char</code><br />
|-<br />
|<code>int16_t</code> ||align="right"| 16 || −32768 ⋯ 32767 || −2<sup>15</sup> ⋯ 2<sup>15</sup>−1 || <code>signed short</code>, <code>signed int</code><br />
|-<br />
|<code>int32_t</code> ||align="right"| 32 || −2147483648 ⋯ 2147483647 || −2<sup>31</sup> ⋯ 2<sup>31</sup>−1 || <code>signed long</code><br />
|-<br />
|<code>int64_t</code> ||align="right"| 64 || −9223372036854775808 ⋯ 9223372036854775807 || −2<sup>63</sup> ⋯ 2<sup>63</sup>−1 || <code>signed long long</code><br />
|- bgcolor="#d0d0ff"<br />
!colspan="5"| Vorzeichenlose int-Typen<br />
|- bgcolor="#e8e8ff"<br />
! Typname || Bit-Breite ||colspan="2"| Wertebereich<br />
|align="center| '''C-Entsprechung''' (avr-gcc)<br />
|-<br />
|<code>uint8_t</code> ||align="right"| 8 || 0 ⋯ 255 || 0 ⋯ 2<sup>8</sup>−1 || <code>unsigned char</code><br />
|-<br />
|<code>uint16_t</code> ||align="right"| 16 || 0 ⋯ 65535 || 0 ⋯ 2<sup>16</sup>−1 || <code>unsigned short</code>, <code>unsigned int</code><br />
|-<br />
|<code>uint32_t</code> ||align="right"| 32 || 0 ⋯ 4294967295 || 0 ⋯ 2<sup>32</sup>−1 || <code>unsigned long</code><br />
|-<br />
|<code>uint64_t</code> ||align="right"| 64 || 0 ⋯ 18446744073709551615 || 0 ⋯ 2<sup>64</sup>−1 || <code>unsigned long long</code><br />
|}<br />
<br />
Neben den Typen gibt es auch Makros für die Bereichsgrenzen wie <code>INT8_MIN</code> oder <code>UINT16_MAX</code>. Siehe dazu auch: [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html Dokumentation der avr-libc: Standard Integer Types].<br />
<br />
= Grundsätzlicher Programmaufbau eines µC-Programms =<br />
<br />
Wir unterscheiden zwischen 2 verschiedenen Methoden, um ein<br />
Mikrocontroller-Programm zu schreiben, und zwar völlig unabhängig davon, in<br />
welcher Programmiersprache das Programm geschrieben wird.<br />
<br />
== Sequentieller Programmablauf ==<br />
<br />
[[Image:Sequentielle Programme.gif|left]]<br />
Bei dieser Programmiertechnik wird eine Endlosschleife programmiert, welche im<br />
Wesentlichen immer den gleichen Aufbau hat. Es wird hier nach dem sogenannten EVA-Prinzip gehandelt. EVA steht für "Eingabe, Verarbeitung, Ausgabe".<br />
{{Absatz}}<br />
<br />
== Interruptgesteuerter Programmablauf ==<br />
<br />
[[Image:Interrupt Programme.gif|left]]<br />
Bei dieser Methode werden beim Programmstart zuerst die gewünschten Interruptquellen aktiviert und dann in eine Endlosschleife gegangen, in welcher Dinge erledigt werden können, welche nicht zeitkritisch sind. Wenn ein Interrupt ausgelöst wird, so wird automatisch die zugeordnete Interruptfunktion ausgeführt.<br />
{{Absatz}}<br />
<br />
= Zugriff auf Register =<br />
<br />
Die AVR-Controller verfügen über eine Vielzahl von Registern. Die meisten<br />
davon sind sogenannte Schreib-/Leseregister. Das heißt, das Programm kann die<br />
Inhalte der Register sowohl auslesen als auch beschreiben.<br />
<br />
Register haben einen besonderen Stellenwert bei den AVR Controllern. Sie dienen dem Zugriff auf die Ports und die Schnittstellen des Controllers. Wir unterscheiden zwischen 8-Bit und 16-Bit Registern. Vorerst behandeln wir die 8-Bit Register.<br />
<br />
Einzelne Register sind bei allen AVRs vorhanden, andere wiederum nur bei bestimmten Typen. So sind beispielsweise die Register, welche für den Zugriff auf den UART notwendig sind, selbstverständlich nur bei denjenigen Modellen vorhanden, welche über einen integrierten Hardware UART bzw. USART verfügen.<br />
<br />
Die Namen der Register sind in den Headerdateien zu den entsprechenden AVR-Typen definiert. Dazu muss man den Namen der controllerspezifischen Headerdatei nicht kennen. Es reicht aus, die allgemeine Headerdatei ''avr/io.h'' einzubinden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
</syntaxhighlight><br />
<br />
Ist im Makefile der MCU-Typ z.&nbsp;B. mit dem Inhalt atmega8 definiert (und wird somit per -mmcu=atmega8 an den Compiler übergeben), wird beim Einlesen der io.h-Datei implizit ("automatisch") auch die iom8.h-Datei mit den Register-Definitionen für den ATmega8 eingelesen.<br />
<br />
<!-- Wohl besser als Anhang - spaeter... --><br />
Intern wird diese "Automatik" wie folgt realisiert: Der Controllertyp wird dem Compiler als Parameter übergeben (vgl. ''avr-gcc -c -mmcu=atmega16 [...]'' im Einführungsbeispiel). Wird ein Makefile nach der WinAVR/mfile-Vorlage verwendet, setzt man die Variable ''MCU'', der Inhalt dieser Variable wird dann an passender Stelle für die Compilerparameter verwendet. Der Compiler definiert intern eine dem mmcu-Parameter zugeordnete "Variable" (genauer: ein Makro) mit dem Namen des Controllers, vorangestelltem ''__AVR_'' und angehängten Unterstrichen (z.&nbsp;B. wird bei ''-mmcu=atmega16'' das Makro ''__AVR_ATmega16__'' definiert). Beim Einbinden der Header-Datei ''avr/io.h'' wird geprüft, ob das jeweilige Makro definiert ist und die zum Controller passende Definitionsdatei eingelesen. Zur Veranschaulichung einige Ausschnitte aus einem Makefile:<br />
<br />
<pre><br />
[...]<br />
# MCU Type ("name") setzen:<br />
MCU = atmega16<br />
[...]<br />
<br />
[...]<br />
## Verwendung des Inhalts von MCU (hier atmega16) fuer die <br />
## Compiler- und Assembler-Parameter<br />
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)<br />
ALL_CPPFLAGS = -mmcu=$(MCU) -I. -x c++ $(CPPFLAGS) $(GENDEPFLAGS)<br />
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)<br />
[...]<br />
<br />
[...]<br />
## Aufruf des Compilers:<br />
## mit den Parametern ($(ALL_CFLAGS) ist -mmcu=$(MCU)[...] = -mmcu=atmega16[...]<br />
$(OBJDIR)/%.o : %.c<br />
@echo<br />
@echo $(MSG_COMPILING) $<<br />
$(CC) -c $(ALL_CFLAGS) $< -o $@ <br />
[...]<br />
</pre><br />
<br />
Da --mmcu=atmega16 übergeben wurde, wird __AVR_ATmega16__ definiert und kann in avr/io.h zur Fallunterscheidung genutzt werden:<br />
<br />
<syntaxhighlight lang="c"><br />
// avr/io.h <br />
// (bei WinAVR-Standardinstallation in C:\WinAVR\avr\include\avr)<br />
[...]<br />
#if defined (__AVR_AT94K__)<br />
# include <avr/ioat94k.h><br />
// [...]<br />
#elif defined (__AVR_ATmega16__)<br />
// da __AVR_ATmega16__ definiert ist, wird avr/iom16.h eingebunden:<br />
# include <avr/iom16.h><br />
// [...]<br />
#else<br />
# if !defined(__COMPILING_AVR_LIBC__)<br />
# warning "device type not defined"<br />
# endif<br />
#endif<br />
</syntaxhighlight><br />
<br />
Die Beispiele in den folgenden Abschnitten demonstrieren den Zugriff auf Register anhand der Register für I/O-Ports (PORTx, DDRx, PINx), die Vorgehensweise ist jedoch für alle Register (z.&nbsp;B. die des UART, ADC, SPI) analog.<br />
<br />
== Schreiben in Register ==<br />
<br />
Zum Schreiben kann man Register einfach wie eine Variable setzen.<ref>In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Schreibzugriff über die Funktion outp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt, outp() ist nicht mehr erforderlich.</ref><br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
/* Setzt das Richtungsregister des Ports A auf 0xff <br />
(alle Pins als Ausgang, vgl. Abschnitt Zugriff auf Ports): */<br />
DDRA = 0xff; <br />
<br />
/* Setzt PortA auf 0x03, Bit 0 und 1 "high", restliche "low": */<br />
PORTA = 0x03; <br />
<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binär 00011111 = Hexadezimal 1F<br />
DDRB = 0x1F; /* direkte Zuweisung - unübersichtlich */<br />
<br />
/* Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit<br />
aber übersichtlicher und selbsterklärend: */<br />
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);<br />
<br />
while (1);<br />
}<br />
</syntaxhighlight><br />
<br />
Die ausführliche Schreibweise sollte bevorzugt verwendet werden, da dadurch die Zuweisungen selbsterklärend sind und somit der Code leichter nachvollzogen werden kann. Atmel verwendet sie auch bei Beispielen in Datenblätten und in den allermeisten Quellcodes zu Application-Notes. Mehr zu der Schreibweise mit "|" und "<<" findet man unter [[Bitmanipulation]].<br />
<br />
Der gcc C-Compiler unterstützt ab Version 4.3.0 Konstanten im Binärformat, z.&nbsp;B. DDRB&nbsp;=&nbsp;0b00011111. Diese Schreibweise ist jedoch nur in GNU-C verfügbar und nicht in ISO-C definiert. Man sollte sie daher nicht verwenden, wenn Code mit anderen ausgetauscht oder mit anderen Compilern bzw. älteren Versionen des gcc genutzt werden soll.<br />
<br />
== Verändern von Registerinhalten ==<br />
<br />
Einzelne Bits setzt und löscht man "Standard-C-konform" mittels logischer (Bit-) Operationen. <br />
<br />
<syntaxhighlight lang="c"><br />
x |= (1 << Bitnummer); // Hiermit wird ein Bit in x gesetzt<br />
x &= ~(1 << Bitnummer); // Hiermit wird ein Bit in x geloescht<br />
</syntaxhighlight><br />
<br />
Es wird jeweils nur der Zustand des angegebenen Bits geändert, der vorherige Zustand der anderen Bits bleibt erhalten. <br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
#define MEINBIT 2<br />
...<br />
PORTA |= (1 << MEINBIT); /* setzt Bit 2 an PortA auf 1 */<br />
PORTA &= ~(1 << MEINBIT); /* loescht Bit 2 an PortA */<br />
</syntaxhighlight><br />
<br />
Mit dieser Methode lassen sich auch mehrere Bits eines Registers gleichzeitig setzen und löschen.<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
DDRA &= ~( (1<<PA0) | (1<<PA3) ); /* PA0 und PA3 als Eingaenge */<br />
PORTA |= ( (1<<PA0) | (1<<PA3) ); /* Interne Pull-Up fuer beide einschalten */<br />
</syntaxhighlight><br />
<br />
Bei bestimmten AVR Registern mit Bits, die durch Beschreiben mit einer logischen 1 gelöscht werden, muss eine absolute Zuweisung benutzt werden. Ein ODER löscht in diesen Registern ALLE gesetzten Bits!<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
TIFR2 = (1<<OCF2A); // Nur Bit OCF2A löschen<br />
</syntaxhighlight><br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind nicht mehr erforderlich.<br />
<br />
Siehe auch:<br />
* [[Bitmanipulation]]<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
<br />
== Lesen aus Registern ==<br />
<br />
Zum Lesen kann man auf Register einfach wie auf eine Variable zugreifen. In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Lesezugriff über die Funktion inp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt und inp() ist nicht mehr erforderlich.<br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdint.h><br />
<br />
uint8_t foo;<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
/* kopiert den Status der Eingabepins an PortB <br />
in die Variable foo: */<br />
foo = PINB; <br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Die Abfrage der Zustände von Bits erfolgt durch Einlesen des gesamten Registerinhalts und ausblenden der Bits deren Zustand nicht von Interesse ist. Einige Beispiele zum Prüfen ob Bits gesetzt oder gelöscht sind:<br />
<br />
<syntaxhighlight lang="c"><br />
#define MEINBIT0 0 <br />
#define MEINBIT2 2<br />
<br />
uint8_t i;<br />
<br />
extern test1();<br />
<br />
// Funkion test1 aufrufen, wenn Bit 0 in Register PINA gesetzt (1) ist<br />
i = PINA; // Inhalt in Arbeitsvariable<br />
i = i & 0x01; // alle Bits bis auf Bit 0 ausblenden (bitweise und)<br />
// falls das Bit gesetzt war, hat i den Inhalt 1<br />
if ( i != 0 ) { // Ergebnis ungleich 0 (wahr)? <br />
test1(); // dann muss Bit 0 in i gesetzt sein -> Funktion aufrufen<br />
}<br />
// verkürzt:<br />
if ( ( PINA & 0x01 ) != 0 ) {<br />
test1();<br />
}<br />
// nochmals verkürzt:<br />
if ( PINA & 0x01 ) {<br />
test1();<br />
}<br />
// mit definierter Bitnummer:<br />
if ( PINA & ( 1 << MEINBIT0 ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und/oder Bit 2 gesetzt ist. (Bit 0 und 2 also Wert 5) <br />
// (Bedenke: Bit 0 hat Wert 1, Bit 1 hat Wert 2 und Bit 2 hat Wert 4)<br />
if ( PINA & 0x05 ) {<br />
test1(); // Vergleich <> 0 (wahr), also mindestens eines der Bits gesetzt<br />
}<br />
// mit definierten Bitnummern:<br />
if ( PINA & ( ( 1 << MEINBIT0 ) | ( 1 << MEINBIT2 ) ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und Bit 2 gesetzt sind<br />
if ( ( PINA & 0x05 ) == 0x05 ) { // nur wahr, wenn beide Bits gesetzt<br />
test1();<br />
}<br />
<br />
// Funktion test2() aufrufen, wenn Bit 0 gelöscht (0) ist<br />
i = PINA; // einlesen in temporäre Variable<br />
i = i & 0x01; // maskieren von Bit 0<br />
if ( i == 0 ) { // Vergleich ist wahr, wenn Bit 0 nicht gesetzt ist<br />
test2();<br />
}<br />
// analog mit not-Operator<br />
if ( !i ) {<br />
test2();<br />
}<br />
// nochmals verkürzt:<br />
if ( !( PINA & 0x01 ) ) {<br />
test2();<br />
}<br />
</syntaxhighlight><br />
<br />
== Warten auf einen bestimmten Zustand ==<br />
<br />
Es gibt in der Bibliothek avr-libc Funktionen, die warten, bis ein bestimmter Zustand eines Bits erreicht ist. Es ist allerdings normalerweise eine eher unschöne Programmiertechnik, da in diesen Funktionen "blockierend" gewartet wird. Der Programmablauf bleibt also an dieser Stelle stehen, bis das maskierte Ereignis erfolgt ist. Setzt man den [[Watchdog]] ein, muss man darauf achten, dass dieser auch noch getriggert wird (Zurücksetzen des Watchdogtimers). <br />
<br />
Die Funktion '''loop_until_bit_is_set''' wartet in einer Schleife, bis das definierte Bit gesetzt ist. Wenn das Bit beim Aufruf der Funktion bereits gesetzt ist, wird die Funktion sofort wieder verlassen. Das niederwertigste Bit hat die Bitnummer 0. <br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 2 (das dritte Bit) in Register PINA gesetzt (1) ist */<br />
<br />
#define WARTEPIN PINA<br />
#define WARTEBIT PA2<br />
<br />
// mit der avr-libc Funktion:<br />
loop_until_bit_is_set(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// _nicht_ ungleich 0 (also 0) ist.<br />
while ( !(WARTEPIN & (1 << WARTEBIT)) ) {}<br />
...<br />
</syntaxhighlight><br />
<br />
<br />
Die Funktion '''loop_until_bit_is_clear''' wartet in einer Schleife, bis das definierte Bit gelöscht ist. Wenn das Bit beim Aufruf der Funktion bereits gelöscht ist, wird die Funktion sofort wieder verlassen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 4 (das fuenfte Bit) in Register PINB geloescht (0) ist */<br />
#define WARTEPIN PINB<br />
#define WARTEBIT PB4<br />
<br />
// avr-libc-Funktion:<br />
loop_until_bit_is_clear(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// gesetzt (1) ist <br />
while ( WARTEPIN & (1<<WARTEBIT) ) {}<br />
...<br />
</syntaxhighlight><br />
<br />
Universeller und auch auf andere Plattformen besser übertragbar ist die Verwendung von C-Standardoperationen.<br />
<br />
Siehe auch: <br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
* [[Bitmanipulation]]<br />
<br />
== 16-Bit Register (ADC, ICR1, OCR1x, TCNT1, UBRR) ==<br />
<br />
Einige der Portregister in den AVR-Controllern sind 16 Bit breit. Im Datenblatt sind diese Register üblicherweise mit dem Suffix "L" (Low-Byte) und "H" (High-Byte) versehen. Die avr-libc definiert zusätzlich die meisten dieser Variablen die Bezeichnung ohne "L" oder "H". Auf diese Register kann dann direkt zugegriffen werden. Dies ist zum Beispiel der Fall für Register wie ADC oder TCNT1.<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
uint16_t foo;<br />
<br />
/* setzt die Wort-Variable foo auf den Wert der letzten AD-Wandlung */<br />
foo = ADC; <br />
</syntaxhighlight><br />
<br />
Bei anderen Registern, wie zum Beispiel Baudraten-Register, liegen High- und Low-Teil nicht direkt nebeneinander im SFR-Bereich, so dass ein 16-Bit Zugriff nicht möglich ist und der Zugriff zusammengebastelt werden muss:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
...<br />
uint16_t baud = F_CPU / (UART_BAUD_RATE * 16L) -1;<br />
<br />
UBRRH = (uint8_t) (baud >> 8);<br />
UBRRL = (uint8_t) baud;<br />
...<br />
</syntaxhighlight><br />
<br />
Bei einigen AVR-Typen wie ATmega8 oder ATmega16 teilen sich UBRRH und UCSRC die gleiche Speicher-Adresse. Damit der AVR trotzdem zwischen den beiden Registern unterscheiden kann, bestimmt das Bit7 (URSEL), welches Register tatsächlich beschrieben werden soll. ''1000 0011'' (0x83) adressiert demnach UCSRC und übergibt den Wert ''3''. Und ''0000 0011'' (0x3) adressiert UBRRH und übergibt ebenfalls den Wert ''3''. <br />
<br />
Speziell bei den 16-Bit-Timern und auch beim ADC ist es bei allen Zugriffen auf Datenregister erforderlich, dass diese Daten synchronisiert sind. Wenn z.&nbsp;B. bei einem 16-Bit-Timer das High-Byte des Zählregisters gelesen wurde und vor dem Lesezugriff auf das Low-Byte ein Überlauf des Low-Bytes stattfindet, erhält man einen völlig unsinnigen Wert. Auch die Compare-Register müssen synchron geschrieben werden, da es ansonsten zu unerwünschten Compare-Ereignissen kommen kann. <br />
<br />
Beim ADC besteht das Problem darin, dass zwischen den Zugriffen auf die beiden Teilregister eine Wandlung beendet werden kann und der ADC ein neues Ergebnis in ADCL und ADCH schreiben will, wodurch High- und Low-Byte nicht zusammenpassen.<br />
<br />
Um diese Datenmüllproduktion zu verhindern, gibt es in beiden Fällen eine Synchronisation, die jeweils durch den Zugriff auf das Low-Byte ausgelöst wird:<br />
* Bei den Timer-Registern (das gilt für alle TCNT-, OCR- und ICR-Register bei den 16-Bit-Timern) wird bei einem ''Lesezugriff'' auf das Low-Byte automatisch das High-Byte in ein temporäres Register, das ansonsten nach außen nicht sichtbar ist, geschoben. Greift man nun ''anschließend'' auf das High-Byte zu, dann wird eben dieses temporäre Register gelesen.<br />
* Bei einem ''Schreibzugriff'' auf eines der genannten Register wird das High-Byte in besagtem temporären Register zwischengespeichert und erst beim Schreiben des Low-Bytes werden ''beide'' gleichzeitig in das eigentliche Register übernommen.<br />
<br />
Das bedeutet für die Reihenfolge:<br />
* Lesezugriff: Erst Low-Byte, dann High-Byte<br />
* Schreibzugriff: Erst High-Byte, dann Low-Byte<br />
<br />
Des weiteren ist zu beachten, dass es für all diese 16-Bit-Register nur ein einziges temporäres Register gibt, so dass das Auftreten eines Interrupts, in dessen Handler ein solches Register manipuliert wird, bei einem durch ihn unterbrochenen Zugriff i.d.R. zu Datenmüll führt. 16-Bit-Zugriffe sind generell nicht atomar! Wenn mit Interrupts gearbeitet wird, kann es erforderlich sein, vor einem solchen Zugriff auf ein 16-Bit-Register die Interrupt-Bearbeitung zu deaktivieren.<br />
<br />
Beim ADC-Datenregister ADCH/ADCL ist die Synchronisierung anders gelöst. Hier wird beim Lesezugriff (ADCH/ADCL sind logischerweise read-only) auf das Low-Byte ADCL beide Teilregister für Zugriffe seitens des ADC so lange gesperrt, bis das High-Byte ADCH ausgelesen wurde. Dadurch kann der ADC nach einem Zugriff auf ADCL keinen neuen Wert in ADCH/ADCL ablegen, bis ADCH gelesen wurde. Ergebnisse von Wandlungen, die zwischen einem Zugriff auf ADCL und ADCH beendet werden, gehen verloren!<br />
<br />
Nach einem Zugriff auf ADCL muss grundsätzlich ADCH gelesen werden!<br />
<br />
In beiden Fällen – also sowohl bei den Timern als auch beim ADC – werden vom C-Compiler 16-Bit Pseudo-Register zur Verfügung gestellt (z.&nbsp;B. TCNT1H/TCNT1L → TCNT1, ADCH/ADCL → ADC bzw. ADCW), bei deren Verwendung der Compiler automatisch die richtige Zugriffsreihenfolge regelt. In C-Programmen sollten grundsätzlich diese 16-Bit-Register verwendet werden! Sollte trotzdem ein Zugriff auf ein Teilregister erforderlich sein, sind obige Angaben zu berücksichtigen.<br />
<br />
Es ist darauf zu achten, dass auch ein Zugriff auf die 16-Bit-Register vom Compiler in zwei 8-Bit-Zugriffe aufgeteilt wird und dementsprechend genauso nicht-atomar ist wie die Einzelzugriffe. Auch hier gilt, dass u.U. die Interrupt-Bearbeitung gesperrt werden muss, um Datenmüll zu vermeiden.<br />
<br />
Beim ADC gibt es für den Fall, dass eine Auflösung von 8 Bit ausreicht, die Möglichkeit, das Ergebnis "linksbündig" in ADCH/ADCL auszurichten, so dass die relevanten 8 MSB in ADCH stehen. In diesem Fall muss bzw. sollte nur ADCH ausgelesen werden.<br />
<br />
ADC und ADCW sind unterschiedliche Bezeichner für das selbe Registerpaar. Üblicherweise kann man in C-Programmen ADC verwenden, was analog zu den anderen 16-Bit-Registern benannt ist. ADCW (ADC Word) existiert nur deshalb, weil die Headerdateien auch für Assembler vorgesehen sind und es bereits einen Assembler-Befehl namens ''adc'' gibt. <br />
<br />
Im Umgang mit 16-Bit Registern siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Related Pages/Frequently Asked Questions/Nr. 8<br />
* Datenblatt Abschnitt ''Accessing 16-bit Registers''<br />
<br />
== IO-Register als Parameter und Variablen ==<br />
<br />
Um Register als Parameter für eigene Funktionen übergeben zu können, muss man sie als einen volatile uint8_t Pointer übergeben. Zum Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <util/delay.h><br />
<br />
uint8_t key_pressed (volatile uint8_t *inputreg, uint8_t inputbit)<br />
{<br />
static uint8_t last_state = 0;<br />
<br />
if (last_state == (*inputreg & (1<<inputbit)))<br />
return 0; /* keine Änderung */<br />
<br />
/* Wenn doch, warten bis etwaiges Prellen vorbei ist: */<br />
_delay_ms(20);<br />
<br />
/* Zustand für nächsten Aufruf merken: */<br />
last_state = *inputreg & (1<<inputbit);<br />
<br />
/* und den entprellten Tastendruck zurückgeben: */<br />
return *inputreg & (1<<inputbit);<br />
}<br />
<br />
/* Beispiel für einen Funktionsaufruf: */<br />
<br />
void foo (void)<br />
{<br />
uint8_t i = key_pressed (&PINB, PB1);<br />
}<br />
</syntaxhighlight><br />
<br />
Ein Aufruf der Funktion mit call by value würde Folgendes bewirken: Beim Funktionseintritt wird nur eine Kopie des momentanen Portzustandes angefertigt, die sich unabhängig vom tatsächlichen Zustand das Ports nicht mehr ändert, womit die Funktion wirkungslos wäre. Die Übergabe eines Zeigers wäre die Lösung, wenn der Compiler nicht optimieren würde. Denn dadurch wird im Programm nicht von der Hardware gelesen, sondern wieder nur von einem Abbild im Speicher. Das Ergebnis wäre das gleiche wie oben. Mit dem Schlüsselwort volatile sagt man nun dem Compiler, dass die entsprechende Variable entweder durch andere Softwareroutinen (Interrupts) oder durch die Hardware verändert werden kann.<br />
<br />
Siehe auch: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass avr-libc FAQ: "How do I pass an IO port as a parameter to a function?"]<br />
<br />
= Zugriff auf IO-Ports =<br />
<br />
Jeder AVR implementiert eine unterschiedliche Menge an GPIO-Registern<br />
(GPIO - General Purpose Input/Output). Diese Register dienen dazu:<br />
* einzustellen welche der Anschlüsse ("Beinchen") des Controllers als Ein- oder Ausgänge dienen<br />
* bei Ausgängen deren Zustand festzulegen<br />
* bei Eingängen deren Zustand zu erfassen<br />
<br />
Mittels GPIO werden digitale Zustände gesetzt und erfasst, d.h. die Spannung an einem Ausgang wird ein- oder ausgeschaltet und an einem Eingang wird erfasst, ob die anliegende Spannung über oder unter einem bestimmten Schwellwert liegt. Im Datenblatt Abschnitt Electrical Characteristics/DC Characteristics finden sich die Spannungswerte (V_OL, V_OH für Ausgänge, V_IL, V_IH für Eingänge).<br />
<br />
Die Verarbeitung von analogen Eingangswerten und die Ausgabe von Analogwerten wird in Kapitel [[AVR-GCC-Tutorial#Analoge_Ein-_und_Ausgabe|Analoge Ein- und Ausgabe]] behandelt.<br />
<br />
Die physischen Ein- und Ausgänge werden bei AVR-Controllern zu logischen Ports gruppiert.<br />
<br />
Alle Ports werden über Register gesteuert. Dazu sind jedem Port 3 Register zugeordnet:<br />
<br />
{| class="wikitable"<br />
|- <br />
! width="10%"| DDRx<br />
| Datenrichtungsregister für Port'''x'''. <br />
'''x''' entspricht '''A''', '''B''', ''' C''' usw. je nach gewünschtem Port. Bit im Register gesetzt (1) für Ausgang, Bit gelöscht (0) für Eingang.<br />
|- <br />
! PINx<br />
| Eingangsadresse für Port'''x'''. <br />
Zustand des Ports. Die Bits in PINx entsprechen dem Zustand der als Eingang definierten Portpins. Bit 1 wenn Pin "high", Bit 0 wenn Portpin low.<br />
|-<br />
! PORTx<br />
| Datenregister für Port'''x'''. <br />
Dieses Register wird verwendet, um die Ausgänge eines Ports anzusteuern. Bei Pins, die mittels DDRx auf Eingang geschaltet wurden, können über PORTx<br />
die internen Pull-Up Widerstände aktiviert oder deaktiviert werden (1 = aktiv).<br />
|}<br />
<br />
Die folgenden Beispiele gehen von einem AVR aus, der sowohl Port A als auch Port B besitzt. Sie müssen für andere AVRs (zum Beispiel ATmega8/48/88/168) entsprechend angepasst werden.<br />
<br />
== Datenrichtung bestimmen ==<br />
<br />
Zuerst muss die Datenrichtung der verwendeten Pins bestimmt werden. Um dies zu erreichen, wird das Datenrichtungsregister des entsprechenden Ports beschrieben.<br />
<br />
Für jeden Pin, der als Ausgang verwendet werden soll, muss dabei das<br />
entsprechende Bit auf dem Port gesetzt werden. Soll der Pin als Eingang<br />
verwendet werden, muss das entsprechende Bit gelöscht sein.<br />
<br />
Beispiel:<br />
Angenommen am Port B sollen die Pins 0 bis 4 als Ausgänge definiert werden, die noch verbleibenden Pins 5 bis 7 sollen als Eingänge fungieren. Dazu ist es daher notwendig, im für das Port B zuständigen Datenrichtungsregister DDRB folgende Bitkonfiguration einzutragen<br />
<br />
+---+---+---+---+---+---+---+---+<br />
| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |<br />
+---+---+---+---+---+---+---+---+<br />
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br />
<br />
In C liest sich das dann so:<br />
<br />
<syntaxhighlight lang="c"><br />
// in io.h wird u.a. DDRB definiert:<br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binaer 00011111 = Hexadezimal 1F<br />
// direkte Zuweisung - standardkonform */<br />
DDRB = 0x1F; /* <br />
<br />
// Uebersichtliche Alternative - Binaerschreibweise, aber kein ISO-C<br />
DDRB = 0b00011111;<br />
<br />
// Ausfuehrliche Schreibweise: identische Funktionalitaet, mehr Tipparbeit<br />
// aber uebersichtlicher und selbsterklaerend:<br />
DDRB |= (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4); <br />
</syntaxhighlight><br />
<br />
Die Pins 5 bis 7 werden (da 0) als Eingänge geschaltet. Weitere Beispiele:<br />
<br />
<syntaxhighlight lang="c"><br />
// Alle Pins des Ports B als Ausgang definieren:<br />
DDRB = 0xff; <br />
// Pin0 wieder auf Eingang und andere im urspruenglichen Zustand belassen:<br />
DDRB &= ~(1 << DDB0);<br />
// Pin 3 und 4 auf Eingang und andere im urspruenglichen Zustand belassen:<br />
DDRB &= ~((1 << DDB3) | (1 << DDB4));<br />
// Pin 0 und 3 wieder auf Ausgang und andere im ursprünglichen Zustand belassen:<br />
DDRB |= (1 << DDB0) | (1 << DDB3);<br />
// Alle Pins auf Eingang:<br />
DDRB = 0x00;<br />
</syntaxhighlight><br />
<br />
== Vordefinierte Bitnummern für I/O-Register ==<br />
<br />
Die Bitnummern (z.&nbsp;B. PCx, PINCx und DDCx für den Port C) sind in den io*.h-Dateien der avr-libc definiert und dienen lediglich der besseren Lesbarkeit. Man muss diese Definitionen nicht verwenden oder kann auch einfach "immer" PAx, PBx, PCx usw. nutzen, auch wenn der Zugriff auf Bits in DDRx- oder PINx-Registern erfolgt. Für den Compiler sind die Ausdrücke (1<<PC7), (1<<DDC7) und (1<<PINC7) identisch zu (1<<7) (genauer: der Präprozessor ersetzt die Ausdrücke (1<<PC7),... zu (1<<7)). Ein Ausschnitt der Definitionen für Port C eines ATmega32 aus der iom32.h-Datei zur Verdeutlichung (analog für die weiteren Ports):<br />
<br />
<syntaxhighlight lang="c"><br />
...<br />
/* PORTC */<br />
#define PC7 7<br />
#define PC6 6<br />
#define PC5 5<br />
#define PC4 4<br />
#define PC3 3<br />
#define PC2 2<br />
#define PC1 1<br />
#define PC0 0<br />
<br />
/* DDRC */<br />
#define DDC7 7<br />
#define DDC6 6<br />
#define DDC5 5<br />
#define DDC4 4<br />
#define DDC3 3<br />
#define DDC2 2<br />
#define DDC1 1<br />
#define DDC0 0<br />
<br />
/* PINC */<br />
#define PINC7 7<br />
#define PINC6 6<br />
#define PINC5 5<br />
#define PINC4 4<br />
#define PINC3 3<br />
#define PINC2 2<br />
#define PINC1 1<br />
#define PINC0 0<br />
</syntaxhighlight><br />
<br />
<br />
== Digitale Signale ==<br />
<br />
Am einfachsten ist es, digitale Signale mit dem Mikrocontroller zu erfassen bzw. auszugeben.<br />
<br />
== Ausgänge ==<br />
Will man als Ausgang definierte Pins (entsprechende DDRx-Bits = 1) auf Logisch 1 setzen, setzt man die entsprechenden Bits im Portregister.<br />
<br />
Mit dem Befehl<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB = 0x04; /* besser PORTB=(1<<PB2) */<br />
<br />
// Uebersichtliche Alternative - Binaerschreibweise<br />
PORTB = 0b00000100; /* direkte Zuweisung - uebersichtlich */<br />
<br />
</syntaxhighlight><br />
wird also der Ausgang an Pin PB2 gesetzt (Beachte, dass die Bits immer ''von 0 an'' gezählt werden, das niederwertigste Bit ist also Bitnummer 0 und nicht etwa Bitnummer 1).<br />
<br />
Man beachte, dass bei der Zuweisung mittels '''=''' immer alle Pins gleichzeitig angegeben werden. Man sollte also, wenn nur bestimmte Ausgänge geschaltet werden sollen, zuerst den aktuellen Wert des Ports einlesen und das Bit des gewünschten Ports in diesen Wert einfließen lassen. Will man also nur den dritten Pin (Bit Nr. 2) an Port B auf "high" setzen und den Status der anderen Ausgänge unverändert lassen, nutze man diese Form:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB = PORTB | 0x04; /* besser: PORTB = PORTB | ( 1<<PB2 ) */<br />
/* vereinfacht durch Nutzung des |= Operators : */<br />
PORTB |= (1<<PB2);<br />
<br />
/* auch mehrere "gleichzeitig": */<br />
PORTB |= (1<<PB4) | (1<<PB5); /* Pins PB4 und PB5 "high" */<br />
</syntaxhighlight><br />
<br />
"Ausschalten", also Ausgänge auf "low" setzen, erfolgt analog:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB &= ~(1<<PB2); /* loescht Bit 2 in PORTB und setzt damit Pin PB2 auf low */ <br />
PORTB &= ~( (1<<PB4) | (1<<PB5) ); /* Pin PB4 und Pin PB5 "low" */<br />
</syntaxhighlight><br />
Siehe auch [[Bitmanipulation]]<br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind in aktuellen Versionen der avr-libc nicht mehr enthalten und auch nicht mehr erforderlich.<br />
<br />
''Falls der Anfangszustand von Ausgängen kritisch ist, muss die Reihenfolge beachtet werden, mit der die Datenrichtung (DDRx) eingestellt und der Ausgabewert (PORTx) gesetzt wird:''<br />
<br />
Für Ausgangspins, die mit Anfangswert "high" initialisiert werden sollen:<br />
* zuerst die Bits im PORTx-Register setzen<br />
* anschließend die Datenrichtung auf Ausgang stellen<br />
<br />
Daraus ergibt sich die Abfolge für einen Pin, der bisher als Eingang mit abgeschaltetem Pull-Up konfiguriert war:<br />
* setze PORTx: interner Pull-Up aktiv<br />
* setze DDRx: Ausgang ("high")<br />
<br />
Bei der Reihenfolge erst DDRx und dann PORTx kann es zu einem kurzen "low-Puls" kommen, der auch externe Pull-Up-Widerstände "überstimmt". Die (ungünstige) Abfolge: Eingang -> setze DDRx: Ausgang (auf "low", da PORTx nach Reset 0) -> setze PORTx: Ausgang auf high. Vergleiche dazu auch das Datenblatt Abschnitt ''Configuring the Pin''.<br />
<br />
== Eingänge (Wie kommen Signale in den &micro;C) ==<br />
<br />
Die digitalen Eingangssignale können auf verschiedene Arten zu unserer Logik gelangen.<br />
<br />
=== Signalkopplung ===<br />
<br />
Am einfachsten ist es, wenn die Signale direkt aus einer anderen digitalen Schaltung übernommen werden können. Hat der Ausgang der entsprechenden Schaltung TTL-Pegel dann können wir sogar direkt den Ausgang der Schaltung mit einem Eingangspin von unserem Controller verbinden.<br />
<br />
Hat der Ausgang der anderen Schaltung keinen TTL-Pegel so müssen wir den Pegel über entsprechende Hardware (z.&nbsp;B. Optokoppler, [[Widerstand#Spannungsteiler|Spannungsteiler]], "Levelshifter" aka [[Pegelwandler]]) anpassen.<br />
<br />
Die Masse der beiden Schaltungen muss selbstverständlich miteinander verbunden werden. Der Software selber ist es natürlich letztendlich egal, wie das Signal eingespeist wird. Wir können ja ohnehin lediglich prüfen, ob an einem Pin unseres Controllers eine logische 1 (Spannung größer ca. 0,7*Vcc) oder eine logische 0 (Spannung kleiner ca. 0,2*Vcc) anliegt. Detaillierte Informationen darüber, ab welcher Spannung ein Eingang als 0 ("low") bzw. 1 ("high") erkannt wird, liefert die Tabelle DC Characteristics im Datenblatt des genutzten Controllers.<br />
<br />
{| class="wikitable" style="text-align:center; width:20em"<br />
|+ '''Logikpegel'''<br />
|-<br />
! VCC [V]<br />
! Low [V]<br />
! High [V]<br />
|-<br />
! 5<br />
| 1,0 || 3,5<br />
|-<br />
! 3,3<br />
| 0,66 || 2,3<br />
|-<br />
! 1,8<br />
| 0,36 || 1,26 <br />
|}<br />
<br />
Die Abfrage der Zustände der Portpins erfolgt direkt über den Registernamen.<br />
<br />
{{Warnung|Dabei ist wichtig, zur Abfrage der Eingänge ''nicht'' etwa Portregister '''PORTx''' zu verwenden, sondern Eingangsregister '''PINx'''. Ansonsten liest man nicht den Zustand der Eingänge, sondern den Status der internen Pull-Up-Widerstände. Die Abfrage der Pinzustände über PORTx statt PINx ist ein häufiger Fehler beim AVR-"Erstkontakt".}}<br />
<br />
Will man also die aktuellen Signalzustände von Port D abfragen und in eine Variable namens bPortD abspeichern, schreibt man folgende Befehlszeilen:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdint.h><br />
...<br />
uint8_t bPortD;<br />
...<br />
bPortD = PIND;<br />
...<br />
</syntaxhighlight><br />
<br />
Mit den C-Bitoperationen kann man den Status der Bits abfragen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
/* Fuehre Aktion aus, wenn Bit Nr. 1 (das "zweite" Bit) in PINC gesetzt (1) ist */<br />
if ( PINC & (1<<PINC1) ) {<br />
/* Aktion */<br />
}<br />
<br />
/* Fuehre Aktion aus, wenn Bit Nr. 2 (das "dritte" Bit) in PINB geloescht (0) ist */<br />
if ( !(PINB & (1<<PINB2)) ) {<br />
/* Aktion */<br />
}<br />
...<br />
</syntaxhighlight><br />
Siehe auch [[Bitmanipulation#Bits_prüfen]]<br />
<br />
=== Interne Pull-Up Widerstände ===<br />
<br />
Portpins für Ein- und Ausgänge (GPIO) eines AVR verfügen über zuschaltbare interne Pull-Up Widerstände (nominal mehrere 10kOhm, z.&nbsp;B. ATmega16 20-50kOhm). Diese können in vielen Fällen statt externer Widerstände genutzt werden.<br />
<br />
Die internen Pull-Up Widerstände von Vcc zu den einzelnen Portpins werden über das Register ''' PORTx''' aktiviert bzw. deaktiviert, wenn ein Pin als ''' Eingang''' geschaltet ist.<br />
<br />
Wird der Wert des entsprechenden Portpins auf 1 gesetzt, so ist der Pull-Up Widerstand aktiviert. Bei einem Wert von 0 ist der Pull-Up Widerstand nicht aktiv. Man sollte jeweils entweder den internen oder einen externen Pull-Up Widerstand verwenden, aber nicht beide zusammen.<br />
<br />
Im Beispiel werden alle Pins des Ports D als Eingänge geschaltet und alle Pull-Up Widerstände aktiviert. Weiterhin wird Pin PC7 als Eingang geschaltet und dessen interner Pull-Up Widerstand aktiviert, ohne die Einstellungen für die anderen Portpins (PC0-PC6) zu verändern.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
DDRD = 0x00; /* alle Pins von Port D als Eingang */<br />
PORTD = 0xff; /* interne Pull-Ups an allen Port-Pins aktivieren */<br />
...<br />
DDRC &= ~(1<<PC7); /* Pin PC7 als Eingang */<br />
PORTC |= (1<<PC7); /* internen Pull-Up an PC7 aktivieren */<br />
</syntaxhighlight><br />
<br />
=== Taster und Schalter ===<br />
<br />
Der Anschluss mechanischer Kontakte an den Mikrocontroller, ist zwischen zwei unterschiedliche Methoden zu unterscheiden: ''Active Low'' und ''Active High''.<br />
<br />
<gallery widths="300" heights="300" caption="Anschluss mechanischer Kontakte an einen µC"><br />
Image:Active Low.gif|'''Active Low:''' Bei dieser Methode wird der Kontakt zwischen den Eingangspin des Controllers und Masse geschaltet. Damit bei offenem Schalter der Controller kein undefiniertes Signal bekommt, wird zwischen die Versorgungsspannung und den Eingangspin ein sogenannter '''Pull-Up''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffnetem Schalter auf logisch 1 zu ziehen.<br />
Image:Active High.gif|'''Active High:''' Hier wird der Kontakt zwischen die Versorgungsspannung und den Eingangspin geschaltet. Damit bei offener Schalterstellung kein undefiniertes Signal am Controller ansteht, wird zwischen den Eingangspin und die Masse ein '''Pull-Down''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffneter Schalterstellung auf logisch 0 zu halten. <br />
</gallery><br />
<br />
Der Widerstandswert von Pull-Up- und Pull-Down-Widerständen ist an sich nicht kritisch. Wird er allerdings zu hoch gewählt, ist die Wirkung eventuell nicht gegeben. Als üblicher Wert haben sich 10 kOhm eingebürgert. Die AVRs verfügen an den meisten Pins über zuschaltbare interne Pull-Up Widerstände (vgl. Abschnitt [[AVR-GCC-Tutorial#Interne Pull-Up Widerstände|Interne Pull-Up Widerstände]]), welche insbesondere wie hier bei Tastern und ähnlichen Bauteilen (z.&nbsp;B. Drehgebern) statt externer Bauteile verwendet werden können. Interne Pull-Down-Widerstand sind nicht verfügbar und müssen daher in Form zusätzlicher Bauteile in die Schaltung eingefügt werden.<br />
<br />
==== Taster entprellen ====<br />
<br />
Siehe: ''[[Entprellung#Warteschleifen-Verfahren|Entprellung: Warteschleifen-Verfahren]]<br />
<br />
= Warteschleifen (delay.h) =<br />
<br />
Der Programmablauf kann verschiedene Arten von Wartefunktionen erfordern:<br />
<br />
* Warten im Sinn von Zeitvertrödeln<br />
* Warten auf einen bestimmten Zustand an den I/O-Pins<br />
* Warten auf einen bestimmten Zeitpunkt (siehe Timer)<br />
* Warten auf einen bestimmten Zählerstand (siehe Counter)<br />
<br />
Der einfachste Fall, das Zeitvertrödeln, kann in vielen Fällen und mit großer Genauigkeit anhand der avr-libc Bibliotheksfunktionen _delay_ms() und _delay_us() erledigt werden. Die Bibliotheksfunktionen sind einfachen Zählschleifen (Warteschleifen) vorzuziehen, da leere Zählschleifen ohne besondere Vorkehrungen sonst bei eingeschalteter Optimierung vom avr-gcc-Compiler wegoptimiert werden. Weiterhin sind die Bibliotheksfunktionen bereits darauf vorbereitet, die in F_CPU definierte Taktfrequenz zu verwenden. Außerdem sind die Funktionen der Bibliothek wirklich getestet.<br />
<br />
Einfach!? Schon, aber während gewartet wird, macht der µC nichts anderes mehr (abgesehen von möglicherweise auftretenden Interrupts, falls welche aktiviert sind). Die Wartefunktion blockiert den Programmablauf. Möchte man einerseits warten, um z.&nbsp;B. eine LED blinken zu lassen und gleichzeitig andere Aktionen ausführen z.&nbsp;B. weitere LED bedienen, sollten die Timer/Counter des AVR verwendet werden, siehe Artikel [[Multitasking]].<br />
<br />
Die Bibliotheksfunktionen funktionieren allerdings nur dann korrekt, wenn sie mit zur Übersetzungszeit (beim Compilieren) bekannten konstanten Werten aufgerufen werden. Der Quellcode muss mit eingeschalteter Optimierung übersetzt werden, sonst wird sehr viel Maschinencode erzeugt, und die Wartezeiten stimmen nicht mehr mit dem Parameter überein.<br />
<br />
Eine weitere Einschränkung liegt darin, daß sie möglicherweise länger warten, als erwartet, nämlich in dem Fall, daß Interrupts auftreten und die _delay...()-Funktion unterbrechen. Genau genommen warten diese nämlich nicht eine bestimmte Zeit, sondern verbrauchen eine bestimmte Anzahl von Prozessortakten. Die wiederum ist so bemessen, daß ohne Unterbrechung durch Interrupts die gewünschte Wartezeit erreicht wird.<br />
Wird das Warten aber durch eine oder mehrere ISR unterbrochen, die zusammen 1% Prozessorzeit verbrauchen, dann dauert das Warten etwa 1% länger. Bei 50% Last durch die ISR dauert das Warten doppelt solange wie gewünscht, bei 90% zehnmal solange...<br />
<br />
Abhängig von der Version der Bibliothek verhalten sich die Bibliotheksfunktionen etwas unterschiedlich.<br />
<br />
== avr-libc Versionen bis 1.6 ==<br />
<br />
Die Wartezeit der Funktion _delay_ms() ist auf 262,14ms/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 13,1ms warten. Die Wartezeit der Funktion _delay_us() ist auf 768us/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 38,4µs warten. Längere Wartezeiten müssen dann über einen mehrfachen Aufruf in einer Schleife gelöst werden.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.&nbsp;B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h> /* in älteren avr-libc Versionen <avr/delay.h> */ <br />
<br />
/*<br />
lange, variable Verzögerungszeit, Einheit in Millisekunden<br />
<br />
Die maximale Zeit pro Funktionsaufruf ist begrenzt auf <br />
262.14 ms / F_CPU in MHz (im Beispiel: <br />
262.1 / 3.6864 = max. 71 ms) <br />
<br />
Daher wird die kleine Warteschleife mehrfach aufgerufen,<br />
um auf eine längere Wartezeit zu kommen. Die zusätzliche <br />
Prüfung der Schleifenbedingung lässt die Wartezeit geringfügig<br />
ungenau werden (macht hier vielleicht 2-3ms aus).<br />
*/<br />
<br />
void long_delay(uint16_t ms)<br />
{<br />
for(; ms>0; ms--) _delay_ms(1);<br />
}<br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) // Endlosschleife<br />
{ <br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.&nbsp;B. angeschlossene LED<br />
long_delay(1000); // Eine Sekunde warten...<br />
}<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
== avr-libc Versionen ab 1.7 ==<br />
<br />
_delay_ms() kann mit einem Argument bis 6553,5 ms (= 6,5535 Sekunden) benutzt werden. Es ist nicht möglich, eine Variable als Argument zu übergeben. Wird die früher gültige Grenze von 262,14 ms/F_CPU (in MHz) überschritten, so arbeitet _delay_ms() einfach etwas ungenauer und zählt nur noch mit einer Auflösung von 1/10 ms. Eine Verzögerung von 1000,10 ms ließe sich nicht mehr von einer von 1000,19 ms unterscheiden. Ein Verlust, der sich im Allgemeinen verschmerzen lässt. Dem Programmierer wird keine Rückmeldung gegeben, dass die Funktion ggf. gröber arbeitet, d.h. wenn es darauf ankommt, bitte den Parameter wie bisher geschickt wählen.<br />
<br />
Die Funktion _delay_us() wurde ebenfalls erweitert. Wenn deren maximal als genau behandelbares Argument überschritten wird, benutzt diese intern _delay_ms(). Damit gelten in diesem Fall die _delay_ms() Einschränkungen.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus, avr-libc ab Version 1.6<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h><br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) { // Endlosschleife<br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED<br />
_delay_ms(1000); // Eine Sekunde +/-1/10000 Sekunde warten...<br />
// funktioniert nicht mit Bibliotheken vor 1.6<br />
<br />
}<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
Die _delay_ms() und die _delay_us aus '''avr-libc 1.7.0''' sind fehlerhaft. _delay_ms () läuft 4x schneller als erwartet. Abhilfe ist eine korrigierte Includedatei: [http://www.mikrocontroller.net/topic/196738#1943039]<br />
<br />
= Programmieren mit Interrupts =<br />
<br />
<div style="float:right; margin:2em;"><br />
[[Image:Interrupt Programme.gif]]<br />
</div><br />
Nachdem wir nun alles Wissenswerte für die serielle Programmerstellung<br />
gelernt haben nehmen wir jetzt ein völlig anderes Thema in Angriff, nämlich<br />
die Programmierung unter Zuhilfenahme der Interrupts des AVR.<br />
<br />
Tritt ein Interrupt auf, unterbricht (engl. interrupts) der Controller die Verarbeitung des Hauptprogramms und verzweigt zu einer Interruptroutine. Das Hauptprogramm wird also beim Eintreffen eines Interrupts unterbrochen, die Interruptroutine ausgeführt und danach erst wieder das Hauptprogramm an der Unterbrechungsstelle fortgesetzt (vgl. die Abbildung).<br />
<br />
Um Interrupts verarbeiten zu können, ist folgendes zu beachten:<br />
<br />
* Für jede aktivierte Interruptquelle ist eine Funktion zu programmieren, in der die beim Auftreten des jeweiligen Interrupts erforderlichen Verarbeitungsschritte enthalten sind. Für diese Funktion existieren verschiedene Bezeichnungen. Üblich sind die englischen Begriffe Interrupt-Handler oder Interrupt-Service-Routinen (ISR), man findet aber auch die Bezeichnungen Interruptverarbeitungs- oder -behandlungsroutine oder auch kurz Interruptroutine. Zum Beispiel wird üblicherweise in der ISR zur Verarbeitung des Empfangsinterrupts eines UARTs (UART-RX Interrupt) das empfangene Zeichen in einen Zwischenspeicher (FIFO-Buffer) kopiert, dessen Inhalt später von anderen Programmteilen geleert wird. Sofern der Zwischenspeicher ausreichend groß ist, geht also kein Zeichen verloren, auch wenn im Hauptprogramm zeitintensive Operationen durchgeführt werden.<br />
* Die benötigten Interrupts sind in den jeweiligen Funktionsbausteinen einzuschalten. Dies erfolgt über das jeweilige Aktivierungsbit (Interrupt Enable) in einem der Hardwareregister (z.B. RX(Complete)Interrupt Enable eines UARTs)<br />
* Sämtliche Interrupts werden über einen weiteren globalen Schalter aktiviert und deaktiviert. Zur Verarbeitung der Interrupts ist dieser Schalter zu aktivieren (sei(), siehe unten).<br />
<br />
Alle Punkte sind zu beachten. Fehlt z.B. die globale Aktivierung, werden Interruptroutinen auch dann nicht aufgerufen, wenn sie im Funktionsbaustein eingeschaltet sind und eine Behandlungsroutine verhanden ist.<br />
<br />
Siehe auch<br />
<br />
* [http://www.mikrocontroller.net/forum/read-1-235092.html#new Ausführlicher Thread im Forum]<br />
* Artikel [[Interrupt]]<br />
* Artikel [[Multitasking]]<br />
{{Clear}}<br />
<br />
== Anforderungen an Interrupt-Routinen ==<br />
<br />
Um unliebsamen Überraschungen vorzubeugen, sollten einige Grundregeln bei der Implementierung der Interruptroutinen beachtet werden. Interruptroutinen sollten möglichst kurz und schnell abarbeitbar sein, daraus folgt:<br />
<br />
* Keine umfangreichen Berechnungen innerhalb der Interruptroutine. (*)<br />
* Keine langen Programmschleifen.<br />
* Obwohl es möglich ist, während der Abarbeitung einer Interruptroutine andere oder sogar den gleichen Interrupt wieder zuzulassen, wird davon ohne genaue Kenntnis der internen Abläufe dringend abgeraten.<br />
<br />
Interruptroutinen (ISRs) sollten also möglichst kurz sein und keine Schleifen mit vielen Durchläufen enthalten. Längere Operationen können meist in einen "Interrupt-Teil" in einer ISR und einen "Arbeitsteil" im Hauptprogramm aufgetrennt werden. Z.B. Speichern des Zustands aller Eingänge im EEPROM in bestimmten Zeitabständen: ISR-Teil: Zeitvergleich (Timer,RTC) mit Logzeit/-intervall. Bei Übereinstimmung ein globales Flag setzen (volatile bei Flag-Deklaration nicht vergessen, s.u.). Dann im Hauptprogramm prüfen, ob das Flag gesetzt ist. Wenn ja: die Daten im EEPROM ablegen und Flag löschen.<br />
<br />
(*)<br />
Hinweis: <br />
Es gibt allerdings die seltene Situation, dass man gerade eingelesene<br />
ADC-Werte sofort verarbeiten muss. Besonders dann, wenn man mehrere Werte sehr<br />
schnell hintereinander bekommt. Dann bleibt einem nichts anderes übrig, als die<br />
Werte noch in der ISR zu verarbeiten. Kommt aber sehr selten vor und sollte<br />
durch geeignete Wahl des Systemtaktes bzw. Auswahl des Controllers vermieden werden!<br />
<br />
== Interrupt-Quellen ==<br />
<br />
Die folgenden Ereignisse können einen Interrupt auf einem AVR AT90S2313 auslösen, wobei die Reihenfolge der Auflistung auch die Priorität der Interrupts aufzeigt.<br />
<br />
* Reset<br />
* Externer Interrupt 0<br />
* Externer Interrupt 1<br />
* Timer/Counter 1 Capture Ereignis<br />
* Timer/Counter 1 Compare Match<br />
* Timer/Counter 1 Überlauf<br />
* Timer/Counter 0 Überlauf<br />
* UART Zeichen empfangen<br />
* UART Datenregister leer<br />
* UART Zeichen gesendet<br />
* Analoger Komparator<br />
<br />
Die Anzahl der möglichen Interruptquellen variiert zwischen den verschiedenen Microcontroller-Typen. Im Zweifel hilft ein Blick ins Datenblatt ("Interrupt Vectors").<br />
<br />
== Register ==<br />
<br />
Der AT90S2313 verfügt über 2 Register die mit den<br />
Interrupts zusammenhängen.<br />
<br />
{| class="wikitable"<br />
|- <br />
!width="10%"| GIMSK<br />
| '''G'''eneral '''I'''nterrupt '''M'''a'''sk''' Register.<br /><br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit <br />
| 7 || 6|| 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INT1''' || '''INT0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INT1''' (External '''Int'''errupt Request '''1''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT1'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
'''INT0''' (External '''Int'''errupt Request '''0''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT0'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
|- <br />
! GIFR<br />
| '''G'''eneral '''I'''nterrupt '''F'''lag '''R'''egister.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INTF1''' || '''INTF0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INTF1''' (External '''Int'''errupt Flag '''1''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT1'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
<br />
'''INTF0''' (External '''Int'''errupt Flag '''0''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT0'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
|- <br />
! MCUCR<br />
| '''MCU''' '''C'''ontrol '''R'''egister.<br />
<br />
Das MCU Control Register enthält Kontrollbits für allgemeine MCU-Funktionen.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''-'''|| '''-'''|| '''SE'''|| '''SM'''|| '''ISC11'''|| '''ISC10'''|| '''ISC01'''|| '''ISC00'''<br />
|- <br />
! R/W<br />
| R || R || R/W || R/W || R/W || R/W || R/W || R/W<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
<br />
|}<br />
<br />
'''SE''' ('''S'''leep '''E'''nable)<br />
:Dieses Bit muss gesetzt sein, um den Controller mit dem '''SLEEP'''-Befehl in den Schlafzustand versetzen zu können.<br />
:Um den Schlafmodus nicht irrtümlich einzuschalten, wird empfohlen, das Bit erst unmittelbar vor Ausführung des '''SLEEP'''-Befehls zu setzen.<br />
<br />
'''SM''' ('''S'''leep '''M'''ode)<br />
:Dieses Bit bestimmt über den Schlafmodus.<br />
:Ist das Bit gelöscht, so wird der '''Idle'''-Modus ausgeführt. Ist das Bit gesetzt, so wird der '''Power-Down'''-Modus ausgeführt. (für andere AVR Controller siehe Abschnitt "Sleep-Mode")<br />
<br />
'''ISC11''', '''ISC10''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''1''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT1'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
!width="10%"| ISC11 ||width="10%"| ISC10 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT1''' erzeugt einen Interrupt.<br />
<br />
Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|}<br />
<br />
'''ISC01''', '''ISC00''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''0''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT0'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
!width="10%"| ISC01 ||width="10%"| ISC00 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT0''' erzeugt einen Interrupt.<br />
<br />
Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|}<br />
<br />
|}<br />
<br />
== Allgemeines über die Interrupt-Abarbeitung ==<br />
<br />
Wenn ein Interrupt eintrifft, wird automatisch das '''Global Interrupt Enable''' Bit im Status Register '''SREG''' gelöscht und alle weiteren Interrupts unterbunden. Dieses wird automatisch wieder gesetzt, wenn die Interruptroutine beendet wird. Wenn in der Zwischenzeit weitere Interrupts eintreffen, werden die zugehörigen Interrupt-Bits gesetzt und die Interrupts bei Beendigung der laufenden Interrupt-Routine in der Reihenfolge ihrer Priorität ausgeführt. Dies kann<br />
eigentlich nur dann zu Problemen führen, wenn ein hoch priorisierter Interrupt ständig und in kurzer Folge auftritt. Dieser sperrt dann möglicherweise alle anderen Interrupts mit niedrigerer Priorität. Dies ist einer der Gründe, weshalb die Interrupt-Routinen sehr kurz gehalten werden sollen. Es ist möglich das GIE-Bit in der ISR zu setzen und so schon wieder weitere Interrupts zuzulassen - allerdings sollte man damit vorsichtig sein und genau wissen was man damit macht. Kritisch wird es vor allem wenn der gleiche Interrupt noch einmal kommt, bevor die ISR abgearbeitet ist. <br />
<br />
<!-- === Das Status-Register ===<br />
<br />
Es gilt auch zu beachten, dass das Status-Register während der Abarbeitung einer Interruptroutine nicht automatisch gesichert wird. Falls notwendig, muss dies vom Programmierer selber vorgesehen werden. --><br />
<br />
== Interrupts mit avr-gcc ==<br />
<br />
<!-- ''Anmerkung eines Nutzers: Ich habe mir das Thema hier angearbeitet und hatte am Anfang starke Probleme: Jeder Interrupt muss nochmals einzeln aktiviert werden. Es reicht nicht nur per ''sei()'' die Interrupts global zu aktiveren.'' - mthomas: Hoffentlich duch die modifizerte Einleitung etwas offensichtlicher erläutert. Ansonsten bitte per Eintrag auf die Diskussionseite nochmals melden) --> <br />
<!-- Selbstverständlich können alle interruptspezifischen Registerzugriffe wie gewohnt über I/O-Adressierung vorgenommen werden. Etwas einfacher geht es jedoch, wenn wir die vom Compiler zur Verfügung gestellten Mittel einsetzen.--><br />
Funktionen zur Interrupt-Verarbeitung werden in den Includedateien ''interrupt.h'' der avr-libc zur Verfügung gestellt (bei älterem Quellcode zusätzlich ''signal.h'').<br />
<br />
<syntaxhighlight lang="c"><br />
// fuer sei(), cli() und ISR():<br />
#include <avr/interrupt.h><br />
</syntaxhighlight><br />
<br />
Das Makro '''sei()''' schaltet die Interrupts ein. Eigentlich wird nichts anderes gemacht, als das '''Global Interrupt Enable''' Bit im Status Register gesetzt.<br />
<br />
<syntaxhighlight lang="c"><br />
sei();<br />
</syntaxhighlight><br />
<br />
Das Makro '''cli()''' schaltet die Interrupts aus, oder anders gesagt, das '''Global Interrupt Enable''' Bit im Status Register wird gelöscht.<br />
<br />
<syntaxhighlight lang="c"><br />
cli();<br />
</syntaxhighlight><br />
<br />
Oft steht man vor der Aufgabe, dass eine Codesequenz nicht unterbrochen werden darf. Es liegt dann nahe, zu Beginn dieser Sequenz ein cli() und am Ende ein sei() einzufügen. Dies ist jedoch ungünstig, wenn die Interrupts vor Aufruf der Sequenz deaktiviert waren und danach auch weiterhin deaktiviert bleiben sollen. Ein sei() würde ungeachtet des vorherigen Zustands die Interrupts aktivieren, was zu unerwünschten Seiteneffekten führen kann. Die aus dem folgenden Beispiel ersichtliche Vorgehensweise ist in solchen Fällen vorzuziehen:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <inttypes.h><br />
<br />
//...<br />
<br />
void NichtUnterbrechenBitte(void)<br />
{<br />
uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister<br />
<br />
tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) sichern<br />
cli(); // Interrupts global deaktivieren<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
/* Beispiel Anfang<br />
JTAG-Interface eines ATmega16 per Software deaktivieren <br />
und damit die JTAG-Pins an PORTC für "general I/O" nutzbar machen<br />
ohne die JTAG-Fuse-Bit zu aendern. Dazu ist eine "timed sequence"<br />
einzuhalten (vgl Datenblatt ATmega16, Stand 10/04, S. 229): <br />
Das JTD-Bit muss zweimal innerhalb von 4 Taktzyklen geschrieben <br />
werden. Ein Interrupt zwischen den beiden Schreibzugriffen wuerde <br />
die erforderliche Sequenz "brechen", das JTAG-Interface bliebe<br />
weiterhin aktiv und die IO-Pins weiterhin für JTAG reserviert. */<br />
<br />
MCUCSR |= (1<<JTD);<br />
MCUCSR |= (1<<JTD); // 2 mal in Folge ,vgl. Datenblatt fuer mehr Information<br />
<br />
/* Beispiel Ende */<br />
<br />
SREG = tmp_sreg; // Status-Register wieder herstellen <br />
// somit auch das I-Flag auf gesicherten Zustand setzen<br />
}<br />
<br />
void NichtSoGut(void)<br />
{<br />
cli();<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
sei();<br />
}<br />
<br />
<br />
int main(void)<br />
{<br />
//...<br />
<br />
cli(); <br />
// Interrupts global deaktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// auch nach Aufruf der Funktion deaktiviert<br />
<br />
sei();<br />
// Interrupts global aktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// weiterhin aktiviert<br />
//...<br />
<br />
/* Verdeutlichung der unguenstigen Vorgehensweise mit cli/sei: */<br />
cli(); <br />
// Interrupts jetzt global deaktiviert <br />
<br />
NichtSoGut();<br />
// nach Aufruf der Funktion sind Interrupts global aktiviert <br />
// dies ist mglw. ungewollt!<br />
//...<br />
<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
<!-- mt: besser so nicht(?), lieber "datenblattkonform"<br />
<br />
<font face="Courier New">'''timer_enable_int (unsigned char ints);<br /><br />
'''</font>Schaltet Timerbezogene Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle<br />
Timerinterrupts ausgeschaltet, ansonsten muss in '''ints''' angegeben werden,<br />
welche Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">timer_enable_int (1 << TOIE1));<br /><br />
</font>'''Achtung: Wenn ein Timerinterrupt eingeschaltet wird während ein<br />
anderer Timerinterrupt bereits läuft, dann müssen beide Bits angegeben werden<br />
sonst wird der andere Timerinterrupt versehentlich ausgeschaltet.<br />
<br />
<font face="Courier New">'''enable_external_int (unsigned char ints);<br /><br />
'''</font>Schaltet die externen Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle externen<br />
Interrrups ausgeschaltet, ansonsten muss in '''ints''' angegeben werden, welche<br />
Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">enable_external_int ((1<<br />
</font>'''Schaltet die externen Interrupts 0 und 1 ein.<br />
<br />
Nachdem nun die Interrupts aktiviert sind, braucht es selbstverständlich noch den auszuführenden Code, der ablaufen soll, wenn ein Interrupt eintrifft.<br />
--><br />
Zu den aktivierten Interrupts ist eine Funktion zu programmieren, deren Code aufgerufen wird, wenn der betreffende Interrupt auftritt (Interrupt-Handler, Interrupt-Service-Routine). Dazu existiert die Definition (ein Makro) '''ISR'''.<br />
<br />
=== ISR ===<br />
<br />
(''ISR()'' ersetzt bei neueren Versionen der avr-libc ''SIGNAL()''. SIGNAL sollte nicht mehr genutzt werden, zur Portierung von SIGNAL nach ISR siehe den [[AVR-GCC-Tutorial#Anhang|Anhang]].)<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
//...<br />
ISR(Vectorname) /* vormals: SIGNAL(siglabel) dabei Vectorname != siglabel ! */<br />
{<br />
/* Interrupt Code */<br />
}<br />
</syntaxhighlight><br />
<br />
Mit ''ISR'' wird eine Funktion für die Bearbeitung eines Interrupts eingeleitet. Als Argument muss dabei die Benennung des entsprechenden Interruptvektors angegeben werden. Diese sind in den jeweiligen Includedateien IOxxxx.h zu finden. Die Bezeichnung entspricht dem Namen aus dem Datenblatt, bei dem die Leerzeichen durch Unterstriche ersetzt sind und ein ''_vect'' angehängt ist.<br />
<br />
Als Beispiel ein Ausschnitt aus der Datei für den ATmega8 (bei WinAVR Standardinstallation in C:\WinAVR\avr\include\avr\iom8.h) in der neben den aktuellen Namen für ''ISR'' (*_vect) noch die Bezeichnungen für das inzwischen nicht mehr aktuelle ''SIGNAL'' (SIG_*) enthalten sind.<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
/* $Id: iom8.h,v 1.13 2005/10/30 22:11:23 joerg_wunsch Exp $ */<br />
<br />
/* avr/iom8.h - definitions for ATmega8 */<br />
//...<br />
<br />
/* Interrupt vectors */<br />
<br />
/* External Interrupt Request 0 */<br />
#define INT0_vect _VECTOR(1)<br />
#define SIG_INTERRUPT0 _VECTOR(1)<br />
<br />
/* External Interrupt Request 1 */<br />
#define INT1_vect _VECTOR(2)<br />
#define SIG_INTERRUPT1 _VECTOR(2)<br />
<br />
/* Timer/Counter2 Compare Match */<br />
#define TIMER2_COMP_vect _VECTOR(3)<br />
#define SIG_OUTPUT_COMPARE2 _VECTOR(3)<br />
<br />
/* Timer/Counter2 Overflow */<br />
#define TIMER2_OVF_vect _VECTOR(4)<br />
#define SIG_OVERFLOW2 _VECTOR(4)<br />
<br />
/* Timer/Counter1 Capture Event */<br />
#define TIMER1_CAPT_vect _VECTOR(5)<br />
#define SIG_INPUT_CAPTURE1 _VECTOR(5)<br />
<br />
/* Timer/Counter1 Compare Match A */<br />
#define TIMER1_COMPA_vect _VECTOR(6)<br />
#define SIG_OUTPUT_COMPARE1A _VECTOR(6)<br />
<br />
/* Timer/Counter1 Compare Match B */<br />
#define TIMER1_COMPB_vect _VECTOR(7)<br />
#define SIG_OUTPUT_COMPARE1B _VECTOR(7)<br />
<br />
//...<br />
</syntaxhighlight><br />
<br />
<!--Vor Nutzung von SIGNAL muss ebenfalls die Header-Datei signal.h eingebunden werden.--> <br />
Mögliche Funktionsrümpfe für Interruptfunktionen sind zum Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
/* veraltet: #include <avr/signal.h> */<br />
<br />
ISR(INT0_vect) /* veraltet: SIGNAL(SIG_INTERRUPT0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(TIMER0_OVF_vect) /* veraltet: SIGNAL(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(USART_RXC_vect) /* veraltet: SIGNAL(SIG_UART_RECV) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
// und so weiter und so fort...<br />
</syntaxhighlight><br />
<br />
Auf die korrekte Schreibweise der Vektorbezeichnung ist zu achten. Der gcc-Compiler prüft erst ab Version 4.x, ob ein Signal/Interrupt der angegebenen Bezeichnung tatsächlich in der Includedatei definiert ist und gibt andernfalls eine Warnung aus. Bei WinAVR (ab 2/2005) wurde die Überprüfung auch in den mitgelieferten Compiler der Version 3.x integriert. Aus dem gcc-Quellcode Version 3.x selbst erstellte Compiler enthalten die Prüfung nicht (vgl. [[AVR-GCC]]). <br />
<br />
Während der Ausführung der Funktion sind alle weiteren Interrupts automatisch gesperrt. Beim Verlassen der Funktion werden die Interrupts wieder zugelassen.<br />
<br />
Sollte während der Abarbeitung der Interruptroutine ein weiterer Interrupt (gleiche oder andere Interruptquelle) auftreten, so wird das entsprechende Bit im zugeordneten Interrupt Flag Register gesetzt und die entsprechende Interruptroutine automatisch nach dem Beenden der aktuellen Funktion aufgerufen.<br />
<br />
Ein Problem ergibt sich eigentlich nur dann, wenn während der Abarbeitung der aktuellen Interruptroutine mehrere gleichartige Interrupts auftreten. Die entsprechende Interruptroutine wird im Nachhinein zwar aufgerufen jedoch wissen wir nicht, ob nun der entsprechende Interrupt einmal, zweimal oder gar noch öfter aufgetreten ist. Deshalb soll hier noch einmal betont werden, dass Interruptroutinen so schnell wie nur irgend möglich wieder verlassen werden sollten.<br />
<br />
=== Unterbrechbare Interruptroutinen ===<br />
<br />
"Faustregel": im Zweifel '''ISR'''. Die nachfolgend beschriebene Methode nur dann verwenden, wenn man sich über die unterschiedliche Funktionsweise im Klaren ist.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
<br />
ISR(XXX,ISR_NOBLOCK) /* veraltet: INTERRUPT(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt-Code */<br />
}<br />
</syntaxhighlight><br />
<br />
Hierbei steht XXX für den oben beschriebenen Namen des Vektors (also z.&nbsp;B. ''TIMER0_OVF_vect''). Der Unterschied im Vergleich zu einer herkömmlichen ISR ist, dass hier beim Aufrufen der Funktion das '''Global Enable Interrupt''' Bit durch Einfügen einer SEI-Anweisung direkt wieder gesetzt und somit alle Interrupts zugelassen werden &ndash; auch XXX-Interrupts. <br />
<br />
Bei unsachgemässer Handhabung kann dies zu erheblichen Problemen durch Rekursion wie einem Stack-Overflow oder anderen unerwarteten Effekten führen und sollte wirklich nur dann eingesetzt werden, wenn man sich sicher ist, das Ganze auch im Griff zu haben.<br />
<br />
Insbesondere sollte möglichst am ISR-Anfang die auslösende IRQ-Quelle deaktiviert und erst am Ende der ISR wieder aktiviert werden. Robuster als die Verwendung einer NOBLOCK-ISR ist daher folgender ISR-Aufbau:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
<br />
ISR (XXX) <br />
{<br />
// Implementiere die ISR ohne zunaechst weitere IRQs zuzulassen<br />
<br />
<<Deaktiviere die XXX-IRQ>><br />
<br />
// Erlaube alle Interrupts (ausser XXX)<br />
sei();<br />
<br />
//... Code ...<br />
<br />
// IRQs global deaktivieren um die XXX-IRQ wieder gefahrlos <br />
// aktivieren zu koennen<br />
cli();<br />
<br />
<<Aktiviere die XXX-IRQ>><br />
}<br />
</syntaxhighlight><br />
Auf diese Weise kann sich die XXX-IRQ nicht selbst unterbrechen, was zu einer Art Endlosschleife führen würde.<br />
<br />
Siehe auch: Hinweise in [[AVR-GCC]]<br />
<br />
siehe dazu: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html<br />
<br />
== Datenaustausch mit Interrupt-Routinen ==<br />
<br />
Variablen, die sowohl in Interrupt-Routinen (ISR = Interrupt Service Routine(s)) als auch vom übrigen Programmcode geschrieben oder gelesen werden, müssen mit einem '''volatile''' deklariert werden. Damit wird dem Compiler mitgeteilt, dass der Inhalt der Variablen vor jedem Lesezugriff aus dem Speicher gelesen und nach jedem Schreibzugriff in den Speicher geschrieben wird. Ansonsten könnte der Compiler den Code so optimieren, dass der Wert der Variablen nur in Prozessorregistern zwischengespeichert wird, die nichts von der Änderung woanders mitbekommen.<br />
<br />
Zur Veranschaulichung ein Codefragment für eine Tastenentprellung mit Erkennung einer "lange gedrückten" Taste.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <stdint.h><br />
//...<br />
<br />
// Schwellwerte<br />
// Entprellung: <br />
#define CNTDEBOUNCE 10<br />
// "lange gedrueckt:"<br />
#define CNTREPEAT 200<br />
<br />
// hier z.&nbsp;B. Taste an Pin2 PortA "active low" = 0 wenn gedrueckt<br />
#define KEY_PIN PINA<br />
#define KEY_PINNO PA2<br />
<br />
// beachte: volatile! <br />
volatile uint8_t gKeyCounter;<br />
<br />
// Timer-Compare Interrupt ISR, wird z.B. alle 10ms ausgefuehrt<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
// hier wird gKeyCounter veraendert. Die übrigen<br />
// Programmteile müssen diese Aenderung "sehen":<br />
// volatile -> aktuellen Wert immer in den Speicher schreiben<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
}<br />
else {<br />
gKeyCounter = 0;<br />
}<br />
}<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
//...<br />
/* hier: Initialisierung der Ports und des Timer-Interrupts */<br />
//... <br />
// hier wird auf gKeyCounter zugegriffen. Dazu muss der in der<br />
// ISR geschriebene Wert bekannt sein:<br />
// volatile -> aktuellen Wert immer aus dem Speicher lesen<br />
if ( gKeyCounter > CNTDEBOUNCE ) { // Taste mind. 10*10 ms "prellfrei"<br />
if (gKeyCounter == CNTREPEAT) {<br />
/* hier: Code fuer "Taste lange gedrueckt" */<br />
}<br />
else {<br />
/* hier: Code fuer "Taste kurz gedrueckt" */<br />
}<br />
}<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Wird innerhalb einer ISR mehrfach auf eine mit volatile deklarierte Variable zugegriffen, wirkt sich dies ungünstig auf die Verarbeitungsgeschwindigkeit aus, da bei jedem Zugriff mit dem Speicherinhalt abgeglichen wird. Da bei AVR-Controllern ''innerhalb'' einer ISR keine Unterbrechungen zu erwarten sind, bietet es sich an, einen Zwischenspeicher in Form einer lokalen Variable zu verwenden, deren Inhalt zu Beginn und am Ende mit dem der volatile Variable synchronisiert wird. Lokale Variable werden bei eingeschalteter Optimierung mit hoher Wahrscheinlichkeit in Prozessorregistern verwaltet und der Zugriff darauf ist daher nur mit wenigen internen Operationen verbunden. Die ISR aus dem vorherigen Beispiel lässt sich so optimieren:<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter; // Uebernahme in lokale Arbeitsvariable<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (tmp_kc < CNTREPEAT) {<br />
tmp_kc++;<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc; // Zurueckschreiben<br />
}<br />
//...<br />
</syntaxhighlight><br />
<br />
Zum Vergleich die Disassemblies (Ausschnitte der "lss-Dateien", compiliert für ATmega162) im Anschluss. Man erkennt den viermaligen Zugriff auf die Speicheraddresse von ''gKeyCounter'' (hier 0x032A) in der ISR ohne "Cache"-Variable und den zweimaligen Zugriff in der Variante mit Zwischenspeicher. Im Beispiel ist der Vorteil gering, bei komplexeren Routinen kann die Zwischenspeicherung in lokalen Variablen jedoch zu deutlicheren Verbesserungen führen.<br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
876: ca 99 sbic 0x19, 2 ; 25<br />
878: 0a c0 rjmp .+20 ; 0x88e <__vector_13+0x24><br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
87a: 80 91 2a 03 lds r24, 0x032A<br />
87e: 88 3c cpi r24, 0xC8 ; 200 <br />
880: 40 f4 brcc .+16 ; 0x892 <__vector_13+0x28><br />
882: 80 91 2a 03 lds r24, 0x032A<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 02 c0 rjmp .+4 ; 0x892 <__vector_13+0x28><br />
}<br />
else {<br />
gKeyCounter = 0;<br />
88e: 10 92 2a 03 sts 0x032A, r1<br />
892: 8f 91 pop r24<br />
894: 0f 90 pop r0<br />
896: 0f be out 0x3f, r0 ; 63<br />
898: 0f 90 pop r0<br />
89a: 1f 90 pop r1<br />
89c: 18 95 reti<br />
</pre><br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter;<br />
876: 80 91 2a 03 lds r24, 0x032A<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
87a: ca 9b sbis 0x19, 2 ; 25<br />
87c: 02 c0 rjmp .+4 ; 0x882 <__vector_13+0x18><br />
87e: 80 e0 ldi r24, 0x00 ; 0<br />
880: 03 c0 rjmp .+6 ; 0x888 <__vector_13+0x1e><br />
if (tmp_kc < CNTREPEAT) {<br />
882: 88 3c cpi r24, 0xC8 ; 200<br />
884: 08 f4 brcc .+2 ; 0x888 <__vector_13+0x1e><br />
tmp_kc++;<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc;<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 8f 91 pop r24<br />
88e: 0f 90 pop r0<br />
890: 0f be out 0x3f, r0 ; 63<br />
892: 0f 90 pop r0<br />
894: 1f 90 pop r1<br />
896: 18 95 reti<br />
</pre><br />
<br />
=== volatile und Pointer ===<br />
<br />
Bei '''volatile''' in Verbindung mit Pointern ist zu beachten, ob der Pointer selbst oder die Variable, auf die der Pointer zeigt, '''volatile''' ist.<br />
<br />
<syntaxhighlight lang="c"><br />
volatile uint8_t *a; // das Ziel von a ist volatile<br />
<br />
uint8_t *volatile a; // a selbst ist volatile<br />
</syntaxhighlight><br />
<br />
Falls der Pointer volatile ist (zweiter Fall im Beispiel), ist zu beachten, dass der Wert des Pointers, also eine Speicheradresse, intern in mehr als einem Byte verwaltet wird. Lese- und Schreibzugriffe im Hauptprogramm (außerhalb von Interrupt-Routinen) sind daher so zu implementieren, dass alle Teilbytes der Adresse konsistent bleiben, vgl. dazu den folgenden Abschnitt.<br />
<br />
=== Variablen größer 1 Byte ===<br />
<br />
Bei Variablen größer ein Byte, auf die in Interrupt-Routinen und im Hauptprogramm zugegriffen wird, muss darauf geachtet werden, dass die Zugriffe auf die einzelnen Bytes außerhalb der ISR nicht durch einen Interrupt unterbrochen werden. (Allgemeinplatz: AVRs sind 8-bit Controller). Zur Veranschaulichung ein Codefragment:<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
volatile uint16_t gMyCounter16bit;<br />
//...<br />
ISR(...)<br />
{<br />
//...<br />
gMyCounter16Bit++;<br />
//...<br />
}<br />
<br />
int main(void)<br />
{<br />
uint16_t tmpCnt;<br />
//...<br />
// nicht gut: Mglw. hier ein Fehler, wenn ein Byte von MyCounter <br />
// schon in tmpCnt kopiert ist aber vor dem Kopieren des zweiten Bytes <br />
// ein Interrupt auftritt, der den Inhalt von MyCounter verändert.<br />
tmpCnt = gMyCounter16bit; <br />
<br />
<br />
// besser: Änderungen "außerhalb" verhindern -> alle "Teilbytes"<br />
// bleiben konsistent<br />
cli(); // Interrupts deaktivieren<br />
tmpCnt = gMyCounter16Bit;<br />
sei(); // wieder aktivieren<br />
<br />
// oder: vorheriger Status des globalen Interrupt-Flags bleibt erhalten<br />
uint8_t sreg_tmp;<br />
sreg_tmp = SREG; /* Sichern */<br />
cli()<br />
tmpCnt = gMyCounter16Bit;<br />
SREG = sreg_tmp; /* Wiederherstellen */<br />
<br />
// oder: mehrfach lesen, bis man konsistente Daten hat<br />
uint16_t count1 = gMyCounter16Bit;<br />
uint16_t count2 = gMyCounter16Bit;<br />
while (count1 != count2) {<br />
count1 = count2;<br />
count2 = gMyCounter16Bit;<br />
}<br />
tmpCnt = count1;<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Die avr-libc bietet ab Version 1.6.0(?) einige Hilfsfunktionen/Makros, mit der im Beispiel oben gezeigten Funktionalität, die zusätzlich auch sogenannte [http://en.wikipedia.org/wiki/Memory_barrier memory barriers] beinhalten. Diese stehen nach #include <util/atomic.h> zur Verfügung.<br />
<syntaxhighlight lang="c"><br />
//...<br />
#include <util/atomic.h><br />
//...<br />
<br />
// analog zu cli, Zugriff, sei:<br />
ATOMIC_BLOCK(ATOMIC_FORCEON) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
// oder:<br />
<br />
// analog zu Sicherung des SREG, cli, Zugriff und Zurückschreiben des SREG:<br />
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
//...<br />
</syntaxhighlight><br />
<br />
* siehe auch [http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Dokumentation der avr-libc zu atomic.h]<br />
<br />
== Interrupt-Routinen und Registerzugriffe ==<br />
<br />
Falls Register sowohl im Hauptprogramm als auch in Interrupt-Routinen verändert werden, ist darauf zu achten, dass diese Zugriffe sich nicht überlappen. Nur wenige Anweisungen lassen sich in sogenannte "atomare" Zugriffe übersetzen, die nicht von Interrupt-Routinen unterbrochen werden können. <br />
<br />
Zur Veranschaulichung eine Anweisung, bei der ein Bit und im Anschluss drei Bits in einem Register gesetzt werden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
int main(void)<br />
{<br />
//...<br />
PORTA |= (1<<PA0);<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Der Compiler übersetzt diese Anweisungen für einen ATmega128 bei Optimierungsstufe "S" nach:<br />
<br />
<div class="code"><pre><br />
...<br />
PORTA |= (1<<PA0);<br />
d2: d8 9a sbi 0x1b, 0 ; 27 (a)<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
d4: 8b b3 in r24, 0x1b ; 27 (b)<br />
d6: 8c 61 ori r24, 0x1C ; 28 (c)<br />
d8: 8b bb out 0x1b, r24 ; 27 (d)<br />
...<br />
</pre></div><br />
<br />
Das Setzen des einzelnen Bits wird bei eingeschalteter Optimierung für Register im unteren Speicherbereich in eine einzige Assembler-Anweisung (sbi) übersetzt und ist nicht anfällig für Unterbrechungen durch Interrupts. Die Anweisung zum Setzen von drei Bits wird jedoch in drei abhängige Assembler-Anweisungen übersetzt und bietet damit zwei "Angriffspunkte" für Unterbrechungen. Eine Interrupt-Routine könnte nach dem Laden des Ausgangszustands in den Zwischenspeicher (hier Register 24) den Wert des Registers ändern, z.&nbsp;B. ein Bit löschen. Damit würde der Zwischenspeicher nicht mehr mit dem tatsächlichen Zustand übereinstimmen aber dennoch nach der Bitoperation (hier ori) in das Register zurückgeschrieben. <br />
<br />
Beispiel: PORTA sei anfangs 0b00000000. Die erste Anweisung (a) setzt Bit 0 auf '''1''', PORTA ist danach 0b0000000'''1'''. Nun wird im ersten Teil der zweiten Anweisung der Portzustand in ein Register eingelesen (b). Unmittelbar darauf (vor (c)) "feuert" ein Interrupt, in dessen Interrupt-Routine Bit 0 von PORTA gelöscht wird. Nach Verlassen der Interrupt-Routine hat PORTA den Wert 0b00000000. In den beiden noch folgenden Anweisungen des Hauptprogramms wird nun der zwischengespeicherte "alte" Zustand 0b00000001 mit 0b00011100 logisch-'''ODER'''-verknüft (c) und das Ergebnis 0b00011101 in PortA geschrieben (d). Obwohl zwischenzeitlich Bit 0 gelöscht wurde, ist es nach (d) wieder gesetzt. <br />
<br />
Lösungsmöglichkeiten:<br />
* Register ohne besondere Vorkehrungen nicht in Interruptroutinen ''und'' im Hauptprogramm verändern.<br />
* Interrupts vor Veränderungen in Registern, die auch in ISRs verändert werden, deaktivieren ("cli").<br />
* Bits einzeln löschen oder setzen. sbi und cbi können nicht unterbrochen werden. Vorsicht: nur Register im unteren Speicherbereich sind mittels sbi/cbi ansprechbar. Der Compiler kann nur für diese sbi/cbi-Anweisungen generieren. Für Register außerhalb dieses Adressbereichs ("Memory-Mapped"-Register) werden auch zur Manipulation einzelner Bits abhängige Anweisungen erzeugt (lds,...,sts).<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Frequently asked Questions/Fragen Nr. 1 und 8. (Stand: avr-libc Vers. 1.0.4)<br />
<br />
== Interruptflags löschen ==<br />
<br />
Beim Löschen von Interruptflags haben AVRs eine Besonderheit, die auch im Datenblatt beschrieben ist: Es wird zum Löschen eine 1 in das betreffende Bit geschrieben. <br />
<br />
Hinweis:<br /><br />
Bei Registern mit mehreren Interrupt-Flag-Bits (wie die Timer Interrupt Flag Register) '''nicht''' die übliche bitweise VerODERung nehmen, sondern eine direkte Zuweisung machen. Da sonst weitere Flags, als nur das gewünschte, ebenfalls gelöscht werden könnten.<br /><br />
([http://www.mikrocontroller.net/topic/171148#1640133 Erklärung]).<br />
<br />
== Was macht das Hauptprogramm? ==<br />
<br />
Im einfachsten (Ausnahme-)Fall gar nichts mehr. Es ist also durchaus denkbar, ein Programm zu schreiben, welches in der main-Funktion lediglich noch die Interrupts aktiviert und dann in einer Endlosschleife verharrt. Sämtliche Funktionen werden dann in den ISRs abgearbeitet. Diese Vorgehensweise ist jedoch bei den <i>meisten</i> Anwendungen schlecht: man verschenkt eine Verarbeitungsebene und hat außerdem möglicherweise Probleme durch Interruptroutinen, die zu viel Verarbeitungszeit benötigen. Für <i>wenige</i> Anwendungen ist diese Vorgehensweise jedoch perfekt: Die Hauptschleife verkommt zu <tt>for(;;) sleep_spu();</tt> — siehe nächster Abschnitt „Sleep“. Weiterer Vorteil: ISRs brauchen keine(!) Register retten, ein Fall für <tt>ISR(<i>name</i>,ISR_NAKED){ … reti();}</tt>.<br />
<br />
Normalerweise wird man in den Interruptroutinen nur die bei Auftreten des jeweiligen Interruptereignisses unbedingt notwendigen Operationen ausführen lassen. Alle weniger kritischen Aufgaben werden dann im Hauptprogramm abgearbeitet.<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Interrupts and Signals<br />
<br />
= Sleep-Modes =<br />
<br />
AVR Controller verfügen über eine Reihe von sogenannten [[Sleep Mode |''Sleep-Modes'']] ("Schlaf-Modi"). Diese ermöglichen es, Teile des Controllers abzuschalten. Zum Einen kann damit besonders bei Batteriebetrieb Strom gespart werden, zum Anderen können Komponenten des Controllers deaktiviert werden, die die Genauigkeit des Analog-Digital-Wandlers bzw. des Analog-Comparators negativ beeinflussen. Der Controller wird durch Interrupts aus dem Schlaf geweckt. Welche Interrupts den jeweiligen Schlafmodus beenden, ist einer Tabelle im Datenblatt des jeweiligen Controllers zu entnehmen.<br />
Die Funktionen (eigentlich Makros) der avr-libc stehen nach Einbinden der header-Datei ''sleep.h'' zur Verfügung.<br />
<br />
;set_sleep_mode (uint8_t mode): Setzt den Schlafmodus, der bei Aufruf von sleep() aktiviert wird. In sleep.h sind einige Konstanten definiert (z.&nbsp;B. SLEEP_MODE_PWR_DOWN). Die definierten Modi werden jedoch nicht alle von sämtlichten AVR-Controllern unterstützt.<br />
;sleep_enable(): Aktiviert den gesetzten Schlafmodus, versetzt den Controller aber noch nicht in den Schlafmodus<br />
;sleep_cpu(): Versetzt den Controller in den Schlafmodus .sleep_cpu wird im Prinzip durch die Assembler-Anweisung ''sleep'' ersetzt.<br />
;sleep_disable(): Deaktiviert den gesetzten Schlafmodus<br />
;sleep_mode(): Versetzt den Controller in den mit set_sleep_mode gewählten Schlafmodus. Das Makro entspricht sleep_enable()+sleep_cpu()+sleep_disable(), beinhaltet also nicht die Aktivierung von Interrupts (besser nicht benutzen).<br />
<br />
Bei Anwendung von sleep_cpu() müssen Interrupts also bereits freigeben sein (sei()), da der Controller sonst nicht mehr "aufwachen" kann. sleep_mode() ist nicht geeignet für die Verwendung in ISR Interrupt-Service-Routinen, da bei deren Abarbeitung Interrupts global deaktiviert sind und somit auch die möglichen "Aufwachinterrupts". Abhilfe: stattdessen sleep_enable(), sei(), sleep_cpu(), sleep_disable() und evtl. cli() verwenden (vgl. Dokumentation der avr-libc).<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/sleep.h><br />
<br />
int main(void)<br />
{<br />
...<br />
<br />
while (1) {<br />
...<br />
set_sleep_mode(SLEEP_MODE_PWR_DOWN);<br />
sleep_mode();<br />
<br />
// Code hier wird erst nach Auftreten eines entsprechenden<br />
// "Aufwach-Interrupts" verarbeitet<br />
...<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
In älteren Versionenen der avr-libc wurden nicht alle AVR-Controller durch die sleep-Funktionen richtig angesteuert. Mit avr-libc 1.2.0 wurde die Anzahl der unterstützten Typen jedoch deutlich erweitert. Bei nicht-unterstützten Typen erreicht man die gewünschte Funktionalität durch direkte "[[Bitmanipulation]]" der entsprechenden Register (vgl. Datenblatt) und Aufruf des Sleep-Befehls via Inline-Assembler oder sleep_cpu():<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
// Sleep-Mode "Power-Save" beim ATmega169 "manuell" aktivieren<br />
SMCR = (3<<SM0) | (1<<SE);<br />
asm volatile ("sleep"::); // alternativ sleep_cpu() aus sleep.h<br />
...<br />
</syntaxhighlight><br />
<br />
== Sleep-Modi ==<br />
Die vielen Prozessoren aus der AVR-Familie unterstützen unterschiedliche Sleep-Modi, gefächert nach Vorhandensein von Funktionsblöcken im Controller. Konkrete und verläßliche Auskunft über die tatsächlichen Gegebenheiten finden sich wie immer in den jeweiligen Datenblättern. Die Modi unterscheiden sich darin, welche Funktionsbereiche zum Energiesparen abgeschaltet werden. Davon hängt auch ab, mit welchen Mitteln der Prozessor aus der jeweiligen Schlaftiefe wieder aufgeweckt werden kann.<br />
<br />
;Idle Mode (SLEEP_MODE_IDLE): Die CPU kann durch SPI, USART, Analog Comperator, ADC, TWI, Timer, Watchdog und irgendeinen anderen Interrupt wieder aufgeweckt werden.<br />
<br />
;ADC Noise Reduction Mode (SLEEP_MODE_ADC): In diesem Modus liegt das Hauptaugenmerk darauf, die CPU soweit stillzulegen, dass der ADC möglichst keine Störungen aus dem inneren der CPU auffangen kann, die das Meßergebnis negativ beeinflussen können. Das Aufwachen aus diesem Modus kann ausgelöst werden durch den ADC, externe Interrupts, TWI, Timer und Watchdog.<br />
<br />
;Power-Down Mode (SLEEP_MODE_PWR_DOWN): In diesem Modus wird ein externer Oszillator (Quarz, Quarzoszillator), wenn vorhanden. gestoppt. Geweckt werden kann die CPU durch einen externen Level-Interrupt, TWI, Watchdog, Brown-Out-Reset.<br />
<br />
;Power-Save-Mode (SLEEP_MODE_PWR_SAVE): Power-Save ist identisch zu Power-Down mit einer Ausnahme: Ist der Timer 2 auf die Verwendung eines externen Taktes konfiguriert, so läuft dieser Timer auch im Power-Save weiter und kann die CPU mit einem Interrupt aufwecken.<br />
<br />
;Standby-Mode (SLEEP_MODE_STANDBY, SLEEP_MODE_EXT_STANDBY): Voraussetzung für den Standby-Modus ist die Verwendung eines Quarzes oder eines Quarzoszillators, also einer externen Taktquelle. Ansonsten ist dieser Modus identisch zum Power-Down Modus. Vorteil dieses Modus' ist eine kürzere Aufwachzeit.<br />
<br />
;Abschalten des Brownout Detect (BOD) während der Sleep-Phase (nur P-Typen): Zur Stromersparnis bieten die P-Typen die Möglichkeit den BOD während der Sleep-Phase abzuschalten. Bei einem Atmega88PA beispielsweise, kann dadurch der Stromverbrauch im SLEEP_MODE_PWR_SAVE mit Timer2 im Asynchronmodus mit Uhrenquarz und periodischer Selbstaufweckung um ca. 50% gesenkt werden.<br />
Das Einschalten dieser Funktion geschieht in einer Timed Sequence.<br />
<br />
<syntaxhighlight lang="c"><br />
unsigned char temp0 = MCUCR;<br />
unsigned char temp1 = MCUCR;<br />
temp0 |= (1 << BODS) | (1 << BODSE);<br />
temp1 |= (1 << BODS);<br />
MCUCR = temp0;<br />
MCUCR = temp1;<br />
sleep_cpu();<br />
</syntaxhighlight><br />
<br />
Hierbei ist unbedingt zu beachten, dass das BODS-Bit 3 Takte nach dem Setzen wieder gelöscht wird. Daher muss der Aufruf des Sleep unmittelbar nach dem Setzen erfolgen und das BODS-Bit muss jedes Mal vor einem Sleep Aufruf erneut gesetzt werden.<br />
<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Power Management and Sleep-Modes<br />
* [http://www.mikrocontroller.net/topic/96369#832712 Forenbeitrag] zur "Nichtverwendung" von sleep_mode in ISRs.<br />
<br />
= Zeiger =<br />
Zeiger (engl. ''Pointer'') sind Variablen, die die Adresse von Daten oder Funktionen enthalten und belegen 16 Bits. Die Größe hängt mit dem adressierbaren Speicherbereich zusammen und der GCC reserviert dann den entsprechenden Platz.<br />
Ggf. ist es also günstiger, Indizes auf Arrays (Listen) zu verwenden, so dass der GCC für die Zeigerarithmetik den erforderlichen RAM nur temporär benötigt.<br />
<br />
Siehe auch: [[Zeiger]]<br />
<br />
= Speicherzugriffe =<br />
<br />
Atmel AVR-Controller verfügen typisch über drei Speicher:<br />
<br />
* [[RAM]]: Im RAM (genauer statisches RAM/SRAM) wird vom gcc-Compiler Platz für Variablen reserviert. Auch der Stack befindet sich im RAM. Dieser Speicher ist "flüchtig", d.h. der Inhalt der Variablen geht beim Ausschalten oder einem Zusammenbruch der Spannungsversorgung verloren.<br />
<br />
* Programmspeicher: Ausgeführt als FLASH-Speicher, seitenweise wiederbeschreibbar. Darin ist das Anwendungsprogramm abgelegt.<br />
<br />
* [[EEPROM]]: Nichtflüchtiger Speicher, d.h. der einmal geschriebene Inhalt bleibt auch ohne Stromversorgung erhalten. Byte-weise schreib/lesbar. Im EEPROM werden typischerweise gerätespezifische Werte wie z.&nbsp;B. Kalibrierungswerte von Sensoren abgelegt.<br />
<br />
Einige AVRs besitzen keinen RAM-Speicher, lediglich die Register können als "Arbeitsvariablen"<br />
genutzt werden. Da die Anwendung des avr-gcc auf solch "kleinen" Controllern ohnehin selten sinnvoll ist und auch nur bei einigen RAM-losen Typen nach [http://lightner.net/avr/ATtinyAvrGcc.html "Bastelarbeiten"] möglich ist, werden diese Controller hier nicht weiter berücksichtigt. Auch EEPROM-Speicher ist nicht auf allen Typen verfügbar. Generell sollten die nachfolgenden Erläuterungen auf alle ATmega-Controller und die größeren AT90-Typen übertragbar sein. Für die Typen ATtiny2313, ATtiny26 und viele weitere der "ATtiny-Reihe" gelten die Ausführungen ebenfalls.<br />
<br />
Siehe auch:<br />
* [[Binäre Daten zum Programm hinzufügen]]<br />
== RAM ==<br />
<br />
Die Verwaltung des RAM-Speichers erfolgt durch den Compiler, im Regelfall ist beim Zugriff auf Variablen im RAM nichts Besonderes zu beachten. Die Erläuterungen in jedem brauchbaren C-Buch gelten auch für den vom avr-gcc-Compiler erzeugten Code.<br />
<br />
Um Speicher dynamisch (während der Laufzeit) zu reservieren, kann '''malloc()''' verwendet werden. malloc(size) "alloziert" (~reserviert) einen gewissen Speicherblock mit '''size''' Bytes. Ist kein Platz für den neuen Block, wird NULL (0) zurückgegeben.<br />
<br />
Wird der angelegte Block zu klein (groß), kann die Größe mit realloc() verändert werden. Den allozierten Speicherbereich kann man mit free() wieder freigeben. Wenn das Freigeben eines Blocks vergessen wird spricht man von einem "Speicherleck" (memory leak).<br />
<br />
malloc() legt Speicherblöcke im '''Heap''' an, belegt man zuviel Platz, dann wächst der Heap zu weit nach oben und überschreibt den Stack, und der Controller kommt in Teufels Küche. Das kann leider nicht nur passieren wenn man insgesamt zu viel Speicher anfordert, sondern auch wenn man Blöcke unterschiedlicher Größe in ungünstiger Reihenfolge alloziert/freigibt (siehe Artikel [[Heap-Fragmentierung]]). Aus diesem Grund sollte man malloc() auf Mikrocontrollern sehr sparsam (am besten gar nicht) verwenden.<br />
<br />
Beispiel zur Verwendung von malloc():<br />
<syntaxhighlight lang="c"><br />
#include <stdlib.h><br />
<br />
void foo(void) {<br />
// neuen speicherbereich anlegen,<br />
// platz für 10 uint16<br />
uint16_t* pBuffer = malloc(10 * sizeof(uint16_t));<br />
<br />
// darauf zugreifen, als wärs ein gewohnter Buffer<br />
pBuffer[2] = 5;<br />
<br />
// Speicher (unbedingt!) wieder freigeben<br />
free(pBuffer);<br />
}<br />
</syntaxhighlight><br />
<br />
Wenn (wie in obigem Beispiel) dynamischer Speicher nur für die Dauer einer Funktion benötigt und am Ende wieder freigegeben wird, bietet es sich an, statt malloc() '''alloca()''' zu verwenden. Der Unterschied zu malloc() ist, dass der Speicher auf dem Stack reserviert wird, und beim Verlassen der Funktion automatisch wieder freigegeben wird. Es kann somit kein Speicherleck und keine Fragmentierung entstehen.<br />
<br />
siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/malloc.html AVR Libc Home Page]: Memory Areas and Using malloc()<br />
* [https://www.mikrocontroller.net/topic/479027#5934443 Forumsbeitrag]: RAM Verbrauch auch von lokalen variablen ermitteln<br />
<br />
== Flash mit PROGMEM und pgm_read ==<br />
<br />
→ [http://nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html avr-libc: Doku zu avr/pgmspace.h]<br />
<br />
Ein Zugriff auf Konstanten im Programmspeicher ist mittels avr-gcc erst ab Version 4.7 "transparent" möglich. Um Daten aus dem Flash zu lesen, muss die AVR-Instruktion LPM (''Load from Program Memory'') erzeugt werden, bei Controllern mit mehr als 64kiB Flash auch ELPM.<br />
<br />
Dazu gibt es das AVR-spezifische GCC-Attribut <tt>progmem</tt>, mit dem eine Variablendeklaration im ''static storage''<ref>Variablen der Speicherklasse ''static storage'' haben eine unbegrenzte Lebensdauer. Beispiel für solche Variablen sind globale Variablen, aber auch static-Variablen innerhalb einer Funktion gehören dazu. Beispiele für Variablen, die nicht ''static storage'' sind: auto-Variablen ("normale" lokale Variablen), register-Variablen, durch malloc geschaffene Objekte, etc.</ref> markiert werden kann:<br />
<syntaxhighlight lang="c"><br />
const int value __attribute__((progmem)) = 1;<br />
</syntaxhighlight><br />
<br />
Effekt ist, dass die so markierte Variable nicht im RAM sondern im Flash angelegt wird. Wird durch "normalen" C-Code auf solch eine Variable zugegriffen, wird jedoch aus der gleichen Adresse aus dem RAM gelesen und nicht aus dem Flash! Das ist ein Fehler, den der Compiler aber nicht anzeigt!<br />
<br />
<syntaxhighlight lang="c"><br />
int test = value; // Fehler! PROGMEM Konstanten müssen mit den pgm_read-Funktionen gelesen werden!<br />
</syntaxhighlight><br />
<br />
Zum Lesen aus dem Flash stellt die avr-libc daher zahlreiche Makros zur Verfügung. Zudem wird das Makro <tt>PROGMEM</tt> definiert, das etwas Tipparbeit spart:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
const int value PROGMEM = 1;<br />
</syntaxhighlight><br />
<br />
<tt>progmem</tt> funktioniert im Wesentlichen wie ein Section-Attribut, das die Daten in der Section <tt>.progmem.data</tt> ablegt. Im Gegensatz zum Section-Attribut werden jedoch noch weitere Prüfungen unternommen, ab avr-gcc 4.6 etwa muss die entsprechende Variable <tt>const</tt> sein.<br />
<br />
=== Integer und float ===<br />
<br />
Zum Lesen von Skalaren stellt die avr-libc folgende Makros zu Verfügung, die jeweils ein Argument erhalten: Die 16-Bit Adresse des zu lesenden Wertes<ref>Damit ist der mögliche Speicherbereich für Flash-Konstanten auf 64kiB begrenzt. Einige pgmspace-Funktionen ermöglichen den Lesezugriff auf den gesamten Flash-Speicher, intern via Assembler-Anweisung ELPM. Die Initialisierungswerte des Speicherinhalts jenseits der 64kiB-Marke müssen dann jedoch auf anderem Weg angelegt werden, d.h. nicht per PROGMEM. Evtl. eigene Section und Linker-Optionen. Alt und nicht ganz korrekt: Die avr-libc pgmspace-Funktionen unterstützen nur die unteren 64kiB Flash bei Controllern mit mehr als 64kiB.</ref><br />
<br />
:{| {{Tabelle}}<br />
|+ Übersicht der <tt>pgm_read</tt> Funktionen aus<br/>dem Header <tt>avr/pgmspace.h</tt> der avr-libc<br />
|-<br />
! Gelesener Wert || <tt>pgm_read_xxx</tt> || Anzahl Bytes<br />
|-<br />
| <tt>uint8_t</tt> || <tt>pgm_read_byte</tt> || 1<br />
|-<br />
| <tt>uint16_t</tt> || <tt>pgm_read_word</tt> || 2<br />
|-<br />
| <tt>uint32_t</tt> || <tt>pgm_read_dword</tt> || 4<br />
|-<br />
| <tt>float</tt> || <tt>pgm_read_float</tt><ref>ab avr-libc 1.7.0</ref> || 4<br />
|}<br />
<br />
Soll ein Zeiger gelesen werden, so verwendet man <tt>pgm_read_word</tt> und castet das Ergebnis zum gewünschten Zeiger-Typ.<br />
<br />
;Beispiele:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
/* Byte */<br />
const uint8_t aByte PROGMEM = 123;<br />
<br />
/* int-Array */<br />
const int anArray[] PROGMEM = { 18, 3 ,70 };<br />
<br />
void foo (void)<br />
{<br />
/* Zeiger */<br />
static const uint8_t* const aPointer PROGMEM = &aByte;<br />
<br />
uint8_t a = pgm_read_byte (&aByte);<br />
int a2 = (int) pgm_read_word (&anArray[2]);<br />
const uint8_t* p = (const uint8_t*) pgm_read_word (&aPointer);<br />
}<br />
</syntaxhighlight><br />
<br />
=== Blöcke ===<br />
<br />
In den Flash-Funktionen der avr-libc sind keine der pgm_read_xxxx Nomenklatur folgenden Funktionen, die Speicherblöcke auslesen oder vergleichen. Die enstprechende Funktionen sind Varianten von <tt>memcpy</tt>, <tt>memcmp</tt> und heißt <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, usw. Für weitere Funktionen und deren Prototypen siehe die Dokumentation der avr-libc.<br />
<br />
=== Strings ===<br />
<br />
Strings sind in C nichts anderes als eine Abfolge von Zeichen und einem <tt>'\0'</tt> als Stringende. Der prinzipielle Weg ist daher identisch zum Lesen von Bytes, wobei auf die [[FAQ#Wie funktioniert String-Verarbeitung in C?|Besonderheiten von Strings]] wie 0-Terminierung geachtet werden muss.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
size_t my_string_length (const char *addr)<br />
{<br />
size_t length = 0;<br />
<br />
while (pgm_read_byte (addr++))<br />
{<br />
length++;<br />
}<br />
return length;<br />
}<br />
</syntaxhighlight><br />
<br />
Zur Unterstützung des Programmierers steht das Repertoire der str-Funktionen auch in jeweils eine Variante zur Verfügung, die mit dem Flash-Speicher arbeiten kann. Die Funktionsnamen tragen den Suffix <tt>_P</tt>. Darüber hinaus gibt es das Makro <tt>PSTR</tt>, das ein String-Literal im Flash-Speicher ablegt und die Adresse des Strings liefert:<br />
<br />
Die nachfolgende Funktion liefert 0 zurück, wenn string_im_ram gleich "Hallo Welt" ist. Mit strcmp (String Compare) können wir zwei Strings vergleichen. Der Rückgabewert kann hierbei folgende Werte haben:<br><br />
0 die Strings sind gleich<br />
>0 das erste ungleiche Zeichen in string_im_ram ist größer als in "Hallo Welt"<br />
<0 das erste ungleiche Zeichen in string_im_ram ist kleiner als in "Hallo Welt"<br />
<br><br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
int foo (const char *string_im_ram)<br />
{<br />
return strcmp_P (string_im_ram, PSTR ("Hallo Welt"));<br />
}<br />
</syntaxhighlight><br />
<br />
Zu beachten ist, dass <tt>PSTR</tt> nur innerhalb von Funktionen verwendet werden kann.<br />
<br />
; Array aus Strings:<br />
<br />
Arrays aus Strings im Flash-Speicher werden in zwei Schritten angelegt:<br />
<br />
# Zuerst die einzelnen Elemente des Arrays und<br />
# im Anschluss ein Array, in dem die Startaddressen der Strings abgelegt werden.<br />
<br />
Zum Auslesen wird zuerst die Adresse des gewünschten Elements aus dem Array im Flash-Speicher gelesen, die im Anschluss dazu genutzt wird, um auf das Element (den String) selbst zuzugreifen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
static const char str1[] PROGMEM = "Hund";<br />
static const char str2[] PROGMEM = "Katze";<br />
static const char str3[] PROGMEM = "Maus";<br />
<br />
const char * const array[] PROGMEM = <br />
{<br />
str1, str2, str3<br />
};<br />
<br />
// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]<br />
void read_string (char *buf, size_t i)<br />
{<br />
// Lese die Adresse des i-ten Strings aus array[]<br />
const char *parray = (const char*) pgm_read_ptr (&array[i]);<br />
<br />
// Kopiere den Inhalt der Zeichenkette vom Flash ins RAM<br />
strcpy_P (buf, parray);<br />
}<br />
</syntaxhighlight><br />
<br />
Eine weitere Möglichkeit ist, die Strings in einem 2-dimensionalen char-Array abzulegen anstatt deren Adresse in einem 1-dimensionalen Adress-Array zu speichern.<br />
<br />
Vorteil ist, dass der Code einfacher wird. Nachteil ist, dass bei unterschiedlich langen Strings Speicherplatz verschwendet wird, weil sich die Array-Dimension and der Länge des längsten Strings orientieret. Bei in etwa gleich langen Strings kann es aber sogar Speicherplatz sparen, denn es die Adressen der einzelnen Strings müssen nicht abgespeichert werden.<ref>In unserem Hund-Katze-Maus Beispiel belegt die erste Variante 22 Bytes Daten und 18 Bytes Code, die zweite Variante mit 2-dimensionalem Array belegt 18 Bytes Daten und 20 Bytes Code. Gemessen wurde mit avr-gcc 4.8 -Os für ATmega8.</ref><br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
// Die "6" ist 1 plus die Länge des längsten Strings ("Katze")<br />
const char array[][6] PROGMEM = <br />
{<br />
"Hund", "Katze", "Maus"<br />
};<br />
<br />
// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]<br />
void read_string (char *buf, size_t i)<br />
{<br />
// Kopiere den Inhalt der i-ten Zeichenkette vom Flash ins RAM<br />
strcpy_P (buf, array[i]);<br />
}<br />
</syntaxhighlight><br />
<br />
Siehe dazu auch die avr-libc FAQ: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_rom_array How do I put an array of strings completely in ROM?]<br />
<br />
=== Warum so kompliziert? ===<br />
<br />
Zu dem Thema, warum die Verabeitung von Werten aus dem Flash-Speicher so kompliziert ist, sei hier nur kurz erläutert: Die Harvard-Architektur des AVR weist getrennte Adressräume für Programm (Flash) und Datenspeicher (RAM) auf. Der C-Standard sieht keine unterschiedlichen Adressräume vor.<br />
<br />
Hat man zum Beispiel eine Funktion string_an_uart (const char* s) und übergibt an diese Funktion die Adresse einer Zeichenkette, dann weiß die Funktion nicht, ob die Adresse in den Flash-Speicher oder das RAM zeigt. Weder aus dem Pointer-Wert, also dem Zahlenwert, noch aus dem "const" kann auf den Ort der Ablage geschlossen werden.<br />
<br />
Einige AVR-Compiler bilden die Harvard-Architektur ab, indem sie in einen Pointer nicht nur die Adresse speichern, sondern auch den Ablageort wie ''Flash'' oder ''RAM''. In einem Aufruf einer Funktion wird dann bei Pointer-Parametern neben der Adresse auch der Speicherbereich, auf den der Pointer zeigt, übergeben.<br />
<br />
Dies hat jedoch auch Nachteile, denn bei jedem Zugriff über einen Zeiger muss zur ''Laufzeit'' entschieden werden, wie der Zugriff auszuführen ist und entsprechend länglicher und langsamer wird der erzeugte Code.<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitte Modules/Program Space String Utilities und Abschnitt Modules/Bootloader Support Utilities<br />
<br />
=== Datenzugriff >64kiB ===<br />
<br />
Die Zeiger beim avr-gcc sind nur 16 Bit breit, können somit also nur 64kiB Datenspeicher adressieren. Darauf sind auch alle Funktion der libc ausgelegt, welche auf _P enden. Als Funktionspointer können sie beim AVR bis zu 128 kiB Programmspeicher adressieren, weil Funktionsadressen immer 16-Bit Worte adressieren und nicht Bytes. Der Zugriff auf den RAM ist mit maximal 16kiB durch 16 Bit Poiinter nicht begrenzt. Um Zugriff jenseits von 64KiB zu bewerkstelligen gibt es mehrere Möglichkeiten:<br />
<br />
* Address-Spaces wie <tt>__flash1</tt> oder <tt>__memx</tt>, siehe Abschnitt "[[#Jenseits von flash|Jenseits von __flash]]".<br />
* Die Funktionen bzw. Makros <tt>pgm_read_xxx_far</tt> der AVR-Libc ab Version 1.8.0, wie im folgenden beschrieben. Dafür gibt es die Funktion pgm_get_far_address(), um 32-Bit Pointer eines Objekts zu erhalten<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/pgmspace.h><br />
<br />
//===================================================================<br />
// Define an additional section, which will be placed after all others<br />
//--------------------------------------------------------------------<br />
#define FAR_SECTION __attribute__((__section__(".far_section")))<br />
//--------------------------------------------------------------------<br />
<br />
//====================================================================<br />
// Just an example<br />
//====================================================================<br />
<br />
const char MyString[] FAR_SECTION = "Hier liegt mein FAR-Teststring!";<br />
const char MyBmp64[] FAR_SECTION = {0xAA,0xBB,0xCC,0xDD,0xEE,0xFF,0x00};<br />
<br />
int main(void) {<br />
uint32_t ptr = pgm_get_far_address(MyString);<br />
char MyChar;<br />
DDRC = 0xFF;<br />
do {<br />
MyChar = pgm_read_byte_far(ptr++);<br />
PORTC = MyChar;<br />
} while(MyChar);<br />
}<br />
</syntaxhighlight><br />
<br />
D.h. man muss<br />
* Die Definition der neuen Section <tt>FAR_SECTION</tt> einfügen<br />
* Die konstanten Daten mit dieser Section kennzeichnen<br />
<br />
Dem Linker muss man über diese Section nichts mitteilen, er fügt diese automatisch nach allen bestehenden sections im Flash ein. Der Zugriff auf diese Variablen kann nur mittels direkter Pointerarithmetik erfolgen, eine Indizierung von Arrays mit variablem Index ist nicht möglich. Dabei muss die Größe des Datentyps immer manuell berücksichtigt werden, denn der Pointer ist immer ein Bytepointer!<br />
<br />
<syntaxhighlight lang="c"><br />
int n=3;<br />
MyChar = pgm_read_byte_far(pgm_get_far_address(MyBmp64)+n*sizeof(char));<br />
</syntaxhighlight><br />
<br />
Dabei gibt es einige praktische Probleme.<br />
* Beim recht alten AVR-Studio 4.18 wird die Größe des belegten FLASH-Speichers nicht korrekt angezeigt, die Daten landen aber im HEX-File.<br />
* beim moderneren Atmelstudio 6.2 sieht man in der Consolenausgabe die richtige Größe, welche von avr-size ermittelt wurde, diese wird aber dann in der 2. Ausgabe durch Atmelstudio falsch dargestellt<br />
* Die Arduino-IDE rechnet richtig, siehe dieser [https://www.mikrocontroller.net/topic/511511?goto=6568945#6568945 Forumsbeitrag].<br />
<br />
== Flash mit __flash und Embedded-C ==<br />
<br />
Ab Version 4.7 unterstützt avr-gcc ''Adress-Spaces'' gemäß dem Embedded-C Dokument ISO/IEC TR18037. Der geläufigste Adress-Space ist <tt>__flash</tt>, der im Gegensatz zu <tt>progmem</tt> kein GCC-Attribut ist, sondern ein Qualifier und damit syntaktisch ähnlich verwendet wird wie <tt>const</tt> oder <tt>volatile</tt>.<br />
<br />
GCC kennt keine eigene Option zum Aktivieren von Embedded-C, es wird als GNU-C Erweiterung behandelt. Daher müssen C-Module, die Address-Spaces verwenden, mit <tt>-std=gnu99</tt> o.ä. compiliert werden.<br />
<br />
<syntaxhighlight lang="c"><br />
static const __flash int value = 10;<br />
<br />
int get_value (void)<br />
{<br />
return value;<br />
}<br />
</syntaxhighlight><br />
<br />
# Im Gegensatz zu <tt>progmem</tt> sind keine speziellen Bibliotheksfunktionen oder -makros für den Zugriff mehr notwendig: Der Code zum Lesen der Variable ist "normales" C.<br />
# Die Variable wird im richtigen Speicherbereich (Flash) angelegt.<br />
# <tt>__flash</tt> ist nur zusammen mit read-only Objekten oder Zeigern, d.h. nur zusammen mit <tt>const</tt>, erlaubt.<br />
# Zugriffe wie im obigen Beispiel können (weg)optimiert werden. Das Beispiel entspricht einem "<tt>return 10</tt>". Es besteht keine Notwendigkeit, für <tt>value</tt> überhaupt Flash-Speicher zu reservieren.<br />
<br />
Auch Zeiger-Indirektionen sind problemlos möglich. Zu beachten ist, dass <tt>__flash</tt> auf der richtigen Seite des "<tt>*</tt>" in der Zeigerdeklaration bzw. -definition steht:<br />
* '''Rechts vom <tt>*</tt>:''' Der Zeiger selbst liegt im Flash<br />
* '''Links vom <tt>*</tt>:''' Der Zeiger enthält eine Flash-Adresse<br />
<br />
<syntaxhighlight lang="c"><br />
// val ist eine Variable im Flash<br />
const __flash int val = 42;<br />
<br />
// pval liegt auch im Flash und enthält die Adresse von val<br />
const __flash int* const __flash pval = &val;<br />
<br />
int get_val (void)<br />
{<br />
// liest den Wert von val über die in pval abgelegte Adresse<br />
return *pval;<br />
}<br />
</syntaxhighlight><br />
<br />
=== Blöcke ===<br />
<br />
Um Speicherbereiche vom Flash in den RAM zu kopieren, gibt es zwei Möglichkeiten: Zum einen können wie bei <tt>progmem</tt> beschreiben die Funktionen der avr-libc wie <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, <tt>movmem_P</tt>, etc. verwendet werden:<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
// Eine Datenstruktur<br />
typedef struct<br />
{<br />
int id;<br />
char buf[10];<br />
} data_t;<br />
<br />
extern void uart_send (const void*, size_t);<br />
<br />
void send_data (const __flash data_t *pdata)<br />
{<br />
// buf wird auf dem Stack angelegt<br />
data_t buf;<br />
<br />
// Kopiere Daten vom Flash nach buf ins RAM<br />
memcpy_P (&buf, pdata, sizeof (data_t));<br />
<br />
// Sende die Daten in buf<br />
uart_send (&buf, sizeof (data_t));<br />
}<br />
</syntaxhighlight><br />
<br />
Zum anderen kann eine Struktur auch über direktes Kopieren ins RAM geladen werden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdlib.h><br />
<br />
// Eine Datenstruktur<br />
typedef struct<br />
{<br />
int id;<br />
char buf[10];<br />
} data_t;<br />
<br />
extern void uart_send (const void*, size_t);<br />
<br />
void send_data (const __flash data_t *pdata)<br />
{<br />
// Kopiere Daten ins RAM. buf wird auf dem Stack angelegt<br />
const data_t buf = *pdata;<br />
<br />
// Verwendet die Daten in buf<br />
uart_send (&buf, sizeof (data_t));<br />
}<br />
</syntaxhighlight><br />
<br />
=== Strings ===<br />
<br />
Natürlich können auch Strings im Flash abgelegt werden und auch mit Funktionen wie <tt>strcpy_P</tt> aus der avr-libc verarbeitet werden. Zudem ist es möglich, Flash-Zeiger mit der Adresse eines String-Literals zu initialisieren:<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
#define FSTR(X) ((const __flash char[]) { X } )<br />
<br />
const __flash char * const __flash array[] = <br />
{<br />
FSTR ("Hund"), FSTR ("Katze"), FSTR ("Maus")<br />
};<br />
<br />
size_t get_len (uint8_t tier)<br />
{<br />
return strlen_P (array[tier]);<br />
}<br />
</syntaxhighlight><br />
<br />
Leider sieht der Embedded-C Draft nicht vor, String-Literale direkt in einem anderen Adress-Space als ''generic'' anzulegen, so dass hier der Umweg über <tt>FSTR</tt> genommen werden muss. Dieses Konstrukt ist nur ausserhalb von Funktionen möglich und kann daher nicht als Ersatz für <tt>PSTR</tt> aus der avr-libc dienen.<br />
<br />
Soll <tt>array</tt> ein 2-dimensonales Array sein anstatt ein 1-dimensionales Array von Zeigern, dann geht das ohne große Verrenkungen:<br />
<br />
<syntaxhighlight lang="c"><br />
// Die 6 ergibt sich aus 1 plus der Länge des längsten Strings "Katze"<br />
const __flash char array[][6] = <br />
{<br />
"Hund", "Katze", "Maus"<br />
};<br />
</syntaxhighlight><br />
<br />
Weiters besteht die Möglichkeit, <tt>array</tt> analog anzulegen, wie man es mit <tt>PROGMEM</tt> machen würde: Jeder String wird explizit angelegt und seine Adresse bei der Initialisierung von <tt>array</tt> verwendet. Dies entspricht dem ersten Beispiel eines 1-dimensionalen Zeigerarrays:<br />
<br />
<syntaxhighlight lang="c"><br />
static const __flash char strHund[] = "Hund";<br />
static const __flash char strKatze[] = "Katze";<br />
static const __flash char strMaus[] = "Maus";<br />
<br />
const __flash char * const __flash array[] = <br />
{<br />
strHund, strKatze, strMaus<br />
};<br />
</syntaxhighlight><br />
<br />
=== Casts ===<br />
<br />
Embedded C fordert, dass zwei Adress-Spaces entweder disjunkt sind – d.h. sie enthalten keine gemeinsamen Adressen – oder aber ein Space komplett im anderen enthalten ist, also eine Teilmengen-Beziehung besteht. Die Adress-Spaces von avr-gcc sind so implementiert, dass jeder Space Teilmenge jedes anderes ist. Zwar haben Spaces wie RAM und Flash physikalisch keinen Speicherbereich gemein, allerdings ermöglicht diese Implementierung das Casten von Zeigern zu unterschiedlichen Adress-Spaces<ref>Im Gegensatz zu einem Attribute wie <tt>progmem</tt> ist ein (Adress Space) Qualifier Teil des Zeiger-Typs.</ref>: <br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdbool.h><br />
<br />
char read_char (const char *address, bool data_in_flash)<br />
{<br />
if (data_in_flash)<br />
return *(const __flash char*) address;<br />
else<br />
return *address;<br />
}<br />
</syntaxhighlight><br />
<br />
Der Cast selbst erzeugt keinen zusätzlichen Code, da eine RAM-Adresse und eine Flash-Adresse die gleiche Binärdarstellung haben. Allerdings wird über den nach <tt>__flash</tt> gecasteten Zeiger anders zugegriffen, nämlich per LPM.<br />
<br />
=== Jenseits von __flash ===<br />
<br />
Ausser <tt>__flash</tt> gibt es auch folgende Address-Spaces:<br />
<br />
==== <tt>__flash</tt>''N'' ====<br />
<br />
<tt>__flash</tt>''N'' mit ''N'' = 1..5 sind fünf weitere Spaces, die analog zu <tt>__flash</tt> funktionieren und deren Zeiger ebenfalls 16 Bit breit sind. avr-gcc erwartet, dass die zugehörigen Daten, welche in die Section <tt>.progmem</tt>''N''<tt>.data</tt> abgelegt werden, so lokatiert sind, dass das high-Byte der Adresse (Bits 16..23) gerade ''N'' ist.<br />
<br />
Weil Daten- und Code-Layout höchst projektspezifisch sind, werden diese Sections im Standard Linker-Skript nicht beschrieben. Um funktionsfähigen Code zu erhalten, muss daher ein eigenes Linker-Skript zur Verfügung gestellt werden, das diese Sections beschreibt, oder es kann eine Erweiterung des Standard Skripts bereitgestellt werden falls dies möglich ist.<br />
<br />
;Beispiel: Eine Applikation, die <tt>__flash2</tt> verwendet. Die zugehörende Section <tt>.progmem2.data</tt> wird hinter <tt>.text</tt> angeordnet aber vor den Initializern für <tt>.data</tt>. Dazu wird beim Linken das ld-Skript Fragment per <tt>-Tflash12.ld</tt> angegeben, welches dann an der gewünschten Stelle in das default Skript eingefügt wird:<br />
:{| <!-- Tabelle bitte für korrekte Einrückung belassen --><br />
|-<br />
|<pre><br />
SECTIONS<br />
{<br />
.flash2 :<br />
{<br />
. = MAX (ABSOLUTE(0x20000), .);<br />
PROVIDE (__flash2_start = .);<br />
. = ALIGN(2);<br />
*(.flash2.text*)<br />
*(.progmem2.data*)<br />
PROVIDE (__flash2_end = .);<br />
<br />
ASSERT (__flash2_start == __flash2_end || __flash2_start >= ABSOLUTE(0x20000),<br />
"__flash2 data in .progmem2.data below 0x20000");<br />
ASSERT (__flash2_start == __flash2_end || __flash2_end <= ABSOLUTE(0x30000),<br />
"__flash2 data in .progmem2.data exceeds 0x30000");<br />
}<br />
}<br />
INSERT AFTER .text<br />
</pre><br />
|}<br />
<br />
==== <tt>__memx</tt> ====<br />
<br />
Dieser Address-Space implementiert 3-Byte Zeiger und unterstützt Lesen über 64KiB-Segmentgrenzen hinweg. Das MSB (Bit 23) gibt dabei an, ob der <tt>__memx</tt>-Zeiger eine Flash-Adresse enthält (Bit23 = 0) oder eine RAM-Adresse (Bit23 = 1), was folgenden Code erlaubt:<br />
<br />
<syntaxhighlight lang="c"><br />
const __memx int a_flash = 42;<br />
const int a_ram = 100;<br />
<br />
int get_a (const __memx int* pa)<br />
{<br />
return *pa;<br />
}<br />
<br />
int main (void)<br />
{<br />
return get_a (&a_flash) + get_a (&a_ram);<br />
}</syntaxhighlight><br />
<br />
Dies bedeutet, dass erst zur ''Laufzeit'' entschieden werden kann, ob <tt>get_a</tt> die Daten aus dem RAM oder aus dem Flash lesen soll, was <tt>__memx</tt> im Vergleich zu den anderen Address-Spaces langsamer macht. Ausserdem ist zu beachten, dass <tt>__memx</tt>-Zeiger zwar 24-Bit Zeiger sind, die zugrundeliegende Adress-Arithmetik jedoch gemäß dem C-Standard erfolgt, also als 16-Bit Arithmetik. Bestehende Funktion der avr-libc wie z.B. printf_P funktionieren damit ebensowenig wie printf! Wenn man <tt>__memx</tt> verwenden will, braucht man dafür eigene Funktionen.<br />
<br />
=== __flash, progmem und Portierbarkeit ===<br />
<br />
Da ab er aktuellen Compilerversion 4.7 sowohl <tt>__flash</tt> als auch <tt>PROGMEM</tt> und die <tt>pgm_read</tt>-Funktionen zur Verfügung stehen, ergibt sich die Frage, welche Variante "besser" ist und wie zwischen ihnen hin- und her zu portieren ist.<br />
<br />
Zunächst sei erwähnt, dass <tt>__flash</tt> kein Ersatz für <tt>PROGMEM</tt> ist, sondern lediglich eine Alternative dazu. Das "alte" progmem wird weiterhin mir gleicher Semantik unterstützt, so dass alter Code ohne Änderungen mit den neueren Compilerversionen übersetzbar bleibt.<br />
<br />
Von der Codegüte her dürften sich keine großen Unterschiede ergeben. Es ist nicht zu erwarten, dass die eine oder die andere Variante wesentlich besseren oder schlechteren Code erzeugt — von einer Ausnahme abgesehen: Der Wert beim Zugriff ist zur Compilezeit bekannt und kann daher eliminiert werden.<br />
<syntaxhighlight lang="c"><br />
static const __flash char x[] = { 'A', 'V', 'R' };<br />
<br />
char foo (void)<br />
{<br />
return x[2];<br />
}<br />
</syntaxhighlight><br />
Dies wird übersetzt wie "<tt>return 'R';</tt>", und das Array <tt>x[]</tt> kann komplett wegoptimiert werden und entfallen.<br />
<br />
==== progmem → __flash ====<br />
<br />
Portierung in diese Richtung bedeutet, alten Code anzupassen. Zwingend ist die Portierung nicht, da <tt>progmem</tt> weiterhin unterstützt wird.<br />
Allerdings ist eine Quelle mit <tt>__flash</tt> besser lesbar, denn der Code wird von den <tt>pgm_read</tt>-Funktionen befreit, die vor allem bei Mehrfach-Indirektion den Code ziemlich verunstalten und unleserlich machen können.<br />
Weiterer Vorteil von <tt>_flash</tt> ist, daß eine striktere Typprüfung erfolgen kann.<br />
<br />
Eine Portierung wird man in zwei Schritten vornehmen:<br />
<br />
;1. Definitionen von Flash-Variablen werden angepasst:<br />
<br />
Vorher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
static const char hund[] PROGMEM = "Hund";<br />
static const char katze[] PROGMEM = "Katze";<br />
static const char maus[] PROGMEM = "Maus";<br />
<br />
const char * const tier[] PROGMEM = <br />
{<br />
hund, katze, maus<br />
};<br />
</syntaxhighlight><br />
|}<br />
<br />
Nachher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
static const __flash char hund[] = "Hund";<br />
static const __flash char katze[] = "Katze";<br />
static const __flash char maus[] = "Maus";<br />
<br />
const __flash char * const __flash tier[] = <br />
{<br />
hund, katze, maus<br />
};<br />
</syntaxhighlight><br />
|}<br />
<br />
Der Header <tt>avr/pgmspace.h</tt> wird nicht mehr benötigt. Im Gegensatz zu <tt>progmem</tt> müssen Qualifier immer links von der definierten Variablen stehen; bei Attributen wie <tt>progmem</tt> ist das mehr oder weniger egal.<br />
<br />
Nachdem diese Anpassung erfolgreich abgeschlossen ist, folgt Schritt<br />
<br />
; 2. Der Code wird von <tt>pgm_read</tt>-Aufrufen bereinigt:<br />
<br />
Vorher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
extern const char *tier[];<br />
<br />
char first_letter (uint8_t i)<br />
{<br />
const char* ptier = (const char*) pgm_read_word (&tier[i]);<br />
return (char) pgm_read_byte (&ptier[0]);<br />
}<br />
</syntaxhighlight><br />
|}<br />
<br />
Nachher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <stdint.h><br />
<br />
extern const __flash char * const __flash tier[];<br />
<br />
char first_letter (uint8_t i)<br />
{<br />
return tier[i][0];<br />
}<br />
</syntaxhighlight><br />
|}<br />
<br />
== Dateien direkt im Flash einbinden ==<br />
<br />
Wenn man größere Dateien direkt im Programm einbinden will, ohne sie vorher in C Quelltext umzuwandeln, muss man das mit dem Linker machen. Wie das geht steht hier.<br />
<br />
* [http://www.atmel.com/webdoc/avrlibcreferencemanual/FAQ_1faq_binarydata.html Atmel, avr gcc Dokumentation]<br />
* [http://nongnu.org/avr-libc/user-manual/FAQ.html#faq_binarydata Nongnu avr gcc Dokumentation]<br />
<br />
Wie man das dann praktisch umsetzt, sieht man in diesem Beitrag.<br />
<br />
* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056910 Forumsbeitrag]: Binärdateien mittels Linker einbinden<br />
* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056947 Forumsbeitrag]: Ein kleines Tool zum Umwandeln von Binärdateien in C-Quelltext.<br />
<br />
== Flash in der Anwendung schreiben ==<br />
<br />
Bei AVRs mit "self-programming"-Option – auch bekannt als [[Bootloader]]-Support – können Teile des Flash-Speichers vom Anwendungsprogramm beschrieben werden. Dies ist nur möglich, wenn die Schreibfunktion in einem besonderen Speicherbereich, der Boot-Section des Programmspeichers/Flash, abgelegt ist.<br />
<br />
Bei einigen kleinen AVRs gibt es keine gesonderte Boot-Section, bei diesen kann der Flashspeicher von jeder Stelle des Programms geschrieben werden. Für Details sei hier auf das jeweilige Controller-Datenblatt und die Erläuterungen zum Modul boot.h der avr-libc verwiesen. Es existieren auch Application-Notes dazu bei atmel.com, die auf avr-gcc-Code übertragbar sind.<br />
<br />
Siehe auch: <br />
* Forumsbeitrag [http://www.mikrocontroller.net/topic/163632#1561622 Daten in Programmspeicher speichern]<br />
<br />
== EEPROM ==<br />
<br />
Möchte man Werte aus einem Programm heraus so speichern, dass sie auch nach dem Abschalten der Versorgungsspannung noch erhalten bleiben und nach dem Wiederherstellen der Versorgungsspannung bei erneutem Programmstart wieder zur Verfügung stehen, dann benutzt man das EEPROM.<br />
<br />
Schreib- und Lesezugriffe auf den EEPROM-Speicher erfolgen über die im Modul eeprom.h der avr-libc definierten Funktionen. Mit diesen Funktionen können einzelne Bytes, Datenworte (16 Bit), Fließkommawerte (32 Bit, single-precision, float) und Datenblöcke geschrieben und gelesen werden.<br />
<br />
Diese Funktionen kümmern sich auch um diverse Details, die bei der Benutzung des EEPROMs normalerweise notwendig sind:<br />
* EEPROM-Operationen sind im Vergleich relativ langsam. Man muss daher darauf achten, dass eine vorhergehende Operation abgeschlossen ist, ehe die nächste Operation mit dem EEPROM gestartet wird. Die in der avr-libc implementierten Funktionen aus eeprom.h berücksichtigten dies. Soll beim Aufruf einer EEPROM-Funktion sichergestellt werden, dass diese nicht intern in einer Warteschleife auf den Abschluss der vorherigen Operation wartet, kann vorher per eeprom_is_ready testen, ob der Zugriff auf den EEPROM-Speicher sofort möglich ist.<br />
* Es ist darauf zu achten, dass die EEPROM-Funktionen nicht durch einen Interrupt unterbrochen werden. Einige Phasen des Zugriffs sind zeitkritisch und müssen in einer definierten bzw. begrenzten Anzahl von Takten durchgeführt werden. Durch einen unterbrechenden Interrupt würde diese Restriktion nicht mehr eingehalten. Auch dieses Detail wird von den avr-libc Funktionen berücksichtigt, so dass man sich als C-Programmierer nicht darum kümmern muss. Innerhalb der Funktionen werden Interrupts vor der "EEPROM-Sequenz" global deaktiviert und im Anschluss, falls vorher auch schon eingeschaltet, wieder aktiviert.<br />
<br />
Man beachte, dass der EEPROM-Speicher nur eine begrenzte Anzahl von Schreibzugriffen zulässt. Beschreibt man eine EEPROM-Zelle öfter als die im Datenblatt zugesicherte Anzahl (typisch 100.000), wird die Funktion der Zelle nicht mehr garantiert. Dies gilt für jede einzelne Zelle. <br />
<br />
Bei geschickter Programmierung (z.&nbsp;B. Ring-Puffer), bei der die zu beschreibenden Zellen regelmäßig gewechselt werden, kann man eine deutlich höhere Anzahl an Schreibzugriffen, bezogen auf den gesamten EEPROM-Speicher, erreichen. Auf jeden Fall sollte man aber eine Abschätzung über die zu erwartende Lebensdauer des EEPROM durchführen. Wird ein Wert im EEPROM im Durchschnitt nur einmal pro Woche verändert, wird die garantierte Anzahl der Schreibzyklen innerhalb der voraussichtlichen Verwendungszeit des Controllers sicherlich nicht erreicht werden. Welcher Controller ist schon 100000 / 52 = 1923 Jahre im Einsatz? In diesem Fall lohnt es sich daher nicht, erweiterte Programmfunktionen zu implementieren, mit denen die Anzahl der Schreibzugriffe minimiert wird.<br />
<br />
Eine weitere Möglichkeit, Schreibzyklen einzusparen, besteht in der Vorabprüfung, ob der zu speichernde Wert im EEPROM bereits enthalten ist und nur veränderte Werte zu schreiben. In aktuelleren Versionen der avr-libc sind bereits Funktionen enthalten, die solche Prüfungen enthalten (eeprom_update_*).<br />
<br />
Eine dritte Möglichkeit speichert alle Daten zunächst im RAM, wo sie beliebig oft beschrieben werden können. Nur beim Ausschalten oder beim Ausfall der Stromversorgung werden die Daten in den EEPROM geschrieben. Wie man das richtig macht sieht man im Artikel [[Speicher#EEPROM Schreibzugriffe minimieren | Speicher]].<br />
<br />
Lesezugriffe können beliebig oft durchgeführt werden. Sie unterliegen keinen Einschränkungen in Bezug auf deren Anzahl. <br />
<br />
=== EEMEM ===<br />
Um eine Variable im EEPROM anzulegen, stellt die avr-libc das Makro EEMEM zur Verfügung:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdint.h><br />
#include <avr/eeprom.h><br />
<br />
/* Byte */<br />
uint8_t eeFooByte EEMEM = 123;<br />
<br />
/* Wort */<br />
uint16_t eeFooWord EEMEM = 12345;<br />
<br />
/* float */<br />
float eeFooFloat EEMEM;<br />
<br />
/* Byte-Array */<br />
uint8_t eeFooByteArray1[] EEMEM = { 18, 3, 70 };<br />
uint8_t eeFooByteArray2[] EEMEM = { 30, 7, 79 };<br />
<br />
/* 16-bit unsigned short feld */<br />
uint16_t eeFooWordArray1[4] EEMEM;<br />
</syntaxhighlight><br />
<br />
Die grundsätzliche Vorgehensweise ist identisch zur Verwendung von PROGMEM. Auch hier erzeugt man sich spezielle attributierte Variablen (EEMEM erledigt das), die vom Compiler/Linker nicht wie normale Variablen behandelt werden. Compiler/Linker kümmern sich zwar darum, dass diesen Variablen eine Adresse zugewiesen wird, diese Adresse ist dann aber die Adresse der 'Variablen' im EEPROM. Um die dort gespeicherten Werte zu lesen bzw. zu schreiben, übergibt man diese Adresse an spezielle Funktionen, die die entsprechenden Werte aus dem EEPROM holen bzw. das EEPROM neu beschreiben.<br />
<br />
Die mittels EEMEM erzeugten 'Variablen' sind also mehr als Platzhalter zu verstehen, denn als echte Variablen. Es geht nur darum, im C-Programm symbolische Namen zur Verfügung zu haben, anstatt mit echten EEPROM-Adressen hantieren zu müssen, etwas, das grundsätzlich aber auch genauso gut möglich ist. Nur muss man sich in diesem Fall dann selbst darum kümmern, dass mehrere 'Variablen' ohne Überschneidung im EEPROM angeordnet werden.<br />
<br />
=== Bytes lesen/schreiben ===<br />
<br />
Die avr-libc Funktion zum Lesen eines Bytes heißt eeprom_read_byte. Parameter ist die Adresse des Bytes im EEPROM. Geschrieben wird über die Funktion eeprom_write_byte mit den Parametern Adresse und Inhalt. Anwendungsbeispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#define EEPROM_DEF 0xFF<br />
<br />
void eeprom_example (void)<br />
{<br />
uint8_t myByte;<br />
<br />
// myByte lesen (Wert = 123)<br />
myByte = eeprom_read_byte (&eeFooByte);<br />
<br />
// der Wert 99 wird im EEPROM an die Adresse der<br />
// Variablen eeFooByte geschrieben<br />
myByte = 99;<br />
eeprom_write_byte(&eeFooByte, myByte); // schreiben<br />
<br />
myByte = eeprom_read_byte (&eeFooByteArray1[1]); <br />
// myByte hat nun den Wert 3<br />
<br />
// Beispiel fuer eeprom_update_byte: die EEPROM-Zelle wird nur<br />
// dann beschrieben, wenn deren Inhalt sich vom Parameterwert<br />
// unterscheidet. In diesem Beispiel erfolgt also kein Schreib-<br />
// zugriff, da die Werte gleich sind.<br />
eeprom_update_byte(&eeFooByte, myByte);<br />
<br />
<br />
// Beispiel zur "Sicherung" gegen leeres EEPROM nach "Chip Erase"<br />
// (z. B. wenn die .eep-Datei nach Programmierung einer neuen Version<br />
// des Programms nicht in den EEPROM uebertragen wurde und EESAVE<br />
// deaktiviert ist (unprogrammed/1)<br />
// <br />
// Vorsicht: wenn EESAVE "programmed" ist, hilft diese Sicherung nicht<br />
// weiter, da die Speicheraddressen in einem neuen/erweiterten Programm<br />
// moeglicherweise verschoben wurden. An der Stelle &eeFooByte steht<br />
// dann u.U. der Wert einer anderen Variable aus einer "alten" Version.<br />
<br />
uint8_t fooByteDefault = 222;<br />
if ((myByte = eeprom_read_byte (&eeFooByte)) == EEPROM_DEF)<br />
{<br />
myByte = fooByteDefault;<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
=== Wort lesen/schreiben ===<br />
<br />
Schreiben und Lesen von Datenworten erfolgt analog zur Vorgehensweise bei Bytes:<br />
<br />
<syntaxhighlight lang="c"><br />
// lesen<br />
uint16_t myWord = eeprom_read_word (&eeFooWord);<br />
<br />
// schreiben<br />
eeprom_write_word (&eeFooWord, 2222);<br />
</syntaxhighlight><br />
<br />
=== Block lesen/schreiben ===<br />
<br />
Lesen und Schreiben von Datenblöcken erfolgt über die Funktionen <code>eeprom_read_block()</code> bzw. <code>eeprom_write_block()</code>. Die Funktionen erwarten drei Parameter: die Adresse der Quell- bzw. Zieldaten im RAM, die EEPROM-Adresse und die Länge des Datenblocks in Bytes als <code>size_t</code>.<br />
<syntaxhighlight lang="c"><br />
uint8_t myByteBuffer[3];<br />
uint16_t myWordBuffer[4];<br />
<br />
void eeprom_block_example (void)<br />
{<br />
/* Datenblock aus EEPROM lesen */<br />
<br />
/* liest 3 Bytes ab der von eeFooByteArray1 definierten EEPROM-Adresse<br />
in das RAM-Array myByteBuffer */<br />
eeprom_read_block (myByteBuffer, eeFooByteArray1, 3);<br />
<br />
/* dito mit etwas Absicherung betr. der Länge */<br />
eeprom_read_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));<br />
<br />
/* und nun mit 16-Bit Array */<br />
eeprom_read_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));<br />
<br />
/* Datenblock in EEPROM schreiben */<br />
eeprom_write_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));<br />
eeprom_write_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));<br />
}<br />
</syntaxhighlight><br />
<br />
=== Fließkommawerte lesen/schreiben ===<br />
<br />
In der avr-libc stehen auch EEPROM-Funktionen für Variablen des Typs float (Fließkommazahlen mit "einfacher" Genauigkeit) zur Verfügung.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/eeprom.h><br />
<br />
float eeFloat EEMEM = 12.34f;<br />
<br />
float void eeprom_float_example(float value)<br />
{<br />
/* float in EEPROM schreiben */<br />
eeprom_write_float(&eeFloat, value);<br />
<br />
/* float aus EEPROM lesen */<br />
return eeprom_read_float(&eeFloat);<br />
}</syntaxhighlight><br />
<br />
=== EEPROM-Speicherabbild in .eep-Datei ===<br />
<br />
Mit den zum Compiler gehörenden Werkzeugen kann der aus den Variablendeklarationen abgeleitete EEPROM-Inhalt in eine Datei geschrieben werden. Die übliche Dateiendung ist .eep, Daten im Intel Hex-Format. Damit können Standardwerte für den EEPROM-Inhalt im Quellcode definiert werden. <br />
<br />
Makefiles nach WinAVR/MFile-Vorlage enthalten bereits die notwendigen Einstellungen, siehe dazu die Erläuterungen im [[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]].<br />
<br />
Der Inhalt der eep-Datei muss ebenfalls zum Mikrocontroller übertragen werden, wenn die Initialisierungswerte aus der Deklaration vom Programm erwartet werden. Ansonsten enthält der EEPROM-Speicher nach der Übertragung des Programmers mittels ISP abhängig von der Einstellung der EESAVE-Fuse<ref>vgl. Datenblatt Abschnitt Fuse Bits</ref> nicht die korrekten Werte:<br />
; EESAVE = 0 (programmed): Die Daten im EEPROM bleiben erhalten. Werden sie nicht neu geschrieben, so enthält das EEPROM evtl. Daten, die nicht mehr zum Programm passen.<br />
; EESAVE = 1 (unprogrammed): Beim Programmieren werden die Daten im EEPROM gelöscht, also auf 0xff gesetzt.<br />
<br />
Als Sicherung kann man im Programm nochmals die Standardwerte vorhalten, beim Lesen auf 0xFF prüfen und gegebenenfalls einen Standardwert nutzen. Das geht natürlich nur, wenn 0xFF selbst nicht als Datenwert vorkommen kann.<br />
<syntaxhighlight lang="c"><br />
#define DUTY_CYCLE_DEFAULT 0x80<br />
<br />
uint8_t eeDutyCycle EEMEM; // Platzhalter für EEPROM<br />
uint8_t DutyCycle; // die echte Variable<br />
<br />
<br />
int main(void)<br />
{<br />
DutyCycle = eeprom_read_byte( &eeDutyCycle );<br />
if( DutyCycle == 0xFF ) // das allererste mal. Im EEPROM steht noch kein gültiger Wert<br />
{<br />
DutyCycle = DUTY_CYCLE_DEFAULT;<br />
eeprom_writeByte( &eeDutyCycle, DutyCycle );<br />
}<br />
<br />
...<br />
</syntaxhighlight><br />
<br />
=== Direkter Zugriff auf EEPROM-Adressen ===<br />
<br />
Will man direkt auf bestimmte EEPROM Adressen zugreifen, dann sind folgende IAR-kompatiblen Makros <tt>_EEGET</tt> und <tt>_EEPUT</tt> hilfreich, um sich die Typecasts zu ersparen.<br />
<br />
;Hinweis: Die nachfolgend gezeigten Makros und Zugriffe auf absolute Adressen sind in Normalfall nicht nötig und nur auf sehr wenige, spezielle Fälle beschränkt! Im Normalfall sollte man auf absolute Adressen möglichst nicht zugreifen und den Compiler seine Arbeit machen lassen, der verwaltet die Variablen und deren Adressen meist besser als der Programmierer. Der Zugriff auf Variablen im EEPROM sollte immer über ihren Namen erfolgen.<br />
<br />
Verwendung:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/eeprom.h><br />
<br />
_EEPUT (0x20, 128); // Byte-Wert 128 an Adresse 0x20 schreiben<br />
...<br />
uint8_t val = _EEGET (0x20); // EEPROM-Wert von Adresse 0x20 lesen<br />
</syntaxhighlight><br />
<br />
=== Was steckt dahinter? - EEPROM-Register ===<br />
Auch wenn es normalerweise keinen Grund gibt, in C selbst an den Steuerregistern herumzuschrauben - die eeprom Funktionen erledigen das alles zuverlässig - der Vollständigkeit halber der registermässige technische Unterbau.<br />
Um das EEPROM anzusteuern, sind drei Register von Bedeutung:<br />
;EEAR: Hier werden die Adressen eingetragen zum Schreiben oder Lesen. Dieses Register unterteilt sich nochmal in EEARH und EEARL, da in einem 8-Bit-Register keine 512 Adressen adressiert werden können.<br />
;EEDR: Hier werden die Daten eingetragen, die geschrieben werden sollen, bzw. es enthält die gelesenen Daten.<br />
;EECR: Ist das Kontrollregister für das EEPROM<br />
<br />
Das EECR steuert den Zugriff auf das EEPROM und ist wie folgt aufgebaut:<br />
<br />
:{| class="wikitable" style="text-align:center"<br />
|+ '''Aufbau des EECR-Registers'''<br />
|-<br />
!Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|-<br />
! Name<br />
| - || - || - ||- || EERIE || EEMWE || EEWE || EERE<br />
|-<br />
! Read/Write<br />
| R || R || R || R || R/W || R/W || R/W || R/W<br />
|-<br />
!Init Value<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''Bedeutung der Bits'''<br />
<br />
;Bit 4-7: nicht belegt<br />
<br />
;Bit 3 (EERIE): ''EEPROM Ready Interrupt Enable'': Wenn das Bit gesetzt ist und globale Interrupts erlaubt sind in Register SREG (Bit 7), wird ein Interrupt ausgelöst nach Beendigung des Schreibzyklus (EEPROM Ready Interrupt). Ist einer der beiden Bits 0, wird kein Interrupt ausgelöst.<br />
<br />
;Bit 2 EEMWE): ''EEPROM Master Write Enable'': Dieses Bit bestimmt, dass, wenn EEWE = 1 gesetzt wird (innerhalb von 4 Taktzyklen), das EEPROM beschrieben wird mit den Daten in EEDR bei Adresse EEAR. Wenn EEMWE = 0 ist und EEWE = 1 gesetzt wird, hat das keine Auswirkungen. Der Schreibvorgang wird dann nicht ausgelöst. Nach 4 Taktzyklen wird das Bit EEMWE automatisch wieder auf 0 gesetzt. Dieses Bit löst den Schreibvorgang nicht aus, es dient sozusagen als Sicherungsbit für EEWE.<br />
<br />
;Bit 1 (EEWE): ''EEPROM Write Enable'': Dieses Bit löst den Schreibvorgang aus, wenn es auf 1 gesetzt wird, sofern vorher EEMWE gesetzt wurde und seitdem nicht mehr als 4 Taktzyklen vergangen sind. Wenn der Schreibvorgang abgeschlossen ist, wird dieses Bit automatisch wieder auf 0 gesetzt und, sofern EERIE gesetzt ist, ein Interrupt ausgelöst. Ein Schreibvorgang sieht typischerweise wie folgt aus:<br />
:# EEPROM-Bereitschaft abwarten (EEWE=0) <br />
:# Adresse übergeben an EEAR<br />
:# Daten übergeben an EEDR<br />
:# Schreibvorgang auslösen in EECR mit Bit EEMWE=1 und EEWE=1<br />
:# (Optional) Warten, bis Schreibvorgang abgeschlossen ist<br />
<br />
;Bit 0 EERE: ''EEPROM Read Enable'': Wird dieses Bit auf 1 gesetzt wird das EEPROM an der Adresse in EEAR ausgelesen und die Daten in EEDR gespeichert. Das EEPROM kann nicht ausgelesen werden, wenn bereits eine Schreiboperation gestartet wurde. Es ist daher zu empfehlen, die Bereitschaft vorher zu prüfen. Das EEPROM ist lesebereit, wenn das Bit EEWE=0 ist. Ist der Lesevorgang abgeschlossen, wird das Bit wieder auf 0 gesetzt, und das EEPROM ist für neue Lese- und Schreibbefehle wieder bereit. Ein typischer Lesevorgang kann wie folgt aufgebaut sein:<br />
:# Bereitschaft zum Lesen prüfen (EEWE=0)<br />
:# Adresse übergeben an EEAR<br />
:# Lesezyklus auslösen mit EERE = 1<br />
:# Warten, bis Lesevorgang abgeschlossen EERE = 0<br />
:# Daten abholen aus EEDR<br />
<br />
= Die Nutzung von sprintf und printf =<br />
<br />
Um komfortabel, d.h. formatiert, Ausgaben auf ein Display oder die serielle Schnittstelle zu tätigen, bieten sich '''sprintf''' oder '''printf''' an. Alle *printf-Varianten sind jedoch ziemlich speicherintensiv und der Einsatz in einem Mikrocontroller mit knappem Speicher muss sorgsam abgewogen werden.<br />
<br />
Bei '''sprintf''' wird die Ausgabe zunächst in einem Puffer vorbereitet und anschließend mit einfachen Funktionen zeichenweise ausgegeben. Es liegt in der Verantwortung des Programmierers, genügend Platz im Puffer für die erwarteten Zeichen bereitzuhalten.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdio.h><br />
#include <stdint.h><br />
<br />
// ...<br />
// nicht dargestellt: Implementierung von uart_puts (vgl. Abschnitt UART)<br />
// ...<br />
<br />
uint16_t counter;<br />
<br />
// Ausgabe eines unsigned Integerwertes<br />
void uart_puti( uint16_t value )<br />
{<br />
uint8_t puffer[20];<br />
<br />
sprintf( puffer, "Zählerstand: %u", value );<br />
uart_puts( puffer );<br />
}<br />
<br />
int main()<br />
{<br />
counter = 5;<br />
<br />
uart_puti( counter );<br />
uart_puti( 42 );<br />
}<br />
</syntaxhighlight><br />
<br />
Eine weitere elegante Möglichkeit besteht darin, den STREAM stdout (Standardausgabe) auf eine eigene Ausgabefunktion umzuleiten. Dazu wird dem Ausgabemechanismus der C-Bibliothek eine neue Ausgabefunktion bekannt gemacht, deren Aufgabe es ist, ein einzelnes Zeichen auszugeben. Wohin die Ausgabe dann tatsächlich stattfindet, ist Sache der Ausgabefunktion. Im Beispiel unten wird auf UART ausgegeben. Alle anderen, höheren Funktionen wie z.&nbsp;B. '''printf''', greifen letztendlich auf diese primitive Ausgabefunktion zurück. <br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdio.h><br />
<br />
void uart_init(void);<br />
<br />
// a. Deklaration der primitiven Ausgabefunktion<br />
int uart_putchar(char c, FILE *stream);<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 1)<br />
static FILE mystdout = FDEV_SETUP_STREAM( uart_putchar, NULL, _FDEV_SETUP_WRITE );<br />
<br />
// c. Definition der Ausgabefunktion<br />
int uart_putchar( char c, FILE *stream )<br />
{<br />
if( c == '\n' )<br />
uart_putchar( '\r', stream );<br />
<br />
loop_until_bit_is_set( UCSRA, UDRE );<br />
UDR = c;<br />
return 0;<br />
}<br />
<br />
void uart_init(void)<br />
{<br />
/* hier µC spezifischen Code zur Initialisierung */<br />
/* des UART einfügen... s.o. im AVR-GCC-Tutorial */<br />
<br />
// Beispiel: <br />
//<br />
// myAVR Board 1.5 mit externem Quarz Q1 3,6864 MHz<br />
// 9600 Baud 8N1<br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
// Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt)<br />
#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)<br />
<br />
UCSRB |= (1<<TXEN) | (1<<RXEN); // UART TX und RX einschalten<br />
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1 <br />
<br />
UBRRH = (uint8_t)( UART_UBRR_CALC( UART_BAUD_RATE, F_CPU ) >> 8 );<br />
UBRRL = (uint8_t)UART_UBRR_CALC( UART_BAUD_RATE, F_CPU );<br />
}<br />
<br />
int main(void)<br />
{<br />
int16_t antwort = 42;<br />
uart_init();<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 2)<br />
stdout = &mystdout;<br />
<br />
// Anwendung<br />
printf( "Die Antwort ist %d.\n", antwort );<br />
return 0;<br />
}<br />
<br />
// Quelle: avr-libc-user-manual-1.4.3.pdf, S.74<br />
// + Ergänzungen<br />
</syntaxhighlight><br />
<br />
<br />
Sollen Fließkommazahlen ausgegeben werden, muss im Makefile eine andere (größere) Version der [[FAQ#Aktivieren_der_Floating_Point_Version_von_sprintf_beim_WinAVR_mit_AVR-Studio|printflib]] eingebunden werden.<br />
<br />
= Anmerkungen =<br />
<references/><br />
<br />
= TODO =<br />
* Aktualisierung Register- und Bitbeschreibungen an aktuelle AVR<br />
* "naked"-Funktionen [http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html][http://arduino.stackexchange.com/questions/8758/arduino-interruption-on-pin-change]<br />
<br />
[[Kategorie:avr-gcc Tutorial| ]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR-GCC-Tutorial&diff=107256AVR-GCC-Tutorial2025-01-27T14:24:41Z<p>Heha: /* Was macht das Hauptprogramm? */</p>
<hr />
<div>Dieses Tutorial soll den Einstieg in die Programmierung von Atmel [[AVR]]-Mikrocontrollern in der Programmiersprache [[C]] mit dem freien C-Compiler [[avr-gcc]] aus der [http://gcc.gnu.org/ GNU Compiler Collection] (GCC) erleichtern.<br />
<br />
Vorausgesetzt werden Grundkenntnisse der Programmiersprache C. Diese Kenntnisse kann man sich online erarbeiten, z. B. mit dem [http://www.schellong.de/c.htm C Tutorial von Helmut Schellong] ([[C|Liste von C-Tutorials]]). Nicht erforderlich sind Vorkenntnisse in der Programmierung von Mikrocontrollern.<br />
<br />
= Vorwort =<br />
<br />
In diesem Text wird häufig auf die Standardbibliothek avr-libc verwiesen, für die es eine [http://www.nongnu.org/avr-libc/user-manual/index.html Online-Dokumentation] gibt, in der sich auch viele nützliche Informationen zum Compiler und zur Programmierung von AVR-Controllern finden. Beim Paket [[WinAVR]] gehört die avr-libc Dokumentation zum Lieferumfang und wird mitinstalliert.<br />
<br />
Der Compiler und die Standardbibliothek avr-libc werden ständig weiterentwickelt. Einige Unterschiede, die sich im Verlauf der Entwicklung ergeben haben, werden hier und im Artikel [[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen]] zwar angesprochen, Anfängern und Umsteigern sei jedoch empfohlen, eine aktuelle Versionen zu nutzen.<br />
<br />
Das ursprüngliche Tutorial stammt von Christian Schifferle, viele neue Abschnitte und aktuelle Anpassungen von Martin Thomas.<br />
<br />
Dieses Tutorial ist in [[Media:AVR-GCC-Tutorial.pdf|PDF-Form]] erhältlich (zur Zeit nur eine sehr veraltete Version).<br />
<br />
== Weiterführende Kapitel ==<br />
<br />
Um dieses riesige Tutorial etwas überschaubarer zu gestalten, wurden einige Kapitel ausgelagert, die nicht unmittelbar mit den Grundlagen von avr-gcc in Verbindung stehen. All diese Seiten gehören zur [[:Kategorie:avr-gcc Tutorial]].<br />
<br />
;UART: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der UART|Der UART]]''<br />
<br />
;ADC: → Hauptartikel: ''[[AVR-GCC-Tutorial/Analoge Ein- und Ausgabe|Analoge Ein- und Ausgabe (ADC)]]''<br />
<br />
;Timer: → Hauptartikel: ''[[AVR-GCC-Tutorial/Die Timer und Zähler des AVR|Die Timer und Zähler des AVR]]''<br />
<br />
;LCD: → Hauptartikel: ''[[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Ansteuerung]]''<br />
<br />
;Watchdog: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der Watchdog|Der Watchdog]]''<br />
<br />
;Assembler: → Hauptartikel: ''[[AVR-GCC-Tutorial/Assembler und Inline-Assembler|Assembler und Inline-Assembler]]''<br />
<br />
;alte Quellen anpassen: → Hauptartikel: ''[[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen anpassen]]''<br />
<br />
;Makefiles: → Hauptartikel: ''[[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]]'' sowie als Alternative für sehr kleine Projekte → Hauptartikel: ''[[C ohne Makefile]]''<br />
<br />
= Benötigte Werkzeuge =<br />
<br />
Um eigene Programme für AVRs mittels einer AVR-Toolchain zu erstellen wird folgende Hard- und Software benötigt:<br />
<br />
* Eine AVR-Toolchain bestehend aus avr-gcc, den avr-Binutils (Assembler, Linker, etc) und einer Standard-C Bibliothek. Üblich ist die AVR-LibC, die auch quasi in allen avr-gcc Distributionen enthalten ist.<br />
<br />
Hardware wird keine benötigt – bis auf einen PC natürlich, auf dem der Compiler ablaufen kann. Selbst ohne AVR-Hardware kann man also bereits C-Programme für AVRs schreiben, compiliern und sich das Look-and-Feel von avr-gcc sowie von IDEs wie [[Atmel Studio]], Eclipse oder leichtgewichtigeren Entwicklungsumbgebungen anschauen. Selbst das Debuggen und Simulieren ist mithilfe entsprechender Tools wie Debugger und Simulator in gewissen Grenzen möglich.<br />
<br />
Um Programme für AVRs mittels einer AVR-Toolchain zu testen, wird folgende Hard- und Software benötigt:<br />
<br />
* Platine oder Versuchsaufbau für die Aufnahme eines AVR-Controllers, der vom avr-gcc Compiler unterstützt wird.<ref>Für eine Liste der unterstützten COntroller siehe die Dokumentation des Compilers oder [http://www.nongnu.org/avr-libc/user-manual/index.html#supported_devices AVR-Libc: Supported Devices].</ref> Dieses Testboard kann durchaus auch selbst gelötet oder auf einem Steckbrett aufgebaut werden. Einige Registerbeschreibungen dieses Tutorials beziehen sich auf den inzwischen veralteten AT90S2313. Der weitaus größte Teil des Textes ist aber für alle Controller der AVR-Familie gültig. <br />
<br />
:Brauchbare Testplattformen sind auch das [[STK500]] und der [[AVR Butterfly]] von Atmel. Weitere Infos findet man in den Artikeln [[AVR#Starterkits|AVR Starterkits]] und [[AVR-Tutorial: Equipment]].<br />
<br />
* Programmiersoftware und -[[AVR In System Programmer |hardware]] z. B. PonyProg (siehe auch: [[Pony-Prog Tutorial]]) oder [[AVRDUDE]] mit [[STK200]]-Dongle oder die von Atmel verfügbare Hard- und Software ([[STK500]], Atmel AVRISP, [[AVR-Studio]]).<br />
<br />
* Nicht unbedingt erforderlich, aber zur Simulation und zum Debuggen unter MS-Windows recht nützlich: [[AVR-Studio]].<br />
<br />
* Wer unter Windows und Linux gleichermassen entwickeln will, der sollte sich die [http://www.eclipse.org/ IDE Eclipse for C/C++ Developers] und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] ansehen. Beide sind unter Windows und Linux einfach zu installieren, siehe auch [[AVR Eclipse]]. Ebenfalls unter Linux und Windows verfügbar ist die Entwicklungsumgebung [http://www.codeblocks.org/ Code::Blocks]<ref>Aktuelle, stabile Versionen sind als Nightly Builds regelmäßig im [http://forums.codeblocks.org/ Forum] verfügbar.</ref>. Innerhalb dieser Entwicklungsumgebung können ohne die Installation zusätzlicher Plugins "AVR-Projekte" angelegt werden. Für Linux gibt es auch noch das [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=25220 KontrollerLab].<br />
<br />
= Was tun, wenn's nicht klappt? =<br />
<br />
* Herausfinden, ob es tatsächlich ein avr(-gcc) spezifisches Problem ist oder nur die eigenen C-Kenntnisse einer Auffrischung bedürfen. Allgemeine C-Fragen kann man eventuell "beim freundlichen Programmierer zwei Büro-, Zimmer- oder Haustüren weiter" loswerden. Ansonsten: [[C]]-Buch (gibt's auch "gratis" online) lesen.<br />
<br />
* Die [[AVR Checkliste]] durcharbeiten.<br />
<br />
* Die '''[http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc]''' lesen, vor allem (aber nicht nur) den Abschnitt Related Pages/'''Frequently Asked Questions''' = Oft gestellte Fragen (und Antworten dazu). Z.Zt leider nur in englischer Sprache verfügbar.<br />
<br />
* Den Artikel [[AVR-GCC]] in diesem Wiki lesen.<br />
<br />
* Das [http://www.mikrocontroller.net/forum/gcc GCC-Forum auf www.mikrocontroller.net] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das avr-gcc-Forum bei [http://www.avrfreaks.net AVRfreaks] nach vergleichbaren Problemen absuchen.<br />
<br />
* Das [http://lists.gnu.org/archive/html/avr-gcc-list/ Archiv der avr-gcc Mailing-Liste] nach vergleichbaren Problemen absuchen.<br />
<br />
* Nach Beispielcode suchen. Vor allem im ''Projects''-Bereich von [http://www.avrfreaks.net AVRfreaks] (anmelden).<br />
<br />
* Google oder yahoo befragen schadet nie.<br />
<br />
* Bei Problemen mit der Ansteuerung interner AVR-Funktionen mit C-Code: das Datenblatt des Controllers lesen (ganz und am Besten zweimal). Datenblätter sind auf den [http://www.atmel.com Atmel Webseiten] als pdf-Dateien verfügbar. Das komplette Datenblatt (complete) und nicht die Kurzfassung (summary) verwenden.<br />
<br />
* Die Beispielprogramme im [[AVR-Tutorial]] sind zwar in AVR-Assembler verfasst, Erläuterungen und Vorgehensweisen sind aber auch auf C-Programme übertragbar.<br />
<br />
* Einen Beitrag in eines der Foren oder eine Mail an die Mailing-Liste schreiben. Dabei möglichst viel Information geben: Controller, Compilerversion, genutzte Bibliotheken, Ausschnitte aus dem Quellcode oder besser ein [http://www.mikrocontroller.net/topic/72767#598986 Testprojekt] mit allen notwendigen Dateien, um das Problem nachzuvollziehen, sowie genaue Fehlermeldungen bzw. Beschreibung des Fehlverhaltens. Bei Ansteuerung externer Geräte die Beschaltung beschreiben oder skizzieren (z. B. mit [http://www.tech-chat.de/ Andys ASCII Circuit]). Siehe dazu auch: '''[http://www.tty1.net/smart-questions_de.html "Wie man Fragen richtig stellt"]'''.<br />
<br />
= Erzeugen von Maschinencode =<br />
<br />
Aus dem C-Quellcode erzeugt der avr-gcc Compiler (zusammen mit Hilfsprogrammen wie z.&nbsp;B. Präprozessor, Assembler und Linker) Maschinencode für den AVR-Controller. Üblicherweise liegt dieser Code dann im Intel Hex-Format vor ("Hex-Datei"). Die Programmiersoftware (z.&nbsp;B. [[AVRDUDE]], PonyProg oder AVRStudio/STK500-plugin) liest diese Datei ein und überträgt die enthaltene Information (den Maschinencode) in den Speicher des Controllers. Im Prinzip sind also "nur" der avr-gcc-Compiler (und wenige Hilfsprogramme) mit den "richtigen" Optionen aufzurufen, um aus C-Code eine "Hex-Datei" zu erzeugen. Grundsätzlich stehen dazu drei verschiedene Ansätze zur Verfügung:<br />
<br />
* Die Verwendung einer integrierten Entwicklungsumgebung (IDE = '''I'''ntegrated '''D'''evelopment '''E'''nvironment), bei der alle Einstellungen z.&nbsp;B. in Dialogboxen durchgeführt werden können. Unter Anderem kann AVRStudio ab Version 4.12 (kostenlos auf [http://www.atmel.com/ atmel.com]) zusammen mit WinAVR als integrierte Entwicklungsumgebung für den Compiler avr-gcc genutzt werden (dazu müssen AVRStudio und WinAVR auf dem Rechner installiert sein). Weitere IDEs (ohne Anspruch auf Vollständigkeit): [http://www.eclipse.org/ Eclipse for C/C++ Developers] (d.h. inkl. CDT) und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] (für diverse Plattformen, u.a. Linux und MS Windows, IDE und Plugin kostenlos), [http://sourceforge.net/projects/kontrollerlab KontrollerLab] (Linux/KDE, kostenlos). [http://www.atmanecl.com/EnglishSite/SoftwareEnglish.htm AtmanAvr] (MS Windows, relativ günstig), KamAVR (MS-Windows, kostenlos, wird augenscheinlich nicht mehr weiterentwickelt), [http://www.amctools.com/vmlab.htm VMLab] (MS Windows, ab Version 3.12 ebenfalls kostenlos). Integrierte Entwicklungsumgebungen unterscheiden sich stark in Ihrer Bedienung und stehen auch nicht für alle Plattformen zur Verfügung, auf denen der Compiler ausführbar ist (z.&nbsp;B. AVRStudio nur für MS-Windows). Zur Anwendung des avr-gcc Compilers mit IDEs sei hier auf deren Dokumentation verwiesen. <br />
<br />
* Die Nutzung des Programms make mit passenden Makefiles. In den folgenden Abschnitten wird die Generierung von Maschinencode für einen AVR ("hex-Datei") aus C-Quellcode ("c-Dateien") anhand von "make" und den "Makefiles" näher erläutert. Viele der darin beschriebenen Optionen findet man auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio (AVRStudio generiert ein makefile in einem Unterverzeichnis des Projektverzeichnisses). <br />
<br />
* Das Generieren des Programms ohne IDE und ohne Makefile. In diesem Fall muss die Quellcodedatei durch eine vorgefertigte Kommandofolge an den Compiler übergeben werden. Der Artikel [[C ohne Makefile]] zeigt, wie das funktioniert. Diese Vorgehensweise empfiehlt sich jedoch nur für kleine Programme, die nicht auf verschiedene Quellcodedateien verteilt sind.<br />
<br />
Beim Wechsel vom makefile-Ansatz nach WinAVR-Vorlage zu AVRStudio ist darauf zu achten, dass AVRStudio (Stand: AVRStudio Version 4.13) bei einem neuen Projekt die Optimierungsoption (vgl. Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|AVR-GCC-Tutorial/Exkurs: Makefiles]], typisch: -Os) nicht einstellt und die mathematische Bibliothek der avr-libc (libm.a, Linker-Option -lm) nicht einbindet. (Hinweis: Bei Version 4.16 wird beides bereits gesetzt). Beides ist Standard bei Verwendung von makefiles nach WinAVR-Vorlage und sollte daher auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio "manuell" eingestellt werden, um auch mit AVRStudio kompakten Code zu erzeugen.<br />
<br />
= Einführungsbeispiel =<br />
<br />
Zum Einstieg ein kleines Beispiel, an dem die Nutzung des Compilers und der Hilfsprogramme (der sogenannten ''Toolchain'') demonstriert wird. Detaillierte Erläuterungen folgen in den weiteren Abschnitten dieses Tutorials.<br />
<br />
Das Programm soll auf einem AVR Mikrocontroller einige Ausgänge ein- und andere ausschalten. Das Beispiel ist für einen ATmega16 programmiert ([http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf Datenblatt]), kann aber sinngemäß für andere Controller der AVR-Familie modifiziert werden. <br />
<br />
Ein kurzes Wort zur Hardware: Bei diesem Programm werden alle Pins von PORTB auf Ausgang gesetzt, und einige davon werden auf HIGH andere auf LOW gesetzt. Das kann je nach angeschlossener Hardware an diesen Pins kritisch sein. Am ungefährlichsten ist es, wenn nichts an den Pins angeschlossen ist und man die Funktion des Programmes durch eine Spannungsmessung mit einem Multimeter kontrolliert. Die Spannung wird dabei zwischen GND-Pin und den einzelnen Pins von PORTB gemessen.<br />
<br />
Zunächst der Quellcode der Anwendung, der in einer Text-Datei mit dem Namen ''main.c'' abgespeichert wird.<br />
<br />
<syntaxhighlight lang="c"><br />
/* Alle Zeichen zwischen Schrägstrich-Stern <br />
und Stern-Schrägstrich sind Kommentare */<br />
<br />
// Zeilenkommentare sind ebenfalls möglich<br />
// alle auf die beiden Schrägstriche folgenden<br />
// Zeichen einer Zeile sind Kommentar<br />
<br />
#include <avr/io.h> // (1)<br />
<br />
int main (void) { // (2)<br />
<br />
DDRB = 0xFF; // (3)<br />
PORTB = 0x03; // (4)<br />
<br />
while(1) { // (5)<br />
/* "leere" Schleife*/ // (6)<br />
} // (7)<br />
<br />
/* wird nie erreicht */<br />
return 0; // (8)<br />
}<br />
</syntaxhighlight><br />
<br />
# In dieser Zeile wird eine sogenannte Header-Datei eingebunden. In <code>avr/io.h</code> sind die Registernamen definiert, die im späteren Verlauf genutzt werden. Auch unter Windows wird ein&nbsp;<code>/</code> zur Kennzeichnung von Unterverzeichnissen in Include-Dateinamen verwendet und kein&nbsp;<code>\</code>.<br />
# Hier beginnt das eigentliche Programm. Jedes C-Programm beginnt mit den Anweisungen in der Funktion <code>main</code>.<br />
# Die Anschlüsse eines AVR (Pins) werden zu Blöcken zusammengefasst, einen solchen Block bezeichnet man als Port. Beim ATmega16 hat jeder Port 8 Anschlüsse, bei kleineren AVRs können einem Port auch weniger als 8 Anschlüsse zugeordnet sein. Da per Definition (Datenblatt) alle gesetzten Bits in einem Datenrichtungsregister den entsprechenden Anschluss auf Ausgang schalten, werden mit DDRB=0xff alle Anschlüsse des Ports B als Ausgänge eingestellt.<br />
# Die den ersten beiden Bits des Ports zugeordneten Anschlüsse (PB0 und PB1) werden 1, alle anderen Anschlüsse des Ports B (PB2-PB7) zu 0. Aktivierte Ausgänge (logisch 1 oder "high") liegen auf Betriebsspannung (VCC, meist 5 Volt), nicht aktivierte Ausgänge führen 0 Volt (GND, Bezugspotential). Es ist sinnvoll, sich möglichst frühzeitig eine alternative Schreibweise beizubringen, die wegen der leichteren Überprüfbarkeit und Portierbarkeit oft im weiteren Tutorial und in Forenbeiträgen benutzt wird. Die Zuordnung sieht in diesem Fall so aus, Näheres dazu im Artikel [[Bitmanipulation]]:<syntaxhighlight lang="c">PORTB = (1<<PB1) | (1<<PB0);</syntaxhighlight><br />
# ist der Beginn der sogenannte ''Hauptschleife'' (main-loop). Dies ist eine Endlosschleife, welche kontinuierlich wiederkehrende Befehle enthält.<br />
# In diesem Beispiel ist die Hauptschleife leer. Der Controller durchläuft die Schleife immer wieder, ohne dass etwas passiert. Eine solche Schleife ist notwendig, da es auf dem Controller kein Betriebssystem gibt, das nach Beendigung des Programmes die Kontrolle übernehmen könnte. Ohne diese Schleife kehrt das Programm aus <code>main</code> zurück, alle Interrupts werden deaktiviert und eine Endlosschleife betreten.<br />
# Ende der Hauptschleife und Sprung zur passenden, öffnenden Klammer, also zu 5.<br />
# ist das Programmende. Die Zeile ist nur aus Gründen der C-Kompatibilität enthalten: <syntaxhighlight lang="c">int main(void)</syntaxhighlight> besagt, dass die Funktion einen int-Wert zurückgibt. Die Anweisung wird aber nicht erreicht, da das Programm die Hauptschleife nie verlässt.<br />
<br />
Um diesen Quellcode in ein lauffähiges Programm zu übersetzen, wird hier ein Makefile genutzt. Das verwendete Makefile findet sich auf der Seite [[Beispiel Makefile]] und basiert auf der Vorlage, die in WinAVR mitgeliefert wird und wurde bereits angepasst (Controllertyp ATmega16). Man kann das Makefile bearbeiten und an andere Controller anpassen oder sich mit dem Programm MFile menügesteuert ein Makefile "zusammenklicken". Das Makefile speichert man unter dem Namen <code>Makefile</code> (ohne Endung) im selben Verzeichnis, in dem auch die Datei <code>main.c</code> mit dem Programmcode abgelegt ist. Detailliertere Erklärungen zur Funktion von Makefiles finden sich im Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|Exkurs: Makefiles]].<br />
<br />
<pre><br />
D:\beispiel>dir<br />
<br />
Verzeichnis von D:\beispiel<br />
<br />
28.11.2006 22:53 <DIR> .<br />
28.11.2006 22:53 <DIR> ..<br />
28.11.2006 20:06 118 main.c<br />
28.11.2006 20:03 16.810 Makefile<br />
2 Datei(en) 16.928 Bytes<br />
</pre><br />
<br />
Nun gibt man ''make all'' ein. Falls das mit WinAVR installierte Programmers Notepad genutzt wird, gibt es dazu einen Menüpunkt im Tools Menü. Sind alle Einstellungen korrekt, entsteht eine Datei <code>main.hex</code>, in welcher der Code für den AVR enthalten ist. <br />
<pre><br />
D:\beispiel>make all<br />
<br />
-------- begin --------<br />
avr-gcc (GCC) 3.4.6<br />
Copyright (C) 2006 Free Software Foundation, Inc.<br />
This is free software; see the source for copying conditions. There is NO<br />
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.<br />
<br />
Compiling C: main.c<br />
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -f<br />
unsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef<br />
-Wa,-adhlns=obj/main.lst -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c -<br />
o obj/main.o<br />
<br />
Linking: main.elf<br />
avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -funs<br />
igned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -W<br />
a,-adhlns=obj/main.o -std=gnu99 -Wundef -MD -MP -MF .dep/main.elf.d obj/main.o<br />
--output main.elf -Wl,-Map=main.map,--cref -lm<br />
<br />
Creating load file for Flash: main.hex<br />
avr-objcopy -O ihex -R .eeprom main.elf main.hex<br />
</pre><br />
<br />
Der Inhalt der hex-Datei kann nun zum Controller übertragen werden. Dies kann z.&nbsp;B. über In-System-Programming ([[ISP]]) erfolgen, das im [[AVR-Tutorial: Equipment]] beschrieben ist. Makefiles nach der WinAVR/MFile-Vorlage sind für die Nutzung des Programms [[AVRDUDE]] vorbereitet. Wenn man den Typ und Anschluss des Programmiergerätes richtig eingestellt hat, kann mit ''make program'' die Übertragung mittels AVRDUDE gestartet werden. Jede andere Software, die hex-Dateien lesen und zu einem AVR übertragen kann<ref>z.&nbsp;B. [[Pony-Prog_Tutorial|Ponyprog]], yapp, AVRStudio</ref>, kann natürlich ebenfalls genutzt werden.<br />
<br />
Startet man nun den Controller (Reset-Taster oder Stromzufuhr aus/an), werden vom Programm die Anschlüsse PB0 und PB1 auf 1 gesetzt. Man kann mit einem Messgerät nun an diesem Anschluss die Betriebsspannung messen oder eine [[LED]] leuchten lassen (Anode an den Pin, Vorwiderstand nicht vergessen). An den Anschlüssen PB2-PB7 misst man 0 Volt. Eine mit der Anode mit einem dieser Anschlüsse verbundene LED leuchtet nicht.<br />
<br />
= Ganzzahlige Datentypen (Integer) =<br />
<br />
Bei der Programmierung von Mikrokontrollern ist die Definition einiger ganzzahliger Datentypen sinnvoll, an denen eindeutig die Bit-Länge abgelesen werden kann.<br />
<br />
Standardisierte Datentypen werden in der Header-Datei <code>stdint.h</code> definiert, die folgendermaßen eingebunden werden kann:<br />
<syntaxhighlight lang="c">#include <stdint.h></syntaxhighlight><br />
<br />
{| {{Tabelle}}<br />
|+ '''int-Typen aus <code>stdint.h</code> (C99)'''<br/>&nbsp;<br />
|- bgcolor="#d0d0ff"<br />
!colspan="5"| Vorzeichenbehaftete int-Typen<br />
|- bgcolor="#e8e8ff"<br />
! Typname || Bit-Breite ||colspan="2"| Wertebereich<br />
|align="center| '''C-Entsprechung''' (avr-gcc)<br />
|-<br />
|<code>int8_t</code> ||align="right"| 8 || −128 ⋯ 127 || −2<sup>7</sup> ⋯ 2<sup>7</sup>−1 || <code>signed char</code><br />
|-<br />
|<code>int16_t</code> ||align="right"| 16 || −32768 ⋯ 32767 || −2<sup>15</sup> ⋯ 2<sup>15</sup>−1 || <code>signed short</code>, <code>signed int</code><br />
|-<br />
|<code>int32_t</code> ||align="right"| 32 || −2147483648 ⋯ 2147483647 || −2<sup>31</sup> ⋯ 2<sup>31</sup>−1 || <code>signed long</code><br />
|-<br />
|<code>int64_t</code> ||align="right"| 64 || −9223372036854775808 ⋯ 9223372036854775807 || −2<sup>63</sup> ⋯ 2<sup>63</sup>−1 || <code>signed long long</code><br />
|- bgcolor="#d0d0ff"<br />
!colspan="5"| Vorzeichenlose int-Typen<br />
|- bgcolor="#e8e8ff"<br />
! Typname || Bit-Breite ||colspan="2"| Wertebereich<br />
|align="center| '''C-Entsprechung''' (avr-gcc)<br />
|-<br />
|<code>uint8_t</code> ||align="right"| 8 || 0 ⋯ 255 || 0 ⋯ 2<sup>8</sup>−1 || <code>unsigned char</code><br />
|-<br />
|<code>uint16_t</code> ||align="right"| 16 || 0 ⋯ 65535 || 0 ⋯ 2<sup>16</sup>−1 || <code>unsigned short</code>, <code>unsigned int</code><br />
|-<br />
|<code>uint32_t</code> ||align="right"| 32 || 0 ⋯ 4294967295 || 0 ⋯ 2<sup>32</sup>−1 || <code>unsigned long</code><br />
|-<br />
|<code>uint64_t</code> ||align="right"| 64 || 0 ⋯ 18446744073709551615 || 0 ⋯ 2<sup>64</sup>−1 || <code>unsigned long long</code><br />
|}<br />
<br />
Neben den Typen gibt es auch Makros für die Bereichsgrenzen wie <code>INT8_MIN</code> oder <code>UINT16_MAX</code>. Siehe dazu auch: [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html Dokumentation der avr-libc: Standard Integer Types].<br />
<br />
= Grundsätzlicher Programmaufbau eines µC-Programms =<br />
<br />
Wir unterscheiden zwischen 2 verschiedenen Methoden, um ein<br />
Mikrocontroller-Programm zu schreiben, und zwar völlig unabhängig davon, in<br />
welcher Programmiersprache das Programm geschrieben wird.<br />
<br />
== Sequentieller Programmablauf ==<br />
<br />
[[Image:Sequentielle Programme.gif|left]]<br />
Bei dieser Programmiertechnik wird eine Endlosschleife programmiert, welche im<br />
Wesentlichen immer den gleichen Aufbau hat. Es wird hier nach dem sogenannten EVA-Prinzip gehandelt. EVA steht für "Eingabe, Verarbeitung, Ausgabe".<br />
{{Absatz}}<br />
<br />
== Interruptgesteuerter Programmablauf ==<br />
<br />
[[Image:Interrupt Programme.gif|left]]<br />
Bei dieser Methode werden beim Programmstart zuerst die gewünschten Interruptquellen aktiviert und dann in eine Endlosschleife gegangen, in welcher Dinge erledigt werden können, welche nicht zeitkritisch sind. Wenn ein Interrupt ausgelöst wird, so wird automatisch die zugeordnete Interruptfunktion ausgeführt.<br />
{{Absatz}}<br />
<br />
= Zugriff auf Register =<br />
<br />
Die AVR-Controller verfügen über eine Vielzahl von Registern. Die meisten<br />
davon sind sogenannte Schreib-/Leseregister. Das heißt, das Programm kann die<br />
Inhalte der Register sowohl auslesen als auch beschreiben.<br />
<br />
Register haben einen besonderen Stellenwert bei den AVR Controllern. Sie dienen dem Zugriff auf die Ports und die Schnittstellen des Controllers. Wir unterscheiden zwischen 8-Bit und 16-Bit Registern. Vorerst behandeln wir die 8-Bit Register.<br />
<br />
Einzelne Register sind bei allen AVRs vorhanden, andere wiederum nur bei bestimmten Typen. So sind beispielsweise die Register, welche für den Zugriff auf den UART notwendig sind, selbstverständlich nur bei denjenigen Modellen vorhanden, welche über einen integrierten Hardware UART bzw. USART verfügen.<br />
<br />
Die Namen der Register sind in den Headerdateien zu den entsprechenden AVR-Typen definiert. Dazu muss man den Namen der controllerspezifischen Headerdatei nicht kennen. Es reicht aus, die allgemeine Headerdatei ''avr/io.h'' einzubinden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
</syntaxhighlight><br />
<br />
Ist im Makefile der MCU-Typ z.&nbsp;B. mit dem Inhalt atmega8 definiert (und wird somit per -mmcu=atmega8 an den Compiler übergeben), wird beim Einlesen der io.h-Datei implizit ("automatisch") auch die iom8.h-Datei mit den Register-Definitionen für den ATmega8 eingelesen.<br />
<br />
<!-- Wohl besser als Anhang - spaeter... --><br />
Intern wird diese "Automatik" wie folgt realisiert: Der Controllertyp wird dem Compiler als Parameter übergeben (vgl. ''avr-gcc -c -mmcu=atmega16 [...]'' im Einführungsbeispiel). Wird ein Makefile nach der WinAVR/mfile-Vorlage verwendet, setzt man die Variable ''MCU'', der Inhalt dieser Variable wird dann an passender Stelle für die Compilerparameter verwendet. Der Compiler definiert intern eine dem mmcu-Parameter zugeordnete "Variable" (genauer: ein Makro) mit dem Namen des Controllers, vorangestelltem ''__AVR_'' und angehängten Unterstrichen (z.&nbsp;B. wird bei ''-mmcu=atmega16'' das Makro ''__AVR_ATmega16__'' definiert). Beim Einbinden der Header-Datei ''avr/io.h'' wird geprüft, ob das jeweilige Makro definiert ist und die zum Controller passende Definitionsdatei eingelesen. Zur Veranschaulichung einige Ausschnitte aus einem Makefile:<br />
<br />
<pre><br />
[...]<br />
# MCU Type ("name") setzen:<br />
MCU = atmega16<br />
[...]<br />
<br />
[...]<br />
## Verwendung des Inhalts von MCU (hier atmega16) fuer die <br />
## Compiler- und Assembler-Parameter<br />
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)<br />
ALL_CPPFLAGS = -mmcu=$(MCU) -I. -x c++ $(CPPFLAGS) $(GENDEPFLAGS)<br />
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)<br />
[...]<br />
<br />
[...]<br />
## Aufruf des Compilers:<br />
## mit den Parametern ($(ALL_CFLAGS) ist -mmcu=$(MCU)[...] = -mmcu=atmega16[...]<br />
$(OBJDIR)/%.o : %.c<br />
@echo<br />
@echo $(MSG_COMPILING) $<<br />
$(CC) -c $(ALL_CFLAGS) $< -o $@ <br />
[...]<br />
</pre><br />
<br />
Da --mmcu=atmega16 übergeben wurde, wird __AVR_ATmega16__ definiert und kann in avr/io.h zur Fallunterscheidung genutzt werden:<br />
<br />
<syntaxhighlight lang="c"><br />
// avr/io.h <br />
// (bei WinAVR-Standardinstallation in C:\WinAVR\avr\include\avr)<br />
[...]<br />
#if defined (__AVR_AT94K__)<br />
# include <avr/ioat94k.h><br />
// [...]<br />
#elif defined (__AVR_ATmega16__)<br />
// da __AVR_ATmega16__ definiert ist, wird avr/iom16.h eingebunden:<br />
# include <avr/iom16.h><br />
// [...]<br />
#else<br />
# if !defined(__COMPILING_AVR_LIBC__)<br />
# warning "device type not defined"<br />
# endif<br />
#endif<br />
</syntaxhighlight><br />
<br />
Die Beispiele in den folgenden Abschnitten demonstrieren den Zugriff auf Register anhand der Register für I/O-Ports (PORTx, DDRx, PINx), die Vorgehensweise ist jedoch für alle Register (z.&nbsp;B. die des UART, ADC, SPI) analog.<br />
<br />
== Schreiben in Register ==<br />
<br />
Zum Schreiben kann man Register einfach wie eine Variable setzen.<ref>In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Schreibzugriff über die Funktion outp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt, outp() ist nicht mehr erforderlich.</ref><br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
/* Setzt das Richtungsregister des Ports A auf 0xff <br />
(alle Pins als Ausgang, vgl. Abschnitt Zugriff auf Ports): */<br />
DDRA = 0xff; <br />
<br />
/* Setzt PortA auf 0x03, Bit 0 und 1 "high", restliche "low": */<br />
PORTA = 0x03; <br />
<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binär 00011111 = Hexadezimal 1F<br />
DDRB = 0x1F; /* direkte Zuweisung - unübersichtlich */<br />
<br />
/* Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit<br />
aber übersichtlicher und selbsterklärend: */<br />
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);<br />
<br />
while (1);<br />
}<br />
</syntaxhighlight><br />
<br />
Die ausführliche Schreibweise sollte bevorzugt verwendet werden, da dadurch die Zuweisungen selbsterklärend sind und somit der Code leichter nachvollzogen werden kann. Atmel verwendet sie auch bei Beispielen in Datenblätten und in den allermeisten Quellcodes zu Application-Notes. Mehr zu der Schreibweise mit "|" und "<<" findet man unter [[Bitmanipulation]].<br />
<br />
Der gcc C-Compiler unterstützt ab Version 4.3.0 Konstanten im Binärformat, z.&nbsp;B. DDRB&nbsp;=&nbsp;0b00011111. Diese Schreibweise ist jedoch nur in GNU-C verfügbar und nicht in ISO-C definiert. Man sollte sie daher nicht verwenden, wenn Code mit anderen ausgetauscht oder mit anderen Compilern bzw. älteren Versionen des gcc genutzt werden soll.<br />
<br />
== Verändern von Registerinhalten ==<br />
<br />
Einzelne Bits setzt und löscht man "Standard-C-konform" mittels logischer (Bit-) Operationen. <br />
<br />
<syntaxhighlight lang="c"><br />
x |= (1 << Bitnummer); // Hiermit wird ein Bit in x gesetzt<br />
x &= ~(1 << Bitnummer); // Hiermit wird ein Bit in x geloescht<br />
</syntaxhighlight><br />
<br />
Es wird jeweils nur der Zustand des angegebenen Bits geändert, der vorherige Zustand der anderen Bits bleibt erhalten. <br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
#define MEINBIT 2<br />
...<br />
PORTA |= (1 << MEINBIT); /* setzt Bit 2 an PortA auf 1 */<br />
PORTA &= ~(1 << MEINBIT); /* loescht Bit 2 an PortA */<br />
</syntaxhighlight><br />
<br />
Mit dieser Methode lassen sich auch mehrere Bits eines Registers gleichzeitig setzen und löschen.<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
DDRA &= ~( (1<<PA0) | (1<<PA3) ); /* PA0 und PA3 als Eingaenge */<br />
PORTA |= ( (1<<PA0) | (1<<PA3) ); /* Interne Pull-Up fuer beide einschalten */<br />
</syntaxhighlight><br />
<br />
Bei bestimmten AVR Registern mit Bits, die durch Beschreiben mit einer logischen 1 gelöscht werden, muss eine absolute Zuweisung benutzt werden. Ein ODER löscht in diesen Registern ALLE gesetzten Bits!<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
TIFR2 = (1<<OCF2A); // Nur Bit OCF2A löschen<br />
</syntaxhighlight><br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind nicht mehr erforderlich.<br />
<br />
Siehe auch:<br />
* [[Bitmanipulation]]<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
<br />
== Lesen aus Registern ==<br />
<br />
Zum Lesen kann man auf Register einfach wie auf eine Variable zugreifen. In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Lesezugriff über die Funktion inp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt und inp() ist nicht mehr erforderlich.<br />
<br />
Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdint.h><br />
<br />
uint8_t foo;<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
/* kopiert den Status der Eingabepins an PortB <br />
in die Variable foo: */<br />
foo = PINB; <br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Die Abfrage der Zustände von Bits erfolgt durch Einlesen des gesamten Registerinhalts und ausblenden der Bits deren Zustand nicht von Interesse ist. Einige Beispiele zum Prüfen ob Bits gesetzt oder gelöscht sind:<br />
<br />
<syntaxhighlight lang="c"><br />
#define MEINBIT0 0 <br />
#define MEINBIT2 2<br />
<br />
uint8_t i;<br />
<br />
extern test1();<br />
<br />
// Funkion test1 aufrufen, wenn Bit 0 in Register PINA gesetzt (1) ist<br />
i = PINA; // Inhalt in Arbeitsvariable<br />
i = i & 0x01; // alle Bits bis auf Bit 0 ausblenden (bitweise und)<br />
// falls das Bit gesetzt war, hat i den Inhalt 1<br />
if ( i != 0 ) { // Ergebnis ungleich 0 (wahr)? <br />
test1(); // dann muss Bit 0 in i gesetzt sein -> Funktion aufrufen<br />
}<br />
// verkürzt:<br />
if ( ( PINA & 0x01 ) != 0 ) {<br />
test1();<br />
}<br />
// nochmals verkürzt:<br />
if ( PINA & 0x01 ) {<br />
test1();<br />
}<br />
// mit definierter Bitnummer:<br />
if ( PINA & ( 1 << MEINBIT0 ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und/oder Bit 2 gesetzt ist. (Bit 0 und 2 also Wert 5) <br />
// (Bedenke: Bit 0 hat Wert 1, Bit 1 hat Wert 2 und Bit 2 hat Wert 4)<br />
if ( PINA & 0x05 ) {<br />
test1(); // Vergleich <> 0 (wahr), also mindestens eines der Bits gesetzt<br />
}<br />
// mit definierten Bitnummern:<br />
if ( PINA & ( ( 1 << MEINBIT0 ) | ( 1 << MEINBIT2 ) ) ) {<br />
test1();<br />
}<br />
<br />
// Funktion aufrufen, wenn Bit 0 und Bit 2 gesetzt sind<br />
if ( ( PINA & 0x05 ) == 0x05 ) { // nur wahr, wenn beide Bits gesetzt<br />
test1();<br />
}<br />
<br />
// Funktion test2() aufrufen, wenn Bit 0 gelöscht (0) ist<br />
i = PINA; // einlesen in temporäre Variable<br />
i = i & 0x01; // maskieren von Bit 0<br />
if ( i == 0 ) { // Vergleich ist wahr, wenn Bit 0 nicht gesetzt ist<br />
test2();<br />
}<br />
// analog mit not-Operator<br />
if ( !i ) {<br />
test2();<br />
}<br />
// nochmals verkürzt:<br />
if ( !( PINA & 0x01 ) ) {<br />
test2();<br />
}<br />
</syntaxhighlight><br />
<br />
== Warten auf einen bestimmten Zustand ==<br />
<br />
Es gibt in der Bibliothek avr-libc Funktionen, die warten, bis ein bestimmter Zustand eines Bits erreicht ist. Es ist allerdings normalerweise eine eher unschöne Programmiertechnik, da in diesen Funktionen "blockierend" gewartet wird. Der Programmablauf bleibt also an dieser Stelle stehen, bis das maskierte Ereignis erfolgt ist. Setzt man den [[Watchdog]] ein, muss man darauf achten, dass dieser auch noch getriggert wird (Zurücksetzen des Watchdogtimers). <br />
<br />
Die Funktion '''loop_until_bit_is_set''' wartet in einer Schleife, bis das definierte Bit gesetzt ist. Wenn das Bit beim Aufruf der Funktion bereits gesetzt ist, wird die Funktion sofort wieder verlassen. Das niederwertigste Bit hat die Bitnummer 0. <br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 2 (das dritte Bit) in Register PINA gesetzt (1) ist */<br />
<br />
#define WARTEPIN PINA<br />
#define WARTEBIT PA2<br />
<br />
// mit der avr-libc Funktion:<br />
loop_until_bit_is_set(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// _nicht_ ungleich 0 (also 0) ist.<br />
while ( !(WARTEPIN & (1 << WARTEBIT)) ) {}<br />
...<br />
</syntaxhighlight><br />
<br />
<br />
Die Funktion '''loop_until_bit_is_clear''' wartet in einer Schleife, bis das definierte Bit gelöscht ist. Wenn das Bit beim Aufruf der Funktion bereits gelöscht ist, wird die Funktion sofort wieder verlassen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
<br />
/* Warten bis Bit Nr. 4 (das fuenfte Bit) in Register PINB geloescht (0) ist */<br />
#define WARTEPIN PINB<br />
#define WARTEBIT PB4<br />
<br />
// avr-libc-Funktion:<br />
loop_until_bit_is_clear(WARTEPIN, WARTEBIT);<br />
<br />
// dito in "C-Standard":<br />
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN<br />
// gesetzt (1) ist <br />
while ( WARTEPIN & (1<<WARTEBIT) ) {}<br />
...<br />
</syntaxhighlight><br />
<br />
Universeller und auch auf andere Plattformen besser übertragbar ist die Verwendung von C-Standardoperationen.<br />
<br />
Siehe auch: <br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers<br />
* [[Bitmanipulation]]<br />
<br />
== 16-Bit Register (ADC, ICR1, OCR1x, TCNT1, UBRR) ==<br />
<br />
Einige der Portregister in den AVR-Controllern sind 16 Bit breit. Im Datenblatt sind diese Register üblicherweise mit dem Suffix "L" (Low-Byte) und "H" (High-Byte) versehen. Die avr-libc definiert zusätzlich die meisten dieser Variablen die Bezeichnung ohne "L" oder "H". Auf diese Register kann dann direkt zugegriffen werden. Dies ist zum Beispiel der Fall für Register wie ADC oder TCNT1.<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
uint16_t foo;<br />
<br />
/* setzt die Wort-Variable foo auf den Wert der letzten AD-Wandlung */<br />
foo = ADC; <br />
</syntaxhighlight><br />
<br />
Bei anderen Registern, wie zum Beispiel Baudraten-Register, liegen High- und Low-Teil nicht direkt nebeneinander im SFR-Bereich, so dass ein 16-Bit Zugriff nicht möglich ist und der Zugriff zusammengebastelt werden muss:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
...<br />
uint16_t baud = F_CPU / (UART_BAUD_RATE * 16L) -1;<br />
<br />
UBRRH = (uint8_t) (baud >> 8);<br />
UBRRL = (uint8_t) baud;<br />
...<br />
</syntaxhighlight><br />
<br />
Bei einigen AVR-Typen wie ATmega8 oder ATmega16 teilen sich UBRRH und UCSRC die gleiche Speicher-Adresse. Damit der AVR trotzdem zwischen den beiden Registern unterscheiden kann, bestimmt das Bit7 (URSEL), welches Register tatsächlich beschrieben werden soll. ''1000 0011'' (0x83) adressiert demnach UCSRC und übergibt den Wert ''3''. Und ''0000 0011'' (0x3) adressiert UBRRH und übergibt ebenfalls den Wert ''3''. <br />
<br />
Speziell bei den 16-Bit-Timern und auch beim ADC ist es bei allen Zugriffen auf Datenregister erforderlich, dass diese Daten synchronisiert sind. Wenn z.&nbsp;B. bei einem 16-Bit-Timer das High-Byte des Zählregisters gelesen wurde und vor dem Lesezugriff auf das Low-Byte ein Überlauf des Low-Bytes stattfindet, erhält man einen völlig unsinnigen Wert. Auch die Compare-Register müssen synchron geschrieben werden, da es ansonsten zu unerwünschten Compare-Ereignissen kommen kann. <br />
<br />
Beim ADC besteht das Problem darin, dass zwischen den Zugriffen auf die beiden Teilregister eine Wandlung beendet werden kann und der ADC ein neues Ergebnis in ADCL und ADCH schreiben will, wodurch High- und Low-Byte nicht zusammenpassen.<br />
<br />
Um diese Datenmüllproduktion zu verhindern, gibt es in beiden Fällen eine Synchronisation, die jeweils durch den Zugriff auf das Low-Byte ausgelöst wird:<br />
* Bei den Timer-Registern (das gilt für alle TCNT-, OCR- und ICR-Register bei den 16-Bit-Timern) wird bei einem ''Lesezugriff'' auf das Low-Byte automatisch das High-Byte in ein temporäres Register, das ansonsten nach außen nicht sichtbar ist, geschoben. Greift man nun ''anschließend'' auf das High-Byte zu, dann wird eben dieses temporäre Register gelesen.<br />
* Bei einem ''Schreibzugriff'' auf eines der genannten Register wird das High-Byte in besagtem temporären Register zwischengespeichert und erst beim Schreiben des Low-Bytes werden ''beide'' gleichzeitig in das eigentliche Register übernommen.<br />
<br />
Das bedeutet für die Reihenfolge:<br />
* Lesezugriff: Erst Low-Byte, dann High-Byte<br />
* Schreibzugriff: Erst High-Byte, dann Low-Byte<br />
<br />
Des weiteren ist zu beachten, dass es für all diese 16-Bit-Register nur ein einziges temporäres Register gibt, so dass das Auftreten eines Interrupts, in dessen Handler ein solches Register manipuliert wird, bei einem durch ihn unterbrochenen Zugriff i.d.R. zu Datenmüll führt. 16-Bit-Zugriffe sind generell nicht atomar! Wenn mit Interrupts gearbeitet wird, kann es erforderlich sein, vor einem solchen Zugriff auf ein 16-Bit-Register die Interrupt-Bearbeitung zu deaktivieren.<br />
<br />
Beim ADC-Datenregister ADCH/ADCL ist die Synchronisierung anders gelöst. Hier wird beim Lesezugriff (ADCH/ADCL sind logischerweise read-only) auf das Low-Byte ADCL beide Teilregister für Zugriffe seitens des ADC so lange gesperrt, bis das High-Byte ADCH ausgelesen wurde. Dadurch kann der ADC nach einem Zugriff auf ADCL keinen neuen Wert in ADCH/ADCL ablegen, bis ADCH gelesen wurde. Ergebnisse von Wandlungen, die zwischen einem Zugriff auf ADCL und ADCH beendet werden, gehen verloren!<br />
<br />
Nach einem Zugriff auf ADCL muss grundsätzlich ADCH gelesen werden!<br />
<br />
In beiden Fällen – also sowohl bei den Timern als auch beim ADC – werden vom C-Compiler 16-Bit Pseudo-Register zur Verfügung gestellt (z.&nbsp;B. TCNT1H/TCNT1L → TCNT1, ADCH/ADCL → ADC bzw. ADCW), bei deren Verwendung der Compiler automatisch die richtige Zugriffsreihenfolge regelt. In C-Programmen sollten grundsätzlich diese 16-Bit-Register verwendet werden! Sollte trotzdem ein Zugriff auf ein Teilregister erforderlich sein, sind obige Angaben zu berücksichtigen.<br />
<br />
Es ist darauf zu achten, dass auch ein Zugriff auf die 16-Bit-Register vom Compiler in zwei 8-Bit-Zugriffe aufgeteilt wird und dementsprechend genauso nicht-atomar ist wie die Einzelzugriffe. Auch hier gilt, dass u.U. die Interrupt-Bearbeitung gesperrt werden muss, um Datenmüll zu vermeiden.<br />
<br />
Beim ADC gibt es für den Fall, dass eine Auflösung von 8 Bit ausreicht, die Möglichkeit, das Ergebnis "linksbündig" in ADCH/ADCL auszurichten, so dass die relevanten 8 MSB in ADCH stehen. In diesem Fall muss bzw. sollte nur ADCH ausgelesen werden.<br />
<br />
ADC und ADCW sind unterschiedliche Bezeichner für das selbe Registerpaar. Üblicherweise kann man in C-Programmen ADC verwenden, was analog zu den anderen 16-Bit-Registern benannt ist. ADCW (ADC Word) existiert nur deshalb, weil die Headerdateien auch für Assembler vorgesehen sind und es bereits einen Assembler-Befehl namens ''adc'' gibt. <br />
<br />
Im Umgang mit 16-Bit Registern siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Related Pages/Frequently Asked Questions/Nr. 8<br />
* Datenblatt Abschnitt ''Accessing 16-bit Registers''<br />
<br />
== IO-Register als Parameter und Variablen ==<br />
<br />
Um Register als Parameter für eigene Funktionen übergeben zu können, muss man sie als einen volatile uint8_t Pointer übergeben. Zum Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <util/delay.h><br />
<br />
uint8_t key_pressed (volatile uint8_t *inputreg, uint8_t inputbit)<br />
{<br />
static uint8_t last_state = 0;<br />
<br />
if (last_state == (*inputreg & (1<<inputbit)))<br />
return 0; /* keine Änderung */<br />
<br />
/* Wenn doch, warten bis etwaiges Prellen vorbei ist: */<br />
_delay_ms(20);<br />
<br />
/* Zustand für nächsten Aufruf merken: */<br />
last_state = *inputreg & (1<<inputbit);<br />
<br />
/* und den entprellten Tastendruck zurückgeben: */<br />
return *inputreg & (1<<inputbit);<br />
}<br />
<br />
/* Beispiel für einen Funktionsaufruf: */<br />
<br />
void foo (void)<br />
{<br />
uint8_t i = key_pressed (&PINB, PB1);<br />
}<br />
</syntaxhighlight><br />
<br />
Ein Aufruf der Funktion mit call by value würde Folgendes bewirken: Beim Funktionseintritt wird nur eine Kopie des momentanen Portzustandes angefertigt, die sich unabhängig vom tatsächlichen Zustand das Ports nicht mehr ändert, womit die Funktion wirkungslos wäre. Die Übergabe eines Zeigers wäre die Lösung, wenn der Compiler nicht optimieren würde. Denn dadurch wird im Programm nicht von der Hardware gelesen, sondern wieder nur von einem Abbild im Speicher. Das Ergebnis wäre das gleiche wie oben. Mit dem Schlüsselwort volatile sagt man nun dem Compiler, dass die entsprechende Variable entweder durch andere Softwareroutinen (Interrupts) oder durch die Hardware verändert werden kann.<br />
<br />
Siehe auch: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass avr-libc FAQ: "How do I pass an IO port as a parameter to a function?"]<br />
<br />
= Zugriff auf IO-Ports =<br />
<br />
Jeder AVR implementiert eine unterschiedliche Menge an GPIO-Registern<br />
(GPIO - General Purpose Input/Output). Diese Register dienen dazu:<br />
* einzustellen welche der Anschlüsse ("Beinchen") des Controllers als Ein- oder Ausgänge dienen<br />
* bei Ausgängen deren Zustand festzulegen<br />
* bei Eingängen deren Zustand zu erfassen<br />
<br />
Mittels GPIO werden digitale Zustände gesetzt und erfasst, d.h. die Spannung an einem Ausgang wird ein- oder ausgeschaltet und an einem Eingang wird erfasst, ob die anliegende Spannung über oder unter einem bestimmten Schwellwert liegt. Im Datenblatt Abschnitt Electrical Characteristics/DC Characteristics finden sich die Spannungswerte (V_OL, V_OH für Ausgänge, V_IL, V_IH für Eingänge).<br />
<br />
Die Verarbeitung von analogen Eingangswerten und die Ausgabe von Analogwerten wird in Kapitel [[AVR-GCC-Tutorial#Analoge_Ein-_und_Ausgabe|Analoge Ein- und Ausgabe]] behandelt.<br />
<br />
Die physischen Ein- und Ausgänge werden bei AVR-Controllern zu logischen Ports gruppiert.<br />
<br />
Alle Ports werden über Register gesteuert. Dazu sind jedem Port 3 Register zugeordnet:<br />
<br />
{| class="wikitable"<br />
|- <br />
! width="10%"| DDRx<br />
| Datenrichtungsregister für Port'''x'''. <br />
'''x''' entspricht '''A''', '''B''', ''' C''' usw. je nach gewünschtem Port. Bit im Register gesetzt (1) für Ausgang, Bit gelöscht (0) für Eingang.<br />
|- <br />
! PINx<br />
| Eingangsadresse für Port'''x'''. <br />
Zustand des Ports. Die Bits in PINx entsprechen dem Zustand der als Eingang definierten Portpins. Bit 1 wenn Pin "high", Bit 0 wenn Portpin low.<br />
|-<br />
! PORTx<br />
| Datenregister für Port'''x'''. <br />
Dieses Register wird verwendet, um die Ausgänge eines Ports anzusteuern. Bei Pins, die mittels DDRx auf Eingang geschaltet wurden, können über PORTx<br />
die internen Pull-Up Widerstände aktiviert oder deaktiviert werden (1 = aktiv).<br />
|}<br />
<br />
Die folgenden Beispiele gehen von einem AVR aus, der sowohl Port A als auch Port B besitzt. Sie müssen für andere AVRs (zum Beispiel ATmega8/48/88/168) entsprechend angepasst werden.<br />
<br />
== Datenrichtung bestimmen ==<br />
<br />
Zuerst muss die Datenrichtung der verwendeten Pins bestimmt werden. Um dies zu erreichen, wird das Datenrichtungsregister des entsprechenden Ports beschrieben.<br />
<br />
Für jeden Pin, der als Ausgang verwendet werden soll, muss dabei das<br />
entsprechende Bit auf dem Port gesetzt werden. Soll der Pin als Eingang<br />
verwendet werden, muss das entsprechende Bit gelöscht sein.<br />
<br />
Beispiel:<br />
Angenommen am Port B sollen die Pins 0 bis 4 als Ausgänge definiert werden, die noch verbleibenden Pins 5 bis 7 sollen als Eingänge fungieren. Dazu ist es daher notwendig, im für das Port B zuständigen Datenrichtungsregister DDRB folgende Bitkonfiguration einzutragen<br />
<br />
+---+---+---+---+---+---+---+---+<br />
| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |<br />
+---+---+---+---+---+---+---+---+<br />
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |<br />
<br />
In C liest sich das dann so:<br />
<br />
<syntaxhighlight lang="c"><br />
// in io.h wird u.a. DDRB definiert:<br />
#include <avr/io.h><br />
<br />
int main()<br />
{<br />
// Setzen der Bits 0,1,2,3 und 4<br />
// Binaer 00011111 = Hexadezimal 1F<br />
// direkte Zuweisung - standardkonform */<br />
DDRB = 0x1F; /* <br />
<br />
// Uebersichtliche Alternative - Binaerschreibweise, aber kein ISO-C<br />
DDRB = 0b00011111;<br />
<br />
// Ausfuehrliche Schreibweise: identische Funktionalitaet, mehr Tipparbeit<br />
// aber uebersichtlicher und selbsterklaerend:<br />
DDRB |= (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4); <br />
</syntaxhighlight><br />
<br />
Die Pins 5 bis 7 werden (da 0) als Eingänge geschaltet. Weitere Beispiele:<br />
<br />
<syntaxhighlight lang="c"><br />
// Alle Pins des Ports B als Ausgang definieren:<br />
DDRB = 0xff; <br />
// Pin0 wieder auf Eingang und andere im urspruenglichen Zustand belassen:<br />
DDRB &= ~(1 << DDB0);<br />
// Pin 3 und 4 auf Eingang und andere im urspruenglichen Zustand belassen:<br />
DDRB &= ~((1 << DDB3) | (1 << DDB4));<br />
// Pin 0 und 3 wieder auf Ausgang und andere im ursprünglichen Zustand belassen:<br />
DDRB |= (1 << DDB0) | (1 << DDB3);<br />
// Alle Pins auf Eingang:<br />
DDRB = 0x00;<br />
</syntaxhighlight><br />
<br />
== Vordefinierte Bitnummern für I/O-Register ==<br />
<br />
Die Bitnummern (z.&nbsp;B. PCx, PINCx und DDCx für den Port C) sind in den io*.h-Dateien der avr-libc definiert und dienen lediglich der besseren Lesbarkeit. Man muss diese Definitionen nicht verwenden oder kann auch einfach "immer" PAx, PBx, PCx usw. nutzen, auch wenn der Zugriff auf Bits in DDRx- oder PINx-Registern erfolgt. Für den Compiler sind die Ausdrücke (1<<PC7), (1<<DDC7) und (1<<PINC7) identisch zu (1<<7) (genauer: der Präprozessor ersetzt die Ausdrücke (1<<PC7),... zu (1<<7)). Ein Ausschnitt der Definitionen für Port C eines ATmega32 aus der iom32.h-Datei zur Verdeutlichung (analog für die weiteren Ports):<br />
<br />
<syntaxhighlight lang="c"><br />
...<br />
/* PORTC */<br />
#define PC7 7<br />
#define PC6 6<br />
#define PC5 5<br />
#define PC4 4<br />
#define PC3 3<br />
#define PC2 2<br />
#define PC1 1<br />
#define PC0 0<br />
<br />
/* DDRC */<br />
#define DDC7 7<br />
#define DDC6 6<br />
#define DDC5 5<br />
#define DDC4 4<br />
#define DDC3 3<br />
#define DDC2 2<br />
#define DDC1 1<br />
#define DDC0 0<br />
<br />
/* PINC */<br />
#define PINC7 7<br />
#define PINC6 6<br />
#define PINC5 5<br />
#define PINC4 4<br />
#define PINC3 3<br />
#define PINC2 2<br />
#define PINC1 1<br />
#define PINC0 0<br />
</syntaxhighlight><br />
<br />
<br />
== Digitale Signale ==<br />
<br />
Am einfachsten ist es, digitale Signale mit dem Mikrocontroller zu erfassen bzw. auszugeben.<br />
<br />
== Ausgänge ==<br />
Will man als Ausgang definierte Pins (entsprechende DDRx-Bits = 1) auf Logisch 1 setzen, setzt man die entsprechenden Bits im Portregister.<br />
<br />
Mit dem Befehl<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB = 0x04; /* besser PORTB=(1<<PB2) */<br />
<br />
// Uebersichtliche Alternative - Binaerschreibweise<br />
PORTB = 0b00000100; /* direkte Zuweisung - uebersichtlich */<br />
<br />
</syntaxhighlight><br />
wird also der Ausgang an Pin PB2 gesetzt (Beachte, dass die Bits immer ''von 0 an'' gezählt werden, das niederwertigste Bit ist also Bitnummer 0 und nicht etwa Bitnummer 1).<br />
<br />
Man beachte, dass bei der Zuweisung mittels '''=''' immer alle Pins gleichzeitig angegeben werden. Man sollte also, wenn nur bestimmte Ausgänge geschaltet werden sollen, zuerst den aktuellen Wert des Ports einlesen und das Bit des gewünschten Ports in diesen Wert einfließen lassen. Will man also nur den dritten Pin (Bit Nr. 2) an Port B auf "high" setzen und den Status der anderen Ausgänge unverändert lassen, nutze man diese Form:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB = PORTB | 0x04; /* besser: PORTB = PORTB | ( 1<<PB2 ) */<br />
/* vereinfacht durch Nutzung des |= Operators : */<br />
PORTB |= (1<<PB2);<br />
<br />
/* auch mehrere "gleichzeitig": */<br />
PORTB |= (1<<PB4) | (1<<PB5); /* Pins PB4 und PB5 "high" */<br />
</syntaxhighlight><br />
<br />
"Ausschalten", also Ausgänge auf "low" setzen, erfolgt analog:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
PORTB &= ~(1<<PB2); /* loescht Bit 2 in PORTB und setzt damit Pin PB2 auf low */ <br />
PORTB &= ~( (1<<PB4) | (1<<PB5) ); /* Pin PB4 und Pin PB5 "low" */<br />
</syntaxhighlight><br />
Siehe auch [[Bitmanipulation]]<br />
<br />
In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind in aktuellen Versionen der avr-libc nicht mehr enthalten und auch nicht mehr erforderlich.<br />
<br />
''Falls der Anfangszustand von Ausgängen kritisch ist, muss die Reihenfolge beachtet werden, mit der die Datenrichtung (DDRx) eingestellt und der Ausgabewert (PORTx) gesetzt wird:''<br />
<br />
Für Ausgangspins, die mit Anfangswert "high" initialisiert werden sollen:<br />
* zuerst die Bits im PORTx-Register setzen<br />
* anschließend die Datenrichtung auf Ausgang stellen<br />
<br />
Daraus ergibt sich die Abfolge für einen Pin, der bisher als Eingang mit abgeschaltetem Pull-Up konfiguriert war:<br />
* setze PORTx: interner Pull-Up aktiv<br />
* setze DDRx: Ausgang ("high")<br />
<br />
Bei der Reihenfolge erst DDRx und dann PORTx kann es zu einem kurzen "low-Puls" kommen, der auch externe Pull-Up-Widerstände "überstimmt". Die (ungünstige) Abfolge: Eingang -> setze DDRx: Ausgang (auf "low", da PORTx nach Reset 0) -> setze PORTx: Ausgang auf high. Vergleiche dazu auch das Datenblatt Abschnitt ''Configuring the Pin''.<br />
<br />
== Eingänge (Wie kommen Signale in den &micro;C) ==<br />
<br />
Die digitalen Eingangssignale können auf verschiedene Arten zu unserer Logik gelangen.<br />
<br />
=== Signalkopplung ===<br />
<br />
Am einfachsten ist es, wenn die Signale direkt aus einer anderen digitalen Schaltung übernommen werden können. Hat der Ausgang der entsprechenden Schaltung TTL-Pegel dann können wir sogar direkt den Ausgang der Schaltung mit einem Eingangspin von unserem Controller verbinden.<br />
<br />
Hat der Ausgang der anderen Schaltung keinen TTL-Pegel so müssen wir den Pegel über entsprechende Hardware (z.&nbsp;B. Optokoppler, [[Widerstand#Spannungsteiler|Spannungsteiler]], "Levelshifter" aka [[Pegelwandler]]) anpassen.<br />
<br />
Die Masse der beiden Schaltungen muss selbstverständlich miteinander verbunden werden. Der Software selber ist es natürlich letztendlich egal, wie das Signal eingespeist wird. Wir können ja ohnehin lediglich prüfen, ob an einem Pin unseres Controllers eine logische 1 (Spannung größer ca. 0,7*Vcc) oder eine logische 0 (Spannung kleiner ca. 0,2*Vcc) anliegt. Detaillierte Informationen darüber, ab welcher Spannung ein Eingang als 0 ("low") bzw. 1 ("high") erkannt wird, liefert die Tabelle DC Characteristics im Datenblatt des genutzten Controllers.<br />
<br />
{| class="wikitable" style="text-align:center; width:20em"<br />
|+ '''Logikpegel'''<br />
|-<br />
! VCC [V]<br />
! Low [V]<br />
! High [V]<br />
|-<br />
! 5<br />
| 1,0 || 3,5<br />
|-<br />
! 3,3<br />
| 0,66 || 2,3<br />
|-<br />
! 1,8<br />
| 0,36 || 1,26 <br />
|}<br />
<br />
Die Abfrage der Zustände der Portpins erfolgt direkt über den Registernamen.<br />
<br />
{{Warnung|Dabei ist wichtig, zur Abfrage der Eingänge ''nicht'' etwa Portregister '''PORTx''' zu verwenden, sondern Eingangsregister '''PINx'''. Ansonsten liest man nicht den Zustand der Eingänge, sondern den Status der internen Pull-Up-Widerstände. Die Abfrage der Pinzustände über PORTx statt PINx ist ein häufiger Fehler beim AVR-"Erstkontakt".}}<br />
<br />
Will man also die aktuellen Signalzustände von Port D abfragen und in eine Variable namens bPortD abspeichern, schreibt man folgende Befehlszeilen:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdint.h><br />
...<br />
uint8_t bPortD;<br />
...<br />
bPortD = PIND;<br />
...<br />
</syntaxhighlight><br />
<br />
Mit den C-Bitoperationen kann man den Status der Bits abfragen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
/* Fuehre Aktion aus, wenn Bit Nr. 1 (das "zweite" Bit) in PINC gesetzt (1) ist */<br />
if ( PINC & (1<<PINC1) ) {<br />
/* Aktion */<br />
}<br />
<br />
/* Fuehre Aktion aus, wenn Bit Nr. 2 (das "dritte" Bit) in PINB geloescht (0) ist */<br />
if ( !(PINB & (1<<PINB2)) ) {<br />
/* Aktion */<br />
}<br />
...<br />
</syntaxhighlight><br />
Siehe auch [[Bitmanipulation#Bits_prüfen]]<br />
<br />
=== Interne Pull-Up Widerstände ===<br />
<br />
Portpins für Ein- und Ausgänge (GPIO) eines AVR verfügen über zuschaltbare interne Pull-Up Widerstände (nominal mehrere 10kOhm, z.&nbsp;B. ATmega16 20-50kOhm). Diese können in vielen Fällen statt externer Widerstände genutzt werden.<br />
<br />
Die internen Pull-Up Widerstände von Vcc zu den einzelnen Portpins werden über das Register ''' PORTx''' aktiviert bzw. deaktiviert, wenn ein Pin als ''' Eingang''' geschaltet ist.<br />
<br />
Wird der Wert des entsprechenden Portpins auf 1 gesetzt, so ist der Pull-Up Widerstand aktiviert. Bei einem Wert von 0 ist der Pull-Up Widerstand nicht aktiv. Man sollte jeweils entweder den internen oder einen externen Pull-Up Widerstand verwenden, aber nicht beide zusammen.<br />
<br />
Im Beispiel werden alle Pins des Ports D als Eingänge geschaltet und alle Pull-Up Widerstände aktiviert. Weiterhin wird Pin PC7 als Eingang geschaltet und dessen interner Pull-Up Widerstand aktiviert, ohne die Einstellungen für die anderen Portpins (PC0-PC6) zu verändern.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
DDRD = 0x00; /* alle Pins von Port D als Eingang */<br />
PORTD = 0xff; /* interne Pull-Ups an allen Port-Pins aktivieren */<br />
...<br />
DDRC &= ~(1<<PC7); /* Pin PC7 als Eingang */<br />
PORTC |= (1<<PC7); /* internen Pull-Up an PC7 aktivieren */<br />
</syntaxhighlight><br />
<br />
=== Taster und Schalter ===<br />
<br />
Der Anschluss mechanischer Kontakte an den Mikrocontroller, ist zwischen zwei unterschiedliche Methoden zu unterscheiden: ''Active Low'' und ''Active High''.<br />
<br />
<gallery widths="300" heights="300" caption="Anschluss mechanischer Kontakte an einen µC"><br />
Image:Active Low.gif|'''Active Low:''' Bei dieser Methode wird der Kontakt zwischen den Eingangspin des Controllers und Masse geschaltet. Damit bei offenem Schalter der Controller kein undefiniertes Signal bekommt, wird zwischen die Versorgungsspannung und den Eingangspin ein sogenannter '''Pull-Up''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffnetem Schalter auf logisch 1 zu ziehen.<br />
Image:Active High.gif|'''Active High:''' Hier wird der Kontakt zwischen die Versorgungsspannung und den Eingangspin geschaltet. Damit bei offener Schalterstellung kein undefiniertes Signal am Controller ansteht, wird zwischen den Eingangspin und die Masse ein '''Pull-Down''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffneter Schalterstellung auf logisch 0 zu halten. <br />
</gallery><br />
<br />
Der Widerstandswert von Pull-Up- und Pull-Down-Widerständen ist an sich nicht kritisch. Wird er allerdings zu hoch gewählt, ist die Wirkung eventuell nicht gegeben. Als üblicher Wert haben sich 10 kOhm eingebürgert. Die AVRs verfügen an den meisten Pins über zuschaltbare interne Pull-Up Widerstände (vgl. Abschnitt [[AVR-GCC-Tutorial#Interne Pull-Up Widerstände|Interne Pull-Up Widerstände]]), welche insbesondere wie hier bei Tastern und ähnlichen Bauteilen (z.&nbsp;B. Drehgebern) statt externer Bauteile verwendet werden können. Interne Pull-Down-Widerstand sind nicht verfügbar und müssen daher in Form zusätzlicher Bauteile in die Schaltung eingefügt werden.<br />
<br />
==== Taster entprellen ====<br />
<br />
Siehe: ''[[Entprellung#Warteschleifen-Verfahren|Entprellung: Warteschleifen-Verfahren]]<br />
<br />
= Warteschleifen (delay.h) =<br />
<br />
Der Programmablauf kann verschiedene Arten von Wartefunktionen erfordern:<br />
<br />
* Warten im Sinn von Zeitvertrödeln<br />
* Warten auf einen bestimmten Zustand an den I/O-Pins<br />
* Warten auf einen bestimmten Zeitpunkt (siehe Timer)<br />
* Warten auf einen bestimmten Zählerstand (siehe Counter)<br />
<br />
Der einfachste Fall, das Zeitvertrödeln, kann in vielen Fällen und mit großer Genauigkeit anhand der avr-libc Bibliotheksfunktionen _delay_ms() und _delay_us() erledigt werden. Die Bibliotheksfunktionen sind einfachen Zählschleifen (Warteschleifen) vorzuziehen, da leere Zählschleifen ohne besondere Vorkehrungen sonst bei eingeschalteter Optimierung vom avr-gcc-Compiler wegoptimiert werden. Weiterhin sind die Bibliotheksfunktionen bereits darauf vorbereitet, die in F_CPU definierte Taktfrequenz zu verwenden. Außerdem sind die Funktionen der Bibliothek wirklich getestet.<br />
<br />
Einfach!? Schon, aber während gewartet wird, macht der µC nichts anderes mehr (abgesehen von möglicherweise auftretenden Interrupts, falls welche aktiviert sind). Die Wartefunktion blockiert den Programmablauf. Möchte man einerseits warten, um z.&nbsp;B. eine LED blinken zu lassen und gleichzeitig andere Aktionen ausführen z.&nbsp;B. weitere LED bedienen, sollten die Timer/Counter des AVR verwendet werden, siehe Artikel [[Multitasking]].<br />
<br />
Die Bibliotheksfunktionen funktionieren allerdings nur dann korrekt, wenn sie mit zur Übersetzungszeit (beim Compilieren) bekannten konstanten Werten aufgerufen werden. Der Quellcode muss mit eingeschalteter Optimierung übersetzt werden, sonst wird sehr viel Maschinencode erzeugt, und die Wartezeiten stimmen nicht mehr mit dem Parameter überein.<br />
<br />
Eine weitere Einschränkung liegt darin, daß sie möglicherweise länger warten, als erwartet, nämlich in dem Fall, daß Interrupts auftreten und die _delay...()-Funktion unterbrechen. Genau genommen warten diese nämlich nicht eine bestimmte Zeit, sondern verbrauchen eine bestimmte Anzahl von Prozessortakten. Die wiederum ist so bemessen, daß ohne Unterbrechung durch Interrupts die gewünschte Wartezeit erreicht wird.<br />
Wird das Warten aber durch eine oder mehrere ISR unterbrochen, die zusammen 1% Prozessorzeit verbrauchen, dann dauert das Warten etwa 1% länger. Bei 50% Last durch die ISR dauert das Warten doppelt solange wie gewünscht, bei 90% zehnmal solange...<br />
<br />
Abhängig von der Version der Bibliothek verhalten sich die Bibliotheksfunktionen etwas unterschiedlich.<br />
<br />
== avr-libc Versionen bis 1.6 ==<br />
<br />
Die Wartezeit der Funktion _delay_ms() ist auf 262,14ms/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 13,1ms warten. Die Wartezeit der Funktion _delay_us() ist auf 768us/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 38,4µs warten. Längere Wartezeiten müssen dann über einen mehrfachen Aufruf in einer Schleife gelöst werden.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.&nbsp;B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h> /* in älteren avr-libc Versionen <avr/delay.h> */ <br />
<br />
/*<br />
lange, variable Verzögerungszeit, Einheit in Millisekunden<br />
<br />
Die maximale Zeit pro Funktionsaufruf ist begrenzt auf <br />
262.14 ms / F_CPU in MHz (im Beispiel: <br />
262.1 / 3.6864 = max. 71 ms) <br />
<br />
Daher wird die kleine Warteschleife mehrfach aufgerufen,<br />
um auf eine längere Wartezeit zu kommen. Die zusätzliche <br />
Prüfung der Schleifenbedingung lässt die Wartezeit geringfügig<br />
ungenau werden (macht hier vielleicht 2-3ms aus).<br />
*/<br />
<br />
void long_delay(uint16_t ms)<br />
{<br />
for(; ms>0; ms--) _delay_ms(1);<br />
}<br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) // Endlosschleife<br />
{ <br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.&nbsp;B. angeschlossene LED<br />
long_delay(1000); // Eine Sekunde warten...<br />
}<br />
<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
== avr-libc Versionen ab 1.7 ==<br />
<br />
_delay_ms() kann mit einem Argument bis 6553,5 ms (= 6,5535 Sekunden) benutzt werden. Es ist nicht möglich, eine Variable als Argument zu übergeben. Wird die früher gültige Grenze von 262,14 ms/F_CPU (in MHz) überschritten, so arbeitet _delay_ms() einfach etwas ungenauer und zählt nur noch mit einer Auflösung von 1/10 ms. Eine Verzögerung von 1000,10 ms ließe sich nicht mehr von einer von 1000,19 ms unterscheiden. Ein Verlust, der sich im Allgemeinen verschmerzen lässt. Dem Programmierer wird keine Rückmeldung gegeben, dass die Funktion ggf. gröber arbeitet, d.h. wenn es darauf ankommt, bitte den Parameter wie bisher geschickt wählen.<br />
<br />
Die Funktion _delay_us() wurde ebenfalls erweitert. Wenn deren maximal als genau behandelbares Argument überschritten wird, benutzt diese intern _delay_ms(). Damit gelten in diesem Fall die _delay_ms() Einschränkungen.<br />
<br />
Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus, avr-libc ab Version 1.6<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#ifndef F_CPU<br />
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert <br />
(z.B. durch Übergabe als Parameter zum Compiler innerhalb <br />
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die<br />
"nachträgliche" Definition hinweist */<br />
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"<br />
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */<br />
#endif<br />
#include <util/delay.h><br />
<br />
int main( void )<br />
{<br />
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen<br />
<br />
while( 1 ) { // Endlosschleife<br />
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED<br />
_delay_ms(1000); // Eine Sekunde +/-1/10000 Sekunde warten...<br />
// funktioniert nicht mit Bibliotheken vor 1.6<br />
<br />
}<br />
return 0;<br />
}<br />
</syntaxhighlight><br />
<br />
Die _delay_ms() und die _delay_us aus '''avr-libc 1.7.0''' sind fehlerhaft. _delay_ms () läuft 4x schneller als erwartet. Abhilfe ist eine korrigierte Includedatei: [http://www.mikrocontroller.net/topic/196738#1943039]<br />
<br />
= Programmieren mit Interrupts =<br />
<br />
<div style="float:right; margin:2em;"><br />
[[Image:Interrupt Programme.gif]]<br />
</div><br />
Nachdem wir nun alles Wissenswerte für die serielle Programmerstellung<br />
gelernt haben nehmen wir jetzt ein völlig anderes Thema in Angriff, nämlich<br />
die Programmierung unter Zuhilfenahme der Interrupts des AVR.<br />
<br />
Tritt ein Interrupt auf, unterbricht (engl. interrupts) der Controller die Verarbeitung des Hauptprogramms und verzweigt zu einer Interruptroutine. Das Hauptprogramm wird also beim Eintreffen eines Interrupts unterbrochen, die Interruptroutine ausgeführt und danach erst wieder das Hauptprogramm an der Unterbrechungsstelle fortgesetzt (vgl. die Abbildung).<br />
<br />
Um Interrupts verarbeiten zu können, ist folgendes zu beachten:<br />
<br />
* Für jede aktivierte Interruptquelle ist eine Funktion zu programmieren, in der die beim Auftreten des jeweiligen Interrupts erforderlichen Verarbeitungsschritte enthalten sind. Für diese Funktion existieren verschiedene Bezeichnungen. Üblich sind die englischen Begriffe Interrupt-Handler oder Interrupt-Service-Routinen (ISR), man findet aber auch die Bezeichnungen Interruptverarbeitungs- oder -behandlungsroutine oder auch kurz Interruptroutine. Zum Beispiel wird üblicherweise in der ISR zur Verarbeitung des Empfangsinterrupts eines UARTs (UART-RX Interrupt) das empfangene Zeichen in einen Zwischenspeicher (FIFO-Buffer) kopiert, dessen Inhalt später von anderen Programmteilen geleert wird. Sofern der Zwischenspeicher ausreichend groß ist, geht also kein Zeichen verloren, auch wenn im Hauptprogramm zeitintensive Operationen durchgeführt werden.<br />
* Die benötigten Interrupts sind in den jeweiligen Funktionsbausteinen einzuschalten. Dies erfolgt über das jeweilige Aktivierungsbit (Interrupt Enable) in einem der Hardwareregister (z.B. RX(Complete)Interrupt Enable eines UARTs)<br />
* Sämtliche Interrupts werden über einen weiteren globalen Schalter aktiviert und deaktiviert. Zur Verarbeitung der Interrupts ist dieser Schalter zu aktivieren (sei(), siehe unten).<br />
<br />
Alle Punkte sind zu beachten. Fehlt z.B. die globale Aktivierung, werden Interruptroutinen auch dann nicht aufgerufen, wenn sie im Funktionsbaustein eingeschaltet sind und eine Behandlungsroutine verhanden ist.<br />
<br />
Siehe auch<br />
<br />
* [http://www.mikrocontroller.net/forum/read-1-235092.html#new Ausführlicher Thread im Forum]<br />
* Artikel [[Interrupt]]<br />
* Artikel [[Multitasking]]<br />
{{Clear}}<br />
<br />
== Anforderungen an Interrupt-Routinen ==<br />
<br />
Um unliebsamen Überraschungen vorzubeugen, sollten einige Grundregeln bei der Implementierung der Interruptroutinen beachtet werden. Interruptroutinen sollten möglichst kurz und schnell abarbeitbar sein, daraus folgt:<br />
<br />
* Keine umfangreichen Berechnungen innerhalb der Interruptroutine. (*)<br />
* Keine langen Programmschleifen.<br />
* Obwohl es möglich ist, während der Abarbeitung einer Interruptroutine andere oder sogar den gleichen Interrupt wieder zuzulassen, wird davon ohne genaue Kenntnis der internen Abläufe dringend abgeraten.<br />
<br />
Interruptroutinen (ISRs) sollten also möglichst kurz sein und keine Schleifen mit vielen Durchläufen enthalten. Längere Operationen können meist in einen "Interrupt-Teil" in einer ISR und einen "Arbeitsteil" im Hauptprogramm aufgetrennt werden. Z.B. Speichern des Zustands aller Eingänge im EEPROM in bestimmten Zeitabständen: ISR-Teil: Zeitvergleich (Timer,RTC) mit Logzeit/-intervall. Bei Übereinstimmung ein globales Flag setzen (volatile bei Flag-Deklaration nicht vergessen, s.u.). Dann im Hauptprogramm prüfen, ob das Flag gesetzt ist. Wenn ja: die Daten im EEPROM ablegen und Flag löschen.<br />
<br />
(*)<br />
Hinweis: <br />
Es gibt allerdings die seltene Situation, dass man gerade eingelesene<br />
ADC-Werte sofort verarbeiten muss. Besonders dann, wenn man mehrere Werte sehr<br />
schnell hintereinander bekommt. Dann bleibt einem nichts anderes übrig, als die<br />
Werte noch in der ISR zu verarbeiten. Kommt aber sehr selten vor und sollte<br />
durch geeignete Wahl des Systemtaktes bzw. Auswahl des Controllers vermieden werden!<br />
<br />
== Interrupt-Quellen ==<br />
<br />
Die folgenden Ereignisse können einen Interrupt auf einem AVR AT90S2313 auslösen, wobei die Reihenfolge der Auflistung auch die Priorität der Interrupts aufzeigt.<br />
<br />
* Reset<br />
* Externer Interrupt 0<br />
* Externer Interrupt 1<br />
* Timer/Counter 1 Capture Ereignis<br />
* Timer/Counter 1 Compare Match<br />
* Timer/Counter 1 Überlauf<br />
* Timer/Counter 0 Überlauf<br />
* UART Zeichen empfangen<br />
* UART Datenregister leer<br />
* UART Zeichen gesendet<br />
* Analoger Komparator<br />
<br />
Die Anzahl der möglichen Interruptquellen variiert zwischen den verschiedenen Microcontroller-Typen. Im Zweifel hilft ein Blick ins Datenblatt ("Interrupt Vectors").<br />
<br />
== Register ==<br />
<br />
Der AT90S2313 verfügt über 2 Register die mit den<br />
Interrupts zusammenhängen.<br />
<br />
{| class="wikitable"<br />
|- <br />
!width="10%"| GIMSK<br />
| '''G'''eneral '''I'''nterrupt '''M'''a'''sk''' Register.<br /><br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit <br />
| 7 || 6|| 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INT1''' || '''INT0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INT1''' (External '''Int'''errupt Request '''1''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT1'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
'''INT0''' (External '''Int'''errupt Request '''0''' Enable)<br />
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT0'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.<br />
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.<br />
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.<br />
<br />
|- <br />
! GIFR<br />
| '''G'''eneral '''I'''nterrupt '''F'''lag '''R'''egister.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''INTF1''' || '''INTF0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''<br />
|- <br />
! R/W<br />
| R/W || R/W || R || R || R || R || R || R<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''INTF1''' (External '''Int'''errupt Flag '''1''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT1'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
<br />
'''INTF0''' (External '''Int'''errupt Flag '''0''')<br />
:Dieses Bit wird gesetzt, wenn am '''INT0'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.<br />
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.<br />
|- <br />
! MCUCR<br />
| '''MCU''' '''C'''ontrol '''R'''egister.<br />
<br />
Das MCU Control Register enthält Kontrollbits für allgemeine MCU-Funktionen.<br />
<br />
{| class="wikitable" style="text-align:center"<br />
|- <br />
! Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|- <br />
! Name<br />
| '''-'''|| '''-'''|| '''SE'''|| '''SM'''|| '''ISC11'''|| '''ISC10'''|| '''ISC01'''|| '''ISC00'''<br />
|- <br />
! R/W<br />
| R || R || R/W || R/W || R/W || R/W || R/W || R/W<br />
|- <br />
! Initialwert<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
<br />
|}<br />
<br />
'''SE''' ('''S'''leep '''E'''nable)<br />
:Dieses Bit muss gesetzt sein, um den Controller mit dem '''SLEEP'''-Befehl in den Schlafzustand versetzen zu können.<br />
:Um den Schlafmodus nicht irrtümlich einzuschalten, wird empfohlen, das Bit erst unmittelbar vor Ausführung des '''SLEEP'''-Befehls zu setzen.<br />
<br />
'''SM''' ('''S'''leep '''M'''ode)<br />
:Dieses Bit bestimmt über den Schlafmodus.<br />
:Ist das Bit gelöscht, so wird der '''Idle'''-Modus ausgeführt. Ist das Bit gesetzt, so wird der '''Power-Down'''-Modus ausgeführt. (für andere AVR Controller siehe Abschnitt "Sleep-Mode")<br />
<br />
'''ISC11''', '''ISC10''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''1''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT1'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
!width="10%"| ISC11 ||width="10%"| ISC10 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT1''' erzeugt einen Interrupt.<br />
<br />
Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT1''' erzeugt einen Interrupt.<br />
|}<br />
<br />
'''ISC01''', '''ISC00''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''0''' Bits)<br />
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT0'''-Pin ausgewertet wird.<br />
<br />
:{| class="wikitable"<br />
|- <br />
!width="10%"| ISC01 ||width="10%"| ISC00 || Bedeutung<br />
|- <br />
| align="center" | 0<br />
| align="center" | 0<br />
| Low Level an '''INT0''' erzeugt einen Interrupt.<br />
<br />
Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.<br />
|- <br />
| align="center" | 0<br />
| align="center" | 1<br />
| Reserviert<br />
|- <br />
| align="center" | 1<br />
| align="center" | 0<br />
| Die fallende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|- <br />
| align="center" | 1<br />
| align="center" | 1<br />
| Die steigende Flanke an '''INT0''' erzeugt einen Interrupt.<br />
|}<br />
<br />
|}<br />
<br />
== Allgemeines über die Interrupt-Abarbeitung ==<br />
<br />
Wenn ein Interrupt eintrifft, wird automatisch das '''Global Interrupt Enable''' Bit im Status Register '''SREG''' gelöscht und alle weiteren Interrupts unterbunden. Dieses wird automatisch wieder gesetzt, wenn die Interruptroutine beendet wird. Wenn in der Zwischenzeit weitere Interrupts eintreffen, werden die zugehörigen Interrupt-Bits gesetzt und die Interrupts bei Beendigung der laufenden Interrupt-Routine in der Reihenfolge ihrer Priorität ausgeführt. Dies kann<br />
eigentlich nur dann zu Problemen führen, wenn ein hoch priorisierter Interrupt ständig und in kurzer Folge auftritt. Dieser sperrt dann möglicherweise alle anderen Interrupts mit niedrigerer Priorität. Dies ist einer der Gründe, weshalb die Interrupt-Routinen sehr kurz gehalten werden sollen. Es ist möglich das GIE-Bit in der ISR zu setzen und so schon wieder weitere Interrupts zuzulassen - allerdings sollte man damit vorsichtig sein und genau wissen was man damit macht. Kritisch wird es vor allem wenn der gleiche Interrupt noch einmal kommt, bevor die ISR abgearbeitet ist. <br />
<br />
<!-- === Das Status-Register ===<br />
<br />
Es gilt auch zu beachten, dass das Status-Register während der Abarbeitung einer Interruptroutine nicht automatisch gesichert wird. Falls notwendig, muss dies vom Programmierer selber vorgesehen werden. --><br />
<br />
== Interrupts mit avr-gcc ==<br />
<br />
<!-- ''Anmerkung eines Nutzers: Ich habe mir das Thema hier angearbeitet und hatte am Anfang starke Probleme: Jeder Interrupt muss nochmals einzeln aktiviert werden. Es reicht nicht nur per ''sei()'' die Interrupts global zu aktiveren.'' - mthomas: Hoffentlich duch die modifizerte Einleitung etwas offensichtlicher erläutert. Ansonsten bitte per Eintrag auf die Diskussionseite nochmals melden) --> <br />
<!-- Selbstverständlich können alle interruptspezifischen Registerzugriffe wie gewohnt über I/O-Adressierung vorgenommen werden. Etwas einfacher geht es jedoch, wenn wir die vom Compiler zur Verfügung gestellten Mittel einsetzen.--><br />
Funktionen zur Interrupt-Verarbeitung werden in den Includedateien ''interrupt.h'' der avr-libc zur Verfügung gestellt (bei älterem Quellcode zusätzlich ''signal.h'').<br />
<br />
<syntaxhighlight lang="c"><br />
// fuer sei(), cli() und ISR():<br />
#include <avr/interrupt.h><br />
</syntaxhighlight><br />
<br />
Das Makro '''sei()''' schaltet die Interrupts ein. Eigentlich wird nichts anderes gemacht, als das '''Global Interrupt Enable''' Bit im Status Register gesetzt.<br />
<br />
<syntaxhighlight lang="c"><br />
sei();<br />
</syntaxhighlight><br />
<br />
Das Makro '''cli()''' schaltet die Interrupts aus, oder anders gesagt, das '''Global Interrupt Enable''' Bit im Status Register wird gelöscht.<br />
<br />
<syntaxhighlight lang="c"><br />
cli();<br />
</syntaxhighlight><br />
<br />
Oft steht man vor der Aufgabe, dass eine Codesequenz nicht unterbrochen werden darf. Es liegt dann nahe, zu Beginn dieser Sequenz ein cli() und am Ende ein sei() einzufügen. Dies ist jedoch ungünstig, wenn die Interrupts vor Aufruf der Sequenz deaktiviert waren und danach auch weiterhin deaktiviert bleiben sollen. Ein sei() würde ungeachtet des vorherigen Zustands die Interrupts aktivieren, was zu unerwünschten Seiteneffekten führen kann. Die aus dem folgenden Beispiel ersichtliche Vorgehensweise ist in solchen Fällen vorzuziehen:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <inttypes.h><br />
<br />
//...<br />
<br />
void NichtUnterbrechenBitte(void)<br />
{<br />
uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister<br />
<br />
tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) sichern<br />
cli(); // Interrupts global deaktivieren<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
/* Beispiel Anfang<br />
JTAG-Interface eines ATmega16 per Software deaktivieren <br />
und damit die JTAG-Pins an PORTC für "general I/O" nutzbar machen<br />
ohne die JTAG-Fuse-Bit zu aendern. Dazu ist eine "timed sequence"<br />
einzuhalten (vgl Datenblatt ATmega16, Stand 10/04, S. 229): <br />
Das JTD-Bit muss zweimal innerhalb von 4 Taktzyklen geschrieben <br />
werden. Ein Interrupt zwischen den beiden Schreibzugriffen wuerde <br />
die erforderliche Sequenz "brechen", das JTAG-Interface bliebe<br />
weiterhin aktiv und die IO-Pins weiterhin für JTAG reserviert. */<br />
<br />
MCUCSR |= (1<<JTD);<br />
MCUCSR |= (1<<JTD); // 2 mal in Folge ,vgl. Datenblatt fuer mehr Information<br />
<br />
/* Beispiel Ende */<br />
<br />
SREG = tmp_sreg; // Status-Register wieder herstellen <br />
// somit auch das I-Flag auf gesicherten Zustand setzen<br />
}<br />
<br />
void NichtSoGut(void)<br />
{<br />
cli();<br />
<br />
/* hier "unterbrechnungsfreier" Code */<br />
<br />
sei();<br />
}<br />
<br />
<br />
int main(void)<br />
{<br />
//...<br />
<br />
cli(); <br />
// Interrupts global deaktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// auch nach Aufruf der Funktion deaktiviert<br />
<br />
sei();<br />
// Interrupts global aktiviert <br />
<br />
NichtUnterbrechenBitte();<br />
// weiterhin aktiviert<br />
//...<br />
<br />
/* Verdeutlichung der unguenstigen Vorgehensweise mit cli/sei: */<br />
cli(); <br />
// Interrupts jetzt global deaktiviert <br />
<br />
NichtSoGut();<br />
// nach Aufruf der Funktion sind Interrupts global aktiviert <br />
// dies ist mglw. ungewollt!<br />
//...<br />
<br />
}<br />
</syntaxhighlight><br />
<br />
<br />
<!-- mt: besser so nicht(?), lieber "datenblattkonform"<br />
<br />
<font face="Courier New">'''timer_enable_int (unsigned char ints);<br /><br />
'''</font>Schaltet Timerbezogene Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle<br />
Timerinterrupts ausgeschaltet, ansonsten muss in '''ints''' angegeben werden,<br />
welche Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">timer_enable_int (1 << TOIE1));<br /><br />
</font>'''Achtung: Wenn ein Timerinterrupt eingeschaltet wird während ein<br />
anderer Timerinterrupt bereits läuft, dann müssen beide Bits angegeben werden<br />
sonst wird der andere Timerinterrupt versehentlich ausgeschaltet.<br />
<br />
<font face="Courier New">'''enable_external_int (unsigned char ints);<br /><br />
'''</font>Schaltet die externen Interrupts ein bzw. aus.<br /><br />
Wenn als Argument '''ints''' der Wert 0 übergeben wird so werden alle externen<br />
Interrrups ausgeschaltet, ansonsten muss in '''ints''' angegeben werden, welche<br />
Interrupts zu aktivieren sind. Dabei müssen einfach die entsprechend zu<br />
setzenden Bits definiert werden.<br /><br />
Beispiel: '''<font face="Courier New">enable_external_int ((1<<br />
</font>'''Schaltet die externen Interrupts 0 und 1 ein.<br />
<br />
Nachdem nun die Interrupts aktiviert sind, braucht es selbstverständlich noch den auszuführenden Code, der ablaufen soll, wenn ein Interrupt eintrifft.<br />
--><br />
Zu den aktivierten Interrupts ist eine Funktion zu programmieren, deren Code aufgerufen wird, wenn der betreffende Interrupt auftritt (Interrupt-Handler, Interrupt-Service-Routine). Dazu existiert die Definition (ein Makro) '''ISR'''.<br />
<br />
=== ISR ===<br />
<br />
(''ISR()'' ersetzt bei neueren Versionen der avr-libc ''SIGNAL()''. SIGNAL sollte nicht mehr genutzt werden, zur Portierung von SIGNAL nach ISR siehe den [[AVR-GCC-Tutorial#Anhang|Anhang]].)<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
//...<br />
ISR(Vectorname) /* vormals: SIGNAL(siglabel) dabei Vectorname != siglabel ! */<br />
{<br />
/* Interrupt Code */<br />
}<br />
</syntaxhighlight><br />
<br />
Mit ''ISR'' wird eine Funktion für die Bearbeitung eines Interrupts eingeleitet. Als Argument muss dabei die Benennung des entsprechenden Interruptvektors angegeben werden. Diese sind in den jeweiligen Includedateien IOxxxx.h zu finden. Die Bezeichnung entspricht dem Namen aus dem Datenblatt, bei dem die Leerzeichen durch Unterstriche ersetzt sind und ein ''_vect'' angehängt ist.<br />
<br />
Als Beispiel ein Ausschnitt aus der Datei für den ATmega8 (bei WinAVR Standardinstallation in C:\WinAVR\avr\include\avr\iom8.h) in der neben den aktuellen Namen für ''ISR'' (*_vect) noch die Bezeichnungen für das inzwischen nicht mehr aktuelle ''SIGNAL'' (SIG_*) enthalten sind.<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
/* $Id: iom8.h,v 1.13 2005/10/30 22:11:23 joerg_wunsch Exp $ */<br />
<br />
/* avr/iom8.h - definitions for ATmega8 */<br />
//...<br />
<br />
/* Interrupt vectors */<br />
<br />
/* External Interrupt Request 0 */<br />
#define INT0_vect _VECTOR(1)<br />
#define SIG_INTERRUPT0 _VECTOR(1)<br />
<br />
/* External Interrupt Request 1 */<br />
#define INT1_vect _VECTOR(2)<br />
#define SIG_INTERRUPT1 _VECTOR(2)<br />
<br />
/* Timer/Counter2 Compare Match */<br />
#define TIMER2_COMP_vect _VECTOR(3)<br />
#define SIG_OUTPUT_COMPARE2 _VECTOR(3)<br />
<br />
/* Timer/Counter2 Overflow */<br />
#define TIMER2_OVF_vect _VECTOR(4)<br />
#define SIG_OVERFLOW2 _VECTOR(4)<br />
<br />
/* Timer/Counter1 Capture Event */<br />
#define TIMER1_CAPT_vect _VECTOR(5)<br />
#define SIG_INPUT_CAPTURE1 _VECTOR(5)<br />
<br />
/* Timer/Counter1 Compare Match A */<br />
#define TIMER1_COMPA_vect _VECTOR(6)<br />
#define SIG_OUTPUT_COMPARE1A _VECTOR(6)<br />
<br />
/* Timer/Counter1 Compare Match B */<br />
#define TIMER1_COMPB_vect _VECTOR(7)<br />
#define SIG_OUTPUT_COMPARE1B _VECTOR(7)<br />
<br />
//...<br />
</syntaxhighlight><br />
<br />
<!--Vor Nutzung von SIGNAL muss ebenfalls die Header-Datei signal.h eingebunden werden.--> <br />
Mögliche Funktionsrümpfe für Interruptfunktionen sind zum Beispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
/* veraltet: #include <avr/signal.h> */<br />
<br />
ISR(INT0_vect) /* veraltet: SIGNAL(SIG_INTERRUPT0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(TIMER0_OVF_vect) /* veraltet: SIGNAL(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
ISR(USART_RXC_vect) /* veraltet: SIGNAL(SIG_UART_RECV) */<br />
{<br />
/* Interrupt Code */<br />
}<br />
<br />
// und so weiter und so fort...<br />
</syntaxhighlight><br />
<br />
Auf die korrekte Schreibweise der Vektorbezeichnung ist zu achten. Der gcc-Compiler prüft erst ab Version 4.x, ob ein Signal/Interrupt der angegebenen Bezeichnung tatsächlich in der Includedatei definiert ist und gibt andernfalls eine Warnung aus. Bei WinAVR (ab 2/2005) wurde die Überprüfung auch in den mitgelieferten Compiler der Version 3.x integriert. Aus dem gcc-Quellcode Version 3.x selbst erstellte Compiler enthalten die Prüfung nicht (vgl. [[AVR-GCC]]). <br />
<br />
Während der Ausführung der Funktion sind alle weiteren Interrupts automatisch gesperrt. Beim Verlassen der Funktion werden die Interrupts wieder zugelassen.<br />
<br />
Sollte während der Abarbeitung der Interruptroutine ein weiterer Interrupt (gleiche oder andere Interruptquelle) auftreten, so wird das entsprechende Bit im zugeordneten Interrupt Flag Register gesetzt und die entsprechende Interruptroutine automatisch nach dem Beenden der aktuellen Funktion aufgerufen.<br />
<br />
Ein Problem ergibt sich eigentlich nur dann, wenn während der Abarbeitung der aktuellen Interruptroutine mehrere gleichartige Interrupts auftreten. Die entsprechende Interruptroutine wird im Nachhinein zwar aufgerufen jedoch wissen wir nicht, ob nun der entsprechende Interrupt einmal, zweimal oder gar noch öfter aufgetreten ist. Deshalb soll hier noch einmal betont werden, dass Interruptroutinen so schnell wie nur irgend möglich wieder verlassen werden sollten.<br />
<br />
=== Unterbrechbare Interruptroutinen ===<br />
<br />
"Faustregel": im Zweifel '''ISR'''. Die nachfolgend beschriebene Methode nur dann verwenden, wenn man sich über die unterschiedliche Funktionsweise im Klaren ist.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
<br />
ISR(XXX,ISR_NOBLOCK) /* veraltet: INTERRUPT(SIG_OVERFLOW0) */<br />
{<br />
/* Interrupt-Code */<br />
}<br />
</syntaxhighlight><br />
<br />
Hierbei steht XXX für den oben beschriebenen Namen des Vektors (also z.&nbsp;B. ''TIMER0_OVF_vect''). Der Unterschied im Vergleich zu einer herkömmlichen ISR ist, dass hier beim Aufrufen der Funktion das '''Global Enable Interrupt''' Bit durch Einfügen einer SEI-Anweisung direkt wieder gesetzt und somit alle Interrupts zugelassen werden &ndash; auch XXX-Interrupts. <br />
<br />
Bei unsachgemässer Handhabung kann dies zu erheblichen Problemen durch Rekursion wie einem Stack-Overflow oder anderen unerwarteten Effekten führen und sollte wirklich nur dann eingesetzt werden, wenn man sich sicher ist, das Ganze auch im Griff zu haben.<br />
<br />
Insbesondere sollte möglichst am ISR-Anfang die auslösende IRQ-Quelle deaktiviert und erst am Ende der ISR wieder aktiviert werden. Robuster als die Verwendung einer NOBLOCK-ISR ist daher folgender ISR-Aufbau:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/interrupt.h><br />
<br />
ISR (XXX) <br />
{<br />
// Implementiere die ISR ohne zunaechst weitere IRQs zuzulassen<br />
<br />
<<Deaktiviere die XXX-IRQ>><br />
<br />
// Erlaube alle Interrupts (ausser XXX)<br />
sei();<br />
<br />
//... Code ...<br />
<br />
// IRQs global deaktivieren um die XXX-IRQ wieder gefahrlos <br />
// aktivieren zu koennen<br />
cli();<br />
<br />
<<Aktiviere die XXX-IRQ>><br />
}<br />
</syntaxhighlight><br />
Auf diese Weise kann sich die XXX-IRQ nicht selbst unterbrechen, was zu einer Art Endlosschleife führen würde.<br />
<br />
Siehe auch: Hinweise in [[AVR-GCC]]<br />
<br />
siehe dazu: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html<br />
<br />
== Datenaustausch mit Interrupt-Routinen ==<br />
<br />
Variablen, die sowohl in Interrupt-Routinen (ISR = Interrupt Service Routine(s)) als auch vom übrigen Programmcode geschrieben oder gelesen werden, müssen mit einem '''volatile''' deklariert werden. Damit wird dem Compiler mitgeteilt, dass der Inhalt der Variablen vor jedem Lesezugriff aus dem Speicher gelesen und nach jedem Schreibzugriff in den Speicher geschrieben wird. Ansonsten könnte der Compiler den Code so optimieren, dass der Wert der Variablen nur in Prozessorregistern zwischengespeichert wird, die nichts von der Änderung woanders mitbekommen.<br />
<br />
Zur Veranschaulichung ein Codefragment für eine Tastenentprellung mit Erkennung einer "lange gedrückten" Taste.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <stdint.h><br />
//...<br />
<br />
// Schwellwerte<br />
// Entprellung: <br />
#define CNTDEBOUNCE 10<br />
// "lange gedrueckt:"<br />
#define CNTREPEAT 200<br />
<br />
// hier z.&nbsp;B. Taste an Pin2 PortA "active low" = 0 wenn gedrueckt<br />
#define KEY_PIN PINA<br />
#define KEY_PINNO PA2<br />
<br />
// beachte: volatile! <br />
volatile uint8_t gKeyCounter;<br />
<br />
// Timer-Compare Interrupt ISR, wird z.B. alle 10ms ausgefuehrt<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
// hier wird gKeyCounter veraendert. Die übrigen<br />
// Programmteile müssen diese Aenderung "sehen":<br />
// volatile -> aktuellen Wert immer in den Speicher schreiben<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
}<br />
else {<br />
gKeyCounter = 0;<br />
}<br />
}<br />
<br />
//...<br />
<br />
int main(void)<br />
{<br />
//...<br />
/* hier: Initialisierung der Ports und des Timer-Interrupts */<br />
//... <br />
// hier wird auf gKeyCounter zugegriffen. Dazu muss der in der<br />
// ISR geschriebene Wert bekannt sein:<br />
// volatile -> aktuellen Wert immer aus dem Speicher lesen<br />
if ( gKeyCounter > CNTDEBOUNCE ) { // Taste mind. 10*10 ms "prellfrei"<br />
if (gKeyCounter == CNTREPEAT) {<br />
/* hier: Code fuer "Taste lange gedrueckt" */<br />
}<br />
else {<br />
/* hier: Code fuer "Taste kurz gedrueckt" */<br />
}<br />
}<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Wird innerhalb einer ISR mehrfach auf eine mit volatile deklarierte Variable zugegriffen, wirkt sich dies ungünstig auf die Verarbeitungsgeschwindigkeit aus, da bei jedem Zugriff mit dem Speicherinhalt abgeglichen wird. Da bei AVR-Controllern ''innerhalb'' einer ISR keine Unterbrechungen zu erwarten sind, bietet es sich an, einen Zwischenspeicher in Form einer lokalen Variable zu verwenden, deren Inhalt zu Beginn und am Ende mit dem der volatile Variable synchronisiert wird. Lokale Variable werden bei eingeschalteter Optimierung mit hoher Wahrscheinlichkeit in Prozessorregistern verwaltet und der Zugriff darauf ist daher nur mit wenigen internen Operationen verbunden. Die ISR aus dem vorherigen Beispiel lässt sich so optimieren:<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter; // Uebernahme in lokale Arbeitsvariable<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
if (tmp_kc < CNTREPEAT) {<br />
tmp_kc++;<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc; // Zurueckschreiben<br />
}<br />
//...<br />
</syntaxhighlight><br />
<br />
Zum Vergleich die Disassemblies (Ausschnitte der "lss-Dateien", compiliert für ATmega162) im Anschluss. Man erkennt den viermaligen Zugriff auf die Speicheraddresse von ''gKeyCounter'' (hier 0x032A) in der ISR ohne "Cache"-Variable und den zweimaligen Zugriff in der Variante mit Zwischenspeicher. Im Beispiel ist der Vorteil gering, bei komplexeren Routinen kann die Zwischenspeicherung in lokalen Variablen jedoch zu deutlicheren Verbesserungen führen.<br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
876: ca 99 sbic 0x19, 2 ; 25<br />
878: 0a c0 rjmp .+20 ; 0x88e <__vector_13+0x24><br />
if (gKeyCounter < CNTREPEAT) gKeyCounter++;<br />
87a: 80 91 2a 03 lds r24, 0x032A<br />
87e: 88 3c cpi r24, 0xC8 ; 200 <br />
880: 40 f4 brcc .+16 ; 0x892 <__vector_13+0x28><br />
882: 80 91 2a 03 lds r24, 0x032A<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 02 c0 rjmp .+4 ; 0x892 <__vector_13+0x28><br />
}<br />
else {<br />
gKeyCounter = 0;<br />
88e: 10 92 2a 03 sts 0x032A, r1<br />
892: 8f 91 pop r24<br />
894: 0f 90 pop r0<br />
896: 0f be out 0x3f, r0 ; 63<br />
898: 0f 90 pop r0<br />
89a: 1f 90 pop r1<br />
89c: 18 95 reti<br />
</pre><br />
<br />
<pre><br />
ISR(TIMER1_COMPA_vect)<br />
{<br />
86a: 1f 92 push r1<br />
86c: 0f 92 push r0<br />
86e: 0f b6 in r0, 0x3f ; 63<br />
870: 0f 92 push r0<br />
872: 11 24 eor r1, r1<br />
874: 8f 93 push r24<br />
uint8_t tmp_kc;<br />
<br />
tmp_kc = gKeyCounter;<br />
876: 80 91 2a 03 lds r24, 0x032A<br />
<br />
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {<br />
87a: ca 9b sbis 0x19, 2 ; 25<br />
87c: 02 c0 rjmp .+4 ; 0x882 <__vector_13+0x18><br />
87e: 80 e0 ldi r24, 0x00 ; 0<br />
880: 03 c0 rjmp .+6 ; 0x888 <__vector_13+0x1e><br />
if (tmp_kc < CNTREPEAT) {<br />
882: 88 3c cpi r24, 0xC8 ; 200<br />
884: 08 f4 brcc .+2 ; 0x888 <__vector_13+0x1e><br />
tmp_kc++;<br />
886: 8f 5f subi r24, 0xFF ; 255<br />
}<br />
}<br />
else {<br />
tmp_kc = 0;<br />
}<br />
<br />
gKeyCounter = tmp_kc;<br />
888: 80 93 2a 03 sts 0x032A, r24<br />
88c: 8f 91 pop r24<br />
88e: 0f 90 pop r0<br />
890: 0f be out 0x3f, r0 ; 63<br />
892: 0f 90 pop r0<br />
894: 1f 90 pop r1<br />
896: 18 95 reti<br />
</pre><br />
<br />
=== volatile und Pointer ===<br />
<br />
Bei '''volatile''' in Verbindung mit Pointern ist zu beachten, ob der Pointer selbst oder die Variable, auf die der Pointer zeigt, '''volatile''' ist.<br />
<br />
<syntaxhighlight lang="c"><br />
volatile uint8_t *a; // das Ziel von a ist volatile<br />
<br />
uint8_t *volatile a; // a selbst ist volatile<br />
</syntaxhighlight><br />
<br />
Falls der Pointer volatile ist (zweiter Fall im Beispiel), ist zu beachten, dass der Wert des Pointers, also eine Speicheradresse, intern in mehr als einem Byte verwaltet wird. Lese- und Schreibzugriffe im Hauptprogramm (außerhalb von Interrupt-Routinen) sind daher so zu implementieren, dass alle Teilbytes der Adresse konsistent bleiben, vgl. dazu den folgenden Abschnitt.<br />
<br />
=== Variablen größer 1 Byte ===<br />
<br />
Bei Variablen größer ein Byte, auf die in Interrupt-Routinen und im Hauptprogramm zugegriffen wird, muss darauf geachtet werden, dass die Zugriffe auf die einzelnen Bytes außerhalb der ISR nicht durch einen Interrupt unterbrochen werden. (Allgemeinplatz: AVRs sind 8-bit Controller). Zur Veranschaulichung ein Codefragment:<br />
<br />
<syntaxhighlight lang="c"><br />
//...<br />
volatile uint16_t gMyCounter16bit;<br />
//...<br />
ISR(...)<br />
{<br />
//...<br />
gMyCounter16Bit++;<br />
//...<br />
}<br />
<br />
int main(void)<br />
{<br />
uint16_t tmpCnt;<br />
//...<br />
// nicht gut: Mglw. hier ein Fehler, wenn ein Byte von MyCounter <br />
// schon in tmpCnt kopiert ist aber vor dem Kopieren des zweiten Bytes <br />
// ein Interrupt auftritt, der den Inhalt von MyCounter verändert.<br />
tmpCnt = gMyCounter16bit; <br />
<br />
<br />
// besser: Änderungen "außerhalb" verhindern -> alle "Teilbytes"<br />
// bleiben konsistent<br />
cli(); // Interrupts deaktivieren<br />
tmpCnt = gMyCounter16Bit;<br />
sei(); // wieder aktivieren<br />
<br />
// oder: vorheriger Status des globalen Interrupt-Flags bleibt erhalten<br />
uint8_t sreg_tmp;<br />
sreg_tmp = SREG; /* Sichern */<br />
cli()<br />
tmpCnt = gMyCounter16Bit;<br />
SREG = sreg_tmp; /* Wiederherstellen */<br />
<br />
// oder: mehrfach lesen, bis man konsistente Daten hat<br />
uint16_t count1 = gMyCounter16Bit;<br />
uint16_t count2 = gMyCounter16Bit;<br />
while (count1 != count2) {<br />
count1 = count2;<br />
count2 = gMyCounter16Bit;<br />
}<br />
tmpCnt = count1;<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Die avr-libc bietet ab Version 1.6.0(?) einige Hilfsfunktionen/Makros, mit der im Beispiel oben gezeigten Funktionalität, die zusätzlich auch sogenannte [http://en.wikipedia.org/wiki/Memory_barrier memory barriers] beinhalten. Diese stehen nach #include <util/atomic.h> zur Verfügung.<br />
<syntaxhighlight lang="c"><br />
//...<br />
#include <util/atomic.h><br />
//...<br />
<br />
// analog zu cli, Zugriff, sei:<br />
ATOMIC_BLOCK(ATOMIC_FORCEON) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
// oder:<br />
<br />
// analog zu Sicherung des SREG, cli, Zugriff und Zurückschreiben des SREG:<br />
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {<br />
tmpCnt = gMyCounter16Bit;<br />
}<br />
<br />
//...<br />
</syntaxhighlight><br />
<br />
* siehe auch [http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Dokumentation der avr-libc zu atomic.h]<br />
<br />
== Interrupt-Routinen und Registerzugriffe ==<br />
<br />
Falls Register sowohl im Hauptprogramm als auch in Interrupt-Routinen verändert werden, ist darauf zu achten, dass diese Zugriffe sich nicht überlappen. Nur wenige Anweisungen lassen sich in sogenannte "atomare" Zugriffe übersetzen, die nicht von Interrupt-Routinen unterbrochen werden können. <br />
<br />
Zur Veranschaulichung eine Anweisung, bei der ein Bit und im Anschluss drei Bits in einem Register gesetzt werden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
<br />
int main(void)<br />
{<br />
//...<br />
PORTA |= (1<<PA0);<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
//...<br />
}<br />
</syntaxhighlight><br />
<br />
Der Compiler übersetzt diese Anweisungen für einen ATmega128 bei Optimierungsstufe "S" nach:<br />
<br />
<div class="code"><pre><br />
...<br />
PORTA |= (1<<PA0);<br />
d2: d8 9a sbi 0x1b, 0 ; 27 (a)<br />
<br />
PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);<br />
d4: 8b b3 in r24, 0x1b ; 27 (b)<br />
d6: 8c 61 ori r24, 0x1C ; 28 (c)<br />
d8: 8b bb out 0x1b, r24 ; 27 (d)<br />
...<br />
</pre></div><br />
<br />
Das Setzen des einzelnen Bits wird bei eingeschalteter Optimierung für Register im unteren Speicherbereich in eine einzige Assembler-Anweisung (sbi) übersetzt und ist nicht anfällig für Unterbrechungen durch Interrupts. Die Anweisung zum Setzen von drei Bits wird jedoch in drei abhängige Assembler-Anweisungen übersetzt und bietet damit zwei "Angriffspunkte" für Unterbrechungen. Eine Interrupt-Routine könnte nach dem Laden des Ausgangszustands in den Zwischenspeicher (hier Register 24) den Wert des Registers ändern, z.&nbsp;B. ein Bit löschen. Damit würde der Zwischenspeicher nicht mehr mit dem tatsächlichen Zustand übereinstimmen aber dennoch nach der Bitoperation (hier ori) in das Register zurückgeschrieben. <br />
<br />
Beispiel: PORTA sei anfangs 0b00000000. Die erste Anweisung (a) setzt Bit 0 auf '''1''', PORTA ist danach 0b0000000'''1'''. Nun wird im ersten Teil der zweiten Anweisung der Portzustand in ein Register eingelesen (b). Unmittelbar darauf (vor (c)) "feuert" ein Interrupt, in dessen Interrupt-Routine Bit 0 von PORTA gelöscht wird. Nach Verlassen der Interrupt-Routine hat PORTA den Wert 0b00000000. In den beiden noch folgenden Anweisungen des Hauptprogramms wird nun der zwischengespeicherte "alte" Zustand 0b00000001 mit 0b00011100 logisch-'''ODER'''-verknüft (c) und das Ergebnis 0b00011101 in PortA geschrieben (d). Obwohl zwischenzeitlich Bit 0 gelöscht wurde, ist es nach (d) wieder gesetzt. <br />
<br />
Lösungsmöglichkeiten:<br />
* Register ohne besondere Vorkehrungen nicht in Interruptroutinen ''und'' im Hauptprogramm verändern.<br />
* Interrupts vor Veränderungen in Registern, die auch in ISRs verändert werden, deaktivieren ("cli").<br />
* Bits einzeln löschen oder setzen. sbi und cbi können nicht unterbrochen werden. Vorsicht: nur Register im unteren Speicherbereich sind mittels sbi/cbi ansprechbar. Der Compiler kann nur für diese sbi/cbi-Anweisungen generieren. Für Register außerhalb dieses Adressbereichs ("Memory-Mapped"-Register) werden auch zur Manipulation einzelner Bits abhängige Anweisungen erzeugt (lds,...,sts).<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Frequently asked Questions/Fragen Nr. 1 und 8. (Stand: avr-libc Vers. 1.0.4)<br />
<br />
== Interruptflags löschen ==<br />
<br />
Beim Löschen von Interruptflags haben AVRs eine Besonderheit, die auch im Datenblatt beschrieben ist: Es wird zum Löschen eine 1 in das betreffende Bit geschrieben. <br />
<br />
Hinweis:<br /><br />
Bei Registern mit mehreren Interrupt-Flag-Bits (wie die Timer Interrupt Flag Register) '''nicht''' die übliche bitweise VerODERung nehmen, sondern eine direkte Zuweisung machen. Da sonst weitere Flags, als nur das gewünschte, ebenfalls gelöscht werden könnten.<br /><br />
([http://www.mikrocontroller.net/topic/171148#1640133 Erklärung]).<br />
<br />
== Was macht das Hauptprogramm? ==<br />
<br />
Im einfachsten (Ausnahme-)Fall gar nichts mehr. Es ist also durchaus denkbar, ein Programm zu schreiben, welches in der main-Funktion lediglich noch die Interrupts aktiviert und dann in einer Endlosschleife verharrt. Sämtliche Funktionen werden dann in den ISRs abgearbeitet. Diese Vorgehensweise ist jedoch bei den <i>meisten</i> Anwendungen schlecht: man verschenkt eine Verarbeitungsebene und hat außerdem möglicherweise Probleme durch Interruptroutinen, die zu viel Verarbeitungszeit benötigen. Für <i>wenige</i> Anwendungen ist diese Vorgehensweise jedoch perfekt: Siehe nächster Abschnitt „Sleep“.<br />
<br />
Normalerweise wird man in den Interruptroutinen nur die bei Auftreten des jeweiligen Interruptereignisses unbedingt notwendigen Operationen ausführen lassen. Alle weniger kritischen Aufgaben werden dann im Hauptprogramm abgearbeitet.<br />
<br />
* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Interrupts and Signals<br />
<br />
= Sleep-Modes =<br />
<br />
AVR Controller verfügen über eine Reihe von sogenannten [[Sleep Mode |''Sleep-Modes'']] ("Schlaf-Modi"). Diese ermöglichen es, Teile des Controllers abzuschalten. Zum Einen kann damit besonders bei Batteriebetrieb Strom gespart werden, zum Anderen können Komponenten des Controllers deaktiviert werden, die die Genauigkeit des Analog-Digital-Wandlers bzw. des Analog-Comparators negativ beeinflussen. Der Controller wird durch Interrupts aus dem Schlaf geweckt. Welche Interrupts den jeweiligen Schlafmodus beenden, ist einer Tabelle im Datenblatt des jeweiligen Controllers zu entnehmen.<br />
Die Funktionen (eigentlich Makros) der avr-libc stehen nach Einbinden der header-Datei ''sleep.h'' zur Verfügung.<br />
<br />
;set_sleep_mode (uint8_t mode): Setzt den Schlafmodus, der bei Aufruf von sleep() aktiviert wird. In sleep.h sind einige Konstanten definiert (z.&nbsp;B. SLEEP_MODE_PWR_DOWN). Die definierten Modi werden jedoch nicht alle von sämtlichten AVR-Controllern unterstützt.<br />
;sleep_enable(): Aktiviert den gesetzten Schlafmodus, versetzt den Controller aber noch nicht in den Schlafmodus<br />
;sleep_cpu(): Versetzt den Controller in den Schlafmodus .sleep_cpu wird im Prinzip durch die Assembler-Anweisung ''sleep'' ersetzt.<br />
;sleep_disable(): Deaktiviert den gesetzten Schlafmodus<br />
;sleep_mode(): Versetzt den Controller in den mit set_sleep_mode gewählten Schlafmodus. Das Makro entspricht sleep_enable()+sleep_cpu()+sleep_disable(), beinhaltet also nicht die Aktivierung von Interrupts (besser nicht benutzen).<br />
<br />
Bei Anwendung von sleep_cpu() müssen Interrupts also bereits freigeben sein (sei()), da der Controller sonst nicht mehr "aufwachen" kann. sleep_mode() ist nicht geeignet für die Verwendung in ISR Interrupt-Service-Routinen, da bei deren Abarbeitung Interrupts global deaktiviert sind und somit auch die möglichen "Aufwachinterrupts". Abhilfe: stattdessen sleep_enable(), sei(), sleep_cpu(), sleep_disable() und evtl. cli() verwenden (vgl. Dokumentation der avr-libc).<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/sleep.h><br />
<br />
int main(void)<br />
{<br />
...<br />
<br />
while (1) {<br />
...<br />
set_sleep_mode(SLEEP_MODE_PWR_DOWN);<br />
sleep_mode();<br />
<br />
// Code hier wird erst nach Auftreten eines entsprechenden<br />
// "Aufwach-Interrupts" verarbeitet<br />
...<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
In älteren Versionenen der avr-libc wurden nicht alle AVR-Controller durch die sleep-Funktionen richtig angesteuert. Mit avr-libc 1.2.0 wurde die Anzahl der unterstützten Typen jedoch deutlich erweitert. Bei nicht-unterstützten Typen erreicht man die gewünschte Funktionalität durch direkte "[[Bitmanipulation]]" der entsprechenden Register (vgl. Datenblatt) und Aufruf des Sleep-Befehls via Inline-Assembler oder sleep_cpu():<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
...<br />
// Sleep-Mode "Power-Save" beim ATmega169 "manuell" aktivieren<br />
SMCR = (3<<SM0) | (1<<SE);<br />
asm volatile ("sleep"::); // alternativ sleep_cpu() aus sleep.h<br />
...<br />
</syntaxhighlight><br />
<br />
== Sleep-Modi ==<br />
Die vielen Prozessoren aus der AVR-Familie unterstützen unterschiedliche Sleep-Modi, gefächert nach Vorhandensein von Funktionsblöcken im Controller. Konkrete und verläßliche Auskunft über die tatsächlichen Gegebenheiten finden sich wie immer in den jeweiligen Datenblättern. Die Modi unterscheiden sich darin, welche Funktionsbereiche zum Energiesparen abgeschaltet werden. Davon hängt auch ab, mit welchen Mitteln der Prozessor aus der jeweiligen Schlaftiefe wieder aufgeweckt werden kann.<br />
<br />
;Idle Mode (SLEEP_MODE_IDLE): Die CPU kann durch SPI, USART, Analog Comperator, ADC, TWI, Timer, Watchdog und irgendeinen anderen Interrupt wieder aufgeweckt werden.<br />
<br />
;ADC Noise Reduction Mode (SLEEP_MODE_ADC): In diesem Modus liegt das Hauptaugenmerk darauf, die CPU soweit stillzulegen, dass der ADC möglichst keine Störungen aus dem inneren der CPU auffangen kann, die das Meßergebnis negativ beeinflussen können. Das Aufwachen aus diesem Modus kann ausgelöst werden durch den ADC, externe Interrupts, TWI, Timer und Watchdog.<br />
<br />
;Power-Down Mode (SLEEP_MODE_PWR_DOWN): In diesem Modus wird ein externer Oszillator (Quarz, Quarzoszillator), wenn vorhanden. gestoppt. Geweckt werden kann die CPU durch einen externen Level-Interrupt, TWI, Watchdog, Brown-Out-Reset.<br />
<br />
;Power-Save-Mode (SLEEP_MODE_PWR_SAVE): Power-Save ist identisch zu Power-Down mit einer Ausnahme: Ist der Timer 2 auf die Verwendung eines externen Taktes konfiguriert, so läuft dieser Timer auch im Power-Save weiter und kann die CPU mit einem Interrupt aufwecken.<br />
<br />
;Standby-Mode (SLEEP_MODE_STANDBY, SLEEP_MODE_EXT_STANDBY): Voraussetzung für den Standby-Modus ist die Verwendung eines Quarzes oder eines Quarzoszillators, also einer externen Taktquelle. Ansonsten ist dieser Modus identisch zum Power-Down Modus. Vorteil dieses Modus' ist eine kürzere Aufwachzeit.<br />
<br />
;Abschalten des Brownout Detect (BOD) während der Sleep-Phase (nur P-Typen): Zur Stromersparnis bieten die P-Typen die Möglichkeit den BOD während der Sleep-Phase abzuschalten. Bei einem Atmega88PA beispielsweise, kann dadurch der Stromverbrauch im SLEEP_MODE_PWR_SAVE mit Timer2 im Asynchronmodus mit Uhrenquarz und periodischer Selbstaufweckung um ca. 50% gesenkt werden.<br />
Das Einschalten dieser Funktion geschieht in einer Timed Sequence.<br />
<br />
<syntaxhighlight lang="c"><br />
unsigned char temp0 = MCUCR;<br />
unsigned char temp1 = MCUCR;<br />
temp0 |= (1 << BODS) | (1 << BODSE);<br />
temp1 |= (1 << BODS);<br />
MCUCR = temp0;<br />
MCUCR = temp1;<br />
sleep_cpu();<br />
</syntaxhighlight><br />
<br />
Hierbei ist unbedingt zu beachten, dass das BODS-Bit 3 Takte nach dem Setzen wieder gelöscht wird. Daher muss der Aufruf des Sleep unmittelbar nach dem Setzen erfolgen und das BODS-Bit muss jedes Mal vor einem Sleep Aufruf erneut gesetzt werden.<br />
<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Power Management and Sleep-Modes<br />
* [http://www.mikrocontroller.net/topic/96369#832712 Forenbeitrag] zur "Nichtverwendung" von sleep_mode in ISRs.<br />
<br />
= Zeiger =<br />
Zeiger (engl. ''Pointer'') sind Variablen, die die Adresse von Daten oder Funktionen enthalten und belegen 16 Bits. Die Größe hängt mit dem adressierbaren Speicherbereich zusammen und der GCC reserviert dann den entsprechenden Platz.<br />
Ggf. ist es also günstiger, Indizes auf Arrays (Listen) zu verwenden, so dass der GCC für die Zeigerarithmetik den erforderlichen RAM nur temporär benötigt.<br />
<br />
Siehe auch: [[Zeiger]]<br />
<br />
= Speicherzugriffe =<br />
<br />
Atmel AVR-Controller verfügen typisch über drei Speicher:<br />
<br />
* [[RAM]]: Im RAM (genauer statisches RAM/SRAM) wird vom gcc-Compiler Platz für Variablen reserviert. Auch der Stack befindet sich im RAM. Dieser Speicher ist "flüchtig", d.h. der Inhalt der Variablen geht beim Ausschalten oder einem Zusammenbruch der Spannungsversorgung verloren.<br />
<br />
* Programmspeicher: Ausgeführt als FLASH-Speicher, seitenweise wiederbeschreibbar. Darin ist das Anwendungsprogramm abgelegt.<br />
<br />
* [[EEPROM]]: Nichtflüchtiger Speicher, d.h. der einmal geschriebene Inhalt bleibt auch ohne Stromversorgung erhalten. Byte-weise schreib/lesbar. Im EEPROM werden typischerweise gerätespezifische Werte wie z.&nbsp;B. Kalibrierungswerte von Sensoren abgelegt.<br />
<br />
Einige AVRs besitzen keinen RAM-Speicher, lediglich die Register können als "Arbeitsvariablen"<br />
genutzt werden. Da die Anwendung des avr-gcc auf solch "kleinen" Controllern ohnehin selten sinnvoll ist und auch nur bei einigen RAM-losen Typen nach [http://lightner.net/avr/ATtinyAvrGcc.html "Bastelarbeiten"] möglich ist, werden diese Controller hier nicht weiter berücksichtigt. Auch EEPROM-Speicher ist nicht auf allen Typen verfügbar. Generell sollten die nachfolgenden Erläuterungen auf alle ATmega-Controller und die größeren AT90-Typen übertragbar sein. Für die Typen ATtiny2313, ATtiny26 und viele weitere der "ATtiny-Reihe" gelten die Ausführungen ebenfalls.<br />
<br />
Siehe auch:<br />
* [[Binäre Daten zum Programm hinzufügen]]<br />
== RAM ==<br />
<br />
Die Verwaltung des RAM-Speichers erfolgt durch den Compiler, im Regelfall ist beim Zugriff auf Variablen im RAM nichts Besonderes zu beachten. Die Erläuterungen in jedem brauchbaren C-Buch gelten auch für den vom avr-gcc-Compiler erzeugten Code.<br />
<br />
Um Speicher dynamisch (während der Laufzeit) zu reservieren, kann '''malloc()''' verwendet werden. malloc(size) "alloziert" (~reserviert) einen gewissen Speicherblock mit '''size''' Bytes. Ist kein Platz für den neuen Block, wird NULL (0) zurückgegeben.<br />
<br />
Wird der angelegte Block zu klein (groß), kann die Größe mit realloc() verändert werden. Den allozierten Speicherbereich kann man mit free() wieder freigeben. Wenn das Freigeben eines Blocks vergessen wird spricht man von einem "Speicherleck" (memory leak).<br />
<br />
malloc() legt Speicherblöcke im '''Heap''' an, belegt man zuviel Platz, dann wächst der Heap zu weit nach oben und überschreibt den Stack, und der Controller kommt in Teufels Küche. Das kann leider nicht nur passieren wenn man insgesamt zu viel Speicher anfordert, sondern auch wenn man Blöcke unterschiedlicher Größe in ungünstiger Reihenfolge alloziert/freigibt (siehe Artikel [[Heap-Fragmentierung]]). Aus diesem Grund sollte man malloc() auf Mikrocontrollern sehr sparsam (am besten gar nicht) verwenden.<br />
<br />
Beispiel zur Verwendung von malloc():<br />
<syntaxhighlight lang="c"><br />
#include <stdlib.h><br />
<br />
void foo(void) {<br />
// neuen speicherbereich anlegen,<br />
// platz für 10 uint16<br />
uint16_t* pBuffer = malloc(10 * sizeof(uint16_t));<br />
<br />
// darauf zugreifen, als wärs ein gewohnter Buffer<br />
pBuffer[2] = 5;<br />
<br />
// Speicher (unbedingt!) wieder freigeben<br />
free(pBuffer);<br />
}<br />
</syntaxhighlight><br />
<br />
Wenn (wie in obigem Beispiel) dynamischer Speicher nur für die Dauer einer Funktion benötigt und am Ende wieder freigegeben wird, bietet es sich an, statt malloc() '''alloca()''' zu verwenden. Der Unterschied zu malloc() ist, dass der Speicher auf dem Stack reserviert wird, und beim Verlassen der Funktion automatisch wieder freigegeben wird. Es kann somit kein Speicherleck und keine Fragmentierung entstehen.<br />
<br />
siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/malloc.html AVR Libc Home Page]: Memory Areas and Using malloc()<br />
* [https://www.mikrocontroller.net/topic/479027#5934443 Forumsbeitrag]: RAM Verbrauch auch von lokalen variablen ermitteln<br />
<br />
== Flash mit PROGMEM und pgm_read ==<br />
<br />
→ [http://nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html avr-libc: Doku zu avr/pgmspace.h]<br />
<br />
Ein Zugriff auf Konstanten im Programmspeicher ist mittels avr-gcc erst ab Version 4.7 "transparent" möglich. Um Daten aus dem Flash zu lesen, muss die AVR-Instruktion LPM (''Load from Program Memory'') erzeugt werden, bei Controllern mit mehr als 64kiB Flash auch ELPM.<br />
<br />
Dazu gibt es das AVR-spezifische GCC-Attribut <tt>progmem</tt>, mit dem eine Variablendeklaration im ''static storage''<ref>Variablen der Speicherklasse ''static storage'' haben eine unbegrenzte Lebensdauer. Beispiel für solche Variablen sind globale Variablen, aber auch static-Variablen innerhalb einer Funktion gehören dazu. Beispiele für Variablen, die nicht ''static storage'' sind: auto-Variablen ("normale" lokale Variablen), register-Variablen, durch malloc geschaffene Objekte, etc.</ref> markiert werden kann:<br />
<syntaxhighlight lang="c"><br />
const int value __attribute__((progmem)) = 1;<br />
</syntaxhighlight><br />
<br />
Effekt ist, dass die so markierte Variable nicht im RAM sondern im Flash angelegt wird. Wird durch "normalen" C-Code auf solch eine Variable zugegriffen, wird jedoch aus der gleichen Adresse aus dem RAM gelesen und nicht aus dem Flash! Das ist ein Fehler, den der Compiler aber nicht anzeigt!<br />
<br />
<syntaxhighlight lang="c"><br />
int test = value; // Fehler! PROGMEM Konstanten müssen mit den pgm_read-Funktionen gelesen werden!<br />
</syntaxhighlight><br />
<br />
Zum Lesen aus dem Flash stellt die avr-libc daher zahlreiche Makros zur Verfügung. Zudem wird das Makro <tt>PROGMEM</tt> definiert, das etwas Tipparbeit spart:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
const int value PROGMEM = 1;<br />
</syntaxhighlight><br />
<br />
<tt>progmem</tt> funktioniert im Wesentlichen wie ein Section-Attribut, das die Daten in der Section <tt>.progmem.data</tt> ablegt. Im Gegensatz zum Section-Attribut werden jedoch noch weitere Prüfungen unternommen, ab avr-gcc 4.6 etwa muss die entsprechende Variable <tt>const</tt> sein.<br />
<br />
=== Integer und float ===<br />
<br />
Zum Lesen von Skalaren stellt die avr-libc folgende Makros zu Verfügung, die jeweils ein Argument erhalten: Die 16-Bit Adresse des zu lesenden Wertes<ref>Damit ist der mögliche Speicherbereich für Flash-Konstanten auf 64kiB begrenzt. Einige pgmspace-Funktionen ermöglichen den Lesezugriff auf den gesamten Flash-Speicher, intern via Assembler-Anweisung ELPM. Die Initialisierungswerte des Speicherinhalts jenseits der 64kiB-Marke müssen dann jedoch auf anderem Weg angelegt werden, d.h. nicht per PROGMEM. Evtl. eigene Section und Linker-Optionen. Alt und nicht ganz korrekt: Die avr-libc pgmspace-Funktionen unterstützen nur die unteren 64kiB Flash bei Controllern mit mehr als 64kiB.</ref><br />
<br />
:{| {{Tabelle}}<br />
|+ Übersicht der <tt>pgm_read</tt> Funktionen aus<br/>dem Header <tt>avr/pgmspace.h</tt> der avr-libc<br />
|-<br />
! Gelesener Wert || <tt>pgm_read_xxx</tt> || Anzahl Bytes<br />
|-<br />
| <tt>uint8_t</tt> || <tt>pgm_read_byte</tt> || 1<br />
|-<br />
| <tt>uint16_t</tt> || <tt>pgm_read_word</tt> || 2<br />
|-<br />
| <tt>uint32_t</tt> || <tt>pgm_read_dword</tt> || 4<br />
|-<br />
| <tt>float</tt> || <tt>pgm_read_float</tt><ref>ab avr-libc 1.7.0</ref> || 4<br />
|}<br />
<br />
Soll ein Zeiger gelesen werden, so verwendet man <tt>pgm_read_word</tt> und castet das Ergebnis zum gewünschten Zeiger-Typ.<br />
<br />
;Beispiele:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
/* Byte */<br />
const uint8_t aByte PROGMEM = 123;<br />
<br />
/* int-Array */<br />
const int anArray[] PROGMEM = { 18, 3 ,70 };<br />
<br />
void foo (void)<br />
{<br />
/* Zeiger */<br />
static const uint8_t* const aPointer PROGMEM = &aByte;<br />
<br />
uint8_t a = pgm_read_byte (&aByte);<br />
int a2 = (int) pgm_read_word (&anArray[2]);<br />
const uint8_t* p = (const uint8_t*) pgm_read_word (&aPointer);<br />
}<br />
</syntaxhighlight><br />
<br />
=== Blöcke ===<br />
<br />
In den Flash-Funktionen der avr-libc sind keine der pgm_read_xxxx Nomenklatur folgenden Funktionen, die Speicherblöcke auslesen oder vergleichen. Die enstprechende Funktionen sind Varianten von <tt>memcpy</tt>, <tt>memcmp</tt> und heißt <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, usw. Für weitere Funktionen und deren Prototypen siehe die Dokumentation der avr-libc.<br />
<br />
=== Strings ===<br />
<br />
Strings sind in C nichts anderes als eine Abfolge von Zeichen und einem <tt>'\0'</tt> als Stringende. Der prinzipielle Weg ist daher identisch zum Lesen von Bytes, wobei auf die [[FAQ#Wie funktioniert String-Verarbeitung in C?|Besonderheiten von Strings]] wie 0-Terminierung geachtet werden muss.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
size_t my_string_length (const char *addr)<br />
{<br />
size_t length = 0;<br />
<br />
while (pgm_read_byte (addr++))<br />
{<br />
length++;<br />
}<br />
return length;<br />
}<br />
</syntaxhighlight><br />
<br />
Zur Unterstützung des Programmierers steht das Repertoire der str-Funktionen auch in jeweils eine Variante zur Verfügung, die mit dem Flash-Speicher arbeiten kann. Die Funktionsnamen tragen den Suffix <tt>_P</tt>. Darüber hinaus gibt es das Makro <tt>PSTR</tt>, das ein String-Literal im Flash-Speicher ablegt und die Adresse des Strings liefert:<br />
<br />
Die nachfolgende Funktion liefert 0 zurück, wenn string_im_ram gleich "Hallo Welt" ist. Mit strcmp (String Compare) können wir zwei Strings vergleichen. Der Rückgabewert kann hierbei folgende Werte haben:<br><br />
0 die Strings sind gleich<br />
>0 das erste ungleiche Zeichen in string_im_ram ist größer als in "Hallo Welt"<br />
<0 das erste ungleiche Zeichen in string_im_ram ist kleiner als in "Hallo Welt"<br />
<br><br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
int foo (const char *string_im_ram)<br />
{<br />
return strcmp_P (string_im_ram, PSTR ("Hallo Welt"));<br />
}<br />
</syntaxhighlight><br />
<br />
Zu beachten ist, dass <tt>PSTR</tt> nur innerhalb von Funktionen verwendet werden kann.<br />
<br />
; Array aus Strings:<br />
<br />
Arrays aus Strings im Flash-Speicher werden in zwei Schritten angelegt:<br />
<br />
# Zuerst die einzelnen Elemente des Arrays und<br />
# im Anschluss ein Array, in dem die Startaddressen der Strings abgelegt werden.<br />
<br />
Zum Auslesen wird zuerst die Adresse des gewünschten Elements aus dem Array im Flash-Speicher gelesen, die im Anschluss dazu genutzt wird, um auf das Element (den String) selbst zuzugreifen.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
static const char str1[] PROGMEM = "Hund";<br />
static const char str2[] PROGMEM = "Katze";<br />
static const char str3[] PROGMEM = "Maus";<br />
<br />
const char * const array[] PROGMEM = <br />
{<br />
str1, str2, str3<br />
};<br />
<br />
// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]<br />
void read_string (char *buf, size_t i)<br />
{<br />
// Lese die Adresse des i-ten Strings aus array[]<br />
const char *parray = (const char*) pgm_read_ptr (&array[i]);<br />
<br />
// Kopiere den Inhalt der Zeichenkette vom Flash ins RAM<br />
strcpy_P (buf, parray);<br />
}<br />
</syntaxhighlight><br />
<br />
Eine weitere Möglichkeit ist, die Strings in einem 2-dimensionalen char-Array abzulegen anstatt deren Adresse in einem 1-dimensionalen Adress-Array zu speichern.<br />
<br />
Vorteil ist, dass der Code einfacher wird. Nachteil ist, dass bei unterschiedlich langen Strings Speicherplatz verschwendet wird, weil sich die Array-Dimension and der Länge des längsten Strings orientieret. Bei in etwa gleich langen Strings kann es aber sogar Speicherplatz sparen, denn es die Adressen der einzelnen Strings müssen nicht abgespeichert werden.<ref>In unserem Hund-Katze-Maus Beispiel belegt die erste Variante 22 Bytes Daten und 18 Bytes Code, die zweite Variante mit 2-dimensionalem Array belegt 18 Bytes Daten und 20 Bytes Code. Gemessen wurde mit avr-gcc 4.8 -Os für ATmega8.</ref><br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
// Die "6" ist 1 plus die Länge des längsten Strings ("Katze")<br />
const char array[][6] PROGMEM = <br />
{<br />
"Hund", "Katze", "Maus"<br />
};<br />
<br />
// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]<br />
void read_string (char *buf, size_t i)<br />
{<br />
// Kopiere den Inhalt der i-ten Zeichenkette vom Flash ins RAM<br />
strcpy_P (buf, array[i]);<br />
}<br />
</syntaxhighlight><br />
<br />
Siehe dazu auch die avr-libc FAQ: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_rom_array How do I put an array of strings completely in ROM?]<br />
<br />
=== Warum so kompliziert? ===<br />
<br />
Zu dem Thema, warum die Verabeitung von Werten aus dem Flash-Speicher so kompliziert ist, sei hier nur kurz erläutert: Die Harvard-Architektur des AVR weist getrennte Adressräume für Programm (Flash) und Datenspeicher (RAM) auf. Der C-Standard sieht keine unterschiedlichen Adressräume vor.<br />
<br />
Hat man zum Beispiel eine Funktion string_an_uart (const char* s) und übergibt an diese Funktion die Adresse einer Zeichenkette, dann weiß die Funktion nicht, ob die Adresse in den Flash-Speicher oder das RAM zeigt. Weder aus dem Pointer-Wert, also dem Zahlenwert, noch aus dem "const" kann auf den Ort der Ablage geschlossen werden.<br />
<br />
Einige AVR-Compiler bilden die Harvard-Architektur ab, indem sie in einen Pointer nicht nur die Adresse speichern, sondern auch den Ablageort wie ''Flash'' oder ''RAM''. In einem Aufruf einer Funktion wird dann bei Pointer-Parametern neben der Adresse auch der Speicherbereich, auf den der Pointer zeigt, übergeben.<br />
<br />
Dies hat jedoch auch Nachteile, denn bei jedem Zugriff über einen Zeiger muss zur ''Laufzeit'' entschieden werden, wie der Zugriff auszuführen ist und entsprechend länglicher und langsamer wird der erzeugte Code.<br />
<br />
Siehe auch:<br />
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitte Modules/Program Space String Utilities und Abschnitt Modules/Bootloader Support Utilities<br />
<br />
=== Datenzugriff >64kiB ===<br />
<br />
Die Zeiger beim avr-gcc sind nur 16 Bit breit, können somit also nur 64kiB Datenspeicher adressieren. Darauf sind auch alle Funktion der libc ausgelegt, welche auf _P enden. Als Funktionspointer können sie beim AVR bis zu 128 kiB Programmspeicher adressieren, weil Funktionsadressen immer 16-Bit Worte adressieren und nicht Bytes. Der Zugriff auf den RAM ist mit maximal 16kiB durch 16 Bit Poiinter nicht begrenzt. Um Zugriff jenseits von 64KiB zu bewerkstelligen gibt es mehrere Möglichkeiten:<br />
<br />
* Address-Spaces wie <tt>__flash1</tt> oder <tt>__memx</tt>, siehe Abschnitt "[[#Jenseits von flash|Jenseits von __flash]]".<br />
* Die Funktionen bzw. Makros <tt>pgm_read_xxx_far</tt> der AVR-Libc ab Version 1.8.0, wie im folgenden beschrieben. Dafür gibt es die Funktion pgm_get_far_address(), um 32-Bit Pointer eines Objekts zu erhalten<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <avr/pgmspace.h><br />
<br />
//===================================================================<br />
// Define an additional section, which will be placed after all others<br />
//--------------------------------------------------------------------<br />
#define FAR_SECTION __attribute__((__section__(".far_section")))<br />
//--------------------------------------------------------------------<br />
<br />
//====================================================================<br />
// Just an example<br />
//====================================================================<br />
<br />
const char MyString[] FAR_SECTION = "Hier liegt mein FAR-Teststring!";<br />
const char MyBmp64[] FAR_SECTION = {0xAA,0xBB,0xCC,0xDD,0xEE,0xFF,0x00};<br />
<br />
int main(void) {<br />
uint32_t ptr = pgm_get_far_address(MyString);<br />
char MyChar;<br />
DDRC = 0xFF;<br />
do {<br />
MyChar = pgm_read_byte_far(ptr++);<br />
PORTC = MyChar;<br />
} while(MyChar);<br />
}<br />
</syntaxhighlight><br />
<br />
D.h. man muss<br />
* Die Definition der neuen Section <tt>FAR_SECTION</tt> einfügen<br />
* Die konstanten Daten mit dieser Section kennzeichnen<br />
<br />
Dem Linker muss man über diese Section nichts mitteilen, er fügt diese automatisch nach allen bestehenden sections im Flash ein. Der Zugriff auf diese Variablen kann nur mittels direkter Pointerarithmetik erfolgen, eine Indizierung von Arrays mit variablem Index ist nicht möglich. Dabei muss die Größe des Datentyps immer manuell berücksichtigt werden, denn der Pointer ist immer ein Bytepointer!<br />
<br />
<syntaxhighlight lang="c"><br />
int n=3;<br />
MyChar = pgm_read_byte_far(pgm_get_far_address(MyBmp64)+n*sizeof(char));<br />
</syntaxhighlight><br />
<br />
Dabei gibt es einige praktische Probleme.<br />
* Beim recht alten AVR-Studio 4.18 wird die Größe des belegten FLASH-Speichers nicht korrekt angezeigt, die Daten landen aber im HEX-File.<br />
* beim moderneren Atmelstudio 6.2 sieht man in der Consolenausgabe die richtige Größe, welche von avr-size ermittelt wurde, diese wird aber dann in der 2. Ausgabe durch Atmelstudio falsch dargestellt<br />
* Die Arduino-IDE rechnet richtig, siehe dieser [https://www.mikrocontroller.net/topic/511511?goto=6568945#6568945 Forumsbeitrag].<br />
<br />
== Flash mit __flash und Embedded-C ==<br />
<br />
Ab Version 4.7 unterstützt avr-gcc ''Adress-Spaces'' gemäß dem Embedded-C Dokument ISO/IEC TR18037. Der geläufigste Adress-Space ist <tt>__flash</tt>, der im Gegensatz zu <tt>progmem</tt> kein GCC-Attribut ist, sondern ein Qualifier und damit syntaktisch ähnlich verwendet wird wie <tt>const</tt> oder <tt>volatile</tt>.<br />
<br />
GCC kennt keine eigene Option zum Aktivieren von Embedded-C, es wird als GNU-C Erweiterung behandelt. Daher müssen C-Module, die Address-Spaces verwenden, mit <tt>-std=gnu99</tt> o.ä. compiliert werden.<br />
<br />
<syntaxhighlight lang="c"><br />
static const __flash int value = 10;<br />
<br />
int get_value (void)<br />
{<br />
return value;<br />
}<br />
</syntaxhighlight><br />
<br />
# Im Gegensatz zu <tt>progmem</tt> sind keine speziellen Bibliotheksfunktionen oder -makros für den Zugriff mehr notwendig: Der Code zum Lesen der Variable ist "normales" C.<br />
# Die Variable wird im richtigen Speicherbereich (Flash) angelegt.<br />
# <tt>__flash</tt> ist nur zusammen mit read-only Objekten oder Zeigern, d.h. nur zusammen mit <tt>const</tt>, erlaubt.<br />
# Zugriffe wie im obigen Beispiel können (weg)optimiert werden. Das Beispiel entspricht einem "<tt>return 10</tt>". Es besteht keine Notwendigkeit, für <tt>value</tt> überhaupt Flash-Speicher zu reservieren.<br />
<br />
Auch Zeiger-Indirektionen sind problemlos möglich. Zu beachten ist, dass <tt>__flash</tt> auf der richtigen Seite des "<tt>*</tt>" in der Zeigerdeklaration bzw. -definition steht:<br />
* '''Rechts vom <tt>*</tt>:''' Der Zeiger selbst liegt im Flash<br />
* '''Links vom <tt>*</tt>:''' Der Zeiger enthält eine Flash-Adresse<br />
<br />
<syntaxhighlight lang="c"><br />
// val ist eine Variable im Flash<br />
const __flash int val = 42;<br />
<br />
// pval liegt auch im Flash und enthält die Adresse von val<br />
const __flash int* const __flash pval = &val;<br />
<br />
int get_val (void)<br />
{<br />
// liest den Wert von val über die in pval abgelegte Adresse<br />
return *pval;<br />
}<br />
</syntaxhighlight><br />
<br />
=== Blöcke ===<br />
<br />
Um Speicherbereiche vom Flash in den RAM zu kopieren, gibt es zwei Möglichkeiten: Zum einen können wie bei <tt>progmem</tt> beschreiben die Funktionen der avr-libc wie <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, <tt>movmem_P</tt>, etc. verwendet werden:<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
// Eine Datenstruktur<br />
typedef struct<br />
{<br />
int id;<br />
char buf[10];<br />
} data_t;<br />
<br />
extern void uart_send (const void*, size_t);<br />
<br />
void send_data (const __flash data_t *pdata)<br />
{<br />
// buf wird auf dem Stack angelegt<br />
data_t buf;<br />
<br />
// Kopiere Daten vom Flash nach buf ins RAM<br />
memcpy_P (&buf, pdata, sizeof (data_t));<br />
<br />
// Sende die Daten in buf<br />
uart_send (&buf, sizeof (data_t));<br />
}<br />
</syntaxhighlight><br />
<br />
Zum anderen kann eine Struktur auch über direktes Kopieren ins RAM geladen werden:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdlib.h><br />
<br />
// Eine Datenstruktur<br />
typedef struct<br />
{<br />
int id;<br />
char buf[10];<br />
} data_t;<br />
<br />
extern void uart_send (const void*, size_t);<br />
<br />
void send_data (const __flash data_t *pdata)<br />
{<br />
// Kopiere Daten ins RAM. buf wird auf dem Stack angelegt<br />
const data_t buf = *pdata;<br />
<br />
// Verwendet die Daten in buf<br />
uart_send (&buf, sizeof (data_t));<br />
}<br />
</syntaxhighlight><br />
<br />
=== Strings ===<br />
<br />
Natürlich können auch Strings im Flash abgelegt werden und auch mit Funktionen wie <tt>strcpy_P</tt> aus der avr-libc verarbeitet werden. Zudem ist es möglich, Flash-Zeiger mit der Adresse eines String-Literals zu initialisieren:<br />
<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
#define FSTR(X) ((const __flash char[]) { X } )<br />
<br />
const __flash char * const __flash array[] = <br />
{<br />
FSTR ("Hund"), FSTR ("Katze"), FSTR ("Maus")<br />
};<br />
<br />
size_t get_len (uint8_t tier)<br />
{<br />
return strlen_P (array[tier]);<br />
}<br />
</syntaxhighlight><br />
<br />
Leider sieht der Embedded-C Draft nicht vor, String-Literale direkt in einem anderen Adress-Space als ''generic'' anzulegen, so dass hier der Umweg über <tt>FSTR</tt> genommen werden muss. Dieses Konstrukt ist nur ausserhalb von Funktionen möglich und kann daher nicht als Ersatz für <tt>PSTR</tt> aus der avr-libc dienen.<br />
<br />
Soll <tt>array</tt> ein 2-dimensonales Array sein anstatt ein 1-dimensionales Array von Zeigern, dann geht das ohne große Verrenkungen:<br />
<br />
<syntaxhighlight lang="c"><br />
// Die 6 ergibt sich aus 1 plus der Länge des längsten Strings "Katze"<br />
const __flash char array[][6] = <br />
{<br />
"Hund", "Katze", "Maus"<br />
};<br />
</syntaxhighlight><br />
<br />
Weiters besteht die Möglichkeit, <tt>array</tt> analog anzulegen, wie man es mit <tt>PROGMEM</tt> machen würde: Jeder String wird explizit angelegt und seine Adresse bei der Initialisierung von <tt>array</tt> verwendet. Dies entspricht dem ersten Beispiel eines 1-dimensionalen Zeigerarrays:<br />
<br />
<syntaxhighlight lang="c"><br />
static const __flash char strHund[] = "Hund";<br />
static const __flash char strKatze[] = "Katze";<br />
static const __flash char strMaus[] = "Maus";<br />
<br />
const __flash char * const __flash array[] = <br />
{<br />
strHund, strKatze, strMaus<br />
};<br />
</syntaxhighlight><br />
<br />
=== Casts ===<br />
<br />
Embedded C fordert, dass zwei Adress-Spaces entweder disjunkt sind – d.h. sie enthalten keine gemeinsamen Adressen – oder aber ein Space komplett im anderen enthalten ist, also eine Teilmengen-Beziehung besteht. Die Adress-Spaces von avr-gcc sind so implementiert, dass jeder Space Teilmenge jedes anderes ist. Zwar haben Spaces wie RAM und Flash physikalisch keinen Speicherbereich gemein, allerdings ermöglicht diese Implementierung das Casten von Zeigern zu unterschiedlichen Adress-Spaces<ref>Im Gegensatz zu einem Attribute wie <tt>progmem</tt> ist ein (Adress Space) Qualifier Teil des Zeiger-Typs.</ref>: <br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdbool.h><br />
<br />
char read_char (const char *address, bool data_in_flash)<br />
{<br />
if (data_in_flash)<br />
return *(const __flash char*) address;<br />
else<br />
return *address;<br />
}<br />
</syntaxhighlight><br />
<br />
Der Cast selbst erzeugt keinen zusätzlichen Code, da eine RAM-Adresse und eine Flash-Adresse die gleiche Binärdarstellung haben. Allerdings wird über den nach <tt>__flash</tt> gecasteten Zeiger anders zugegriffen, nämlich per LPM.<br />
<br />
=== Jenseits von __flash ===<br />
<br />
Ausser <tt>__flash</tt> gibt es auch folgende Address-Spaces:<br />
<br />
==== <tt>__flash</tt>''N'' ====<br />
<br />
<tt>__flash</tt>''N'' mit ''N'' = 1..5 sind fünf weitere Spaces, die analog zu <tt>__flash</tt> funktionieren und deren Zeiger ebenfalls 16 Bit breit sind. avr-gcc erwartet, dass die zugehörigen Daten, welche in die Section <tt>.progmem</tt>''N''<tt>.data</tt> abgelegt werden, so lokatiert sind, dass das high-Byte der Adresse (Bits 16..23) gerade ''N'' ist.<br />
<br />
Weil Daten- und Code-Layout höchst projektspezifisch sind, werden diese Sections im Standard Linker-Skript nicht beschrieben. Um funktionsfähigen Code zu erhalten, muss daher ein eigenes Linker-Skript zur Verfügung gestellt werden, das diese Sections beschreibt, oder es kann eine Erweiterung des Standard Skripts bereitgestellt werden falls dies möglich ist.<br />
<br />
;Beispiel: Eine Applikation, die <tt>__flash2</tt> verwendet. Die zugehörende Section <tt>.progmem2.data</tt> wird hinter <tt>.text</tt> angeordnet aber vor den Initializern für <tt>.data</tt>. Dazu wird beim Linken das ld-Skript Fragment per <tt>-Tflash12.ld</tt> angegeben, welches dann an der gewünschten Stelle in das default Skript eingefügt wird:<br />
:{| <!-- Tabelle bitte für korrekte Einrückung belassen --><br />
|-<br />
|<pre><br />
SECTIONS<br />
{<br />
.flash2 :<br />
{<br />
. = MAX (ABSOLUTE(0x20000), .);<br />
PROVIDE (__flash2_start = .);<br />
. = ALIGN(2);<br />
*(.flash2.text*)<br />
*(.progmem2.data*)<br />
PROVIDE (__flash2_end = .);<br />
<br />
ASSERT (__flash2_start == __flash2_end || __flash2_start >= ABSOLUTE(0x20000),<br />
"__flash2 data in .progmem2.data below 0x20000");<br />
ASSERT (__flash2_start == __flash2_end || __flash2_end <= ABSOLUTE(0x30000),<br />
"__flash2 data in .progmem2.data exceeds 0x30000");<br />
}<br />
}<br />
INSERT AFTER .text<br />
</pre><br />
|}<br />
<br />
==== <tt>__memx</tt> ====<br />
<br />
Dieser Address-Space implementiert 3-Byte Zeiger und unterstützt Lesen über 64KiB-Segmentgrenzen hinweg. Das MSB (Bit 23) gibt dabei an, ob der <tt>__memx</tt>-Zeiger eine Flash-Adresse enthält (Bit23 = 0) oder eine RAM-Adresse (Bit23 = 1), was folgenden Code erlaubt:<br />
<br />
<syntaxhighlight lang="c"><br />
const __memx int a_flash = 42;<br />
const int a_ram = 100;<br />
<br />
int get_a (const __memx int* pa)<br />
{<br />
return *pa;<br />
}<br />
<br />
int main (void)<br />
{<br />
return get_a (&a_flash) + get_a (&a_ram);<br />
}</syntaxhighlight><br />
<br />
Dies bedeutet, dass erst zur ''Laufzeit'' entschieden werden kann, ob <tt>get_a</tt> die Daten aus dem RAM oder aus dem Flash lesen soll, was <tt>__memx</tt> im Vergleich zu den anderen Address-Spaces langsamer macht. Ausserdem ist zu beachten, dass <tt>__memx</tt>-Zeiger zwar 24-Bit Zeiger sind, die zugrundeliegende Adress-Arithmetik jedoch gemäß dem C-Standard erfolgt, also als 16-Bit Arithmetik. Bestehende Funktion der avr-libc wie z.B. printf_P funktionieren damit ebensowenig wie printf! Wenn man <tt>__memx</tt> verwenden will, braucht man dafür eigene Funktionen.<br />
<br />
=== __flash, progmem und Portierbarkeit ===<br />
<br />
Da ab er aktuellen Compilerversion 4.7 sowohl <tt>__flash</tt> als auch <tt>PROGMEM</tt> und die <tt>pgm_read</tt>-Funktionen zur Verfügung stehen, ergibt sich die Frage, welche Variante "besser" ist und wie zwischen ihnen hin- und her zu portieren ist.<br />
<br />
Zunächst sei erwähnt, dass <tt>__flash</tt> kein Ersatz für <tt>PROGMEM</tt> ist, sondern lediglich eine Alternative dazu. Das "alte" progmem wird weiterhin mir gleicher Semantik unterstützt, so dass alter Code ohne Änderungen mit den neueren Compilerversionen übersetzbar bleibt.<br />
<br />
Von der Codegüte her dürften sich keine großen Unterschiede ergeben. Es ist nicht zu erwarten, dass die eine oder die andere Variante wesentlich besseren oder schlechteren Code erzeugt — von einer Ausnahme abgesehen: Der Wert beim Zugriff ist zur Compilezeit bekannt und kann daher eliminiert werden.<br />
<syntaxhighlight lang="c"><br />
static const __flash char x[] = { 'A', 'V', 'R' };<br />
<br />
char foo (void)<br />
{<br />
return x[2];<br />
}<br />
</syntaxhighlight><br />
Dies wird übersetzt wie "<tt>return 'R';</tt>", und das Array <tt>x[]</tt> kann komplett wegoptimiert werden und entfallen.<br />
<br />
==== progmem → __flash ====<br />
<br />
Portierung in diese Richtung bedeutet, alten Code anzupassen. Zwingend ist die Portierung nicht, da <tt>progmem</tt> weiterhin unterstützt wird.<br />
Allerdings ist eine Quelle mit <tt>__flash</tt> besser lesbar, denn der Code wird von den <tt>pgm_read</tt>-Funktionen befreit, die vor allem bei Mehrfach-Indirektion den Code ziemlich verunstalten und unleserlich machen können.<br />
Weiterer Vorteil von <tt>_flash</tt> ist, daß eine striktere Typprüfung erfolgen kann.<br />
<br />
Eine Portierung wird man in zwei Schritten vornehmen:<br />
<br />
;1. Definitionen von Flash-Variablen werden angepasst:<br />
<br />
Vorher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
static const char hund[] PROGMEM = "Hund";<br />
static const char katze[] PROGMEM = "Katze";<br />
static const char maus[] PROGMEM = "Maus";<br />
<br />
const char * const tier[] PROGMEM = <br />
{<br />
hund, katze, maus<br />
};<br />
</syntaxhighlight><br />
|}<br />
<br />
Nachher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
static const __flash char hund[] = "Hund";<br />
static const __flash char katze[] = "Katze";<br />
static const __flash char maus[] = "Maus";<br />
<br />
const __flash char * const __flash tier[] = <br />
{<br />
hund, katze, maus<br />
};<br />
</syntaxhighlight><br />
|}<br />
<br />
Der Header <tt>avr/pgmspace.h</tt> wird nicht mehr benötigt. Im Gegensatz zu <tt>progmem</tt> müssen Qualifier immer links von der definierten Variablen stehen; bei Attributen wie <tt>progmem</tt> ist das mehr oder weniger egal.<br />
<br />
Nachdem diese Anpassung erfolgreich abgeschlossen ist, folgt Schritt<br />
<br />
; 2. Der Code wird von <tt>pgm_read</tt>-Aufrufen bereinigt:<br />
<br />
Vorher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <avr/pgmspace.h><br />
<br />
extern const char *tier[];<br />
<br />
char first_letter (uint8_t i)<br />
{<br />
const char* ptier = (const char*) pgm_read_word (&tier[i]);<br />
return (char) pgm_read_byte (&ptier[0]);<br />
}<br />
</syntaxhighlight><br />
|}<br />
<br />
Nachher:<br />
:{|<br />
|-<br />
|<syntaxhighlight lang="c"><br />
#include <stdint.h><br />
<br />
extern const __flash char * const __flash tier[];<br />
<br />
char first_letter (uint8_t i)<br />
{<br />
return tier[i][0];<br />
}<br />
</syntaxhighlight><br />
|}<br />
<br />
== Dateien direkt im Flash einbinden ==<br />
<br />
Wenn man größere Dateien direkt im Programm einbinden will, ohne sie vorher in C Quelltext umzuwandeln, muss man das mit dem Linker machen. Wie das geht steht hier.<br />
<br />
* [http://www.atmel.com/webdoc/avrlibcreferencemanual/FAQ_1faq_binarydata.html Atmel, avr gcc Dokumentation]<br />
* [http://nongnu.org/avr-libc/user-manual/FAQ.html#faq_binarydata Nongnu avr gcc Dokumentation]<br />
<br />
Wie man das dann praktisch umsetzt, sieht man in diesem Beitrag.<br />
<br />
* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056910 Forumsbeitrag]: Binärdateien mittels Linker einbinden<br />
* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056947 Forumsbeitrag]: Ein kleines Tool zum Umwandeln von Binärdateien in C-Quelltext.<br />
<br />
== Flash in der Anwendung schreiben ==<br />
<br />
Bei AVRs mit "self-programming"-Option – auch bekannt als [[Bootloader]]-Support – können Teile des Flash-Speichers vom Anwendungsprogramm beschrieben werden. Dies ist nur möglich, wenn die Schreibfunktion in einem besonderen Speicherbereich, der Boot-Section des Programmspeichers/Flash, abgelegt ist.<br />
<br />
Bei einigen kleinen AVRs gibt es keine gesonderte Boot-Section, bei diesen kann der Flashspeicher von jeder Stelle des Programms geschrieben werden. Für Details sei hier auf das jeweilige Controller-Datenblatt und die Erläuterungen zum Modul boot.h der avr-libc verwiesen. Es existieren auch Application-Notes dazu bei atmel.com, die auf avr-gcc-Code übertragbar sind.<br />
<br />
Siehe auch: <br />
* Forumsbeitrag [http://www.mikrocontroller.net/topic/163632#1561622 Daten in Programmspeicher speichern]<br />
<br />
== EEPROM ==<br />
<br />
Möchte man Werte aus einem Programm heraus so speichern, dass sie auch nach dem Abschalten der Versorgungsspannung noch erhalten bleiben und nach dem Wiederherstellen der Versorgungsspannung bei erneutem Programmstart wieder zur Verfügung stehen, dann benutzt man das EEPROM.<br />
<br />
Schreib- und Lesezugriffe auf den EEPROM-Speicher erfolgen über die im Modul eeprom.h der avr-libc definierten Funktionen. Mit diesen Funktionen können einzelne Bytes, Datenworte (16 Bit), Fließkommawerte (32 Bit, single-precision, float) und Datenblöcke geschrieben und gelesen werden.<br />
<br />
Diese Funktionen kümmern sich auch um diverse Details, die bei der Benutzung des EEPROMs normalerweise notwendig sind:<br />
* EEPROM-Operationen sind im Vergleich relativ langsam. Man muss daher darauf achten, dass eine vorhergehende Operation abgeschlossen ist, ehe die nächste Operation mit dem EEPROM gestartet wird. Die in der avr-libc implementierten Funktionen aus eeprom.h berücksichtigten dies. Soll beim Aufruf einer EEPROM-Funktion sichergestellt werden, dass diese nicht intern in einer Warteschleife auf den Abschluss der vorherigen Operation wartet, kann vorher per eeprom_is_ready testen, ob der Zugriff auf den EEPROM-Speicher sofort möglich ist.<br />
* Es ist darauf zu achten, dass die EEPROM-Funktionen nicht durch einen Interrupt unterbrochen werden. Einige Phasen des Zugriffs sind zeitkritisch und müssen in einer definierten bzw. begrenzten Anzahl von Takten durchgeführt werden. Durch einen unterbrechenden Interrupt würde diese Restriktion nicht mehr eingehalten. Auch dieses Detail wird von den avr-libc Funktionen berücksichtigt, so dass man sich als C-Programmierer nicht darum kümmern muss. Innerhalb der Funktionen werden Interrupts vor der "EEPROM-Sequenz" global deaktiviert und im Anschluss, falls vorher auch schon eingeschaltet, wieder aktiviert.<br />
<br />
Man beachte, dass der EEPROM-Speicher nur eine begrenzte Anzahl von Schreibzugriffen zulässt. Beschreibt man eine EEPROM-Zelle öfter als die im Datenblatt zugesicherte Anzahl (typisch 100.000), wird die Funktion der Zelle nicht mehr garantiert. Dies gilt für jede einzelne Zelle. <br />
<br />
Bei geschickter Programmierung (z.&nbsp;B. Ring-Puffer), bei der die zu beschreibenden Zellen regelmäßig gewechselt werden, kann man eine deutlich höhere Anzahl an Schreibzugriffen, bezogen auf den gesamten EEPROM-Speicher, erreichen. Auf jeden Fall sollte man aber eine Abschätzung über die zu erwartende Lebensdauer des EEPROM durchführen. Wird ein Wert im EEPROM im Durchschnitt nur einmal pro Woche verändert, wird die garantierte Anzahl der Schreibzyklen innerhalb der voraussichtlichen Verwendungszeit des Controllers sicherlich nicht erreicht werden. Welcher Controller ist schon 100000 / 52 = 1923 Jahre im Einsatz? In diesem Fall lohnt es sich daher nicht, erweiterte Programmfunktionen zu implementieren, mit denen die Anzahl der Schreibzugriffe minimiert wird.<br />
<br />
Eine weitere Möglichkeit, Schreibzyklen einzusparen, besteht in der Vorabprüfung, ob der zu speichernde Wert im EEPROM bereits enthalten ist und nur veränderte Werte zu schreiben. In aktuelleren Versionen der avr-libc sind bereits Funktionen enthalten, die solche Prüfungen enthalten (eeprom_update_*).<br />
<br />
Eine dritte Möglichkeit speichert alle Daten zunächst im RAM, wo sie beliebig oft beschrieben werden können. Nur beim Ausschalten oder beim Ausfall der Stromversorgung werden die Daten in den EEPROM geschrieben. Wie man das richtig macht sieht man im Artikel [[Speicher#EEPROM Schreibzugriffe minimieren | Speicher]].<br />
<br />
Lesezugriffe können beliebig oft durchgeführt werden. Sie unterliegen keinen Einschränkungen in Bezug auf deren Anzahl. <br />
<br />
=== EEMEM ===<br />
Um eine Variable im EEPROM anzulegen, stellt die avr-libc das Makro EEMEM zur Verfügung:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdint.h><br />
#include <avr/eeprom.h><br />
<br />
/* Byte */<br />
uint8_t eeFooByte EEMEM = 123;<br />
<br />
/* Wort */<br />
uint16_t eeFooWord EEMEM = 12345;<br />
<br />
/* float */<br />
float eeFooFloat EEMEM;<br />
<br />
/* Byte-Array */<br />
uint8_t eeFooByteArray1[] EEMEM = { 18, 3, 70 };<br />
uint8_t eeFooByteArray2[] EEMEM = { 30, 7, 79 };<br />
<br />
/* 16-bit unsigned short feld */<br />
uint16_t eeFooWordArray1[4] EEMEM;<br />
</syntaxhighlight><br />
<br />
Die grundsätzliche Vorgehensweise ist identisch zur Verwendung von PROGMEM. Auch hier erzeugt man sich spezielle attributierte Variablen (EEMEM erledigt das), die vom Compiler/Linker nicht wie normale Variablen behandelt werden. Compiler/Linker kümmern sich zwar darum, dass diesen Variablen eine Adresse zugewiesen wird, diese Adresse ist dann aber die Adresse der 'Variablen' im EEPROM. Um die dort gespeicherten Werte zu lesen bzw. zu schreiben, übergibt man diese Adresse an spezielle Funktionen, die die entsprechenden Werte aus dem EEPROM holen bzw. das EEPROM neu beschreiben.<br />
<br />
Die mittels EEMEM erzeugten 'Variablen' sind also mehr als Platzhalter zu verstehen, denn als echte Variablen. Es geht nur darum, im C-Programm symbolische Namen zur Verfügung zu haben, anstatt mit echten EEPROM-Adressen hantieren zu müssen, etwas, das grundsätzlich aber auch genauso gut möglich ist. Nur muss man sich in diesem Fall dann selbst darum kümmern, dass mehrere 'Variablen' ohne Überschneidung im EEPROM angeordnet werden.<br />
<br />
=== Bytes lesen/schreiben ===<br />
<br />
Die avr-libc Funktion zum Lesen eines Bytes heißt eeprom_read_byte. Parameter ist die Adresse des Bytes im EEPROM. Geschrieben wird über die Funktion eeprom_write_byte mit den Parametern Adresse und Inhalt. Anwendungsbeispiel:<br />
<br />
<syntaxhighlight lang="c"><br />
#define EEPROM_DEF 0xFF<br />
<br />
void eeprom_example (void)<br />
{<br />
uint8_t myByte;<br />
<br />
// myByte lesen (Wert = 123)<br />
myByte = eeprom_read_byte (&eeFooByte);<br />
<br />
// der Wert 99 wird im EEPROM an die Adresse der<br />
// Variablen eeFooByte geschrieben<br />
myByte = 99;<br />
eeprom_write_byte(&eeFooByte, myByte); // schreiben<br />
<br />
myByte = eeprom_read_byte (&eeFooByteArray1[1]); <br />
// myByte hat nun den Wert 3<br />
<br />
// Beispiel fuer eeprom_update_byte: die EEPROM-Zelle wird nur<br />
// dann beschrieben, wenn deren Inhalt sich vom Parameterwert<br />
// unterscheidet. In diesem Beispiel erfolgt also kein Schreib-<br />
// zugriff, da die Werte gleich sind.<br />
eeprom_update_byte(&eeFooByte, myByte);<br />
<br />
<br />
// Beispiel zur "Sicherung" gegen leeres EEPROM nach "Chip Erase"<br />
// (z. B. wenn die .eep-Datei nach Programmierung einer neuen Version<br />
// des Programms nicht in den EEPROM uebertragen wurde und EESAVE<br />
// deaktiviert ist (unprogrammed/1)<br />
// <br />
// Vorsicht: wenn EESAVE "programmed" ist, hilft diese Sicherung nicht<br />
// weiter, da die Speicheraddressen in einem neuen/erweiterten Programm<br />
// moeglicherweise verschoben wurden. An der Stelle &eeFooByte steht<br />
// dann u.U. der Wert einer anderen Variable aus einer "alten" Version.<br />
<br />
uint8_t fooByteDefault = 222;<br />
if ((myByte = eeprom_read_byte (&eeFooByte)) == EEPROM_DEF)<br />
{<br />
myByte = fooByteDefault;<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
=== Wort lesen/schreiben ===<br />
<br />
Schreiben und Lesen von Datenworten erfolgt analog zur Vorgehensweise bei Bytes:<br />
<br />
<syntaxhighlight lang="c"><br />
// lesen<br />
uint16_t myWord = eeprom_read_word (&eeFooWord);<br />
<br />
// schreiben<br />
eeprom_write_word (&eeFooWord, 2222);<br />
</syntaxhighlight><br />
<br />
=== Block lesen/schreiben ===<br />
<br />
Lesen und Schreiben von Datenblöcken erfolgt über die Funktionen <code>eeprom_read_block()</code> bzw. <code>eeprom_write_block()</code>. Die Funktionen erwarten drei Parameter: die Adresse der Quell- bzw. Zieldaten im RAM, die EEPROM-Adresse und die Länge des Datenblocks in Bytes als <code>size_t</code>.<br />
<syntaxhighlight lang="c"><br />
uint8_t myByteBuffer[3];<br />
uint16_t myWordBuffer[4];<br />
<br />
void eeprom_block_example (void)<br />
{<br />
/* Datenblock aus EEPROM lesen */<br />
<br />
/* liest 3 Bytes ab der von eeFooByteArray1 definierten EEPROM-Adresse<br />
in das RAM-Array myByteBuffer */<br />
eeprom_read_block (myByteBuffer, eeFooByteArray1, 3);<br />
<br />
/* dito mit etwas Absicherung betr. der Länge */<br />
eeprom_read_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));<br />
<br />
/* und nun mit 16-Bit Array */<br />
eeprom_read_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));<br />
<br />
/* Datenblock in EEPROM schreiben */<br />
eeprom_write_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));<br />
eeprom_write_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));<br />
}<br />
</syntaxhighlight><br />
<br />
=== Fließkommawerte lesen/schreiben ===<br />
<br />
In der avr-libc stehen auch EEPROM-Funktionen für Variablen des Typs float (Fließkommazahlen mit "einfacher" Genauigkeit) zur Verfügung.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/eeprom.h><br />
<br />
float eeFloat EEMEM = 12.34f;<br />
<br />
float void eeprom_float_example(float value)<br />
{<br />
/* float in EEPROM schreiben */<br />
eeprom_write_float(&eeFloat, value);<br />
<br />
/* float aus EEPROM lesen */<br />
return eeprom_read_float(&eeFloat);<br />
}</syntaxhighlight><br />
<br />
=== EEPROM-Speicherabbild in .eep-Datei ===<br />
<br />
Mit den zum Compiler gehörenden Werkzeugen kann der aus den Variablendeklarationen abgeleitete EEPROM-Inhalt in eine Datei geschrieben werden. Die übliche Dateiendung ist .eep, Daten im Intel Hex-Format. Damit können Standardwerte für den EEPROM-Inhalt im Quellcode definiert werden. <br />
<br />
Makefiles nach WinAVR/MFile-Vorlage enthalten bereits die notwendigen Einstellungen, siehe dazu die Erläuterungen im [[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]].<br />
<br />
Der Inhalt der eep-Datei muss ebenfalls zum Mikrocontroller übertragen werden, wenn die Initialisierungswerte aus der Deklaration vom Programm erwartet werden. Ansonsten enthält der EEPROM-Speicher nach der Übertragung des Programmers mittels ISP abhängig von der Einstellung der EESAVE-Fuse<ref>vgl. Datenblatt Abschnitt Fuse Bits</ref> nicht die korrekten Werte:<br />
; EESAVE = 0 (programmed): Die Daten im EEPROM bleiben erhalten. Werden sie nicht neu geschrieben, so enthält das EEPROM evtl. Daten, die nicht mehr zum Programm passen.<br />
; EESAVE = 1 (unprogrammed): Beim Programmieren werden die Daten im EEPROM gelöscht, also auf 0xff gesetzt.<br />
<br />
Als Sicherung kann man im Programm nochmals die Standardwerte vorhalten, beim Lesen auf 0xFF prüfen und gegebenenfalls einen Standardwert nutzen. Das geht natürlich nur, wenn 0xFF selbst nicht als Datenwert vorkommen kann.<br />
<syntaxhighlight lang="c"><br />
#define DUTY_CYCLE_DEFAULT 0x80<br />
<br />
uint8_t eeDutyCycle EEMEM; // Platzhalter für EEPROM<br />
uint8_t DutyCycle; // die echte Variable<br />
<br />
<br />
int main(void)<br />
{<br />
DutyCycle = eeprom_read_byte( &eeDutyCycle );<br />
if( DutyCycle == 0xFF ) // das allererste mal. Im EEPROM steht noch kein gültiger Wert<br />
{<br />
DutyCycle = DUTY_CYCLE_DEFAULT;<br />
eeprom_writeByte( &eeDutyCycle, DutyCycle );<br />
}<br />
<br />
...<br />
</syntaxhighlight><br />
<br />
=== Direkter Zugriff auf EEPROM-Adressen ===<br />
<br />
Will man direkt auf bestimmte EEPROM Adressen zugreifen, dann sind folgende IAR-kompatiblen Makros <tt>_EEGET</tt> und <tt>_EEPUT</tt> hilfreich, um sich die Typecasts zu ersparen.<br />
<br />
;Hinweis: Die nachfolgend gezeigten Makros und Zugriffe auf absolute Adressen sind in Normalfall nicht nötig und nur auf sehr wenige, spezielle Fälle beschränkt! Im Normalfall sollte man auf absolute Adressen möglichst nicht zugreifen und den Compiler seine Arbeit machen lassen, der verwaltet die Variablen und deren Adressen meist besser als der Programmierer. Der Zugriff auf Variablen im EEPROM sollte immer über ihren Namen erfolgen.<br />
<br />
Verwendung:<br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/eeprom.h><br />
<br />
_EEPUT (0x20, 128); // Byte-Wert 128 an Adresse 0x20 schreiben<br />
...<br />
uint8_t val = _EEGET (0x20); // EEPROM-Wert von Adresse 0x20 lesen<br />
</syntaxhighlight><br />
<br />
=== Was steckt dahinter? - EEPROM-Register ===<br />
Auch wenn es normalerweise keinen Grund gibt, in C selbst an den Steuerregistern herumzuschrauben - die eeprom Funktionen erledigen das alles zuverlässig - der Vollständigkeit halber der registermässige technische Unterbau.<br />
Um das EEPROM anzusteuern, sind drei Register von Bedeutung:<br />
;EEAR: Hier werden die Adressen eingetragen zum Schreiben oder Lesen. Dieses Register unterteilt sich nochmal in EEARH und EEARL, da in einem 8-Bit-Register keine 512 Adressen adressiert werden können.<br />
;EEDR: Hier werden die Daten eingetragen, die geschrieben werden sollen, bzw. es enthält die gelesenen Daten.<br />
;EECR: Ist das Kontrollregister für das EEPROM<br />
<br />
Das EECR steuert den Zugriff auf das EEPROM und ist wie folgt aufgebaut:<br />
<br />
:{| class="wikitable" style="text-align:center"<br />
|+ '''Aufbau des EECR-Registers'''<br />
|-<br />
!Bit<br />
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0<br />
|-<br />
! Name<br />
| - || - || - ||- || EERIE || EEMWE || EEWE || EERE<br />
|-<br />
! Read/Write<br />
| R || R || R || R || R/W || R/W || R/W || R/W<br />
|-<br />
!Init Value<br />
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0<br />
|}<br />
<br />
'''Bedeutung der Bits'''<br />
<br />
;Bit 4-7: nicht belegt<br />
<br />
;Bit 3 (EERIE): ''EEPROM Ready Interrupt Enable'': Wenn das Bit gesetzt ist und globale Interrupts erlaubt sind in Register SREG (Bit 7), wird ein Interrupt ausgelöst nach Beendigung des Schreibzyklus (EEPROM Ready Interrupt). Ist einer der beiden Bits 0, wird kein Interrupt ausgelöst.<br />
<br />
;Bit 2 EEMWE): ''EEPROM Master Write Enable'': Dieses Bit bestimmt, dass, wenn EEWE = 1 gesetzt wird (innerhalb von 4 Taktzyklen), das EEPROM beschrieben wird mit den Daten in EEDR bei Adresse EEAR. Wenn EEMWE = 0 ist und EEWE = 1 gesetzt wird, hat das keine Auswirkungen. Der Schreibvorgang wird dann nicht ausgelöst. Nach 4 Taktzyklen wird das Bit EEMWE automatisch wieder auf 0 gesetzt. Dieses Bit löst den Schreibvorgang nicht aus, es dient sozusagen als Sicherungsbit für EEWE.<br />
<br />
;Bit 1 (EEWE): ''EEPROM Write Enable'': Dieses Bit löst den Schreibvorgang aus, wenn es auf 1 gesetzt wird, sofern vorher EEMWE gesetzt wurde und seitdem nicht mehr als 4 Taktzyklen vergangen sind. Wenn der Schreibvorgang abgeschlossen ist, wird dieses Bit automatisch wieder auf 0 gesetzt und, sofern EERIE gesetzt ist, ein Interrupt ausgelöst. Ein Schreibvorgang sieht typischerweise wie folgt aus:<br />
:# EEPROM-Bereitschaft abwarten (EEWE=0) <br />
:# Adresse übergeben an EEAR<br />
:# Daten übergeben an EEDR<br />
:# Schreibvorgang auslösen in EECR mit Bit EEMWE=1 und EEWE=1<br />
:# (Optional) Warten, bis Schreibvorgang abgeschlossen ist<br />
<br />
;Bit 0 EERE: ''EEPROM Read Enable'': Wird dieses Bit auf 1 gesetzt wird das EEPROM an der Adresse in EEAR ausgelesen und die Daten in EEDR gespeichert. Das EEPROM kann nicht ausgelesen werden, wenn bereits eine Schreiboperation gestartet wurde. Es ist daher zu empfehlen, die Bereitschaft vorher zu prüfen. Das EEPROM ist lesebereit, wenn das Bit EEWE=0 ist. Ist der Lesevorgang abgeschlossen, wird das Bit wieder auf 0 gesetzt, und das EEPROM ist für neue Lese- und Schreibbefehle wieder bereit. Ein typischer Lesevorgang kann wie folgt aufgebaut sein:<br />
:# Bereitschaft zum Lesen prüfen (EEWE=0)<br />
:# Adresse übergeben an EEAR<br />
:# Lesezyklus auslösen mit EERE = 1<br />
:# Warten, bis Lesevorgang abgeschlossen EERE = 0<br />
:# Daten abholen aus EEDR<br />
<br />
= Die Nutzung von sprintf und printf =<br />
<br />
Um komfortabel, d.h. formatiert, Ausgaben auf ein Display oder die serielle Schnittstelle zu tätigen, bieten sich '''sprintf''' oder '''printf''' an. Alle *printf-Varianten sind jedoch ziemlich speicherintensiv und der Einsatz in einem Mikrocontroller mit knappem Speicher muss sorgsam abgewogen werden.<br />
<br />
Bei '''sprintf''' wird die Ausgabe zunächst in einem Puffer vorbereitet und anschließend mit einfachen Funktionen zeichenweise ausgegeben. Es liegt in der Verantwortung des Programmierers, genügend Platz im Puffer für die erwarteten Zeichen bereitzuhalten.<br />
<br />
<syntaxhighlight lang="c"><br />
#include <stdio.h><br />
#include <stdint.h><br />
<br />
// ...<br />
// nicht dargestellt: Implementierung von uart_puts (vgl. Abschnitt UART)<br />
// ...<br />
<br />
uint16_t counter;<br />
<br />
// Ausgabe eines unsigned Integerwertes<br />
void uart_puti( uint16_t value )<br />
{<br />
uint8_t puffer[20];<br />
<br />
sprintf( puffer, "Zählerstand: %u", value );<br />
uart_puts( puffer );<br />
}<br />
<br />
int main()<br />
{<br />
counter = 5;<br />
<br />
uart_puti( counter );<br />
uart_puti( 42 );<br />
}<br />
</syntaxhighlight><br />
<br />
Eine weitere elegante Möglichkeit besteht darin, den STREAM stdout (Standardausgabe) auf eine eigene Ausgabefunktion umzuleiten. Dazu wird dem Ausgabemechanismus der C-Bibliothek eine neue Ausgabefunktion bekannt gemacht, deren Aufgabe es ist, ein einzelnes Zeichen auszugeben. Wohin die Ausgabe dann tatsächlich stattfindet, ist Sache der Ausgabefunktion. Im Beispiel unten wird auf UART ausgegeben. Alle anderen, höheren Funktionen wie z.&nbsp;B. '''printf''', greifen letztendlich auf diese primitive Ausgabefunktion zurück. <br />
<br />
<syntaxhighlight lang="c"><br />
#include <avr/io.h><br />
#include <stdio.h><br />
<br />
void uart_init(void);<br />
<br />
// a. Deklaration der primitiven Ausgabefunktion<br />
int uart_putchar(char c, FILE *stream);<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 1)<br />
static FILE mystdout = FDEV_SETUP_STREAM( uart_putchar, NULL, _FDEV_SETUP_WRITE );<br />
<br />
// c. Definition der Ausgabefunktion<br />
int uart_putchar( char c, FILE *stream )<br />
{<br />
if( c == '\n' )<br />
uart_putchar( '\r', stream );<br />
<br />
loop_until_bit_is_set( UCSRA, UDRE );<br />
UDR = c;<br />
return 0;<br />
}<br />
<br />
void uart_init(void)<br />
{<br />
/* hier µC spezifischen Code zur Initialisierung */<br />
/* des UART einfügen... s.o. im AVR-GCC-Tutorial */<br />
<br />
// Beispiel: <br />
//<br />
// myAVR Board 1.5 mit externem Quarz Q1 3,6864 MHz<br />
// 9600 Baud 8N1<br />
<br />
#ifndef F_CPU<br />
#define F_CPU 3686400<br />
#endif<br />
#define UART_BAUD_RATE 9600<br />
<br />
// Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt)<br />
#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)<br />
<br />
UCSRB |= (1<<TXEN) | (1<<RXEN); // UART TX und RX einschalten<br />
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1 <br />
<br />
UBRRH = (uint8_t)( UART_UBRR_CALC( UART_BAUD_RATE, F_CPU ) >> 8 );<br />
UBRRL = (uint8_t)UART_UBRR_CALC( UART_BAUD_RATE, F_CPU );<br />
}<br />
<br />
int main(void)<br />
{<br />
int16_t antwort = 42;<br />
uart_init();<br />
<br />
// b. Umleiten der Standardausgabe stdout (Teil 2)<br />
stdout = &mystdout;<br />
<br />
// Anwendung<br />
printf( "Die Antwort ist %d.\n", antwort );<br />
return 0;<br />
}<br />
<br />
// Quelle: avr-libc-user-manual-1.4.3.pdf, S.74<br />
// + Ergänzungen<br />
</syntaxhighlight><br />
<br />
<br />
Sollen Fließkommazahlen ausgegeben werden, muss im Makefile eine andere (größere) Version der [[FAQ#Aktivieren_der_Floating_Point_Version_von_sprintf_beim_WinAVR_mit_AVR-Studio|printflib]] eingebunden werden.<br />
<br />
= Anmerkungen =<br />
<references/><br />
<br />
= TODO =<br />
* Aktualisierung Register- und Bitbeschreibungen an aktuelle AVR<br />
* "naked"-Funktionen [http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html][http://arduino.stackexchange.com/questions/8758/arduino-interruption-on-pin-change]<br />
<br />
[[Kategorie:avr-gcc Tutorial| ]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=Interrupt&diff=107255Interrupt2025-01-27T13:49:43Z<p>Heha: Verweis auf DMA (für ISRs die nur Daten schaufeln)</p>
<hr />
<div>Bei bestimmten Ereignissen in Prozessoren wird ein '''Interrupt''' (Unterbrechungsanforderung) registriert. <br />
<br />
Bei [[Mikrocontroller]]n werden Interrupts z.&nbsp;B. ausgelöst wenn:<br />
* sich der an einem bestimmten Eingangs-Pin anliegende Pegel ändert<br />
* eine vorher festgelegte Zeitspanne abgelaufen ist ([[Timer]])<br />
* eine [[Seriell|serielle]] Übertragung abgeschlossen ist<br />
* eine Messung des [[ADC |Analog-Digital-Wandlers]] abgeschlossen ist<br />
<br />
Die Registrierung eines Interrupts setzt ein passend zum Ereignis benanntes '''Interruptflag''' in Form eines Bits in einem speziellen Statusregister. Bei der Behandlung des Interrupts wird das Anwendungsprogramm unterbrochen, das auslösende Interruptflag gelöscht und ein Unterprogramm, die sogenannte '''I'''nterrupt '''S'''ervice '''R'''outine ('''ISR'''), aufgerufen. Wenn dieses beendet ist, läuft das Anwendungsprogramm ganz normal weiter.<br />
<br />
== Wichtige Eigenschaften von ISRs ==<br />
<br />
ISRs reagieren auf ein bestimmtes Ereignis, welches relativ oft oder selten passiert. Prinzipiell sollte man ISRs möglichst (zeitlich) kurz halten und schnell beenden. <br />
<br />
Im Mittel muss die ISR kürzer sein als die Periodendauer des Ereignisses, andernfalls wird es passieren, dass Interrupts „verschluckt“ werden, d.h. beim UART gehen Daten verloren, beim Timer gehen Zählzyklen verloren, beim AD-Wandler gehen Daten verloren usw. Solche verschluckten Interrupts sind schwer zu finden, weil es nur sehr wenige in ganz bestimmten Konstellationen sind. Wenn dann eine per Timer realisierte Uhr in der Stunde um 1 s falsch geht, merkt man das oft nicht. Langwierige Berechnungen, Auswertungen, Ausgaben oder gar Warteschleifen haben daher in ISRs nichts zu suchen. Auch typische C-Funktionen wie <tt>printf()</tt>, <tt>scanf()</tt>, Ausgaben auf ein [[LCD]] usw. sollte man <i>nie</i> in ISRs vornehmen. <br />
<br />
Stattdessen kommt bei Interruptbetrieb sinnvollerweise eine andere Programmiertechnik zum Einsatz, nämlich die Übergabe von Parametern bzw. Steuersignalen an das Hauptprogramm. Fachsprachlich handelt es sich um ein „bottom half“ (Linux) oder um einen „Aufgeschobenen Prozeduraufruf“ (DPC, Windows). Hierbei ist wichtig, dass die Steuerbits („Flags“), welche gemeinsam im Interrupt-Programmteil und im Nicht-Interrupt-Programmteil verwendet werden, mit dem Schlüsselwort [[Interrupt#Weblinks|volatile]] deklariert werden. Dadurch wird sichergestellt, dass jeder Zugriff auf die Variable im Code auch in die entsprechenden Maschinenbefehle umgesetzt wird und nicht wegoptimiert wird, weil sich die Variable in einem der beiden unabhängigen Programmteile scheinbar nicht ändert. Außerdem müssen sowohl der Lese- als auch Schreibzugriff auf Steuervariablen ununterbrechbar ([[Interrupt#Atomarer Datenzugriff|atomar]]) sein.<br />
<br />
Für die Steuerbits bietet sich die Verwendung von <tt>GPIOR0</tt> an, welches volatil und bitadressierbar in den meisten AVR-Controllern zur Verfügung steht.<br />
<br />
=== Interruptsteuerung ===<br />
<br />
Interrupts müssen wie alle anderen Module und Funktionen eines Mikrocontrollers gesteuert werden. Dazu wird auf praktisch allen Mikrocontrollern ein zweistufiges System verwendet.<br />
* Globale Interruptfreigabe über ein CPU-Statusbit: Beim [[AVR]] ist das das I-Bit (Interrupt) im Statusregister (SREG). Dieses Bit wirkt wie ein Hauptschalter und kann global die Ausführung aller Interrupts ein - und ausschalten. Das heisst aber nicht, dass während der Zeit der inaktiven Interrupts diese verloren gehen. Vielmehr wird das jeweilige Interruptbit gesetzt, und wenn die Interrupts wieder freigegeben werden wird der Interrupt ausgeführt. Verloren gehen Interrupts erst dann, wenn die Sperrzeit zu groß ist und währenddessen mehr als ein Interrupt vom selben Typ eintrifft. Siehe [[Interrupt#Zeitverhalten eines Timerinterrupts|Beispiel 1]] und [[Interrupt#Zeitverhalten des UART Empfangsinterrupts|Beispiel 2]].<br />
* Lokale Interruptsteuerung für jede einzelne Interruptquelle über Maskenbits in mehreren Interruptmaskenregistern. Hier kann jede einzelne Interruptquelle individuell ein- und ausgeschaltet werden.<br />
<br />
Dieses System hat eine Reihe von Vorteilen.<br />
So können sehr schnell und einfach alle Interrupts kurzzeitig gesperrt werden, wenn beispielsweise [[Interrupt#Atomarer Datenzugriff | atomare]] Operationen durchgeführt werden sollen, oder besonders zeitkritische Abläufe ausgeführt werden. Danach können alle konfigurierten Interrupts einfach wieder freigeschaltet werden, ohne dass die CPU viele verschiedene Interruptmaskenbits verwalten müsste.<br />
<br />
<br />
Eine ISR wird demnach nur dann ausgeführt, wenn<br />
* die Interrupts global freigeschaltet sind<br />
* das individuelle Maskenbit gesetzt ist<br />
* der Interrupt eintritt bzw. anliegt<br />
<br />
=== Verschachtelte Interrupts ===<br />
<br />
Einige Mikrocontroller, wie z.&nbsp;B. der [[AVR]] kennen nur zwei CPU-Zustände. Normale Programmausführung und Interruptausführung, gesteuert durch das I-Bit der CPU. Die normale Programmausführung kann jederzeit durch Interrupts unterbrochen werden. Die Interruptausführung kann nicht durch neue Interrupts unterbrochen werden. Die ISR wird erst zu Ende bearbeitet, zurück in die normale Programmausführung gesprungen und erst dann werden neue, wartende (engl. pending = anliegend) Interrupts bearbeitet.<br />
<br />
Etwas komplexere Mikrocontroller oder große Prozessoren bieten verschiedene Interruptlevel (Stufen) an. Dabei gilt meist je niedriger die Zahl des Levels, um so höher die Priorität. Ein Interrupt mit höherer Priorität kann einen Interrupt mit niedriger Priorität unterbrechen.<br />
Ein Interrupt mit gleicher Priorität wie der gerade bearbeitete Interrupt kann das im allgemeinen nicht.<br />
Das nennt man verschachtelte Interrupts (engl. nested interrupts).<br />
Klassische Vertreter hierfür sind PIC18, [[8051]], PowerPC, [[X86]] und Motorola 68000.<br />
<br />
Auf dem AVR kann man [[AVR-GCC-Tutorial#Unterbrechbare_Interruptroutinen | verschachtelte Interrupts]] sowohl in Assembler als auch in C nachbilden, allerdings mit einigen Einschränkungen und Tücken.<br />
Das ist jedoch Leuten vorbehalten, die schon viel Erfahrung auf diesem Gebiet haben.<br />
Zu 99,9% braucht man sie nicht, und wenn doch sollte das Problem besser mittels DPC und einer globalen <tt>idle()</tt>-Routine gelöst werden.<br />
<br />
=== Wie lange dauert meine Interruptroutine? ===<br />
<br />
Diese Frage sollte man beantworten können, zumindest sollte eine Worst-Case-Abschätzung gemacht werden. Das geht auf zwei Wegen.<br />
<br />
* Simulation, dabei muss in einer verzweigten ISR der längste Pfad simuliert werden. Dazu müssen alle beteiligten Variablen auf den ensprechenden Wert gesetzt werden.<br />
* Abzählen der Takte im Assembler- oder Disassemblerlisting<br />
* Messung mit dem [[Oszilloskop]], dabei wird zum Beginn der ISR ein Pin auf HIGH gesetzt und am Ende auf LOW. Damit kann man in Echtzeit die Dauer der ISR messen. Die zusätzlichen Taktzyklen zum Aufruf und verlassen der ISR sind konstant und im wesentlichen bekannt. Mit einem modernen Digitaloszilloskop und dem "Infinite Persistence Mode" kann man eine Worst-Case-Messung vornehmen<br />
<br />
Als Hilfsmittel zur Fehlersuche kann man auch am Ende der ISR prüfen, ob das jeweilige Interrupt-Request-Bit schon wieder gesetzt ist. Wenn ja, dann ist die ISR in den meisten Fällen zu lang. Auch hier kann man einen Ausgang auf HIGH setzen und somit den Fehler anzeigen.<br />
<br />
In hartnäckigen Fällen lässt der Check auf das Interrupt-Request-Bit am ISR-Ende zum wiederholten Ausführen des Interrupt-Kodes verwenden. Diese Technik nennt sich „tail chaining“ und spart den Aufwand des Register-Rettens und -Wiederherstellens, kann jedoch zur Folge haben, dass andere ISRs und das Hauptprogramm nicht mehr zum (Schach-)Zug kommen. Das nennt man „verhungern“, englisch „starvation“.<br />
<br />
=== Zeitverhalten eines Timerinterrupts ===<br />
<br />
Ein Timerinterrupt wird im allgemeinen dazu genutzt, in konstanten, periodischen Abständen bestimmte Funktionen aufzurufen. Es ist möglich, dass während eines Timerinterrupts derselbe Interrupt wieder aktiv wird, weil die Routine sehr verzweigt ist und dieses Mal sehr lange dauert.<br />
<br />
Wenn zum Beispiel der Timerinterrupt mit einer Periodendauer von 100ms aufgerufen wird, er aber unter bestimmten Umständen 180ms benötigt, dann wird nach 100ms nach Eintritt in die ISR der Interrupt wieder aktiv, das Timer Interrupt Flag wird gesetzt. Da aber gerade ein Interrupt bearbeitet wird, wird er nicht sofort angesprungen, weil währenddessen die Interruptfunktion global gesperrt ist (beim AVR ist das I-Bit in der CPU gelöscht). Der Interrupt wird zu Ende bearbeitet, die CPU springt zurück zum Hauptprogramm. Dabei werden die Interrupts wieder global eingeschaltet. Der zwischenzeitlich eingetroffene und zwischengespeicherte Interrupt wird nun sofort ausgeführt, sodass das Hauptprogramm praktisch gar nicht weiter kommt, bestenfalls einen Maschinenbefehl. Nun sind aber nur noch 20ms bis zum nächsten Timerinterrupt übrig. Wenn dieser nun wieder 180 ms benötigt werden in dieser Zeit aber '''zwei''' Interrupts ausgelöst, nach 20ms und 120ms. Da diese aber nicht gezählt oder andersweitig einzeln gespeichert werden können, geht ein Interrupt verloren. Das ist ein Programmfehler.<br />
<br />
=== Zeitverhalten des UART Empfangsinterrupts ===<br />
<br />
Ein [[UART]] Interrupt zum Empfang von Daten per [[RS232]] mit 115200 [[Baud]] ist ein recht häufiges Ereignis (1 Zeichen = 10 Bits = 86,8&mu;s). Wenn kontinuierlich Daten empfangen werden, wird nach jeweils 86,8&mu;s ein neuer Interrupt ausgelöst. Dabei wird das empfangene Datenbyte vom UART aus dem Empfangsschiebegregister in einem Puffer kopiert. Während das neue Zeichen Bit für Bit empfangen wird, wird es zunächst im Schieberegister des UART gespeichert. Die Daten im Puffer bleiben davon unberührt. Die CPU muss nun schnell das empfangene Datenbyte aus dem Empfangsbuffer auslesen. Die maximale Verzögerung, die sich die CPU erlauben kann von der Aktivierung des Interrupts bis zum tatsächlichen Auslesen des Datenregisters beträgt ziemlich genau die Übertragungszeit von einem Zeichen. Wenn bis dahin nicht das Zeichen von der CPU ausgelesen wurde, wird es vom UART überschrieben und ein Fehler im Statusregister des UART signalisiert (Overrun, Überlauf des Datenpuffers). Die UARTs in heutigen Mikrocontrollern haben mindestens ein Byte Puffer wie hier beschrieben. Die neueren [[AVR]]s haben sogar effektiv 3 Byte Puffer im UART, praktisch ein kleines [[FIFO]], womit der Datenempfang besser gepuffert werden kann, wenn die CPU gerade mit anderen sehr wichtigen Dingen beschäftigt ist. D.h. kurzzeitig kann sich die CPU erlauben, die Übertragungszeit von bis zu drei Zeichen zu warten, ehe sie die Daten ausliest. Dann müssen sie aber sehr schnell hintereinander gelesen werden. Im Mittel hat die CPU aber nur die Übertragungszeit <i>eines</i> Zeichens zur Verfügung, um es abzuholen.<br />
<br />
Bei Mikrocontrollern mit DMA (Direct Memory Access, praktisch alle 32-Bit-Mikrocontroller) ist in so einem Fall <i>unbedingt</i> der DMA für den Zeichenempfang zu benutzen, denn genau dafür ist er da. Das ist jedoch anfänglich schwieriger zu programmieren und erfordert ein noch tiefgreifenderes Datenblattstudium.<br />
<br />
=== Zusammenfassung ===<br />
<br />
Interruptserviceroutinen:<br />
* sollten so kurz wie möglich gehalten werden<br />
* können im Einzelfall nahezu doppelt so lange dauern wie die kürzeste Periodendauer des Ereignisses, ohne dass Interrupts verloren gehen (z.&nbsp;B. Timerinterrupt).<br />
* dürfen im Mittel maximal solange dauern wie die kürzeste Periodendauer des Ereignisses<br />
* dürfen maximal solange dauern, wie die kürzeste Periodendauer des Ereignisses, wenn man auf Nummer sicher gehen will, dass keine Interrupts verschluckt werden<br />
* Die Interruptzeit versteht sich immer abzüglich einer kleinen Reserve für das Anspringen und Verlassen des Interrupt minus Panikreserve<br />
<br />
==Interruptfeste Programmierung==<br />
<br />
=== Atomarer Datenzugriff ===<br />
<br />
Von einem atomaren Zugriff (engl. atomic access) spricht man, wenn der Zugriff innerhalb einer nicht unterbrechbaren Instruktionsfolge abgearbeitet wird.<br />
<br />
Alle Variablen, Steuerregister und I/O-Ports, die sowohl im Hauptprogramm als auch in Interrupts verwendet werden, sind mit viel Sorgfalt zu behandeln.<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
port |= 0x03;<br />
</syntaxhighlight><br />
übersetzt sich auf AVR-Prozessoren in<br />
<syntaxhighlight lang="avrasm"> <br />
IN r16,port<br />
ORI r16,0x03<br />
OUT port,r16<br />
</syntaxhighlight><br />
Wenn nun zwischen IN und OUT ein Interrupt auftritt, der beispielsweise Bit&nbsp;7 verändert, dann geht mit dem OUT-Befehl diese Änderung verloren, da der OUT-Befehl den alten Zustand vor dem Interrupt wiederherstellt.<br />
<br />
'''Gefährlich ist das insbesondere deshalb, weil der Fall nur selten auftritt und dieses Verhalten sehr schlecht reproduzierbar ist!'''<br />
<br />
Bei verschiedenen Prozessor-Architekturen tritt das Problem verschieden häufig auf. So übersetzt sich obiger Code bei MSP430 Prozessoren in einen einzelnen Befehl<br />
<pre><br />
OR #0x03,port<br />
</pre><br />
und stellt somit kein Problem dar. Im Zweifel hilft nur ein Blick in den erzeugten Assembler-Code. Bei der Übernahme fremden Codes ist dies zu beachten. Was beim [[8051]] kein Problem war, kann beim [[AVR]] zu einem Problem werden, unter Umständen sogar abhängig vom verwendeten Port sein (einige Ports bzw. I/O Register können mit den atomaren Befehlen sbi, cbi zum Setzen und Löschen einzelner Bits erreicht werden, andere nicht).<br />
<br />
Ein ähnliches Problem entsteht bei Variablen, deren Größe die Wortbreite der Maschine übersteigt, unter Umständen auch Bitfeld-Zugriffe. Bei 8-Bit-Prozessoren wie AVR oder 8051 also bereits bei normalen "int" Variablen. Diese Variablen werden zwangsläufig byteweise verarbeitet. Wenn genau dazwischen ein Interrupt erfolgt, wird ein falscher Wert gelesen. Wenn beispielsweise eine Interrupt-Routine einen 16-Bit-Zähler verwendet und von 0x00FF auf 0x0100 hochzählt, dann kann das Hauptprogramm auch schon mal versehentlich die Werte 0x01FF oder 0x0000 lesen. Ein Beispiel.<br />
<br />
<syntaxhighlight lang="c"><br />
/* var wird in einer ISR inkrementiert */<br />
volatile int var;<br />
<br />
int get_var (void)<br />
{<br />
/* Folgende Zuweisung besteht aus mehr als einem Maschinenbefehl */<br />
return var;<br />
}<br />
</syntaxhighlight><br />
<br />
Das Lesen von var ist in C nur ein Befehl, in Assembler werden aber mindestens 2 Befehle benötigt, da pro Maschinen-Befehl nur 8&nbsp;Bit bewegt werden können.<br />
Die Zuweisung kann also unterbrochen werden. Das kann dazu führen, daß ein Teil alter Bits und ein Teil neuer Bits zugewiesen wird:<br />
<br />
# var sei 0x00FF<br />
# Das Lowbyte von var wird für die return-Anweisung gelesen: 0xFF<br />
# Ein Interrupt inkrementiert var um 1 auf 0x0100<br />
# Das Highbyte von var wird in für die return-Anweisung gelesen: 0x01<br />
# Die Funktion gibt 0x01FF zurück<br />
<br />
Dies ist auch ein Grund, weshalb für Programmierung auf derart maschinennaher Ebene Kenntnisse in Prozessorarchitektur und Assembler-Programmierung sehr hilfreich sind.<br />
<br />
'''Abhilfe''': Wenn man sich nicht wirklich ganz sicher ist, müssen um kritische Aktivitäten herum jedesmal die Interrupts abgeschaltet werden.<br />
<br />
Beispiel ([[AVR-GCC]]):<br />
<syntaxhighlight lang="c"><br />
// Manuelle Methode<br />
cli(); // Interrupts abschalten<br />
port |= 0x03;<br />
sei(); // Interrupts wieder einschalten<br />
<br />
// Per Macros aus dem avr gcc, schöner lesbar und bequemer<br />
// siehe Doku der avr-libc, Abschnitt <util/atomic.h><br />
ATOMIC_BLOCK(ATOMIC_FORCEON) {<br />
port |= 0x03; <br />
}<br />
</syntaxhighlight><br />
<br />
Wenn man ein globales Einschalten der Interrupts mit sei() vermeiden will, kann man die folgende Methode benutzen. Hierbei werden die Interrupts nur eingeschaltet, wenn sie vorher bereits eingeschaltet waren (Hinweis aus der FAQ von avr-libc):<br />
<br />
<syntaxhighlight lang="c"><br />
{<br />
// ...<br />
{<br />
uint8_t sreg_local; // Lokale Sicherungskopie von SREG<br />
sreg_local = SREG;<br />
cli();<br />
// hierhin kommt der Code mit atomarem Zugriff<br />
SREG = sreg_local;<br />
} <br />
<br />
// wieder per Macro<br />
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {<br />
// hierhin kommt der Code mit atomarem Zugriff<br />
}<br />
// ...<br />
}<br />
</syntaxhighlight><br />
<br />
Je nach Prozessor kann man das Problem manchmal auch ohne Abschalten von Interrupts durch geeignete Programmierung lösen. So führt<br />
<syntaxhighlight lang="c"><br />
port = (port & ~0x0F) | lcd_data;<br />
</syntaxhighlight><br />
immer zum beschriebenen Problem,<br />
<syntaxhighlight lang="c"><br />
port &= ~0x0F;<br />
port |= lcd_data;<br />
</syntaxhighlight><br />
jedoch nicht, wenn die beiden Zeilen zu jeweils einem Assembler-Befehl übersetzt werden, wie z.B. auf dem MSP430, nicht jedoch auf dem AVR. Was dann aber abhängig von den Optimierungs-Einstellungen des Compilers werden kann. Eine interruptfeste Variante für AVR-Prozessoren der neuesten Generation, wie beispielsweise Tiny2313 und Mega88 (alle ab 2004):<br />
<syntaxhighlight lang="c"><br />
PINx = (PORTx & 0x0F) ^ lcd_data;<br />
</syntaxhighlight><br />
<br />
Wenn man diese Tricks nutzt, sollte man sie auch sehr gut und eindeutig mit einem Kommentar dokumentieren! Im Zweifelsfall sollte man lieber den soliden, eindeutigen Weg wählen und die Interrupts kurz sperren. Diese Methode ist auch gefahrlos auf andere Controller portierbar.<br />
<br />
=== Reentrante Funktionen ===<br />
<br />
Eine Funktion ist reentrant (wiedereintrittsfest), wenn sie mehrmals gleichzeitig aktiv sein kann, ohne dass sich diese Aufrufe gegenseitig beeinflussen. Betrifft beispielsweise Funktionen, die sowohl im Hauptprogramm als auch in Interrupts aufgerufen werden. Manche C Compiler erfordern eine besondere Kennzeichnung solcher Funktionen. Wenn möglich sollte man es jedoch vermeiden, eine Funktion aus dem Hauptprogramm '''und''' aus einem Interrupt aus aufzurufen. Das ist meist problemlos machbar.<br />
<br />
=== Volatile Variablen ===<br />
Variablen, auf die sowohl innerhalb wie auch außerhalb einer Interruptserviceroutine zugegriffen wird (schreibend oder lesend), müssen (ähnlich wie Hardwareregister) mit dem Schlüsselwort '''volatile''' (flüchtig) versehen werden, damit der C-Compiler berücksichtigen kann, dass diese Variablen jederzeit (durch das Auftreten des Interrupts) gelesen oder geschrieben werden können.<br />
Ansonsten würde der C-Compiler das regelmäßige Abfragen oder Beschreiben dieser Variablen ggf. wegoptimieren, da er nicht damit rechnet, dass auf die Variable auch "ohne sein Zutun" zugegriffen wird.<br />
<br />
Eine ausführlichere Erklärung zu "volatile" ist hier zu finden: <br />
[http://www.mikrocontroller.net/articles/FAQ#Was_hat_es_mit_volatile_auf_sich FAQ: Was hat es mit volatile auf sich]<br />
<br />
== Interrupts und Low Power Modes (Sleep) ==<br />
<br />
Wenn der Microcontroller in einen Low Power Mode versetzt wird, wird er durch einen Interrupt wieder aufgeweckt, z.B. in einem festen Zeitraster per Timer-Interrupt oder vom ADC nach Beendigung einer AD-Wandlung.<br />
Dabei muß sichergestellt werden, daß der Interrupt erst nach dem In-Low-Power-Gehen (z.B. per Befehl ''sleep()'') kommen kann, da sonst der µC nicht bzw. nicht rechtzeitig geweckt wird. Dazu muß eine Möglichkeit bestehen, daß der Interrupt gesperrt wird und erst mit dem Sleep-Befehl freigegeben wird. Dies scheint auf den ersten Blick unmöglich: Man kann nicht gleichzeitig zwei Befehle (''sei()'' und ''sleep()'') ausführen.<br />
Es gibt spezielle Mechanismen für diesen Fall. Beim C51 und beim AVR ist es z.B. so, daß ''sei()'' erst einen Befehl später "wirksam" wird. Dadurch wird die Kombination <br />
<syntaxhighlight lang="c"><br />
sei(); <br />
sleep();<br />
</syntaxhighlight><br />
ununterbrechbar (natürlich sofern zuvor die Interrupts gesperrt wurden).<br />
Andere Microcontroller bieten andere Mechanismen, z.B. sperrt der Assembler-Befehl<br />
<syntaxhighlight lang="c"><br />
DISI<br />
</syntaxhighlight> <br />
beim PIC24 die Interrupts für eine bestimmten Anzahl von CPU-Taktzyklen. Die CPU kann dann eine vorgegebene Anzahl an folgenden Befehlen unter Interruptsperre ausführen und der Interrupt wird automatisch wieder freigegeben.<br />
<br />
== (AVR-) Beispiele für die praktische Programmierung ==<br />
<br />
Die Beispiele sind mit WINAVR 20060421 compiliert und getestet worden. Als Mikrocontroller wird ein AVR vom Typ ATmega32 verwendet. Alle Programme wurden mit Optimierungsstufe -Os compiliert.<br />
<br />
=== Steuersignale zwischen ISR und Hauptprogramm ===<br />
<br />
In vielen Anwendungen wird ein [[Timer]] verwendet, um in regelmäßigen Abständen bestimmte Aktionen auszuführen, wie z.&nbsp;B. Tasten abfragen, ADC-auslesen, ein LCD auffrischen etc. Wenn viele Dinge zu erledigen sind, nebenbei aber noch andere Interrupts verwendet werden, dann ist es notwendig die Funktionsaufrufe aus dem Timerinterrupt in die Hauptschleife zu verlagern. Der Interrupt signalisiert über eine Steuervariable (engl. Flag, Flagge), dass ein neuer Timerzyklus begonnen hat. Dadurch wird der Timerinterrupt sehr kurz und die langwierigen, aber meist nicht zeitkritischen Funktionen werden als normales Programm ausgeführt. Damit kann die CPU auf andere Interrupts schnell reagieren.<br />
<br />
Wichtig ist auf jeden Fall, dass die Steuervariable, welche in der ISR und in der Hauptschleife verwendet wird, mit [http://www.netrino.com/Embedded-Systems/How-To/C-Volatile-Keyword '''volatile'''] deklariert wird. Ausserdem müssen sowohl der Lese- als auch Schreibzugriff auf die Steuersignale [[#Atomarer Datenzugriff | '''atomar''']] sein. Auf dem AVR ist das mit 8-Bit-Variablen direkt möglich, für grössere Variablen müssen die Interrupts kurzzeitig gesperrt werden.<br />
<br />
Das Beispiel ist sehr einfach gehalten um das Prinzip zu veranschaulichen. Ein Timer mit einer Überlaufperiodendauer von ca. 65ms stößt periodisch eine Funktion zum Togglen einer LED an, welche dadurch mit ca. 7 Hz blinkt.<br />
<br />
<syntaxhighlight lang="c"><br />
/*<br />
*******************************************************************************<br />
*<br />
* Timer Interrupt Demo<br />
*<br />
* ATmega32 mit internem 1-MHz-Oszillator<br />
*<br />
* LOW Fuse Byte = 0xE1<br />
*<br />
* An PD5 muss eine LED mit 1-kOhm-Vorwiderstand angeschlossen werden<br />
*<br />
*******************************************************************************<br />
*/<br />
<br />
#define F_CPU 1000000<br />
<br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
<br />
// globale Variablen<br />
<br />
volatile uint8_t flag;<br />
<br />
int main() {<br />
<br />
// IO konfigurieren<br />
<br />
DDRA = 0xFF;<br />
DDRB = 0xFF;<br />
DDRC = 0xFF;<br />
DDRD = 0xFF;<br />
<br />
// Timer2 konfigurieren<br />
<br />
TCCR2 = (1<<CS22) | (1<<CS21); // Vorteiler 256 -> ~65ms Überlaufperiode<br />
TIMSK |= (1<<TOIE2); // Timer Overflow Interrupt freischalten <br />
<br />
// Interrupts freigeben<br />
<br />
sei();<br />
<br />
// Endlose Hauptschleife<br />
<br />
while(1) {<br />
if (flag == 1) { // Neuer Timerzyklus ?<br />
flag = 0;<br />
<br />
// hier steht jetzt in Normalfall ein grosser Programmblock ;-) <br />
PORTD ^= (1 << PD5); // LED toggeln<br />
}<br />
}<br />
}<br />
<br />
// Timer2 overflow Interrupt<br />
// hier wird der Hauptschleife ein neuer Timerinterrupt signalisiert<br />
<br />
ISR( TIMER2_OVF_vect ) {<br />
flag = 1;<br />
}<br />
</syntaxhighlight><br />
<br />
=== UART mit Interrupts ===<br />
<br />
Der UART ist ein oft benutztes Modul eines Mikrocontrollers. Anfänger nutzen ihn meist im sogenannten Polling Betrieb (engl. to poll, abfragen). D.h. wenn ein Zeichen empfangen werden soll, fragt eine Funktion den UART in einer Schleife ununterbrochen ab, ob Daten empfangen wurden. In dieser Zeit macht die CPU nichts anderes! Und wenn lange kein Zeichen eintrifft tut sie sehr lange nichts, sie ist praktisch blockiert! Senden verläuft ähnlich, nur dass hier die CPU vor dem Senden prüft, ob der UART ein neues Byte aufnehmen kann. D.h. während der UART selbsttätig das Zeichen sendet ist die CPU zum Warten verdammt. All diese Nachteile haben nur einen Vorteil. Die Funktionen und Mechanismen zur UART-Nutzung sind sehr einfach, klein und leicht anwendbar.<br />
<br />
Will man aber die CPU nicht sinnlos warten lassen, was vor allem bei niedrigeren Baudraten ziemlich lange sein kann, muss man die Interrupts nutzen. Der AVR hat gleich drei davon.<br />
<br />
* '''RXC''' (Receive Complete): Ein Zeichen wurde empfangen.<br />
* '''UDRE''' (UART Data Register Empty): Der Zwischenpuffer des Senders ist leer und kann ein neues Zeichen aufnehmen. Dieser Zwischenpuffer ist wichtig, um lückenlos auch bei hohen Baudraten senden zu können.<br />
* '''TXC''' (Transmit Complete): Das aktuelle Zeichen wurde vollständig inclusive Stopbit gesendet und es liegt kein neues Datenbyte im Sendepuffer. Dieser Interrupt ist extrem nützlich für eine Halbduplexkommunikation, z.&nbsp;B. auf einem RS485-[[Bus]]. Hier kann man nach dem vollständigen Senden aller Bytes den Bustranceiver (z.&nbsp;B. MAX485) von Senden auf Empfangen umschalten, um den Bus freizugeben.<br />
<br />
Bei Nutzung der Interrupts kann die CPU andere Dinge bearbeiten und muss nur kurz einen Interrupt ausführen, wenn ein Zeichen empfangen oder gesendet wurde.<br />
<br />
Die Kommunikation zwischen ISRs und Hauptschleife erfolgt wieder durch Flags und zwei Pufferarrays (uart_rx_buffer und uart_tx_buffer). Es gibt zwei Funktionen, eine zum Senden von Strings, eine zum Empfangen. Das Senden sowie Empfangen kann parallel erfolgen und läuft vollkommen unabhängig vom Hauptprogramm. Die Daten werden in spezielle Puffer kopiert, sodass das Hauptprogramm mit seinen Strings sofort weiterarbeiten kann. Im Beispiel ist die CPU nicht wirklich mit sinnvollen Dingen beschäftigt, zur Demonstration des Prinzips aber ausreichend.<br />
<br />
Um das Programm real zu nutzen braucht man ein Terminalprogramm, z.&nbsp;B. Hyperterminal von Windows. Dort muss nur die richtige Baudrate eingestellt werden (9600 8N1, 9600 Baud, 8 Bits, keine Parität, 1 Stopbit, keine Flusskontrolle). Ausserdem muss man im Menu Datei -> Eigenschaften -> Einstellungen -> ASCII Konfiguration den Punkt "Eingegebene Zeichen lokal ausgeben (lokales Echo)" aktivieren. Nun kann man beliebige Texte eintippen. Mit RETURN wird die Eingabe abgeschlossen und der AVR vermittelt den empfangenen String an das Hauptprogramm. Diese sendet ihn einfach zurück, parallel dazu wird der String gemorst per LED angezeigt. Sollte es Probleme bei der Inbetriebnahme des UART geben, so findet man hier wichtige Hinweise zur [[AVR_Checkliste#UART.2FUSART | Fehlersuche]].<br />
<br />
<syntaxhighlight lang="c"><br />
/*<br />
*******************************************************************************<br />
*<br />
* UART Interrupt Demo<br />
*<br />
* ATmega32 mit 3,6864 MHz Quarz an XTAL1/XTAL2<br />
*<br />
* LOW Fuse Byte = 0xFF<br />
*<br />
* An PD5 muss eine LED mit 1-kOhm-Vorwiderstand angeschlossen werden<br />
* An PD0/PD1 ist ein MAX232 angeschlosssen, um Daten vom PC zu empfangen/senden<br />
*<br />
*******************************************************************************<br />
*/<br />
<br />
// Systemtakt in Hz, das L am Ende ist wichtig, NICHT UL verwenden!<br />
#define F_CPU 3686400L <br />
// "Morsedauer" für ein Bit in Millisekunden<br />
#define BITZEIT 100 <br />
<br />
#include <string.h><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <util/delay.h><br />
<br />
// Baudrate, das L am Ende ist wichtig, NICHT UL verwenden!<br />
#define BAUD 9600L <br />
<br />
// Berechnungen<br />
// clever runden<br />
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1) <br />
// Reale Baudrate<br />
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1))) <br />
// Fehler in Promille <br />
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD-1000) <br />
<br />
#if ((BAUD_ERROR>10) || (BAUD_ERROR<-10))<br />
#error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch! <br />
#endif<br />
<br />
// globale Variablen für den UART<br />
<br />
// Puffergrösse in Bytes, RX und TX sind gleich gross<br />
#define uart_buffer_size 32 <br />
<br />
volatile uint8_t uart_rx_flag=0; // Flag, String komplett empfangen<br />
volatile uint8_t uart_tx_flag=1; // Flag, String komplett gesendet<br />
char uart_rx_buffer[uart_buffer_size]; // Empfangspuffer<br />
char uart_tx_buffer[uart_buffer_size]; // Sendepuffer<br />
<br />
// lange, variable Wartezeit, Einheit in Millisekunden<br />
void long_delay(uint16_t ms) {<br />
for (; ms>0; ms--) _delay_ms(1);<br />
}<br />
<br />
// einen String senden<br />
// vor Aufruf der Funktion muss man prüfen, ob uart_t_flag==1 ist<br />
// nur dann kann ein neuer String gesendet werden<br />
<br />
void put_string(char *daten) {<br />
<br />
if (uart_tx_flag==1) {<br />
// String daten ind en Sendepuffer kopieren<br />
strcpy(uart_tx_buffer, daten); <br />
// Flag für 'Senden ist komplett' löschen, <br />
uart_tx_flag = 0; <br />
// UDRE Interrupt einschalten, los gehts<br />
UCSRB |= (1<<UDRIE); <br />
}<br />
}<br />
<br />
// einen empfangenen String kopieren<br />
// vor Aufruf der Funktion muss man prüfen, ob uart_rx_flag==1 ist<br />
// anderenfalls ist der RX Buffer noch ungültig<br />
<br />
void get_string(char *daten) {<br />
<br />
if (uart_rx_flag==1) {<br />
// String kopieren<br />
strcpy(daten, uart_rx_buffer); <br />
// Flag löschen<br />
uart_rx_flag = 0; <br />
}<br />
}<br />
<br />
// Ein Byte im RS232 Format auf eine LED ausgeben<br />
<br />
void morse(uint8_t data) {<br />
uint8_t i;<br />
<br />
// Startbit, immer 0<br />
PORTD &= ~(1 << PD5); // LED aus<br />
long_delay(BITZEIT);<br />
<br />
for(i=0; i<8; i++) {<br />
if (data & 0x01) // Prüfe Bit #0<br />
PORTD |= (1 << PD5); // LED an<br />
else<br />
PORTD &= ~(1 << PD5); // LED aus <br />
long_delay(BITZEIT); <br />
data >>= 1; // nächstes Bit auf Bit #0 schieben<br />
}<br />
// Stopbit, immer 1<br />
PORTD |= (1 << PD5); // LED an<br />
long_delay(BITZEIT);<br />
}<br />
<br />
// Hauptprogramm<br />
<br />
int main (void) {<br />
<br />
char stringbuffer[64]; // Allgemeiner Puffer für Strings<br />
uint8_t buffer_full=0; // noch ein Flag, aber nur in der Hauptschleife<br />
char * charpointer; // Hilfszeiger<br />
<br />
// IO konfigurieren<br />
<br />
DDRA = 0xFF;<br />
DDRB = 0xFF;<br />
DDRC = 0xFF;<br />
DDRD = 0xFF;<br />
<br />
// UART konfigurieren<br />
<br />
UBRRH = UBRR_VAL >> 8;<br />
UBRRL = UBRR_VAL & 0xFF;<br />
UCSRB = (1<<RXCIE) | (1<<RXEN) | (1<<TXEN); <br />
<br />
// Stringbuffer initialisieren<br />
<br />
stringbuffer[0] = '\n';<br />
stringbuffer[1] = '\r';<br />
<br />
// Interrupts freigeben<br />
<br />
sei();<br />
<br />
// Endlose Hauptschleife<br />
<br />
while(1) {<br />
<br />
// "Sinnvolle" CPU Tätigkeit <br />
PORTD &= ~(1<<PD5);<br />
long_delay(300);<br />
PORTD |= (1<<PD5);<br />
long_delay(300);<br />
<br />
// Wurde ein kompletter String empfangen <br />
// und der Buffer ist leer?<br />
if (uart_rx_flag==1 && buffer_full==0) { <br />
// ja, dann String lesen, <br />
// die ersten zwei Zeichen <br />
// aber nicht überschreiben<br />
get_string(stringbuffer+2); <br />
buffer_full=1;<br />
}<br />
<br />
// Ist letzte Stringsendung abgeschlossen <br />
// und ein neuer String verfügbar?<br />
if (uart_tx_flag==1 && buffer_full==1) { <br />
// Newline + Carrige return anfügen<br />
strcat(stringbuffer, "\n\r"); <br />
put_string(stringbuffer); // zurücksenden<br />
buffer_full=0; // Buffer ist wieder verfügbar<br />
// Alle Zeichen per LED morsen<br />
charpointer = stringbuffer;<br />
while(*charpointer) morse(*charpointer++);<br />
}<br />
}<br />
}<br />
<br />
// UART RX complete interrupt<br />
<br />
// hier werden Daten vom PC empfangen und in einem String zwischengespeichert<br />
// Wird ein Stringterminator empfangen, wird ein Flag gesetzt, welches dem <br />
// Hauptprogramm den kompletten Empfang signalisiert<br />
<br />
ISR(USART_RXC_vect) {<br />
<br />
static uint8_t uart_rx_cnt; // Zähler für empfangene Zeichen<br />
char data;<br />
<br />
// Daten auslesen, dadurch wird das Interruptflag gelöscht <br />
data = UDR;<br />
<br />
// Ist Puffer frei für neue Daten? <br />
if (!uart_rx_flag) {<br />
// ja, ist Ende des Strings (RETURN) erreicht?<br />
if (data=='\r') {<br />
// ja, dann String terminieren<br />
uart_rx_buffer[uart_rx_cnt]=0; <br />
// Flag für 'Empfangspuffer voll' setzen<br />
uart_rx_flag=1;<br />
// Zähler zurücksetzen<br />
uart_rx_cnt=0;<br />
}<br />
else if (uart_rx_cnt<(uart_buffer_size-1)) { <br />
// Daten in Puffer speichern<br />
// aber durch if() Pufferüberlauf vermeiden<br />
uart_rx_buffer[uart_rx_cnt]=data; <br />
uart_rx_cnt++; // Zähler erhöhen<br />
}<br />
}<br />
}<br />
<br />
// UART TX data register empty interrupt<br />
// hier werden neue Daten in das UART-Senderegister geladen<br />
<br />
ISR(USART_UDRE_vect) {<br />
// Zeiger auf Sendepuffer<br />
static char* uart_tx_p = uart_tx_buffer; <br />
char data;<br />
<br />
// zu sendendes Zeichen lesen, <br />
// Zeiger auf Sendepuffer erhöhen<br />
data = *uart_tx_p++;<br />
<br />
// Ende des nullterminierten Strings erreicht?<br />
if (data==0 ) { <br />
UCSRB &= ~(1<<UDRIE); // ja, dann UDRE Interrupt ausschalten <br />
uart_tx_p = uart_tx_buffer; // Pointer zurücksetzen<br />
uart_tx_flag = 1; // Flag setzen, Übertragung beeendet<br />
}<br />
else UDR = data; // nein, Daten senden<br />
}<br />
</syntaxhighlight><br />
<br />
=== Atomarer Zugriff auf eine 16-Bit Variable ===<br />
<br />
<syntaxhighlight lang="c"><br />
// Atmega8 @ 4 MHz<br />
// Siehe http://www.mikrocontroller.net/topic/206455<br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <util/atomic.h><br />
<br />
// Anm. Für das Programm würde wohl eine 8-Bit Variable genügen.<br />
// Mit 16-Bit kann der Sinn eines atomaren Zugriffs besser<br />
// demonstriert werden <br />
volatile int sekunde;<br />
<br />
void setup (void)<br />
{<br />
TCCR0 |= ( 1<<CS02 )|( 1<<CS00 ); // counter0,Prescaler auf 1024<br />
TIMSK |= ( 1<<TOIE0 ); // enable counter0 overflow interrupt<br />
TCNT0 = 0x00; // Counter0 auf Null setzen<br />
sei(); // Interrupts global aktivieren<br />
}<br />
<br />
ISR(TIMER0_OVF_vect)<br />
{<br />
sekunde++;<br />
}<br />
<br />
int main(void)<br />
{<br />
DDRB = (1<<PB0); // Pin PB0 Ausgang<br />
setup();<br />
while (1) {<br />
int sekunde_kopie;<br />
ATOMIC_BLOCK(ATOMIC_FORCEON)<br />
{<br />
sekunde_kopie = sekunde; // 16-Bit Zuweisung ist nicht atomar<br />
// deshalb ATOMIC_BLOCK<br />
}<br />
if ( sekunde_kopie >= 25 ) {<br />
ATOMIC_BLOCK(ATOMIC_FORCEON)<br />
{<br />
sekunde = 0; // 16-Bit Zuweisung ist nicht atomar<br />
// deshalb ATOMIC_BLOCK<br />
}<br />
PORTB ^= (1<<PB0); // Toggle PB0<br />
}<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
== Siehe auch ==<br />
<br />
* [[ADC]]<br />
* [[Timer]]<br />
* [[FAQ#Timer]]<br />
* [[AVR-Tutorial: Interrupts | AVR-Tutorial - Interrupts in Assembler]]<br />
* [[AVR-GCC-Tutorial#Programmieren_mit_Interrupts | AVR-GCC-Tutorial - Interrupts in C]]<br />
* [https://www.mikrocontroller.net/topic/121333#1110623 Forumsbeitrag]: Minimale Pulsbreite zum Auslösen eines Pin Change Interrupts beim AVR<br />
* [https://www.mikrocontroller.net/topic/65923?goto=new#528085 Forumsbeitrag]: Schwerer Bug in AVR-GCC 4.1.1<br />
* [https://www.mikrocontroller.net/topic/513157?goto=6588881#6588720 Forumsbeitrag]: Code in den Atomic Block verschleppt<br />
<br />
== Weblinks ==<br />
<br />
* [http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Atomare Operationen in der avr-libc]<br />
* [http://www.nongnu.org/avr-libc/user-manual/optimization.html#optim_code_reorder Problems with reordering code]<br />
* [http://www.embedded.com/electronics-blogs/beginner-s-corner/4023801/Introduction-to-the-Volatile-Keyword Introduction to the '''Volatile''' Keyword] von Nigel Jones auf [http://www.embedded.com/ Embedded Systems Design]<br />
* [http://blog.regehr.org/archives/28 Nine ways to break your systems code using volatile]<br />
<br />
[[Category:AVR]]<br />
[[Category:Grundlagen]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=Interrupt&diff=107254Interrupt2025-01-27T13:44:20Z<p>Heha: /* Wichtige Eigenschaften von ISRs */</p>
<hr />
<div>Bei bestimmten Ereignissen in Prozessoren wird ein '''Interrupt''' (Unterbrechungsanforderung) registriert. <br />
<br />
Bei [[Mikrocontroller]]n werden Interrupts z.&nbsp;B. ausgelöst wenn:<br />
* sich der an einem bestimmten Eingangs-Pin anliegende Pegel ändert<br />
* eine vorher festgelegte Zeitspanne abgelaufen ist ([[Timer]])<br />
* eine [[Seriell|serielle]] Übertragung abgeschlossen ist<br />
* eine Messung des [[ADC |Analog-Digital-Wandlers]] abgeschlossen ist<br />
<br />
Die Registrierung eines Interrupts setzt ein passend zum Ereignis benanntes '''Interruptflag''' in Form eines Bits in einem speziellen Statusregister. Bei der Behandlung des Interrupts wird das Anwendungsprogramm unterbrochen, das auslösende Interruptflag gelöscht und ein Unterprogramm, die sogenannte '''I'''nterrupt '''S'''ervice '''R'''outine ('''ISR'''), aufgerufen. Wenn dieses beendet ist, läuft das Anwendungsprogramm ganz normal weiter.<br />
<br />
== Wichtige Eigenschaften von ISRs ==<br />
<br />
ISRs reagieren auf ein bestimmtes Ereignis, welches relativ oft oder selten passiert. Prinzipiell sollte man ISRs möglichst (zeitlich) kurz halten und schnell beenden. <br />
<br />
Im Mittel muss die ISR kürzer sein als die Periodendauer des Ereignisses, andernfalls wird es passieren, dass Interrupts „verschluckt“ werden, d.h. beim UART gehen Daten verloren, beim Timer gehen Zählzyklen verloren, beim AD-Wandler gehen Daten verloren usw. Solche verschluckten Interrupts sind schwer zu finden, weil es nur sehr wenige in ganz bestimmten Konstellationen sind. Wenn dann eine per Timer realisierte Uhr in der Stunde um 1 s falsch geht, merkt man das oft nicht. Langwierige Berechnungen, Auswertungen, Ausgaben oder gar Warteschleifen haben daher in ISRs nichts zu suchen. Auch typische C-Funktionen wie <tt>printf()</tt>, <tt>scanf()</tt>, Ausgaben auf ein [[LCD]] usw. sollte man <i>nie</i> in ISRs vornehmen. <br />
<br />
Stattdessen kommt bei Interruptbetrieb sinnvollerweise eine andere Programmiertechnik zum Einsatz, nämlich die Übergabe von Parametern bzw. Steuersignalen an das Hauptprogramm. Fachsprachlich handelt es sich um ein „bottom half“ (Linux) oder um einen „Aufgeschobenen Prozeduraufruf“ (DPC, Windows). Hierbei ist wichtig, dass die Steuerbits („Flags“), welche gemeinsam im Interrupt-Programmteil und im Nicht-Interrupt-Programmteil verwendet werden, mit dem Schlüsselwort [[Interrupt#Weblinks|volatile]] deklariert werden. Dadurch wird sichergestellt, dass jeder Zugriff auf die Variable im Code auch in die entsprechenden Maschinenbefehle umgesetzt wird und nicht wegoptimiert wird, weil sich die Variable in einem der beiden unabhängigen Programmteile scheinbar nicht ändert. Außerdem müssen sowohl der Lese- als auch Schreibzugriff auf Steuervariablen ununterbrechbar ([[Interrupt#Atomarer Datenzugriff|atomar]]) sein.<br />
<br />
Für die Steuerbits bietet sich die Verwendung von <tt>GPIOR0</tt> an, welches volatil und bitadressierbar in den meisten AVR-Controllern zur Verfügung steht.<br />
<br />
=== Interruptsteuerung ===<br />
<br />
Interrupts müssen wie alle anderen Module und Funktionen eines Mikrocontrollers gesteuert werden. Dazu wird auf praktisch allen Mikrocontrollern ein zweistufiges System verwendet.<br />
* Globale Interruptfreigabe über ein CPU-Statusbit: Beim [[AVR]] ist das das I-Bit (Interrupt) im Statusregister (SREG). Dieses Bit wirkt wie ein Hauptschalter und kann global die Ausführung aller Interrupts ein - und ausschalten. Das heisst aber nicht, dass während der Zeit der inaktiven Interrupts diese verloren gehen. Vielmehr wird das jeweilige Interruptbit gesetzt, und wenn die Interrupts wieder freigegeben werden wird der Interrupt ausgeführt. Verloren gehen Interrupts erst dann, wenn die Sperrzeit zu groß ist und währenddessen mehr als ein Interrupt vom selben Typ eintrifft. Siehe [[Interrupt#Zeitverhalten eines Timerinterrupts|Beispiel 1]] und [[Interrupt#Zeitverhalten des UART Empfangsinterrupts|Beispiel 2]].<br />
* Lokale Interruptsteuerung für jede einzelne Interruptquelle über Maskenbits in mehreren Interruptmaskenregistern. Hier kann jede einzelne Interruptquelle individuell ein- und ausgeschaltet werden.<br />
<br />
Dieses System hat eine Reihe von Vorteilen.<br />
So können sehr schnell und einfach alle Interrupts kurzzeitig gesperrt werden, wenn beispielsweise [[Interrupt#Atomarer Datenzugriff | atomare]] Operationen durchgeführt werden sollen, oder besonders zeitkritische Abläufe ausgeführt werden. Danach können alle konfigurierten Interrupts einfach wieder freigeschaltet werden, ohne dass die CPU viele verschiedene Interruptmaskenbits verwalten müsste.<br />
<br />
<br />
Eine ISR wird demnach nur dann ausgeführt, wenn<br />
* die Interrupts global freigeschaltet sind<br />
* das individuelle Maskenbit gesetzt ist<br />
* der Interrupt eintritt bzw. anliegt<br />
<br />
=== Verschachtelte Interrupts ===<br />
<br />
Einige Mikrocontroller, wie z.&nbsp;B. der [[AVR]] kennen nur zwei CPU-Zustände. Normale Programmausführung und Interruptausführung, gesteuert durch das I-Bit der CPU. Die normale Programmausführung kann jederzeit durch Interrupts unterbrochen werden. Die Interruptausführung kann nicht durch neue Interrupts unterbrochen werden. Die ISR wird erst zu Ende bearbeitet, zurück in die normale Programmausführung gesprungen und erst dann werden neue, wartende (engl. pending = anliegend) Interrupts bearbeitet.<br />
<br />
Etwas komplexere Mikrocontroller oder große Prozessoren bieten verschiedene Interruptlevel (Stufen) an. Dabei gilt meist je niedriger die Zahl des Levels, um so höher die Priorität. Ein Interrupt mit höherer Priorität kann einen Interrupt mit niedriger Priorität unterbrechen.<br />
Ein Interrupt mit gleicher Priorität wie der gerade bearbeitete Interrupt kann das im allgemeinen nicht.<br />
Das nennt man verschachtelte Interrupts (engl. nested interrupts).<br />
Klassische Vertreter hierfür sind PIC18, [[8051]], PowerPC, [[X86]] und Motorola 68000.<br />
<br />
Auf dem AVR kann man [[AVR-GCC-Tutorial#Unterbrechbare_Interruptroutinen | verschachtelte Interrupts]] sowohl in Assembler als auch in C nachbilden, allerdings mit einigen Einschränkungen und Tücken.<br />
Das ist jedoch Leuten vorbehalten, die schon viel Erfahrung auf diesem Gebiet haben.<br />
Zu 99,9% braucht man sie nicht, und wenn doch sollte das Problem besser mittels DPC und einer globalen <tt>idle()</tt>-Routine gelöst werden.<br />
<br />
=== Wie lange dauert meine Interruptroutine? ===<br />
<br />
Diese Frage sollte man beantworten können, zumindest sollte eine Worst-Case-Abschätzung gemacht werden. Das geht auf zwei Wegen.<br />
<br />
* Simulation, dabei muss in einer verzweigten ISR der längste Pfad simuliert werden. Dazu müssen alle beteiligten Variablen auf den ensprechenden Wert gesetzt werden.<br />
* Abzählen der Takte im Assembler- oder Disassemblerlisting<br />
* Messung mit dem [[Oszilloskop]], dabei wird zum Beginn der ISR ein Pin auf HIGH gesetzt und am Ende auf LOW. Damit kann man in Echtzeit die Dauer der ISR messen. Die zusätzlichen Taktzyklen zum Aufruf und verlassen der ISR sind konstant und im wesentlichen bekannt. Mit einem modernen Digitaloszilloskop und dem "Infinite Persistence Mode" kann man eine Worst-Case-Messung vornehmen<br />
<br />
Als Hilfsmittel zur Fehlersuche kann man auch am Ende der ISR prüfen, ob das jeweilige Interrupt-Request-Bit schon wieder gesetzt ist. Wenn ja, dann ist die ISR in den meisten Fällen zu lang. Auch hier kann man einen Ausgang auf HIGH setzen und somit den Fehler anzeigen.<br />
<br />
In hartnäckigen Fällen lässt der Check auf das Interrupt-Request-Bit am ISR-Ende zum wiederholten Ausführen des Interrupt-Kodes verwenden. Diese Technik nennt sich „tail chaining“ und spart den Aufwand des Register-Rettens und -Wiederherstellens, kann jedoch zur Folge haben, dass andere ISRs und das Hauptprogramm nicht mehr zum (Schach-)Zug kommen. Das nennt man „verhungern“, englisch „starvation“.<br />
<br />
=== Zeitverhalten eines Timerinterrupts ===<br />
<br />
Ein Timerinterrupt wird im allgemeinen dazu genutzt, in konstanten, periodischen Abständen bestimmte Funktionen aufzurufen. Es ist möglich, dass während eines Timerinterrupts derselbe Interrupt wieder aktiv wird, weil die Routine sehr verzweigt ist und dieses Mal sehr lange dauert.<br />
<br />
Wenn zum Beispiel der Timerinterrupt mit einer Periodendauer von 100ms aufgerufen wird, er aber unter bestimmten Umständen 180ms benötigt, dann wird nach 100ms nach Eintritt in die ISR der Interrupt wieder aktiv, das Timer Interrupt Flag wird gesetzt. Da aber gerade ein Interrupt bearbeitet wird, wird er nicht sofort angesprungen, weil währenddessen die Interruptfunktion global gesperrt ist (beim AVR ist das I-Bit in der CPU gelöscht). Der Interrupt wird zu Ende bearbeitet, die CPU springt zurück zum Hauptprogramm. Dabei werden die Interrupts wieder global eingeschaltet. Der zwischenzeitlich eingetroffene und zwischengespeicherte Interrupt wird nun sofort ausgeführt, sodass das Hauptprogramm praktisch gar nicht weiter kommt, bestenfalls einen Maschinenbefehl. Nun sind aber nur noch 20ms bis zum nächsten Timerinterrupt übrig. Wenn dieser nun wieder 180 ms benötigt werden in dieser Zeit aber '''zwei''' Interrupts ausgelöst, nach 20ms und 120ms. Da diese aber nicht gezählt oder andersweitig einzeln gespeichert werden können, geht ein Interrupt verloren. Das ist ein Programmfehler.<br />
<br />
=== Zeitverhalten des UART Empfangsinterrupts ===<br />
<br />
Ein [[UART]] Interrupt zum Empfang von Daten per [[RS232]] mit 115200 [[Baud]] ist ein recht häufiges Ereignis (1 Zeichen = 10 Bits = 86,8&mu;s). Wenn kontinuierlich Daten empfangen werden, wird nach jeweils 86,8&mu;s ein neuer Interrupt ausgelöst. Dabei wird das empfangene Datenbyte vom UART aus dem Empfangsschiebegregister in einem Puffer kopiert. Während das neue Zeichen Bit für Bit empfangen wird, wird es zunächst im Schieberegister des UART gespeichert. Die Daten im Puffer bleiben davon unberührt. Die CPU muss nun schnell das empfangene Datenbyte aus dem Empfangsbuffer auslesen. Die maximale Verzögerung, die sich die CPU erlauben kann von der Aktivierung des Interrupts bis zum tatsächlichen Auslesen des Datenregisters beträgt ziemlich genau die Übertragungszeit von einem Zeichen. Wenn bis dahin nicht das Zeichen von der CPU ausgelesen wurde, wird es vom UART überschrieben und ein Fehler im Statusregister des UART signalisiert (Overrun, Überlauf des Datenpuffers). Die UARTs in heutigen Mikrocontrollern haben mindestens ein Byte Puffer wie hier beschrieben. Die neueren [[AVR]]s haben sogar effektiv 3 Byte Puffer im UART, praktisch ein kleines [[FIFO]], womit der Datenempfang besser gepuffert werden kann, wenn die CPU gerade mit anderen sehr wichtigen Dingen beschäftigt ist. D.h. kurzzeitig kann sich die CPU erlauben, die Übertragungszeit von bis zu drei Zeichen zu warten, ehe sie die Daten ausliest. Dann müssen sie aber sehr schnell hintereinander gelesen werden. Im Mittel hat die CPU aber nur die Übertragungszeit eines Zeichens zur Verfügung, um es abzuholen.<br />
<br />
=== Zusammenfassung ===<br />
<br />
Interruptserviceroutinen:<br />
* sollten so kurz wie möglich gehalten werden<br />
* können im Einzelfall nahezu doppelt so lange dauern wie die kürzeste Periodendauer des Ereignisses, ohne dass Interrupts verloren gehen (z.&nbsp;B. Timerinterrupt).<br />
* dürfen im Mittel maximal solange dauern wie die kürzeste Periodendauer des Ereignisses<br />
* dürfen maximal solange dauern, wie die kürzeste Periodendauer des Ereignisses, wenn man auf Nummer sicher gehen will, dass keine Interrupts verschluckt werden<br />
* Die Interruptzeit versteht sich immer abzüglich einer kleinen Reserve für das Anspringen und Verlassen des Interrupt minus Panikreserve<br />
<br />
==Interruptfeste Programmierung==<br />
<br />
=== Atomarer Datenzugriff ===<br />
<br />
Von einem atomaren Zugriff (engl. atomic access) spricht man, wenn der Zugriff innerhalb einer nicht unterbrechbaren Instruktionsfolge abgearbeitet wird.<br />
<br />
Alle Variablen, Steuerregister und I/O-Ports, die sowohl im Hauptprogramm als auch in Interrupts verwendet werden, sind mit viel Sorgfalt zu behandeln.<br />
<br />
Beispiel:<br />
<syntaxhighlight lang="c"><br />
port |= 0x03;<br />
</syntaxhighlight><br />
übersetzt sich auf AVR-Prozessoren in<br />
<syntaxhighlight lang="avrasm"> <br />
IN r16,port<br />
ORI r16,0x03<br />
OUT port,r16<br />
</syntaxhighlight><br />
Wenn nun zwischen IN und OUT ein Interrupt auftritt, der beispielsweise Bit&nbsp;7 verändert, dann geht mit dem OUT-Befehl diese Änderung verloren, da der OUT-Befehl den alten Zustand vor dem Interrupt wiederherstellt.<br />
<br />
'''Gefährlich ist das insbesondere deshalb, weil der Fall nur selten auftritt und dieses Verhalten sehr schlecht reproduzierbar ist!'''<br />
<br />
Bei verschiedenen Prozessor-Architekturen tritt das Problem verschieden häufig auf. So übersetzt sich obiger Code bei MSP430 Prozessoren in einen einzelnen Befehl<br />
<pre><br />
OR #0x03,port<br />
</pre><br />
und stellt somit kein Problem dar. Im Zweifel hilft nur ein Blick in den erzeugten Assembler-Code. Bei der Übernahme fremden Codes ist dies zu beachten. Was beim [[8051]] kein Problem war, kann beim [[AVR]] zu einem Problem werden, unter Umständen sogar abhängig vom verwendeten Port sein (einige Ports bzw. I/O Register können mit den atomaren Befehlen sbi, cbi zum Setzen und Löschen einzelner Bits erreicht werden, andere nicht).<br />
<br />
Ein ähnliches Problem entsteht bei Variablen, deren Größe die Wortbreite der Maschine übersteigt, unter Umständen auch Bitfeld-Zugriffe. Bei 8-Bit-Prozessoren wie AVR oder 8051 also bereits bei normalen "int" Variablen. Diese Variablen werden zwangsläufig byteweise verarbeitet. Wenn genau dazwischen ein Interrupt erfolgt, wird ein falscher Wert gelesen. Wenn beispielsweise eine Interrupt-Routine einen 16-Bit-Zähler verwendet und von 0x00FF auf 0x0100 hochzählt, dann kann das Hauptprogramm auch schon mal versehentlich die Werte 0x01FF oder 0x0000 lesen. Ein Beispiel.<br />
<br />
<syntaxhighlight lang="c"><br />
/* var wird in einer ISR inkrementiert */<br />
volatile int var;<br />
<br />
int get_var (void)<br />
{<br />
/* Folgende Zuweisung besteht aus mehr als einem Maschinenbefehl */<br />
return var;<br />
}<br />
</syntaxhighlight><br />
<br />
Das Lesen von var ist in C nur ein Befehl, in Assembler werden aber mindestens 2 Befehle benötigt, da pro Maschinen-Befehl nur 8&nbsp;Bit bewegt werden können.<br />
Die Zuweisung kann also unterbrochen werden. Das kann dazu führen, daß ein Teil alter Bits und ein Teil neuer Bits zugewiesen wird:<br />
<br />
# var sei 0x00FF<br />
# Das Lowbyte von var wird für die return-Anweisung gelesen: 0xFF<br />
# Ein Interrupt inkrementiert var um 1 auf 0x0100<br />
# Das Highbyte von var wird in für die return-Anweisung gelesen: 0x01<br />
# Die Funktion gibt 0x01FF zurück<br />
<br />
Dies ist auch ein Grund, weshalb für Programmierung auf derart maschinennaher Ebene Kenntnisse in Prozessorarchitektur und Assembler-Programmierung sehr hilfreich sind.<br />
<br />
'''Abhilfe''': Wenn man sich nicht wirklich ganz sicher ist, müssen um kritische Aktivitäten herum jedesmal die Interrupts abgeschaltet werden.<br />
<br />
Beispiel ([[AVR-GCC]]):<br />
<syntaxhighlight lang="c"><br />
// Manuelle Methode<br />
cli(); // Interrupts abschalten<br />
port |= 0x03;<br />
sei(); // Interrupts wieder einschalten<br />
<br />
// Per Macros aus dem avr gcc, schöner lesbar und bequemer<br />
// siehe Doku der avr-libc, Abschnitt <util/atomic.h><br />
ATOMIC_BLOCK(ATOMIC_FORCEON) {<br />
port |= 0x03; <br />
}<br />
</syntaxhighlight><br />
<br />
Wenn man ein globales Einschalten der Interrupts mit sei() vermeiden will, kann man die folgende Methode benutzen. Hierbei werden die Interrupts nur eingeschaltet, wenn sie vorher bereits eingeschaltet waren (Hinweis aus der FAQ von avr-libc):<br />
<br />
<syntaxhighlight lang="c"><br />
{<br />
// ...<br />
{<br />
uint8_t sreg_local; // Lokale Sicherungskopie von SREG<br />
sreg_local = SREG;<br />
cli();<br />
// hierhin kommt der Code mit atomarem Zugriff<br />
SREG = sreg_local;<br />
} <br />
<br />
// wieder per Macro<br />
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {<br />
// hierhin kommt der Code mit atomarem Zugriff<br />
}<br />
// ...<br />
}<br />
</syntaxhighlight><br />
<br />
Je nach Prozessor kann man das Problem manchmal auch ohne Abschalten von Interrupts durch geeignete Programmierung lösen. So führt<br />
<syntaxhighlight lang="c"><br />
port = (port & ~0x0F) | lcd_data;<br />
</syntaxhighlight><br />
immer zum beschriebenen Problem,<br />
<syntaxhighlight lang="c"><br />
port &= ~0x0F;<br />
port |= lcd_data;<br />
</syntaxhighlight><br />
jedoch nicht, wenn die beiden Zeilen zu jeweils einem Assembler-Befehl übersetzt werden, wie z.B. auf dem MSP430, nicht jedoch auf dem AVR. Was dann aber abhängig von den Optimierungs-Einstellungen des Compilers werden kann. Eine interruptfeste Variante für AVR-Prozessoren der neuesten Generation, wie beispielsweise Tiny2313 und Mega88 (alle ab 2004):<br />
<syntaxhighlight lang="c"><br />
PINx = (PORTx & 0x0F) ^ lcd_data;<br />
</syntaxhighlight><br />
<br />
Wenn man diese Tricks nutzt, sollte man sie auch sehr gut und eindeutig mit einem Kommentar dokumentieren! Im Zweifelsfall sollte man lieber den soliden, eindeutigen Weg wählen und die Interrupts kurz sperren. Diese Methode ist auch gefahrlos auf andere Controller portierbar.<br />
<br />
=== Reentrante Funktionen ===<br />
<br />
Eine Funktion ist reentrant (wiedereintrittsfest), wenn sie mehrmals gleichzeitig aktiv sein kann, ohne dass sich diese Aufrufe gegenseitig beeinflussen. Betrifft beispielsweise Funktionen, die sowohl im Hauptprogramm als auch in Interrupts aufgerufen werden. Manche C Compiler erfordern eine besondere Kennzeichnung solcher Funktionen. Wenn möglich sollte man es jedoch vermeiden, eine Funktion aus dem Hauptprogramm '''und''' aus einem Interrupt aus aufzurufen. Das ist meist problemlos machbar.<br />
<br />
=== Volatile Variablen ===<br />
Variablen, auf die sowohl innerhalb wie auch außerhalb einer Interruptserviceroutine zugegriffen wird (schreibend oder lesend), müssen (ähnlich wie Hardwareregister) mit dem Schlüsselwort '''volatile''' (flüchtig) versehen werden, damit der C-Compiler berücksichtigen kann, dass diese Variablen jederzeit (durch das Auftreten des Interrupts) gelesen oder geschrieben werden können.<br />
Ansonsten würde der C-Compiler das regelmäßige Abfragen oder Beschreiben dieser Variablen ggf. wegoptimieren, da er nicht damit rechnet, dass auf die Variable auch "ohne sein Zutun" zugegriffen wird.<br />
<br />
Eine ausführlichere Erklärung zu "volatile" ist hier zu finden: <br />
[http://www.mikrocontroller.net/articles/FAQ#Was_hat_es_mit_volatile_auf_sich FAQ: Was hat es mit volatile auf sich]<br />
<br />
== Interrupts und Low Power Modes (Sleep) ==<br />
<br />
Wenn der Microcontroller in einen Low Power Mode versetzt wird, wird er durch einen Interrupt wieder aufgeweckt, z.B. in einem festen Zeitraster per Timer-Interrupt oder vom ADC nach Beendigung einer AD-Wandlung.<br />
Dabei muß sichergestellt werden, daß der Interrupt erst nach dem In-Low-Power-Gehen (z.B. per Befehl ''sleep()'') kommen kann, da sonst der µC nicht bzw. nicht rechtzeitig geweckt wird. Dazu muß eine Möglichkeit bestehen, daß der Interrupt gesperrt wird und erst mit dem Sleep-Befehl freigegeben wird. Dies scheint auf den ersten Blick unmöglich: Man kann nicht gleichzeitig zwei Befehle (''sei()'' und ''sleep()'') ausführen.<br />
Es gibt spezielle Mechanismen für diesen Fall. Beim C51 und beim AVR ist es z.B. so, daß ''sei()'' erst einen Befehl später "wirksam" wird. Dadurch wird die Kombination <br />
<syntaxhighlight lang="c"><br />
sei(); <br />
sleep();<br />
</syntaxhighlight><br />
ununterbrechbar (natürlich sofern zuvor die Interrupts gesperrt wurden).<br />
Andere Microcontroller bieten andere Mechanismen, z.B. sperrt der Assembler-Befehl<br />
<syntaxhighlight lang="c"><br />
DISI<br />
</syntaxhighlight> <br />
beim PIC24 die Interrupts für eine bestimmten Anzahl von CPU-Taktzyklen. Die CPU kann dann eine vorgegebene Anzahl an folgenden Befehlen unter Interruptsperre ausführen und der Interrupt wird automatisch wieder freigegeben.<br />
<br />
== (AVR-) Beispiele für die praktische Programmierung ==<br />
<br />
Die Beispiele sind mit WINAVR 20060421 compiliert und getestet worden. Als Mikrocontroller wird ein AVR vom Typ ATmega32 verwendet. Alle Programme wurden mit Optimierungsstufe -Os compiliert.<br />
<br />
=== Steuersignale zwischen ISR und Hauptprogramm ===<br />
<br />
In vielen Anwendungen wird ein [[Timer]] verwendet, um in regelmäßigen Abständen bestimmte Aktionen auszuführen, wie z.&nbsp;B. Tasten abfragen, ADC-auslesen, ein LCD auffrischen etc. Wenn viele Dinge zu erledigen sind, nebenbei aber noch andere Interrupts verwendet werden, dann ist es notwendig die Funktionsaufrufe aus dem Timerinterrupt in die Hauptschleife zu verlagern. Der Interrupt signalisiert über eine Steuervariable (engl. Flag, Flagge), dass ein neuer Timerzyklus begonnen hat. Dadurch wird der Timerinterrupt sehr kurz und die langwierigen, aber meist nicht zeitkritischen Funktionen werden als normales Programm ausgeführt. Damit kann die CPU auf andere Interrupts schnell reagieren.<br />
<br />
Wichtig ist auf jeden Fall, dass die Steuervariable, welche in der ISR und in der Hauptschleife verwendet wird, mit [http://www.netrino.com/Embedded-Systems/How-To/C-Volatile-Keyword '''volatile'''] deklariert wird. Ausserdem müssen sowohl der Lese- als auch Schreibzugriff auf die Steuersignale [[#Atomarer Datenzugriff | '''atomar''']] sein. Auf dem AVR ist das mit 8-Bit-Variablen direkt möglich, für grössere Variablen müssen die Interrupts kurzzeitig gesperrt werden.<br />
<br />
Das Beispiel ist sehr einfach gehalten um das Prinzip zu veranschaulichen. Ein Timer mit einer Überlaufperiodendauer von ca. 65ms stößt periodisch eine Funktion zum Togglen einer LED an, welche dadurch mit ca. 7 Hz blinkt.<br />
<br />
<syntaxhighlight lang="c"><br />
/*<br />
*******************************************************************************<br />
*<br />
* Timer Interrupt Demo<br />
*<br />
* ATmega32 mit internem 1-MHz-Oszillator<br />
*<br />
* LOW Fuse Byte = 0xE1<br />
*<br />
* An PD5 muss eine LED mit 1-kOhm-Vorwiderstand angeschlossen werden<br />
*<br />
*******************************************************************************<br />
*/<br />
<br />
#define F_CPU 1000000<br />
<br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
<br />
// globale Variablen<br />
<br />
volatile uint8_t flag;<br />
<br />
int main() {<br />
<br />
// IO konfigurieren<br />
<br />
DDRA = 0xFF;<br />
DDRB = 0xFF;<br />
DDRC = 0xFF;<br />
DDRD = 0xFF;<br />
<br />
// Timer2 konfigurieren<br />
<br />
TCCR2 = (1<<CS22) | (1<<CS21); // Vorteiler 256 -> ~65ms Überlaufperiode<br />
TIMSK |= (1<<TOIE2); // Timer Overflow Interrupt freischalten <br />
<br />
// Interrupts freigeben<br />
<br />
sei();<br />
<br />
// Endlose Hauptschleife<br />
<br />
while(1) {<br />
if (flag == 1) { // Neuer Timerzyklus ?<br />
flag = 0;<br />
<br />
// hier steht jetzt in Normalfall ein grosser Programmblock ;-) <br />
PORTD ^= (1 << PD5); // LED toggeln<br />
}<br />
}<br />
}<br />
<br />
// Timer2 overflow Interrupt<br />
// hier wird der Hauptschleife ein neuer Timerinterrupt signalisiert<br />
<br />
ISR( TIMER2_OVF_vect ) {<br />
flag = 1;<br />
}<br />
</syntaxhighlight><br />
<br />
=== UART mit Interrupts ===<br />
<br />
Der UART ist ein oft benutztes Modul eines Mikrocontrollers. Anfänger nutzen ihn meist im sogenannten Polling Betrieb (engl. to poll, abfragen). D.h. wenn ein Zeichen empfangen werden soll, fragt eine Funktion den UART in einer Schleife ununterbrochen ab, ob Daten empfangen wurden. In dieser Zeit macht die CPU nichts anderes! Und wenn lange kein Zeichen eintrifft tut sie sehr lange nichts, sie ist praktisch blockiert! Senden verläuft ähnlich, nur dass hier die CPU vor dem Senden prüft, ob der UART ein neues Byte aufnehmen kann. D.h. während der UART selbsttätig das Zeichen sendet ist die CPU zum Warten verdammt. All diese Nachteile haben nur einen Vorteil. Die Funktionen und Mechanismen zur UART-Nutzung sind sehr einfach, klein und leicht anwendbar.<br />
<br />
Will man aber die CPU nicht sinnlos warten lassen, was vor allem bei niedrigeren Baudraten ziemlich lange sein kann, muss man die Interrupts nutzen. Der AVR hat gleich drei davon.<br />
<br />
* '''RXC''' (Receive Complete): Ein Zeichen wurde empfangen.<br />
* '''UDRE''' (UART Data Register Empty): Der Zwischenpuffer des Senders ist leer und kann ein neues Zeichen aufnehmen. Dieser Zwischenpuffer ist wichtig, um lückenlos auch bei hohen Baudraten senden zu können.<br />
* '''TXC''' (Transmit Complete): Das aktuelle Zeichen wurde vollständig inclusive Stopbit gesendet und es liegt kein neues Datenbyte im Sendepuffer. Dieser Interrupt ist extrem nützlich für eine Halbduplexkommunikation, z.&nbsp;B. auf einem RS485-[[Bus]]. Hier kann man nach dem vollständigen Senden aller Bytes den Bustranceiver (z.&nbsp;B. MAX485) von Senden auf Empfangen umschalten, um den Bus freizugeben.<br />
<br />
Bei Nutzung der Interrupts kann die CPU andere Dinge bearbeiten und muss nur kurz einen Interrupt ausführen, wenn ein Zeichen empfangen oder gesendet wurde.<br />
<br />
Die Kommunikation zwischen ISRs und Hauptschleife erfolgt wieder durch Flags und zwei Pufferarrays (uart_rx_buffer und uart_tx_buffer). Es gibt zwei Funktionen, eine zum Senden von Strings, eine zum Empfangen. Das Senden sowie Empfangen kann parallel erfolgen und läuft vollkommen unabhängig vom Hauptprogramm. Die Daten werden in spezielle Puffer kopiert, sodass das Hauptprogramm mit seinen Strings sofort weiterarbeiten kann. Im Beispiel ist die CPU nicht wirklich mit sinnvollen Dingen beschäftigt, zur Demonstration des Prinzips aber ausreichend.<br />
<br />
Um das Programm real zu nutzen braucht man ein Terminalprogramm, z.&nbsp;B. Hyperterminal von Windows. Dort muss nur die richtige Baudrate eingestellt werden (9600 8N1, 9600 Baud, 8 Bits, keine Parität, 1 Stopbit, keine Flusskontrolle). Ausserdem muss man im Menu Datei -> Eigenschaften -> Einstellungen -> ASCII Konfiguration den Punkt "Eingegebene Zeichen lokal ausgeben (lokales Echo)" aktivieren. Nun kann man beliebige Texte eintippen. Mit RETURN wird die Eingabe abgeschlossen und der AVR vermittelt den empfangenen String an das Hauptprogramm. Diese sendet ihn einfach zurück, parallel dazu wird der String gemorst per LED angezeigt. Sollte es Probleme bei der Inbetriebnahme des UART geben, so findet man hier wichtige Hinweise zur [[AVR_Checkliste#UART.2FUSART | Fehlersuche]].<br />
<br />
<syntaxhighlight lang="c"><br />
/*<br />
*******************************************************************************<br />
*<br />
* UART Interrupt Demo<br />
*<br />
* ATmega32 mit 3,6864 MHz Quarz an XTAL1/XTAL2<br />
*<br />
* LOW Fuse Byte = 0xFF<br />
*<br />
* An PD5 muss eine LED mit 1-kOhm-Vorwiderstand angeschlossen werden<br />
* An PD0/PD1 ist ein MAX232 angeschlosssen, um Daten vom PC zu empfangen/senden<br />
*<br />
*******************************************************************************<br />
*/<br />
<br />
// Systemtakt in Hz, das L am Ende ist wichtig, NICHT UL verwenden!<br />
#define F_CPU 3686400L <br />
// "Morsedauer" für ein Bit in Millisekunden<br />
#define BITZEIT 100 <br />
<br />
#include <string.h><br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <util/delay.h><br />
<br />
// Baudrate, das L am Ende ist wichtig, NICHT UL verwenden!<br />
#define BAUD 9600L <br />
<br />
// Berechnungen<br />
// clever runden<br />
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1) <br />
// Reale Baudrate<br />
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1))) <br />
// Fehler in Promille <br />
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD-1000) <br />
<br />
#if ((BAUD_ERROR>10) || (BAUD_ERROR<-10))<br />
#error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch! <br />
#endif<br />
<br />
// globale Variablen für den UART<br />
<br />
// Puffergrösse in Bytes, RX und TX sind gleich gross<br />
#define uart_buffer_size 32 <br />
<br />
volatile uint8_t uart_rx_flag=0; // Flag, String komplett empfangen<br />
volatile uint8_t uart_tx_flag=1; // Flag, String komplett gesendet<br />
char uart_rx_buffer[uart_buffer_size]; // Empfangspuffer<br />
char uart_tx_buffer[uart_buffer_size]; // Sendepuffer<br />
<br />
// lange, variable Wartezeit, Einheit in Millisekunden<br />
void long_delay(uint16_t ms) {<br />
for (; ms>0; ms--) _delay_ms(1);<br />
}<br />
<br />
// einen String senden<br />
// vor Aufruf der Funktion muss man prüfen, ob uart_t_flag==1 ist<br />
// nur dann kann ein neuer String gesendet werden<br />
<br />
void put_string(char *daten) {<br />
<br />
if (uart_tx_flag==1) {<br />
// String daten ind en Sendepuffer kopieren<br />
strcpy(uart_tx_buffer, daten); <br />
// Flag für 'Senden ist komplett' löschen, <br />
uart_tx_flag = 0; <br />
// UDRE Interrupt einschalten, los gehts<br />
UCSRB |= (1<<UDRIE); <br />
}<br />
}<br />
<br />
// einen empfangenen String kopieren<br />
// vor Aufruf der Funktion muss man prüfen, ob uart_rx_flag==1 ist<br />
// anderenfalls ist der RX Buffer noch ungültig<br />
<br />
void get_string(char *daten) {<br />
<br />
if (uart_rx_flag==1) {<br />
// String kopieren<br />
strcpy(daten, uart_rx_buffer); <br />
// Flag löschen<br />
uart_rx_flag = 0; <br />
}<br />
}<br />
<br />
// Ein Byte im RS232 Format auf eine LED ausgeben<br />
<br />
void morse(uint8_t data) {<br />
uint8_t i;<br />
<br />
// Startbit, immer 0<br />
PORTD &= ~(1 << PD5); // LED aus<br />
long_delay(BITZEIT);<br />
<br />
for(i=0; i<8; i++) {<br />
if (data & 0x01) // Prüfe Bit #0<br />
PORTD |= (1 << PD5); // LED an<br />
else<br />
PORTD &= ~(1 << PD5); // LED aus <br />
long_delay(BITZEIT); <br />
data >>= 1; // nächstes Bit auf Bit #0 schieben<br />
}<br />
// Stopbit, immer 1<br />
PORTD |= (1 << PD5); // LED an<br />
long_delay(BITZEIT);<br />
}<br />
<br />
// Hauptprogramm<br />
<br />
int main (void) {<br />
<br />
char stringbuffer[64]; // Allgemeiner Puffer für Strings<br />
uint8_t buffer_full=0; // noch ein Flag, aber nur in der Hauptschleife<br />
char * charpointer; // Hilfszeiger<br />
<br />
// IO konfigurieren<br />
<br />
DDRA = 0xFF;<br />
DDRB = 0xFF;<br />
DDRC = 0xFF;<br />
DDRD = 0xFF;<br />
<br />
// UART konfigurieren<br />
<br />
UBRRH = UBRR_VAL >> 8;<br />
UBRRL = UBRR_VAL & 0xFF;<br />
UCSRB = (1<<RXCIE) | (1<<RXEN) | (1<<TXEN); <br />
<br />
// Stringbuffer initialisieren<br />
<br />
stringbuffer[0] = '\n';<br />
stringbuffer[1] = '\r';<br />
<br />
// Interrupts freigeben<br />
<br />
sei();<br />
<br />
// Endlose Hauptschleife<br />
<br />
while(1) {<br />
<br />
// "Sinnvolle" CPU Tätigkeit <br />
PORTD &= ~(1<<PD5);<br />
long_delay(300);<br />
PORTD |= (1<<PD5);<br />
long_delay(300);<br />
<br />
// Wurde ein kompletter String empfangen <br />
// und der Buffer ist leer?<br />
if (uart_rx_flag==1 && buffer_full==0) { <br />
// ja, dann String lesen, <br />
// die ersten zwei Zeichen <br />
// aber nicht überschreiben<br />
get_string(stringbuffer+2); <br />
buffer_full=1;<br />
}<br />
<br />
// Ist letzte Stringsendung abgeschlossen <br />
// und ein neuer String verfügbar?<br />
if (uart_tx_flag==1 && buffer_full==1) { <br />
// Newline + Carrige return anfügen<br />
strcat(stringbuffer, "\n\r"); <br />
put_string(stringbuffer); // zurücksenden<br />
buffer_full=0; // Buffer ist wieder verfügbar<br />
// Alle Zeichen per LED morsen<br />
charpointer = stringbuffer;<br />
while(*charpointer) morse(*charpointer++);<br />
}<br />
}<br />
}<br />
<br />
// UART RX complete interrupt<br />
<br />
// hier werden Daten vom PC empfangen und in einem String zwischengespeichert<br />
// Wird ein Stringterminator empfangen, wird ein Flag gesetzt, welches dem <br />
// Hauptprogramm den kompletten Empfang signalisiert<br />
<br />
ISR(USART_RXC_vect) {<br />
<br />
static uint8_t uart_rx_cnt; // Zähler für empfangene Zeichen<br />
char data;<br />
<br />
// Daten auslesen, dadurch wird das Interruptflag gelöscht <br />
data = UDR;<br />
<br />
// Ist Puffer frei für neue Daten? <br />
if (!uart_rx_flag) {<br />
// ja, ist Ende des Strings (RETURN) erreicht?<br />
if (data=='\r') {<br />
// ja, dann String terminieren<br />
uart_rx_buffer[uart_rx_cnt]=0; <br />
// Flag für 'Empfangspuffer voll' setzen<br />
uart_rx_flag=1;<br />
// Zähler zurücksetzen<br />
uart_rx_cnt=0;<br />
}<br />
else if (uart_rx_cnt<(uart_buffer_size-1)) { <br />
// Daten in Puffer speichern<br />
// aber durch if() Pufferüberlauf vermeiden<br />
uart_rx_buffer[uart_rx_cnt]=data; <br />
uart_rx_cnt++; // Zähler erhöhen<br />
}<br />
}<br />
}<br />
<br />
// UART TX data register empty interrupt<br />
// hier werden neue Daten in das UART-Senderegister geladen<br />
<br />
ISR(USART_UDRE_vect) {<br />
// Zeiger auf Sendepuffer<br />
static char* uart_tx_p = uart_tx_buffer; <br />
char data;<br />
<br />
// zu sendendes Zeichen lesen, <br />
// Zeiger auf Sendepuffer erhöhen<br />
data = *uart_tx_p++;<br />
<br />
// Ende des nullterminierten Strings erreicht?<br />
if (data==0 ) { <br />
UCSRB &= ~(1<<UDRIE); // ja, dann UDRE Interrupt ausschalten <br />
uart_tx_p = uart_tx_buffer; // Pointer zurücksetzen<br />
uart_tx_flag = 1; // Flag setzen, Übertragung beeendet<br />
}<br />
else UDR = data; // nein, Daten senden<br />
}<br />
</syntaxhighlight><br />
<br />
=== Atomarer Zugriff auf eine 16-Bit Variable ===<br />
<br />
<syntaxhighlight lang="c"><br />
// Atmega8 @ 4 MHz<br />
// Siehe http://www.mikrocontroller.net/topic/206455<br />
#include <avr/io.h><br />
#include <avr/interrupt.h><br />
#include <util/atomic.h><br />
<br />
// Anm. Für das Programm würde wohl eine 8-Bit Variable genügen.<br />
// Mit 16-Bit kann der Sinn eines atomaren Zugriffs besser<br />
// demonstriert werden <br />
volatile int sekunde;<br />
<br />
void setup (void)<br />
{<br />
TCCR0 |= ( 1<<CS02 )|( 1<<CS00 ); // counter0,Prescaler auf 1024<br />
TIMSK |= ( 1<<TOIE0 ); // enable counter0 overflow interrupt<br />
TCNT0 = 0x00; // Counter0 auf Null setzen<br />
sei(); // Interrupts global aktivieren<br />
}<br />
<br />
ISR(TIMER0_OVF_vect)<br />
{<br />
sekunde++;<br />
}<br />
<br />
int main(void)<br />
{<br />
DDRB = (1<<PB0); // Pin PB0 Ausgang<br />
setup();<br />
while (1) {<br />
int sekunde_kopie;<br />
ATOMIC_BLOCK(ATOMIC_FORCEON)<br />
{<br />
sekunde_kopie = sekunde; // 16-Bit Zuweisung ist nicht atomar<br />
// deshalb ATOMIC_BLOCK<br />
}<br />
if ( sekunde_kopie >= 25 ) {<br />
ATOMIC_BLOCK(ATOMIC_FORCEON)<br />
{<br />
sekunde = 0; // 16-Bit Zuweisung ist nicht atomar<br />
// deshalb ATOMIC_BLOCK<br />
}<br />
PORTB ^= (1<<PB0); // Toggle PB0<br />
}<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
== Siehe auch ==<br />
<br />
* [[ADC]]<br />
* [[Timer]]<br />
* [[FAQ#Timer]]<br />
* [[AVR-Tutorial: Interrupts | AVR-Tutorial - Interrupts in Assembler]]<br />
* [[AVR-GCC-Tutorial#Programmieren_mit_Interrupts | AVR-GCC-Tutorial - Interrupts in C]]<br />
* [https://www.mikrocontroller.net/topic/121333#1110623 Forumsbeitrag]: Minimale Pulsbreite zum Auslösen eines Pin Change Interrupts beim AVR<br />
* [https://www.mikrocontroller.net/topic/65923?goto=new#528085 Forumsbeitrag]: Schwerer Bug in AVR-GCC 4.1.1<br />
* [https://www.mikrocontroller.net/topic/513157?goto=6588881#6588720 Forumsbeitrag]: Code in den Atomic Block verschleppt<br />
<br />
== Weblinks ==<br />
<br />
* [http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Atomare Operationen in der avr-libc]<br />
* [http://www.nongnu.org/avr-libc/user-manual/optimization.html#optim_code_reorder Problems with reordering code]<br />
* [http://www.embedded.com/electronics-blogs/beginner-s-corner/4023801/Introduction-to-the-Volatile-Keyword Introduction to the '''Volatile''' Keyword] von Nigel Jones auf [http://www.embedded.com/ Embedded Systems Design]<br />
* [http://blog.regehr.org/archives/28 Nine ways to break your systems code using volatile]<br />
<br />
[[Category:AVR]]<br />
[[Category:Grundlagen]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR-Tutorial:_Interrupts&diff=107253AVR-Tutorial: Interrupts2025-01-27T13:18:42Z<p>Heha: /* Die Interruptvektoren */</p>
<hr />
<div>==Definition==<br />
<br />
Bei bestimmten Ereignissen in Prozessoren wird ein sogenannter '''Interrupt''' ausgelöst. Interrupts machen es möglich, beim Eintreten eines Ereignisses sofort informiert zu werden, ohne permanent irgendeinen Status abzufragen, was teure Rechenzeit kosten würde. Dabei wird das Programm unterbrochen und ein Unterprogramm aufgerufen. Wenn dieses beendet ist, läuft das Hauptprogramm ganz normal weiter.<br />
<br />
==Mögliche Auslöser==<br />
<br />
Bei Mikrocontrollern werden Interrupts z.&nbsp;B. ausgelöst, wenn:<br />
<br />
* sich der an einem bestimmten Eingangs-Pin anliegende Wert von high auf low ändert (oder umgekehrt)<br />
* eine vorher festgelegte Zeitspanne abgelaufen ist ([[Timer]])<br />
* eine serielle Übertragung abgeschlossen ist ([[UART]])<br />
* …<br />
<br />
Der ATmega8 besitzt 18 verschiedene Interruptquellen. Standardmäßig sind diese alle deaktiviert und müssen über verschiedene IO-Register einzeln eingeschaltet werden. Zusätzlich muss mit <tt>sei()</tt> auch das I-Flag gesetzt werden.<br />
<br />
==INT0, INT1 und die zugehörigen Register==<br />
<br />
Wir wollen uns hier ersteinmal die beiden Interrupts '''INT0''' und '''INT1''' anschauen. INT0 wird ausgelöst, wenn sich der an PD2 anliegende Wert ändert, INT1 reagiert auf Änderungen an PD3.<br />
<br />
Als erstes müssen wir die beiden Interrupts konfigurieren. Im Register '''MCUCR''' wird eingestellt, ob die Interrupts bei einer steigenden Flanke (low nach high) oder bei einer fallenden Flanke (high nach low) ausgelöst werden. Dafür gibt es in diesem Register die Bits '''ISC00''', '''ISC01''' (betreffen INT0) sowie '''ISC10''' und '''ISC11''' (betreffen INT1).<br />
<br />
Hier eine Übersicht über die möglichen Einstellungen und was sie bewirken:<br />
<br />
{| class="wikitable"<br />
! ISC11 bzw. ISC01 || ISC10 bzw. ISC00 ||Beschreibung<br />
|-<br />
|align="center" | 0<br />
|align="center" | 0<br />
||Low-Level am Pin löst den Interrupt aus<br />
|-<br />
|align="center" | 0<br />
|align="center" | 1<br />
||Jede Änderung am Pin löst den Interrupt aus<br />
|-<br />
|align="center" | 1<br />
|align="center" | 0<br />
||Eine fallende Flanke löst den Interrupt aus<br />
|-<br />
|align="center" | 1<br />
|align="center" | 1<br />
||Eine steigende Flanke löst den Interrupt aus<br />
|}<br />
<br />
Danach müssen diese beiden Interrupts aktiviert werden, indem die Bits '''INT0''' und '''INT1''' im Register '''GICR''' auf '''1''' gesetzt werden.<br />
<br />
Die Register '''MCUCR''' und '''GICR''' gehören zwar zu den IO-Registern, können aber nicht wie andere mit den Befehlen <code>cbi</code> und <code>sbi</code> verwendet werden. Diese Befehle wirken nur auf die IO-Register bis zur Adresse 0x1F (welches Register sich an welcher IO-Adresse befindet, steht in der Include-Datei, hier „m8def.inc“, und im Datenblatt des Controllers). Somit bleiben zum Zugriff auf diese Register nur die Befehle <code>in</code> und <code>out</code> übrig.<br />
<br />
==Interrupts generell zulassen==<br />
<br />
Schließlich muss man noch das Ausführen von Interrupts allgemein aktivieren, was man durch einfaches Aufrufen des Assemblerbefehls '''<code>sei</code>''' bewerkstelligt.<br />
<br />
==Die Interruptvektoren==<br />
<br />
Woher weiß der Controller jetzt, welche Routine aufgerufen werden muss, wenn ein Interrupt ausgelöst wird?<br />
<br />
Wenn ein Interrupt auftritt, dann springt die Programmausführung an eine bestimmte Stelle im Programmspeicher. Diese Stellen sind festgelegt und können nicht geändert werden:<br />
<br />
{| class="wikitable"<br />
! Nr. || Adresse || Interruptname || Beschreibung<br />
|-<br />
|align="center" | 1<br />
|align="center" | 0x000<br />
|align="center" | RESET<br />
||Reset bzw. Einschalten der Stromversorgung<br />
|-<br />
|align="center" | 2<br />
|align="center" | 0x001<br />
|align="center" | INT0<br />
||Externer Interrupt 0<br />
|-<br />
|align="center" | 3<br />
|align="center" | 0x002<br />
|align="center" | INT1<br />
||Externer Interrupt 1<br />
|-<br />
|align="center" | 4<br />
|align="center" | 0x003<br />
|align="center" | TIMER2_COMP<br />
||Timer/Counter2 Compare Match<br />
|-<br />
|align="center" | 5<br />
|align="center" | 0x004<br />
|align="center" | TIMER2_OVF<br />
||Timer/Counter2 Overflow<br />
|-<br />
|align="center" | 6<br />
|align="center" | 0x005<br />
|align="center" | TIMER1_CAPT<br />
||Timer/Counter1 Capture Event<br />
|-<br />
|align="center" | 7<br />
|align="center" | 0x006<br />
|align="center" | TIMER1_COMPA<br />
||Timer/Counter1 Compare Match A<br />
|-<br />
|align="center" | 8<br />
|align="center" | 0x007<br />
|align="center" | TIMER1_COMPB<br />
||Timer/Counter1 Compare Match B<br />
|-<br />
|align="center" | 9<br />
|align="center" | 0x008<br />
|align="center" | TIMER1_OVF<br />
||Timer/Counter1 Overflow<br />
|-<br />
|align="center" | 10<br />
|align="center" | 0x009<br />
|align="center" | TIMER0_OVF<br />
||Timer/Counter0 Overflow<br />
|-<br />
|align="center" | 11<br />
|align="center" | 0x00A<br />
|align="center" | SPI_STC<br />
||SPI-Übertragung abgeschlossen<br />
|-<br />
|align="center" | 12<br />
|align="center" | 0x00B<br />
|align="center" | USART_RX<br />
||USART-Empfang abgeschlossen<br />
|-<br />
|align="center" | 13<br />
|align="center" | 0x00C<br />
|align="center" | USART_UDRE<br />
||USART-Datenregister leer<br />
|-<br />
|align="center" | 14<br />
|align="center" | 0x00D<br />
|align="center" | USART_TX<br />
||USART-Sendung abgeschlossen<br />
|-<br />
|align="center" | 15<br />
|align="center" | 0x00E<br />
|align="center" | ADC<br />
||AD-Wandlung abgeschlossen<br />
|-<br />
|align="center" | 16<br />
|align="center" | 0x00F<br />
|align="center" | EE_RDY<br />
||EEPROM bereit<br />
|-<br />
|align="center" | 17<br />
|align="center" | 0x010<br />
|align="center" | ANA_COMP<br />
||Analogkomparator<br />
|-<br />
|align="center" | 18<br />
|align="center" | 0x011<br />
|align="center" | TWI<br />
||Two-Wire Interface<br />
|-<br />
|align="center" | 19<br />
|align="center" | 0x012<br />
|align="center" | SPM_RDY<br />
||Store Program Memory Ready<br />
|}<br />
<small>Die Spalten „Nummer“ und „Adresse“ sind <u>so</u> im Original-Datenblatt eher verwirrend.<br />
Denn erfahrene Programmierer beginnen mit 0 zu zählen und denken in Byte-Adressen. Hier hingegen beginnt die Zählung mit 1, und es sind Word-Adressen.</small><br />
<br />
So, wir wissen jetzt, dass der Controller zu Adresse 0x001 springt, wenn INT0 auftritt. Aber dort ist ja nur Platz für einen Befehl, denn die nächste Adresse ist doch für INT1 reserviert. Wie geht das? Ganz einfach: Dort kommt ein Sprungbefehl rein, z.&nbsp;B. <code>rjmp interrupt0</code>. Irgendwo anders im Programm muss in diesem Fall eine Stelle mit <code>interrupt0:</code> gekennzeichnet sein, zu der dann gesprungen wird. Diese durch den Interrupt aufgerufene Routine nennt man ''Interrupthandler'' (engl. <span style="text-decoration:underline">I</span>nterrupt <span style="text-decoration:underline">S</span>ervice <span style="text-decoration:underline">R</span>outine, ISR).<br />
<br />
==Beenden eines Interrupthandlers==<br />
<br />
Und wie wird die Interruptroutine wieder beendet? Durch den Befehl '''<code>reti</code>'''. Wird dieser aufgerufen, dann wird das Programm ganz normal dort fortgesetzt, wo es durch den Interrupt unterbrochen wurde. Es ist dabei wichtig, daß hier der Befehl <code>reti</code> und nicht ein normaler <code>ret</code> benutzt wird. Wird ein Interrupthandler betreten, so sperrt der Mikrocontroller automatisch alle weiteren Interrupts. Im Unterschied zu <code>ret</code> hebt ein <code>reti</code> diese Sperre wieder auf.<br />
<br />
==Aufbau der Interruptvektortabelle==<br />
<br />
Jetzt müssen wir dem Assembler nur noch klarmachen, dass er unser <code>rjmp interrupt0</code> an die richtige Stelle im Programmspeicher schreibt, nämlich an den Interruptvektor für INT0. Dazu gibt es eine Assemblerdirektive. Durch <code>.org 0x001</code> sagt man dem Assembler, dass er die darauffolgenden Befehle ab Adresse 0x001 im Programmspeicher platzieren soll. Diese Stelle wird von INT0 angesprungen.<br />
<br />
Damit man nicht alle Interruptvektoren immer nachschlagen muss, sind in der Definitionsdatei m8def.inc einfach zu merkende Namen für die Adressen definiert. Statt 0x001 kann man z.&nbsp;B. einfach '''<code>INT0addr</code>''' schreiben. Das hat außerdem den Vorteil, dass man bei Portierung des Programms auf einen anderen AVR-Mikrocontroller nur die passende Definitionsdatei einbinden muss, und sich über evtl. geänderte Adressen für die Interruptvektoren keine Gedanken zu machen braucht.<br />
<br />
Nun gibt es nur noch ein Problem: Beim Reset (bzw. wenn die Spannung eingeschaltet wird) wird das Programm immer ab der Adresse 0x000 gestartet. Deswegen muss an diese Stelle ein Sprungbefehl zum Hauptprogramm erfolgen, z.&nbsp;B. '''<code>rjmp RESET</code>''', um an die mit '''<code>RESET:</code>''' markierte Stelle zu springen.<br />
<br />
Wenn man mehrere Interrupts verwenden möchte, kann man auch, anstatt jeden Interruptvektor einzeln mit <code>.org</code> an die richtige Stelle zu rücken, die gesamte Sprungtabelle ausschreiben:<br />
<br />
<syntaxhighlight lang="asm"><br />
.include "m8def.inc"<br />
<br />
.org 0x000 ; kommt ganz an den Anfang des Speichers<br />
rjmp RESET ; Interruptvektoren überspringen<br />
; und zum Hauptprogramm<br />
rjmp EXT_INT0 ; IRQ0 Handler<br />
rjmp EXT_INT1 ; IRQ1 Handler<br />
rjmp TIM2_COMP<br />
rjmp TIM2_OVF<br />
rjmp TIM1_CAPT ; Timer1 Capture Handler<br />
rjmp TIM1_COMPA ; Timer1 CompareA Handler<br />
rjmp TIM1_COMPB ; Timer1 CompareB Handler<br />
rjmp TIM1_OVF ; Timer1 Overflow Handler<br />
rjmp TIM0_OVF ; Timer0 Overflow Handler<br />
rjmp SPI_STC ; SPI Transfer Complete Handler<br />
rjmp USART_RXC ; USART RX Complete Handler<br />
rjmp USART_DRE ; UDR Empty Handler<br />
rjmp USART_TXC ; USART TX Complete Handler<br />
rjmp ADC ; ADC Conversion Complete Interrupthandler<br />
rjmp EE_RDY ; EEPROM Ready Handler<br />
rjmp ANA_COMP ; Analog Comparator Handler<br />
rjmp TWSI ; Two-wire Serial Interface Handler<br />
rjmp SPM_RDY ; Store Program Memory Ready Handler<br />
<br />
RESET: ; hier beginnt das Hauptprogramm<br />
</syntaxhighlight><br />
<br />
Hier ist es unbedingt nötig, bei unbenutzten Interruptvektoren statt des Sprungbefehls den Befehl '''<code>reti</code>''' (bzw. <code>reti nop</code>, wenn <code>jmp</code> 4&nbsp;Byte lang ist) reinzuschreiben. Wenn man einen Vektor einfach weglässt, stehen die nachfolgenden Sprungbefehle sonst alle an der falschen Adresse im Speicher.<br />
<br />
Wer auf Nummer sicher gehen möchte kann aber auch alle Vektoren einzeln mit <code>.org</code> adressieren:<br />
<br />
<syntaxhighlight lang="asm"><br />
.include "m8def.inc"<br />
<br />
.org 0x000<br />
rjmp RESET<br />
.org INT0addr ; External Interrupt0 Vector Address<br />
reti <br />
.org INT1addr ; External Interrupt1 Vector Address<br />
reti <br />
.org OC2addr ; Output Compare2 Interrupt Vector Address<br />
reti <br />
.org OVF2addr ; Overflow2 Interrupt Vector Address<br />
reti <br />
.org ICP1addr ; Input Capture1 Interrupt Vector Address<br />
reti <br />
.org OC1Aaddr ; Output Compare1A Interrupt Vector Address<br />
reti <br />
.org OC1Baddr ; Output Compare1B Interrupt Vector Address<br />
reti <br />
.org OVF1addr ; Overflow1 Interrupt Vector Address<br />
reti <br />
.org OVF0addr ; Overflow0 Interrupt Vector Address<br />
reti <br />
.org SPIaddr ; SPI Interrupt Vector Address<br />
reti <br />
.org URXCaddr ; USART Receive Complete Interrupt Vector Address<br />
reti <br />
.org UDREaddr ; USART Data Register Empty Interrupt Vector Address<br />
reti <br />
.org UTXCaddr ; USART Transmit Complete Interrupt Vector Address<br />
reti <br />
.org ADCCaddr ; ADC Interrupt Vector Address<br />
reti <br />
.org ERDYaddr ; EEPROM Interrupt Vector Address<br />
reti <br />
.org ACIaddr ; Analog Comparator Interrupt Vector Address<br />
reti <br />
.org TWIaddr ; Irq. vector address for Two-Wire Interface<br />
reti <br />
.org SPMRaddr ; SPM complete Interrupt Vector Address<br />
reti <br />
<br />
.org INT_VECTORS_SIZE<br />
RESET: ; hier beginnt das Hauptprogramm<br />
</syntaxhighlight><br />
<br />
Statt die unbenutzten Interruptvektoren mit <code>reti</code> zu füllen könnte man sie hier auch einfach weglassen, da die <code>.org</code>-Direktive dafür sorgt, dass jeder Vektor in jedem Fall am richtigen Ort im Speicher landet.<br />
<br />
==Beispiel==<br />
So könnte ein Minimal-Assemblerprogramm aussehen, das die Interrupts INT0 und INT1 verwendet. An die Interruptpins können z.&nbsp;B. Taster nach bewährter Manier angeschlossen werden. Die Interrupts werden auf fallende Flanke konfiguriert, da ja die Taster so angeschlossen sind, dass sie im Ruhezustand eine 1 liefern und bei einem Tastendruck nach 0 wechseln.<br />
<br />
[https://www.mikrocontroller.net/sourcecode/tutorial/extinttest.asm Download extinttest.asm]<br />
<br />
<syntaxhighlight lang="asm"><br />
.include "m8def.inc"<br />
<br />
.def temp = r16<br />
<br />
.org 0x000<br />
rjmp main ; Reset Handler<br />
.org INT0addr<br />
rjmp int0_handler ; IRQ0 Handler<br />
.org INT1addr<br />
rjmp int1_handler ; IRQ1 Handler<br />
<br />
<br />
main: ; hier beginnt das Hauptprogramm<br />
<br />
ldi temp, LOW(RAMEND)<br />
out SPL, temp<br />
ldi temp, HIGH(RAMEND)<br />
out SPH, temp<br />
<br />
ldi temp, 0x00<br />
out DDRD, temp<br />
<br />
ldi temp, 0xFF<br />
out DDRB, temp<br />
<br />
ldi temp, (1<<ISC01) | (1<<ISC11) ; INT0 und INT1 auf fallende Flanke konfigurieren<br />
out MCUCR, temp<br />
<br />
ldi temp, (1<<INT0) | (1<<INT1) ; INT0 und INT1 aktivieren<br />
out GICR, temp<br />
<br />
sei ; Interrupts allgemein aktivieren<br />
<br />
loop: rjmp loop ; eine leere Endlosschleife<br />
<br />
int0_handler:<br />
sbi PORTB, 0<br />
reti<br />
<br />
int1_handler:<br />
cbi PORTB, 0<br />
reti<br />
</syntaxhighlight><br />
<br />
Für dieses Programm braucht man nichts weiter als eine LED an PB0 und je einen Taster an PD2 (INT0) und PD3 (INT1). Wie diese angeschlossen werden, steht in [[AVR-Tutorial: IO-Grundlagen|Teil 2 des Tutorials]].<br />
<br />
Die Funktion ist auch nicht schwer zu verstehen: Drückt man eine Taste, wird der dazugehörige Interrupt aufgerufen und die LED an- oder abgeschaltet. Das ist zwar nicht sonderlich spektakulär, aber das Prinzip sollte deutlich werden.<br />
<br />
Meistens macht es keinen Sinn, Taster direkt an einen Interrupteingang anzuschließen. Das kann bisweilen sogar sehr schlecht sein, siehe [[Entprellung]]. Häufiger werden Interrupts in Zusammenhang mit dem UART verwendet, um z.&nbsp;B. auf ein empfangenes Zeichen zu reagieren. Wie das funktioniert, wird im [[AVR-Tutorial: UART|Kapitel über den UART]] beschrieben.<br />
<br />
==Besonderheiten des Interrupthandlers==<br />
<br />
Der Interrupthandler kann ja mehr oder weniger zu jedem beliebigen Zeitpunkt unabhängig vom restlichen Programm aufgerufen werden. Dabei soll das restliche Programm auf keinen Fall durch den Interrupthandler negativ beeinflusst werden, das heißt, das Hauptprogramm soll nach dem Beenden des Handlers weiterlaufen als wäre nichts passiert. Insbesondere muss deshalb darauf geachtet werden, dass im Interrupthandler Register, die vom Programmierer nicht ausschließlich nur für den Interrupthandler reserviert wurden, auf dem Stack gesichert und zum Schluss wieder hergestellt werden müssen.<br />
<br />
Ein Register, das gerne übersehen wird, ist das '''Statusregister (SREG)'''. In ihm merkt sich der Prozessor bestimmte Zustände von Berechnungen, z.&nbsp;B. ob ein arithmetischer Überlauf stattgefunden hat, ob das letzte Rechenergebnis 0 war, etc. Sobald ein Interrupthandler etwas komplizierter wird als im obigen Beispiel, tut man gut daran, das Statusregister auf jeden Fall zu sichern. Ansonsten kann das Hinzufügen von weiterem Code zum Interrupthandler schnell zum Boomerang werden: Die dann möglicherweise notwendige Sicherung des SREG wird vergessen. Überhaupt empfiehlt es sich, in diesen Dingen bei der Programmierung eines Interrupthandlers eher vorausschauend, übervorsichtig und konservativ zu programmieren. Wird dies getan, so vergeudet man höchstens ein bisschen Rechenzeit. Im anderen Fall handelt man sich allerdings einen Super-GAU ein: Man steht dann vor einem Programm, das sporadisch nicht funktioniert und keiner weiß warum. Solche Fehler sind nur sehr schwer und oft nur mit einem Quäntchen Glück zu finden.<br />
<br />
Im Beispiel wäre zwar das Sichern und Wiederherstellen der Register „temp“ und SREG nicht wirklich notwendig, aber hier soll die grundsätzliche Vorgehensweise gezeigt werden:<br />
<br />
<syntaxhighlight lang="asm"><br />
.include "m8def.inc"<br />
<br />
.def temp = r16<br />
<br />
.org 0x000<br />
rjmp main ; Reset Handler<br />
.org INT0addr<br />
rjmp int0_handler ; IRQ0 Handler<br />
.org INT1addr<br />
rjmp int1_handler ; IRQ1 Handler<br />
<br />
<br />
main: ; hier beginnt das Hauptprogramm<br />
<br />
ldi temp, LOW(RAMEND)<br />
out SPL, temp<br />
ldi temp, HIGH(RAMEND)<br />
out SPH, temp<br />
<br />
ldi temp, 0x00<br />
out DDRD, temp<br />
<br />
ldi temp, 0xFF<br />
out DDRB, temp<br />
<br />
ldi temp, (1<<ISC01) | (1<<ISC11) ; INT0 und INT1 auf fallende Flanke konfigurieren<br />
out MCUCR, temp<br />
<br />
ldi temp, (1<<INT0) | (1<<INT1) ; INT0 und INT1 aktivieren<br />
out GICR, temp<br />
<br />
sei ; Interrupts allgemein aktivieren<br />
<br />
loop: rjmp loop ; eine leere Endlosschleife<br />
<br />
int0_handler:<br />
push temp ; Das SREG in temp sichern. Vorher<br />
in temp, SREG ; muss natürlich temp gesichert werden<br />
<br />
sbi PORTB, 0<br />
<br />
out SREG, temp ; Die Register SREG und temp wieder<br />
pop temp ; herstellen<br />
reti<br />
<br />
int1_handler:<br />
push temp ; Das SREG in temp sichern. Vorher<br />
in temp, SREG ; muss natürlich temp gesichert werden<br />
<br />
cbi PORTB, 0<br />
<br />
out SREG, temp ; Die Register SREG und temp wieder<br />
pop temp ; herstellen<br />
reti<br />
</syntaxhighlight><br />
<br />
==Siehe auch==<br />
* Artikel [[Interrupt]]: Interrupts in C<br />
* [https://www.mikrocontroller.net/topic/353715?goto=3945222#3945222 Forumsbeitrag]: Flexible Verwaltung von Interruptroutinen ohne zentrale Interrupttabelle<br />
<br />
----<br />
<br />
{{Navigation_zurückhochvor|<br />
zurücktext=LCD|<br />
zurücklink=AVR-Tutorial: LCD|<br />
hochtext=Inhaltsverzeichnis|<br />
hochlink=AVR-Tutorial|<br />
vortext=Vergleiche|<br />
vorlink=AVR-Tutorial: Vergleiche}}<br />
<br />
[[Category:AVR-Tutorial|Interrupts]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR-Tutorial:_Interrupts&diff=107252AVR-Tutorial: Interrupts2025-01-27T13:14:33Z<p>Heha: /* Mögliche Auslöser */</p>
<hr />
<div>==Definition==<br />
<br />
Bei bestimmten Ereignissen in Prozessoren wird ein sogenannter '''Interrupt''' ausgelöst. Interrupts machen es möglich, beim Eintreten eines Ereignisses sofort informiert zu werden, ohne permanent irgendeinen Status abzufragen, was teure Rechenzeit kosten würde. Dabei wird das Programm unterbrochen und ein Unterprogramm aufgerufen. Wenn dieses beendet ist, läuft das Hauptprogramm ganz normal weiter.<br />
<br />
==Mögliche Auslöser==<br />
<br />
Bei Mikrocontrollern werden Interrupts z.&nbsp;B. ausgelöst, wenn:<br />
<br />
* sich der an einem bestimmten Eingangs-Pin anliegende Wert von high auf low ändert (oder umgekehrt)<br />
* eine vorher festgelegte Zeitspanne abgelaufen ist ([[Timer]])<br />
* eine serielle Übertragung abgeschlossen ist ([[UART]])<br />
* …<br />
<br />
Der ATmega8 besitzt 18 verschiedene Interruptquellen. Standardmäßig sind diese alle deaktiviert und müssen über verschiedene IO-Register einzeln eingeschaltet werden. Zusätzlich muss mit <tt>sei()</tt> auch das I-Flag gesetzt werden.<br />
<br />
==INT0, INT1 und die zugehörigen Register==<br />
<br />
Wir wollen uns hier ersteinmal die beiden Interrupts '''INT0''' und '''INT1''' anschauen. INT0 wird ausgelöst, wenn sich der an PD2 anliegende Wert ändert, INT1 reagiert auf Änderungen an PD3.<br />
<br />
Als erstes müssen wir die beiden Interrupts konfigurieren. Im Register '''MCUCR''' wird eingestellt, ob die Interrupts bei einer steigenden Flanke (low nach high) oder bei einer fallenden Flanke (high nach low) ausgelöst werden. Dafür gibt es in diesem Register die Bits '''ISC00''', '''ISC01''' (betreffen INT0) sowie '''ISC10''' und '''ISC11''' (betreffen INT1).<br />
<br />
Hier eine Übersicht über die möglichen Einstellungen und was sie bewirken:<br />
<br />
{| class="wikitable"<br />
! ISC11 bzw. ISC01 || ISC10 bzw. ISC00 ||Beschreibung<br />
|-<br />
|align="center" | 0<br />
|align="center" | 0<br />
||Low-Level am Pin löst den Interrupt aus<br />
|-<br />
|align="center" | 0<br />
|align="center" | 1<br />
||Jede Änderung am Pin löst den Interrupt aus<br />
|-<br />
|align="center" | 1<br />
|align="center" | 0<br />
||Eine fallende Flanke löst den Interrupt aus<br />
|-<br />
|align="center" | 1<br />
|align="center" | 1<br />
||Eine steigende Flanke löst den Interrupt aus<br />
|}<br />
<br />
Danach müssen diese beiden Interrupts aktiviert werden, indem die Bits '''INT0''' und '''INT1''' im Register '''GICR''' auf '''1''' gesetzt werden.<br />
<br />
Die Register '''MCUCR''' und '''GICR''' gehören zwar zu den IO-Registern, können aber nicht wie andere mit den Befehlen <code>cbi</code> und <code>sbi</code> verwendet werden. Diese Befehle wirken nur auf die IO-Register bis zur Adresse 0x1F (welches Register sich an welcher IO-Adresse befindet, steht in der Include-Datei, hier „m8def.inc“, und im Datenblatt des Controllers). Somit bleiben zum Zugriff auf diese Register nur die Befehle <code>in</code> und <code>out</code> übrig.<br />
<br />
==Interrupts generell zulassen==<br />
<br />
Schließlich muss man noch das Ausführen von Interrupts allgemein aktivieren, was man durch einfaches Aufrufen des Assemblerbefehls '''<code>sei</code>''' bewerkstelligt.<br />
<br />
==Die Interruptvektoren==<br />
<br />
Woher weiß der Controller jetzt, welche Routine aufgerufen werden muss, wenn ein Interrupt ausgelöst wird?<br />
<br />
Wenn ein Interrupt auftritt, dann springt die Programmausführung an eine bestimmte Stelle im Programmspeicher. Diese Stellen sind festgelegt und können nicht geändert werden:<br />
<br />
{| class="wikitable"<br />
! Nr. || Adresse || Interruptname || Beschreibung<br />
|-<br />
|align="center" | 1<br />
|align="center" | 0x000<br />
|align="center" | RESET<br />
||Reset bzw. Einschalten der Stromversorgung<br />
|-<br />
|align="center" | 2<br />
|align="center" | 0x001<br />
|align="center" | INT0<br />
||Externer Interrupt 0<br />
|-<br />
|align="center" | 3<br />
|align="center" | 0x002<br />
|align="center" | INT1<br />
||Externer Interrupt 1<br />
|-<br />
|align="center" | 4<br />
|align="center" | 0x003<br />
|align="center" | TIMER2_COMP<br />
||Timer/Counter2 Compare Match<br />
|-<br />
|align="center" | 5<br />
|align="center" | 0x004<br />
|align="center" | TIMER2_OVF<br />
||Timer/Counter2 Overflow<br />
|-<br />
|align="center" | 6<br />
|align="center" | 0x005<br />
|align="center" | TIMER1_CAPT<br />
||Timer/Counter1 Capture Event<br />
|-<br />
|align="center" | 7<br />
|align="center" | 0x006<br />
|align="center" | TIMER1_COMPA<br />
||Timer/Counter1 Compare Match A<br />
|-<br />
|align="center" | 8<br />
|align="center" | 0x007<br />
|align="center" | TIMER1_COMPB<br />
||Timer/Counter1 Compare Match B<br />
|-<br />
|align="center" | 9<br />
|align="center" | 0x008<br />
|align="center" | TIMER1_OVF<br />
||Timer/Counter1 Overflow<br />
|-<br />
|align="center" | 10<br />
|align="center" | 0x009<br />
|align="center" | TIMER0_OVF<br />
||Timer/Counter0 Overflow<br />
|-<br />
|align="center" | 11<br />
|align="center" | 0x00A<br />
|align="center" | SPI_STC<br />
||SPI-Übertragung abgeschlossen<br />
|-<br />
|align="center" | 12<br />
|align="center" | 0x00B<br />
|align="center" | USART_RX<br />
||USART-Empfang abgeschlossen<br />
|-<br />
|align="center" | 13<br />
|align="center" | 0x00C<br />
|align="center" | USART_UDRE<br />
||USART-Datenregister leer<br />
|-<br />
|align="center" | 14<br />
|align="center" | 0x00D<br />
|align="center" | USART_TX<br />
||USART-Sendung abgeschlossen<br />
|-<br />
|align="center" | 15<br />
|align="center" | 0x00E<br />
|align="center" | ADC<br />
||AD-Wandlung abgeschlossen<br />
|-<br />
|align="center" | 16<br />
|align="center" | 0x00F<br />
|align="center" | EE_RDY<br />
||EEPROM bereit<br />
|-<br />
|align="center" | 17<br />
|align="center" | 0x010<br />
|align="center" | ANA_COMP<br />
||Analogkomparator<br />
|-<br />
|align="center" | 18<br />
|align="center" | 0x011<br />
|align="center" | TWI<br />
||Two-Wire Interface<br />
|-<br />
|align="center" | 19<br />
|align="center" | 0x012<br />
|align="center" | SPM_RDY<br />
||Store Program Memory Ready<br />
|}<br />
<br />
So, wir wissen jetzt, dass der Controller zu Adresse 0x001 springt, wenn INT0 auftritt. Aber dort ist ja nur Platz für einen Befehl, denn die nächste Adresse ist doch für INT1 reserviert. Wie geht das? Ganz einfach: Dort kommt ein Sprungbefehl rein, z.&nbsp;B. <code>rjmp interrupt0</code>. Irgendwo anders im Programm muss in diesem Fall eine Stelle mit <code>interrupt0:</code> gekennzeichnet sein, zu der dann gesprungen wird. Diese durch den Interrupt aufgerufene Routine nennt man ''Interrupthandler'' (engl. <span style="text-decoration:underline">I</span>nterrupt <span style="text-decoration:underline">S</span>ervice <span style="text-decoration:underline">R</span>outine, ISR).<br />
<br />
==Beenden eines Interrupthandlers==<br />
<br />
Und wie wird die Interruptroutine wieder beendet? Durch den Befehl '''<code>reti</code>'''. Wird dieser aufgerufen, dann wird das Programm ganz normal dort fortgesetzt, wo es durch den Interrupt unterbrochen wurde. Es ist dabei wichtig, daß hier der Befehl <code>reti</code> und nicht ein normaler <code>ret</code> benutzt wird. Wird ein Interrupthandler betreten, so sperrt der Mikrocontroller automatisch alle weiteren Interrupts. Im Unterschied zu <code>ret</code> hebt ein <code>reti</code> diese Sperre wieder auf.<br />
<br />
==Aufbau der Interruptvektortabelle==<br />
<br />
Jetzt müssen wir dem Assembler nur noch klarmachen, dass er unser <code>rjmp interrupt0</code> an die richtige Stelle im Programmspeicher schreibt, nämlich an den Interruptvektor für INT0. Dazu gibt es eine Assemblerdirektive. Durch <code>.org 0x001</code> sagt man dem Assembler, dass er die darauffolgenden Befehle ab Adresse 0x001 im Programmspeicher platzieren soll. Diese Stelle wird von INT0 angesprungen.<br />
<br />
Damit man nicht alle Interruptvektoren immer nachschlagen muss, sind in der Definitionsdatei m8def.inc einfach zu merkende Namen für die Adressen definiert. Statt 0x001 kann man z.&nbsp;B. einfach '''<code>INT0addr</code>''' schreiben. Das hat außerdem den Vorteil, dass man bei Portierung des Programms auf einen anderen AVR-Mikrocontroller nur die passende Definitionsdatei einbinden muss, und sich über evtl. geänderte Adressen für die Interruptvektoren keine Gedanken zu machen braucht.<br />
<br />
Nun gibt es nur noch ein Problem: Beim Reset (bzw. wenn die Spannung eingeschaltet wird) wird das Programm immer ab der Adresse 0x000 gestartet. Deswegen muss an diese Stelle ein Sprungbefehl zum Hauptprogramm erfolgen, z.&nbsp;B. '''<code>rjmp RESET</code>''', um an die mit '''<code>RESET:</code>''' markierte Stelle zu springen.<br />
<br />
Wenn man mehrere Interrupts verwenden möchte, kann man auch, anstatt jeden Interruptvektor einzeln mit <code>.org</code> an die richtige Stelle zu rücken, die gesamte Sprungtabelle ausschreiben:<br />
<br />
<syntaxhighlight lang="asm"><br />
.include "m8def.inc"<br />
<br />
.org 0x000 ; kommt ganz an den Anfang des Speichers<br />
rjmp RESET ; Interruptvektoren überspringen<br />
; und zum Hauptprogramm<br />
rjmp EXT_INT0 ; IRQ0 Handler<br />
rjmp EXT_INT1 ; IRQ1 Handler<br />
rjmp TIM2_COMP<br />
rjmp TIM2_OVF<br />
rjmp TIM1_CAPT ; Timer1 Capture Handler<br />
rjmp TIM1_COMPA ; Timer1 CompareA Handler<br />
rjmp TIM1_COMPB ; Timer1 CompareB Handler<br />
rjmp TIM1_OVF ; Timer1 Overflow Handler<br />
rjmp TIM0_OVF ; Timer0 Overflow Handler<br />
rjmp SPI_STC ; SPI Transfer Complete Handler<br />
rjmp USART_RXC ; USART RX Complete Handler<br />
rjmp USART_DRE ; UDR Empty Handler<br />
rjmp USART_TXC ; USART TX Complete Handler<br />
rjmp ADC ; ADC Conversion Complete Interrupthandler<br />
rjmp EE_RDY ; EEPROM Ready Handler<br />
rjmp ANA_COMP ; Analog Comparator Handler<br />
rjmp TWSI ; Two-wire Serial Interface Handler<br />
rjmp SPM_RDY ; Store Program Memory Ready Handler<br />
<br />
RESET: ; hier beginnt das Hauptprogramm<br />
</syntaxhighlight><br />
<br />
Hier ist es unbedingt nötig, bei unbenutzten Interruptvektoren statt des Sprungbefehls den Befehl '''<code>reti</code>''' (bzw. <code>reti nop</code>, wenn <code>jmp</code> 4&nbsp;Byte lang ist) reinzuschreiben. Wenn man einen Vektor einfach weglässt, stehen die nachfolgenden Sprungbefehle sonst alle an der falschen Adresse im Speicher.<br />
<br />
Wer auf Nummer sicher gehen möchte kann aber auch alle Vektoren einzeln mit <code>.org</code> adressieren:<br />
<br />
<syntaxhighlight lang="asm"><br />
.include "m8def.inc"<br />
<br />
.org 0x000<br />
rjmp RESET<br />
.org INT0addr ; External Interrupt0 Vector Address<br />
reti <br />
.org INT1addr ; External Interrupt1 Vector Address<br />
reti <br />
.org OC2addr ; Output Compare2 Interrupt Vector Address<br />
reti <br />
.org OVF2addr ; Overflow2 Interrupt Vector Address<br />
reti <br />
.org ICP1addr ; Input Capture1 Interrupt Vector Address<br />
reti <br />
.org OC1Aaddr ; Output Compare1A Interrupt Vector Address<br />
reti <br />
.org OC1Baddr ; Output Compare1B Interrupt Vector Address<br />
reti <br />
.org OVF1addr ; Overflow1 Interrupt Vector Address<br />
reti <br />
.org OVF0addr ; Overflow0 Interrupt Vector Address<br />
reti <br />
.org SPIaddr ; SPI Interrupt Vector Address<br />
reti <br />
.org URXCaddr ; USART Receive Complete Interrupt Vector Address<br />
reti <br />
.org UDREaddr ; USART Data Register Empty Interrupt Vector Address<br />
reti <br />
.org UTXCaddr ; USART Transmit Complete Interrupt Vector Address<br />
reti <br />
.org ADCCaddr ; ADC Interrupt Vector Address<br />
reti <br />
.org ERDYaddr ; EEPROM Interrupt Vector Address<br />
reti <br />
.org ACIaddr ; Analog Comparator Interrupt Vector Address<br />
reti <br />
.org TWIaddr ; Irq. vector address for Two-Wire Interface<br />
reti <br />
.org SPMRaddr ; SPM complete Interrupt Vector Address<br />
reti <br />
<br />
.org INT_VECTORS_SIZE<br />
RESET: ; hier beginnt das Hauptprogramm<br />
</syntaxhighlight><br />
<br />
Statt die unbenutzten Interruptvektoren mit <code>reti</code> zu füllen könnte man sie hier auch einfach weglassen, da die <code>.org</code>-Direktive dafür sorgt, dass jeder Vektor in jedem Fall am richtigen Ort im Speicher landet.<br />
<br />
==Beispiel==<br />
So könnte ein Minimal-Assemblerprogramm aussehen, das die Interrupts INT0 und INT1 verwendet. An die Interruptpins können z.&nbsp;B. Taster nach bewährter Manier angeschlossen werden. Die Interrupts werden auf fallende Flanke konfiguriert, da ja die Taster so angeschlossen sind, dass sie im Ruhezustand eine 1 liefern und bei einem Tastendruck nach 0 wechseln.<br />
<br />
[https://www.mikrocontroller.net/sourcecode/tutorial/extinttest.asm Download extinttest.asm]<br />
<br />
<syntaxhighlight lang="asm"><br />
.include "m8def.inc"<br />
<br />
.def temp = r16<br />
<br />
.org 0x000<br />
rjmp main ; Reset Handler<br />
.org INT0addr<br />
rjmp int0_handler ; IRQ0 Handler<br />
.org INT1addr<br />
rjmp int1_handler ; IRQ1 Handler<br />
<br />
<br />
main: ; hier beginnt das Hauptprogramm<br />
<br />
ldi temp, LOW(RAMEND)<br />
out SPL, temp<br />
ldi temp, HIGH(RAMEND)<br />
out SPH, temp<br />
<br />
ldi temp, 0x00<br />
out DDRD, temp<br />
<br />
ldi temp, 0xFF<br />
out DDRB, temp<br />
<br />
ldi temp, (1<<ISC01) | (1<<ISC11) ; INT0 und INT1 auf fallende Flanke konfigurieren<br />
out MCUCR, temp<br />
<br />
ldi temp, (1<<INT0) | (1<<INT1) ; INT0 und INT1 aktivieren<br />
out GICR, temp<br />
<br />
sei ; Interrupts allgemein aktivieren<br />
<br />
loop: rjmp loop ; eine leere Endlosschleife<br />
<br />
int0_handler:<br />
sbi PORTB, 0<br />
reti<br />
<br />
int1_handler:<br />
cbi PORTB, 0<br />
reti<br />
</syntaxhighlight><br />
<br />
Für dieses Programm braucht man nichts weiter als eine LED an PB0 und je einen Taster an PD2 (INT0) und PD3 (INT1). Wie diese angeschlossen werden, steht in [[AVR-Tutorial: IO-Grundlagen|Teil 2 des Tutorials]].<br />
<br />
Die Funktion ist auch nicht schwer zu verstehen: Drückt man eine Taste, wird der dazugehörige Interrupt aufgerufen und die LED an- oder abgeschaltet. Das ist zwar nicht sonderlich spektakulär, aber das Prinzip sollte deutlich werden.<br />
<br />
Meistens macht es keinen Sinn, Taster direkt an einen Interrupteingang anzuschließen. Das kann bisweilen sogar sehr schlecht sein, siehe [[Entprellung]]. Häufiger werden Interrupts in Zusammenhang mit dem UART verwendet, um z.&nbsp;B. auf ein empfangenes Zeichen zu reagieren. Wie das funktioniert, wird im [[AVR-Tutorial: UART|Kapitel über den UART]] beschrieben.<br />
<br />
==Besonderheiten des Interrupthandlers==<br />
<br />
Der Interrupthandler kann ja mehr oder weniger zu jedem beliebigen Zeitpunkt unabhängig vom restlichen Programm aufgerufen werden. Dabei soll das restliche Programm auf keinen Fall durch den Interrupthandler negativ beeinflusst werden, das heißt, das Hauptprogramm soll nach dem Beenden des Handlers weiterlaufen als wäre nichts passiert. Insbesondere muss deshalb darauf geachtet werden, dass im Interrupthandler Register, die vom Programmierer nicht ausschließlich nur für den Interrupthandler reserviert wurden, auf dem Stack gesichert und zum Schluss wieder hergestellt werden müssen.<br />
<br />
Ein Register, das gerne übersehen wird, ist das '''Statusregister (SREG)'''. In ihm merkt sich der Prozessor bestimmte Zustände von Berechnungen, z.&nbsp;B. ob ein arithmetischer Überlauf stattgefunden hat, ob das letzte Rechenergebnis 0 war, etc. Sobald ein Interrupthandler etwas komplizierter wird als im obigen Beispiel, tut man gut daran, das Statusregister auf jeden Fall zu sichern. Ansonsten kann das Hinzufügen von weiterem Code zum Interrupthandler schnell zum Boomerang werden: Die dann möglicherweise notwendige Sicherung des SREG wird vergessen. Überhaupt empfiehlt es sich, in diesen Dingen bei der Programmierung eines Interrupthandlers eher vorausschauend, übervorsichtig und konservativ zu programmieren. Wird dies getan, so vergeudet man höchstens ein bisschen Rechenzeit. Im anderen Fall handelt man sich allerdings einen Super-GAU ein: Man steht dann vor einem Programm, das sporadisch nicht funktioniert und keiner weiß warum. Solche Fehler sind nur sehr schwer und oft nur mit einem Quäntchen Glück zu finden.<br />
<br />
Im Beispiel wäre zwar das Sichern und Wiederherstellen der Register „temp“ und SREG nicht wirklich notwendig, aber hier soll die grundsätzliche Vorgehensweise gezeigt werden:<br />
<br />
<syntaxhighlight lang="asm"><br />
.include "m8def.inc"<br />
<br />
.def temp = r16<br />
<br />
.org 0x000<br />
rjmp main ; Reset Handler<br />
.org INT0addr<br />
rjmp int0_handler ; IRQ0 Handler<br />
.org INT1addr<br />
rjmp int1_handler ; IRQ1 Handler<br />
<br />
<br />
main: ; hier beginnt das Hauptprogramm<br />
<br />
ldi temp, LOW(RAMEND)<br />
out SPL, temp<br />
ldi temp, HIGH(RAMEND)<br />
out SPH, temp<br />
<br />
ldi temp, 0x00<br />
out DDRD, temp<br />
<br />
ldi temp, 0xFF<br />
out DDRB, temp<br />
<br />
ldi temp, (1<<ISC01) | (1<<ISC11) ; INT0 und INT1 auf fallende Flanke konfigurieren<br />
out MCUCR, temp<br />
<br />
ldi temp, (1<<INT0) | (1<<INT1) ; INT0 und INT1 aktivieren<br />
out GICR, temp<br />
<br />
sei ; Interrupts allgemein aktivieren<br />
<br />
loop: rjmp loop ; eine leere Endlosschleife<br />
<br />
int0_handler:<br />
push temp ; Das SREG in temp sichern. Vorher<br />
in temp, SREG ; muss natürlich temp gesichert werden<br />
<br />
sbi PORTB, 0<br />
<br />
out SREG, temp ; Die Register SREG und temp wieder<br />
pop temp ; herstellen<br />
reti<br />
<br />
int1_handler:<br />
push temp ; Das SREG in temp sichern. Vorher<br />
in temp, SREG ; muss natürlich temp gesichert werden<br />
<br />
cbi PORTB, 0<br />
<br />
out SREG, temp ; Die Register SREG und temp wieder<br />
pop temp ; herstellen<br />
reti<br />
</syntaxhighlight><br />
<br />
==Siehe auch==<br />
* Artikel [[Interrupt]]: Interrupts in C<br />
* [https://www.mikrocontroller.net/topic/353715?goto=3945222#3945222 Forumsbeitrag]: Flexible Verwaltung von Interruptroutinen ohne zentrale Interrupttabelle<br />
<br />
----<br />
<br />
{{Navigation_zurückhochvor|<br />
zurücktext=LCD|<br />
zurücklink=AVR-Tutorial: LCD|<br />
hochtext=Inhaltsverzeichnis|<br />
hochlink=AVR-Tutorial|<br />
vortext=Vergleiche|<br />
vorlink=AVR-Tutorial: Vergleiche}}<br />
<br />
[[Category:AVR-Tutorial|Interrupts]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR-Tutorial:_Vergleiche&diff=107251AVR-Tutorial: Vergleiche2025-01-27T13:10:43Z<p>Heha: Zweierkomplement</p>
<hr />
<div>Vergleiche und Entscheidungen sind in jeder Programmiersprache ein zentrales Mittel, um den Programmfluss abhängig von Bedingungen zu kontrollieren. In einem [[AVR]] spielen dazu vier Komponenten zusammen:<br />
* Vergleichsbefehle,<br />
* die Flags im Statusregister,<br />
* bedingte Sprungbefehle,<br />
* andere Befehle, die die Flags im Statusregister beeinflussen, wie z.&nbsp;B. die meisten arithmetischen Funktionen.<br />
<br />
Der Zusammenhang ist dabei folgender: Die Vergleichsbefehle führen einen Vergleich durch, zum Beispiel zwischen zwei Registern oder zwischen einem Register und einer Konstanten. Das Ergebnis des Vergleiches wird in den Flags abgelegt. Die bedingten Sprungbefehle werten die Flags aus und führen bei einem positiven Ergebnis den Sprung aus. Besonders der erste Satzteil ist wichtig! Den bedingten Sprungbefehlen ist es nämlich völlig egal, ob die Flags über Vergleichsbefehle oder über sonstige Befehle gesetzt wurden. Die Sprungbefehle werten einfach nur die Flags aus, wie auch immer diese zu ihrem Zustand kommen.<br />
<br />
==Flags==<br />
<br />
Die Flags sind Bits im Statusregister '''SREG'''. Ihre Aufgabe ist es, das Auftreten bestimmter Ereignisse, die während Berechnungen eintreten können, festzuhalten.<br />
Speicherbefehle (LD, LDI, ST, MOV, …) haben auf dem AVR grundsätzlich keinen Einfluss auf das Statusregister. Will man den Inhalt eines Registers explizit testen (z.&nbsp;B. nach dem Laden aus dem SRAM), so kann man hierfür den TST-Befehl verwenden.<br />
<br />
<!--<br />
+---+---+---+---+---+---+---+---+<br />
| I | T | H | S | V | N | Z | C |<br />
+---+---+---+---+---+---+---+---+<br />
--><br />
<br />
<center><br />
{{Byte|Bits im SREG| I|T|H|S|V|N|Z|C}}<br />
</center><br />
<br />
===Carry (C)===<br />
Das Carry-Flag hält fest, ob es bei der letzten Berechnung einen Über- oder Unterlauf gab. Aber Achtung: Nicht alle arithmetischen Befehle verändern tatsächlich das Carry-Flag. So haben z.&nbsp;B. die Inkrementier- und Dekrementierbefehle keine Auswirkung auf dieses Flag.<br />
<br />
Weiterhin dient das C-Flag als „neuntes Bit“ für Schiebeoperationen und die Befehle <tt>adc</tt>, <tt>sbc</tt>, <tt>sbic</tt> und <tt>cpc</tt>.<br />
<br />
===Zero (Z)===<br />
Das Zero-Flag hält fest, ob das Ergebnis der letzten 8-Bit-Berechnung gleich 0 war oder nicht.<br />
<br />
<b>Achtung:</b> Einige AVR-Befehle „kaskadieren“ das Z-Flag: Arithmetische Operationen mit C-Flag als Input, vor allem <tt>cpc</tt> (compare with carry). Damit eignet es sich zur Nullfeststellung für beliebig breite Zahlen. IMHO keine weitere Prozessorarchitektur tut das.<br />
<br />
===Negative (N)===<br />
Spiegelt den Zustand des höchstwertigen Bits (Bit 7) der letzten 8-Bit-Berechnung wider. In Zweierkomplement-Arithmetik — Standard bei allen Compilern für Ganzzahlen — bedeutet ein gesetztes Bit 7 eine negative Zahl. Das Bit kann also dazu genutzt werden um festzustellen, ob das Ergebnis einer Berechnung im Sinne einer Zweierkomplement-Arithmetik positiv oder negativ ist.<br />
<br />
===Overflow (V)===<br />
Dieses Bit wird gesetzt, wenn bei einer Berechnung mit Zweierkomplement-Arithmetik (Standard für vorzeichenbehaftete Ganzzahlen bei jedem Compiler) ein Überlauf (Unterlauf) stattgefunden hat. Dies entspricht einem Überlauf von Bit 6 ins Bit 7.<br />
<br />
Der Übertrag, der bei der Addition/Subtraktion von Bit 6 auf Bit 7 auftritt, zeigt daher — wenn er vorhanden ist — an,<br />
dass es sich hier um einen Überlauf (Overflow) des Zahlenbereichs handelt und das Ergebnis falsch ist.<br />
Das ist allerdings nicht der Fall, wenn auch der Übertrag von Bit 7 nach Bit 8 (Carry) aufgetreten ist.<br />
Daher ist das Overflow-Flag die [[AVR-Tutorial: Logik#XOR (Exklusives Oder)|XOR-Verknüpfung]] aus dem Übertrag von Bit 6 nach Bit 7 und dem Carry.<br />
<br />
Beispiele für die Anwendung des V-Flags finden sich in [[AVR Arithmetik/Saturierung|saturierter Arithmetik]].<br />
<br />
<b>Merke:</b> Das V-Flag ist für <u>vorzeichenbehaftete</u> Zahlen. Das C-Flag ist für <u>vorzeichenlose</u> Zahlen auszuwerten. Eine <i>gemischte Arithmetik</i> (vzb. + vzl.) ist hingegen <i>sehr schwierig</i> und „zu Fuß“ auf Überläufe zu prüfen! Im Compiler behilft man sich mit einem Cast zum nächstgrößeren Datentyp.<br />
<br />
===Signed (S)===<br />
Das Signed-Bit ergibt sich aus der Antivalenz (exklusives Oder) der Flags N und V, also S = N XOR V.<br />
Mit Hilfe des Signed-Flags können vorzeichenbehaftete Werte miteinander verglichen werden. Ist nach einem Vergleich zweier Register S=1, so ist der Wert des ersten Registers kleiner dem zweiten (in der Signed-Darstellung). Damit entspricht das Signed-Flag gewissermaßen dem Carry-Flag für Signed-Werte. Es wird hauptsächlich für „Signed“-Tests benötigt. Daher auch der Name.<br />
<br />
===Half Carry (H)===<br />
Das Half-Carry-Flag hat die gleiche Aufgabe wie das Carry Flag, nur beschäftigt es sich mit einem Überlauf von Bit 3 nach Bit 4, also dem Übertrag zwischen dem oberen und dem unteren Nibble. Wie beim Carry-Flag gilt, dass das Flag nicht durch Inkrementieren bzw. Dekrementieren ausgelöst werden kann.<br />
Das Haupteinsatzgebiet ist der Bereich der BCD-Arithmetik (binär codierte Dezimalzahlen), bei der jeweils 4 Bits eine Stelle einer Dezimalzahl repräsentieren.<br />
<br />
Kein Compiler benutzt das H-Flag. Findet man die Befehle <tt>brhc</tt>, <tt>brhs</tt>, <tt>clh</tt> oder <tt>seh</tt> in einem Disassemblerlisting, sind das entweder Daten oder es wurde in Assembler programmiert. Das H-Flag lässt sich bspw. dazu verwenden, zwei Zähler in einem Byte zu realisieren. So signalisiert das H-Flag in einem <u>Bit</u>zähler, wann das nächste <u>Byte</u> nachzuladen ist, indem man 2 addiert. Das reicht für 127 Bit.<br />
<br />
=== Transfer (T)===<br />
Das T-Flag ist kein Statusbit im eigentlichen Sinne. Es steht dem Programmierer als 1-Bit-Speicher zur Verfügung. Der Zugriff erfolgt über die Befehle Bit Load (BLD), Bit Store (BST), Set-T (SET) und Clear-T (CLT) und wird sonst von keinen anderen Befehlen beeinflusst. Damit können Bits von einer Stelle schnell an eine andere kopiert oder getestet werden. Es gibt <i>keinen</i> Befehl um das Bit zu kippen.<br />
<br />
Kein Compiler benutzt das T-Flag. Es kann jedoch in der Laufzeitbibliothek Verwendung finden, solche Kode-Abschnitte sind handoptimierter Assembler. <tt>avr-gcc</tt> betrachtet das T-Flag als „flüchtig“ und darf in Unterprogrammen und Makros verändert werden.<br />
<br />
===Interrupt (I)===<br />
Das Interrupt-Flag fällt hier etwas aus dem Rahmen; es hat nichts mit Berechnungen zu tun, sondern steuert, ob Interrupts im Controller zugelassen sind (siehe [[AVR-Tutorial: Interrupts]]).<br />
<br />
==Vergleiche==<br />
Um einen Vergleich durchzuführen, wird intern eine Subtraktion der beiden Operanden vorgenommen. Das eigentliche Ergebnis der Subtraktion wird allerdings verworfen, es bleibt nur die neue Belegung der Flags übrig, die in weiterer Folge ausgewertet werden kann.<br />
<br />
===CP – Compare===<br />
Vergleicht den Inhalt zweier Register miteinander. Prozessorintern wird dabei eine Subtraktion der beiden Register durchgeführt. Das eigentliche Subtraktionsergebnis wird allerdings verworfen, das Subtraktionsergebnis beeinflusst lediglich die Flags.<br />
<br />
===CPC – Compare with Carry===<br />
Vergleicht den Inhalt zweier Register, wobei das Carry-Flag in den Vergleich mit einbezogen wird. Dieser Befehl wird für Arithmetik mit großen Variablen (16 oder 32 Bit) benötigt. Siehe [[AVR-Tutorial: Arithmetik]].<br />
<br />
===CPI – Compare Immediate===<br />
Vergleicht den Inhalt eines Registers mit einer direkt angegebenen Konstanten. Der Befehl ist nur auf die Register r16…r31 anwendbar.<br />
<br />
==Bedingte Sprünge==<br />
<br />
Die bedingten Sprünge werten immer bestimmte Flags im Statusregister (SREG) aus. Es spielt dabei keine Rolle, ob dies nach einem Vergleichsbefehl oder einem sonstigen Befehl gemacht wird. Entscheidend ist einzig und allein der Zustand des abgefragten Flags. Die Namen der Sprungbefehle wurden allerdings so gewählt, daß sich im Befehlsnamen die Beziehung der Operanden direkt nach einem Compare-Befehl widerspiegelt. Zu beachten ist auch, daß die Flags nicht nur durch Vergleichsbefehle verändert werden, sondern auch durch arithmetische Operationen, Schiebebefehle und [[Bitmanipulation|logische Verknüpfungen]]. Da diese Information wichtig ist, ist auch in der bei Atmel/Microchip erhältlichen [https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf Übersicht über alle Assemblerbefehle] bei jedem Befehl angegeben, ob und wie er Flags beeinflusst. Ebenso ist dort eine kompakte Übersicht aller bedingten Sprünge zu finden. Beachten muss man jedoch, dass die bedingten Sprünge maximal 64 Worte weit springen können.<br />
<br />
=== Bedingte Sprünge für vorzeichenlose Zahlen ===<br />
<br />
;BRSH – Branch if Same or Higher: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) nicht gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann statt, wenn der erste Operand größer oder gleich dem zweiten Operanden ist. BRSH ist identisch mit BRCC (Branch if Carry Cleared).<br />
<br />
;BRLO – Branch if Lower: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann statt, wenn der erste Operand kleiner dem zweiten Operanden ist. BRLO ist identisch mit BRCS (Branch if Carry Set).<br />
<br />
=== Bedingte Sprünge für vorzeichenbehaftete Zahlen ===<br />
<br />
;BRGE – Branch if Greater or Equal: Der Sprung wird durchgeführt, wenn das Signed-Flag (S) nicht gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann und nur dann statt, wenn der erste Operand größer oder gleich dem zweiten Operanden ist.<br />
<br />
;BRLT – Branch if Less Than: Der Sprung wird durchgeführt, wenn das Signed-Flag (S) gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann und nur dann statt, wenn der erste Operand kleiner als der zweite Operand ist.<br />
<br />
;BRMI – Branch if Minus: Der Sprung wird durchgeführt, wenn das Negativ-Flag (N) gesetzt ist, das Ergebnis der letzten Operation also negativ war.<br />
<br />
;BRPL – Branch if Plus: Der Sprung wird durchgeführt, wenn das Negativ-Flag (N) nicht gesetzt ist, das Ergebnis der letzten Operation also positiv war (einschließlich null).<br />
<br />
=== Sonstige bedingte Sprünge ===<br />
<br />
;BREQ – Branch if Equal: Der Sprung wird durchgeführt, wenn das Zero-Flag (Z) gesetzt ist. Ist nach einem Vergleich das Zero-Flag gesetzt, lieferte die interne Subtraktion also 0, so waren beide Operanden gleich.<br />
<br />
;BRNE – Branch if Not Equal: Der Sprung wird durchgeführt, wenn das Zero-Flag (Z) nicht gesetzt ist. Ist nach einem Vergleich das Zero-Flag nicht gesetzt, lieferte die interne Subtraktion also nicht 0, so waren beide Operanden verschieden.<br />
<br />
;BRCC – Branch if Carry Flag is Cleared: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) nicht gesetzt ist. Dieser Befehl wird oft für Arithmetik mit großen Variablen (16 oder 32&nbsp;Bit) bzw. im Zusammenhang mit Schiebeoperationen verwendet. BRCC ≡ BRSH<br />
<br />
;BRCS – Branch if Carry Flag is Set: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) gesetzt ist. Die Verwendung ist sehr ähnlich zu BRCC. BRCS ≡ BRLO<br />
<br />
=== Selten verwendete bedingte Sprünge ===<br />
<br />
;BRHC – Branch if Half Carry Flag is Cleared: Der Sprung wird durchgeführt, wenn das Half-Carry-Flag (H) nicht gesetzt ist.<br />
<br />
;BRHS – Branch if Half Carry Flag is Set: Der Sprung wird durchgeführt, wenn das Half-Carry-Flag (H) gesetzt ist.<br />
<br />
;BRID – Branch if Global Interrupt is Disabled: Der Sprung wird durchgeführt, wenn das Interrupt-Flag (I) nicht gesetzt ist.<br />
<br />
;BRIE – Branch if Global Interrupt is Enabled: Der Sprung wird durchgeführt, wenn das Interrupt-Flag (I) gesetzt ist.<br />
<br />
;BRTC – Branch if T Flag is Cleared: Der Sprung wird durchgeführt, wenn das T-Flag nicht gesetzt ist.<br />
<br />
;BRTS – Branch if T Flag is Set: Der Sprung wird durchgeführt, wenn das T-Flag gesetzt ist.<br />
<br />
;BRVC – Branch if Overflow Cleared: Der Sprung wird durchgeführt, wenn das Overflow-Flag (V) nicht gesetzt ist.<br />
<br />
;BRVS – Branch if Overflow Set: Der Sprung wird durchgeführt, wenn das Overflow-Flag (V) gesetzt ist.<br />
<br />
==Beispiele==<br />
<br />
=== Entscheidungen ===<br />
<br />
In jedem Programm kommt früher oder später das Problem, die Ausführung von Codeteilen von irgendwelchen Zahlenwerten, die sich in anderen Registern befinden, abhängig zu machen. Sieht beispielsweise die Aufgabe vor, daß Register r18 auf 0 gesetzt werden soll, falls im Register r17 der Zahlenwert 25 enthalten ist und in allen anderen Fällen soll r18 auf 123 gesetzt werden, dann lautet der Code:<br />
<br />
<syntaxhighlight lang="asm"><br />
cpi r17, 25 ; vergleiche r17 mit der Konstante 25<br />
brne nicht_gleich ; wenn nicht gleich, dann mach bei nicht_gleich weiter<br />
ldi r18, 0 ; hier stehen nun Anweisungen für den Fall,<br />
; dass R17 gleich 25 ist<br />
rjmp weiter ; meist will man den anderen Zweig nicht durchlaufen, darum der Sprung<br />
nicht_gleich:<br />
ldi r18, 123 ; hier stehen nun Anweisungen für den Fall,<br />
; dass R17 ungleich 25 ist<br />
weiter: ; hier geht das Programm weiter<br />
</syntaxhighlight><br />
<br />
In ähnlicher Weise können die anderen bedingten Sprungbefehle eingesetzt werden, um die üblicherweise vorkommenden Vergleiche auf Gleichheit, Ungleichheit, „größer als“, „kleiner als“ zu realisieren.<br />
<br />
===Schleifenkonstrukte===<br />
<br />
Ein immer wiederkehrendes Muster in der Programmierung ist eine '''Schleife'''. Die einfachste Form einer Schleife ist die ''Zählschleife''. Dabei wird ein Register von einem Startwert ausgehend eine gewisse Anzahl erhöht, bis ein Endwert erreicht wird.<br />
<br />
<syntaxhighlight lang="asm"><br />
ldi r17, 10 ; der Startwert sei in diesem Beispiel 10<br />
loop:<br />
; an dieser Stelle stehen die Befehle, welche innerhalb der Schleife<br />
; mehrfach ausgeführt werden sollen<br />
<br />
inc r17 ; erhöhe das Zählregister<br />
cpi r17, 134 ; mit dem Endwert vergleichen<br />
brne loop ; und wenn der Endwert noch nicht erreicht ist,<br />
; wird bei der Marke loop ein weiterer Schleifendurchlauf ausgeführt<br />
</syntaxhighlight><br />
<br />
Sehr oft ist es auch möglich, das Konstrukt umzukehren. Anstatt von einem Startwert aus zu inkrementieren genügt es, die Anzahl der gewünschten Schleifendurchläufe in ein Register zu laden und dieses Register zu dekrementieren. Dabei kann man von der Eigenschaft der Dekrementieranweisung Gebrauch machen, das Zero-Flag (Z) zu beeinflussen. Ist das Ergebnis des Dekrements gleich 0, so wird das Zero-Flag gesetzt, welches wiederum in der nachfolgenden BRNE-Anweisung für einen bedingten Sprung benutzt werden kann. Das vereinfacht die Schleife und spart eine Anweisung sowie einen Takt Ausführungszeit.<br />
<br />
<syntaxhighlight lang="asm"><br />
ldi r17, 124 ; Die Anzahl der Wiederholungen in ein Register laden<br />
loop:<br />
; an dieser Stelle stehen die Befehle, welche innerhalb der Schleife<br />
; mehrfach ausgeführt werden sollen<br />
<br />
dec r17 ; Schleifenzähler um 1 verringern, dabei wird das Zero-Flag beeinflusst<br />
brne loop ; wenn r17 noch nicht 0 geworden ist -> Schleife wiederholen<br />
</syntaxhighlight><br />
<br />
==Literatur==<br />
* [https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf AVR Instruction Set Manual]: Übersicht aller AVR-Befehle mit Angaben zur Beeinflussung der Statusbits<br />
<br />
----<br />
<br />
{{Navigation_zurückhochvor|<br />
zurücktext=Interrupts|<br />
zurücklink=AVR-Tutorial: Interrupts|<br />
hochtext=Inhaltsverzeichnis|<br />
hochlink=AVR-Tutorial|<br />
vortext=Mehrfachverzweigungen|<br />
vorlink=AVR-Tutorial: Mehrfachverzweigung}}<br />
<br />
[[Category:AVR-Tutorial|Vergleiche]]<br />
[[Category:AVR-Arithmetik]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR-Tutorial:_Vergleiche&diff=107250AVR-Tutorial: Vergleiche2025-01-27T13:03:32Z<p>Heha: /* Carry (C) */</p>
<hr />
<div>Vergleiche und Entscheidungen sind in jeder Programmiersprache ein zentrales Mittel, um den Programmfluss abhängig von Bedingungen zu kontrollieren. In einem [[AVR]] spielen dazu vier Komponenten zusammen:<br />
* Vergleichsbefehle,<br />
* die Flags im Statusregister,<br />
* bedingte Sprungbefehle,<br />
* andere Befehle, die die Flags im Statusregister beeinflussen, wie z.&nbsp;B. die meisten arithmetischen Funktionen.<br />
<br />
Der Zusammenhang ist dabei folgender: Die Vergleichsbefehle führen einen Vergleich durch, zum Beispiel zwischen zwei Registern oder zwischen einem Register und einer Konstanten. Das Ergebnis des Vergleiches wird in den Flags abgelegt. Die bedingten Sprungbefehle werten die Flags aus und führen bei einem positiven Ergebnis den Sprung aus. Besonders der erste Satzteil ist wichtig! Den bedingten Sprungbefehlen ist es nämlich völlig egal, ob die Flags über Vergleichsbefehle oder über sonstige Befehle gesetzt wurden. Die Sprungbefehle werten einfach nur die Flags aus, wie auch immer diese zu ihrem Zustand kommen.<br />
<br />
==Flags==<br />
<br />
Die Flags sind Bits im Statusregister '''SREG'''. Ihre Aufgabe ist es, das Auftreten bestimmter Ereignisse, die während Berechnungen eintreten können, festzuhalten.<br />
Speicherbefehle (LD, LDI, ST, MOV, …) haben auf dem AVR grundsätzlich keinen Einfluss auf das Statusregister. Will man den Inhalt eines Registers explizit testen (z.&nbsp;B. nach dem Laden aus dem SRAM), so kann man hierfür den TST-Befehl verwenden.<br />
<br />
<!--<br />
+---+---+---+---+---+---+---+---+<br />
| I | T | H | S | V | N | Z | C |<br />
+---+---+---+---+---+---+---+---+<br />
--><br />
<br />
<center><br />
{{Byte|Bits im SREG| I|T|H|S|V|N|Z|C}}<br />
</center><br />
<br />
===Carry (C)===<br />
Das Carry-Flag hält fest, ob es bei der letzten Berechnung einen Über- oder Unterlauf gab. Aber Achtung: Nicht alle arithmetischen Befehle verändern tatsächlich das Carry-Flag. So haben z.&nbsp;B. die Inkrementier- und Dekrementierbefehle keine Auswirkung auf dieses Flag.<br />
<br />
Weiterhin dient das C-Flag als „neuntes Bit“ für Schiebeoperationen und die Befehle <tt>adc</tt>, <tt>sbc</tt>, <tt>sbic</tt> und <tt>cpc</tt>.<br />
<br />
===Zero (Z)===<br />
Das Zero-Flag hält fest, ob das Ergebnis der letzten 8-Bit-Berechnung gleich 0 war oder nicht.<br />
<br />
<b>Achtung:</b> Einige AVR-Befehle „kaskadieren“ das Z-Flag: Arithmetische Operationen mit C-Flag als Input, vor allem <tt>cpc</tt> (compare with carry). Damit eignet es sich zur Nullfeststellung für beliebig breite Zahlen. IMHO keine weitere Prozessorarchitektur tut das.<br />
<br />
===Negative (N)===<br />
Spiegelt den Zustand des höchstwertigen Bits (Bit 7) der letzten 8-Bit-Berechnung wider. In Zweierkomplement-Arithmetik — Standard bei allen Compilern für Ganzzahlen — bedeutet ein gesetztes Bit 7 eine negative Zahl. Das Bit kann also dazu genutzt werden um festzustellen, ob das Ergebnis einer Berechnung im Sinne einer Zweierkomplement-Arithmetik positiv oder negativ ist.<br />
<br />
===Overflow (V)===<br />
Dieses Bit wird gesetzt, wenn bei einer Berechnung mit 2er-Komplement-Arithmetik ein Überlauf (Unterlauf) stattgefunden hat. Dies entspricht einem Überlauf von Bit 6 ins Bit 7.<br />
<br />
Der Übertrag, der bei der Addition/Subtraktion von Bit 6 auf Bit 7 auftritt, zeigt daher – wenn er vorhanden ist – an,<br />
dass es sich hier um einen Überlauf (Overflow) des Zahlenbereichs handelt und das Ergebnis falsch ist.<br />
Das ist allerdings nicht der Fall, wenn auch der Übertrag von Bit 7 nach Bit 8 (Carry) aufgetreten ist.<br />
Daher ist das Overflow-Flag die [[AVR-Tutorial: Logik#XOR (Exklusives Oder)|XOR-Verknüpfung]] aus dem Übertrag von Bit 6 nach Bit 7 und dem Carry.<br />
<br />
Beispiele für die Anwendung des V-Flags finden sich in [[AVR Arithmetik/Saturierung|saturierter Arithmetik]].<br />
<br />
===Signed (S)===<br />
Das Signed-Bit ergibt sich aus der Antivalenz (exklusives Oder) der Flags N und V, also S = N XOR V.<br />
Mit Hilfe des Signed-Flags können vorzeichenbehaftete Werte miteinander verglichen werden. Ist nach einem Vergleich zweier Register S=1, so ist der Wert des ersten Registers kleiner dem zweiten (in der Signed-Darstellung). Damit entspricht das Signed-Flag gewissermaßen dem Carry-Flag für Signed-Werte. Es wird hauptsächlich für „Signed“-Tests benötigt. Daher auch der Name.<br />
<br />
===Half Carry (H)===<br />
Das Half-Carry-Flag hat die gleiche Aufgabe wie das Carry Flag, nur beschäftigt es sich mit einem Überlauf von Bit 3 nach Bit 4, also dem Übertrag zwischen dem oberen und dem unteren Nibble. Wie beim Carry-Flag gilt, dass das Flag nicht durch Inkrementieren bzw. Dekrementieren ausgelöst werden kann.<br />
Das Haupteinsatzgebiet ist der Bereich der BCD-Arithmetik (binär codierte Dezimalzahlen), bei der jeweils 4 Bits eine Stelle einer Dezimalzahl repräsentieren.<br />
<br />
Kein Compiler benutzt das H-Flag. Findet man die Befehle <tt>brhc</tt>, <tt>brhs</tt>, <tt>clh</tt> oder <tt>seh</tt> in einem Disassemblerlisting, sind das entweder Daten oder es wurde in Assembler programmiert. Das H-Flag lässt sich bspw. dazu verwenden, zwei Zähler in einem Byte zu realisieren. So signalisiert das H-Flag in einem <u>Bit</u>zähler, wann das nächste <u>Byte</u> nachzuladen ist, indem man 2 addiert. Das reicht für 127 Bit.<br />
<br />
=== Transfer (T)===<br />
Das T-Flag ist kein Statusbit im eigentlichen Sinne. Es steht dem Programmierer als 1-Bit-Speicher zur Verfügung. Der Zugriff erfolgt über die Befehle Bit Load (BLD), Bit Store (BST), Set-T (SET) und Clear-T (CLT) und wird sonst von keinen anderen Befehlen beeinflusst. Damit können Bits von einer Stelle schnell an eine andere kopiert oder getestet werden. Es gibt <i>keinen</i> Befehl um das Bit zu kippen.<br />
<br />
Kein Compiler benutzt das T-Flag. Es kann jedoch in der Laufzeitbibliothek Verwendung finden, solche Kode-Abschnitte sind handoptimierter Assembler. <tt>avr-gcc</tt> betrachtet das T-Flag als „flüchtig“ und darf in Unterprogrammen und Makros verändert werden.<br />
<br />
===Interrupt (I)===<br />
Das Interrupt-Flag fällt hier etwas aus dem Rahmen; es hat nichts mit Berechnungen zu tun, sondern steuert, ob Interrupts im Controller zugelassen sind (siehe [[AVR-Tutorial: Interrupts]]).<br />
<br />
==Vergleiche==<br />
Um einen Vergleich durchzuführen, wird intern eine Subtraktion der beiden Operanden vorgenommen. Das eigentliche Ergebnis der Subtraktion wird allerdings verworfen, es bleibt nur die neue Belegung der Flags übrig, die in weiterer Folge ausgewertet werden kann.<br />
<br />
===CP – Compare===<br />
Vergleicht den Inhalt zweier Register miteinander. Prozessorintern wird dabei eine Subtraktion der beiden Register durchgeführt. Das eigentliche Subtraktionsergebnis wird allerdings verworfen, das Subtraktionsergebnis beeinflusst lediglich die Flags.<br />
<br />
===CPC – Compare with Carry===<br />
Vergleicht den Inhalt zweier Register, wobei das Carry-Flag in den Vergleich mit einbezogen wird. Dieser Befehl wird für Arithmetik mit großen Variablen (16 oder 32 Bit) benötigt. Siehe [[AVR-Tutorial: Arithmetik]].<br />
<br />
===CPI – Compare Immediate===<br />
Vergleicht den Inhalt eines Registers mit einer direkt angegebenen Konstanten. Der Befehl ist nur auf die Register r16…r31 anwendbar.<br />
<br />
==Bedingte Sprünge==<br />
<br />
Die bedingten Sprünge werten immer bestimmte Flags im Statusregister (SREG) aus. Es spielt dabei keine Rolle, ob dies nach einem Vergleichsbefehl oder einem sonstigen Befehl gemacht wird. Entscheidend ist einzig und allein der Zustand des abgefragten Flags. Die Namen der Sprungbefehle wurden allerdings so gewählt, daß sich im Befehlsnamen die Beziehung der Operanden direkt nach einem Compare-Befehl widerspiegelt. Zu beachten ist auch, daß die Flags nicht nur durch Vergleichsbefehle verändert werden, sondern auch durch arithmetische Operationen, Schiebebefehle und [[Bitmanipulation|logische Verknüpfungen]]. Da diese Information wichtig ist, ist auch in der bei Atmel/Microchip erhältlichen [https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf Übersicht über alle Assemblerbefehle] bei jedem Befehl angegeben, ob und wie er Flags beeinflusst. Ebenso ist dort eine kompakte Übersicht aller bedingten Sprünge zu finden. Beachten muss man jedoch, dass die bedingten Sprünge maximal 64 Worte weit springen können.<br />
<br />
=== Bedingte Sprünge für vorzeichenlose Zahlen ===<br />
<br />
;BRSH – Branch if Same or Higher: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) nicht gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann statt, wenn der erste Operand größer oder gleich dem zweiten Operanden ist. BRSH ist identisch mit BRCC (Branch if Carry Cleared).<br />
<br />
;BRLO – Branch if Lower: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann statt, wenn der erste Operand kleiner dem zweiten Operanden ist. BRLO ist identisch mit BRCS (Branch if Carry Set).<br />
<br />
=== Bedingte Sprünge für vorzeichenbehaftete Zahlen ===<br />
<br />
;BRGE – Branch if Greater or Equal: Der Sprung wird durchgeführt, wenn das Signed-Flag (S) nicht gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann und nur dann statt, wenn der erste Operand größer oder gleich dem zweiten Operanden ist.<br />
<br />
;BRLT – Branch if Less Than: Der Sprung wird durchgeführt, wenn das Signed-Flag (S) gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann und nur dann statt, wenn der erste Operand kleiner als der zweite Operand ist.<br />
<br />
;BRMI – Branch if Minus: Der Sprung wird durchgeführt, wenn das Negativ-Flag (N) gesetzt ist, das Ergebnis der letzten Operation also negativ war.<br />
<br />
;BRPL – Branch if Plus: Der Sprung wird durchgeführt, wenn das Negativ-Flag (N) nicht gesetzt ist, das Ergebnis der letzten Operation also positiv war (einschließlich null).<br />
<br />
=== Sonstige bedingte Sprünge ===<br />
<br />
;BREQ – Branch if Equal: Der Sprung wird durchgeführt, wenn das Zero-Flag (Z) gesetzt ist. Ist nach einem Vergleich das Zero-Flag gesetzt, lieferte die interne Subtraktion also 0, so waren beide Operanden gleich.<br />
<br />
;BRNE – Branch if Not Equal: Der Sprung wird durchgeführt, wenn das Zero-Flag (Z) nicht gesetzt ist. Ist nach einem Vergleich das Zero-Flag nicht gesetzt, lieferte die interne Subtraktion also nicht 0, so waren beide Operanden verschieden.<br />
<br />
;BRCC – Branch if Carry Flag is Cleared: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) nicht gesetzt ist. Dieser Befehl wird oft für Arithmetik mit großen Variablen (16 oder 32&nbsp;Bit) bzw. im Zusammenhang mit Schiebeoperationen verwendet. BRCC ≡ BRSH<br />
<br />
;BRCS – Branch if Carry Flag is Set: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) gesetzt ist. Die Verwendung ist sehr ähnlich zu BRCC. BRCS ≡ BRLO<br />
<br />
=== Selten verwendete bedingte Sprünge ===<br />
<br />
;BRHC – Branch if Half Carry Flag is Cleared: Der Sprung wird durchgeführt, wenn das Half-Carry-Flag (H) nicht gesetzt ist.<br />
<br />
;BRHS – Branch if Half Carry Flag is Set: Der Sprung wird durchgeführt, wenn das Half-Carry-Flag (H) gesetzt ist.<br />
<br />
;BRID – Branch if Global Interrupt is Disabled: Der Sprung wird durchgeführt, wenn das Interrupt-Flag (I) nicht gesetzt ist.<br />
<br />
;BRIE – Branch if Global Interrupt is Enabled: Der Sprung wird durchgeführt, wenn das Interrupt-Flag (I) gesetzt ist.<br />
<br />
;BRTC – Branch if T Flag is Cleared: Der Sprung wird durchgeführt, wenn das T-Flag nicht gesetzt ist.<br />
<br />
;BRTS – Branch if T Flag is Set: Der Sprung wird durchgeführt, wenn das T-Flag gesetzt ist.<br />
<br />
;BRVC – Branch if Overflow Cleared: Der Sprung wird durchgeführt, wenn das Overflow-Flag (V) nicht gesetzt ist.<br />
<br />
;BRVS – Branch if Overflow Set: Der Sprung wird durchgeführt, wenn das Overflow-Flag (V) gesetzt ist.<br />
<br />
==Beispiele==<br />
<br />
=== Entscheidungen ===<br />
<br />
In jedem Programm kommt früher oder später das Problem, die Ausführung von Codeteilen von irgendwelchen Zahlenwerten, die sich in anderen Registern befinden, abhängig zu machen. Sieht beispielsweise die Aufgabe vor, daß Register r18 auf 0 gesetzt werden soll, falls im Register r17 der Zahlenwert 25 enthalten ist und in allen anderen Fällen soll r18 auf 123 gesetzt werden, dann lautet der Code:<br />
<br />
<syntaxhighlight lang="asm"><br />
cpi r17, 25 ; vergleiche r17 mit der Konstante 25<br />
brne nicht_gleich ; wenn nicht gleich, dann mach bei nicht_gleich weiter<br />
ldi r18, 0 ; hier stehen nun Anweisungen für den Fall,<br />
; dass R17 gleich 25 ist<br />
rjmp weiter ; meist will man den anderen Zweig nicht durchlaufen, darum der Sprung<br />
nicht_gleich:<br />
ldi r18, 123 ; hier stehen nun Anweisungen für den Fall,<br />
; dass R17 ungleich 25 ist<br />
weiter: ; hier geht das Programm weiter<br />
</syntaxhighlight><br />
<br />
In ähnlicher Weise können die anderen bedingten Sprungbefehle eingesetzt werden, um die üblicherweise vorkommenden Vergleiche auf Gleichheit, Ungleichheit, „größer als“, „kleiner als“ zu realisieren.<br />
<br />
===Schleifenkonstrukte===<br />
<br />
Ein immer wiederkehrendes Muster in der Programmierung ist eine '''Schleife'''. Die einfachste Form einer Schleife ist die ''Zählschleife''. Dabei wird ein Register von einem Startwert ausgehend eine gewisse Anzahl erhöht, bis ein Endwert erreicht wird.<br />
<br />
<syntaxhighlight lang="asm"><br />
ldi r17, 10 ; der Startwert sei in diesem Beispiel 10<br />
loop:<br />
; an dieser Stelle stehen die Befehle, welche innerhalb der Schleife<br />
; mehrfach ausgeführt werden sollen<br />
<br />
inc r17 ; erhöhe das Zählregister<br />
cpi r17, 134 ; mit dem Endwert vergleichen<br />
brne loop ; und wenn der Endwert noch nicht erreicht ist,<br />
; wird bei der Marke loop ein weiterer Schleifendurchlauf ausgeführt<br />
</syntaxhighlight><br />
<br />
Sehr oft ist es auch möglich, das Konstrukt umzukehren. Anstatt von einem Startwert aus zu inkrementieren genügt es, die Anzahl der gewünschten Schleifendurchläufe in ein Register zu laden und dieses Register zu dekrementieren. Dabei kann man von der Eigenschaft der Dekrementieranweisung Gebrauch machen, das Zero-Flag (Z) zu beeinflussen. Ist das Ergebnis des Dekrements gleich 0, so wird das Zero-Flag gesetzt, welches wiederum in der nachfolgenden BRNE-Anweisung für einen bedingten Sprung benutzt werden kann. Das vereinfacht die Schleife und spart eine Anweisung sowie einen Takt Ausführungszeit.<br />
<br />
<syntaxhighlight lang="asm"><br />
ldi r17, 124 ; Die Anzahl der Wiederholungen in ein Register laden<br />
loop:<br />
; an dieser Stelle stehen die Befehle, welche innerhalb der Schleife<br />
; mehrfach ausgeführt werden sollen<br />
<br />
dec r17 ; Schleifenzähler um 1 verringern, dabei wird das Zero-Flag beeinflusst<br />
brne loop ; wenn r17 noch nicht 0 geworden ist -> Schleife wiederholen<br />
</syntaxhighlight><br />
<br />
==Literatur==<br />
* [https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf AVR Instruction Set Manual]: Übersicht aller AVR-Befehle mit Angaben zur Beeinflussung der Statusbits<br />
<br />
----<br />
<br />
{{Navigation_zurückhochvor|<br />
zurücktext=Interrupts|<br />
zurücklink=AVR-Tutorial: Interrupts|<br />
hochtext=Inhaltsverzeichnis|<br />
hochlink=AVR-Tutorial|<br />
vortext=Mehrfachverzweigungen|<br />
vorlink=AVR-Tutorial: Mehrfachverzweigung}}<br />
<br />
[[Category:AVR-Tutorial|Vergleiche]]<br />
[[Category:AVR-Arithmetik]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR-Tutorial:_Vergleiche&diff=107249AVR-Tutorial: Vergleiche2025-01-27T13:00:23Z<p>Heha: Kaskadiertes Z-Flag</p>
<hr />
<div>Vergleiche und Entscheidungen sind in jeder Programmiersprache ein zentrales Mittel, um den Programmfluss abhängig von Bedingungen zu kontrollieren. In einem [[AVR]] spielen dazu vier Komponenten zusammen:<br />
* Vergleichsbefehle,<br />
* die Flags im Statusregister,<br />
* bedingte Sprungbefehle,<br />
* andere Befehle, die die Flags im Statusregister beeinflussen, wie z.&nbsp;B. die meisten arithmetischen Funktionen.<br />
<br />
Der Zusammenhang ist dabei folgender: Die Vergleichsbefehle führen einen Vergleich durch, zum Beispiel zwischen zwei Registern oder zwischen einem Register und einer Konstanten. Das Ergebnis des Vergleiches wird in den Flags abgelegt. Die bedingten Sprungbefehle werten die Flags aus und führen bei einem positiven Ergebnis den Sprung aus. Besonders der erste Satzteil ist wichtig! Den bedingten Sprungbefehlen ist es nämlich völlig egal, ob die Flags über Vergleichsbefehle oder über sonstige Befehle gesetzt wurden. Die Sprungbefehle werten einfach nur die Flags aus, wie auch immer diese zu ihrem Zustand kommen.<br />
<br />
==Flags==<br />
<br />
Die Flags sind Bits im Statusregister '''SREG'''. Ihre Aufgabe ist es, das Auftreten bestimmter Ereignisse, die während Berechnungen eintreten können, festzuhalten.<br />
Speicherbefehle (LD, LDI, ST, MOV, …) haben auf dem AVR grundsätzlich keinen Einfluss auf das Statusregister. Will man den Inhalt eines Registers explizit testen (z.&nbsp;B. nach dem Laden aus dem SRAM), so kann man hierfür den TST-Befehl verwenden.<br />
<br />
<!--<br />
+---+---+---+---+---+---+---+---+<br />
| I | T | H | S | V | N | Z | C |<br />
+---+---+---+---+---+---+---+---+<br />
--><br />
<br />
<center><br />
{{Byte|Bits im SREG| I|T|H|S|V|N|Z|C}}<br />
</center><br />
<br />
===Carry (C)===<br />
Das Carry-Flag hält fest, ob es bei der letzten Berechnung einen Über- oder Unterlauf gab. Aber Achtung: Nicht alle arithmetischen Befehle verändern tatsächlich das Carry-Flag. So haben z.&nbsp;B. die Inkrementier- und Dekrementierbefehle keine Auswirkung auf dieses Flag.<br />
<br />
===Zero (Z)===<br />
Das Zero-Flag hält fest, ob das Ergebnis der letzten 8-Bit-Berechnung gleich 0 war oder nicht.<br />
<br />
<b>Achtung:</b> Einige AVR-Befehle „kaskadieren“ das Z-Flag: Arithmetische Operationen mit C-Flag als Input, vor allem <tt>cpc</tt> (compare with carry). Damit eignet es sich zur Nullfeststellung für beliebig breite Zahlen. IMHO keine weitere Prozessorarchitektur tut das.<br />
<br />
===Negative (N)===<br />
Spiegelt den Zustand des höchstwertigen Bits (Bit 7) der letzten 8-Bit-Berechnung wider. In Zweierkomplement-Arithmetik — Standard bei allen Compilern für Ganzzahlen — bedeutet ein gesetztes Bit 7 eine negative Zahl. Das Bit kann also dazu genutzt werden um festzustellen, ob das Ergebnis einer Berechnung im Sinne einer Zweierkomplement-Arithmetik positiv oder negativ ist.<br />
<br />
===Overflow (V)===<br />
Dieses Bit wird gesetzt, wenn bei einer Berechnung mit 2er-Komplement-Arithmetik ein Überlauf (Unterlauf) stattgefunden hat. Dies entspricht einem Überlauf von Bit 6 ins Bit 7.<br />
<br />
Der Übertrag, der bei der Addition/Subtraktion von Bit 6 auf Bit 7 auftritt, zeigt daher – wenn er vorhanden ist – an,<br />
dass es sich hier um einen Überlauf (Overflow) des Zahlenbereichs handelt und das Ergebnis falsch ist.<br />
Das ist allerdings nicht der Fall, wenn auch der Übertrag von Bit 7 nach Bit 8 (Carry) aufgetreten ist.<br />
Daher ist das Overflow-Flag die [[AVR-Tutorial: Logik#XOR (Exklusives Oder)|XOR-Verknüpfung]] aus dem Übertrag von Bit 6 nach Bit 7 und dem Carry.<br />
<br />
Beispiele für die Anwendung des V-Flags finden sich in [[AVR Arithmetik/Saturierung|saturierter Arithmetik]].<br />
<br />
===Signed (S)===<br />
Das Signed-Bit ergibt sich aus der Antivalenz (exklusives Oder) der Flags N und V, also S = N XOR V.<br />
Mit Hilfe des Signed-Flags können vorzeichenbehaftete Werte miteinander verglichen werden. Ist nach einem Vergleich zweier Register S=1, so ist der Wert des ersten Registers kleiner dem zweiten (in der Signed-Darstellung). Damit entspricht das Signed-Flag gewissermaßen dem Carry-Flag für Signed-Werte. Es wird hauptsächlich für „Signed“-Tests benötigt. Daher auch der Name.<br />
<br />
===Half Carry (H)===<br />
Das Half-Carry-Flag hat die gleiche Aufgabe wie das Carry Flag, nur beschäftigt es sich mit einem Überlauf von Bit 3 nach Bit 4, also dem Übertrag zwischen dem oberen und dem unteren Nibble. Wie beim Carry-Flag gilt, dass das Flag nicht durch Inkrementieren bzw. Dekrementieren ausgelöst werden kann.<br />
Das Haupteinsatzgebiet ist der Bereich der BCD-Arithmetik (binär codierte Dezimalzahlen), bei der jeweils 4 Bits eine Stelle einer Dezimalzahl repräsentieren.<br />
<br />
Kein Compiler benutzt das H-Flag. Findet man die Befehle <tt>brhc</tt>, <tt>brhs</tt>, <tt>clh</tt> oder <tt>seh</tt> in einem Disassemblerlisting, sind das entweder Daten oder es wurde in Assembler programmiert. Das H-Flag lässt sich bspw. dazu verwenden, zwei Zähler in einem Byte zu realisieren. So signalisiert das H-Flag in einem <u>Bit</u>zähler, wann das nächste <u>Byte</u> nachzuladen ist, indem man 2 addiert. Das reicht für 127 Bit.<br />
<br />
=== Transfer (T)===<br />
Das T-Flag ist kein Statusbit im eigentlichen Sinne. Es steht dem Programmierer als 1-Bit-Speicher zur Verfügung. Der Zugriff erfolgt über die Befehle Bit Load (BLD), Bit Store (BST), Set-T (SET) und Clear-T (CLT) und wird sonst von keinen anderen Befehlen beeinflusst. Damit können Bits von einer Stelle schnell an eine andere kopiert oder getestet werden. Es gibt <i>keinen</i> Befehl um das Bit zu kippen.<br />
<br />
Kein Compiler benutzt das T-Flag. Es kann jedoch in der Laufzeitbibliothek Verwendung finden, solche Kode-Abschnitte sind handoptimierter Assembler. <tt>avr-gcc</tt> betrachtet das T-Flag als „flüchtig“ und darf in Unterprogrammen und Makros verändert werden.<br />
<br />
===Interrupt (I)===<br />
Das Interrupt-Flag fällt hier etwas aus dem Rahmen; es hat nichts mit Berechnungen zu tun, sondern steuert, ob Interrupts im Controller zugelassen sind (siehe [[AVR-Tutorial: Interrupts]]).<br />
<br />
==Vergleiche==<br />
Um einen Vergleich durchzuführen, wird intern eine Subtraktion der beiden Operanden vorgenommen. Das eigentliche Ergebnis der Subtraktion wird allerdings verworfen, es bleibt nur die neue Belegung der Flags übrig, die in weiterer Folge ausgewertet werden kann.<br />
<br />
===CP – Compare===<br />
Vergleicht den Inhalt zweier Register miteinander. Prozessorintern wird dabei eine Subtraktion der beiden Register durchgeführt. Das eigentliche Subtraktionsergebnis wird allerdings verworfen, das Subtraktionsergebnis beeinflusst lediglich die Flags.<br />
<br />
===CPC – Compare with Carry===<br />
Vergleicht den Inhalt zweier Register, wobei das Carry-Flag in den Vergleich mit einbezogen wird. Dieser Befehl wird für Arithmetik mit großen Variablen (16 oder 32 Bit) benötigt. Siehe [[AVR-Tutorial: Arithmetik]].<br />
<br />
===CPI – Compare Immediate===<br />
Vergleicht den Inhalt eines Registers mit einer direkt angegebenen Konstanten. Der Befehl ist nur auf die Register r16…r31 anwendbar.<br />
<br />
==Bedingte Sprünge==<br />
<br />
Die bedingten Sprünge werten immer bestimmte Flags im Statusregister (SREG) aus. Es spielt dabei keine Rolle, ob dies nach einem Vergleichsbefehl oder einem sonstigen Befehl gemacht wird. Entscheidend ist einzig und allein der Zustand des abgefragten Flags. Die Namen der Sprungbefehle wurden allerdings so gewählt, daß sich im Befehlsnamen die Beziehung der Operanden direkt nach einem Compare-Befehl widerspiegelt. Zu beachten ist auch, daß die Flags nicht nur durch Vergleichsbefehle verändert werden, sondern auch durch arithmetische Operationen, Schiebebefehle und [[Bitmanipulation|logische Verknüpfungen]]. Da diese Information wichtig ist, ist auch in der bei Atmel/Microchip erhältlichen [https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf Übersicht über alle Assemblerbefehle] bei jedem Befehl angegeben, ob und wie er Flags beeinflusst. Ebenso ist dort eine kompakte Übersicht aller bedingten Sprünge zu finden. Beachten muss man jedoch, dass die bedingten Sprünge maximal 64 Worte weit springen können.<br />
<br />
=== Bedingte Sprünge für vorzeichenlose Zahlen ===<br />
<br />
;BRSH – Branch if Same or Higher: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) nicht gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann statt, wenn der erste Operand größer oder gleich dem zweiten Operanden ist. BRSH ist identisch mit BRCC (Branch if Carry Cleared).<br />
<br />
;BRLO – Branch if Lower: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann statt, wenn der erste Operand kleiner dem zweiten Operanden ist. BRLO ist identisch mit BRCS (Branch if Carry Set).<br />
<br />
=== Bedingte Sprünge für vorzeichenbehaftete Zahlen ===<br />
<br />
;BRGE – Branch if Greater or Equal: Der Sprung wird durchgeführt, wenn das Signed-Flag (S) nicht gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann und nur dann statt, wenn der erste Operand größer oder gleich dem zweiten Operanden ist.<br />
<br />
;BRLT – Branch if Less Than: Der Sprung wird durchgeführt, wenn das Signed-Flag (S) gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann und nur dann statt, wenn der erste Operand kleiner als der zweite Operand ist.<br />
<br />
;BRMI – Branch if Minus: Der Sprung wird durchgeführt, wenn das Negativ-Flag (N) gesetzt ist, das Ergebnis der letzten Operation also negativ war.<br />
<br />
;BRPL – Branch if Plus: Der Sprung wird durchgeführt, wenn das Negativ-Flag (N) nicht gesetzt ist, das Ergebnis der letzten Operation also positiv war (einschließlich null).<br />
<br />
=== Sonstige bedingte Sprünge ===<br />
<br />
;BREQ – Branch if Equal: Der Sprung wird durchgeführt, wenn das Zero-Flag (Z) gesetzt ist. Ist nach einem Vergleich das Zero-Flag gesetzt, lieferte die interne Subtraktion also 0, so waren beide Operanden gleich.<br />
<br />
;BRNE – Branch if Not Equal: Der Sprung wird durchgeführt, wenn das Zero-Flag (Z) nicht gesetzt ist. Ist nach einem Vergleich das Zero-Flag nicht gesetzt, lieferte die interne Subtraktion also nicht 0, so waren beide Operanden verschieden.<br />
<br />
;BRCC – Branch if Carry Flag is Cleared: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) nicht gesetzt ist. Dieser Befehl wird oft für Arithmetik mit großen Variablen (16 oder 32&nbsp;Bit) bzw. im Zusammenhang mit Schiebeoperationen verwendet. BRCC ≡ BRSH<br />
<br />
;BRCS – Branch if Carry Flag is Set: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) gesetzt ist. Die Verwendung ist sehr ähnlich zu BRCC. BRCS ≡ BRLO<br />
<br />
=== Selten verwendete bedingte Sprünge ===<br />
<br />
;BRHC – Branch if Half Carry Flag is Cleared: Der Sprung wird durchgeführt, wenn das Half-Carry-Flag (H) nicht gesetzt ist.<br />
<br />
;BRHS – Branch if Half Carry Flag is Set: Der Sprung wird durchgeführt, wenn das Half-Carry-Flag (H) gesetzt ist.<br />
<br />
;BRID – Branch if Global Interrupt is Disabled: Der Sprung wird durchgeführt, wenn das Interrupt-Flag (I) nicht gesetzt ist.<br />
<br />
;BRIE – Branch if Global Interrupt is Enabled: Der Sprung wird durchgeführt, wenn das Interrupt-Flag (I) gesetzt ist.<br />
<br />
;BRTC – Branch if T Flag is Cleared: Der Sprung wird durchgeführt, wenn das T-Flag nicht gesetzt ist.<br />
<br />
;BRTS – Branch if T Flag is Set: Der Sprung wird durchgeführt, wenn das T-Flag gesetzt ist.<br />
<br />
;BRVC – Branch if Overflow Cleared: Der Sprung wird durchgeführt, wenn das Overflow-Flag (V) nicht gesetzt ist.<br />
<br />
;BRVS – Branch if Overflow Set: Der Sprung wird durchgeführt, wenn das Overflow-Flag (V) gesetzt ist.<br />
<br />
==Beispiele==<br />
<br />
=== Entscheidungen ===<br />
<br />
In jedem Programm kommt früher oder später das Problem, die Ausführung von Codeteilen von irgendwelchen Zahlenwerten, die sich in anderen Registern befinden, abhängig zu machen. Sieht beispielsweise die Aufgabe vor, daß Register r18 auf 0 gesetzt werden soll, falls im Register r17 der Zahlenwert 25 enthalten ist und in allen anderen Fällen soll r18 auf 123 gesetzt werden, dann lautet der Code:<br />
<br />
<syntaxhighlight lang="asm"><br />
cpi r17, 25 ; vergleiche r17 mit der Konstante 25<br />
brne nicht_gleich ; wenn nicht gleich, dann mach bei nicht_gleich weiter<br />
ldi r18, 0 ; hier stehen nun Anweisungen für den Fall,<br />
; dass R17 gleich 25 ist<br />
rjmp weiter ; meist will man den anderen Zweig nicht durchlaufen, darum der Sprung<br />
nicht_gleich:<br />
ldi r18, 123 ; hier stehen nun Anweisungen für den Fall,<br />
; dass R17 ungleich 25 ist<br />
weiter: ; hier geht das Programm weiter<br />
</syntaxhighlight><br />
<br />
In ähnlicher Weise können die anderen bedingten Sprungbefehle eingesetzt werden, um die üblicherweise vorkommenden Vergleiche auf Gleichheit, Ungleichheit, „größer als“, „kleiner als“ zu realisieren.<br />
<br />
===Schleifenkonstrukte===<br />
<br />
Ein immer wiederkehrendes Muster in der Programmierung ist eine '''Schleife'''. Die einfachste Form einer Schleife ist die ''Zählschleife''. Dabei wird ein Register von einem Startwert ausgehend eine gewisse Anzahl erhöht, bis ein Endwert erreicht wird.<br />
<br />
<syntaxhighlight lang="asm"><br />
ldi r17, 10 ; der Startwert sei in diesem Beispiel 10<br />
loop:<br />
; an dieser Stelle stehen die Befehle, welche innerhalb der Schleife<br />
; mehrfach ausgeführt werden sollen<br />
<br />
inc r17 ; erhöhe das Zählregister<br />
cpi r17, 134 ; mit dem Endwert vergleichen<br />
brne loop ; und wenn der Endwert noch nicht erreicht ist,<br />
; wird bei der Marke loop ein weiterer Schleifendurchlauf ausgeführt<br />
</syntaxhighlight><br />
<br />
Sehr oft ist es auch möglich, das Konstrukt umzukehren. Anstatt von einem Startwert aus zu inkrementieren genügt es, die Anzahl der gewünschten Schleifendurchläufe in ein Register zu laden und dieses Register zu dekrementieren. Dabei kann man von der Eigenschaft der Dekrementieranweisung Gebrauch machen, das Zero-Flag (Z) zu beeinflussen. Ist das Ergebnis des Dekrements gleich 0, so wird das Zero-Flag gesetzt, welches wiederum in der nachfolgenden BRNE-Anweisung für einen bedingten Sprung benutzt werden kann. Das vereinfacht die Schleife und spart eine Anweisung sowie einen Takt Ausführungszeit.<br />
<br />
<syntaxhighlight lang="asm"><br />
ldi r17, 124 ; Die Anzahl der Wiederholungen in ein Register laden<br />
loop:<br />
; an dieser Stelle stehen die Befehle, welche innerhalb der Schleife<br />
; mehrfach ausgeführt werden sollen<br />
<br />
dec r17 ; Schleifenzähler um 1 verringern, dabei wird das Zero-Flag beeinflusst<br />
brne loop ; wenn r17 noch nicht 0 geworden ist -> Schleife wiederholen<br />
</syntaxhighlight><br />
<br />
==Literatur==<br />
* [https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf AVR Instruction Set Manual]: Übersicht aller AVR-Befehle mit Angaben zur Beeinflussung der Statusbits<br />
<br />
----<br />
<br />
{{Navigation_zurückhochvor|<br />
zurücktext=Interrupts|<br />
zurücklink=AVR-Tutorial: Interrupts|<br />
hochtext=Inhaltsverzeichnis|<br />
hochlink=AVR-Tutorial|<br />
vortext=Mehrfachverzweigungen|<br />
vorlink=AVR-Tutorial: Mehrfachverzweigung}}<br />
<br />
[[Category:AVR-Tutorial|Vergleiche]]<br />
[[Category:AVR-Arithmetik]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR-Tutorial:_Vergleiche&diff=107248AVR-Tutorial: Vergleiche2025-01-27T12:54:06Z<p>Heha: Negative (N)</p>
<hr />
<div>Vergleiche und Entscheidungen sind in jeder Programmiersprache ein zentrales Mittel, um den Programmfluss abhängig von Bedingungen zu kontrollieren. In einem [[AVR]] spielen dazu vier Komponenten zusammen:<br />
* Vergleichsbefehle,<br />
* die Flags im Statusregister,<br />
* bedingte Sprungbefehle,<br />
* andere Befehle, die die Flags im Statusregister beeinflussen, wie z.&nbsp;B. die meisten arithmetischen Funktionen.<br />
<br />
Der Zusammenhang ist dabei folgender: Die Vergleichsbefehle führen einen Vergleich durch, zum Beispiel zwischen zwei Registern oder zwischen einem Register und einer Konstanten. Das Ergebnis des Vergleiches wird in den Flags abgelegt. Die bedingten Sprungbefehle werten die Flags aus und führen bei einem positiven Ergebnis den Sprung aus. Besonders der erste Satzteil ist wichtig! Den bedingten Sprungbefehlen ist es nämlich völlig egal, ob die Flags über Vergleichsbefehle oder über sonstige Befehle gesetzt wurden. Die Sprungbefehle werten einfach nur die Flags aus, wie auch immer diese zu ihrem Zustand kommen.<br />
<br />
==Flags==<br />
<br />
Die Flags sind Bits im Statusregister '''SREG'''. Ihre Aufgabe ist es, das Auftreten bestimmter Ereignisse, die während Berechnungen eintreten können, festzuhalten.<br />
Speicherbefehle (LD, LDI, ST, MOV, …) haben auf dem AVR grundsätzlich keinen Einfluss auf das Statusregister. Will man den Inhalt eines Registers explizit testen (z.&nbsp;B. nach dem Laden aus dem SRAM), so kann man hierfür den TST-Befehl verwenden.<br />
<br />
<!--<br />
+---+---+---+---+---+---+---+---+<br />
| I | T | H | S | V | N | Z | C |<br />
+---+---+---+---+---+---+---+---+<br />
--><br />
<br />
<center><br />
{{Byte|Bits im SREG| I|T|H|S|V|N|Z|C}}<br />
</center><br />
<br />
===Carry (C)===<br />
Das Carry-Flag hält fest, ob es bei der letzten Berechnung einen Über- oder Unterlauf gab. Aber Achtung: Nicht alle arithmetischen Befehle verändern tatsächlich das Carry-Flag. So haben z.&nbsp;B. die Inkrementier- und Dekrementierbefehle keine Auswirkung auf dieses Flag.<br />
<br />
===Zero (Z)===<br />
Das Zero-Flag hält fest, ob das Ergebnis der letzten 8-Bit-Berechnung gleich 0 war oder nicht.<br />
<br />
===Negative (N)===<br />
Spiegelt den Zustand des höchstwertigen Bits (Bit 7) der letzten 8-Bit-Berechnung wider. In Zweierkomplement-Arithmetik — Standard bei allen Compilern für Ganzzahlen — bedeutet ein gesetztes Bit 7 eine negative Zahl. Das Bit kann also dazu genutzt werden um festzustellen, ob das Ergebnis einer Berechnung im Sinne einer Zweierkomplement-Arithmetik positiv oder negativ ist.<br />
<br />
===Overflow (V)===<br />
Dieses Bit wird gesetzt, wenn bei einer Berechnung mit 2er-Komplement-Arithmetik ein Überlauf (Unterlauf) stattgefunden hat. Dies entspricht einem Überlauf von Bit 6 ins Bit 7.<br />
<br />
Der Übertrag, der bei der Addition/Subtraktion von Bit 6 auf Bit 7 auftritt, zeigt daher – wenn er vorhanden ist – an,<br />
dass es sich hier um einen Überlauf (Overflow) des Zahlenbereichs handelt und das Ergebnis falsch ist.<br />
Das ist allerdings nicht der Fall, wenn auch der Übertrag von Bit 7 nach Bit 8 (Carry) aufgetreten ist.<br />
Daher ist das Overflow-Flag die [[AVR-Tutorial: Logik#XOR (Exklusives Oder)|XOR-Verknüpfung]] aus dem Übertrag von Bit 6 nach Bit 7 und dem Carry.<br />
<br />
Beispiele für die Anwendung des V-Flags finden sich in [[AVR Arithmetik/Saturierung|saturierter Arithmetik]].<br />
<br />
===Signed (S)===<br />
Das Signed-Bit ergibt sich aus der Antivalenz (exklusives Oder) der Flags N und V, also S = N XOR V.<br />
Mit Hilfe des Signed-Flags können vorzeichenbehaftete Werte miteinander verglichen werden. Ist nach einem Vergleich zweier Register S=1, so ist der Wert des ersten Registers kleiner dem zweiten (in der Signed-Darstellung). Damit entspricht das Signed-Flag gewissermaßen dem Carry-Flag für Signed-Werte. Es wird hauptsächlich für „Signed“-Tests benötigt. Daher auch der Name.<br />
<br />
===Half Carry (H)===<br />
Das Half-Carry-Flag hat die gleiche Aufgabe wie das Carry Flag, nur beschäftigt es sich mit einem Überlauf von Bit 3 nach Bit 4, also dem Übertrag zwischen dem oberen und dem unteren Nibble. Wie beim Carry-Flag gilt, dass das Flag nicht durch Inkrementieren bzw. Dekrementieren ausgelöst werden kann.<br />
Das Haupteinsatzgebiet ist der Bereich der BCD-Arithmetik (binär codierte Dezimalzahlen), bei der jeweils 4 Bits eine Stelle einer Dezimalzahl repräsentieren.<br />
<br />
Kein Compiler benutzt das H-Flag. Findet man die Befehle <tt>brhc</tt>, <tt>brhs</tt>, <tt>clh</tt> oder <tt>seh</tt> in einem Disassemblerlisting, sind das entweder Daten oder es wurde in Assembler programmiert. Das H-Flag lässt sich bspw. dazu verwenden, zwei Zähler in einem Byte zu realisieren. So signalisiert das H-Flag in einem <u>Bit</u>zähler, wann das nächste <u>Byte</u> nachzuladen ist, indem man 2 addiert. Das reicht für 127 Bit.<br />
<br />
=== Transfer (T)===<br />
Das T-Flag ist kein Statusbit im eigentlichen Sinne. Es steht dem Programmierer als 1-Bit-Speicher zur Verfügung. Der Zugriff erfolgt über die Befehle Bit Load (BLD), Bit Store (BST), Set-T (SET) und Clear-T (CLT) und wird sonst von keinen anderen Befehlen beeinflusst. Damit können Bits von einer Stelle schnell an eine andere kopiert oder getestet werden. Es gibt <i>keinen</i> Befehl um das Bit zu kippen.<br />
<br />
Kein Compiler benutzt das T-Flag. Es kann jedoch in der Laufzeitbibliothek Verwendung finden, solche Kode-Abschnitte sind handoptimierter Assembler. <tt>avr-gcc</tt> betrachtet das T-Flag als „flüchtig“ und darf in Unterprogrammen und Makros verändert werden.<br />
<br />
===Interrupt (I)===<br />
Das Interrupt-Flag fällt hier etwas aus dem Rahmen; es hat nichts mit Berechnungen zu tun, sondern steuert, ob Interrupts im Controller zugelassen sind (siehe [[AVR-Tutorial: Interrupts]]).<br />
<br />
==Vergleiche==<br />
Um einen Vergleich durchzuführen, wird intern eine Subtraktion der beiden Operanden vorgenommen. Das eigentliche Ergebnis der Subtraktion wird allerdings verworfen, es bleibt nur die neue Belegung der Flags übrig, die in weiterer Folge ausgewertet werden kann.<br />
<br />
===CP – Compare===<br />
Vergleicht den Inhalt zweier Register miteinander. Prozessorintern wird dabei eine Subtraktion der beiden Register durchgeführt. Das eigentliche Subtraktionsergebnis wird allerdings verworfen, das Subtraktionsergebnis beeinflusst lediglich die Flags.<br />
<br />
===CPC – Compare with Carry===<br />
Vergleicht den Inhalt zweier Register, wobei das Carry-Flag in den Vergleich mit einbezogen wird. Dieser Befehl wird für Arithmetik mit großen Variablen (16 oder 32 Bit) benötigt. Siehe [[AVR-Tutorial: Arithmetik]].<br />
<br />
===CPI – Compare Immediate===<br />
Vergleicht den Inhalt eines Registers mit einer direkt angegebenen Konstanten. Der Befehl ist nur auf die Register r16…r31 anwendbar.<br />
<br />
==Bedingte Sprünge==<br />
<br />
Die bedingten Sprünge werten immer bestimmte Flags im Statusregister (SREG) aus. Es spielt dabei keine Rolle, ob dies nach einem Vergleichsbefehl oder einem sonstigen Befehl gemacht wird. Entscheidend ist einzig und allein der Zustand des abgefragten Flags. Die Namen der Sprungbefehle wurden allerdings so gewählt, daß sich im Befehlsnamen die Beziehung der Operanden direkt nach einem Compare-Befehl widerspiegelt. Zu beachten ist auch, daß die Flags nicht nur durch Vergleichsbefehle verändert werden, sondern auch durch arithmetische Operationen, Schiebebefehle und [[Bitmanipulation|logische Verknüpfungen]]. Da diese Information wichtig ist, ist auch in der bei Atmel/Microchip erhältlichen [https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf Übersicht über alle Assemblerbefehle] bei jedem Befehl angegeben, ob und wie er Flags beeinflusst. Ebenso ist dort eine kompakte Übersicht aller bedingten Sprünge zu finden. Beachten muss man jedoch, dass die bedingten Sprünge maximal 64 Worte weit springen können.<br />
<br />
=== Bedingte Sprünge für vorzeichenlose Zahlen ===<br />
<br />
;BRSH – Branch if Same or Higher: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) nicht gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann statt, wenn der erste Operand größer oder gleich dem zweiten Operanden ist. BRSH ist identisch mit BRCC (Branch if Carry Cleared).<br />
<br />
;BRLO – Branch if Lower: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann statt, wenn der erste Operand kleiner dem zweiten Operanden ist. BRLO ist identisch mit BRCS (Branch if Carry Set).<br />
<br />
=== Bedingte Sprünge für vorzeichenbehaftete Zahlen ===<br />
<br />
;BRGE – Branch if Greater or Equal: Der Sprung wird durchgeführt, wenn das Signed-Flag (S) nicht gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann und nur dann statt, wenn der erste Operand größer oder gleich dem zweiten Operanden ist.<br />
<br />
;BRLT – Branch if Less Than: Der Sprung wird durchgeführt, wenn das Signed-Flag (S) gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann und nur dann statt, wenn der erste Operand kleiner als der zweite Operand ist.<br />
<br />
;BRMI – Branch if Minus: Der Sprung wird durchgeführt, wenn das Negativ-Flag (N) gesetzt ist, das Ergebnis der letzten Operation also negativ war.<br />
<br />
;BRPL – Branch if Plus: Der Sprung wird durchgeführt, wenn das Negativ-Flag (N) nicht gesetzt ist, das Ergebnis der letzten Operation also positiv war (einschließlich null).<br />
<br />
=== Sonstige bedingte Sprünge ===<br />
<br />
;BREQ – Branch if Equal: Der Sprung wird durchgeführt, wenn das Zero-Flag (Z) gesetzt ist. Ist nach einem Vergleich das Zero-Flag gesetzt, lieferte die interne Subtraktion also 0, so waren beide Operanden gleich.<br />
<br />
;BRNE – Branch if Not Equal: Der Sprung wird durchgeführt, wenn das Zero-Flag (Z) nicht gesetzt ist. Ist nach einem Vergleich das Zero-Flag nicht gesetzt, lieferte die interne Subtraktion also nicht 0, so waren beide Operanden verschieden.<br />
<br />
;BRCC – Branch if Carry Flag is Cleared: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) nicht gesetzt ist. Dieser Befehl wird oft für Arithmetik mit großen Variablen (16 oder 32&nbsp;Bit) bzw. im Zusammenhang mit Schiebeoperationen verwendet. BRCC ≡ BRSH<br />
<br />
;BRCS – Branch if Carry Flag is Set: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) gesetzt ist. Die Verwendung ist sehr ähnlich zu BRCC. BRCS ≡ BRLO<br />
<br />
=== Selten verwendete bedingte Sprünge ===<br />
<br />
;BRHC – Branch if Half Carry Flag is Cleared: Der Sprung wird durchgeführt, wenn das Half-Carry-Flag (H) nicht gesetzt ist.<br />
<br />
;BRHS – Branch if Half Carry Flag is Set: Der Sprung wird durchgeführt, wenn das Half-Carry-Flag (H) gesetzt ist.<br />
<br />
;BRID – Branch if Global Interrupt is Disabled: Der Sprung wird durchgeführt, wenn das Interrupt-Flag (I) nicht gesetzt ist.<br />
<br />
;BRIE – Branch if Global Interrupt is Enabled: Der Sprung wird durchgeführt, wenn das Interrupt-Flag (I) gesetzt ist.<br />
<br />
;BRTC – Branch if T Flag is Cleared: Der Sprung wird durchgeführt, wenn das T-Flag nicht gesetzt ist.<br />
<br />
;BRTS – Branch if T Flag is Set: Der Sprung wird durchgeführt, wenn das T-Flag gesetzt ist.<br />
<br />
;BRVC – Branch if Overflow Cleared: Der Sprung wird durchgeführt, wenn das Overflow-Flag (V) nicht gesetzt ist.<br />
<br />
;BRVS – Branch if Overflow Set: Der Sprung wird durchgeführt, wenn das Overflow-Flag (V) gesetzt ist.<br />
<br />
==Beispiele==<br />
<br />
=== Entscheidungen ===<br />
<br />
In jedem Programm kommt früher oder später das Problem, die Ausführung von Codeteilen von irgendwelchen Zahlenwerten, die sich in anderen Registern befinden, abhängig zu machen. Sieht beispielsweise die Aufgabe vor, daß Register r18 auf 0 gesetzt werden soll, falls im Register r17 der Zahlenwert 25 enthalten ist und in allen anderen Fällen soll r18 auf 123 gesetzt werden, dann lautet der Code:<br />
<br />
<syntaxhighlight lang="asm"><br />
cpi r17, 25 ; vergleiche r17 mit der Konstante 25<br />
brne nicht_gleich ; wenn nicht gleich, dann mach bei nicht_gleich weiter<br />
ldi r18, 0 ; hier stehen nun Anweisungen für den Fall,<br />
; dass R17 gleich 25 ist<br />
rjmp weiter ; meist will man den anderen Zweig nicht durchlaufen, darum der Sprung<br />
nicht_gleich:<br />
ldi r18, 123 ; hier stehen nun Anweisungen für den Fall,<br />
; dass R17 ungleich 25 ist<br />
weiter: ; hier geht das Programm weiter<br />
</syntaxhighlight><br />
<br />
In ähnlicher Weise können die anderen bedingten Sprungbefehle eingesetzt werden, um die üblicherweise vorkommenden Vergleiche auf Gleichheit, Ungleichheit, „größer als“, „kleiner als“ zu realisieren.<br />
<br />
===Schleifenkonstrukte===<br />
<br />
Ein immer wiederkehrendes Muster in der Programmierung ist eine '''Schleife'''. Die einfachste Form einer Schleife ist die ''Zählschleife''. Dabei wird ein Register von einem Startwert ausgehend eine gewisse Anzahl erhöht, bis ein Endwert erreicht wird.<br />
<br />
<syntaxhighlight lang="asm"><br />
ldi r17, 10 ; der Startwert sei in diesem Beispiel 10<br />
loop:<br />
; an dieser Stelle stehen die Befehle, welche innerhalb der Schleife<br />
; mehrfach ausgeführt werden sollen<br />
<br />
inc r17 ; erhöhe das Zählregister<br />
cpi r17, 134 ; mit dem Endwert vergleichen<br />
brne loop ; und wenn der Endwert noch nicht erreicht ist,<br />
; wird bei der Marke loop ein weiterer Schleifendurchlauf ausgeführt<br />
</syntaxhighlight><br />
<br />
Sehr oft ist es auch möglich, das Konstrukt umzukehren. Anstatt von einem Startwert aus zu inkrementieren genügt es, die Anzahl der gewünschten Schleifendurchläufe in ein Register zu laden und dieses Register zu dekrementieren. Dabei kann man von der Eigenschaft der Dekrementieranweisung Gebrauch machen, das Zero-Flag (Z) zu beeinflussen. Ist das Ergebnis des Dekrements gleich 0, so wird das Zero-Flag gesetzt, welches wiederum in der nachfolgenden BRNE-Anweisung für einen bedingten Sprung benutzt werden kann. Das vereinfacht die Schleife und spart eine Anweisung sowie einen Takt Ausführungszeit.<br />
<br />
<syntaxhighlight lang="asm"><br />
ldi r17, 124 ; Die Anzahl der Wiederholungen in ein Register laden<br />
loop:<br />
; an dieser Stelle stehen die Befehle, welche innerhalb der Schleife<br />
; mehrfach ausgeführt werden sollen<br />
<br />
dec r17 ; Schleifenzähler um 1 verringern, dabei wird das Zero-Flag beeinflusst<br />
brne loop ; wenn r17 noch nicht 0 geworden ist -> Schleife wiederholen<br />
</syntaxhighlight><br />
<br />
==Literatur==<br />
* [https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf AVR Instruction Set Manual]: Übersicht aller AVR-Befehle mit Angaben zur Beeinflussung der Statusbits<br />
<br />
----<br />
<br />
{{Navigation_zurückhochvor|<br />
zurücktext=Interrupts|<br />
zurücklink=AVR-Tutorial: Interrupts|<br />
hochtext=Inhaltsverzeichnis|<br />
hochlink=AVR-Tutorial|<br />
vortext=Mehrfachverzweigungen|<br />
vorlink=AVR-Tutorial: Mehrfachverzweigung}}<br />
<br />
[[Category:AVR-Tutorial|Vergleiche]]<br />
[[Category:AVR-Arithmetik]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR-Tutorial:_Vergleiche&diff=107247AVR-Tutorial: Vergleiche2025-01-27T12:50:13Z<p>Heha: Bit Transfer (T)</p>
<hr />
<div>Vergleiche und Entscheidungen sind in jeder Programmiersprache ein zentrales Mittel, um den Programmfluss abhängig von Bedingungen zu kontrollieren. In einem [[AVR]] spielen dazu vier Komponenten zusammen:<br />
* Vergleichsbefehle,<br />
* die Flags im Statusregister,<br />
* bedingte Sprungbefehle,<br />
* andere Befehle, die die Flags im Statusregister beeinflussen, wie z.&nbsp;B. die meisten arithmetischen Funktionen.<br />
<br />
Der Zusammenhang ist dabei folgender: Die Vergleichsbefehle führen einen Vergleich durch, zum Beispiel zwischen zwei Registern oder zwischen einem Register und einer Konstanten. Das Ergebnis des Vergleiches wird in den Flags abgelegt. Die bedingten Sprungbefehle werten die Flags aus und führen bei einem positiven Ergebnis den Sprung aus. Besonders der erste Satzteil ist wichtig! Den bedingten Sprungbefehlen ist es nämlich völlig egal, ob die Flags über Vergleichsbefehle oder über sonstige Befehle gesetzt wurden. Die Sprungbefehle werten einfach nur die Flags aus, wie auch immer diese zu ihrem Zustand kommen.<br />
<br />
==Flags==<br />
<br />
Die Flags sind Bits im Statusregister '''SREG'''. Ihre Aufgabe ist es, das Auftreten bestimmter Ereignisse, die während Berechnungen eintreten können, festzuhalten.<br />
Speicherbefehle (LD, LDI, ST, MOV, …) haben auf dem AVR grundsätzlich keinen Einfluss auf das Statusregister. Will man den Inhalt eines Registers explizit testen (z.&nbsp;B. nach dem Laden aus dem SRAM), so kann man hierfür den TST-Befehl verwenden.<br />
<br />
<!--<br />
+---+---+---+---+---+---+---+---+<br />
| I | T | H | S | V | N | Z | C |<br />
+---+---+---+---+---+---+---+---+<br />
--><br />
<br />
<center><br />
{{Byte|Bits im SREG| I|T|H|S|V|N|Z|C}}<br />
</center><br />
<br />
===Carry (C)===<br />
Das Carry-Flag hält fest, ob es bei der letzten Berechnung einen Über- oder Unterlauf gab. Aber Achtung: Nicht alle arithmetischen Befehle verändern tatsächlich das Carry-Flag. So haben z.&nbsp;B. die Inkrementier- und Dekrementierbefehle keine Auswirkung auf dieses Flag.<br />
<br />
===Zero (Z)===<br />
Das Zero-Flag hält fest, ob das Ergebnis der letzten 8-Bit-Berechnung gleich 0 war oder nicht.<br />
<br />
===Negative (N)===<br />
Spiegelt den Zustand des höchstwertigen Bits (Bit 7) der letzten 8-Bit-Berechnung wider. In 2er-Komplement-Arithmetik bedeutet ein gesetztes Bit 7 eine negative Zahl, das Bit kann also dazu genutzt werden um festzustellen, ob das Ergebnis einer Berechnung im Sinne einer 2er-Komplement-Arithmetik positiv oder negativ ist.<br />
<br />
===Overflow (V)===<br />
Dieses Bit wird gesetzt, wenn bei einer Berechnung mit 2er-Komplement-Arithmetik ein Überlauf (Unterlauf) stattgefunden hat. Dies entspricht einem Überlauf von Bit 6 ins Bit 7.<br />
<br />
Der Übertrag, der bei der Addition/Subtraktion von Bit 6 auf Bit 7 auftritt, zeigt daher – wenn er vorhanden ist – an,<br />
dass es sich hier um einen Überlauf (Overflow) des Zahlenbereichs handelt und das Ergebnis falsch ist.<br />
Das ist allerdings nicht der Fall, wenn auch der Übertrag von Bit 7 nach Bit 8 (Carry) aufgetreten ist.<br />
Daher ist das Overflow-Flag die [[AVR-Tutorial: Logik#XOR (Exklusives Oder)|XOR-Verknüpfung]] aus dem Übertrag von Bit 6 nach Bit 7 und dem Carry.<br />
<br />
Beispiele für die Anwendung des V-Flags finden sich in [[AVR Arithmetik/Saturierung|saturierter Arithmetik]].<br />
<br />
===Signed (S)===<br />
Das Signed-Bit ergibt sich aus der Antivalenz (exklusives Oder) der Flags N und V, also S = N XOR V.<br />
Mit Hilfe des Signed-Flags können vorzeichenbehaftete Werte miteinander verglichen werden. Ist nach einem Vergleich zweier Register S=1, so ist der Wert des ersten Registers kleiner dem zweiten (in der Signed-Darstellung). Damit entspricht das Signed-Flag gewissermaßen dem Carry-Flag für Signed-Werte. Es wird hauptsächlich für „Signed“-Tests benötigt. Daher auch der Name.<br />
<br />
===Half Carry (H)===<br />
Das Half-Carry-Flag hat die gleiche Aufgabe wie das Carry Flag, nur beschäftigt es sich mit einem Überlauf von Bit 3 nach Bit 4, also dem Übertrag zwischen dem oberen und dem unteren Nibble. Wie beim Carry-Flag gilt, dass das Flag nicht durch Inkrementieren bzw. Dekrementieren ausgelöst werden kann.<br />
Das Haupteinsatzgebiet ist der Bereich der BCD-Arithmetik (binär codierte Dezimalzahlen), bei der jeweils 4 Bits eine Stelle einer Dezimalzahl repräsentieren.<br />
<br />
Kein Compiler benutzt das H-Flag. Findet man die Befehle <tt>brhc</tt>, <tt>brhs</tt>, <tt>clh</tt> oder <tt>seh</tt> in einem Disassemblerlisting, sind das entweder Daten oder es wurde in Assembler programmiert. Das H-Flag lässt sich bspw. dazu verwenden, zwei Zähler in einem Byte zu realisieren. So signalisiert das H-Flag in einem <u>Bit</u>zähler, wann das nächste <u>Byte</u> nachzuladen ist, indem man 2 addiert. Das reicht für 127 Bit.<br />
<br />
=== Transfer (T)===<br />
Das T-Flag ist kein Statusbit im eigentlichen Sinne. Es steht dem Programmierer als 1-Bit-Speicher zur Verfügung. Der Zugriff erfolgt über die Befehle Bit Load (BLD), Bit Store (BST), Set-T (SET) und Clear-T (CLT) und wird sonst von keinen anderen Befehlen beeinflusst. Damit können Bits von einer Stelle schnell an eine andere kopiert oder getestet werden. Es gibt <i>keinen</i> Befehl um das Bit zu kippen.<br />
<br />
Kein Compiler benutzt das T-Flag. Es kann jedoch in der Laufzeitbibliothek Verwendung finden, solche Kode-Abschnitte sind handoptimierter Assembler. <tt>avr-gcc</tt> betrachtet das T-Flag als „flüchtig“ und darf in Unterprogrammen und Makros verändert werden.<br />
<br />
===Interrupt (I)===<br />
Das Interrupt-Flag fällt hier etwas aus dem Rahmen; es hat nichts mit Berechnungen zu tun, sondern steuert, ob Interrupts im Controller zugelassen sind (siehe [[AVR-Tutorial: Interrupts]]).<br />
<br />
==Vergleiche==<br />
Um einen Vergleich durchzuführen, wird intern eine Subtraktion der beiden Operanden vorgenommen. Das eigentliche Ergebnis der Subtraktion wird allerdings verworfen, es bleibt nur die neue Belegung der Flags übrig, die in weiterer Folge ausgewertet werden kann.<br />
<br />
===CP – Compare===<br />
Vergleicht den Inhalt zweier Register miteinander. Prozessorintern wird dabei eine Subtraktion der beiden Register durchgeführt. Das eigentliche Subtraktionsergebnis wird allerdings verworfen, das Subtraktionsergebnis beeinflusst lediglich die Flags.<br />
<br />
===CPC – Compare with Carry===<br />
Vergleicht den Inhalt zweier Register, wobei das Carry-Flag in den Vergleich mit einbezogen wird. Dieser Befehl wird für Arithmetik mit großen Variablen (16 oder 32 Bit) benötigt. Siehe [[AVR-Tutorial: Arithmetik]].<br />
<br />
===CPI – Compare Immediate===<br />
Vergleicht den Inhalt eines Registers mit einer direkt angegebenen Konstanten. Der Befehl ist nur auf die Register r16…r31 anwendbar.<br />
<br />
==Bedingte Sprünge==<br />
<br />
Die bedingten Sprünge werten immer bestimmte Flags im Statusregister (SREG) aus. Es spielt dabei keine Rolle, ob dies nach einem Vergleichsbefehl oder einem sonstigen Befehl gemacht wird. Entscheidend ist einzig und allein der Zustand des abgefragten Flags. Die Namen der Sprungbefehle wurden allerdings so gewählt, daß sich im Befehlsnamen die Beziehung der Operanden direkt nach einem Compare-Befehl widerspiegelt. Zu beachten ist auch, daß die Flags nicht nur durch Vergleichsbefehle verändert werden, sondern auch durch arithmetische Operationen, Schiebebefehle und [[Bitmanipulation|logische Verknüpfungen]]. Da diese Information wichtig ist, ist auch in der bei Atmel/Microchip erhältlichen [https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf Übersicht über alle Assemblerbefehle] bei jedem Befehl angegeben, ob und wie er Flags beeinflusst. Ebenso ist dort eine kompakte Übersicht aller bedingten Sprünge zu finden. Beachten muss man jedoch, dass die bedingten Sprünge maximal 64 Worte weit springen können.<br />
<br />
=== Bedingte Sprünge für vorzeichenlose Zahlen ===<br />
<br />
;BRSH – Branch if Same or Higher: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) nicht gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann statt, wenn der erste Operand größer oder gleich dem zweiten Operanden ist. BRSH ist identisch mit BRCC (Branch if Carry Cleared).<br />
<br />
;BRLO – Branch if Lower: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann statt, wenn der erste Operand kleiner dem zweiten Operanden ist. BRLO ist identisch mit BRCS (Branch if Carry Set).<br />
<br />
=== Bedingte Sprünge für vorzeichenbehaftete Zahlen ===<br />
<br />
;BRGE – Branch if Greater or Equal: Der Sprung wird durchgeführt, wenn das Signed-Flag (S) nicht gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann und nur dann statt, wenn der erste Operand größer oder gleich dem zweiten Operanden ist.<br />
<br />
;BRLT – Branch if Less Than: Der Sprung wird durchgeführt, wenn das Signed-Flag (S) gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann und nur dann statt, wenn der erste Operand kleiner als der zweite Operand ist.<br />
<br />
;BRMI – Branch if Minus: Der Sprung wird durchgeführt, wenn das Negativ-Flag (N) gesetzt ist, das Ergebnis der letzten Operation also negativ war.<br />
<br />
;BRPL – Branch if Plus: Der Sprung wird durchgeführt, wenn das Negativ-Flag (N) nicht gesetzt ist, das Ergebnis der letzten Operation also positiv war (einschließlich null).<br />
<br />
=== Sonstige bedingte Sprünge ===<br />
<br />
;BREQ – Branch if Equal: Der Sprung wird durchgeführt, wenn das Zero-Flag (Z) gesetzt ist. Ist nach einem Vergleich das Zero-Flag gesetzt, lieferte die interne Subtraktion also 0, so waren beide Operanden gleich.<br />
<br />
;BRNE – Branch if Not Equal: Der Sprung wird durchgeführt, wenn das Zero-Flag (Z) nicht gesetzt ist. Ist nach einem Vergleich das Zero-Flag nicht gesetzt, lieferte die interne Subtraktion also nicht 0, so waren beide Operanden verschieden.<br />
<br />
;BRCC – Branch if Carry Flag is Cleared: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) nicht gesetzt ist. Dieser Befehl wird oft für Arithmetik mit großen Variablen (16 oder 32&nbsp;Bit) bzw. im Zusammenhang mit Schiebeoperationen verwendet. BRCC ≡ BRSH<br />
<br />
;BRCS – Branch if Carry Flag is Set: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) gesetzt ist. Die Verwendung ist sehr ähnlich zu BRCC. BRCS ≡ BRLO<br />
<br />
=== Selten verwendete bedingte Sprünge ===<br />
<br />
;BRHC – Branch if Half Carry Flag is Cleared: Der Sprung wird durchgeführt, wenn das Half-Carry-Flag (H) nicht gesetzt ist.<br />
<br />
;BRHS – Branch if Half Carry Flag is Set: Der Sprung wird durchgeführt, wenn das Half-Carry-Flag (H) gesetzt ist.<br />
<br />
;BRID – Branch if Global Interrupt is Disabled: Der Sprung wird durchgeführt, wenn das Interrupt-Flag (I) nicht gesetzt ist.<br />
<br />
;BRIE – Branch if Global Interrupt is Enabled: Der Sprung wird durchgeführt, wenn das Interrupt-Flag (I) gesetzt ist.<br />
<br />
;BRTC – Branch if T Flag is Cleared: Der Sprung wird durchgeführt, wenn das T-Flag nicht gesetzt ist.<br />
<br />
;BRTS – Branch if T Flag is Set: Der Sprung wird durchgeführt, wenn das T-Flag gesetzt ist.<br />
<br />
;BRVC – Branch if Overflow Cleared: Der Sprung wird durchgeführt, wenn das Overflow-Flag (V) nicht gesetzt ist.<br />
<br />
;BRVS – Branch if Overflow Set: Der Sprung wird durchgeführt, wenn das Overflow-Flag (V) gesetzt ist.<br />
<br />
==Beispiele==<br />
<br />
=== Entscheidungen ===<br />
<br />
In jedem Programm kommt früher oder später das Problem, die Ausführung von Codeteilen von irgendwelchen Zahlenwerten, die sich in anderen Registern befinden, abhängig zu machen. Sieht beispielsweise die Aufgabe vor, daß Register r18 auf 0 gesetzt werden soll, falls im Register r17 der Zahlenwert 25 enthalten ist und in allen anderen Fällen soll r18 auf 123 gesetzt werden, dann lautet der Code:<br />
<br />
<syntaxhighlight lang="asm"><br />
cpi r17, 25 ; vergleiche r17 mit der Konstante 25<br />
brne nicht_gleich ; wenn nicht gleich, dann mach bei nicht_gleich weiter<br />
ldi r18, 0 ; hier stehen nun Anweisungen für den Fall,<br />
; dass R17 gleich 25 ist<br />
rjmp weiter ; meist will man den anderen Zweig nicht durchlaufen, darum der Sprung<br />
nicht_gleich:<br />
ldi r18, 123 ; hier stehen nun Anweisungen für den Fall,<br />
; dass R17 ungleich 25 ist<br />
weiter: ; hier geht das Programm weiter<br />
</syntaxhighlight><br />
<br />
In ähnlicher Weise können die anderen bedingten Sprungbefehle eingesetzt werden, um die üblicherweise vorkommenden Vergleiche auf Gleichheit, Ungleichheit, „größer als“, „kleiner als“ zu realisieren.<br />
<br />
===Schleifenkonstrukte===<br />
<br />
Ein immer wiederkehrendes Muster in der Programmierung ist eine '''Schleife'''. Die einfachste Form einer Schleife ist die ''Zählschleife''. Dabei wird ein Register von einem Startwert ausgehend eine gewisse Anzahl erhöht, bis ein Endwert erreicht wird.<br />
<br />
<syntaxhighlight lang="asm"><br />
ldi r17, 10 ; der Startwert sei in diesem Beispiel 10<br />
loop:<br />
; an dieser Stelle stehen die Befehle, welche innerhalb der Schleife<br />
; mehrfach ausgeführt werden sollen<br />
<br />
inc r17 ; erhöhe das Zählregister<br />
cpi r17, 134 ; mit dem Endwert vergleichen<br />
brne loop ; und wenn der Endwert noch nicht erreicht ist,<br />
; wird bei der Marke loop ein weiterer Schleifendurchlauf ausgeführt<br />
</syntaxhighlight><br />
<br />
Sehr oft ist es auch möglich, das Konstrukt umzukehren. Anstatt von einem Startwert aus zu inkrementieren genügt es, die Anzahl der gewünschten Schleifendurchläufe in ein Register zu laden und dieses Register zu dekrementieren. Dabei kann man von der Eigenschaft der Dekrementieranweisung Gebrauch machen, das Zero-Flag (Z) zu beeinflussen. Ist das Ergebnis des Dekrements gleich 0, so wird das Zero-Flag gesetzt, welches wiederum in der nachfolgenden BRNE-Anweisung für einen bedingten Sprung benutzt werden kann. Das vereinfacht die Schleife und spart eine Anweisung sowie einen Takt Ausführungszeit.<br />
<br />
<syntaxhighlight lang="asm"><br />
ldi r17, 124 ; Die Anzahl der Wiederholungen in ein Register laden<br />
loop:<br />
; an dieser Stelle stehen die Befehle, welche innerhalb der Schleife<br />
; mehrfach ausgeführt werden sollen<br />
<br />
dec r17 ; Schleifenzähler um 1 verringern, dabei wird das Zero-Flag beeinflusst<br />
brne loop ; wenn r17 noch nicht 0 geworden ist -> Schleife wiederholen<br />
</syntaxhighlight><br />
<br />
==Literatur==<br />
* [https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf AVR Instruction Set Manual]: Übersicht aller AVR-Befehle mit Angaben zur Beeinflussung der Statusbits<br />
<br />
----<br />
<br />
{{Navigation_zurückhochvor|<br />
zurücktext=Interrupts|<br />
zurücklink=AVR-Tutorial: Interrupts|<br />
hochtext=Inhaltsverzeichnis|<br />
hochlink=AVR-Tutorial|<br />
vortext=Mehrfachverzweigungen|<br />
vorlink=AVR-Tutorial: Mehrfachverzweigung}}<br />
<br />
[[Category:AVR-Tutorial|Vergleiche]]<br />
[[Category:AVR-Arithmetik]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR-Tutorial:_Vergleiche&diff=107246AVR-Tutorial: Vergleiche2025-01-27T12:43:19Z<p>Heha: Half Carry (H)</p>
<hr />
<div>Vergleiche und Entscheidungen sind in jeder Programmiersprache ein zentrales Mittel, um den Programmfluss abhängig von Bedingungen zu kontrollieren. In einem [[AVR]] spielen dazu vier Komponenten zusammen:<br />
* Vergleichsbefehle,<br />
* die Flags im Statusregister,<br />
* bedingte Sprungbefehle,<br />
* andere Befehle, die die Flags im Statusregister beeinflussen, wie z.&nbsp;B. die meisten arithmetischen Funktionen.<br />
<br />
Der Zusammenhang ist dabei folgender: Die Vergleichsbefehle führen einen Vergleich durch, zum Beispiel zwischen zwei Registern oder zwischen einem Register und einer Konstanten. Das Ergebnis des Vergleiches wird in den Flags abgelegt. Die bedingten Sprungbefehle werten die Flags aus und führen bei einem positiven Ergebnis den Sprung aus. Besonders der erste Satzteil ist wichtig! Den bedingten Sprungbefehlen ist es nämlich völlig egal, ob die Flags über Vergleichsbefehle oder über sonstige Befehle gesetzt wurden. Die Sprungbefehle werten einfach nur die Flags aus, wie auch immer diese zu ihrem Zustand kommen.<br />
<br />
==Flags==<br />
<br />
Die Flags sind Bits im Statusregister '''SREG'''. Ihre Aufgabe ist es, das Auftreten bestimmter Ereignisse, die während Berechnungen eintreten können, festzuhalten.<br />
Speicherbefehle (LD, LDI, ST, MOV, …) haben auf dem AVR grundsätzlich keinen Einfluss auf das Statusregister. Will man den Inhalt eines Registers explizit testen (z.&nbsp;B. nach dem Laden aus dem SRAM), so kann man hierfür den TST-Befehl verwenden.<br />
<br />
<!--<br />
+---+---+---+---+---+---+---+---+<br />
| I | T | H | S | V | N | Z | C |<br />
+---+---+---+---+---+---+---+---+<br />
--><br />
<br />
<center><br />
{{Byte|Bits im SREG| I|T|H|S|V|N|Z|C}}<br />
</center><br />
<br />
===Carry (C)===<br />
Das Carry-Flag hält fest, ob es bei der letzten Berechnung einen Über- oder Unterlauf gab. Aber Achtung: Nicht alle arithmetischen Befehle verändern tatsächlich das Carry-Flag. So haben z.&nbsp;B. die Inkrementier- und Dekrementierbefehle keine Auswirkung auf dieses Flag.<br />
<br />
===Zero (Z)===<br />
Das Zero-Flag hält fest, ob das Ergebnis der letzten 8-Bit-Berechnung gleich 0 war oder nicht.<br />
<br />
===Negative (N)===<br />
Spiegelt den Zustand des höchstwertigen Bits (Bit 7) der letzten 8-Bit-Berechnung wider. In 2er-Komplement-Arithmetik bedeutet ein gesetztes Bit 7 eine negative Zahl, das Bit kann also dazu genutzt werden um festzustellen, ob das Ergebnis einer Berechnung im Sinne einer 2er-Komplement-Arithmetik positiv oder negativ ist.<br />
<br />
===Overflow (V)===<br />
Dieses Bit wird gesetzt, wenn bei einer Berechnung mit 2er-Komplement-Arithmetik ein Überlauf (Unterlauf) stattgefunden hat. Dies entspricht einem Überlauf von Bit 6 ins Bit 7.<br />
<br />
Der Übertrag, der bei der Addition/Subtraktion von Bit 6 auf Bit 7 auftritt, zeigt daher – wenn er vorhanden ist – an,<br />
dass es sich hier um einen Überlauf (Overflow) des Zahlenbereichs handelt und das Ergebnis falsch ist.<br />
Das ist allerdings nicht der Fall, wenn auch der Übertrag von Bit 7 nach Bit 8 (Carry) aufgetreten ist.<br />
Daher ist das Overflow-Flag die [[AVR-Tutorial: Logik#XOR (Exklusives Oder)|XOR-Verknüpfung]] aus dem Übertrag von Bit 6 nach Bit 7 und dem Carry.<br />
<br />
Beispiele für die Anwendung des V-Flags finden sich in [[AVR Arithmetik/Saturierung|saturierter Arithmetik]].<br />
<br />
===Signed (S)===<br />
Das Signed-Bit ergibt sich aus der Antivalenz (exklusives Oder) der Flags N und V, also S = N XOR V.<br />
Mit Hilfe des Signed-Flags können vorzeichenbehaftete Werte miteinander verglichen werden. Ist nach einem Vergleich zweier Register S=1, so ist der Wert des ersten Registers kleiner dem zweiten (in der Signed-Darstellung). Damit entspricht das Signed-Flag gewissermaßen dem Carry-Flag für Signed-Werte. Es wird hauptsächlich für „Signed“-Tests benötigt. Daher auch der Name.<br />
<br />
===Half Carry (H)===<br />
Das Half-Carry-Flag hat die gleiche Aufgabe wie das Carry Flag, nur beschäftigt es sich mit einem Überlauf von Bit 3 nach Bit 4, also dem Übertrag zwischen dem oberen und dem unteren Nibble. Wie beim Carry-Flag gilt, dass das Flag nicht durch Inkrementieren bzw. Dekrementieren ausgelöst werden kann.<br />
Das Haupteinsatzgebiet ist der Bereich der BCD-Arithmetik (binär codierte Dezimalzahlen), bei der jeweils 4 Bits eine Stelle einer Dezimalzahl repräsentieren.<br />
<br />
Kein Compiler benutzt das H-Flag. Findet man die Befehle <tt>brhc</tt>, <tt>brhs</tt>, <tt>clh</tt> oder <tt>seh</tt> in einem Disassemblerlisting, sind das entweder Daten oder es wurde in Assembler programmiert. Das H-Flag lässt sich bspw. dazu verwenden, zwei Zähler in einem Byte zu realisieren. So signalisiert das H-Flag in einem <u>Bit</u>zähler, wann das nächste <u>Byte</u> nachzuladen ist, indem man 2 addiert. Das reicht für 127 Bit.<br />
<br />
=== Transfer (T)===<br />
Das T-Flag ist kein Statusbit im eigentlichen Sinne. Es steht dem Programmierer als 1-Bit-Speicher zur Verfügung. Der Zugriff erfolgt über die Befehle Bit Load (BLD), Bit Store (BST), Set (SET) und Clear (CLT) und wird sonst von keinen anderen Befehlen beeinflusst. Damit können Bits von einer Stelle schnell an eine andere kopiert oder getestet werden.<br />
<br />
===Interrupt (I)===<br />
Das Interrupt-Flag fällt hier etwas aus dem Rahmen; es hat nichts mit Berechnungen zu tun, sondern steuert, ob Interrupts im Controller zugelassen sind (siehe [[AVR-Tutorial: Interrupts]]).<br />
<br />
==Vergleiche==<br />
Um einen Vergleich durchzuführen, wird intern eine Subtraktion der beiden Operanden vorgenommen. Das eigentliche Ergebnis der Subtraktion wird allerdings verworfen, es bleibt nur die neue Belegung der Flags übrig, die in weiterer Folge ausgewertet werden kann.<br />
<br />
===CP – Compare===<br />
Vergleicht den Inhalt zweier Register miteinander. Prozessorintern wird dabei eine Subtraktion der beiden Register durchgeführt. Das eigentliche Subtraktionsergebnis wird allerdings verworfen, das Subtraktionsergebnis beeinflusst lediglich die Flags.<br />
<br />
===CPC – Compare with Carry===<br />
Vergleicht den Inhalt zweier Register, wobei das Carry-Flag in den Vergleich mit einbezogen wird. Dieser Befehl wird für Arithmetik mit großen Variablen (16 oder 32 Bit) benötigt. Siehe [[AVR-Tutorial: Arithmetik]].<br />
<br />
===CPI – Compare Immediate===<br />
Vergleicht den Inhalt eines Registers mit einer direkt angegebenen Konstanten. Der Befehl ist nur auf die Register r16…r31 anwendbar.<br />
<br />
==Bedingte Sprünge==<br />
<br />
Die bedingten Sprünge werten immer bestimmte Flags im Statusregister (SREG) aus. Es spielt dabei keine Rolle, ob dies nach einem Vergleichsbefehl oder einem sonstigen Befehl gemacht wird. Entscheidend ist einzig und allein der Zustand des abgefragten Flags. Die Namen der Sprungbefehle wurden allerdings so gewählt, daß sich im Befehlsnamen die Beziehung der Operanden direkt nach einem Compare-Befehl widerspiegelt. Zu beachten ist auch, daß die Flags nicht nur durch Vergleichsbefehle verändert werden, sondern auch durch arithmetische Operationen, Schiebebefehle und [[Bitmanipulation|logische Verknüpfungen]]. Da diese Information wichtig ist, ist auch in der bei Atmel/Microchip erhältlichen [https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf Übersicht über alle Assemblerbefehle] bei jedem Befehl angegeben, ob und wie er Flags beeinflusst. Ebenso ist dort eine kompakte Übersicht aller bedingten Sprünge zu finden. Beachten muss man jedoch, dass die bedingten Sprünge maximal 64 Worte weit springen können.<br />
<br />
=== Bedingte Sprünge für vorzeichenlose Zahlen ===<br />
<br />
;BRSH – Branch if Same or Higher: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) nicht gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann statt, wenn der erste Operand größer oder gleich dem zweiten Operanden ist. BRSH ist identisch mit BRCC (Branch if Carry Cleared).<br />
<br />
;BRLO – Branch if Lower: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann statt, wenn der erste Operand kleiner dem zweiten Operanden ist. BRLO ist identisch mit BRCS (Branch if Carry Set).<br />
<br />
=== Bedingte Sprünge für vorzeichenbehaftete Zahlen ===<br />
<br />
;BRGE – Branch if Greater or Equal: Der Sprung wird durchgeführt, wenn das Signed-Flag (S) nicht gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann und nur dann statt, wenn der erste Operand größer oder gleich dem zweiten Operanden ist.<br />
<br />
;BRLT – Branch if Less Than: Der Sprung wird durchgeführt, wenn das Signed-Flag (S) gesetzt ist. Wird dieser Branch direkt nach einer CP-, CPI-, SUB- oder SUBI-Operation eingesetzt, so findet der Sprung dann und nur dann statt, wenn der erste Operand kleiner als der zweite Operand ist.<br />
<br />
;BRMI – Branch if Minus: Der Sprung wird durchgeführt, wenn das Negativ-Flag (N) gesetzt ist, das Ergebnis der letzten Operation also negativ war.<br />
<br />
;BRPL – Branch if Plus: Der Sprung wird durchgeführt, wenn das Negativ-Flag (N) nicht gesetzt ist, das Ergebnis der letzten Operation also positiv war (einschließlich null).<br />
<br />
=== Sonstige bedingte Sprünge ===<br />
<br />
;BREQ – Branch if Equal: Der Sprung wird durchgeführt, wenn das Zero-Flag (Z) gesetzt ist. Ist nach einem Vergleich das Zero-Flag gesetzt, lieferte die interne Subtraktion also 0, so waren beide Operanden gleich.<br />
<br />
;BRNE – Branch if Not Equal: Der Sprung wird durchgeführt, wenn das Zero-Flag (Z) nicht gesetzt ist. Ist nach einem Vergleich das Zero-Flag nicht gesetzt, lieferte die interne Subtraktion also nicht 0, so waren beide Operanden verschieden.<br />
<br />
;BRCC – Branch if Carry Flag is Cleared: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) nicht gesetzt ist. Dieser Befehl wird oft für Arithmetik mit großen Variablen (16 oder 32&nbsp;Bit) bzw. im Zusammenhang mit Schiebeoperationen verwendet. BRCC ≡ BRSH<br />
<br />
;BRCS – Branch if Carry Flag is Set: Der Sprung wird durchgeführt, wenn das Carry-Flag (C) gesetzt ist. Die Verwendung ist sehr ähnlich zu BRCC. BRCS ≡ BRLO<br />
<br />
=== Selten verwendete bedingte Sprünge ===<br />
<br />
;BRHC – Branch if Half Carry Flag is Cleared: Der Sprung wird durchgeführt, wenn das Half-Carry-Flag (H) nicht gesetzt ist.<br />
<br />
;BRHS – Branch if Half Carry Flag is Set: Der Sprung wird durchgeführt, wenn das Half-Carry-Flag (H) gesetzt ist.<br />
<br />
;BRID – Branch if Global Interrupt is Disabled: Der Sprung wird durchgeführt, wenn das Interrupt-Flag (I) nicht gesetzt ist.<br />
<br />
;BRIE – Branch if Global Interrupt is Enabled: Der Sprung wird durchgeführt, wenn das Interrupt-Flag (I) gesetzt ist.<br />
<br />
;BRTC – Branch if T Flag is Cleared: Der Sprung wird durchgeführt, wenn das T-Flag nicht gesetzt ist.<br />
<br />
;BRTS – Branch if T Flag is Set: Der Sprung wird durchgeführt, wenn das T-Flag gesetzt ist.<br />
<br />
;BRVC – Branch if Overflow Cleared: Der Sprung wird durchgeführt, wenn das Overflow-Flag (V) nicht gesetzt ist.<br />
<br />
;BRVS – Branch if Overflow Set: Der Sprung wird durchgeführt, wenn das Overflow-Flag (V) gesetzt ist.<br />
<br />
==Beispiele==<br />
<br />
=== Entscheidungen ===<br />
<br />
In jedem Programm kommt früher oder später das Problem, die Ausführung von Codeteilen von irgendwelchen Zahlenwerten, die sich in anderen Registern befinden, abhängig zu machen. Sieht beispielsweise die Aufgabe vor, daß Register r18 auf 0 gesetzt werden soll, falls im Register r17 der Zahlenwert 25 enthalten ist und in allen anderen Fällen soll r18 auf 123 gesetzt werden, dann lautet der Code:<br />
<br />
<syntaxhighlight lang="asm"><br />
cpi r17, 25 ; vergleiche r17 mit der Konstante 25<br />
brne nicht_gleich ; wenn nicht gleich, dann mach bei nicht_gleich weiter<br />
ldi r18, 0 ; hier stehen nun Anweisungen für den Fall,<br />
; dass R17 gleich 25 ist<br />
rjmp weiter ; meist will man den anderen Zweig nicht durchlaufen, darum der Sprung<br />
nicht_gleich:<br />
ldi r18, 123 ; hier stehen nun Anweisungen für den Fall,<br />
; dass R17 ungleich 25 ist<br />
weiter: ; hier geht das Programm weiter<br />
</syntaxhighlight><br />
<br />
In ähnlicher Weise können die anderen bedingten Sprungbefehle eingesetzt werden, um die üblicherweise vorkommenden Vergleiche auf Gleichheit, Ungleichheit, „größer als“, „kleiner als“ zu realisieren.<br />
<br />
===Schleifenkonstrukte===<br />
<br />
Ein immer wiederkehrendes Muster in der Programmierung ist eine '''Schleife'''. Die einfachste Form einer Schleife ist die ''Zählschleife''. Dabei wird ein Register von einem Startwert ausgehend eine gewisse Anzahl erhöht, bis ein Endwert erreicht wird.<br />
<br />
<syntaxhighlight lang="asm"><br />
ldi r17, 10 ; der Startwert sei in diesem Beispiel 10<br />
loop:<br />
; an dieser Stelle stehen die Befehle, welche innerhalb der Schleife<br />
; mehrfach ausgeführt werden sollen<br />
<br />
inc r17 ; erhöhe das Zählregister<br />
cpi r17, 134 ; mit dem Endwert vergleichen<br />
brne loop ; und wenn der Endwert noch nicht erreicht ist,<br />
; wird bei der Marke loop ein weiterer Schleifendurchlauf ausgeführt<br />
</syntaxhighlight><br />
<br />
Sehr oft ist es auch möglich, das Konstrukt umzukehren. Anstatt von einem Startwert aus zu inkrementieren genügt es, die Anzahl der gewünschten Schleifendurchläufe in ein Register zu laden und dieses Register zu dekrementieren. Dabei kann man von der Eigenschaft der Dekrementieranweisung Gebrauch machen, das Zero-Flag (Z) zu beeinflussen. Ist das Ergebnis des Dekrements gleich 0, so wird das Zero-Flag gesetzt, welches wiederum in der nachfolgenden BRNE-Anweisung für einen bedingten Sprung benutzt werden kann. Das vereinfacht die Schleife und spart eine Anweisung sowie einen Takt Ausführungszeit.<br />
<br />
<syntaxhighlight lang="asm"><br />
ldi r17, 124 ; Die Anzahl der Wiederholungen in ein Register laden<br />
loop:<br />
; an dieser Stelle stehen die Befehle, welche innerhalb der Schleife<br />
; mehrfach ausgeführt werden sollen<br />
<br />
dec r17 ; Schleifenzähler um 1 verringern, dabei wird das Zero-Flag beeinflusst<br />
brne loop ; wenn r17 noch nicht 0 geworden ist -> Schleife wiederholen<br />
</syntaxhighlight><br />
<br />
==Literatur==<br />
* [https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-InstructionSet-Manual-DS40002198.pdf AVR Instruction Set Manual]: Übersicht aller AVR-Befehle mit Angaben zur Beeinflussung der Statusbits<br />
<br />
----<br />
<br />
{{Navigation_zurückhochvor|<br />
zurücktext=Interrupts|<br />
zurücklink=AVR-Tutorial: Interrupts|<br />
hochtext=Inhaltsverzeichnis|<br />
hochlink=AVR-Tutorial|<br />
vortext=Mehrfachverzweigungen|<br />
vorlink=AVR-Tutorial: Mehrfachverzweigung}}<br />
<br />
[[Category:AVR-Tutorial|Vergleiche]]<br />
[[Category:AVR-Arithmetik]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR_HV-Programmer&diff=107244AVR HV-Programmer2025-01-26T21:28:16Z<p>Heha: Emuliert (besser) STK600</p>
<hr />
<div>Ein "Hochspannungs"-Programmierer für AVR legt eine Spannung von +12V an den Reset-Eingang. Damit lassen sich auch Fusebits programmieren, die mit dem normalen ISP-Programmer nicht zugänglich sind.<br />
<br />
Zu unterscheiden sind das High Voltage Serial Programming ([http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/AVRDragon/AVRDragon_HVSP_Description.htm HVSP]) und das Parallel Programming ([http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/AVRDragon/AVRDragon_PP_Description.htm PP]). Welche Methode(n) ein AVR unterstützt, steht im jeweiligen Datenblatt des AVRs.<br />
<br />
Bekannte HV Programmer sind:<br />
* [[STK500]] (HVSP, PP)<br />
* [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (HVSP, PP)<br />
* [http://www.der-hammer.info/hvprog/ HVProg von Tobias Hammer] (PP, HVSP)<br />
* [http://www.b-redemann.de/sp-hvprog1.shtml Bausatz und Anleitung von Bernhard Redemann] (PP)<br />
* [https://www.obdev.at/products/vusb/avrdoper.html AVR-Doper] High Voltage '''Serial''' Programmer (HVSP)<br />
* [http://mightyohm.com/blog/2008/09/arduino-based-avr-high-voltage-programmer/ Arduino-based AVR High Voltage Programmer] (PP)<br />
* [http://elm-chan.org/works/avrx/report_e.html '''Parallel''' HV-Programmer von ElmChan (ChaN)] (HVSP, PP, TPI)<br />
* [http://diy.elektroda.eu/atmega-fusebit-doctor-hvpp/?lang=en Atmega fusebit doctor] (HVSP, PP)<br />
* [https://guloshop.de/shop/Mikrocontroller-Programmierung/HVSP-Fusebit-Programmer::63.html HVSP Fusebit Programmer] (HVSP, auch stand-alone ohne PC nutzbar)<br />
* [http://homepage.hispeed.ch/peterfleury/avr-hvsp-fuse-restore.html ATtiny Fuse Restore] Anleitung für einen einfach aufzubauenden ATtiny Fuse Resetter mit AVR-GCC Software von Peter Fleury (HVSP)<br />
<br />
Hochvolt-Programmer sind ''nur dann'' als '''In-System'''-Programmer verwendbar, wenn die Schaltung mit den 12 V an der Resetleitung zurechtkommt und auch alle anderen Pins genügend hochohmig und ohne schaltungstechnische Nebenwirkungen (etwa einem Brückenkurzschluss) angeschlossen sind. Da dies bei der Menge anzuschließender Pins [im Vergleich zur Gesamtanzahl der Pins des Gehäuses] eher selten der Fall sein wird, werden die Chips fast immer „solo“ (sozusagen „Out-System“) gebrannt. Am ehesten bietet sich HVSP-ISP für 14-beinige SMD-AVRs an; dazu müssen in der Einsatzschaltung ggf. entsprechende Vorkehrungen getroffen werden.<br />
<br />
=== Ein Platinenlayout für ElmChans Hochvolt-Programmer ===<br />
<br />
Dieser benötigt einen PC mit Parallelport sowie eine externe Stromversorgung von 6..24 V=. USB-Parallel-Konverter (für Drucker) funktionieren ''nicht''. Vorteil: Ein Mikrocontroller wird nicht benötigt.<br />
<br />
Wie auch das Original beherrscht dieser PP (parallel programming) als auch HVSP (serial programming).<br />
Für den rein seriellen Gebrauch (HVSP der 8- und 14-Beiner) kann man auf den 74HC299 verzichten.<br />
<br />
Schaltplan im Eagle-Format, Bestückungspläne und Platinenlayout: [[Benutzer:Christoph kessler|Christoph Kessler]] <br />
<br />
ElmChans Konzept ist eine ausgesprochene „Billiglösung“, die 20-poligen AVRs bevorzugend, dem scheint eine einseitige Platine mit Drahtbrücken im Eagle-Light-Format 80×100 mm² angemessen. Jener verzichtet auf Spannungsregler; einen 78L05 hinzuzusetzen und das Ganze mit stabilisierten 12 V zu speisen sollte jedoch nicht allzu schwer fallen.<br />
<br />
Das Foto (unten) zeigt schon die „Luxusversion“, Teilbestückung ist entsprechend denkbar.<br />
<br />
'''Achtung, Schaltplanfehler!''' Die Bezeichnungen /AUTOFEED und /SELIN sind genau verkehrt herum.<br />
<br />
[[Media:AVR_HV_Programmer_Eagle.zip | Eagle board / schematic files]]<br />
<br />
[[Bild:Schematic.png|600px]]<br />
<br />
[[Bild:Components.png|600px]]<br />
<br />
[[Bild:AVR_HV_Programmer_Layout.png|600px]]<br />
<br />
[[Bild:AVR_HV_Programmer_Foto.jpg]]<br />
<br />
=== Software, auch für ATtiny4..10, also TPI ===<br />
<br />
Open-Source, für Windows und Linux, jeweils 32 und 64 Bit, winzige Echse-Größe, [http://www.tu-chemnitz.de/~heha/hs/avrpp.zip/ Download].<br />
Kann direkt ELF-Dateien laden, kein Umweg über <tt>avr-objcopy</tt> erforderlich.<br />
Kann EEPROM, Fuses und Lockbits „in einem Rutsch“ der (von-neumannisierten) Hex- oder ELF-Datei<br />
entnehmen und brennen.<br />
Sowie die Chip-Signatur aus der Datei (mit <tt>#include <avr/signature.h></tt> zu generieren) mit dem Chip vergleichen.<br />
Bei Verwendung einer ELF-Datei kann die Software die Chip-Signatur von der elf-Section '''.note.gnu.avr.deviceinfo''' ermitteln; <tt>#include <avr/signature.h></tt> ist dann nicht mehr erforderlich.<br />
Die Software kennt alle 8-Bit-AVRs.<br />
Unterstützt direkten (giveio.sys) als auch indirekten (InpOut32.dll) Portzugriff aufs Parallelport sowie eine wahlfreie Port(basis)adresse.<br />
Läuft von Windows 95 bis Windows 10 sowie Linux; ein PC mit Parallelport (auch als Steckkarte via PCI oder PCIexpress nachgerüstet) ist erforderlich. Parallelports an Docking-Stations funktionieren auch. USB-Parallel-Konverter (für alte Drucker) funktionieren nicht.<br />
<br />
Der sechsbeinige Schaltkreis im SOT23-Gehäuse ist wie folgt an die 8-polige Fassung anzuschließen:<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Pin der Fassung !! Pin des Controllers !! Signalname<br />
|-<br />
| 1 || 6 || <span style='text-decoration:overline'>RESET</span> = Programmierspannung<br />
|-<br />
| 2 || 3 || TPICLK (Takt)<br />
|-<br />
| 4 || 2 || GND (Bezugspotenzial)<br />
|-<br />
| 7 || 1 || TPIDATA (Daten, bidirektional)<br />
|-<br />
| 8 || 5 || 5P (geschaltet)<br />
|}<br />
<br />
Das Pin 4 des Controllers kann frei bleiben.<br />
<br />
==== Fuse bei ATtiny4..10 ====<br />
<br />
Diese Mikrocontroller haben laut Dokumentation keine Fuse(s), sondern '''Configuration Bits'''.<br />
avr-gcc trägt diesem Umstand „Rechnung“, dass <tt>#include &lt;avr/fuse.h&gt;</tt> nicht wie erwartet funktioniert: Die Configuration-Bits sollen laut Linker-Skript in der Sektion <tt>.config</tt> ankommen, mit der linearen Adresse 0x820000 (die gleiche wie <tt>.fuse</tt> für die übrigen AVRs).<br />
In die ELF-Datei setzt man ein einzelnes Configuration-Byte so:<br />
<br />
'''uint8_t __attribute__((section('''<span style="color:blue">".config"</span>''')))''' Config=<span style="color:blue">0xFE</span>; ''// <span style="text-decoration:overline">Reset</span> = I/O-Pin''<br />
<br />
Der ELF-Loader vom oben angegebenen '''avrpp''' berücksichtigt diese Besonderheit.<br />
<br />
==== avr-gcc-Fehler bei ATtiny4 und ATtiny5 ====<br />
<br />
Verwendet man<br />
<br />
#include <avr/signature.h><br />
<br />
verweigert '''avrpp''' die Zusammenarbeit mit dem Chip, weil die Signatur nicht passt. Hier liegt der Fehler in den Kopfdateien <tt>avr/tn4.h</tt> und <tt>avr/tn5.h</tt>, dort sind die Signaturbytes tatsächlich falsch eingetragen.<br />
Vielleicht liest das jemand vom avr-gcc-Team und packt das Problem an der Wurzel, statt selbst die Dateien korrigieren zu müssen.<br />
<br />
=== USB-Hardware ===<br />
<br />
Das Verschwinden von Parallelports stellt die größte Hürde für Bastel-Programmiergeräte dar.<br />
Programmiergeräte mit USB leiden nur dann nicht unter dem Henne-Ei-Problem, wenn der verwendete USB-Mikrocontroller bereits ab Fabrik einen USB-Urlader enthält. Immerhin löst USB das Problem der sonst erforderlichen zusätzlichen Stromversorgung.<br />
<br />
Es scheint kein Bastel-USB-Programmiergerät zu geben, welches '''ISP''' ''und'' '''HVSP''' ''und'' '''HVPP''' ''und'' '''TPI''' kann! '''TPI''' sowohl in Niedervolt- als auch Hochvolt-Ausprägung. Deshalb habe ich hier ein [https://www-user.tu-chemnitz.de/~heha/basteln/pg/avrpp#2 nachbaufähiges Muster] entwickelt. Es basiert auf ATmega16U2, der bereits einen Urlader mitbringt.<br />
<br />
Der Gerätezugriff darauf erfolgt noch nicht mit avrpp.exe sondern <tt>avrdude -c stk600</tt> bzw. <tt>stk600pp</tt> bzw. <tt>stk600hvsp</tt>. Unterstützung für PIC ist ebenfalls vorgesehen, indem die Programmierspannung einstellbar ist. (Das PIC-Programmierinterface ist identisch zu TPI, bloß ein anderer Name und ein anderes Protokoll.)<br />
<br />
=== Betrieb mit SMD-Clip ===<br />
<br />
Beim Betrieb dieses Programmiergerätes in Verbindung mit einem 8-poligen SMD-Clip zur Programmierung von '''ATtiny<i>X</i>5''' (SU und SSU = breites und normales SMD-Gehäuse mit '''e''' = 1,27 mm) versagt bereits das Auslesen der Device-ID-Bytes, und der Chip wird nicht erkannt.<br />
Auch das Drosseln der Programmiergeschwindigkeit (bspw. mit '''-i10''') hilft nicht dagegen.<br />
Ursache sind gegenseitige Störungen auf den vier Datenleitungen, die vom Mikrocontroller selbst verursacht werden und über die Leitungslänge von nur 15 cm nicht mehr genügend von den Widerständen auf dem Programmerboard bedämpft werden.<br />
Dies führt letztlich zu zusätzlichen Taktflanken auf '''SCI = PB3'''.<br />
<br />
Abhilfe schafft ein '''Kondensator 100 pF''' zwischen '''Pin 2 = SCI = PB3''' und '''Pin 4 = GND''' ''direkt am zu programmierenden Mikrocontroller''.<br />
<small>Alternativ ein '''Kondensator 4,7 nF''' zwischen '''Pin 7 = PB2 = SDO''' und '''Pin 4 = GND''', ebenfalls ''direkt am zu programmierenden Mikrocontroller''.<br />
Andere versuchsweise Kondensatoren, insbesondere zwischen '''Pin 8 = U<sub>CC</sub>''' und '''Pin 4 = GND''' brachten keinen Erfolg.</small><br />
<br />
Dasselbe Problem wird vermutlich auch bei anderen 8-poligen ATtinys und beim Verlängern mit 14-poligen '''ATtiny<i>X</i>4''' auftreten, da gleicher Programmieralgorithmus: „HVSP“ = Hochvolt-serielle Programmierung.<br />
<br />
Es ist davon auszugehen, dass eine geeignete Terminierung auf der Programmer-Seite (bspw. Serienwiderstände 100 Ω statt 1 kΩ) das Problem ebenfalls und besser löst.<br />
<br />
===siehe auch===<br />
[http://xray37.de/?Bastelbuch:Lima-SDR:RX Miniatur-Version von ElmChans HV-Programmer]<br />
<br />
[[AVR In System Programmer]]<br />
<br />
[[Kategorie:AVR-Programmer und -Bootloader]]<br />
[[Kategorie:AVR-Boards]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR_HV-Programmer&diff=107243AVR HV-Programmer2025-01-26T21:22:57Z<p>Heha: ElmChan kann auch TPI für ATtiny4..10</p>
<hr />
<div>Ein "Hochspannungs"-Programmierer für AVR legt eine Spannung von +12V an den Reset-Eingang. Damit lassen sich auch Fusebits programmieren, die mit dem normalen ISP-Programmer nicht zugänglich sind.<br />
<br />
Zu unterscheiden sind das High Voltage Serial Programming ([http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/AVRDragon/AVRDragon_HVSP_Description.htm HVSP]) und das Parallel Programming ([http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/AVRDragon/AVRDragon_PP_Description.htm PP]). Welche Methode(n) ein AVR unterstützt, steht im jeweiligen Datenblatt des AVRs.<br />
<br />
Bekannte HV Programmer sind:<br />
* [[STK500]] (HVSP, PP)<br />
* [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (HVSP, PP)<br />
* [http://www.der-hammer.info/hvprog/ HVProg von Tobias Hammer] (PP, HVSP)<br />
* [http://www.b-redemann.de/sp-hvprog1.shtml Bausatz und Anleitung von Bernhard Redemann] (PP)<br />
* [https://www.obdev.at/products/vusb/avrdoper.html AVR-Doper] High Voltage '''Serial''' Programmer (HVSP)<br />
* [http://mightyohm.com/blog/2008/09/arduino-based-avr-high-voltage-programmer/ Arduino-based AVR High Voltage Programmer] (PP)<br />
* [http://elm-chan.org/works/avrx/report_e.html '''Parallel''' HV-Programmer von ElmChan (ChaN)] (HVSP, PP, TPI)<br />
* [http://diy.elektroda.eu/atmega-fusebit-doctor-hvpp/?lang=en Atmega fusebit doctor] (HVSP, PP)<br />
* [https://guloshop.de/shop/Mikrocontroller-Programmierung/HVSP-Fusebit-Programmer::63.html HVSP Fusebit Programmer] (HVSP, auch stand-alone ohne PC nutzbar)<br />
* [http://homepage.hispeed.ch/peterfleury/avr-hvsp-fuse-restore.html ATtiny Fuse Restore] Anleitung für einen einfach aufzubauenden ATtiny Fuse Resetter mit AVR-GCC Software von Peter Fleury (HVSP)<br />
<br />
Hochvolt-Programmer sind ''nur dann'' als '''In-System'''-Programmer verwendbar, wenn die Schaltung mit den 12 V an der Resetleitung zurechtkommt und auch alle anderen Pins genügend hochohmig und ohne schaltungstechnische Nebenwirkungen (etwa einem Brückenkurzschluss) angeschlossen sind. Da dies bei der Menge anzuschließender Pins [im Vergleich zur Gesamtanzahl der Pins des Gehäuses] eher selten der Fall sein wird, werden die Chips fast immer „solo“ (sozusagen „Out-System“) gebrannt. Am ehesten bietet sich HVSP-ISP für 14-beinige SMD-AVRs an; dazu müssen in der Einsatzschaltung ggf. entsprechende Vorkehrungen getroffen werden.<br />
<br />
=== Ein Platinenlayout für ElmChans Hochvolt-Programmer ===<br />
<br />
Dieser benötigt einen PC mit Parallelport sowie eine externe Stromversorgung von 6..24 V=. USB-Parallel-Konverter (für Drucker) funktionieren ''nicht''. Vorteil: Ein Mikrocontroller wird nicht benötigt.<br />
<br />
Wie auch das Original beherrscht dieser PP (parallel programming) als auch HVSP (serial programming).<br />
Für den rein seriellen Gebrauch (HVSP der 8- und 14-Beiner) kann man auf den 74HC299 verzichten.<br />
<br />
Schaltplan im Eagle-Format, Bestückungspläne und Platinenlayout: [[Benutzer:Christoph kessler|Christoph Kessler]] <br />
<br />
ElmChans Konzept ist eine ausgesprochene „Billiglösung“, die 20-poligen AVRs bevorzugend, dem scheint eine einseitige Platine mit Drahtbrücken im Eagle-Light-Format 80×100 mm² angemessen. Jener verzichtet auf Spannungsregler; einen 78L05 hinzuzusetzen und das Ganze mit stabilisierten 12 V zu speisen sollte jedoch nicht allzu schwer fallen.<br />
<br />
Das Foto (unten) zeigt schon die „Luxusversion“, Teilbestückung ist entsprechend denkbar.<br />
<br />
'''Achtung, Schaltplanfehler!''' Die Bezeichnungen /AUTOFEED und /SELIN sind genau verkehrt herum.<br />
<br />
[[Media:AVR_HV_Programmer_Eagle.zip | Eagle board / schematic files]]<br />
<br />
[[Bild:Schematic.png|600px]]<br />
<br />
[[Bild:Components.png|600px]]<br />
<br />
[[Bild:AVR_HV_Programmer_Layout.png|600px]]<br />
<br />
[[Bild:AVR_HV_Programmer_Foto.jpg]]<br />
<br />
=== Software, auch für ATtiny4..10, also TPI ===<br />
<br />
Open-Source, für Windows und Linux, jeweils 32 und 64 Bit, winzige Echse-Größe, [http://www.tu-chemnitz.de/~heha/hs/avrpp.zip/ Download].<br />
Kann direkt ELF-Dateien laden, kein Umweg über <tt>avr-objcopy</tt> erforderlich.<br />
Kann EEPROM, Fuses und Lockbits „in einem Rutsch“ der (von-neumannisierten) Hex- oder ELF-Datei<br />
entnehmen und brennen.<br />
Sowie die Chip-Signatur aus der Datei (mit <tt>#include <avr/signature.h></tt> zu generieren) mit dem Chip vergleichen.<br />
Bei Verwendung einer ELF-Datei kann die Software die Chip-Signatur von der elf-Section '''.note.gnu.avr.deviceinfo''' ermitteln; <tt>#include <avr/signature.h></tt> ist dann nicht mehr erforderlich.<br />
Die Software kennt alle 8-Bit-AVRs.<br />
Unterstützt direkten (giveio.sys) als auch indirekten (InpOut32.dll) Portzugriff aufs Parallelport sowie eine wahlfreie Port(basis)adresse.<br />
Läuft von Windows 95 bis Windows 10 sowie Linux; ein PC mit Parallelport (auch als Steckkarte via PCI oder PCIexpress nachgerüstet) ist erforderlich. Parallelports an Docking-Stations funktionieren auch. USB-Parallel-Konverter (für alte Drucker) funktionieren nicht.<br />
<br />
Der sechsbeinige Schaltkreis im SOT23-Gehäuse ist wie folgt an die 8-polige Fassung anzuschließen:<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Pin der Fassung !! Pin des Controllers !! Signalname<br />
|-<br />
| 1 || 6 || <span style='text-decoration:overline'>RESET</span> = Programmierspannung<br />
|-<br />
| 2 || 3 || TPICLK (Takt)<br />
|-<br />
| 4 || 2 || GND (Bezugspotenzial)<br />
|-<br />
| 7 || 1 || TPIDATA (Daten, bidirektional)<br />
|-<br />
| 8 || 5 || 5P (geschaltet)<br />
|}<br />
<br />
Das Pin 4 des Controllers kann frei bleiben.<br />
<br />
==== Fuse bei ATtiny4..10 ====<br />
<br />
Diese Mikrocontroller haben laut Dokumentation keine Fuse(s), sondern '''Configuration Bits'''.<br />
avr-gcc trägt diesem Umstand „Rechnung“, dass <tt>#include &lt;avr/fuse.h&gt;</tt> nicht wie erwartet funktioniert: Die Configuration-Bits sollen laut Linker-Skript in der Sektion <tt>.config</tt> ankommen, mit der linearen Adresse 0x820000 (die gleiche wie <tt>.fuse</tt> für die übrigen AVRs).<br />
In die ELF-Datei setzt man ein einzelnes Configuration-Byte so:<br />
<br />
'''uint8_t __attribute__((section('''<span style="color:blue">".config"</span>''')))''' Config=<span style="color:blue">0xFE</span>; ''// <span style="text-decoration:overline">Reset</span> = I/O-Pin''<br />
<br />
Der ELF-Loader vom oben angegebenen '''avrpp''' berücksichtigt diese Besonderheit.<br />
<br />
==== avr-gcc-Fehler bei ATtiny4 und ATtiny5 ====<br />
<br />
Verwendet man<br />
<br />
#include <avr/signature.h><br />
<br />
verweigert '''avrpp''' die Zusammenarbeit mit dem Chip, weil die Signatur nicht passt. Hier liegt der Fehler in den Kopfdateien <tt>avr/tn4.h</tt> und <tt>avr/tn5.h</tt>, dort sind die Signaturbytes tatsächlich falsch eingetragen.<br />
Vielleicht liest das jemand vom avr-gcc-Team und packt das Problem an der Wurzel, statt selbst die Dateien korrigieren zu müssen.<br />
<br />
=== USB-Hardware ===<br />
<br />
Das Verschwinden von Parallelports stellt die größte Hürde für Bastel-Programmiergeräte dar.<br />
Programmiergeräte mit USB leiden nur dann nicht unter dem Henne-Ei-Problem, wenn der verwendete USB-Mikrocontroller bereits ab Fabrik einen USB-Urlader enthält. Immerhin löst USB das Problem der sonst erforderlichen zusätzlichen Stromversorgung.<br />
<br />
Es scheint kein Bastel-USB-Programmiergerät zu geben, welches '''ISP''' ''und'' '''HVSP''' ''und'' '''HVPP''' ''und'' '''TPI''' kann! '''TPI''' sowohl in Niedervolt- als auch Hochvolt-Ausprägung. Deshalb habe ich hier ein [https://www-user.tu-chemnitz.de/~heha/basteln/pg/avrpp#2 nachbaufähiges Muster] entwickelt. Es basiert auf ATmega16U2, der bereits einen Urlader mitbringt.<br />
<br />
Derzeit funktioniert TPI noch nicht. Der Gerätezugriff darauf erfolgt noch nicht mit avrpp.exe sondern <tt>avrdude -c stk500</tt> bzw. <tt>stk500pp</tt> bzw. <tt>stk500hvsp</tt>. Unterstützung für PIC ist ebenfalls vorgesehen, indem die Programmierspannung einstellbar ist. (Das PIC-Programmierinterface ist identisch zu TPI, bloß ein anderer Name und ein anderes Protokoll.)<br />
<br />
=== Betrieb mit SMD-Clip ===<br />
<br />
Beim Betrieb dieses Programmiergerätes in Verbindung mit einem 8-poligen SMD-Clip zur Programmierung von '''ATtiny<i>X</i>5''' (SU und SSU = breites und normales SMD-Gehäuse mit '''e''' = 1,27 mm) versagt bereits das Auslesen der Device-ID-Bytes, und der Chip wird nicht erkannt.<br />
Auch das Drosseln der Programmiergeschwindigkeit (bspw. mit '''-i10''') hilft nicht dagegen.<br />
Ursache sind gegenseitige Störungen auf den vier Datenleitungen, die vom Mikrocontroller selbst verursacht werden und über die Leitungslänge von nur 15 cm nicht mehr genügend von den Widerständen auf dem Programmerboard bedämpft werden.<br />
Dies führt letztlich zu zusätzlichen Taktflanken auf '''SCI = PB3'''.<br />
<br />
Abhilfe schafft ein '''Kondensator 100 pF''' zwischen '''Pin 2 = SCI = PB3''' und '''Pin 4 = GND''' ''direkt am zu programmierenden Mikrocontroller''.<br />
<small>Alternativ ein '''Kondensator 4,7 nF''' zwischen '''Pin 7 = PB2 = SDO''' und '''Pin 4 = GND''', ebenfalls ''direkt am zu programmierenden Mikrocontroller''.<br />
Andere versuchsweise Kondensatoren, insbesondere zwischen '''Pin 8 = U<sub>CC</sub>''' und '''Pin 4 = GND''' brachten keinen Erfolg.</small><br />
<br />
Dasselbe Problem wird vermutlich auch bei anderen 8-poligen ATtinys und beim Verlängern mit 14-poligen '''ATtiny<i>X</i>4''' auftreten, da gleicher Programmieralgorithmus: „HVSP“ = Hochvolt-serielle Programmierung.<br />
<br />
Es ist davon auszugehen, dass eine geeignete Terminierung auf der Programmer-Seite (bspw. Serienwiderstände 100 Ω statt 1 kΩ) das Problem ebenfalls und besser löst.<br />
<br />
===siehe auch===<br />
[http://xray37.de/?Bastelbuch:Lima-SDR:RX Miniatur-Version von ElmChans HV-Programmer]<br />
<br />
[[AVR In System Programmer]]<br />
<br />
[[Kategorie:AVR-Programmer und -Bootloader]]<br />
[[Kategorie:AVR-Boards]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR_HV-Programmer&diff=107236AVR HV-Programmer2025-01-23T09:38:42Z<p>Heha: /* Software, auch für ATtiny4..10, also TPI */</p>
<hr />
<div>Ein "Hochspannungs"-Programmierer für AVR legt eine Spannung von +12V an den Reset-Eingang. Damit lassen sich auch Fusebits programmieren, die mit dem normalen ISP-Programmer nicht zugänglich sind.<br />
<br />
Zu unterscheiden sind das High Voltage Serial Programming ([http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/AVRDragon/AVRDragon_HVSP_Description.htm HVSP]) und das Parallel Programming ([http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/AVRDragon/AVRDragon_PP_Description.htm PP]). Welche Methode(n) ein AVR unterstützt, steht im jeweiligen Datenblatt des AVRs.<br />
<br />
Bekannte HV Programmer sind:<br />
* [[STK500]] (HVSP, PP)<br />
* [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (HVSP, PP)<br />
* [http://www.der-hammer.info/hvprog/ HVProg von Tobias Hammer] (PP, HVSP)<br />
* [http://www.b-redemann.de/sp-hvprog1.shtml Bausatz und Anleitung von Bernhard Redemann] (PP)<br />
* [https://www.obdev.at/products/vusb/avrdoper.html AVR-Doper] High Voltage '''Serial''' Programmer (HVSP)<br />
* [http://mightyohm.com/blog/2008/09/arduino-based-avr-high-voltage-programmer/ Arduino-based AVR High Voltage Programmer] (PP)<br />
* [http://elm-chan.org/works/avrx/report_e.html '''Parallel''' HV-Programmer von ElmChan (ChaN)] (HVSP, PP)<br />
* [http://diy.elektroda.eu/atmega-fusebit-doctor-hvpp/?lang=en Atmega fusebit doctor] (HVSP, PP)<br />
* [https://guloshop.de/shop/Mikrocontroller-Programmierung/HVSP-Fusebit-Programmer::63.html HVSP Fusebit Programmer] (HVSP, auch stand-alone ohne PC nutzbar)<br />
* [http://homepage.hispeed.ch/peterfleury/avr-hvsp-fuse-restore.html ATtiny Fuse Restore] Anleitung für einen einfach aufzubauenden ATtiny Fuse Resetter mit AVR-GCC Software von Peter Fleury (HVSP)<br />
<br />
Hochvolt-Programmer sind ''nur dann'' als '''In-System'''-Programmer verwendbar, wenn die Schaltung mit den 12 V an der Resetleitung zurechtkommt und auch alle anderen Pins genügend hochohmig und ohne schaltungstechnische Nebenwirkungen (etwa einem Brückenkurzschluss) angeschlossen sind. Da dies bei der Menge anzuschließender Pins [im Vergleich zur Gesamtanzahl der Pins des Gehäuses] eher selten der Fall sein wird, werden die Chips fast immer „solo“ (sozusagen „Out-System“) gebrannt. Am ehesten bietet sich HVSP-ISP für 14-beinige SMD-AVRs an; dazu müssen in der Einsatzschaltung ggf. entsprechende Vorkehrungen getroffen werden.<br />
<br />
=== Ein Platinenlayout für ElmChans Hochvolt-Programmer ===<br />
<br />
Dieser benötigt einen PC mit Parallelport sowie eine externe Stromversorgung von 6..24 V=. USB-Parallel-Konverter (für Drucker) funktionieren ''nicht''. Vorteil: Ein Mikrocontroller wird nicht benötigt.<br />
<br />
Wie auch das Original beherrscht dieser PP (parallel programming) als auch HVSP (serial programming).<br />
Für den rein seriellen Gebrauch (HVSP der 8- und 14-Beiner) kann man auf den 74HC299 verzichten.<br />
<br />
Schaltplan im Eagle-Format, Bestückungspläne und Platinenlayout: [[Benutzer:Christoph kessler|Christoph Kessler]] <br />
<br />
ElmChans Konzept ist eine ausgesprochene „Billiglösung“, die 20-poligen AVRs bevorzugend, dem scheint eine einseitige Platine mit Drahtbrücken im Eagle-Light-Format 80×100 mm² angemessen. Jener verzichtet auf Spannungsregler; einen 78L05 hinzuzusetzen und das Ganze mit stabilisierten 12 V zu speisen sollte jedoch nicht allzu schwer fallen.<br />
<br />
Das Foto (unten) zeigt schon die „Luxusversion“, Teilbestückung ist entsprechend denkbar.<br />
<br />
'''Achtung, Schaltplanfehler!''' Die Bezeichnungen /AUTOFEED und /SELIN sind genau verkehrt herum.<br />
<br />
[[Media:AVR_HV_Programmer_Eagle.zip | Eagle board / schematic files]]<br />
<br />
[[Bild:Schematic.png|600px]]<br />
<br />
[[Bild:Components.png|600px]]<br />
<br />
[[Bild:AVR_HV_Programmer_Layout.png|600px]]<br />
<br />
[[Bild:AVR_HV_Programmer_Foto.jpg]]<br />
<br />
=== Software, auch für ATtiny4..10, also TPI ===<br />
<br />
Open-Source, für Windows und Linux, jeweils 32 und 64 Bit, winzige Echse-Größe, [http://www.tu-chemnitz.de/~heha/hs/avrpp.zip/ Download].<br />
Kann direkt ELF-Dateien laden, kein Umweg über <tt>avr-objcopy</tt> erforderlich.<br />
Kann EEPROM, Fuses und Lockbits „in einem Rutsch“ der (von-neumannisierten) Hex- oder ELF-Datei<br />
entnehmen und brennen.<br />
Sowie die Chip-Signatur aus der Datei (mit <tt>#include <avr/signature.h></tt> zu generieren) mit dem Chip vergleichen.<br />
Bei Verwendung einer ELF-Datei kann die Software die Chip-Signatur von der elf-Section '''.note.gnu.avr.deviceinfo''' ermitteln; <tt>#include <avr/signature.h></tt> ist dann nicht mehr erforderlich.<br />
Die Software kennt alle 8-Bit-AVRs.<br />
Unterstützt direkten (giveio.sys) als auch indirekten (InpOut32.dll) Portzugriff aufs Parallelport sowie eine wahlfreie Port(basis)adresse.<br />
Läuft von Windows 95 bis Windows 10 sowie Linux; ein PC mit Parallelport (auch als Steckkarte via PCI oder PCIexpress nachgerüstet) ist erforderlich. Parallelports an Docking-Stations funktionieren auch. USB-Parallel-Konverter (für alte Drucker) funktionieren nicht.<br />
<br />
Der sechsbeinige Schaltkreis im SOT23-Gehäuse ist wie folgt an die 8-polige Fassung anzuschließen:<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Pin der Fassung !! Pin des Controllers !! Signalname<br />
|-<br />
| 1 || 6 || <span style='text-decoration:overline'>RESET</span> = Programmierspannung<br />
|-<br />
| 2 || 3 || TPICLK (Takt)<br />
|-<br />
| 4 || 2 || GND (Bezugspotenzial)<br />
|-<br />
| 7 || 1 || TPIDATA (Daten, bidirektional)<br />
|-<br />
| 8 || 5 || 5P (geschaltet)<br />
|}<br />
<br />
Das Pin 4 des Controllers kann frei bleiben.<br />
<br />
==== Fuse bei ATtiny4..10 ====<br />
<br />
Diese Mikrocontroller haben laut Dokumentation keine Fuse(s), sondern '''Configuration Bits'''.<br />
avr-gcc trägt diesem Umstand „Rechnung“, dass <tt>#include &lt;avr/fuse.h&gt;</tt> nicht wie erwartet funktioniert: Die Configuration-Bits sollen laut Linker-Skript in der Sektion <tt>.config</tt> ankommen, mit der linearen Adresse 0x820000 (die gleiche wie <tt>.fuse</tt> für die übrigen AVRs).<br />
In die ELF-Datei setzt man ein einzelnes Configuration-Byte so:<br />
<br />
'''uint8_t __attribute__((section('''<span style="color:blue">".config"</span>''')))''' Config=<span style="color:blue">0xFE</span>; ''// <span style="text-decoration:overline">Reset</span> = I/O-Pin''<br />
<br />
Der ELF-Loader vom oben angegebenen '''avrpp''' berücksichtigt diese Besonderheit.<br />
<br />
==== avr-gcc-Fehler bei ATtiny4 und ATtiny5 ====<br />
<br />
Verwendet man<br />
<br />
#include <avr/signature.h><br />
<br />
verweigert '''avrpp''' die Zusammenarbeit mit dem Chip, weil die Signatur nicht passt. Hier liegt der Fehler in den Kopfdateien <tt>avr/tn4.h</tt> und <tt>avr/tn5.h</tt>, dort sind die Signaturbytes tatsächlich falsch eingetragen.<br />
Vielleicht liest das jemand vom avr-gcc-Team und packt das Problem an der Wurzel, statt selbst die Dateien korrigieren zu müssen.<br />
<br />
=== USB-Hardware ===<br />
<br />
Das Verschwinden von Parallelports stellt die größte Hürde für Bastel-Programmiergeräte dar.<br />
Programmiergeräte mit USB leiden nur dann nicht unter dem Henne-Ei-Problem, wenn der verwendete USB-Mikrocontroller bereits ab Fabrik einen USB-Urlader enthält. Immerhin löst USB das Problem der sonst erforderlichen zusätzlichen Stromversorgung.<br />
<br />
Es scheint kein Bastel-USB-Programmiergerät zu geben, welches '''ISP''' ''und'' '''HVSP''' ''und'' '''HVPP''' ''und'' '''TPI''' kann! '''TPI''' sowohl in Niedervolt- als auch Hochvolt-Ausprägung. Deshalb habe ich hier ein [https://www-user.tu-chemnitz.de/~heha/basteln/pg/avrpp#2 nachbaufähiges Muster] entwickelt. Es basiert auf ATmega16U2, der bereits einen Urlader mitbringt.<br />
<br />
Derzeit funktioniert TPI noch nicht. Der Gerätezugriff darauf erfolgt noch nicht mit avrpp.exe sondern <tt>avrdude -c stk500</tt> bzw. <tt>stk500pp</tt> bzw. <tt>stk500hvsp</tt>. Unterstützung für PIC ist ebenfalls vorgesehen, indem die Programmierspannung einstellbar ist. (Das PIC-Programmierinterface ist identisch zu TPI, bloß ein anderer Name und ein anderes Protokoll.)<br />
<br />
=== Betrieb mit SMD-Clip ===<br />
<br />
Beim Betrieb dieses Programmiergerätes in Verbindung mit einem 8-poligen SMD-Clip zur Programmierung von '''ATtiny<i>X</i>5''' (SU und SSU = breites und normales SMD-Gehäuse mit '''e''' = 1,27 mm) versagt bereits das Auslesen der Device-ID-Bytes, und der Chip wird nicht erkannt.<br />
Auch das Drosseln der Programmiergeschwindigkeit (bspw. mit '''-i10''') hilft nicht dagegen.<br />
Ursache sind gegenseitige Störungen auf den vier Datenleitungen, die vom Mikrocontroller selbst verursacht werden und über die Leitungslänge von nur 15 cm nicht mehr genügend von den Widerständen auf dem Programmerboard bedämpft werden.<br />
Dies führt letztlich zu zusätzlichen Taktflanken auf '''SCI = PB3'''.<br />
<br />
Abhilfe schafft ein '''Kondensator 100 pF''' zwischen '''Pin 2 = SCI = PB3''' und '''Pin 4 = GND''' ''direkt am zu programmierenden Mikrocontroller''.<br />
<small>Alternativ ein '''Kondensator 4,7 nF''' zwischen '''Pin 7 = PB2 = SDO''' und '''Pin 4 = GND''', ebenfalls ''direkt am zu programmierenden Mikrocontroller''.<br />
Andere versuchsweise Kondensatoren, insbesondere zwischen '''Pin 8 = U<sub>CC</sub>''' und '''Pin 4 = GND''' brachten keinen Erfolg.</small><br />
<br />
Dasselbe Problem wird vermutlich auch bei anderen 8-poligen ATtinys und beim Verlängern mit 14-poligen '''ATtiny<i>X</i>4''' auftreten, da gleicher Programmieralgorithmus: „HVSP“ = Hochvolt-serielle Programmierung.<br />
<br />
Es ist davon auszugehen, dass eine geeignete Terminierung auf der Programmer-Seite (bspw. Serienwiderstände 100 Ω statt 1 kΩ) das Problem ebenfalls und besser löst.<br />
<br />
===siehe auch===<br />
[http://xray37.de/?Bastelbuch:Lima-SDR:RX Miniatur-Version von ElmChans HV-Programmer]<br />
<br />
[[AVR In System Programmer]]<br />
<br />
[[Kategorie:AVR-Programmer und -Bootloader]]<br />
[[Kategorie:AVR-Boards]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=AVR_HV-Programmer&diff=107235AVR HV-Programmer2025-01-23T09:10:40Z<p>Heha: USB-Hardware</p>
<hr />
<div>Ein "Hochspannungs"-Programmierer für AVR legt eine Spannung von +12V an den Reset-Eingang. Damit lassen sich auch Fusebits programmieren, die mit dem normalen ISP-Programmer nicht zugänglich sind.<br />
<br />
Zu unterscheiden sind das High Voltage Serial Programming ([http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/AVRDragon/AVRDragon_HVSP_Description.htm HVSP]) und das Parallel Programming ([http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/AVRDragon/AVRDragon_PP_Description.htm PP]). Welche Methode(n) ein AVR unterstützt, steht im jeweiligen Datenblatt des AVRs.<br />
<br />
Bekannte HV Programmer sind:<br />
* [[STK500]] (HVSP, PP)<br />
* [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (HVSP, PP)<br />
* [http://www.der-hammer.info/hvprog/ HVProg von Tobias Hammer] (PP, HVSP)<br />
* [http://www.b-redemann.de/sp-hvprog1.shtml Bausatz und Anleitung von Bernhard Redemann] (PP)<br />
* [https://www.obdev.at/products/vusb/avrdoper.html AVR-Doper] High Voltage '''Serial''' Programmer (HVSP)<br />
* [http://mightyohm.com/blog/2008/09/arduino-based-avr-high-voltage-programmer/ Arduino-based AVR High Voltage Programmer] (PP)<br />
* [http://elm-chan.org/works/avrx/report_e.html '''Parallel''' HV-Programmer von ElmChan (ChaN)] (HVSP, PP)<br />
* [http://diy.elektroda.eu/atmega-fusebit-doctor-hvpp/?lang=en Atmega fusebit doctor] (HVSP, PP)<br />
* [https://guloshop.de/shop/Mikrocontroller-Programmierung/HVSP-Fusebit-Programmer::63.html HVSP Fusebit Programmer] (HVSP, auch stand-alone ohne PC nutzbar)<br />
* [http://homepage.hispeed.ch/peterfleury/avr-hvsp-fuse-restore.html ATtiny Fuse Restore] Anleitung für einen einfach aufzubauenden ATtiny Fuse Resetter mit AVR-GCC Software von Peter Fleury (HVSP)<br />
<br />
Hochvolt-Programmer sind ''nur dann'' als '''In-System'''-Programmer verwendbar, wenn die Schaltung mit den 12 V an der Resetleitung zurechtkommt und auch alle anderen Pins genügend hochohmig und ohne schaltungstechnische Nebenwirkungen (etwa einem Brückenkurzschluss) angeschlossen sind. Da dies bei der Menge anzuschließender Pins [im Vergleich zur Gesamtanzahl der Pins des Gehäuses] eher selten der Fall sein wird, werden die Chips fast immer „solo“ (sozusagen „Out-System“) gebrannt. Am ehesten bietet sich HVSP-ISP für 14-beinige SMD-AVRs an; dazu müssen in der Einsatzschaltung ggf. entsprechende Vorkehrungen getroffen werden.<br />
<br />
=== Ein Platinenlayout für ElmChans Hochvolt-Programmer ===<br />
<br />
Dieser benötigt einen PC mit Parallelport sowie eine externe Stromversorgung von 6..24 V=. USB-Parallel-Konverter (für Drucker) funktionieren ''nicht''. Vorteil: Ein Mikrocontroller wird nicht benötigt.<br />
<br />
Wie auch das Original beherrscht dieser PP (parallel programming) als auch HVSP (serial programming).<br />
Für den rein seriellen Gebrauch (HVSP der 8- und 14-Beiner) kann man auf den 74HC299 verzichten.<br />
<br />
Schaltplan im Eagle-Format, Bestückungspläne und Platinenlayout: [[Benutzer:Christoph kessler|Christoph Kessler]] <br />
<br />
ElmChans Konzept ist eine ausgesprochene „Billiglösung“, die 20-poligen AVRs bevorzugend, dem scheint eine einseitige Platine mit Drahtbrücken im Eagle-Light-Format 80×100 mm² angemessen. Jener verzichtet auf Spannungsregler; einen 78L05 hinzuzusetzen und das Ganze mit stabilisierten 12 V zu speisen sollte jedoch nicht allzu schwer fallen.<br />
<br />
Das Foto (unten) zeigt schon die „Luxusversion“, Teilbestückung ist entsprechend denkbar.<br />
<br />
'''Achtung, Schaltplanfehler!''' Die Bezeichnungen /AUTOFEED und /SELIN sind genau verkehrt herum.<br />
<br />
[[Media:AVR_HV_Programmer_Eagle.zip | Eagle board / schematic files]]<br />
<br />
[[Bild:Schematic.png|600px]]<br />
<br />
[[Bild:Components.png|600px]]<br />
<br />
[[Bild:AVR_HV_Programmer_Layout.png|600px]]<br />
<br />
[[Bild:AVR_HV_Programmer_Foto.jpg]]<br />
<br />
=== Software, auch für ATtiny4..10, also TPI ===<br />
<br />
Open-Source, [http://www.tu-chemnitz.de/~heha/hs/avrpp.zip/ Download].<br />
Kann direkt ELF-Dateien laden, kein Umweg über <tt>avr-objcopy</tt> erforderlich.<br />
Kann EEPROM, Fuses und Lockbits „in einem Rutsch“ der (von-neumannisierten) Hex- oder ELF-Datei<br />
entnehmen und brennen.<br />
Sowie die Chip-Signatur aus der Datei (mit <tt>#include <avr/signature.h></tt> zu generieren) mit dem Chip vergleichen.<br />
Bei Verwendung einer ELF-Datei kann die Software die Chip-Signatur von der elf-Section '''.note.gnu.avr.deviceinfo''' ermitteln; <tt>#include <avr/signature.h></tt> ist dann nicht mehr erforderlich.<br />
Die Software kennt alle 8-Bit-AVRs.<br />
Unterstützt direkten (giveio.sys) als auch indirekten (InpOut32.dll) Portzugriff aufs Parallelport sowie eine wahlfreie Port(basis)adresse.<br />
Läuft von Windows 95 bis Windows 10 sowie Linux; ein PC mit Parallelport (auch als Steckkarte via PCI oder PCIexpress nachgerüstet) ist erforderlich. Parallelports an Docking-Stations funktionieren auch. USB-Parallel-Konverter (für alte Drucker) funktionieren nicht.<br />
<br />
Der sechsbeinige Schaltkreis im SOT23-Gehäuse ist wie folgt an die 8-polige Fassung anzuschließen:<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Pin der Fassung !! Pin des Controllers !! Signalname<br />
|-<br />
| 1 || 6 || <span style='text-decoration:overline'>RESET</span> = Programmierspannung<br />
|-<br />
| 2 || 3 || TPICLK (Takt)<br />
|-<br />
| 4 || 2 || GND (Bezugspotenzial)<br />
|-<br />
| 7 || 1 || TPIDATA (Daten, bidirektional)<br />
|-<br />
| 8 || 5 || 5P (geschaltet)<br />
|}<br />
<br />
Das Pin 4 des Controllers kann frei bleiben.<br />
<br />
==== Fuse bei ATtiny4..10 ====<br />
<br />
Diese Mikrocontroller haben laut Dokumentation keine Fuse(s), sondern '''Configuration Bits'''.<br />
avr-gcc trägt diesem Umstand „Rechnung“, dass <tt>#include &lt;avr/fuse.h&gt;</tt> nicht wie erwartet funktioniert: Die Configuration-Bits sollen laut Linker-Skript in der Sektion <tt>.config</tt> ankommen, mit der linearen Adresse 0x820000 (die gleiche wie <tt>.fuse</tt> für die übrigen AVRs).<br />
In die ELF-Datei setzt man ein einzelnes Configuration-Byte so:<br />
<br />
'''uint8_t __attribute__((section('''<span style="color:blue">".config"</span>''')))''' Config=<span style="color:blue">0xFE</span>; ''// <span style="text-decoration:overline">Reset</span> = I/O-Pin''<br />
<br />
Der ELF-Loader vom oben angegebenen '''avrpp''' berücksichtigt diese Besonderheit.<br />
<br />
==== avr-gcc-Fehler bei ATtiny4 und ATtiny5 ====<br />
<br />
Verwendet man<br />
<br />
#include <avr/signature.h><br />
<br />
verweigert '''avrpp''' die Zusammenarbeit mit dem Chip, weil die Signatur nicht passt. Hier liegt der Fehler in den Kopfdateien <tt>avr/tn4.h</tt> und <tt>avr/tn5.h</tt>, dort sind die Signaturbytes tatsächlich falsch eingetragen.<br />
Vielleicht liest das jemand vom avr-gcc-Team und packt das Problem an der Wurzel, statt selbst die Dateien korrigieren zu müssen.<br />
<br />
=== USB-Hardware ===<br />
<br />
Das Verschwinden von Parallelports stellt die größte Hürde für Bastel-Programmiergeräte dar.<br />
Programmiergeräte mit USB leiden nur dann nicht unter dem Henne-Ei-Problem, wenn der verwendete USB-Mikrocontroller bereits ab Fabrik einen USB-Urlader enthält. Immerhin löst USB das Problem der sonst erforderlichen zusätzlichen Stromversorgung.<br />
<br />
Es scheint kein Bastel-USB-Programmiergerät zu geben, welches '''ISP''' ''und'' '''HVSP''' ''und'' '''HVPP''' ''und'' '''TPI''' kann! '''TPI''' sowohl in Niedervolt- als auch Hochvolt-Ausprägung. Deshalb habe ich hier ein [https://www-user.tu-chemnitz.de/~heha/basteln/pg/avrpp#2 nachbaufähiges Muster] entwickelt. Es basiert auf ATmega16U2, der bereits einen Urlader mitbringt.<br />
<br />
Derzeit funktioniert TPI noch nicht. Der Gerätezugriff darauf erfolgt noch nicht mit avrpp.exe sondern <tt>avrdude -c stk500</tt> bzw. <tt>stk500pp</tt> bzw. <tt>stk500hvsp</tt>. Unterstützung für PIC ist ebenfalls vorgesehen, indem die Programmierspannung einstellbar ist. (Das PIC-Programmierinterface ist identisch zu TPI, bloß ein anderer Name und ein anderes Protokoll.)<br />
<br />
=== Betrieb mit SMD-Clip ===<br />
<br />
Beim Betrieb dieses Programmiergerätes in Verbindung mit einem 8-poligen SMD-Clip zur Programmierung von '''ATtiny<i>X</i>5''' (SU und SSU = breites und normales SMD-Gehäuse mit '''e''' = 1,27 mm) versagt bereits das Auslesen der Device-ID-Bytes, und der Chip wird nicht erkannt.<br />
Auch das Drosseln der Programmiergeschwindigkeit (bspw. mit '''-i10''') hilft nicht dagegen.<br />
Ursache sind gegenseitige Störungen auf den vier Datenleitungen, die vom Mikrocontroller selbst verursacht werden und über die Leitungslänge von nur 15 cm nicht mehr genügend von den Widerständen auf dem Programmerboard bedämpft werden.<br />
Dies führt letztlich zu zusätzlichen Taktflanken auf '''SCI = PB3'''.<br />
<br />
Abhilfe schafft ein '''Kondensator 100 pF''' zwischen '''Pin 2 = SCI = PB3''' und '''Pin 4 = GND''' ''direkt am zu programmierenden Mikrocontroller''.<br />
<small>Alternativ ein '''Kondensator 4,7 nF''' zwischen '''Pin 7 = PB2 = SDO''' und '''Pin 4 = GND''', ebenfalls ''direkt am zu programmierenden Mikrocontroller''.<br />
Andere versuchsweise Kondensatoren, insbesondere zwischen '''Pin 8 = U<sub>CC</sub>''' und '''Pin 4 = GND''' brachten keinen Erfolg.</small><br />
<br />
Dasselbe Problem wird vermutlich auch bei anderen 8-poligen ATtinys und beim Verlängern mit 14-poligen '''ATtiny<i>X</i>4''' auftreten, da gleicher Programmieralgorithmus: „HVSP“ = Hochvolt-serielle Programmierung.<br />
<br />
Es ist davon auszugehen, dass eine geeignete Terminierung auf der Programmer-Seite (bspw. Serienwiderstände 100 Ω statt 1 kΩ) das Problem ebenfalls und besser löst.<br />
<br />
===siehe auch===<br />
[http://xray37.de/?Bastelbuch:Lima-SDR:RX Miniatur-Version von ElmChans HV-Programmer]<br />
<br />
[[AVR In System Programmer]]<br />
<br />
[[Kategorie:AVR-Programmer und -Bootloader]]<br />
[[Kategorie:AVR-Boards]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=LED-%22Birnen%22&diff=107154LED-"Birnen"2024-10-30T13:30:34Z<p>Heha: Weißraum weg</p>
<hr />
<div>Dieser Beitrag beschreibt Aufbau und Funktion von [[LED]]-basierten Leuchtmitteln (LED-Lampen), umgangssprachlich auch manchmal als '''"LED-Birnen"''' bezeichnet.<br />
<br />
== Einleitung ==<br />
Anstelle von Glühlampen werden heutzutage nahezu ausschließlich LED-„Birnen“ benutzt. Im Vergleich zu den Anfang des Jahrtausends eingesetzten Kompaktleuchtstofflampen (Quecksilberdampf-Niederdrucklampe) erreichen sie ein noch höheres Energiesparpotenzial ohne Problemabfall zu sein. Dabei erreichen sie die volle Helligkeit sofort nach dem Einschalten, genauso wie Metalldraht-Glühlampen.<br />
Dabei dominieren Bauformen, die auf leichte Fertigung optimiert sind (plane Leiterplatte und Lichtstreukappe). Für repräsentativen Einsatz (sichtbare Birne) gibt es sogenannte Filamentlampen, deren LED-Nacktchips dicht an dicht auf ein Keramiksubstrat gebondet sind.<br />
<br />
== Vergleich mit anderen Leuchtmitteln ==<br />
Auf den Packungen der Hersteller sind sowohl bei Kompaktleuchtstofflampen, als auch bei LED-Birnen sehr optimistische Werte für die Lebensdauer und die Helligkeit angegeben. <br />
<br />
Seit 1. September 2013 ist die [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2012:342:0001:0022:DE:PDF DIM II – EU 1194/2012 EU Verordnung] in Kraft, die gewisse Mindestanforderungen an die angegeben Werte gibt. Die Anforderungen werden schrittweise in 3 Stufen verschärft: <br />
- Stufe 1: 1. September 2013, <br />
- Stufe 2: 1. September 2014<br />
- Stufe 3: 1. September 2016<br />
<br />
Die Einhaltung wird durch Marktaufsichtsbehörden zu kontrollieren; Man kann sich nur selber überlegen ob eher die Marken oder Noname-Hersteller sich daran halten werden.<br />
<br />
=== Lebensdauervergleich===<br />
Kompaktleuchtstofflampen werden gerne mit bis zu 10.000h - LED-Lampen sogar mit bis zu 50.000h angegeben. <br />
<br />
Für LED Lampen fordert die DIM II eine maximale Frühausfallrate von 5% nach 1000h und eine maximale Ausfallrate von 10% nach 6000h. (ab Stufe 1)<br />
<br />
Kompaktleuchtstofflampen dürfen maximale 5% Frühausfallrate nach 500h haben und nach 6000h dürfen maximal 50% ausgefallen sein. (Stufe 1; Stufe 3: 70%)<br />
<br />
Ein weiterer Punkt ist die alterungsbedingte Lichtstromabnahme: Nach der Richtlinie müssen für Kompaktleuchtstofflampen nach 2000h noch 80% (Stufe 2) bzw 83% nach 2000h und 70% nach 6000h (Stufe 3)<br />
<br />
LEDs müssen nach 6000h noch mindestens 80% Lichtstrom haben. (Stufe 2)<br />
<br />
Zum Vergleich: 50% der Glühlampen müssten >1000h (Stufe 1), 2000h (Stufe 2) bzw. für Kleinspannungslampen ab Stufe 3 4000h leben.<br />
Dabei müssen sie bei 3/4 der obigen Lebensdauerforderung noch mindestens 80% der Helligkeit haben. Frühausfallraten wären <5% bei 200h.<br />
Wären, da bekannterweise die Glühlampen die Anforderungen <br />
<br />
=== Leistungsvergleich===<br />
<br />
Nach der DIM II ist es vorgeschrieben, dass die Lampen oder die Verpackung den Lichtstromwert in Lumen ausweisen. Damit werden die Leuchtmittel direkt vergleichbar in Punkto Helligkeit. Zusätzlich dürfen die Äquivalenzwerte angegeben werden, wobei die Umrechnung vom Lichtstrom vorgegeben ist. In der Regel benötigen hier dann LED-Lampen "mehr" Lumen als herkömmliche Glühlampen um die selbe Äquivalenzleistung zu haben.<br />
<br />
Beispiel: eine GU20 40D 35W Halogen hat ca. 140lm. Die selbe Lichtmenge reicht nur für das Labeln von 25W (Äquivalent). 35W würden 230lm brauchen. (Beispiel von [http://www.lighting.philips.com/pwc_li/main/led/assets/final%20dim2-philips_presentation.pdf hier, Seite 8])<br />
<br />
Im direkten Vergleich ist der Lichstrom sinnvoller, da hier die Augenempfindlichkeit schon berücksichtigt ist.<br />
<br />
=== Farbwiedergabe- und Lichtfarbenvergleich ===<br />
<br />
Auch Anforderungen an die Farbwiedergabe und an die Lichtfarbe werden in der DIM 2 formuliert:<br />
<br />
==== Farbwiedergabe ====<br />
<br />
Glühlampen haben per Definition einen Farbwiedergabewert Ra=100.<br />
Für LED und Kompaktleuchtstofflampen sind die Mindestanforderungen Ra>85 (bzw. Ra>65 für Aussen- oder Industrieanwendungen). Gute Lampen gibt es aber auch mit Ra>90.<br />
<br />
==== Lichtfarbe ====<br />
<br />
Auch die [https://de.wikipedia.org/wiki/Farbtemperatur Lichtfarbe] muss angegeben werden. Hier ist die Einheit Kelvin und je kleiner der Wert desto "wärmer" das Licht. <br />
<br />
Normalerweise bekommt man hier nur "warmweiss" oder 3000K. <br />
Damit sollten die Zeiten vorbei sein wo man vom Chinamann eine 8000K LED-Lampe als warmweiss verkauft bekommt und dann sich über das blaue Licht wundert.<br />
<br />
Bei LEDs darf maximale Farbabweichung darf hier nicht mehr als 6 [http://fastvoice.net/2013/09/18/farbkonsistenz-macadam-sdcm-wie-unterschiedlich-leuchten-leds/ Schwellwerteinheiten] sein. Der Wert sollte angegeben sein, gut Lampen erreichen hier weniger als 3 Schwellwerteinheiten.<br />
<br />
=== Vor- und Nachteile der LED-Lampen ===<br />
<br />
LED-Lampen haben einige Vorteile gegenüber den Kompaktleuchtstofflampen und vor allem gegenüber den Glühfadenlampen: <br />
<br />
* Die Energieeffizienz ist in der Regel höher als bei Kompaktleuchststofflampen.<br />
* Die Kosteneffizienz ist bei einfachen Ausführungen ähnlich gut.<br />
* Die Lichtfarbe bzw. Farbtemperatur der LED-Lampe ist flexibler und kann auf Wunsch der Glühfadenlampenfarbe besser angepasst werden. Dazu gibt es kaltweiße, warmweiße und auch farbige Ausführungen.<br />
* Sie enthalten keine leicht freisetzbaren Giftstoffe wie Quecksilber.<br />
* Erreichen bereits nach wenigen Millisekunden nach dem Einschalten die volle Leuchtkraft.<br />
* Können eine sehr lange Lebensdauer haben (meist >= 30000 Stunden).<br />
* Sind nach Lebensende „nur“ als Elektroschrott zu entsorgen — kein Problemabfall wie Energiesparlampen.<br />
<br />
Jedoch gibt es auch einige Nachteile:<br />
<br />
* bei birnenähnlichen Designs und höheren Leistungen höherer Beschaffungspreis<br />
* Ähnlich wie bei ESLs befinden sich sehr viel billige Produkte am Markt, bei denen die Elektronik rasch kaputt geht.<br />
* schlechterer Farbwiedergabeindex R<sub>a</sub> = 80-95 (Glühbirne als Referenz R<sub>a</sub> = 100)<br />
* Bei Billigprodukten oftmals EMV-Probleme (Störungen im Kurzwellenbereich sowie bei DAB+)<br />
* Sollten nicht in Leuchten verwendet werden, bei denen eine Keramikfassung darauf hindeutet, dass der Sockel heiß werden darf. Anders als die extrem hitzebeständigen Glühlampen sollte der Sockel einer LED-Lampe möglichst kühl bleiben. Daher muss man bei einer liebgewonnenen Leuchte ggf. konstruktive Maßnahmen zur Wärmeabführung treffen, ''trotz'' der viel geringeren Wärmeabgabe von LED-Lampen<br />
* Problematischer Einsatz in Feuchträumen (Keller, Brunnen, unterirdische Anlagen bspw. der Wasserver- und Entsorgung, Schwimmbad, Tropen — ''nicht'' das heimische Bad): Ersatz durch Kleinspannung erspart empfindliche Elektronik im Feuchtbereich<br />
<br />
=== Kostenvergleich von Energiesparlampen ===<br />
[[Datei:Kostenvergleich-led-esl-birnen.jpg|left|300px|Kostenvergleich]]<br />
<br />
Die Grafik zeigt 3 Fälle von Kostenrechnungen für konventionelle Glühlampen, Kompaktleuchtstofflampe (als ESL bezeichnet) und LED-Lampen.<br />
<br />
Berechnet werden jeweils die beiden Extremfälle einer Lampe mit niedrigem Preis und hoher Lebensdauer (günstiger Fall) und einer "Montagslampe", die schnell kaputt geht, trotz hohen Preises. Daraus wird ein wahrscheinlichster Mittelwert (geometrische Mitte) - einmal für geringe und einmal für starke Nutzung gebildet.<br />
<br />
Aufgeführt ist auch die Unterscheidung der privaten und geschäftlichen Nutzung, bei der die Beschaffungs- und Wartungszeiten viel stärker zu Buche schlagen, da ein Angestellter bezahlt werden muss. Hier zeigt sich der Vorteil der langen Nutzungsdauer der LED-Lampen besonders deutlich.<br />
<br />
Es zeigt sich auch, dass Privatnutzer durchaus noch einen geringen Sparvorteil haben können, wenn sie auf LED-Lampen umrüsten.<br />
<br />
Excel für eigene Berechnungen: [http://www.mikrocontroller.net/wikifiles/0/09/Lampenrechner.xls Lampenvergleichsrechner]<br />
<br />
Externer Link auf Excel:<br />
[http://shop.bioledex.de/files/BIOLEDEX-LED-Stromkosten-Rechner.xls Stromkostenrechner]<br />
<br />
== Bauformen ==<br />
=== Hochvolt-LED-Lampen===<br />
<br />
Moderne Lampen mit einer Leistung über 5 W enthalten einen Gleichrichter, eine simple elektronische Strombegrenzung sowie eine Kette von LEDs mit einer Gesamtflussspannung von typisch 200 V.<br />
Die wie Einzelchips aussehenden SMD-LEDs enthalten oftmals mehrere LEDs in Reihe.<br />
Zudem ist in jedem der SMD-LED eine „Crowbar“ genannte Schaltung aus Z-Diode und Thyristor enthalten, die bei Ausfall (=Unterbrechung) einer Leuchtdiode das Bauteil elektrisch überbrückt, sodass die Kette weiter leuchtet.<br />
Von Vorteil dieses Designs ist das Fehlen von Funkstörungen.<br />
Nachteil dieses Designs ist 100-Hz-Flimmern (ungünstig für Kinos) und eine stark nichtsinusförmige Stromaufnahme.<br />
Auch der Wirkungsgrad ist nicht gerade üppig.<br />
Gesehen in LED-Panels für Außenbeleuchtung.<br />
<br />
Mit nur einen kleinen Speicherdrossel kommen Designs aus, die mit einem Hochsetzsteller einen sinusförmigen Strom durch eine LED-Kette mit einer Gesamtflussspannung von 400 V einprägen. Das 100-Hz-Flimmern ist wesentlich softer. Ein Netzfilter muss die Funkstörungen des Hochsetzstellers unterdrücken.<br />
<br />
Für exaktes Gleichlicht ist ein weiterer Energiespeicher nötig, der 10 ms überbrückt. Das ist typischerweise ein Elektrolytkondensator.<br />
<br />
=== Niederspannungs-LED-Lampen===<br />
==== Halogenersatzlampen ====<br />
Üblicherweise werden Niederspannungs-LED-Lampen an einem dezentralen Transformator betrieben, wie z.B mit 24V. Mit einer geeigneten Vorschaltung zur Spannungsherabsetzung im Lampengehäuse, sind sie auch indirekt an 230V-Netzen benutzbar.<br />
<br />
==== Betrieb von Standard-LEDs an 230V ====<br />
[[Datei:led_230v.png|left|300px|230V-Vorschaltung]]<br />
Mit der nebenstehenden Schaltung besteht die Möglichkeit, eine normale LED direkt an 230V anzuschließen. Diese Schaltung funktioniert so, dass die Spannung mittels Z-Dioden begrenzt wird; in diesem Fall auf 30V. Diese sind deshalb wichtig, weil die Gleichrichtdioden für hohen Frequenzanteile als Kapazität wirken und der Elko diese nicht aufnehmen kann, wodurch sie direkt auf die LEDs wirken würden. Gfs sollte dem Elko noch eine keramischer Kondensator beigefügt werden.<br />
{{Absatz}}<br />
<br />
[[Datei:Led an 220V.png|left|300px|230V-Schaltung]]<br />
Statt eines Gleichrichters, kann auch eine Antiparallelschaltung von LEDs verwendet werden. Auch dabei werden beide Halbwellen genutzt. Die Ausfallwahrscheinlichkeit ist geringer, weil weniger Bauteile und vor allem kein Elko genutzt wird. Allerdings muss die Schaltung genau dimensioniert werden, d.h. die strombegrenzende Wirkung des Kondensators ist sehr wichtig. Daher werden zur Sicherheit einige in Serie geschaltet, um das Problem der Alterung oder Defektbildung zu minimieren. Die LEDs leuchten bei dieser Schaltungsform aber etwas dunkler als oben, weil kein konstanter Strom fliessen kann und man mit Rücksicht auf die Lebensdauer der LEDs nicht einfach die Spannung so erhöhen kann, dass der Effektivwert erreicht wird.<br />
{{Absatz}}<br />
<br />
<br />
{{warnung|Spannungen ab 60V sind lebensgefährlich!}}<br />
<br />
== Funktion einer LED-Lampe am Beispiel==<br />
von [[Benutzer:Didi34]]<br />
=== Aufbau ===<br />
[[Datei:aufbau.JPG|left|300px]]<br />
Ich beschreibe in diesem Beitrag den Aufbau eines 4W Philips LED-Leuchtmittels mit E-14 Sockel. Über dem LED-Chip befindet sich ein Glaskolben, der in den weißen Kunststoffsockel geklebt ist. Der Glaskolben ist aus Milchglas, dies dient als Diffusor. Um näher in die Lampe zu kommen, muss der Glaskolben abgenommen werden.<br />
{{Absatz}}<br />
<br />
[[Datei:sockel.JPG|left|300px]]<br />
Nun sieht man den LED-Chip in der Mitte der Lampe. Über dem Chip befindet sich eine weitere Abdeckung, die abgenommen werden muss. <br />
{{Absatz}}<br />
<br />
[[Datei:chip_anschluss.JPG|left|300px]]<br />
Auf dem nächsten Bild sieht man die Aluminium-Platine, worauf sich der LED-Chip befindet. Die beiden Drähte stellen die Versorgung der LED (300V Gleichspannung) dar. Die Platine besteht aus dem Basismaterial Aluminium, um eine bessere Kühlung zu erreichen.<br />
{{Absatz}}<br />
<br />
=== Innenleben ===<br />
[[Datei:platine_unten.jpg|left|300px]]<br />
Im Inneren der LED-Lampe befindet sich folgende Platine:<br />
<br />
Man sieht nun auf der Platine eine kleine Gleichrichterschaltung. Die Anschlüsse Blau und Braun sind Neutralleiter(N) und Außenleiter(L1) unserer Energieversorgung mit 230V Wechselspannung.<br />
{{Absatz}}<br />
<br />
[[Datei:platine_oben.JPG|left|300px]]<br />
<br />
Die beiden Drähte Rot(+) und Schwarz(-) sind die Ausgänge der Schaltung. Sie führen eine Gleichspannung von 300V und werden direkt an der Aluminiumplatine der LED angeschlossen, da die LED für diese Spannung ausgelegt ist. Näheres zur Schaltung:<br />
[http://www.mikrocontroller.net/articles/LED-Gl%C3%BChbirne#Schaltung/ Schaltung]<br />
{{Absatz}}<br />
<br />
==== LED-Chip ====<br />
[[Datei:ledchip_dunkel.jpg|left|300px]]<br />
Der LED-Chip besteht aus mehreren in Serie geschalteten LEDs. Die in Serie geschalteten LEDs sind um eine warm-weiße Farbe zu erreichen teils rot und teils weiß. Die LED ist für 300V DC ausgelegt. Auf dem LED-Chip befinden sich zwei weiße und zwei rote LED-Arrays. Die gelbe Schicht der weißen LEDs ist ein Phosphor (also ein Leuchtstoff) der aus dem blauen Licht der Kristalle weißes Licht macht.<br />
{{Absatz}}<br />
<br />
[[Datei:ledchip_hell.jpg|left|300px]]<br />
Eine weitere Ansicht des LED-Chips im Betrieb unter Spannung.<br />
{{Absatz}}<br />
<br />
==== Schaltung ====<br />
[[Datei:netzteilschaltung.png|left|300px|Einfache Gleichrichterschaltung für LEDs]]<br />
Für den Betieb an Netzspannung wird ein Kondensatornetzteil verwendet, welches aus 230V AC 300V DC macht. Die Schaltung ist mit 1A abgesichert. {{Absatz}}<br />
<br />
=== Messung ===<br />
[[Datei:messung.bmp|left|300px|Messung]]<br />
Es wurde zwischen dem roten und schwarzen Ausgang der oben genannten Schaltung gemessen. CH1 roter Anschluss CH2 schwarzer Anschluss.<br />
Die rote Linie am Oszillogramm ist Die Spannung zwischen den beiden Drähten (CH1-CH2).<br />
{{Absatz}}<br />
<br />
{{warnung|Spannungen ab 60V sind lebensgefährlich!}}<br />
<br />
== Interne Links ==<br />
* [[LED]]<br />
<br />
== Externe Links ==<br />
<br />
* [http://de.wikipedia.org/wiki/Leuchtdiode Wikipedia: LED]<br />
* [http://de.wikipedia.org/wiki/Kompaktleuchtstofflampe Wikipedia: Kompaktleuchtstofflampe]<br />
* [http://de.wikipedia.org/wiki/Glühlampe Wikipedia: Glühbirne ]<br />
* [http://de.wikipedia.org/wiki/Kondensatornetzteil Wikipedia: Kondensatornetzteil]<br />
* [http://de.wikipedia.org/wiki/Energiesparende Leuchtmittel Wikipedia: Energiesparende Leuchtmittel allgemein]<br />
<br />
<br />
[[Kategorie:Bauteile]]<br />
[[Kategorie:Displays und Anzeigen]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=LED-%22Birnen%22&diff=107153LED-"Birnen"2024-10-30T13:27:21Z<p>Heha: fehlen noch Schaltpläne und Beispiele</p>
<hr />
<div>Dieser Beitrag beschreibt Aufbau und Funktion von [[LED]]-basierten Leuchtmitteln (LED-Lampen), umgangssprachlich auch manchmal als '''"LED-Birnen"''' bezeichnet.<br />
<br />
== Einleitung ==<br />
Anstelle von Glühlampen werden heutzutage nahezu ausschließlich LED-„Birnen“ benutzt. Im Vergleich zu den Anfang des Jahrtausends eingesetzten Kompaktleuchtstofflampen (Quecksilberdampf-Niederdrucklampe) erreichen sie ein noch höheres Energiesparpotenzial ohne Problemabfall zu sein. Dabei erreichen sie die volle Helligkeit sofort nach dem Einschalten, genauso wie Metalldraht-Glühlampen.<br />
Dabei dominieren Bauformen, die auf leichte Fertigung optimiert sind (plane Leiterplatte und Lichtstreukappe). Für repräsentativen Einsatz (sichtbare Birne) gibt es sogenannte Filamentlampen, deren LED-Nacktchips dicht an dicht auf ein Keramiksubstrat gebondet sind.<br />
<br />
== Vergleich mit anderen Leuchtmitteln ==<br />
Auf den Packungen der Hersteller sind sowohl bei Kompaktleuchtstofflampen, als auch bei LED-Birnen sehr optimistische Werte für die Lebensdauer und die Helligkeit angegeben. <br />
<br />
Seit 1. September 2013 ist die [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2012:342:0001:0022:DE:PDF DIM II – EU 1194/2012 EU Verordnung] in Kraft, die gewisse Mindestanforderungen an die angegeben Werte gibt. Die Anforderungen werden schrittweise in 3 Stufen verschärft: <br />
- Stufe 1: 1. September 2013, <br />
- Stufe 2: 1. September 2014<br />
- Stufe 3: 1. September 2016<br />
<br />
Die Einhaltung wird durch Marktaufsichtsbehörden zu kontrollieren; Man kann sich nur selber überlegen ob eher die Marken oder Noname-Hersteller sich daran halten werden.<br />
<br />
=== Lebensdauervergleich===<br />
Kompaktleuchtstofflampen werden gerne mit bis zu 10.000h - LED-Lampen sogar mit bis zu 50.000h angegeben. <br />
<br />
Für LED Lampen fordert die DIM II eine maximale Frühausfallrate von 5% nach 1000h und eine maximale Ausfallrate von 10% nach 6000h. (ab Stufe 1)<br />
<br />
Kompaktleuchtstofflampen dürfen maximale 5% Frühausfallrate nach 500h haben und nach 6000h dürfen maximal 50% ausgefallen sein. (Stufe 1; Stufe 3: 70%)<br />
<br />
Ein weiterer Punkt ist die alterungsbedingte Lichtstromabnahme: Nach der Richtlinie müssen für Kompaktleuchtstofflampen nach 2000h noch 80% (Stufe 2) bzw 83% nach 2000h und 70% nach 6000h (Stufe 3)<br />
<br />
LEDs müssen nach 6000h noch mindestens 80% Lichtstrom haben. (Stufe 2)<br />
<br />
Zum Vergleich: 50% der Glühlampen müssten >1000h (Stufe 1), 2000h (Stufe 2) bzw. für Kleinspannungslampen ab Stufe 3 4000h leben.<br />
Dabei müssen sie bei 3/4 der obigen Lebensdauerforderung noch mindestens 80% der Helligkeit haben. Frühausfallraten wären <5% bei 200h.<br />
Wären, da bekannterweise die Glühlampen die Anforderungen <br />
<br />
=== Leistungsvergleich===<br />
<br />
Nach der DIM II ist es vorgeschrieben, dass die Lampen oder die Verpackung den Lichtstromwert in Lumen ausweisen. Damit werden die Leuchtmittel direkt vergleichbar in Punkto Helligkeit. Zusätzlich dürfen die Äquivalenzwerte angegeben werden, wobei die Umrechnung vom Lichtstrom vorgegeben ist. In der Regel benötigen hier dann LED-Lampen "mehr" Lumen als herkömmliche Glühlampen um die selbe Äquivalenzleistung zu haben.<br />
<br />
Beispiel: eine GU20 40D 35W Halogen hat ca. 140lm. Die selbe Lichtmenge reicht nur für das Labeln von 25W (Äquivalent). 35W würden 230lm brauchen. (Beispiel von [http://www.lighting.philips.com/pwc_li/main/led/assets/final%20dim2-philips_presentation.pdf hier, Seite 8])<br />
<br />
Im direkten Vergleich ist der Lichstrom sinnvoller, da hier die Augenempfindlichkeit schon berücksichtigt ist.<br />
<br />
=== Farbwiedergabe- und Lichtfarbenvergleich ===<br />
<br />
Auch Anforderungen an die Farbwiedergabe und an die Lichtfarbe werden in der DIM 2 formuliert:<br />
<br />
==== Farbwiedergabe ====<br />
<br />
Glühlampen haben per Definition einen Farbwiedergabewert Ra=100.<br />
Für LED und Kompaktleuchtstofflampen sind die Mindestanforderungen Ra>85 (bzw. Ra>65 für Aussen- oder Industrieanwendungen). Gute Lampen gibt es aber auch mit Ra>90.<br />
<br />
==== Lichtfarbe ====<br />
<br />
Auch die [https://de.wikipedia.org/wiki/Farbtemperatur Lichtfarbe] muss angegeben werden. Hier ist die Einheit Kelvin und je kleiner der Wert desto "wärmer" das Licht. <br />
<br />
Normalerweise bekommt man hier nur "warmweiss" oder 3000K. <br />
Damit sollten die Zeiten vorbei sein wo man vom Chinamann eine 8000K LED-Lampe als warmweiss verkauft bekommt und dann sich über das blaue Licht wundert.<br />
<br />
Bei LEDs darf maximale Farbabweichung darf hier nicht mehr als 6 [http://fastvoice.net/2013/09/18/farbkonsistenz-macadam-sdcm-wie-unterschiedlich-leuchten-leds/ Schwellwerteinheiten] sein. Der Wert sollte angegeben sein, gut Lampen erreichen hier weniger als 3 Schwellwerteinheiten.<br />
<br />
=== Vor- und Nachteile der LED-Lampen ===<br />
<br />
LED-Lampen haben einige Vorteile gegenüber den Kompaktleuchtstofflampen und vor allem gegenüber den Glühfadenlampen: <br />
<br />
* Die Energieeffizienz ist in der Regel höher als bei Kompaktleuchststofflampen.<br />
* Die Kosteneffizienz ist bei einfachen Ausführungen ähnlich gut.<br />
* Die Lichtfarbe bzw. Farbtemperatur der LED-Lampe ist flexibler und kann auf Wunsch der Glühfadenlampenfarbe besser angepasst werden. Dazu gibt es kaltweiße, warmweiße und auch farbige Ausführungen.<br />
* Sie enthalten keine leicht freisetzbaren Giftstoffe wie Quecksilber.<br />
* Erreichen bereits nach wenigen Millisekunden nach dem Einschalten die volle Leuchtkraft.<br />
* Können eine sehr lange Lebensdauer haben (meist >= 30000 Stunden).<br />
* Sind nach Lebensende „nur“ als Elektroschrott zu entsorgen — kein Problemabfall wie Energiesparlampen.<br />
<br />
Jedoch gibt es auch einige Nachteile:<br />
<br />
* bei birnenähnlichen Designs und höheren Leistungen höherer Beschaffungspreis<br />
* Ähnlich wie bei ESLs befinden sich sehr viel billige Produkte am Markt, bei denen die Elektronik rasch kaputt geht.<br />
* schlechterer Farbwiedergabeindex R<sub>a</sub> = 80-95 (Glühbirne als Referenz R<sub>a</sub> = 100)<br />
* Bei Billigprodukten oftmals EMV-Probleme (Störungen im Kurzwellenbereich sowie bei DAB+)<br />
* Sollten nicht in Leuchten verwendet werden, bei denen eine Keramikfassung darauf hindeutet, dass der Sockel heiß werden darf. Anders als die extrem hitzebeständigen Glühlampen sollte der Sockel einer LED-Lampe möglichst kühl bleiben. Daher muss man bei einer liebgewonnenen Leuchte ggf. konstruktive Maßnahmen zur Wärmeabführung treffen, ''trotz'' der viel geringeren Wärmeabgabe von LED-Lampen<br />
* Problematischer Einsatz in Feuchträumen (Keller, Brunnen, unterirdische Anlagen bspw. der Wasserver- und Entsorgung, Schwimmbad, Tropen — ''nicht'' das heimische Bad): Ersatz durch Kleinspannung erspart empfindliche Elektronik im Feuchtbereich<br />
<br />
=== Kostenvergleich von Energiesparlampen ===<br />
[[Datei:Kostenvergleich-led-esl-birnen.jpg|left|300px|Kostenvergleich]]<br />
<br />
Die Grafik zeigt 3 Fälle von Kostenrechnungen für konventionelle Glühlampen, Kompaktleuchtstofflampe (als ESL bezeichnet) und LED-Lampen.<br />
<br />
Berechnet werden jeweils die beiden Extremfälle einer Lampe mit niedrigem Preis und hoher Lebensdauer (günstiger Fall) und einer "Montagslampe", die schnell kaputt geht, trotz hohen Preises. Daraus wird ein wahrscheinlichster Mittelwert (geometrische Mitte) - einmal für geringe und einmal für starke Nutzung gebildet.<br />
<br />
Aufgeführt ist auch die Unterscheidung der privaten und geschäftlichen Nutzung, bei der die Beschaffungs- und Wartungszeiten viel stärker zu Buche schlagen, da ein Angestellter bezahlt werden muss. Hier zeigt sich der Vorteil der langen Nutzungsdauer der LED-Lampen besonders deutlich.<br />
<br />
Es zeigt sich auch, dass Privatnutzer durchaus noch einen geringen Sparvorteil haben können, wenn sie auf LED-Lampen umrüsten.<br />
<br />
Excel für eigene Berechnungen: [http://www.mikrocontroller.net/wikifiles/0/09/Lampenrechner.xls Lampenvergleichsrechner]<br />
<br />
Externer Link auf Excel:<br />
[http://shop.bioledex.de/files/BIOLEDEX-LED-Stromkosten-Rechner.xls Stromkostenrechner]<br />
<br />
<br />
{{Absatz}}<br />
<br />
== Bauformen ==<br />
=== Hochvolt-LED-Lampen===<br />
<br />
Moderne Lampen mit einer Leistung über 5 W enthalten einen Gleichrichter, eine simple elektronische Strombegrenzung sowie eine Kette von LEDs mit einer Gesamtflussspannung von typisch 200 V.<br />
Die wie Einzelchips aussehenden SMD-LEDs enthalten oftmals mehrere LEDs in Reihe.<br />
Zudem ist in jedem der SMD-LED eine „Crowbar“ genannte Schaltung aus Z-Diode und Thyristor enthalten, die bei Ausfall (=Unterbrechung) einer Leuchtdiode das Bauteil elektrisch überbrückt, sodass die Kette weiter leuchtet.<br />
Von Vorteil dieses Designs ist das Fehlen von Funkstörungen.<br />
Nachteil dieses Designs ist 100-Hz-Flimmern (ungünstig für Kinos) und eine stark nichtsinusförmige Stromaufnahme.<br />
Auch der Wirkungsgrad ist nicht gerade üppig.<br />
Gesehen in LED-Panels für Außenbeleuchtung.<br />
<br />
Mit nur einen kleinen Speicherdrossel kommen Designs aus, die mit einem Hochsetzsteller einen sinusförmigen Strom durch eine LED-Kette mit einer Gesamtflussspannung von 400 V einprägen. Das 100-Hz-Flimmern ist wesentlich softer. Ein Netzfilter muss die Funkstörungen des Hochsetzstellers unterdrücken.<br />
<br />
Für exaktes Gleichlicht ist ein weiterer Energiespeicher nötig, der 10 ms überbrückt. Das ist typischerweise ein Elektrolytkondensator.<br />
<br />
=== Niederspannungs-LED-Lampen===<br />
==== Halogenersatzlampen ====<br />
Üblicherweise werden Niederspannungs-LED-Lampen an einem dezentralen Transformator betrieben, wie z.B mit 24V. Mit einer geeigneten Vorschaltung zur Spannungsherabsetzung im Lampengehäuse, sind sie auch indirekt an 230V-Netzen benutzbar.<br />
<br />
==== Betrieb von Standard-LEDs an 230V ====<br />
[[Datei:led_230v.png|left|300px|230V-Vorschaltung]]<br />
Mit der nebenstehenden Schaltung besteht die Möglichkeit, eine normale LED direkt an 230V anzuschließen. Diese Schaltung funktioniert so, dass die Spannung mittels Z-Dioden begrenzt wird; in diesem Fall auf 30V. Diese sind deshalb wichtig, weil die Gleichrichtdioden für hohen Frequenzanteile als Kapazität wirken und der Elko diese nicht aufnehmen kann, wodurch sie direkt auf die LEDs wirken würden. Gfs sollte dem Elko noch eine keramischer Kondensator beigefügt werden.<br />
{{Absatz}}<br />
<br />
[[Datei:Led an 220V.png|left|300px|230V-Schaltung]]<br />
Statt eines Gleichrichters, kann auch eine Antiparallelschaltung von LEDs verwendet werden. Auch dabei werden beide Halbwellen genutzt. Die Ausfallwahrscheinlichkeit ist geringer, weil weniger Bauteile und vor allem kein Elko genutzt wird. Allerdings muss die Schaltung genau dimensioniert werden, d.h. die strombegrenzende Wirkung des Kondensators ist sehr wichtig. Daher werden zur Sicherheit einige in Serie geschaltet, um das Problem der Alterung oder Defektbildung zu minimieren. Die LEDs leuchten bei dieser Schaltungsform aber etwas dunkler als oben, weil kein konstanter Strom fliessen kann und man mit Rücksicht auf die Lebensdauer der LEDs nicht einfach die Spannung so erhöhen kann, dass der Effektivwert erreicht wird.<br />
{{Absatz}}<br />
<br />
<br />
{{warnung|Spannungen ab 60V sind lebensgefährlich!}}<br />
<br />
== Funktion einer LED-Lampe am Beispiel==<br />
von [[Benutzer:Didi34]]<br />
=== Aufbau ===<br />
[[Datei:aufbau.JPG|left|300px]]<br />
Ich beschreibe in diesem Beitrag den Aufbau eines 4W Philips LED-Leuchtmittels mit E-14 Sockel. Über dem LED-Chip befindet sich ein Glaskolben, der in den weißen Kunststoffsockel geklebt ist. Der Glaskolben ist aus Milchglas, dies dient als Diffusor. Um näher in die Lampe zu kommen, muss der Glaskolben abgenommen werden.<br />
{{Absatz}}<br />
<br />
[[Datei:sockel.JPG|left|300px]]<br />
Nun sieht man den LED-Chip in der Mitte der Lampe. Über dem Chip befindet sich eine weitere Abdeckung, die abgenommen werden muss. <br />
{{Absatz}}<br />
<br />
[[Datei:chip_anschluss.JPG|left|300px]]<br />
Auf dem nächsten Bild sieht man die Aluminium-Platine, worauf sich der LED-Chip befindet. Die beiden Drähte stellen die Versorgung der LED (300V Gleichspannung) dar. Die Platine besteht aus dem Basismaterial Aluminium, um eine bessere Kühlung zu erreichen.<br />
{{Absatz}}<br />
<br />
=== Innenleben ===<br />
[[Datei:platine_unten.jpg|left|300px]]<br />
Im Inneren der LED-Lampe befindet sich folgende Platine:<br />
<br />
Man sieht nun auf der Platine eine kleine Gleichrichterschaltung. Die Anschlüsse Blau und Braun sind Neutralleiter(N) und Außenleiter(L1) unserer Energieversorgung mit 230V Wechselspannung.<br />
{{Absatz}}<br />
<br />
[[Datei:platine_oben.JPG|left|300px]]<br />
<br />
Die beiden Drähte Rot(+) und Schwarz(-) sind die Ausgänge der Schaltung. Sie führen eine Gleichspannung von 300V und werden direkt an der Aluminiumplatine der LED angeschlossen, da die LED für diese Spannung ausgelegt ist. Näheres zur Schaltung:<br />
[http://www.mikrocontroller.net/articles/LED-Gl%C3%BChbirne#Schaltung/ Schaltung]<br />
{{Absatz}}<br />
<br />
==== LED-Chip ====<br />
[[Datei:ledchip_dunkel.jpg|left|300px]]<br />
Der LED-Chip besteht aus mehreren in Serie geschalteten LEDs. Die in Serie geschalteten LEDs sind um eine warm-weiße Farbe zu erreichen teils rot und teils weiß. Die LED ist für 300V DC ausgelegt. Auf dem LED-Chip befinden sich zwei weiße und zwei rote LED-Arrays. Die gelbe Schicht der weißen LEDs ist ein Phosphor (also ein Leuchtstoff) der aus dem blauen Licht der Kristalle weißes Licht macht.<br />
{{Absatz}}<br />
<br />
[[Datei:ledchip_hell.jpg|left|300px]]<br />
Eine weitere Ansicht des LED-Chips im Betrieb unter Spannung.<br />
{{Absatz}}<br />
<br />
==== Schaltung ====<br />
[[Datei:netzteilschaltung.png|left|300px|Einfache Gleichrichterschaltung für LEDs]]<br />
Für den Betieb an Netzspannung wird ein Kondensatornetzteil verwendet, welches aus 230V AC 300V DC macht. Die Schaltung ist mit 1A abgesichert. {{Absatz}}<br />
<br />
=== Messung ===<br />
[[Datei:messung.bmp|left|300px|Messung]]<br />
Es wurde zwischen dem roten und schwarzen Ausgang der oben genannten Schaltung gemessen. CH1 roter Anschluss CH2 schwarzer Anschluss.<br />
Die rote Linie am Oszillogramm ist Die Spannung zwischen den beiden Drähten (CH1-CH2).<br />
{{Absatz}}<br />
<br />
{{warnung|Spannungen ab 60V sind lebensgefährlich!}}<br />
<br />
== Interne Links ==<br />
* [[LED]]<br />
<br />
== Externe Links ==<br />
<br />
* [http://de.wikipedia.org/wiki/Leuchtdiode Wikipedia: LED]<br />
* [http://de.wikipedia.org/wiki/Kompaktleuchtstofflampe Wikipedia: Kompaktleuchtstofflampe]<br />
* [http://de.wikipedia.org/wiki/Glühlampe Wikipedia: Glühbirne ]<br />
* [http://de.wikipedia.org/wiki/Kondensatornetzteil Wikipedia: Kondensatornetzteil]<br />
* [http://de.wikipedia.org/wiki/Energiesparende Leuchtmittel Wikipedia: Energiesparende Leuchtmittel allgemein]<br />
<br />
<br />
[[Kategorie:Bauteile]]<br />
[[Kategorie:Displays und Anzeigen]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=LED-%22Birnen%22&diff=107152LED-"Birnen"2024-10-30T13:09:02Z<p>Heha: Wärmeabfuhr ist nicht bei jedem Leuchtendesign vorgesehen</p>
<hr />
<div>Dieser Beitrag beschreibt Aufbau und Funktion von [[LED]]-basierten Leuchtmitteln (LED-Lampen), umgangssprachlich auch manchmal als '''"LED-Birnen"''' bezeichnet.<br />
<br />
== Einleitung ==<br />
Anstelle von Glühlampen werden heutzutage nahezu ausschließlich LED-„Birnen“ benutzt. Im Vergleich zu den Anfang des Jahrtausends eingesetzten Kompaktleuchtstofflampen (Quecksilberdampf-Niederdrucklampe) erreichen sie ein noch höheres Energiesparpotenzial ohne Problemabfall zu sein. Dabei erreichen sie die volle Helligkeit sofort nach dem Einschalten, genauso wie Metalldraht-Glühlampen.<br />
Dabei dominieren Bauformen, die auf leichte Fertigung optimiert sind (plane Leiterplatte und Lichtstreukappe). Für repräsentativen Einsatz (sichtbare Birne) gibt es sogenannte Filamentlampen, deren LED-Nacktchips dicht an dicht auf ein Keramiksubstrat gebondet sind.<br />
<br />
== Vergleich mit anderen Leuchtmitteln ==<br />
Auf den Packungen der Hersteller sind sowohl bei Kompaktleuchtstofflampen, als auch bei LED-Birnen sehr optimistische Werte für die Lebensdauer und die Helligkeit angegeben. <br />
<br />
Seit 1. September 2013 ist die [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2012:342:0001:0022:DE:PDF DIM II – EU 1194/2012 EU Verordnung] in Kraft, die gewisse Mindestanforderungen an die angegeben Werte gibt. Die Anforderungen werden schrittweise in 3 Stufen verschärft: <br />
- Stufe 1: 1. September 2013, <br />
- Stufe 2: 1. September 2014<br />
- Stufe 3: 1. September 2016<br />
<br />
Die Einhaltung wird durch Marktaufsichtsbehörden zu kontrollieren; Man kann sich nur selber überlegen ob eher die Marken oder Noname-Hersteller sich daran halten werden.<br />
<br />
=== Lebensdauervergleich===<br />
Kompaktleuchtstofflampen werden gerne mit bis zu 10.000h - LED-Lampen sogar mit bis zu 50.000h angegeben. <br />
<br />
Für LED Lampen fordert die DIM II eine maximale Frühausfallrate von 5% nach 1000h und eine maximale Ausfallrate von 10% nach 6000h. (ab Stufe 1)<br />
<br />
Kompaktleuchtstofflampen dürfen maximale 5% Frühausfallrate nach 500h haben und nach 6000h dürfen maximal 50% ausgefallen sein. (Stufe 1; Stufe 3: 70%)<br />
<br />
Ein weiterer Punkt ist die alterungsbedingte Lichtstromabnahme: Nach der Richtlinie müssen für Kompaktleuchtstofflampen nach 2000h noch 80% (Stufe 2) bzw 83% nach 2000h und 70% nach 6000h (Stufe 3)<br />
<br />
LEDs müssen nach 6000h noch mindestens 80% Lichtstrom haben. (Stufe 2)<br />
<br />
Zum Vergleich: 50% der Glühlampen müssten >1000h (Stufe 1), 2000h (Stufe 2) bzw. für Kleinspannungslampen ab Stufe 3 4000h leben.<br />
Dabei müssen sie bei 3/4 der obigen Lebensdauerforderung noch mindestens 80% der Helligkeit haben. Frühausfallraten wären <5% bei 200h.<br />
Wären, da bekannterweise die Glühlampen die Anforderungen <br />
<br />
=== Leistungsvergleich===<br />
<br />
Nach der DIM II ist es vorgeschrieben, dass die Lampen oder die Verpackung den Lichtstromwert in Lumen ausweisen. Damit werden die Leuchtmittel direkt vergleichbar in Punkto Helligkeit. Zusätzlich dürfen die Äquivalenzwerte angegeben werden, wobei die Umrechnung vom Lichtstrom vorgegeben ist. In der Regel benötigen hier dann LED-Lampen "mehr" Lumen als herkömmliche Glühlampen um die selbe Äquivalenzleistung zu haben.<br />
<br />
Beispiel: eine GU20 40D 35W Halogen hat ca. 140lm. Die selbe Lichtmenge reicht nur für das Labeln von 25W (Äquivalent). 35W würden 230lm brauchen. (Beispiel von [http://www.lighting.philips.com/pwc_li/main/led/assets/final%20dim2-philips_presentation.pdf hier, Seite 8])<br />
<br />
Im direkten Vergleich ist der Lichstrom sinnvoller, da hier die Augenempfindlichkeit schon berücksichtigt ist.<br />
<br />
=== Farbwiedergabe- und Lichtfarbenvergleich ===<br />
<br />
Auch Anforderungen an die Farbwiedergabe und an die Lichtfarbe werden in der DIM 2 formuliert:<br />
<br />
==== Farbwiedergabe ====<br />
<br />
Glühlampen haben per Definition einen Farbwiedergabewert Ra=100.<br />
Für LED und Kompaktleuchtstofflampen sind die Mindestanforderungen Ra>85 (bzw. Ra>65 für Aussen- oder Industrieanwendungen). Gute Lampen gibt es aber auch mit Ra>90.<br />
<br />
==== Lichtfarbe ====<br />
<br />
Auch die [https://de.wikipedia.org/wiki/Farbtemperatur Lichtfarbe] muss angegeben werden. Hier ist die Einheit Kelvin und je kleiner der Wert desto "wärmer" das Licht. <br />
<br />
Normalerweise bekommt man hier nur "warmweiss" oder 3000K. <br />
Damit sollten die Zeiten vorbei sein wo man vom Chinamann eine 8000K LED-Lampe als warmweiss verkauft bekommt und dann sich über das blaue Licht wundert.<br />
<br />
Bei LEDs darf maximale Farbabweichung darf hier nicht mehr als 6 [http://fastvoice.net/2013/09/18/farbkonsistenz-macadam-sdcm-wie-unterschiedlich-leuchten-leds/ Schwellwerteinheiten] sein. Der Wert sollte angegeben sein, gut Lampen erreichen hier weniger als 3 Schwellwerteinheiten.<br />
<br />
=== Vor- und Nachteile der LED-Lampen ===<br />
<br />
LED-Lampen haben einige Vorteile gegenüber den Kompaktleuchtstofflampen und vor allem gegenüber den Glühfadenlampen: <br />
<br />
* Die Energieeffizienz ist in der Regel höher als bei Kompaktleuchststofflampen.<br />
* Die Kosteneffizienz ist bei einfachen Ausführungen ähnlich gut.<br />
* Die Lichtfarbe bzw. Farbtemperatur der LED-Lampe ist flexibler und kann auf Wunsch der Glühfadenlampenfarbe besser angepasst werden. Dazu gibt es kaltweiße, warmweiße und auch farbige Ausführungen.<br />
* Sie enthalten keine leicht freisetzbaren Giftstoffe wie Quecksilber.<br />
* Erreichen bereits nach wenigen Millisekunden nach dem Einschalten die volle Leuchtkraft.<br />
* Können eine sehr lange Lebensdauer haben (meist >= 30000 Stunden).<br />
* Sind nach Lebensende „nur“ als Elektroschrott zu entsorgen — kein Problemabfall wie Energiesparlampen.<br />
<br />
Jedoch gibt es auch einige Nachteile:<br />
<br />
* bei birnenähnlichen Designs und höheren Leistungen höherer Beschaffungspreis<br />
* Ähnlich wie bei ESLs befinden sich sehr viel billige Produkte am Markt, bei denen die Elektronik rasch kaputt geht.<br />
* schlechterer Farbwiedergabeindex R<sub>a</sub> = 80-95 (Glühbirne als Referenz R<sub>a</sub> = 100)<br />
* Bei Billigprodukten oftmals EMV-Probleme (Störungen im Kurzwellenbereich sowie bei DAB+)<br />
* Sollten nicht in Leuchten verwendet werden, bei denen eine Keramikfassung darauf hindeutet, dass der Sockel heiß werden darf. Anders als die extrem hitzebeständigen Glühlampen sollte der Sockel einer LED-Lampe möglichst kühl bleiben. Daher muss man bei einer liebgewonnenen Leuchte ggf. konstruktive Maßnahmen zur Wärmeabführung treffen, ''trotz'' der viel geringeren Wärmeabgabe von LED-Lampen<br />
* Problematischer Einsatz in Feuchträumen (Keller, Brunnen, unterirdische Anlagen bspw. der Wasserver- und Entsorgung, Schwimmbad, Tropen — ''nicht'' das heimische Bad): Ersatz durch Kleinspannung erspart empfindliche Elektronik im Feuchtbereich<br />
<br />
=== Kostenvergleich von Energiesparlampen ===<br />
[[Datei:Kostenvergleich-led-esl-birnen.jpg|left|300px|Kostenvergleich]]<br />
<br />
Die Grafik zeigt 3 Fälle von Kostenrechnungen für konventionelle Glühlampen, Kompaktleuchtstofflampe (als ESL bezeichnet) und LED-Lampen.<br />
<br />
Berechnet werden jeweils die beiden Extremfälle einer Lampe mit niedrigem Preis und hoher Lebensdauer (günstiger Fall) und einer "Montagslampe", die schnell kaputt geht, trotz hohen Preises. Daraus wird ein wahrscheinlichster Mittelwert (geometrische Mitte) - einmal für geringe und einmal für starke Nutzung gebildet.<br />
<br />
Aufgeführt ist auch die Unterscheidung der privaten und geschäftlichen Nutzung, bei der die Beschaffungs- und Wartungszeiten viel stärker zu Buche schlagen, da ein Angestellter bezahlt werden muss. Hier zeigt sich der Vorteil der langen Nutzungsdauer der LED-Lampen besonders deutlich.<br />
<br />
Es zeigt sich auch, dass Privatnutzer durchaus noch einen geringen Sparvorteil haben können, wenn sie auf LED-Lampen umrüsten.<br />
<br />
Excel für eigene Berechnungen: [http://www.mikrocontroller.net/wikifiles/0/09/Lampenrechner.xls Lampenvergleichsrechner]<br />
<br />
Externer Link auf Excel:<br />
[http://shop.bioledex.de/files/BIOLEDEX-LED-Stromkosten-Rechner.xls Stromkostenrechner]<br />
<br />
<br />
{{Absatz}}<br />
<br />
== Bauformen ==<br />
=== Hochvolt-LED-Lampen===<br />
<br />
=== Niederspannungs-LED-Lampen===<br />
==== Halogenersatzlampen ====<br />
Üblicherweise werden Niederspannungs-LED-Lampen an einem dezentralen Transformator betrieben, wie z.B mit 24V. Mit einer geeigneten Vorschaltung zur Spannungsherabsetzung im Lampengehäuse, sind sie auch indirekt an 230V-Netzen benutzbar.<br />
<br />
==== Betrieb von Standard-LEDs an 230V ====<br />
[[Datei:led_230v.png|left|300px|230V-Vorschaltung]]<br />
Mit der nebenstehenden Schaltung besteht die Möglichkeit, eine normale LED direkt an 230V anzuschließen. Diese Schaltung funktioniert so, dass die Spannung mittels Z-Dioden begrenzt wird; in diesem Fall auf 30V. Diese sind deshalb wichtig, weil die Gleichrichtdioden für hohen Frequenzanteile als Kapazität wirken und der Elko diese nicht aufnehmen kann, wodurch sie direkt auf die LEDs wirken würden. Gfs sollte dem Elko noch eine keramischer Kondensator beigefügt werden.<br />
{{Absatz}}<br />
<br />
[[Datei:Led an 220V.png|left|300px|230V-Schaltung]]<br />
Statt eines Gleichrichters, kann auch eine Antiparallelschaltung von LEDs verwendet werden. Auch dabei werden beide Halbwellen genutzt. Die Ausfallwahrscheinlichkeit ist geringer, weil weniger Bauteile und vor allem kein Elko genutzt wird. Allerdings muss die Schaltung genau dimensioniert werden, d.h. die strombegrenzende Wirkung des Kondensators ist sehr wichtig. Daher werden zur Sicherheit einige in Serie geschaltet, um das Problem der Alterung oder Defektbildung zu minimieren. Die LEDs leuchten bei dieser Schaltungsform aber etwas dunkler als oben, weil kein konstanter Strom fliessen kann und man mit Rücksicht auf die Lebensdauer der LEDs nicht einfach die Spannung so erhöhen kann, dass der Effektivwert erreicht wird.<br />
{{Absatz}}<br />
<br />
<br />
{{warnung|Spannungen ab 60V sind lebensgefährlich!}}<br />
<br />
== Funktion einer LED-Lampe am Beispiel==<br />
von [[Benutzer:Didi34]]<br />
=== Aufbau ===<br />
[[Datei:aufbau.JPG|left|300px]]<br />
Ich beschreibe in diesem Beitrag den Aufbau eines 4W Philips LED-Leuchtmittels mit E-14 Sockel. Über dem LED-Chip befindet sich ein Glaskolben, der in den weißen Kunststoffsockel geklebt ist. Der Glaskolben ist aus Milchglas, dies dient als Diffusor. Um näher in die Lampe zu kommen, muss der Glaskolben abgenommen werden.<br />
{{Absatz}}<br />
<br />
[[Datei:sockel.JPG|left|300px]]<br />
Nun sieht man den LED-Chip in der Mitte der Lampe. Über dem Chip befindet sich eine weitere Abdeckung, die abgenommen werden muss. <br />
{{Absatz}}<br />
<br />
[[Datei:chip_anschluss.JPG|left|300px]]<br />
Auf dem nächsten Bild sieht man die Aluminium-Platine, worauf sich der LED-Chip befindet. Die beiden Drähte stellen die Versorgung der LED (300V Gleichspannung) dar. Die Platine besteht aus dem Basismaterial Aluminium, um eine bessere Kühlung zu erreichen.<br />
{{Absatz}}<br />
<br />
=== Innenleben ===<br />
[[Datei:platine_unten.jpg|left|300px]]<br />
Im Inneren der LED-Lampe befindet sich folgende Platine:<br />
<br />
Man sieht nun auf der Platine eine kleine Gleichrichterschaltung. Die Anschlüsse Blau und Braun sind Neutralleiter(N) und Außenleiter(L1) unserer Energieversorgung mit 230V Wechselspannung.<br />
{{Absatz}}<br />
<br />
[[Datei:platine_oben.JPG|left|300px]]<br />
<br />
Die beiden Drähte Rot(+) und Schwarz(-) sind die Ausgänge der Schaltung. Sie führen eine Gleichspannung von 300V und werden direkt an der Aluminiumplatine der LED angeschlossen, da die LED für diese Spannung ausgelegt ist. Näheres zur Schaltung:<br />
[http://www.mikrocontroller.net/articles/LED-Gl%C3%BChbirne#Schaltung/ Schaltung]<br />
{{Absatz}}<br />
<br />
==== LED-Chip ====<br />
[[Datei:ledchip_dunkel.jpg|left|300px]]<br />
Der LED-Chip besteht aus mehreren in Serie geschalteten LEDs. Die in Serie geschalteten LEDs sind um eine warm-weiße Farbe zu erreichen teils rot und teils weiß. Die LED ist für 300V DC ausgelegt. Auf dem LED-Chip befinden sich zwei weiße und zwei rote LED-Arrays. Die gelbe Schicht der weißen LEDs ist ein Phosphor (also ein Leuchtstoff) der aus dem blauen Licht der Kristalle weißes Licht macht.<br />
{{Absatz}}<br />
<br />
[[Datei:ledchip_hell.jpg|left|300px]]<br />
Eine weitere Ansicht des LED-Chips im Betrieb unter Spannung.<br />
{{Absatz}}<br />
<br />
==== Schaltung ====<br />
[[Datei:netzteilschaltung.png|left|300px|Einfache Gleichrichterschaltung für LEDs]]<br />
Für den Betieb an Netzspannung wird ein Kondensatornetzteil verwendet, welches aus 230V AC 300V DC macht. Die Schaltung ist mit 1A abgesichert. {{Absatz}}<br />
<br />
=== Messung ===<br />
[[Datei:messung.bmp|left|300px|Messung]]<br />
Es wurde zwischen dem roten und schwarzen Ausgang der oben genannten Schaltung gemessen. CH1 roter Anschluss CH2 schwarzer Anschluss.<br />
Die rote Linie am Oszillogramm ist Die Spannung zwischen den beiden Drähten (CH1-CH2).<br />
{{Absatz}}<br />
<br />
{{warnung|Spannungen ab 60V sind lebensgefährlich!}}<br />
<br />
== Interne Links ==<br />
* [[LED]]<br />
<br />
== Externe Links ==<br />
<br />
* [http://de.wikipedia.org/wiki/Leuchtdiode Wikipedia: LED]<br />
* [http://de.wikipedia.org/wiki/Kompaktleuchtstofflampe Wikipedia: Kompaktleuchtstofflampe]<br />
* [http://de.wikipedia.org/wiki/Glühlampe Wikipedia: Glühbirne ]<br />
* [http://de.wikipedia.org/wiki/Kondensatornetzteil Wikipedia: Kondensatornetzteil]<br />
* [http://de.wikipedia.org/wiki/Energiesparende Leuchtmittel Wikipedia: Energiesparende Leuchtmittel allgemein]<br />
<br />
<br />
[[Kategorie:Bauteile]]<br />
[[Kategorie:Displays und Anzeigen]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=LED-%22Birnen%22&diff=107151LED-"Birnen"2024-10-30T12:51:44Z<p>Heha: Text zeitgemäß: Kompaktleuchtstofflampen interessieren nur noch im Museum (als Irrweg der Beleuchtungstechnik)</p>
<hr />
<div>Dieser Beitrag beschreibt Aufbau und Funktion von [[LED]]-basierten Leuchtmitteln (LED-Lampen), umgangssprachlich auch manchmal als '''"LED-Birnen"''' bezeichnet.<br />
<br />
== Einleitung ==<br />
Anstelle von Glühlampen werden heutzutage nahezu ausschließlich LED-„Birnen“ benutzt. Im Vergleich zu den Anfang des Jahrtausends eingesetzten Kompaktleuchtstofflampen (Quecksilberdampf-Niederdrucklampe) erreichen sie ein noch höheres Energiesparpotenzial ohne Problemabfall zu sein. Dabei erreichen sie die volle Helligkeit sofort nach dem Einschalten, genauso wie Metalldraht-Glühlampen.<br />
Dabei dominieren Bauformen, die auf leichte Fertigung optimiert sind (plane Leiterplatte und Lichtstreukappe). Für repräsentativen Einsatz (sichtbare Birne) gibt es sogenannte Filamentlampen, deren LED-Nacktchips dicht an dicht auf ein Keramiksubstrat gebondet sind.<br />
<br />
== Vergleich mit anderen Leuchtmitteln ==<br />
Auf den Packungen der Hersteller sind sowohl bei Kompaktleuchtstofflampen, als auch bei LED-Birnen sehr optimistische Werte für die Lebensdauer und die Helligkeit angegeben. <br />
<br />
Seit 1. September 2013 ist die [http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2012:342:0001:0022:DE:PDF DIM II – EU 1194/2012 EU Verordnung] in Kraft, die gewisse Mindestanforderungen an die angegeben Werte gibt. Die Anforderungen werden schrittweise in 3 Stufen verschärft: <br />
- Stufe 1: 1. September 2013, <br />
- Stufe 2: 1. September 2014<br />
- Stufe 3: 1. September 2016<br />
<br />
Die Einhaltung wird durch Marktaufsichtsbehörden zu kontrollieren; Man kann sich nur selber überlegen ob eher die Marken oder Noname-Hersteller sich daran halten werden.<br />
<br />
=== Lebensdauervergleich===<br />
Kompaktleuchtstofflampen werden gerne mit bis zu 10.000h - LED-Lampen sogar mit bis zu 50.000h angegeben. <br />
<br />
Für LED Lampen fordert die DIM II eine maximale Frühausfallrate von 5% nach 1000h und eine maximale Ausfallrate von 10% nach 6000h. (ab Stufe 1)<br />
<br />
Kompaktleuchtstofflampen dürfen maximale 5% Frühausfallrate nach 500h haben und nach 6000h dürfen maximal 50% ausgefallen sein. (Stufe 1; Stufe 3: 70%)<br />
<br />
Ein weiterer Punkt ist die alterungsbedingte Lichtstromabnahme: Nach der Richtlinie müssen für Kompaktleuchtstofflampen nach 2000h noch 80% (Stufe 2) bzw 83% nach 2000h und 70% nach 6000h (Stufe 3)<br />
<br />
LEDs müssen nach 6000h noch mindestens 80% Lichtstrom haben. (Stufe 2)<br />
<br />
Zum Vergleich: 50% der Glühlampen müssten >1000h (Stufe 1), 2000h (Stufe 2) bzw. für Kleinspannungslampen ab Stufe 3 4000h leben.<br />
Dabei müssen sie bei 3/4 der obigen Lebensdauerforderung noch mindestens 80% der Helligkeit haben. Frühausfallraten wären <5% bei 200h.<br />
Wären, da bekannterweise die Glühlampen die Anforderungen <br />
<br />
=== Leistungsvergleich===<br />
<br />
Nach der DIM II ist es vorgeschrieben, dass die Lampen oder die Verpackung den Lichtstromwert in Lumen ausweisen. Damit werden die Leuchtmittel direkt vergleichbar in Punkto Helligkeit. Zusätzlich dürfen die Äquivalenzwerte angegeben werden, wobei die Umrechnung vom Lichtstrom vorgegeben ist. In der Regel benötigen hier dann LED-Lampen "mehr" Lumen als herkömmliche Glühlampen um die selbe Äquivalenzleistung zu haben.<br />
<br />
Beispiel: eine GU20 40D 35W Halogen hat ca. 140lm. Die selbe Lichtmenge reicht nur für das Labeln von 25W (Äquivalent). 35W würden 230lm brauchen. (Beispiel von [http://www.lighting.philips.com/pwc_li/main/led/assets/final%20dim2-philips_presentation.pdf hier, Seite 8])<br />
<br />
Im direkten Vergleich ist der Lichstrom sinnvoller, da hier die Augenempfindlichkeit schon berücksichtigt ist.<br />
<br />
=== Farbwiedergabe- und Lichtfarbenvergleich ===<br />
<br />
Auch Anforderungen an die Farbwiedergabe und an die Lichtfarbe werden in der DIM 2 formuliert:<br />
<br />
==== Farbwiedergabe ====<br />
<br />
Glühlampen haben per Definition einen Farbwiedergabewert Ra=100.<br />
Für LED und Kompaktleuchtstofflampen sind die Mindestanforderungen Ra>85 (bzw. Ra>65 für Aussen- oder Industrieanwendungen). Gute Lampen gibt es aber auch mit Ra>90.<br />
<br />
==== Lichtfarbe ====<br />
<br />
Auch die [https://de.wikipedia.org/wiki/Farbtemperatur Lichtfarbe] muss angegeben werden. Hier ist die Einheit Kelvin und je kleiner der Wert desto "wärmer" das Licht. <br />
<br />
Normalerweise bekommt man hier nur "warmweiss" oder 3000K. <br />
Damit sollten die Zeiten vorbei sein wo man vom Chinamann eine 8000K LED-Lampe als warmweiss verkauft bekommt und dann sich über das blaue Licht wundert.<br />
<br />
Bei LEDs darf maximale Farbabweichung darf hier nicht mehr als 6 [http://fastvoice.net/2013/09/18/farbkonsistenz-macadam-sdcm-wie-unterschiedlich-leuchten-leds/ Schwellwerteinheiten] sein. Der Wert sollte angegeben sein, gut Lampen erreichen hier weniger als 3 Schwellwerteinheiten.<br />
<br />
=== Vor- und Nachteile der LED-Lampen ===<br />
<br />
LED-Lampen haben einige Vorteile gegenüber den Kompaktleuchtstofflampen und vor allem gegenüber den Glühfadenlampen: <br />
<br />
* Die Energieeffizienz ist in der Regel höher als bei Kompaktleuchststofflampen.<br />
* Die Kosteneffizienz ist bei einfachen Ausführungen ähnlich gut.<br />
* Die Lichtfarbe bzw. Farbtemperatur der LED-Lampe ist flexibler und kann auf Wunsch der Glühfadenlampenfarbe besser angepasst werden. Dazu gibt es kaltweiße, warmweiße und auch farbige Ausführungen.<br />
* Sie enthalten keine leicht freisetzbaren Giftstoffe, wie Quecksilber.<br />
* Erreichen bereits nach wenigen Millisekunden nach dem Einschalten die volle Leuchtkraft.<br />
* Können eine sehr lange Lebensdauer haben (meist >= 30000 Stunden).<br />
* Sind nach Lebensende "nur" als Elektroschrott zu entsorgen (aber kein Sondermüll wie Energiesparlampen).<br />
<br />
Jedoch gibt es auch einige Nachteile:<br />
<br />
* bei birnenähnlichen Designs und höheren Leistungen höherer Preis <br />
* Ähnlich wie bei ESLs befinden sich sehr viel billige Produkte am Markt, bei denen die Elektronik rasch kaputt geht.<br />
* schlechterer Farbwiedergabeindex Ra=80-95 (Glühbirne als Referenz Ra=100)<br />
* Bei Billigprodukten oftmals starke EMV-Probleme (Störungen im Kurzwellenbereich)<br />
<br />
=== Kostenvergleich von Energiesparlampen ===<br />
[[Datei:Kostenvergleich-led-esl-birnen.jpg|left|300px|Kostenvergleich]]<br />
<br />
Die Grafik zeigt 3 Fälle von Kostenrechnungen für konventionelle Glühlampen, Kompaktleuchtstofflampe (als ESL bezeichnet) und LED-Lampen.<br />
<br />
Berechnet werden jeweils die beiden Extremfälle einer Lampe mit niedrigem Preis und hoher Lebensdauer (günstiger Fall) und einer "Montagslampe", die schnell kaputt geht, trotz hohen Preises. Daraus wird ein wahrscheinlichster Mittelwert (geometrische Mitte) - einmal für geringe und einmal für starke Nutzung gebildet.<br />
<br />
Aufgeführt ist auch die Unterscheidung der privaten und geschäftlichen Nutzung, bei der die Beschaffungs- und Wartungszeiten viel stärker zu Buche schlagen, da ein Angestellter bezahlt werden muss. Hier zeigt sich der Vorteil der langen Nutzungsdauer der LED-Lampen besonders deutlich.<br />
<br />
Es zeigt sich auch, dass Privatnutzer durchaus noch einen geringen Sparvorteil haben können, wenn sie auf LED-Lampen umrüsten.<br />
<br />
Excel für eigene Berechnungen: [http://www.mikrocontroller.net/wikifiles/0/09/Lampenrechner.xls Lampenvergleichsrechner]<br />
<br />
Externer Link auf Excel:<br />
[http://shop.bioledex.de/files/BIOLEDEX-LED-Stromkosten-Rechner.xls Stromkostenrechner]<br />
<br />
<br />
{{Absatz}}<br />
<br />
== Bauformen ==<br />
=== Hochvolt-LED-Lampen===<br />
<br />
=== Niederspannungs-LED-Lampen===<br />
==== Halogenersatzlampen ====<br />
Üblicherweise werden Niederspannungs-LED-Lampen an einem dezentralen Transformator betrieben, wie z.B mit 24V. Mit einer geeigneten Vorschaltung zur Spannungsherabsetzung im Lampengehäuse, sind sie auch indirekt an 230V-Netzen benutzbar.<br />
<br />
==== Betrieb von Standard-LEDs an 230V ====<br />
[[Datei:led_230v.png|left|300px|230V-Vorschaltung]]<br />
Mit der nebenstehenden Schaltung besteht die Möglichkeit, eine normale LED direkt an 230V anzuschließen. Diese Schaltung funktioniert so, dass die Spannung mittels Z-Dioden begrenzt wird; in diesem Fall auf 30V. Diese sind deshalb wichtig, weil die Gleichrichtdioden für hohen Frequenzanteile als Kapazität wirken und der Elko diese nicht aufnehmen kann, wodurch sie direkt auf die LEDs wirken würden. Gfs sollte dem Elko noch eine keramischer Kondensator beigefügt werden.<br />
{{Absatz}}<br />
<br />
[[Datei:Led an 220V.png|left|300px|230V-Schaltung]]<br />
Statt eines Gleichrichters, kann auch eine Antiparallelschaltung von LEDs verwendet werden. Auch dabei werden beide Halbwellen genutzt. Die Ausfallwahrscheinlichkeit ist geringer, weil weniger Bauteile und vor allem kein Elko genutzt wird. Allerdings muss die Schaltung genau dimensioniert werden, d.h. die strombegrenzende Wirkung des Kondensators ist sehr wichtig. Daher werden zur Sicherheit einige in Serie geschaltet, um das Problem der Alterung oder Defektbildung zu minimieren. Die LEDs leuchten bei dieser Schaltungsform aber etwas dunkler als oben, weil kein konstanter Strom fliessen kann und man mit Rücksicht auf die Lebensdauer der LEDs nicht einfach die Spannung so erhöhen kann, dass der Effektivwert erreicht wird.<br />
{{Absatz}}<br />
<br />
<br />
{{warnung|Spannungen ab 60V sind lebensgefährlich!}}<br />
<br />
== Funktion einer LED-Lampe am Beispiel==<br />
von [[Benutzer:Didi34]]<br />
=== Aufbau ===<br />
[[Datei:aufbau.JPG|left|300px]]<br />
Ich beschreibe in diesem Beitrag den Aufbau eines 4W Philips LED-Leuchtmittels mit E-14 Sockel. Über dem LED-Chip befindet sich ein Glaskolben, der in den weißen Kunststoffsockel geklebt ist. Der Glaskolben ist aus Milchglas, dies dient als Diffusor. Um näher in die Lampe zu kommen, muss der Glaskolben abgenommen werden.<br />
{{Absatz}}<br />
<br />
[[Datei:sockel.JPG|left|300px]]<br />
Nun sieht man den LED-Chip in der Mitte der Lampe. Über dem Chip befindet sich eine weitere Abdeckung, die abgenommen werden muss. <br />
{{Absatz}}<br />
<br />
[[Datei:chip_anschluss.JPG|left|300px]]<br />
Auf dem nächsten Bild sieht man die Aluminium-Platine, worauf sich der LED-Chip befindet. Die beiden Drähte stellen die Versorgung der LED (300V Gleichspannung) dar. Die Platine besteht aus dem Basismaterial Aluminium, um eine bessere Kühlung zu erreichen.<br />
{{Absatz}}<br />
<br />
=== Innenleben ===<br />
[[Datei:platine_unten.jpg|left|300px]]<br />
Im Inneren der LED-Lampe befindet sich folgende Platine:<br />
<br />
Man sieht nun auf der Platine eine kleine Gleichrichterschaltung. Die Anschlüsse Blau und Braun sind Neutralleiter(N) und Außenleiter(L1) unserer Energieversorgung mit 230V Wechselspannung.<br />
{{Absatz}}<br />
<br />
[[Datei:platine_oben.JPG|left|300px]]<br />
<br />
Die beiden Drähte Rot(+) und Schwarz(-) sind die Ausgänge der Schaltung. Sie führen eine Gleichspannung von 300V und werden direkt an der Aluminiumplatine der LED angeschlossen, da die LED für diese Spannung ausgelegt ist. Näheres zur Schaltung:<br />
[http://www.mikrocontroller.net/articles/LED-Gl%C3%BChbirne#Schaltung/ Schaltung]<br />
{{Absatz}}<br />
<br />
==== LED-Chip ====<br />
[[Datei:ledchip_dunkel.jpg|left|300px]]<br />
Der LED-Chip besteht aus mehreren in Serie geschalteten LEDs. Die in Serie geschalteten LEDs sind um eine warm-weiße Farbe zu erreichen teils rot und teils weiß. Die LED ist für 300V DC ausgelegt. Auf dem LED-Chip befinden sich zwei weiße und zwei rote LED-Arrays. Die gelbe Schicht der weißen LEDs ist ein Phosphor (also ein Leuchtstoff) der aus dem blauen Licht der Kristalle weißes Licht macht.<br />
{{Absatz}}<br />
<br />
[[Datei:ledchip_hell.jpg|left|300px]]<br />
Eine weitere Ansicht des LED-Chips im Betrieb unter Spannung.<br />
{{Absatz}}<br />
<br />
==== Schaltung ====<br />
[[Datei:netzteilschaltung.png|left|300px|Einfache Gleichrichterschaltung für LEDs]]<br />
Für den Betieb an Netzspannung wird ein Kondensatornetzteil verwendet, welches aus 230V AC 300V DC macht. Die Schaltung ist mit 1A abgesichert. {{Absatz}}<br />
<br />
=== Messung ===<br />
[[Datei:messung.bmp|left|300px|Messung]]<br />
Es wurde zwischen dem roten und schwarzen Ausgang der oben genannten Schaltung gemessen. CH1 roter Anschluss CH2 schwarzer Anschluss.<br />
Die rote Linie am Oszillogramm ist Die Spannung zwischen den beiden Drähten (CH1-CH2).<br />
{{Absatz}}<br />
<br />
{{warnung|Spannungen ab 60V sind lebensgefährlich!}}<br />
<br />
== Interne Links ==<br />
* [[LED]]<br />
<br />
== Externe Links ==<br />
<br />
* [http://de.wikipedia.org/wiki/Leuchtdiode Wikipedia: LED]<br />
* [http://de.wikipedia.org/wiki/Kompaktleuchtstofflampe Wikipedia: Kompaktleuchtstofflampe]<br />
* [http://de.wikipedia.org/wiki/Glühlampe Wikipedia: Glühbirne ]<br />
* [http://de.wikipedia.org/wiki/Kondensatornetzteil Wikipedia: Kondensatornetzteil]<br />
* [http://de.wikipedia.org/wiki/Energiesparende Leuchtmittel Wikipedia: Energiesparende Leuchtmittel allgemein]<br />
<br />
<br />
[[Kategorie:Bauteile]]<br />
[[Kategorie:Displays und Anzeigen]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=FET&diff=107033FET2024-07-24T09:31:12Z<p>Heha: Erklärung Warum und Woher</p>
<hr />
<div>Dieser Artikel versteht sich als Unterpunkt zum Artikel [[Leistungselektronik]]<br />
<br />
<br />
Ein FET (engl. '''F'''ield '''E'''ffect '''T'''ransistor) ist ein Feldeffekttransistor. Der FET ist ein Bauelement, das im Gegensatz zum Bipolartransistor (engl. '''B'''ipolar '''J'''unction '''T'''ransistor, BJT) mit Spannung und nicht mit Strom gesteuert wird. Weil keine P-N-Sperrschichten am Stromfluss beteiligt sind, heißen diese auch Unipolartransistoren. Unterschieden werden<br />
<br />
* MOSFET = engl. '''M'''etall '''O'''xide '''S'''emiconductor '''F'''ield '''E'''ffect '''T'''ransistor; Metalloxidschicht-FET, größte Teilgruppe der FETs mit isoliertem Gate.<br />
<br />
* JFET = engl. '''J'''unction '''F'''ield '''E'''ffect '''T'''ransistor, Übergangszonen-FET, der steuerbare Kanal wird durch einen PN-Übergang wie in einer Diode gebildet. <small>(Diese Diode lässt sich nachmessen und unterscheidet JFET von (selbtleitenden) MOSFET, auch wenn sie schaltungstechnisch keine Rolle spielt. Wichtig: JFETs gibt es ''nur'' selbstleitend!)</small><br />
<br />
Die drei Anschlüsse eines FETs werden ''Gate'', ''Drain'' und ''Source'' genannt. Unter Umständen ist ein vierter Anschluß vorhanden, der ''Bulk'' genannt wird. Normalerweise ist Bulk intern mit Source verbunden. <small>Wenn dies nicht der Fall ist, muss diese Verbindung durch den Designer in der Schaltung hergestellt werden. Nicht gesichtet für Leistungstransistoren.</small><br />
<br />
== FET-Typen ==<br />
<br />
FETs werden hauptsächlich unterschieden in N-Kanal und P-Kanal, sowie "selbst sperrend = Anreicherungstyp" (engl. enhancement type) und "selbst leitend = Verarmungstyp" (engl. depletion type). Beim selbstleitenden FET ist der Transistor bei 0V Gate-Source Spannung maximal leitend (durchgesteuert) und wird durch Anlegen einer Spannung ans Gate gesperrt. Beim selbstsperrenden FET (größte Gruppe) ist der Transistor bei 0V Gate-Source Spannung gesperrt und wird durch Anlegen einer Spannung ans Gate leitend. Ist die Linie zwischen Drain und Source durchgezogen handelt es sich um einen selbstleitenden, bei einer gestrichelten Linie um einen selbstsperrenden FET. JFETs gibt es nur als Verarmungstyp.<br />
<br />
Im weiteren Artikel wird nur der '''selbstsperrende''' MOSFET betrachtet, weil nur dieser einen althergebrachten Bipolartransistor „ersetzen“ kann.<br />
<br />
{| class="wikitable"<br />
|+ '''Typen von Feldeffekttransistoren<br/>&nbsp;'''<br />
|-<br />
! style="width:10em" | Typ <br />
! N-Kanal <br />
! P-Kanal<br />
|- valign="top"<br />
| JFET<br/>SFET<br/>(selbst leitend) || [[bild:JFET-N.png|center]]<br />
* drittgrößte Gruppe<br />
* bislang nur für kleine Leistungen verfügbar<br />
* JFETs mit hoher Leistung sind im Kommen<br />
* Eingangsstufen von OPVs<br />
* Eingangsstufen von HF-Verstärkern bis in den GHz-Bereich<br />
* als einfache [[Konstantstromquelle]] geeignet<br />
| [[bild:JFET-P.png|center]]<br />
* selten<br />
* ersatzhalber für „fehlenden“ P-Kanal-Verarmungs-MOSFET<br />
* Ältester Vertreter der Unipolartransistoren<br />
|- valign="top"<br />
| MOSFET<br/>Anreicherungstyp<br/>(selbst sperrend)<br/>''Enhancement Mode'' || [[bild:MOS-EN.png|center]]<br />
* Mit Abstand größte Gruppe; wenn nicht besonders erwähnt ist ''dieser'' gemeint<br />
* Eingangsstufen von HF-Verstärkern bis in den GHz-Bereich<br />
** Typen mit zwei Gates zum Regeln und Mischen üblich<br />
* Auch als Doppel-MOSFET oder zusammen mit P-Kanal-MOSFET in einem Gehäuse gängig<br />
| [[bild:MOS-EP.png|center]]<br />
* zweitgrößte Gruppe<br />
* bei gleicher Geometrie etwas schlechter als ein N-Kanal-Typ, da „Löcherleitung“ (aus „Defektelektronen“ = gedachte positive Ladungsträger) vorliegt<br />
* Auch als Doppel-MOSFET oder zusammen mit N-Kanal-MOSFET in einem Gehäuse gängig<br />
|- valign="top"<br />
| MOSFET<br/>Verarmungstyp<br/>(selbst leitend)<br/>''Depletion Mode'' || [[bild:MOS-DN.png|center]]<br />
* selten aber käuflich<br />
* Sinnvolle Anwendungen ergeben sich vor allem in Reihenschaltungen<br />
| [[bild:MOS-DP.png|center]]<br />
* Nicht in freier Wildbahn gesichtet<br />
|}<br />
<br />
=== Vorteile des FET ===<br />
<br />
* Niedrigere Verluste als bei Bipolartransistoren.<br />
* Sehr schnelles Schalten möglich, daher für sehr hohe Frequenzen geeignet (keine Speicherzeit wie beim BJT).<br />
* Einfaches Parallelschalten im Schaltbetrieb, da Unterschiede im <math>R_{DS,on}</math> durch den positiven Temperaturkoeffizienten ausgeglichen werden.<br />
* Leistungslose Ansteuerung im statischen Fall, jedoch hohe Umladeverluste am Gate!<br />
* oft preiswerter als vergleichbare Bipolartransistoren (engl. '''B'''ipolar '''J'''unction '''T'''ransistor, BJT)<br />
* Relativ unempfindlich gegen Überspannung zwischen Drain und Source. Bei Überschreitung der Maximalspannung zwischen Drain und Source findet ein sogenannter "Durchbruch" statt. Dies ist vergleichbar mit dem Zener-Effekt. Ist die Energiemenge begrenzt, ist dieser Durchbruch reversibel und der FET wird NICHT zerstört. Beim Bipolartransistor ist die dafür zulässige Energiemenge viel kleiner, weil die den Strom durchquerende Fläche zu Hotspots neigt.<br />
* Möglichkeit eines Stromfühler-Anschlusses: Durch geeignete Geometrie kann der Source-Anschluss aufgeteilt werden, etwa im Verhältnis 1:9 bis 1:99. Der Drainstrom teilt sich kontrolliert auf, auch wenn am „kleineren“ Source-Anschluss ein Messwiderstand zur Spannungs-Strom-Wandlung angeschlossen ist. Leider sind solche „Sense-MOSFETs“ selten einzeln und faktisch nie als P-Kanal-Typen verfügbar. In integrierten (Schaltnetzteil-)Schaltungen sind sie Standard.<br />
<br />
=== Nachteile des FET ===<br />
<br />
* Nur bedingt für hohe Spannungen [[Transistor#Wann setzt man einen MOSFET, Bipolartransistor, IGBT oder Thyristor ein ? |geeignet]], die ON-Verluste sind ab ca. 250V höher als bei einem [[IGBT]]. <br />
* Parasitäre Diode parallel zur Drain-Source Strecke ist immer enthalten, das (Ab-)Schaltverhalten dieser Dioden ist meist schlechter als separate Dioden, was häufig zu unerwünschten Schwingungen führt.<br />
* Empfindlicher gegen ESD am Gate als BJT<br />
* Positiver Temperaturkoeffizient (TK), der <math>R_{DS,on}</math> ist stark temperaturabhängig und steigt von 25°C (Datenblattangabe) auf 150°C ungefähr um den Faktor 2. Dadurch steigen auch die Verluste und damit die Erwärmung des Bauteiles.<br />
<br />
=== Erklärung der wichtigsten Datenblattwerte ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! style="width:12em" | '''Parameter'''<br />
! style="width:7em" | '''Symbol'''<br />
! style="width:6em" | Beispiel<br />
! '''Erklärung'''<br />
|-<br />
| Drain Source Voltage <br>(Breakdown) || V(BR)_DSS <br> V_DS || 75 V || Maximale Spannungsfestigkeit des Bauteiles zwischen Drain und Source<br />
|-<br />
| Continuous Drain Current || I_D(on) || 55 A @ 125 °C || Maximaler Dauerstrom bei 125°C Gehäusetemperatur <br />
|-<br />
| Pulsed Drain Current || ID_pulse <br> I_CD(on) || 240 A || Maximaler Pulsstrom (Achtung die zulässige Zeitdauer des Pulses kann nur über die maximale Junctiontemperatur ermittelt werden)<br />
|-<br />
| Gate Charge || Q<sub>GS</sub> || 320 nC || Gate-Ladung in Coloumb oder Amperesekunden, die zum Ein- oder Ausschalten des MOSFET erforderlich ist. Dies berücksichtigt die Nichtlinearität der Kapazität und (richtig?) den Miller-Effekt. Mit dieser Angabe wird der für das Schalten von Leistungs-MOSFET benötigte Gatestrom für eine bestimmte Schaltzeit ermittelt. Dieser liegt üblicherweise im einstelligen Ampere-Bereich. Moderne Typen mit extra geringer Gate-Ladung können so schneller schalten.<br />
|-<br />
| Repetetive Avalanche Energy || t_sc || 280 mJ || Maximale Energie, welche beim Avalanche Durchbruch bei Überschreiten der maximalen Drain-Source Spannung im MOSFET bei z.&nbsp;B. 1% Puls/Pausen Verhältnis regelmäßig auftreten darf, ohne den FET zu schädigen<br />
|-<br />
| Drain-Source<br>ON Resistance || R<sub>DS_ON</sub> || 0,01 Ω || Widerstand des eingeschalteten FETs bei '''25°C''', V_GS = 10V und ID = 30A<br />
|-<br />
| Drain-Source<br>ON Resistance || R<sub>DS_on</sub> || 0,021 Ω || Widerstand des eingeschalteten FETs bei '''175°C''', V_GS = 10V und ID = 30A<br />
|-<br />
| Thermal Resistance<br>(junction-case) || R<sub>th_JC</sub> || 0,8 K/W || Thermischer Widerstand im Transistor vom der „Sperrschicht“ (junction eines Bipolartransistors, ja altmodischer Index, hier besser „Kanal“) bis zur Rückseite oder bestmöglichen Kühlmöglichkeit des Transistorgehäuses (case)<br />
|-<br />
| Gate-Source<br>Threshold Voltage || V_GS(th) || 2,0-4,5 V || Gatespannung, ab welcher der Transistor minimal leitend wird (I_D typisch 100-200µA), große Toleranz, typisch 1:2 zwischen Minimum und Maximum<br />
|-<br />
| Turn-on Delay || t_d(on) || 40 ns || Verzögerung zwischen dem Einschalten am Gate bis zur Reaktion im Drainstrom<br />
|-<br />
| Rise Time || t_r || 200 ns || Anstiegszeit des Transistorstromes am Drain<br />
|-<br />
| Turn-off Delay || t_d(off) || 120 ns || Verzögerung zwischen Abschalten am Gate bis zur Reaktion im Drainstrom<br />
|-<br />
| Fall Time || t_f || 60 ns || Abfallzeit des Transistorstromes am Drain <br />
|}<br />
<br />
Die oben genannten Zeiten gelten ausschließlich unter den angegebenen Messbedingungen (Gatewiderstand, Treiberspannung, sowie einer '''FET-Teperatur von 25°C!''') und müssen für die eigene Anwendung ggf. neu berechnet werden. Meist wird man sie eher messen, weil die Rechung zu aufwändig und bisweilen unmöglich ist. <br />
<br />
==== Gate-Source Threshold Voltage ====<br />
Gerade bei der '''Gate-Source Threshold Voltage <math>V_{GS}(th)</math>''' gibt es hier immer wieder Verwirrung. Sie gibt an, ab welcher Spannung der MOSFET anfängt, minimal leitfähig zu werden. Diese Spannung ist technologisch bedingt auch heute noch einer starken Toleranz unterworfen, typischerweise hat der Bereich bei dem der FET zu leiten beginnt eine Spreizung von etwa 1:2 zwischen Minimum und Maximum. Welche Spannung man nun wirklich anlegen muss, um den gewünschten <math>R_{DS}(on)</math> zu erreichen kann der Tabelle im jeweiligen Datenblatt entnommen werden. Dabei unbedingt die angegebene Gatespannung beachten, nur dieser Wert ist garantiert!.<br />
<br />
[[bild: IRLZ34N_R_DS_ON.png | thumb | 800px | R_DS_ON im Datenblatt des IRLZ34N]]<br />
{{Clear}}<br />
<br />
Die Kurvenschar von <math>I_D</math> über <math>U_{DS}</math> in Abhängigkeit von <math>U_{GS}</math> stellt immer nur typische Werte dar, keine garantierten Extremwerte (engl. worst case). Als Standardwerte kann man 10-15V für einen Standardtypen und ca. 3-5V für einen Logic Level MOSFET (LL-FET) ansetzen. Kleinsignal-FETs leiten schon ab ca 1V. Bei Ansteuerung mit 5V benötigt man also einen Typen, der '''sicher''' bei 5V voll durchgesteuert ist, z.B. IRLZ34N. Bei 3,3V ist er bereits nicht mehr zuverlässig nutzbar. Es gibt auch Typen mit noch geringerer Spannung für Vollaussteuerung. Wer einen BUZ11 (<math>V_{GS}(th)</math> 4V max.) mit 5V ansteuert riskiert ein Abfackeln des MOSFETs, denn je nach Toleranz kann er bereit ganz gut aufgesteuert sein oder auch nicht. Das soll in den nachfolgenden Diagrammen dargestellt werden. Zunächst die Transferkennlinie. Sie gibt an, wieviel Drainstrom in Abhängigkeit der Gatespannung fließen kann, wobei die Drainspannung konstant ist, hier im Beispiel 25V. Ein typischer BUZ11 (mittlere, schwarze Kurve) fängt bei 3V zu leiten an und erreicht bei 6V am Gate ca. 17A. Erwischt man nun ein kritisches Exemplar, das erst bei 4V zu leiten anfängt (rechte, rote Kurve um 1V parallel verschoben), so kann dieser bei 6V nur 8A leiten, für 17A braucht er 7V. Der günstige Fall, daß der BUZ11 schon bei 2V anfängt zu leiten sieht man in der linken, roten Kurve.<br />
<br />
[[bild: BUZ11_UGS_ID.png | thumb | 800px | Transferkennlinie des BUZ11]]<br />
{{Clear}}<br />
<br />
Wenn man die drei Fälle (min, typ, max) mit 5V ansteuert, erhält man die Arbeitspunkte 1-3 mit einem maximal schaltbaren Drainstrom von 2,5, 8 und 17A. Diese kann man in das Ausgangskennlinienfeld übertragen. Wir nehmen max. 1V U_DS an. Es ergeben sie die gleichen Ströme. Der maximale Drainstrom weicht um -5,5/+9A vom typischen Fall ab. Erhöht man nun die Gate-Source Spannung auf 10V (Arbeitspunkt 4), schwankt der maximal schaltbare Drainstrom nur noch um -2/+2A, außerdem liegt er mit 30A deutlich höher. Der BUZ11 ist somit sicher durchgesteuert.<br />
<br />
[[bild: BUZ11_UDS_ID_UGS.png | thumb | 800px | Ausgangskennlinie des BUZ11]]<br />
{{Clear}}<br />
<br />
==== Parasitäre Diode ====<br />
<br />
Der Schwerpunkt in der FET-Entwicklung liegt auf den geringst-möglichen <math>R_{DS}(on)</math>, die Diode entsteht auf Grund des Herstellungsprozesses, und wird nur nachrangig verbessert, da viele Optimierungsversuche auch einen Einfluss auf wichtige Kennwerte des FETs hatten und haben.<br />
Daher muss sorgfältig geprüft werden, ob die Schaltgeschwindigkeit, die Recovery-Time und die damit verbundenen Verluste sowie die dabei erzeugte unerwünschte EMV-Abstahlung tolerierbar ist, oder nicht.<br />
Hier hilft es oft eine optimierte Diode / Schottky-Diode zum FET parallel zu schalten. Ganz ausblenden läßt sich die parasitäre Diode jedoch nicht, jedoch kann man den Anteil des Stromes beeinflussen, der über die intere Diode fliest.<br />
<br />
{| class="wikitable"<br />
|+ ''' Parasitäre Diode des FETs '''<br />
|-<br />
! style="width:10em" | '''Parameter'''<br />
! style="width:6em" | '''Symbol'''<br />
! style="width:6em" | '''Beispiel'''<br />
! '''Erklärung'''<br />
|-<br />
| Continuous Current || I_S || 75A || Maximaler Dauerstrom der parasitären Diode, meist identisch zum maximalen Dauerstrom des MOSFETs<br />
|-<br />
| Forward Voltage || V_SD || 1,3V || Spannungsfall an der parasitären Diode <br />
|-<br />
| Reverse Recovery Time || t_rr || 120ns || Zeit, welche die Elektronen brauchen um aus der leitenden Diode vollständig abzufließen. Während dieser Zeit fließt der Strom in '''Rückwärtsrichtung''' durch die Diode und erzeugt relativ viel Verlustleistung. <br />
|-<br />
| Reverse Recovery Charge || Q_rr || 60nC || Ladungsmenge, die während t_rr rückwärts durch die Diode fließt. <br />
|}<br />
<br />
== Haupttypen und Gatespannungslevel ==<br />
<br />
===Unterschied N-Kanal / P-Kanal FET===<br />
<br />
Im Schaltsymbol werden die MOSFET-Typen meist durch die Pfeilrichtung in der Mitte des Symbols (eigentlich "Bulk") vom oder zum Gate unterschieden. Zeigt der Pfeil zum Gate hin, handelt es sich um einen N-Kanal-FET, zeigt der Pfeil vom Gate weg um einen P-Kanal FET.<br />
<br />
Der große Vorteil des N-Kanal FETs (Elektronenleitung) ist, daß er immer niederohmiger ist, als ein gleich großer P-Kanal FET (Löcherleitung). Daher sind P-Kanal Typen bei vergleichbaren Werten auch immer größer = teuerer da weniger Chips auf einem Wafer Platz haben.<br />
<br />
Beim N-Kanal FET muss die Gatespannung positiv gegenüber Source sein. Dabei wird der FET dann leitend, wenn die sogenannte "threshold voltage" (Schwellenspannung) erreicht wird. Eine typische Anwendung ist z.&nbsp;B. ein '''Low-Side Schalter''': Source an GND, Drain an die Last, Ansteuerung des N-Kanal FETs mit 12V gleichbedeutend mit 12V ÜBER den Source = GND Potential.<br />
<br />
Beim P-Kanal FET als HS-Schalter muss die Gatespannung negativer=niedriger als das Sourcepotential sein.Beispiel.<br />
Beispiel: <br />
Lastspannung = 400V d.h. Source an 400V, Last zwischen Drain und GND, Ansteuerung des P-Kanal FETs mit 388V, also 12V UNTER dem Sourcepotential.<br />
<br />
Beim N-Kanal FET als HS-Schalter muss die Gatespannung positver=höher als das Sourcepotential sein.<br />
Beispiel:<br />
Lastspannung = 400V d.h. Drain an 400V, die Last zwischen Source und GND, Ansteuerung des N-Kanal FETs mit 412V, also 12V ÜBER dem Sourcepotential.<br />
In diesem Fall ist aber eine zusätzliche Spannungsquelle erforderlich, denn der FET wird mit einer Spannung über der Lastspannung eingeschaltet. <br />
<br />
'''Weblinks'''<br />
* [https://www.eetimes.com/a-primer-on-high-side-fet-load-switches-part-1-of-2/?utm_source=eetimes&utm_medium=networksearch A primer on high-side FET load switches (Part 1 of 2)], Qi Deng, Senior Product Marketing Manager, Mixed-Signal Products, Micrel, Inc., 5/3/2007 4:14 PM EDT, www.eetimes.com<br />
* [https://www.eetimes.com/a-primer-on-high-side-fet-load-switches-part-2-of-2/ A primer on high-side FET load switches (Part 2 of 2)], Qi Deng, Senior Product Marketing Manager, Mixed-Signal Products. Micrel, Inc., 5/7/2007 1:36 PM EDT, www.eetimes.com<br />
* [http://www.vishay.com/docs/70611/70611.pdf AN804 P-Channel MOSFETs, the Best Choice for High-Side Switching (PDF)] von Vishay Siliconix<br />
<br />
===Unterschied Logic-Level / „Normal“-Level===<br />
<br />
Den meisten FETs ist gemein, daß sie mit einer Spannung von 10..15 V angesteuert werden müssen, um den minimalen Einschaltwiderstand zu erreichen. Diese FETs lassen sich nicht ohne weiteres mit einem CMOS-Pegel von 5V ansteuern. Es gibt jedoch für diesen Anwendungsfall sogenannte „Logic Level“ (LL) FETs, die schon bei einer Gatespannung von etwa 4,5V voll durchgesteuert sind. Einige Kleinsignal-FETs sind schon ab ca. 1,2V voll durchgesteuert.<br />
<br />
Hochvolt-MOSFETs für Schaltnetzteil-Anwendungen gibt es ''faktisch nie'' als Logic-Level-Typen, weswegen Ansteuerschaltkreise wie UC3842 eine Unterspannungsabschaltung bei 10 V haben. Um Steuerleistung zu sparen ist hier die (niedrige) Gate-Ladung (gate charge) der wichtigere Kennwert.<br />
<br />
Die Schaltschwelle ergibt sich aus Dotierung und Chipgeometrie. Diese muss für Logic-Level-Typen besonders engtoleriert gehalten werden da ein „zu niedrig“ zur Selbstleitung führt (= Depletion Mode MOSFET) — ein unerwünschtes Betriebsverhalten. Das ist auch der Grund, warum die berühmt gewordene Standard-CMOS-Serie 4000 mit relativ hoher Spannung betrieben wurde, ganz zu schweigen von NMOS (12 V, dazu -5 V Substratvorspannung: EPROM 2708) oder gar PMOS (27 V): „Logic Level“, damals 5 V Logikspannung, war für MOSFET noch nicht sicher beherrschbar und hat allenfalls komplementär funktioniert.<br />
<br />
== Beispiel zur Bauteiledimensionierung ==<br />
<br />
=== Spannungsfestigkeit ===<br />
<br />
Die höchste vorkommende Betriebsspannung + Abschaltüberspannung soll kleiner als ca. 80% der Spannungsfestigkeit des Bauteiles sein. <br />
<br />
Achtung: Zwischen dem je nach Anwendungsfall erforderlichen Pufferkondensator und dem FET wird es immer eine parasitäre Induktivität geben.<br />
Abhängig von Schaltgeschwindigkeit und Induktivität wird im Schaltmoment eine mehr oder weniger große Übrspannungsspitze produziert. Dieser Peak<br />
addiert sich auf die aktuelle Versorgungsspannung.<br />
<br />
Überschlagsrechnung als Beispiel:<br />
* Schaltgeschwindigkeit: dI/dt = -100A/µs (= Abschalten von 5A innerhalb 50ns),<br />
* Induktivität: L = 1µH (~ 1 m loses, ungebündeltes Kabel)<br />
* dU=-L*dI/dt = -1µH * (-100A / 1µs) = 100V<br />
<br />
Dies bedeutet, daß an der "Induktivität" zwischen Transistor und Kondensator - Aufgrund von Selbstinduktion im Schaltmoment - ein Überspannungspuls von ca. 100V entsteht, der auf die Betriebsspannung aufzuschlagen ist, also lieber die Leitung kürzer machen, und - sofern möglich - nicht ganz so schnell schalten.<br />
<br />
=== Stromtragfähigkeit ===<br />
<br />
In jedem Datenblatt ist eine Stromtragfähigkeit bei 25°C, und meist noch bei einer höheren Temperatur z.B. 125°C, 150°C oder 175°C Kühlfahnentemperatur angegeben. Dieser Wert ist als ERSTE Entscheidungsgrundlage ausreichend, aber aus der theoretisch abführbaren Verlustleistung errechnet, und<br />
* dient zum qualitativen Vergleich von Transistoren bezüglich ihres R_ds(on) und ihres Wärmewiderstands.<br />
* ist für die Dimensionierung einer Schaltung nur als Richtwert zu interpretieren. <br />
* ist ohne Schaltverluste genannt, und daher nur für einen Schaltbetrieb von wenigen Hz gültig. Außerdem wird ein annähernd idealer Kühlkörper unterstellt, der trotz der Verlustleistung das Gehäuse des Transistors auf der angegebenen Temperatur halten kann.<br />
* entbindet einen nicht davon den Kopf einzuschalten... siehe die nachfolgenden Zeilen.<br />
* Liegt der Strom für den die Schaltung entwickelt wird mit ca. 10..20% Abstand unter dem Datenblattwert von 125°C ist dieses Bauteil vermutlich verwendbar (siehe Detailberechnungen unten !). <br />
* Ist der benötigte Strom im Bereich oder größer als der zulässige bei 125°C sollte entweder ein anderer Typ eingesetzt oder mehrere FETs ''des gleichen Typs'' parallelgeschaltet werden.<br />
<br />
== Verlustleistung ==<br />
<br />
Hier wird eine Näherung für eine getaktete Anwendung betrachtet. In einem Transistor treten sowohl beim Ein- und Ausschalten, als auch während der Einschaltphase Verluste im Bauteil auf. Diese Verluste führen zu einer Bauteilerwärmung. Die dabei entstehende Temperatur darf die maximal zulässige Bauteiletemperatur nie überschreiten. Bei den ersten Projekten ist zu empfehlen eine berechnete Chiptemperatur von ca. 125°C nicht zu überschreiten. Fast alle aktuell verfügbaren FETs nennen im Datenblatt eine Temperatur von 175°C als ihre maximale Chiptemperatur.<br />
<br />
{| class="wikitable" style="width:32em" <br />
|+ '''Beispiel'''<br />
|-<br />
! Parameter<br />
! style="width:8em" | Symbol<br />
! style="width:8em" | Wert<br />
|-<br />
| Betriebsspannung || U<sub>N</sub> || 70 V<br />
|-<br />
| Nennstrom || I<sub>N</sub> || 30 A<br />
|-<br />
| Drain-Source Widerstand bei<br>Chiptemperatur: 125°C<br> Gatespannung: 10V || R<sub>DS<sub>on</sub></sub> || 17 mΩ<br />
|-<br />
| Pulsbreite || t<sub>on</sub> || 150 µs<br />
|-<br />
| Schaltfrequenz || ƒ<sub>schalt</sub> || 5 kHz<br>T = 200µs<br />
|-<br />
| Einschaltzeit (risetime) || t<sub>r</sub> || 500 ns<br />
|-<br />
| Ausschaltzeit (falltime) || t<sub>ƒ</sub> || 800 ns <br />
|-<br />
|}<br />
<br />
==== Leitend-Verluste ====<br />
<br />
Während der FET bei [[PWM]]-Ansteuerung eingeschaltet ist, erzeugt er Verlustleistung.<br />
<br />
<math><br />
P_\text{ON}<br />
= {I_\mathrm{N}}^2 \cdot R_\mathrm{DS_\mathrm{ON}} \cdot \frac{t_\mathrm{ON}}{T}<br />
= 30^2A^2 \cdot 17m\Omega \cdot \frac{150\mu s}{200\mu s} = 11{,}5W<br />
</math><br />
<br />
==== Schalt-Verluste ====<br />
<br />
Vereinfachter Ansatz.<br />
<br />
Einschalten:<br />
<br />
:<math>\begin{align}<br />
P_\mathrm{SW_r}<br />
&= \tfrac14 \cdot U_N \cdot I_N \cdot \frac{t_r}{T} \\<br />
&= \tfrac14 \cdot 70V \cdot 30A \cdot \frac{500ns}{200\mu s}=1{,}3W<br />
\end{align}</math><br />
<br />
Ausschalten:<br />
<br />
:<math>\begin{align}<br />
P_\mathrm{SW_f} <br />
&=\tfrac14 \cdot U_N \cdot I_N \cdot \frac{t_f}{T}\\<br />
&=\tfrac14 \cdot 70V \cdot 30A \cdot \frac{800ns}{200\mu s}=2{,}1W<br />
\end{align}</math><br />
<br />
Alternativ und genauer kann man rechnen, wenn die Ein- Ausschaltenergie im Datenblatt angegeben ist. Aber Achtung! Die Randbedingungen unter denen die genannte Energie ermittelt wurde, müssen genau so zutreffen.<br />
:<math>\begin{align}<br />
P_{SW_f} = f_{schalt} \cdot E_{ON}<br />
\end{align}</math><br />
:<math>\begin{align}<br />
P_{SW_r} = f_{schalt} \cdot E_{OFF}<br />
\end{align}</math><br />
<br />
Die Gesamtverlustleistung beträgt also in etwa 15W.<br />
<br />
Damit muß ein entsprechender [[Kühlkörper]] ausgelegt und die Chiptemperatur berechnet werden. z.&nbsp;B.:<br />
* Kühlkörper mit einem R_th von 0,2K/W<br />
* max. Umgebungstemperatur +60°C<br />
* R_th "junction-case" des FETs 0,8K/W<br />
* R_th der Wärmeleitfolie zwischen FET und Kühlkörper ca. 2,0K/W<br />
* R_th gesamt: 3,0K/W <br><br />
* Bei einer Verlustleistung von 18W und einer Umgebungstemperatur von 60°C hat der Chip eine Temperatur von ca. 18W * 3,0K/W +60°C = 114°C. ==> o.k.!<br />
<br />
Unter Berücksichtigung der Tatsache, daß hier viele Vereinfachungen vorgenommen, und die Art der Last nicht beachtet wurde ist es sinnvoll, einen gewissen Sicherheitsabstand zu den zulässigen Maximalwerten einzuhalten. Daher ist es empfehlenswert, die Chiptemperatur auf ca. 125°C zu beschränken. <br />
<br />
Des Weiteren ist hier die parasitäre Diode im FET nicht berücksichtigt.<br />
Wenn während der "off" Zeit ein Strom über die Diode fließt (Reverse recovery current oder Freilaufstrom), muß die dadurch '''zusätzlich''' entstehende Verlustleistung in die obige Berechnung der maximalen Chiptemperatur mit einfließen.<br />
<br />
==Treiberleistung==<br />
<br />
Auch wenn der MOSFET ein spannungsgesteuertes Bauelement ist, muss trotzdem bei jedem Einschalten und bei jedem Ausschalten die Gatekapazität umgeladen werden. Bei älteren Leistungs-FET - oder bei einem schlechten Design (!) - muss sogar teilweise mit negativer Spannung am Gate gearbeitet werden, um eine vollständige Sperrung zu erreichen.<br />
Diese Umladung muss möglichst schnell erfolgen, um die Verluste im FET während der Umschaltphase zu minimieren. Dazu findet ein [[Mosfet-Übersicht#MOSFET-Treiber|MOSFET-Treiber]] Verwendung. Hier eine detaillierte Beschreibung zum [[Treiber]].<br />
<br />
Da die Gatekapazität nicht direkt im Datenblatt enthalten ist kann man sich mit der Eingangskapazität Ciss behelfen. Im Arbeitspunkt ist die Gatekapazität ungefähr 5x größer als der im Datenblatt für Ciss angegebene Wert. <br />
Daher berechnet sich die Treiberleistung wie folgt: <br />
<br />
:<math>P_\text{Treiber} = C \cdot U^2 \cdot f = 5 \cdot C_\text{íss} \cdot U_\text{Gate}^2 \cdot f_\text{schalt}</math><br />
<br />
1.Beispiel, kleine MOSFET-Steuerung mit niedriger Leistung und Frequenz.<br />
<br />
:<math>P_\text{treiber} = 5 \cdot 4{,}8\,\text{nF} \cdot 15\,\text{V}^2 \cdot 10\,\text{kHz} = 54\,\text{mW}</math><br />
<br />
2.Beispiel, sehr große MOSFET-Steuerung für Induktionsheizung mit sehr hoher Leistung und Frequenz.<br />
<br />
:<math>P_\text{treiber} = 5 \cdot 24\,\text{nF} \cdot 15\,\text{V}^2 \cdot 250\,\text{kHz} = 6{,}75\,\text{W}</math><br />
<br />
Aber Achtung, so ein MOSFET-Treiber hat auch einen Eigenverbrauch, der leicht zwischen 0,5 und 1 W liegen kann.<br />
<br />
Bei niedrigen PWM-Frequenzen kann man Logic Level MOSFETs auch direkt per CMOS-Ausgang ansteuern, z.B. mit einem [[AVR]], wie in diesem [http://www.mikrocontroller.net/topic/246449#2519459 Forumsbeitrag] zu sehen ist.<br />
<br />
== Low- und High-Side ==<br />
<br />
Definition LS- und HS:<br />
<br />
;Low-Side Schalter: Der FET schaltet eine Last gegen GND - auch als LS-Schalter bezeichnet.<br />
;High-Side Schalter: Der FET schaltet eine Last an die Versorgungsspannung – auch als HS-Schalter bezeichnet.<br />
<br />
Anregungen oder Fragen auch gerne per Email an [http://www.mikrocontroller.net/user/show/powerfreak Powerfreak]. Dieser Artikel kann dadurch regelmäßig erweitert und ggf. durch ein FAQ ergänzt werden.<br />
<br />
<br />
== SOA Diagramm ==<br />
<br />
SOA-Diagramm (engl. '''S'''afe '''O'''perating '''A'''rea, sicherer Arbeitsbereich) beschreibt die zulässige Verlustleistung eines Transistors in Anhängigkeit des Drainstroms (I_D), der Drain-Source Spannung (U_DS) und der Pulsbreite. Als Beispiel sei hier der BUZ 11 genannt. Im nachfolgenden Diagramm ist das SOA-Diagramm dargestellt. Wie ist es zu verstehen? Zunächst gibt es eine Grenze auf der linken Seite, die schräge, dunkelblaue Line. Diese wird durch den minimalen R_DS_ON festgelegt, hier wirkt der MOSFET wie ein ohmscher Widerstand. Mehr Strom kann bei einer bestimmten Spannung nicht fließen. Die zweite Grenzlinie ist ganz rechts die pinkfarbene Linie, sie stellt die maximale Sperrspannung des MOSFET dar. Die dritte Grenze ist der maximal zulässige Drainstrom, hier im Beispiel 120A, dargestellt durch die gelbe Linie. Die maximale Spannung zwischen Drain und Source sowie der Drainstrom sind abhängig von der Pulsbreite, mit welcher der MOSFET betrieben wird. Bei nur 2,5µs Pulsbreite (Rechteckimpuls) müssen die beiden Parameter sich innerhalb der Fläche bewegen, welche durch die dunkelblaue, gelbe und die pinkfarbene Line begrenzt wird. Im Extremfall dürfen 50V anliegen und 120A fließen, das sind satte 6kW Pulsleistung! Werden die Pulse breiter, so sinken die zulässigen Ströme und Spannungen, bei 1ms (dunkelblaue Linie bis zur braunen Linie, dann zur pinkfarbenen Linie) sind maximal noch 50V und 7A zulässig, also nur noch 350W. Die letzte Linie stellt den Fall für Gleichstrom (engl. '''D'''irect '''C'''urrent), also Dauerbelastung dar, hier sind bei 50V maximal 1,5A zulässig, was einer Dauerverlustleistung von 75W entspricht. MOSFETs, welche nur für Schaltbetrieb und nicht für [[#Linearbetrieb von MOSFETs | Linearbetrieb]] geeignet sind, haben keine Kennlinie für DC. Im normalen Schaltbetrieb liegt der Arbeitspunkt auf der linken Grenzlinie R_DS_ON_MIN. Nur im Linearbetrieb liegt der Arbeitspunkt innerhalb der Fläche, welche durch die Außenlinien begrenzt wird.<br />
<br />
[[bild: SOA-BUZ11.png | thumb | 300px| SOA-Diagramm]]<br />
<br />
Bei der Anwendung des Diagramms gilt es einiges zu beachten. Die Pulsleistungen sind nur zulässig, wenn der MOSFET vorher kalt ist, sprich ca. 25°C Sperrschichttemperatur hat. War er vorher schon heiß, reduziert sich die zulässige Belastung deutlich. Ebenso dürfen die Pulse nicht zu schnell wiederholt werden, denn dann ist der MOSFET noch vom vorherigen Puls aufgeheizt. Im Fall von DC sind 75W Verlustleistung auch eher ein theoretischer Wert, welcher real nur schwer erreicht werden kann, wenn der MOSFET auf einem sehr großen [[Kühlkörper]] optimal montiert ist. Praktisch liegen die erreichbaren Werte eher bei der Hälfte.<br />
<br />
(Anm. Eigentlich müsste für die R_DS_ON Grenzlinie R = U / I der minimale R_DS_ON rauskommen, hier ~40mOhm, es kommen aber ~80mOhm raus. Die Ursache dafür ist unklar, möglicherweise liegt hier ein Sicherheitsfaktor zu grunde).<br />
<br />
{{Clear}}<br />
<br />
== Linearbetrieb von MOSFETs ==<br />
<br />
Der Großteil der Anwendungen nutzt MOSFETs als Schalter, d.h. der MOSFET ist entweder voll gesperrt oder voll durchgesteuert. Dafür gelten auch all die Hinweise in diesem Artikel. In bestimmten Anwendungen werden MOSFETs aber auch im Linearbetrieb eingesetzt, z.B in linearen Endstufen für Audio, Video, elektronischen Lasten und Stromquellen. Hier muss man einiges beachten. Ein verbreiteter Irrtum besteht darin zu glauben, MOSFETs könne man im Linearbetrieb einfach parallel schalten, weil der positive Temperaturkoeffizient von <math>R_{DS(ON)}</math> eine Symmetrierung bewirkt, ähnlich den Emitterwiderständen bei parallelgeschalteten Bipolartransistoren. Das ist ''ausschließlich'' im Schaltbetrieb möglich, und daher falsch! Im Linearbetrieb spielt der Temperaturkoeffizient von <math>R_{DS(ON)}</math> keine Rolle, weil der MOSFET selten bis nie komplett durchgesteuert ist. Eben darum ist beim Linearbetrieb der minimale <math>R_{DS(ON)}</math> in den meisten Fällen unwichtig und man kann auch eher hochohmige, ältere MOSFETs verwenden, wie z.B. den BUZ11.<br />
<br />
Hier wirkt vielmehr der negative Temperaturkoeffizient (TK) der Thresholdspannung <math>U_{GS(thr)}</math>, vergleichbar dem negativen TK der Basis-Emitter-Spannung von Bipolartransistoren. D.h. mit steigender Temperatur und konstanter Gate-Source-Spannung steigt der Stromfluss der Drain-Source Strecke. In einer Parallelschaltung von MOSFETs würde dies bedeuten, dass der MOSFET mit dem geringfügig größeren Drainstrom (Fertigungstoleranzen) wärmer wird, was zu einem weiter steigenden Drainstrom und damit noch mehr Wärme führt. Damit ist die Schaltung thermisch instabil und würde zum Durchbrennen der MOSFETs führen, einer nach dem Anderen. <br />
<br />
Um das zu verhindern muss man relativ große Ausgleichswiderstände in die Source-Leitung der einzelnen MOSFETs schalten, um diese Drift zu kompensieren. Dadurch verschlechtert sich natürlich der Wirkungsgrad des Verstärkers. MOSFETs haben einen TK von typisch -5mV/K für <math>U_{GS(thr)}</math>, das ist mehr als das doppelte von Bipolartransistoren mit typisch -2mV/K, weshalb die Symmetrierungswiderstände mehr als doppelt so groß sein müssen. Weiterhin muss man beachten, dass die Toleranzen von <math>U_{GS(thr)}</math> sehr groß sind, im Bereich von Volt! Das kann man sinnvoll nicht mehr mit Gatewiderständen symmetrieren, hier muss man die MOSFETs ausmessen und Gruppen mit geringen Toleranzen in einer Schaltung verwenden (engl. matching). <br />
<br />
Eine andere Möglichkeit ist die getrennte Ansteuerung der einzelnen MOSFETs, das wird oft in elektronischen Lasten bzw. [[Konstantstromquelle#Konstantstromquelle mit Operationsverstärker und Transistor | Konstantstromquellen]] gemacht. Hier treten keine zusätzlichen Verluste auf und der Mehraufwand in der Ansteuerung ist meist unkritisch.<br />
<br />
Weiterhin muss man beachten, dass viele der heutigen HochleistungsMOSFETs intern eine Parallelschaltung vieler kleiner MOSFET-Zellen (z.B. sogenannte Trench-FET) sind, und somit oft für den Linearbetrieb ungeeignet sind. Denn auch dort können einzelne Zellen überhitzen und durchbrennen (Hot Spot). Ob ein MOSFET für den Linearbetrieb tauglich ist steht manchmal im Datenblatt, oft aber eher nicht, eben weil die meisten MOSFETs als Schalter entwickelt und gebaut sind. Typische Vertreter für Linearbetrieb findet man in der [[MOSFET-Übersicht]]. Ein wichtiges Indiz für Linearbetrieb ist eine Kurve für DC im [[#SOA_Diagramm | SOA-Diagramm]]. Meist geht es dort nur bis 10ms, DC fehlt, eben weil DC (engl. '''D'''irect '''C'''urrent = Gleichstrom = Linearbetrieb) nicht zulässig ist. Manchmal hat der Hersteller auch "vergessen", die Kennlinie für DC mit reinzuschreiben, wie z.B. bei [http://www.irf.com/product-info/hi-rel/alerts/fv5-p-09-01-A.pdf IRF], wie in diesem [http://www.mikrocontroller.net/topic/291760#3106758 Beitrag] zu erfahren ist.<br />
Ein recht gutes Indiz dafür, ob ein FET für den Linearbetrieb taugt, ist die Vorwärtssteilheit. Diese kennzeichnet die Abhängigkeit des Drainstromes von der Ansteuerung am Gate als <math>S = \Delta i_d/\Delta u_{gs}</math>. Moderne Trench-FET erreichen heute Steilheiten im dreistelligen Bereich und sind für Linearanwendungen völlig unbrauchbar. Zum Vergleich: Der BUZ11 kommt mit gerade einmal 4 bis 5 Siemens daher.<br />
<br />
In diesem Beitrag wird die DC-Linie im SOA-Diagramm noch genauer erklärt: [http://www.mikrocontroller.net/topic/319961#3473567 Re: MOSFET Linearbetrieb möglich?]<br />
<br />
<br />
== Siehe auch ==<br />
<br />
* [[Leistungselektronik]]<br />
* [[Mosfet-Übersicht]]<br />
* [[IGBT]]<br />
* [[TRIAC]]<br />
* [[Kühlkörper]] <br />
* [[Zwischenkreiskapazität]]<br />
* [[Treiber]]<br />
* [[Snippets#Wie_schlie.C3.9Fe_ich_einen_MOSFET_an_einen_Mikrocontroller_an.3F|Wie schließe ich einen Mosfet an einen Mikrocontroller an?]]<br />
* [http://www.mikrocontroller.net/articles/H-Br%C3%BCcken_%C3%9Cbersicht Übersicht H-Brücken]<br />
* [http://www.mikrocontroller.net/topic/168218#1609684 Forumsbeitrag]: MOSFETs im Linearbetrieb<br />
* [http://www.mikrocontroller.net/topic/186785#new Forumsbeitrag]: nochmal MOSFETs im Linearbetrieb<br />
* [http://www.mikrocontroller.net/topic/319961#3473567 Forumsbeitrag]: sehr ausführlicher Forumsbeitrag über MOSFETs im Linearbetrieb. Berücksichtigt auch den Spirito-Effekt.<br />
* [http://www.mikrocontroller.net/topic/143324#new Forumsbeitrag]: Über eine elektronische Last, sehr lang<br />
*[http://www.mikrocontroller.net/topic/246449#2519459 Forumsbeitrag]: Logic Level MOSFETs direkt mit einem [[AVR]] treiben.<br />
* [http://www.mikrocontroller.net/topic/267254#2787855 Forumsbeitrag]: MOSFETs im Linearbetrieb, Laborerfahrungen<br />
* [http://www.mikrocontroller.net/topic/267254#2787945 Forumsbeitrag]: MOSFETs für Linearbetrieb<br />
* [https://www.mikrocontroller.net/topic/269642?goto=2820617#2820617 Forumsbeitrag]: Verpol- und Überspannungsschutz mit MOSFETs<br />
* [https://www.mikrocontroller.net/topic/425414#4981611 Forumsbeitrag]: Linearbetrieb von MOSFETs<br />
<br />
== Weblinks ==<br />
<br />
* [http://www.elektronikinfo.de/strom/feldeffekttransistoren.htm Feldeffekttransistoren bei elektronikinfo.de]<br />
* [http://www.elektronik-kompendium.de/sites/bau/0207011.htm FET im ELKO]<br />
* [http://www.elektronik-kompendium.de/sites/bau/0510161.htm MOSFET im ELKO]<br />
* [http://www.sprut.de/electronic/switch/nkanal/nkanal.html MOSFET bei sprut.de]<br />
* [http://sound.westhost.com/articles/hexfet.htm#51 MOSFETs in Audioendstufen, engl.]<br />
* [http://irf.custhelp.com/cgi-bin/irf.cfg/php/enduser/std_adp.php?p_faqid=214&p_created=1019728945&p_sid=pt9ITiCj&p_accessibility=0&p_redirect=&p_lva=&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9MTQsMTQmcF9wcm9kcz0mcF9jYXRzPSZwX3B2PSZwX2N2PSZwX3BhZ2U9MSZwX3NlYXJjaF90ZXh0PWxpbmVhcg**&p_li=&p_topview=1 FAQ Answer ID 214 bei IRF zum Linearbetrieb]<br />
* [http://www.nxp.com/documents/application_note/AN11158.pdf AN11158 - Understanding power MOSFET data sheet parameters] von NXP (PDF)<br />
* [https://assets.nexperia.com/documents/technical-note/TN00008.pdf TN00008 - Power MOSFET frequently asked questions and answers] von nexperia (PDF)<br />
* [http://www.infineon.com/dgdl/Infineon+-+Application+Note+-+PowerMOSFETs+-+OptiMOS%E2%84%A2+-+Linear+Mode+Operation+and+SOA+Power+MOSFETs.pdf?fileId=db3a30433e30e4bf013e3646e9381200 AN: Linear Mode Operation andSafe Operating Diagram of Power-MOSFETs] von Infineon (PDF)<br />
* [http://www.ixys.com/Documents/Articles/Article_Linear_Power_MOSFETs.pdf MOSFETs Withstand Stress of Linear-Mode Operation] Neuentwickelte MOSFETs für Linearbetrieb (PDF)<br />
<br />
[[Kategorie:Bauteile]] [[Kategorie:Leistungselektronik]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=FET&diff=107028FET2024-07-19T16:59:09Z<p>Heha: Stromfühler-Anschluss</p>
<hr />
<div>Dieser Artikel versteht sich als Unterpunkt zum Artikel [[Leistungselektronik]]<br />
<br />
<br />
Ein FET (engl. '''F'''ield '''E'''ffect '''T'''ransistor) ist ein Feldeffekttransistor. Der FET ist ein Bauelement, das im Gegensatz zum Bipolartransistor (engl. '''B'''ipolar '''J'''unction '''T'''ransistor, BJT) mit Spannung und nicht mit Strom gesteuert wird. Weil keine P-N-Sperrschichten am Stromfluss beteiligt sind, heißen diese auch Unipolartransistoren. Unterschieden werden<br />
<br />
* MOSFET = engl. '''M'''etall '''O'''xide '''S'''emiconductor '''F'''ield '''E'''ffect '''T'''ransistor; Metalloxidschicht-FET, größte Teilgruppe der FETs mit isoliertem Gate.<br />
<br />
* JFET = engl. '''J'''unction '''F'''ield '''E'''ffect '''T'''ransistor, Übergangszonen-FET, der steuerbare Kanal wird durch einen PN-Übergang wie in einer Diode gebildet. <small>(Diese Diode lässt sich nachmessen und unterscheidet JFET von (selbtleitenden) MOSFET, auch wenn sie schaltungstechnisch keine Rolle spielt. Wichtig: JFETs gibt es ''nur'' selbstleitend!)</small><br />
<br />
Die drei Anschlüsse eines FETs werden ''Gate'', ''Drain'' und ''Source'' genannt. Unter Umständen ist ein vierter Anschluß vorhanden, der ''Bulk'' genannt wird. Normalerweise ist Bulk intern mit Source verbunden. <small>Wenn dies nicht der Fall ist, muss diese Verbindung durch den Designer in der Schaltung hergestellt werden. Nicht gesichtet für Leistungstransistoren.</small><br />
<br />
== FET-Typen ==<br />
<br />
FETs werden hauptsächlich unterschieden in N-Kanal und P-Kanal, sowie "selbst sperrend = Anreicherungstyp" (engl. enhancement type) und "selbst leitend = Verarmungstyp" (engl. depletion type). Beim selbstleitenden FET ist der Transistor bei 0V Gate-Source Spannung maximal leitend (durchgesteuert) und wird durch Anlegen einer Spannung ans Gate gesperrt. Beim selbstsperrenden FET (größte Gruppe) ist der Transistor bei 0V Gate-Source Spannung gesperrt und wird durch Anlegen einer Spannung ans Gate leitend. Ist die Linie zwischen Drain und Source durchgezogen handelt es sich um einen selbstleitenden, bei einer gestrichelten Linie um einen selbstsperrenden FET. JFETs gibt es nur als Verarmungstyp.<br />
<br />
Im weiteren Artikel wird nur der '''selbstsperrende''' MOSFET betrachtet, weil nur dieser einen althergebrachten Bipolartransistor „ersetzen“ kann.<br />
<br />
{| class="wikitable"<br />
|+ '''Typen von Feldeffekttransistoren<br/>&nbsp;'''<br />
|-<br />
! style="width:10em" | Typ <br />
! N-Kanal <br />
! P-Kanal<br />
|- valign="top"<br />
| JFET<br/>SFET<br/>(selbst leitend) || [[bild:JFET-N.png|center]]<br />
* drittgrößte Gruppe<br />
* bislang nur für kleine Leistungen verfügbar<br />
* JFETs mit hoher Leistung sind im Kommen<br />
* Eingangsstufen von OPVs<br />
* Eingangsstufen von HF-Verstärkern bis in den GHz-Bereich<br />
* als einfache [[Konstantstromquelle]] geeignet<br />
| [[bild:JFET-P.png|center]]<br />
* selten<br />
* ersatzhalber für „fehlenden“ P-Kanal-Verarmungs-MOSFET<br />
* Ältester Vertreter der Unipolartransistoren<br />
|- valign="top"<br />
| MOSFET<br/>Anreicherungstyp<br/>(selbst sperrend)<br/>''Enhancement Mode'' || [[bild:MOS-EN.png|center]]<br />
* Mit Abstand größte Gruppe; wenn nicht besonders erwähnt ist ''dieser'' gemeint<br />
* Eingangsstufen von HF-Verstärkern bis in den GHz-Bereich<br />
** Typen mit zwei Gates zum Regeln und Mischen üblich<br />
* Auch als Doppel-MOSFET oder zusammen mit P-Kanal-MOSFET in einem Gehäuse gängig<br />
| [[bild:MOS-EP.png|center]]<br />
* zweitgrößte Gruppe<br />
* bei gleicher Geometrie etwas schlechter als ein N-Kanal-Typ, da „Löcherleitung“ (aus „Defektelektronen“ = gedachte positive Ladungsträger) vorliegt<br />
* Auch als Doppel-MOSFET oder zusammen mit N-Kanal-MOSFET in einem Gehäuse gängig<br />
|- valign="top"<br />
| MOSFET<br/>Verarmungstyp<br/>(selbst leitend)<br/>''Depletion Mode'' || [[bild:MOS-DN.png|center]]<br />
* selten aber käuflich<br />
* Sinnvolle Anwendungen ergeben sich vor allem in Reihenschaltungen<br />
| [[bild:MOS-DP.png|center]]<br />
* Nicht in freier Wildbahn gesichtet<br />
|}<br />
<br />
=== Vorteile des FET ===<br />
<br />
* Niedrigere Verluste als bei Bipolartransistoren.<br />
* Sehr schnelles Schalten möglich, daher für sehr hohe Frequenzen geeignet (keine Speicherzeit wie beim BJT).<br />
* Einfaches Parallelschalten im Schaltbetrieb, da Unterschiede im <math>R_{DS,on}</math> durch den positiven Temperaturkoeffizienten ausgeglichen werden.<br />
* Leistungslose Ansteuerung im statischen Fall, jedoch hohe Umladeverluste am Gate!<br />
* oft preiswerter als vergleichbare Bipolartransistoren (engl. '''B'''ipolar '''J'''unction '''T'''ransistor, BJT)<br />
* Relativ unempfindlich gegen Überspannung zwischen Drain und Source. Bei Überschreitung der Maximalspannung zwischen Drain und Source findet ein sogenannter "Durchbruch" statt. Dies ist vergleichbar mit dem Zener-Effekt. Ist die Energiemenge begrenzt, ist dieser Durchbruch reversibel und der FET wird NICHT zerstört. Beim Bipolartransistor ist die dafür zulässige Energiemenge viel kleiner, weil die den Strom durchquerende Fläche zu Hotspots neigt.<br />
* Möglichkeit eines Stromfühler-Anschlusses: Durch geeignete Geometrie kann der Source-Anschluss aufgeteilt werden, etwa im Verhältnis 1:9 bis 1:99. Der Drainstrom teilt sich kontrolliert auf, auch wenn am „kleineren“ Source-Anschluss ein Messwiderstand zur Spannungs-Strom-Wandlung angeschlossen ist. Leider sind solche „Sense-MOSFETs“ selten einzeln und faktisch nie als P-Kanal-Typen verfügbar. In integrierten (Schaltnetzteil-)Schaltungen sind sie Standard.<br />
<br />
=== Nachteile des FET ===<br />
<br />
* Nur bedingt für hohe Spannungen [[Transistor#Wann setzt man einen MOSFET, Bipolartransistor, IGBT oder Thyristor ein ? |geeignet]], die ON-Verluste sind ab ca. 250V höher als bei einem [[IGBT]]. <br />
* Parasitäre Diode parallel zur Drain-Source Strecke ist immer enthalten, das (Ab-)Schaltverhalten dieser Dioden ist meist schlechter als separate Dioden, was häufig zu unerwünschten Schwingungen führt.<br />
* Empfindlicher gegen ESD am Gate als BJT<br />
* Positiver Temperaturkoeffizient (TK), der <math>R_{DS,on}</math> ist stark temperaturabhängig und steigt von 25°C (Datenblattangabe) auf 150°C ungefähr um den Faktor 2. Dadurch steigen auch die Verluste und damit die Erwärmung des Bauteiles.<br />
<br />
=== Erklärung der wichtigsten Datenblattwerte ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! style="width:12em" | '''Parameter'''<br />
! style="width:7em" | '''Symbol'''<br />
! style="width:6em" | Beispiel<br />
! '''Erklärung'''<br />
|-<br />
| Drain Source Voltage <br>(Breakdown) || V(BR)_DSS <br> V_DS || 75 V || Maximale Spannungsfestigkeit des Bauteiles zwischen Drain und Source<br />
|-<br />
| Continuous Drain Current || I_D(on) || 55 A @ 125 °C || Maximaler Dauerstrom bei 125°C Gehäusetemperatur <br />
|-<br />
| Pulsed Drain Current || ID_pulse <br> I_CD(on) || 240 A || Maximaler Pulsstrom (Achtung die zulässige Zeitdauer des Pulses kann nur über die maximale Junctiontemperatur ermittelt werden)<br />
|-<br />
| Gate Charge || Q<sub>GS</sub> || 320 nC || Gate-Ladung in Coloumb oder Amperesekunden, die zum Ein- oder Ausschalten des MOSFET erforderlich ist. Dies berücksichtigt die Nichtlinearität der Kapazität und (richtig?) den Miller-Effekt. Mit dieser Angabe wird der für das Schalten von Leistungs-MOSFET benötigte Gatestrom für eine bestimmte Schaltzeit ermittelt. Dieser liegt üblicherweise im einstelligen Ampere-Bereich. Moderne Typen mit extra geringer Gate-Ladung können so schneller schalten.<br />
|-<br />
| Repetetive Avalanche Energy || t_sc || 280 mJ || Maximale Energie, welche beim Avalanche Durchbruch bei Überschreiten der maximalen Drain-Source Spannung im MOSFET bei z.&nbsp;B. 1% Puls/Pausen Verhältnis regelmäßig auftreten darf, ohne den FET zu schädigen<br />
|-<br />
| Drain-Source<br>ON Resistance || R<sub>DS_ON</sub> || 0,01 Ω || Widerstand des eingeschalteten FETs bei '''25°C''', V_GS = 10V und ID = 30A<br />
|-<br />
| Drain-Source<br>ON Resistance || R<sub>DS_on</sub> || 0,021 Ω || Widerstand des eingeschalteten FETs bei '''175°C''', V_GS = 10V und ID = 30A<br />
|-<br />
| Thermal Resistance<br>(junction-case) || R<sub>th_JC</sub> || 0,8 K/W || Thermischer Widerstand im Transistor vom der „Sperrschicht“ (junction eines Bipolartransistors, ja altmodischer Index, hier besser „Kanal“) bis zur Rückseite oder bestmöglichen Kühlmöglichkeit des Transistorgehäuses (case)<br />
|-<br />
| Gate-Source<br>Threshold Voltage || V_GS(th) || 2,0-4,5 V || Gatespannung, ab welcher der Transistor minimal leitend wird (I_D typisch 100-200µA), große Toleranz, typisch 1:2 zwischen Minimum und Maximum<br />
|-<br />
| Turn-on Delay || t_d(on) || 40 ns || Verzögerung zwischen dem Einschalten am Gate bis zur Reaktion im Drainstrom<br />
|-<br />
| Rise Time || t_r || 200 ns || Anstiegszeit des Transistorstromes am Drain<br />
|-<br />
| Turn-off Delay || t_d(off) || 120 ns || Verzögerung zwischen Abschalten am Gate bis zur Reaktion im Drainstrom<br />
|-<br />
| Fall Time || t_f || 60 ns || Abfallzeit des Transistorstromes am Drain <br />
|}<br />
<br />
Die oben genannten Zeiten gelten ausschließlich unter den angegebenen Messbedingungen (Gatewiderstand, Treiberspannung, sowie einer '''FET-Teperatur von 25°C!''') und müssen für die eigene Anwendung ggf. neu berechnet werden. Meist wird man sie eher messen, weil die Rechung zu aufwändig und bisweilen unmöglich ist. <br />
<br />
==== Gate-Source Threshold Voltage ====<br />
Gerade bei der '''Gate-Source Threshold Voltage <math>V_{GS}(th)</math>''' gibt es hier immer wieder Verwirrung. Sie gibt an, ab welcher Spannung der MOSFET anfängt, minimal leitfähig zu werden. Diese Spannung ist technologisch bedingt auch heute noch einer starken Toleranz unterworfen, typischerweise hat der Bereich bei dem der FET zu leiten beginnt eine Spreizung von etwa 1:2 zwischen Minimum und Maximum. Welche Spannung man nun wirklich anlegen muss, um den gewünschten <math>R_{DS}(on)</math> zu erreichen kann der Tabelle im jeweiligen Datenblatt entnommen werden. Dabei unbedingt die angegebene Gatespannung beachten, nur dieser Wert ist garantiert!.<br />
<br />
[[bild: IRLZ34N_R_DS_ON.png | thumb | 800px | R_DS_ON im Datenblatt des IRLZ34N]]<br />
{{Clear}}<br />
<br />
Die Kurvenschar von <math>I_D</math> über <math>U_{DS}</math> in Abhängigkeit von <math>U_{GS}</math> stellt immer nur typische Werte dar, keine garantierten Extremwerte (engl. worst case). Als Standardwerte kann man 10-15V für einen Standardtypen und ca. 3-5V für einen Logic Level MOSFET (LL-FET) ansetzen. Kleinsignal-FETs leiten schon ab ca 1V. Bei Ansteuerung mit 5V benötigt man also einen Typen, der '''sicher''' bei 5V voll durchgesteuert ist, z.B. IRLZ34N. Bei 3,3V ist er bereits nicht mehr zuverlässig nutzbar. Es gibt auch Typen mit noch geringerer Spannung für Vollaussteuerung. Wer einen BUZ11 (<math>V_{GS}(th)</math> 4V max.) mit 5V ansteuert riskiert ein Abfackeln des MOSFETs, denn je nach Toleranz kann er bereit ganz gut aufgesteuert sein oder auch nicht. Das soll in den nachfolgenden Diagrammen dargestellt werden. Zunächst die Transferkennlinie. Sie gibt an, wieviel Drainstrom in Abhängigkeit der Gatespannung fließen kann, wobei die Drainspannung konstant ist, hier im Beispiel 25V. Ein typischer BUZ11 (mittlere, schwarze Kurve) fängt bei 3V zu leiten an und erreicht bei 6V am Gate ca. 17A. Erwischt man nun ein kritisches Exemplar, das erst bei 4V zu leiten anfängt (rechte, rote Kurve um 1V parallel verschoben), so kann dieser bei 6V nur 8A leiten, für 17A braucht er 7V. Der günstige Fall, daß der BUZ11 schon bei 2V anfängt zu leiten sieht man in der linken, roten Kurve.<br />
<br />
[[bild: BUZ11_UGS_ID.png | thumb | 800px | Transferkennlinie des BUZ11]]<br />
{{Clear}}<br />
<br />
Wenn man die drei Fälle (min, typ, max) mit 5V ansteuert, erhält man die Arbeitspunkte 1-3 mit einem maximal schaltbaren Drainstrom von 2,5, 8 und 17A. Diese kann man in das Ausgangskennlinienfeld übertragen. Wir nehmen max. 1V U_DS an. Es ergeben sie die gleichen Ströme. Der maximale Drainstrom weicht um -5,5/+9A vom typischen Fall ab. Erhöht man nun die Gate-Source Spannung auf 10V (Arbeitspunkt 4), schwankt der maximal schaltbare Drainstrom nur noch um -2/+2A, außerdem liegt er mit 30A deutlich höher. Der BUZ11 ist somit sicher durchgesteuert.<br />
<br />
[[bild: BUZ11_UDS_ID_UGS.png | thumb | 800px | Ausgangskennlinie des BUZ11]]<br />
{{Clear}}<br />
<br />
==== Parasitäre Diode ====<br />
<br />
Der Schwerpunkt in der FET-Entwicklung liegt auf den geringst-möglichen <math>R_{DS}(on)</math>, die Diode entsteht auf Grund des Herstellungsprozesses, und wird nur nachrangig verbessert, da viele Optimierungsversuche auch einen Einfluss auf wichtige Kennwerte des FETs hatten und haben.<br />
Daher muss sorgfältig geprüft werden, ob die Schaltgeschwindigkeit, die Recovery-Time und die damit verbundenen Verluste sowie die dabei erzeugte unerwünschte EMV-Abstahlung tolerierbar ist, oder nicht.<br />
Hier hilft es oft eine optimierte Diode / Schottky-Diode zum FET parallel zu schalten. Ganz ausblenden läßt sich die parasitäre Diode jedoch nicht, jedoch kann man den Anteil des Stromes beeinflussen, der über die intere Diode fliest.<br />
<br />
{| class="wikitable"<br />
|+ ''' Parasitäre Diode des FETs '''<br />
|-<br />
! style="width:10em" | '''Parameter'''<br />
! style="width:6em" | '''Symbol'''<br />
! style="width:6em" | '''Beispiel'''<br />
! '''Erklärung'''<br />
|-<br />
| Continuous Current || I_S || 75A || Maximaler Dauerstrom der parasitären Diode, meist identisch zum maximalen Dauerstrom des MOSFETs<br />
|-<br />
| Forward Voltage || V_SD || 1,3V || Spannungsfall an der parasitären Diode <br />
|-<br />
| Reverse Recovery Time || t_rr || 120ns || Zeit, welche die Elektronen brauchen um aus der leitenden Diode vollständig abzufließen. Während dieser Zeit fließt der Strom in '''Rückwärtsrichtung''' durch die Diode und erzeugt relativ viel Verlustleistung. <br />
|-<br />
| Reverse Recovery Charge || Q_rr || 60nC || Ladungsmenge, die während t_rr rückwärts durch die Diode fließt. <br />
|}<br />
<br />
== Haupttypen und Gatespannungslevel ==<br />
<br />
===Unterschied N-Kanal / P-Kanal FET===<br />
<br />
Im Schaltsymbol werden die MOSFET-Typen meist durch die Pfeilrichtung in der Mitte des Symbols (eigentlich "Bulk") vom oder zum Gate unterschieden. Zeigt der Pfeil zum Gate hin, handelt es sich um einen N-Kanal-FET, zeigt der Pfeil vom Gate weg um einen P-Kanal FET.<br />
<br />
Der große Vorteil des N-Kanal FETs (Elektronenleitung) ist, daß er immer niederohmiger ist, als ein gleich großer P-Kanal FET (Löcherleitung). Daher sind P-Kanal Typen bei vergleichbaren Werten auch immer größer = teuerer da weniger Chips auf einem Wafer Platz haben.<br />
<br />
Beim N-Kanal FET muss die Gatespannung positiv gegenüber Source sein. Dabei wird der FET dann leitend, wenn die sogenannte "threshold voltage" (Schwellenspannung) erreicht wird. Eine typische Anwendung ist z.&nbsp;B. ein '''Low-Side Schalter''': Source an GND, Drain an die Last, Ansteuerung des N-Kanal FETs mit 12V gleichbedeutend mit 12V ÜBER den Source = GND Potential.<br />
<br />
Beim P-Kanal FET als HS-Schalter muss die Gatespannung negativer=niedriger als das Sourcepotential sein.Beispiel.<br />
Beispiel: <br />
Lastspannung = 400V d.h. Source an 400V, Last zwischen Drain und GND, Ansteuerung des P-Kanal FETs mit 388V, also 12V UNTER dem Sourcepotential.<br />
<br />
Beim N-Kanal FET als HS-Schalter muss die Gatespannung positver=höher als das Sourcepotential sein.<br />
Beispiel:<br />
Lastspannung = 400V d.h. Drain an 400V, die Last zwischen Source und GND, Ansteuerung des N-Kanal FETs mit 412V, also 12V ÜBER dem Sourcepotential.<br />
In diesem Fall ist aber eine zusätzliche Spannungsquelle erforderlich, denn der FET wird mit einer Spannung über der Lastspannung eingeschaltet. <br />
<br />
'''Weblinks'''<br />
* [https://www.eetimes.com/a-primer-on-high-side-fet-load-switches-part-1-of-2/?utm_source=eetimes&utm_medium=networksearch A primer on high-side FET load switches (Part 1 of 2)], Qi Deng, Senior Product Marketing Manager, Mixed-Signal Products, Micrel, Inc., 5/3/2007 4:14 PM EDT, www.eetimes.com<br />
* [https://www.eetimes.com/a-primer-on-high-side-fet-load-switches-part-2-of-2/ A primer on high-side FET load switches (Part 2 of 2)], Qi Deng, Senior Product Marketing Manager, Mixed-Signal Products. Micrel, Inc., 5/7/2007 1:36 PM EDT, www.eetimes.com<br />
* [http://www.vishay.com/docs/70611/70611.pdf AN804 P-Channel MOSFETs, the Best Choice for High-Side Switching (PDF)] von Vishay Siliconix<br />
<br />
===Unterschied Logic-Level / "Normal"-Level===<br />
<br />
Den meisten FETs ist gemein, daß sie mit einer Spannung von 10..15V angesteuert werden müssen, um den minimalen Einschaltwiderstand zu erreichen. Diese FETs lassen sich nicht ohne weiteres mit einem CMOS-Pegel von 5V ansteuern. Es gibt jedoch für diesen Anwendungsfall sogenannte "Logic Level" (LL) FETs, die schon bei einer Gatespannung von etwa 4,5V voll durchgesteuert sind. Einige Kleinsignal-FETs sind schon ab ca. 1,2V voll durchgesteuert.<br />
<br />
== Beispiel zur Bauteiledimensionierung ==<br />
<br />
=== Spannungsfestigkeit ===<br />
<br />
Die höchste vorkommende Betriebsspannung + Abschaltüberspannung soll kleiner als ca. 80% der Spannungsfestigkeit des Bauteiles sein. <br />
<br />
Achtung: Zwischen dem je nach Anwendungsfall erforderlichen Pufferkondensator und dem FET wird es immer eine parasitäre Induktivität geben.<br />
Abhängig von Schaltgeschwindigkeit und Induktivität wird im Schaltmoment eine mehr oder weniger große Übrspannungsspitze produziert. Dieser Peak<br />
addiert sich auf die aktuelle Versorgungsspannung.<br />
<br />
Überschlagsrechnung als Beispiel:<br />
* Schaltgeschwindigkeit: dI/dt = -100A/µs (= Abschalten von 5A innerhalb 50ns),<br />
* Induktivität: L = 1µH (~ 1 m loses, ungebündeltes Kabel)<br />
* dU=-L*dI/dt = -1µH * (-100A / 1µs) = 100V<br />
<br />
Dies bedeutet, daß an der "Induktivität" zwischen Transistor und Kondensator - Aufgrund von Selbstinduktion im Schaltmoment - ein Überspannungspuls von ca. 100V entsteht, der auf die Betriebsspannung aufzuschlagen ist, also lieber die Leitung kürzer machen, und - sofern möglich - nicht ganz so schnell schalten.<br />
<br />
=== Stromtragfähigkeit ===<br />
<br />
In jedem Datenblatt ist eine Stromtragfähigkeit bei 25°C, und meist noch bei einer höheren Temperatur z.B. 125°C, 150°C oder 175°C Kühlfahnentemperatur angegeben. Dieser Wert ist als ERSTE Entscheidungsgrundlage ausreichend, aber aus der theoretisch abführbaren Verlustleistung errechnet, und<br />
* dient zum qualitativen Vergleich von Transistoren bezüglich ihres R_ds(on) und ihres Wärmewiderstands.<br />
* ist für die Dimensionierung einer Schaltung nur als Richtwert zu interpretieren. <br />
* ist ohne Schaltverluste genannt, und daher nur für einen Schaltbetrieb von wenigen Hz gültig. Außerdem wird ein annähernd idealer Kühlkörper unterstellt, der trotz der Verlustleistung das Gehäuse des Transistors auf der angegebenen Temperatur halten kann.<br />
* entbindet einen nicht davon den Kopf einzuschalten... siehe die nachfolgenden Zeilen.<br />
* Liegt der Strom für den die Schaltung entwickelt wird mit ca. 10..20% Abstand unter dem Datenblattwert von 125°C ist dieses Bauteil vermutlich verwendbar (siehe Detailberechnungen unten !). <br />
* Ist der benötigte Strom im Bereich oder größer als der zulässige bei 125°C sollte entweder ein anderer Typ eingesetzt oder mehrere FETs ''des gleichen Typs'' parallelgeschaltet werden.<br />
<br />
== Verlustleistung ==<br />
<br />
Hier wird eine Näherung für eine getaktete Anwendung betrachtet. In einem Transistor treten sowohl beim Ein- und Ausschalten, als auch während der Einschaltphase Verluste im Bauteil auf. Diese Verluste führen zu einer Bauteilerwärmung. Die dabei entstehende Temperatur darf die maximal zulässige Bauteiletemperatur nie überschreiten. Bei den ersten Projekten ist zu empfehlen eine berechnete Chiptemperatur von ca. 125°C nicht zu überschreiten. Fast alle aktuell verfügbaren FETs nennen im Datenblatt eine Temperatur von 175°C als ihre maximale Chiptemperatur.<br />
<br />
{| class="wikitable" style="width:32em" <br />
|+ '''Beispiel'''<br />
|-<br />
! Parameter<br />
! style="width:8em" | Symbol<br />
! style="width:8em" | Wert<br />
|-<br />
| Betriebsspannung || U<sub>N</sub> || 70 V<br />
|-<br />
| Nennstrom || I<sub>N</sub> || 30 A<br />
|-<br />
| Drain-Source Widerstand bei<br>Chiptemperatur: 125°C<br> Gatespannung: 10V || R<sub>DS<sub>on</sub></sub> || 17 mΩ<br />
|-<br />
| Pulsbreite || t<sub>on</sub> || 150 µs<br />
|-<br />
| Schaltfrequenz || ƒ<sub>schalt</sub> || 5 kHz<br>T = 200µs<br />
|-<br />
| Einschaltzeit (risetime) || t<sub>r</sub> || 500 ns<br />
|-<br />
| Ausschaltzeit (falltime) || t<sub>ƒ</sub> || 800 ns <br />
|-<br />
|}<br />
<br />
==== Leitend-Verluste ====<br />
<br />
Während der FET bei [[PWM]]-Ansteuerung eingeschaltet ist, erzeugt er Verlustleistung.<br />
<br />
<math><br />
P_\text{ON}<br />
= {I_\mathrm{N}}^2 \cdot R_\mathrm{DS_\mathrm{ON}} \cdot \frac{t_\mathrm{ON}}{T}<br />
= 30^2A^2 \cdot 17m\Omega \cdot \frac{150\mu s}{200\mu s} = 11{,}5W<br />
</math><br />
<br />
==== Schalt-Verluste ====<br />
<br />
Vereinfachter Ansatz.<br />
<br />
Einschalten:<br />
<br />
:<math>\begin{align}<br />
P_\mathrm{SW_r}<br />
&= \tfrac14 \cdot U_N \cdot I_N \cdot \frac{t_r}{T} \\<br />
&= \tfrac14 \cdot 70V \cdot 30A \cdot \frac{500ns}{200\mu s}=1{,}3W<br />
\end{align}</math><br />
<br />
Ausschalten:<br />
<br />
:<math>\begin{align}<br />
P_\mathrm{SW_f} <br />
&=\tfrac14 \cdot U_N \cdot I_N \cdot \frac{t_f}{T}\\<br />
&=\tfrac14 \cdot 70V \cdot 30A \cdot \frac{800ns}{200\mu s}=2{,}1W<br />
\end{align}</math><br />
<br />
Alternativ und genauer kann man rechnen, wenn die Ein- Ausschaltenergie im Datenblatt angegeben ist. Aber Achtung! Die Randbedingungen unter denen die genannte Energie ermittelt wurde, müssen genau so zutreffen.<br />
:<math>\begin{align}<br />
P_{SW_f} = f_{schalt} \cdot E_{ON}<br />
\end{align}</math><br />
:<math>\begin{align}<br />
P_{SW_r} = f_{schalt} \cdot E_{OFF}<br />
\end{align}</math><br />
<br />
Die Gesamtverlustleistung beträgt also in etwa 15W.<br />
<br />
Damit muß ein entsprechender [[Kühlkörper]] ausgelegt und die Chiptemperatur berechnet werden. z.&nbsp;B.:<br />
* Kühlkörper mit einem R_th von 0,2K/W<br />
* max. Umgebungstemperatur +60°C<br />
* R_th "junction-case" des FETs 0,8K/W<br />
* R_th der Wärmeleitfolie zwischen FET und Kühlkörper ca. 2,0K/W<br />
* R_th gesamt: 3,0K/W <br><br />
* Bei einer Verlustleistung von 18W und einer Umgebungstemperatur von 60°C hat der Chip eine Temperatur von ca. 18W * 3,0K/W +60°C = 114°C. ==> o.k.!<br />
<br />
Unter Berücksichtigung der Tatsache, daß hier viele Vereinfachungen vorgenommen, und die Art der Last nicht beachtet wurde ist es sinnvoll, einen gewissen Sicherheitsabstand zu den zulässigen Maximalwerten einzuhalten. Daher ist es empfehlenswert, die Chiptemperatur auf ca. 125°C zu beschränken. <br />
<br />
Des Weiteren ist hier die parasitäre Diode im FET nicht berücksichtigt.<br />
Wenn während der "off" Zeit ein Strom über die Diode fließt (Reverse recovery current oder Freilaufstrom), muß die dadurch '''zusätzlich''' entstehende Verlustleistung in die obige Berechnung der maximalen Chiptemperatur mit einfließen.<br />
<br />
==Treiberleistung==<br />
<br />
Auch wenn der MOSFET ein spannungsgesteuertes Bauelement ist, muss trotzdem bei jedem Einschalten und bei jedem Ausschalten die Gatekapazität umgeladen werden. Bei älteren Leistungs-FET - oder bei einem schlechten Design (!) - muss sogar teilweise mit negativer Spannung am Gate gearbeitet werden, um eine vollständige Sperrung zu erreichen.<br />
Diese Umladung muss möglichst schnell erfolgen, um die Verluste im FET während der Umschaltphase zu minimieren. Dazu findet ein [[Mosfet-Übersicht#MOSFET-Treiber|MOSFET-Treiber]] Verwendung. Hier eine detaillierte Beschreibung zum [[Treiber]].<br />
<br />
Da die Gatekapazität nicht direkt im Datenblatt enthalten ist kann man sich mit der Eingangskapazität Ciss behelfen. Im Arbeitspunkt ist die Gatekapazität ungefähr 5x größer als der im Datenblatt für Ciss angegebene Wert. <br />
Daher berechnet sich die Treiberleistung wie folgt: <br />
<br />
:<math>P_\text{Treiber} = C \cdot U^2 \cdot f = 5 \cdot C_\text{íss} \cdot U_\text{Gate}^2 \cdot f_\text{schalt}</math><br />
<br />
1.Beispiel, kleine MOSFET-Steuerung mit niedriger Leistung und Frequenz.<br />
<br />
:<math>P_\text{treiber} = 5 \cdot 4{,}8\,\text{nF} \cdot 15\,\text{V}^2 \cdot 10\,\text{kHz} = 54\,\text{mW}</math><br />
<br />
2.Beispiel, sehr große MOSFET-Steuerung für Induktionsheizung mit sehr hoher Leistung und Frequenz.<br />
<br />
:<math>P_\text{treiber} = 5 \cdot 24\,\text{nF} \cdot 15\,\text{V}^2 \cdot 250\,\text{kHz} = 6{,}75\,\text{W}</math><br />
<br />
Aber Achtung, so ein MOSFET-Treiber hat auch einen Eigenverbrauch, der leicht zwischen 0,5 und 1 W liegen kann.<br />
<br />
Bei niedrigen PWM-Frequenzen kann man Logic Level MOSFETs auch direkt per CMOS-Ausgang ansteuern, z.B. mit einem [[AVR]], wie in diesem [http://www.mikrocontroller.net/topic/246449#2519459 Forumsbeitrag] zu sehen ist.<br />
<br />
== Low- und High-Side ==<br />
<br />
Definition LS- und HS:<br />
<br />
;Low-Side Schalter: Der FET schaltet eine Last gegen GND - auch als LS-Schalter bezeichnet.<br />
;High-Side Schalter: Der FET schaltet eine Last an die Versorgungsspannung – auch als HS-Schalter bezeichnet.<br />
<br />
Anregungen oder Fragen auch gerne per Email an [http://www.mikrocontroller.net/user/show/powerfreak Powerfreak]. Dieser Artikel kann dadurch regelmäßig erweitert und ggf. durch ein FAQ ergänzt werden.<br />
<br />
<br />
== SOA Diagramm ==<br />
<br />
SOA-Diagramm (engl. '''S'''afe '''O'''perating '''A'''rea, sicherer Arbeitsbereich) beschreibt die zulässige Verlustleistung eines Transistors in Anhängigkeit des Drainstroms (I_D), der Drain-Source Spannung (U_DS) und der Pulsbreite. Als Beispiel sei hier der BUZ 11 genannt. Im nachfolgenden Diagramm ist das SOA-Diagramm dargestellt. Wie ist es zu verstehen? Zunächst gibt es eine Grenze auf der linken Seite, die schräge, dunkelblaue Line. Diese wird durch den minimalen R_DS_ON festgelegt, hier wirkt der MOSFET wie ein ohmscher Widerstand. Mehr Strom kann bei einer bestimmten Spannung nicht fließen. Die zweite Grenzlinie ist ganz rechts die pinkfarbene Linie, sie stellt die maximale Sperrspannung des MOSFET dar. Die dritte Grenze ist der maximal zulässige Drainstrom, hier im Beispiel 120A, dargestellt durch die gelbe Linie. Die maximale Spannung zwischen Drain und Source sowie der Drainstrom sind abhängig von der Pulsbreite, mit welcher der MOSFET betrieben wird. Bei nur 2,5µs Pulsbreite (Rechteckimpuls) müssen die beiden Parameter sich innerhalb der Fläche bewegen, welche durch die dunkelblaue, gelbe und die pinkfarbene Line begrenzt wird. Im Extremfall dürfen 50V anliegen und 120A fließen, das sind satte 6kW Pulsleistung! Werden die Pulse breiter, so sinken die zulässigen Ströme und Spannungen, bei 1ms (dunkelblaue Linie bis zur braunen Linie, dann zur pinkfarbenen Linie) sind maximal noch 50V und 7A zulässig, also nur noch 350W. Die letzte Linie stellt den Fall für Gleichstrom (engl. '''D'''irect '''C'''urrent), also Dauerbelastung dar, hier sind bei 50V maximal 1,5A zulässig, was einer Dauerverlustleistung von 75W entspricht. MOSFETs, welche nur für Schaltbetrieb und nicht für [[#Linearbetrieb von MOSFETs | Linearbetrieb]] geeignet sind, haben keine Kennlinie für DC. Im normalen Schaltbetrieb liegt der Arbeitspunkt auf der linken Grenzlinie R_DS_ON_MIN. Nur im Linearbetrieb liegt der Arbeitspunkt innerhalb der Fläche, welche durch die Außenlinien begrenzt wird.<br />
<br />
[[bild: SOA-BUZ11.png | thumb | 300px| SOA-Diagramm]]<br />
<br />
Bei der Anwendung des Diagramms gilt es einiges zu beachten. Die Pulsleistungen sind nur zulässig, wenn der MOSFET vorher kalt ist, sprich ca. 25°C Sperrschichttemperatur hat. War er vorher schon heiß, reduziert sich die zulässige Belastung deutlich. Ebenso dürfen die Pulse nicht zu schnell wiederholt werden, denn dann ist der MOSFET noch vom vorherigen Puls aufgeheizt. Im Fall von DC sind 75W Verlustleistung auch eher ein theoretischer Wert, welcher real nur schwer erreicht werden kann, wenn der MOSFET auf einem sehr großen [[Kühlkörper]] optimal montiert ist. Praktisch liegen die erreichbaren Werte eher bei der Hälfte.<br />
<br />
(Anm. Eigentlich müsste für die R_DS_ON Grenzlinie R = U / I der minimale R_DS_ON rauskommen, hier ~40mOhm, es kommen aber ~80mOhm raus. Die Ursache dafür ist unklar, möglicherweise liegt hier ein Sicherheitsfaktor zu grunde).<br />
<br />
{{Clear}}<br />
<br />
== Linearbetrieb von MOSFETs ==<br />
<br />
Der Großteil der Anwendungen nutzt MOSFETs als Schalter, d.h. der MOSFET ist entweder voll gesperrt oder voll durchgesteuert. Dafür gelten auch all die Hinweise in diesem Artikel. In bestimmten Anwendungen werden MOSFETs aber auch im Linearbetrieb eingesetzt, z.B in linearen Endstufen für Audio, Video, elektronischen Lasten und Stromquellen. Hier muss man einiges beachten. Ein verbreiteter Irrtum besteht darin zu glauben, MOSFETs könne man im Linearbetrieb einfach parallel schalten, weil der positive Temperaturkoeffizient von <math>R_{DS(ON)}</math> eine Symmetrierung bewirkt, ähnlich den Emitterwiderständen bei parallelgeschalteten Bipolartransistoren. Das ist ''ausschließlich'' im Schaltbetrieb möglich, und daher falsch! Im Linearbetrieb spielt der Temperaturkoeffizient von <math>R_{DS(ON)}</math> keine Rolle, weil der MOSFET selten bis nie komplett durchgesteuert ist. Eben darum ist beim Linearbetrieb der minimale <math>R_{DS(ON)}</math> in den meisten Fällen unwichtig und man kann auch eher hochohmige, ältere MOSFETs verwenden, wie z.B. den BUZ11.<br />
<br />
Hier wirkt vielmehr der negative Temperaturkoeffizient (TK) der Thresholdspannung <math>U_{GS(thr)}</math>, vergleichbar dem negativen TK der Basis-Emitter-Spannung von Bipolartransistoren. D.h. mit steigender Temperatur und konstanter Gate-Source-Spannung steigt der Stromfluss der Drain-Source Strecke. In einer Parallelschaltung von MOSFETs würde dies bedeuten, dass der MOSFET mit dem geringfügig größeren Drainstrom (Fertigungstoleranzen) wärmer wird, was zu einem weiter steigenden Drainstrom und damit noch mehr Wärme führt. Damit ist die Schaltung thermisch instabil und würde zum Durchbrennen der MOSFETs führen, einer nach dem Anderen. <br />
<br />
Um das zu verhindern muss man relativ große Ausgleichswiderstände in die Source-Leitung der einzelnen MOSFETs schalten, um diese Drift zu kompensieren. Dadurch verschlechtert sich natürlich der Wirkungsgrad des Verstärkers. MOSFETs haben einen TK von typisch -5mV/K für <math>U_{GS(thr)}</math>, das ist mehr als das doppelte von Bipolartransistoren mit typisch -2mV/K, weshalb die Symmetrierungswiderstände mehr als doppelt so groß sein müssen. Weiterhin muss man beachten, dass die Toleranzen von <math>U_{GS(thr)}</math> sehr groß sind, im Bereich von Volt! Das kann man sinnvoll nicht mehr mit Gatewiderständen symmetrieren, hier muss man die MOSFETs ausmessen und Gruppen mit geringen Toleranzen in einer Schaltung verwenden (engl. matching). <br />
<br />
Eine andere Möglichkeit ist die getrennte Ansteuerung der einzelnen MOSFETs, das wird oft in elektronischen Lasten bzw. [[Konstantstromquelle#Konstantstromquelle mit Operationsverstärker und Transistor | Konstantstromquellen]] gemacht. Hier treten keine zusätzlichen Verluste auf und der Mehraufwand in der Ansteuerung ist meist unkritisch.<br />
<br />
Weiterhin muss man beachten, dass viele der heutigen HochleistungsMOSFETs intern eine Parallelschaltung vieler kleiner MOSFET-Zellen (z.B. sogenannte Trench-FET) sind, und somit oft für den Linearbetrieb ungeeignet sind. Denn auch dort können einzelne Zellen überhitzen und durchbrennen (Hot Spot). Ob ein MOSFET für den Linearbetrieb tauglich ist steht manchmal im Datenblatt, oft aber eher nicht, eben weil die meisten MOSFETs als Schalter entwickelt und gebaut sind. Typische Vertreter für Linearbetrieb findet man in der [[MOSFET-Übersicht]]. Ein wichtiges Indiz für Linearbetrieb ist eine Kurve für DC im [[#SOA_Diagramm | SOA-Diagramm]]. Meist geht es dort nur bis 10ms, DC fehlt, eben weil DC (engl. '''D'''irect '''C'''urrent = Gleichstrom = Linearbetrieb) nicht zulässig ist. Manchmal hat der Hersteller auch "vergessen", die Kennlinie für DC mit reinzuschreiben, wie z.B. bei [http://www.irf.com/product-info/hi-rel/alerts/fv5-p-09-01-A.pdf IRF], wie in diesem [http://www.mikrocontroller.net/topic/291760#3106758 Beitrag] zu erfahren ist.<br />
Ein recht gutes Indiz dafür, ob ein FET für den Linearbetrieb taugt, ist die Vorwärtssteilheit. Diese kennzeichnet die Abhängigkeit des Drainstromes von der Ansteuerung am Gate als <math>S = \Delta i_d/\Delta u_{gs}</math>. Moderne Trench-FET erreichen heute Steilheiten im dreistelligen Bereich und sind für Linearanwendungen völlig unbrauchbar. Zum Vergleich: Der BUZ11 kommt mit gerade einmal 4 bis 5 Siemens daher.<br />
<br />
In diesem Beitrag wird die DC-Linie im SOA-Diagramm noch genauer erklärt: [http://www.mikrocontroller.net/topic/319961#3473567 Re: MOSFET Linearbetrieb möglich?]<br />
<br />
<br />
== Siehe auch ==<br />
<br />
* [[Leistungselektronik]]<br />
* [[Mosfet-Übersicht]]<br />
* [[IGBT]]<br />
* [[TRIAC]]<br />
* [[Kühlkörper]] <br />
* [[Zwischenkreiskapazität]]<br />
* [[Treiber]]<br />
* [[Snippets#Wie_schlie.C3.9Fe_ich_einen_MOSFET_an_einen_Mikrocontroller_an.3F|Wie schließe ich einen Mosfet an einen Mikrocontroller an?]]<br />
* [http://www.mikrocontroller.net/articles/H-Br%C3%BCcken_%C3%9Cbersicht Übersicht H-Brücken]<br />
* [http://www.mikrocontroller.net/topic/168218#1609684 Forumsbeitrag]: MOSFETs im Linearbetrieb<br />
* [http://www.mikrocontroller.net/topic/186785#new Forumsbeitrag]: nochmal MOSFETs im Linearbetrieb<br />
* [http://www.mikrocontroller.net/topic/319961#3473567 Forumsbeitrag]: sehr ausführlicher Forumsbeitrag über MOSFETs im Linearbetrieb. Berücksichtigt auch den Spirito-Effekt.<br />
* [http://www.mikrocontroller.net/topic/143324#new Forumsbeitrag]: Über eine elektronische Last, sehr lang<br />
*[http://www.mikrocontroller.net/topic/246449#2519459 Forumsbeitrag]: Logic Level MOSFETs direkt mit einem [[AVR]] treiben.<br />
* [http://www.mikrocontroller.net/topic/267254#2787855 Forumsbeitrag]: MOSFETs im Linearbetrieb, Laborerfahrungen<br />
* [http://www.mikrocontroller.net/topic/267254#2787945 Forumsbeitrag]: MOSFETs für Linearbetrieb<br />
* [https://www.mikrocontroller.net/topic/269642?goto=2820617#2820617 Forumsbeitrag]: Verpol- und Überspannungsschutz mit MOSFETs<br />
* [https://www.mikrocontroller.net/topic/425414#4981611 Forumsbeitrag]: Linearbetrieb von MOSFETs<br />
<br />
== Weblinks ==<br />
<br />
* [http://www.elektronikinfo.de/strom/feldeffekttransistoren.htm Feldeffekttransistoren bei elektronikinfo.de]<br />
* [http://www.elektronik-kompendium.de/sites/bau/0207011.htm FET im ELKO]<br />
* [http://www.elektronik-kompendium.de/sites/bau/0510161.htm MOSFET im ELKO]<br />
* [http://www.sprut.de/electronic/switch/nkanal/nkanal.html MOSFET bei sprut.de]<br />
* [http://sound.westhost.com/articles/hexfet.htm#51 MOSFETs in Audioendstufen, engl.]<br />
* [http://irf.custhelp.com/cgi-bin/irf.cfg/php/enduser/std_adp.php?p_faqid=214&p_created=1019728945&p_sid=pt9ITiCj&p_accessibility=0&p_redirect=&p_lva=&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9MTQsMTQmcF9wcm9kcz0mcF9jYXRzPSZwX3B2PSZwX2N2PSZwX3BhZ2U9MSZwX3NlYXJjaF90ZXh0PWxpbmVhcg**&p_li=&p_topview=1 FAQ Answer ID 214 bei IRF zum Linearbetrieb]<br />
* [http://www.nxp.com/documents/application_note/AN11158.pdf AN11158 - Understanding power MOSFET data sheet parameters] von NXP (PDF)<br />
* [https://assets.nexperia.com/documents/technical-note/TN00008.pdf TN00008 - Power MOSFET frequently asked questions and answers] von nexperia (PDF)<br />
* [http://www.infineon.com/dgdl/Infineon+-+Application+Note+-+PowerMOSFETs+-+OptiMOS%E2%84%A2+-+Linear+Mode+Operation+and+SOA+Power+MOSFETs.pdf?fileId=db3a30433e30e4bf013e3646e9381200 AN: Linear Mode Operation andSafe Operating Diagram of Power-MOSFETs] von Infineon (PDF)<br />
* [http://www.ixys.com/Documents/Articles/Article_Linear_Power_MOSFETs.pdf MOSFETs Withstand Stress of Linear-Mode Operation] Neuentwickelte MOSFETs für Linearbetrieb (PDF)<br />
<br />
[[Kategorie:Bauteile]] [[Kategorie:Leistungselektronik]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=FET&diff=107027FET2024-07-19T16:52:23Z<p>Heha: </p>
<hr />
<div>Dieser Artikel versteht sich als Unterpunkt zum Artikel [[Leistungselektronik]]<br />
<br />
<br />
Ein FET (engl. '''F'''ield '''E'''ffect '''T'''ransistor) ist ein Feldeffekttransistor. Der FET ist ein Bauelement, das im Gegensatz zum Bipolartransistor (engl. '''B'''ipolar '''J'''unction '''T'''ransistor, BJT) mit Spannung und nicht mit Strom gesteuert wird. Weil keine P-N-Sperrschichten am Stromfluss beteiligt sind, heißen diese auch Unipolartransistoren. Unterschieden werden<br />
<br />
* MOSFET = engl. '''M'''etall '''O'''xide '''S'''emiconductor '''F'''ield '''E'''ffect '''T'''ransistor; Metalloxidschicht-FET, größte Teilgruppe der FETs mit isoliertem Gate.<br />
<br />
* JFET = engl. '''J'''unction '''F'''ield '''E'''ffect '''T'''ransistor, Übergangszonen-FET, der steuerbare Kanal wird durch einen PN-Übergang wie in einer Diode gebildet. <small>(Diese Diode lässt sich nachmessen und unterscheidet JFET von (selbtleitenden) MOSFET, auch wenn sie schaltungstechnisch keine Rolle spielt. Wichtig: JFETs gibt es ''nur'' selbstleitend!)</small><br />
<br />
Die drei Anschlüsse eines FETs werden ''Gate'', ''Drain'' und ''Source'' genannt. Unter Umständen ist ein vierter Anschluß vorhanden, der ''Bulk'' genannt wird. Normalerweise ist Bulk intern mit Source verbunden. <small>Wenn dies nicht der Fall ist, muss diese Verbindung durch den Designer in der Schaltung hergestellt werden. Nicht gesichtet für Leistungstransistoren.</small><br />
<br />
== FET-Typen ==<br />
<br />
FETs werden hauptsächlich unterschieden in N-Kanal und P-Kanal, sowie "selbst sperrend = Anreicherungstyp" (engl. enhancement type) und "selbst leitend = Verarmungstyp" (engl. depletion type). Beim selbstleitenden FET ist der Transistor bei 0V Gate-Source Spannung maximal leitend (durchgesteuert) und wird durch Anlegen einer Spannung ans Gate gesperrt. Beim selbstsperrenden FET (größte Gruppe) ist der Transistor bei 0V Gate-Source Spannung gesperrt und wird durch Anlegen einer Spannung ans Gate leitend. Ist die Linie zwischen Drain und Source durchgezogen handelt es sich um einen selbstleitenden, bei einer gestrichelten Linie um einen selbstsperrenden FET. JFETs gibt es nur als Verarmungstyp.<br />
<br />
Im weiteren Artikel wird nur der '''selbstsperrende''' MOSFET betrachtet, weil nur dieser einen althergebrachten Bipolartransistor „ersetzen“ kann.<br />
<br />
{| class="wikitable"<br />
|+ '''Typen von Feldeffekttransistoren<br/>&nbsp;'''<br />
|-<br />
! style="width:10em" | Typ <br />
! N-Kanal <br />
! P-Kanal<br />
|- valign="top"<br />
| JFET<br/>SFET<br/>(selbst leitend) || [[bild:JFET-N.png|center]]<br />
* drittgrößte Gruppe<br />
* bislang nur für kleine Leistungen verfügbar<br />
* JFETs mit hoher Leistung sind im Kommen<br />
* Eingangsstufen von OPVs<br />
* Eingangsstufen von HF-Verstärkern bis in den GHz-Bereich<br />
* als einfache [[Konstantstromquelle]] geeignet<br />
| [[bild:JFET-P.png|center]]<br />
* selten<br />
* ersatzhalber für „fehlenden“ P-Kanal-Verarmungs-MOSFET<br />
* Ältester Vertreter der Unipolartransistoren<br />
|- valign="top"<br />
| MOSFET<br/>Anreicherungstyp<br/>(selbst sperrend)<br/>''Enhancement Mode'' || [[bild:MOS-EN.png|center]]<br />
* Mit Abstand größte Gruppe; wenn nicht besonders erwähnt ist ''dieser'' gemeint<br />
* Eingangsstufen von HF-Verstärkern bis in den GHz-Bereich<br />
** Typen mit zwei Gates zum Regeln und Mischen üblich<br />
* Auch als Doppel-MOSFET oder zusammen mit P-Kanal-MOSFET in einem Gehäuse gängig<br />
| [[bild:MOS-EP.png|center]]<br />
* zweitgrößte Gruppe<br />
* bei gleicher Geometrie etwas schlechter als ein N-Kanal-Typ, da „Löcherleitung“ (aus „Defektelektronen“ = gedachte positive Ladungsträger) vorliegt<br />
* Auch als Doppel-MOSFET oder zusammen mit N-Kanal-MOSFET in einem Gehäuse gängig<br />
|- valign="top"<br />
| MOSFET<br/>Verarmungstyp<br/>(selbst leitend)<br/>''Depletion Mode'' || [[bild:MOS-DN.png|center]]<br />
* selten aber käuflich<br />
* Sinnvolle Anwendungen ergeben sich vor allem in Reihenschaltungen<br />
| [[bild:MOS-DP.png|center]]<br />
* Nicht in freier Wildbahn gesichtet<br />
|}<br />
<br />
=== Vorteile des FET ===<br />
<br />
* Niedrigere Verluste als bei Bipolartransistoren.<br />
* Sehr schnelles Schalten möglich, daher für sehr hohe Frequenzen geeignet (keine Speicherzeit wie beim BJT).<br />
* Einfaches Parallelschalten im Schaltbetrieb, da Unterschiede im <math>R_{DS,on}</math> durch den positiven Temperaturkoeffizienten ausgeglichen werden.<br />
* Leistungslose Ansteuerung im statischen Fall, jedoch hohe Umladeverluste am Gate!<br />
* oft preiswerter als vergleichbare Bipolartransistoren (engl. '''B'''ipolar '''J'''unction '''T'''ransistor, BJT)<br />
* Relativ unempfindlich gegen Überspannung zwischen Drain und Source. Bei Überschreitung der Maximalspannung zwischen Drain und Source findet ein sogenannter "Durchbruch" statt. Dies ist vergleichbar mit dem Zener-Effekt. Ist die Energiemenge begrenzt, ist dieser Durchbruch reversibel und der FET wird NICHT zerstört. Beim Bipolartransistor ist die dafür zulässige Energiemenge viel kleiner, weil die den Strom durchquerende Fläche zu Hotspots neigt.<br />
<br />
=== Nachteile des FET ===<br />
<br />
* Nur bedingt für hohe Spannungen [[Transistor#Wann setzt man einen MOSFET, Bipolartransistor, IGBT oder Thyristor ein ? |geeignet]], die ON-Verluste sind ab ca. 250V höher als bei einem [[IGBT]]. <br />
* Parasitäre Diode parallel zur Drain-Source Strecke ist immer enthalten, das (Ab-)Schaltverhalten dieser Dioden ist meist schlechter als separate Dioden, was häufig zu unerwünschten Schwingungen führt.<br />
* Empfindlicher gegen ESD am Gate als BJT<br />
* Positiver Temperaturkoeffizient (TK), der <math>R_{DS,on}</math> ist stark temperaturabhängig und steigt von 25°C (Datenblattangabe) auf 150°C ungefähr um den Faktor 2. Dadurch steigen auch die Verluste und damit die Erwärmung des Bauteiles.<br />
<br />
=== Erklärung der wichtigsten Datenblattwerte ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! style="width:12em" | '''Parameter'''<br />
! style="width:7em" | '''Symbol'''<br />
! style="width:6em" | Beispiel<br />
! '''Erklärung'''<br />
|-<br />
| Drain Source Voltage <br>(Breakdown) || V(BR)_DSS <br> V_DS || 75 V || Maximale Spannungsfestigkeit des Bauteiles zwischen Drain und Source<br />
|-<br />
| Continuous Drain Current || I_D(on) || 55 A @ 125 °C || Maximaler Dauerstrom bei 125°C Gehäusetemperatur <br />
|-<br />
| Pulsed Drain Current || ID_pulse <br> I_CD(on) || 240 A || Maximaler Pulsstrom (Achtung die zulässige Zeitdauer des Pulses kann nur über die maximale Junctiontemperatur ermittelt werden)<br />
|-<br />
| Gate Charge || Q<sub>GS</sub> || 320 nC || Gate-Ladung in Coloumb oder Amperesekunden, die zum Ein- oder Ausschalten des MOSFET erforderlich ist. Dies berücksichtigt die Nichtlinearität der Kapazität und (richtig?) den Miller-Effekt. Mit dieser Angabe wird der für das Schalten von Leistungs-MOSFET benötigte Gatestrom für eine bestimmte Schaltzeit ermittelt. Dieser liegt üblicherweise im einstelligen Ampere-Bereich. Moderne Typen mit extra geringer Gate-Ladung können so schneller schalten.<br />
|-<br />
| Repetetive Avalanche Energy || t_sc || 280 mJ || Maximale Energie, welche beim Avalanche Durchbruch bei Überschreiten der maximalen Drain-Source Spannung im MOSFET bei z.&nbsp;B. 1% Puls/Pausen Verhältnis regelmäßig auftreten darf, ohne den FET zu schädigen<br />
|-<br />
| Drain-Source<br>ON Resistance || R<sub>DS_ON</sub> || 0,01 Ω || Widerstand des eingeschalteten FETs bei '''25°C''', V_GS = 10V und ID = 30A<br />
|-<br />
| Drain-Source<br>ON Resistance || R<sub>DS_on</sub> || 0,021 Ω || Widerstand des eingeschalteten FETs bei '''175°C''', V_GS = 10V und ID = 30A<br />
|-<br />
| Thermal Resistance<br>(junction-case) || R<sub>th_JC</sub> || 0,8 K/W || Thermischer Widerstand im Transistor vom der „Sperrschicht“ (junction eines Bipolartransistors, ja altmodischer Index, hier besser „Kanal“) bis zur Rückseite oder bestmöglichen Kühlmöglichkeit des Transistorgehäuses (case)<br />
|-<br />
| Gate-Source<br>Threshold Voltage || V_GS(th) || 2,0-4,5 V || Gatespannung, ab welcher der Transistor minimal leitend wird (I_D typisch 100-200µA), große Toleranz, typisch 1:2 zwischen Minimum und Maximum<br />
|-<br />
| Turn-on Delay || t_d(on) || 40 ns || Verzögerung zwischen dem Einschalten am Gate bis zur Reaktion im Drainstrom<br />
|-<br />
| Rise Time || t_r || 200 ns || Anstiegszeit des Transistorstromes am Drain<br />
|-<br />
| Turn-off Delay || t_d(off) || 120 ns || Verzögerung zwischen Abschalten am Gate bis zur Reaktion im Drainstrom<br />
|-<br />
| Fall Time || t_f || 60 ns || Abfallzeit des Transistorstromes am Drain <br />
|}<br />
<br />
Die oben genannten Zeiten gelten ausschließlich unter den angegebenen Messbedingungen (Gatewiderstand, Treiberspannung, sowie einer '''FET-Teperatur von 25°C!''') und müssen für die eigene Anwendung ggf. neu berechnet werden. Meist wird man sie eher messen, weil die Rechung zu aufwändig und bisweilen unmöglich ist. <br />
<br />
==== Gate-Source Threshold Voltage ====<br />
Gerade bei der '''Gate-Source Threshold Voltage <math>V_{GS}(th)</math>''' gibt es hier immer wieder Verwirrung. Sie gibt an, ab welcher Spannung der MOSFET anfängt, minimal leitfähig zu werden. Diese Spannung ist technologisch bedingt auch heute noch einer starken Toleranz unterworfen, typischerweise hat der Bereich bei dem der FET zu leiten beginnt eine Spreizung von etwa 1:2 zwischen Minimum und Maximum. Welche Spannung man nun wirklich anlegen muss, um den gewünschten <math>R_{DS}(on)</math> zu erreichen kann der Tabelle im jeweiligen Datenblatt entnommen werden. Dabei unbedingt die angegebene Gatespannung beachten, nur dieser Wert ist garantiert!.<br />
<br />
[[bild: IRLZ34N_R_DS_ON.png | thumb | 800px | R_DS_ON im Datenblatt des IRLZ34N]]<br />
{{Clear}}<br />
<br />
Die Kurvenschar von <math>I_D</math> über <math>U_{DS}</math> in Abhängigkeit von <math>U_{GS}</math> stellt immer nur typische Werte dar, keine garantierten Extremwerte (engl. worst case). Als Standardwerte kann man 10-15V für einen Standardtypen und ca. 3-5V für einen Logic Level MOSFET (LL-FET) ansetzen. Kleinsignal-FETs leiten schon ab ca 1V. Bei Ansteuerung mit 5V benötigt man also einen Typen, der '''sicher''' bei 5V voll durchgesteuert ist, z.B. IRLZ34N. Bei 3,3V ist er bereits nicht mehr zuverlässig nutzbar. Es gibt auch Typen mit noch geringerer Spannung für Vollaussteuerung. Wer einen BUZ11 (<math>V_{GS}(th)</math> 4V max.) mit 5V ansteuert riskiert ein Abfackeln des MOSFETs, denn je nach Toleranz kann er bereit ganz gut aufgesteuert sein oder auch nicht. Das soll in den nachfolgenden Diagrammen dargestellt werden. Zunächst die Transferkennlinie. Sie gibt an, wieviel Drainstrom in Abhängigkeit der Gatespannung fließen kann, wobei die Drainspannung konstant ist, hier im Beispiel 25V. Ein typischer BUZ11 (mittlere, schwarze Kurve) fängt bei 3V zu leiten an und erreicht bei 6V am Gate ca. 17A. Erwischt man nun ein kritisches Exemplar, das erst bei 4V zu leiten anfängt (rechte, rote Kurve um 1V parallel verschoben), so kann dieser bei 6V nur 8A leiten, für 17A braucht er 7V. Der günstige Fall, daß der BUZ11 schon bei 2V anfängt zu leiten sieht man in der linken, roten Kurve.<br />
<br />
[[bild: BUZ11_UGS_ID.png | thumb | 800px | Transferkennlinie des BUZ11]]<br />
{{Clear}}<br />
<br />
Wenn man die drei Fälle (min, typ, max) mit 5V ansteuert, erhält man die Arbeitspunkte 1-3 mit einem maximal schaltbaren Drainstrom von 2,5, 8 und 17A. Diese kann man in das Ausgangskennlinienfeld übertragen. Wir nehmen max. 1V U_DS an. Es ergeben sie die gleichen Ströme. Der maximale Drainstrom weicht um -5,5/+9A vom typischen Fall ab. Erhöht man nun die Gate-Source Spannung auf 10V (Arbeitspunkt 4), schwankt der maximal schaltbare Drainstrom nur noch um -2/+2A, außerdem liegt er mit 30A deutlich höher. Der BUZ11 ist somit sicher durchgesteuert.<br />
<br />
[[bild: BUZ11_UDS_ID_UGS.png | thumb | 800px | Ausgangskennlinie des BUZ11]]<br />
{{Clear}}<br />
<br />
==== Parasitäre Diode ====<br />
<br />
Der Schwerpunkt in der FET-Entwicklung liegt auf den geringst-möglichen <math>R_{DS}(on)</math>, die Diode entsteht auf Grund des Herstellungsprozesses, und wird nur nachrangig verbessert, da viele Optimierungsversuche auch einen Einfluss auf wichtige Kennwerte des FETs hatten und haben.<br />
Daher muss sorgfältig geprüft werden, ob die Schaltgeschwindigkeit, die Recovery-Time und die damit verbundenen Verluste sowie die dabei erzeugte unerwünschte EMV-Abstahlung tolerierbar ist, oder nicht.<br />
Hier hilft es oft eine optimierte Diode / Schottky-Diode zum FET parallel zu schalten. Ganz ausblenden läßt sich die parasitäre Diode jedoch nicht, jedoch kann man den Anteil des Stromes beeinflussen, der über die intere Diode fliest.<br />
<br />
{| class="wikitable"<br />
|+ ''' Parasitäre Diode des FETs '''<br />
|-<br />
! style="width:10em" | '''Parameter'''<br />
! style="width:6em" | '''Symbol'''<br />
! style="width:6em" | '''Beispiel'''<br />
! '''Erklärung'''<br />
|-<br />
| Continuous Current || I_S || 75A || Maximaler Dauerstrom der parasitären Diode, meist identisch zum maximalen Dauerstrom des MOSFETs<br />
|-<br />
| Forward Voltage || V_SD || 1,3V || Spannungsfall an der parasitären Diode <br />
|-<br />
| Reverse Recovery Time || t_rr || 120ns || Zeit, welche die Elektronen brauchen um aus der leitenden Diode vollständig abzufließen. Während dieser Zeit fließt der Strom in '''Rückwärtsrichtung''' durch die Diode und erzeugt relativ viel Verlustleistung. <br />
|-<br />
| Reverse Recovery Charge || Q_rr || 60nC || Ladungsmenge, die während t_rr rückwärts durch die Diode fließt. <br />
|}<br />
<br />
== Haupttypen und Gatespannungslevel ==<br />
<br />
===Unterschied N-Kanal / P-Kanal FET===<br />
<br />
Im Schaltsymbol werden die MOSFET-Typen meist durch die Pfeilrichtung in der Mitte des Symbols (eigentlich "Bulk") vom oder zum Gate unterschieden. Zeigt der Pfeil zum Gate hin, handelt es sich um einen N-Kanal-FET, zeigt der Pfeil vom Gate weg um einen P-Kanal FET.<br />
<br />
Der große Vorteil des N-Kanal FETs (Elektronenleitung) ist, daß er immer niederohmiger ist, als ein gleich großer P-Kanal FET (Löcherleitung). Daher sind P-Kanal Typen bei vergleichbaren Werten auch immer größer = teuerer da weniger Chips auf einem Wafer Platz haben.<br />
<br />
Beim N-Kanal FET muss die Gatespannung positiv gegenüber Source sein. Dabei wird der FET dann leitend, wenn die sogenannte "threshold voltage" (Schwellenspannung) erreicht wird. Eine typische Anwendung ist z.&nbsp;B. ein '''Low-Side Schalter''': Source an GND, Drain an die Last, Ansteuerung des N-Kanal FETs mit 12V gleichbedeutend mit 12V ÜBER den Source = GND Potential.<br />
<br />
Beim P-Kanal FET als HS-Schalter muss die Gatespannung negativer=niedriger als das Sourcepotential sein.Beispiel.<br />
Beispiel: <br />
Lastspannung = 400V d.h. Source an 400V, Last zwischen Drain und GND, Ansteuerung des P-Kanal FETs mit 388V, also 12V UNTER dem Sourcepotential.<br />
<br />
Beim N-Kanal FET als HS-Schalter muss die Gatespannung positver=höher als das Sourcepotential sein.<br />
Beispiel:<br />
Lastspannung = 400V d.h. Drain an 400V, die Last zwischen Source und GND, Ansteuerung des N-Kanal FETs mit 412V, also 12V ÜBER dem Sourcepotential.<br />
In diesem Fall ist aber eine zusätzliche Spannungsquelle erforderlich, denn der FET wird mit einer Spannung über der Lastspannung eingeschaltet. <br />
<br />
'''Weblinks'''<br />
* [https://www.eetimes.com/a-primer-on-high-side-fet-load-switches-part-1-of-2/?utm_source=eetimes&utm_medium=networksearch A primer on high-side FET load switches (Part 1 of 2)], Qi Deng, Senior Product Marketing Manager, Mixed-Signal Products, Micrel, Inc., 5/3/2007 4:14 PM EDT, www.eetimes.com<br />
* [https://www.eetimes.com/a-primer-on-high-side-fet-load-switches-part-2-of-2/ A primer on high-side FET load switches (Part 2 of 2)], Qi Deng, Senior Product Marketing Manager, Mixed-Signal Products. Micrel, Inc., 5/7/2007 1:36 PM EDT, www.eetimes.com<br />
* [http://www.vishay.com/docs/70611/70611.pdf AN804 P-Channel MOSFETs, the Best Choice for High-Side Switching (PDF)] von Vishay Siliconix<br />
<br />
===Unterschied Logic-Level / "Normal"-Level===<br />
<br />
Den meisten FETs ist gemein, daß sie mit einer Spannung von 10..15V angesteuert werden müssen, um den minimalen Einschaltwiderstand zu erreichen. Diese FETs lassen sich nicht ohne weiteres mit einem CMOS-Pegel von 5V ansteuern. Es gibt jedoch für diesen Anwendungsfall sogenannte "Logic Level" (LL) FETs, die schon bei einer Gatespannung von etwa 4,5V voll durchgesteuert sind. Einige Kleinsignal-FETs sind schon ab ca. 1,2V voll durchgesteuert.<br />
<br />
== Beispiel zur Bauteiledimensionierung ==<br />
<br />
=== Spannungsfestigkeit ===<br />
<br />
Die höchste vorkommende Betriebsspannung + Abschaltüberspannung soll kleiner als ca. 80% der Spannungsfestigkeit des Bauteiles sein. <br />
<br />
Achtung: Zwischen dem je nach Anwendungsfall erforderlichen Pufferkondensator und dem FET wird es immer eine parasitäre Induktivität geben.<br />
Abhängig von Schaltgeschwindigkeit und Induktivität wird im Schaltmoment eine mehr oder weniger große Übrspannungsspitze produziert. Dieser Peak<br />
addiert sich auf die aktuelle Versorgungsspannung.<br />
<br />
Überschlagsrechnung als Beispiel:<br />
* Schaltgeschwindigkeit: dI/dt = -100A/µs (= Abschalten von 5A innerhalb 50ns),<br />
* Induktivität: L = 1µH (~ 1 m loses, ungebündeltes Kabel)<br />
* dU=-L*dI/dt = -1µH * (-100A / 1µs) = 100V<br />
<br />
Dies bedeutet, daß an der "Induktivität" zwischen Transistor und Kondensator - Aufgrund von Selbstinduktion im Schaltmoment - ein Überspannungspuls von ca. 100V entsteht, der auf die Betriebsspannung aufzuschlagen ist, also lieber die Leitung kürzer machen, und - sofern möglich - nicht ganz so schnell schalten.<br />
<br />
=== Stromtragfähigkeit ===<br />
<br />
In jedem Datenblatt ist eine Stromtragfähigkeit bei 25°C, und meist noch bei einer höheren Temperatur z.B. 125°C, 150°C oder 175°C Kühlfahnentemperatur angegeben. Dieser Wert ist als ERSTE Entscheidungsgrundlage ausreichend, aber aus der theoretisch abführbaren Verlustleistung errechnet, und<br />
* dient zum qualitativen Vergleich von Transistoren bezüglich ihres R_ds(on) und ihres Wärmewiderstands.<br />
* ist für die Dimensionierung einer Schaltung nur als Richtwert zu interpretieren. <br />
* ist ohne Schaltverluste genannt, und daher nur für einen Schaltbetrieb von wenigen Hz gültig. Außerdem wird ein annähernd idealer Kühlkörper unterstellt, der trotz der Verlustleistung das Gehäuse des Transistors auf der angegebenen Temperatur halten kann.<br />
* entbindet einen nicht davon den Kopf einzuschalten... siehe die nachfolgenden Zeilen.<br />
* Liegt der Strom für den die Schaltung entwickelt wird mit ca. 10..20% Abstand unter dem Datenblattwert von 125°C ist dieses Bauteil vermutlich verwendbar (siehe Detailberechnungen unten !). <br />
* Ist der benötigte Strom im Bereich oder größer als der zulässige bei 125°C sollte entweder ein anderer Typ eingesetzt oder mehrere FETs ''des gleichen Typs'' parallelgeschaltet werden.<br />
<br />
== Verlustleistung ==<br />
<br />
Hier wird eine Näherung für eine getaktete Anwendung betrachtet. In einem Transistor treten sowohl beim Ein- und Ausschalten, als auch während der Einschaltphase Verluste im Bauteil auf. Diese Verluste führen zu einer Bauteilerwärmung. Die dabei entstehende Temperatur darf die maximal zulässige Bauteiletemperatur nie überschreiten. Bei den ersten Projekten ist zu empfehlen eine berechnete Chiptemperatur von ca. 125°C nicht zu überschreiten. Fast alle aktuell verfügbaren FETs nennen im Datenblatt eine Temperatur von 175°C als ihre maximale Chiptemperatur.<br />
<br />
{| class="wikitable" style="width:32em" <br />
|+ '''Beispiel'''<br />
|-<br />
! Parameter<br />
! style="width:8em" | Symbol<br />
! style="width:8em" | Wert<br />
|-<br />
| Betriebsspannung || U<sub>N</sub> || 70 V<br />
|-<br />
| Nennstrom || I<sub>N</sub> || 30 A<br />
|-<br />
| Drain-Source Widerstand bei<br>Chiptemperatur: 125°C<br> Gatespannung: 10V || R<sub>DS<sub>on</sub></sub> || 17 mΩ<br />
|-<br />
| Pulsbreite || t<sub>on</sub> || 150 µs<br />
|-<br />
| Schaltfrequenz || ƒ<sub>schalt</sub> || 5 kHz<br>T = 200µs<br />
|-<br />
| Einschaltzeit (risetime) || t<sub>r</sub> || 500 ns<br />
|-<br />
| Ausschaltzeit (falltime) || t<sub>ƒ</sub> || 800 ns <br />
|-<br />
|}<br />
<br />
==== Leitend-Verluste ====<br />
<br />
Während der FET bei [[PWM]]-Ansteuerung eingeschaltet ist, erzeugt er Verlustleistung.<br />
<br />
<math><br />
P_\text{ON}<br />
= {I_\mathrm{N}}^2 \cdot R_\mathrm{DS_\mathrm{ON}} \cdot \frac{t_\mathrm{ON}}{T}<br />
= 30^2A^2 \cdot 17m\Omega \cdot \frac{150\mu s}{200\mu s} = 11{,}5W<br />
</math><br />
<br />
==== Schalt-Verluste ====<br />
<br />
Vereinfachter Ansatz.<br />
<br />
Einschalten:<br />
<br />
:<math>\begin{align}<br />
P_\mathrm{SW_r}<br />
&= \tfrac14 \cdot U_N \cdot I_N \cdot \frac{t_r}{T} \\<br />
&= \tfrac14 \cdot 70V \cdot 30A \cdot \frac{500ns}{200\mu s}=1{,}3W<br />
\end{align}</math><br />
<br />
Ausschalten:<br />
<br />
:<math>\begin{align}<br />
P_\mathrm{SW_f} <br />
&=\tfrac14 \cdot U_N \cdot I_N \cdot \frac{t_f}{T}\\<br />
&=\tfrac14 \cdot 70V \cdot 30A \cdot \frac{800ns}{200\mu s}=2{,}1W<br />
\end{align}</math><br />
<br />
Alternativ und genauer kann man rechnen, wenn die Ein- Ausschaltenergie im Datenblatt angegeben ist. Aber Achtung! Die Randbedingungen unter denen die genannte Energie ermittelt wurde, müssen genau so zutreffen.<br />
:<math>\begin{align}<br />
P_{SW_f} = f_{schalt} \cdot E_{ON}<br />
\end{align}</math><br />
:<math>\begin{align}<br />
P_{SW_r} = f_{schalt} \cdot E_{OFF}<br />
\end{align}</math><br />
<br />
Die Gesamtverlustleistung beträgt also in etwa 15W.<br />
<br />
Damit muß ein entsprechender [[Kühlkörper]] ausgelegt und die Chiptemperatur berechnet werden. z.&nbsp;B.:<br />
* Kühlkörper mit einem R_th von 0,2K/W<br />
* max. Umgebungstemperatur +60°C<br />
* R_th "junction-case" des FETs 0,8K/W<br />
* R_th der Wärmeleitfolie zwischen FET und Kühlkörper ca. 2,0K/W<br />
* R_th gesamt: 3,0K/W <br><br />
* Bei einer Verlustleistung von 18W und einer Umgebungstemperatur von 60°C hat der Chip eine Temperatur von ca. 18W * 3,0K/W +60°C = 114°C. ==> o.k.!<br />
<br />
Unter Berücksichtigung der Tatsache, daß hier viele Vereinfachungen vorgenommen, und die Art der Last nicht beachtet wurde ist es sinnvoll, einen gewissen Sicherheitsabstand zu den zulässigen Maximalwerten einzuhalten. Daher ist es empfehlenswert, die Chiptemperatur auf ca. 125°C zu beschränken. <br />
<br />
Des Weiteren ist hier die parasitäre Diode im FET nicht berücksichtigt.<br />
Wenn während der "off" Zeit ein Strom über die Diode fließt (Reverse recovery current oder Freilaufstrom), muß die dadurch '''zusätzlich''' entstehende Verlustleistung in die obige Berechnung der maximalen Chiptemperatur mit einfließen.<br />
<br />
==Treiberleistung==<br />
<br />
Auch wenn der MOSFET ein spannungsgesteuertes Bauelement ist, muss trotzdem bei jedem Einschalten und bei jedem Ausschalten die Gatekapazität umgeladen werden. Bei älteren Leistungs-FET - oder bei einem schlechten Design (!) - muss sogar teilweise mit negativer Spannung am Gate gearbeitet werden, um eine vollständige Sperrung zu erreichen.<br />
Diese Umladung muss möglichst schnell erfolgen, um die Verluste im FET während der Umschaltphase zu minimieren. Dazu findet ein [[Mosfet-Übersicht#MOSFET-Treiber|MOSFET-Treiber]] Verwendung. Hier eine detaillierte Beschreibung zum [[Treiber]].<br />
<br />
Da die Gatekapazität nicht direkt im Datenblatt enthalten ist kann man sich mit der Eingangskapazität Ciss behelfen. Im Arbeitspunkt ist die Gatekapazität ungefähr 5x größer als der im Datenblatt für Ciss angegebene Wert. <br />
Daher berechnet sich die Treiberleistung wie folgt: <br />
<br />
:<math>P_\text{Treiber} = C \cdot U^2 \cdot f = 5 \cdot C_\text{íss} \cdot U_\text{Gate}^2 \cdot f_\text{schalt}</math><br />
<br />
1.Beispiel, kleine MOSFET-Steuerung mit niedriger Leistung und Frequenz.<br />
<br />
:<math>P_\text{treiber} = 5 \cdot 4{,}8\,\text{nF} \cdot 15\,\text{V}^2 \cdot 10\,\text{kHz} = 54\,\text{mW}</math><br />
<br />
2.Beispiel, sehr große MOSFET-Steuerung für Induktionsheizung mit sehr hoher Leistung und Frequenz.<br />
<br />
:<math>P_\text{treiber} = 5 \cdot 24\,\text{nF} \cdot 15\,\text{V}^2 \cdot 250\,\text{kHz} = 6{,}75\,\text{W}</math><br />
<br />
Aber Achtung, so ein MOSFET-Treiber hat auch einen Eigenverbrauch, der leicht zwischen 0,5 und 1 W liegen kann.<br />
<br />
Bei niedrigen PWM-Frequenzen kann man Logic Level MOSFETs auch direkt per CMOS-Ausgang ansteuern, z.B. mit einem [[AVR]], wie in diesem [http://www.mikrocontroller.net/topic/246449#2519459 Forumsbeitrag] zu sehen ist.<br />
<br />
== Low- und High-Side ==<br />
<br />
Definition LS- und HS:<br />
<br />
;Low-Side Schalter: Der FET schaltet eine Last gegen GND - auch als LS-Schalter bezeichnet.<br />
;High-Side Schalter: Der FET schaltet eine Last an die Versorgungsspannung – auch als HS-Schalter bezeichnet.<br />
<br />
Anregungen oder Fragen auch gerne per Email an [http://www.mikrocontroller.net/user/show/powerfreak Powerfreak]. Dieser Artikel kann dadurch regelmäßig erweitert und ggf. durch ein FAQ ergänzt werden.<br />
<br />
<br />
== SOA Diagramm ==<br />
<br />
SOA-Diagramm (engl. '''S'''afe '''O'''perating '''A'''rea, sicherer Arbeitsbereich) beschreibt die zulässige Verlustleistung eines Transistors in Anhängigkeit des Drainstroms (I_D), der Drain-Source Spannung (U_DS) und der Pulsbreite. Als Beispiel sei hier der BUZ 11 genannt. Im nachfolgenden Diagramm ist das SOA-Diagramm dargestellt. Wie ist es zu verstehen? Zunächst gibt es eine Grenze auf der linken Seite, die schräge, dunkelblaue Line. Diese wird durch den minimalen R_DS_ON festgelegt, hier wirkt der MOSFET wie ein ohmscher Widerstand. Mehr Strom kann bei einer bestimmten Spannung nicht fließen. Die zweite Grenzlinie ist ganz rechts die pinkfarbene Linie, sie stellt die maximale Sperrspannung des MOSFET dar. Die dritte Grenze ist der maximal zulässige Drainstrom, hier im Beispiel 120A, dargestellt durch die gelbe Linie. Die maximale Spannung zwischen Drain und Source sowie der Drainstrom sind abhängig von der Pulsbreite, mit welcher der MOSFET betrieben wird. Bei nur 2,5µs Pulsbreite (Rechteckimpuls) müssen die beiden Parameter sich innerhalb der Fläche bewegen, welche durch die dunkelblaue, gelbe und die pinkfarbene Line begrenzt wird. Im Extremfall dürfen 50V anliegen und 120A fließen, das sind satte 6kW Pulsleistung! Werden die Pulse breiter, so sinken die zulässigen Ströme und Spannungen, bei 1ms (dunkelblaue Linie bis zur braunen Linie, dann zur pinkfarbenen Linie) sind maximal noch 50V und 7A zulässig, also nur noch 350W. Die letzte Linie stellt den Fall für Gleichstrom (engl. '''D'''irect '''C'''urrent), also Dauerbelastung dar, hier sind bei 50V maximal 1,5A zulässig, was einer Dauerverlustleistung von 75W entspricht. MOSFETs, welche nur für Schaltbetrieb und nicht für [[#Linearbetrieb von MOSFETs | Linearbetrieb]] geeignet sind, haben keine Kennlinie für DC. Im normalen Schaltbetrieb liegt der Arbeitspunkt auf der linken Grenzlinie R_DS_ON_MIN. Nur im Linearbetrieb liegt der Arbeitspunkt innerhalb der Fläche, welche durch die Außenlinien begrenzt wird.<br />
<br />
[[bild: SOA-BUZ11.png | thumb | 300px| SOA-Diagramm]]<br />
<br />
Bei der Anwendung des Diagramms gilt es einiges zu beachten. Die Pulsleistungen sind nur zulässig, wenn der MOSFET vorher kalt ist, sprich ca. 25°C Sperrschichttemperatur hat. War er vorher schon heiß, reduziert sich die zulässige Belastung deutlich. Ebenso dürfen die Pulse nicht zu schnell wiederholt werden, denn dann ist der MOSFET noch vom vorherigen Puls aufgeheizt. Im Fall von DC sind 75W Verlustleistung auch eher ein theoretischer Wert, welcher real nur schwer erreicht werden kann, wenn der MOSFET auf einem sehr großen [[Kühlkörper]] optimal montiert ist. Praktisch liegen die erreichbaren Werte eher bei der Hälfte.<br />
<br />
(Anm. Eigentlich müsste für die R_DS_ON Grenzlinie R = U / I der minimale R_DS_ON rauskommen, hier ~40mOhm, es kommen aber ~80mOhm raus. Die Ursache dafür ist unklar, möglicherweise liegt hier ein Sicherheitsfaktor zu grunde).<br />
<br />
{{Clear}}<br />
<br />
== Linearbetrieb von MOSFETs ==<br />
<br />
Der Großteil der Anwendungen nutzt MOSFETs als Schalter, d.h. der MOSFET ist entweder voll gesperrt oder voll durchgesteuert. Dafür gelten auch all die Hinweise in diesem Artikel. In bestimmten Anwendungen werden MOSFETs aber auch im Linearbetrieb eingesetzt, z.B in linearen Endstufen für Audio, Video, elektronischen Lasten und Stromquellen. Hier muss man einiges beachten. Ein verbreiteter Irrtum besteht darin zu glauben, MOSFETs könne man im Linearbetrieb einfach parallel schalten, weil der positive Temperaturkoeffizient von <math>R_{DS(ON)}</math> eine Symmetrierung bewirkt, ähnlich den Emitterwiderständen bei parallelgeschalteten Bipolartransistoren. Das ist ''ausschließlich'' im Schaltbetrieb möglich, und daher falsch! Im Linearbetrieb spielt der Temperaturkoeffizient von <math>R_{DS(ON)}</math> keine Rolle, weil der MOSFET selten bis nie komplett durchgesteuert ist. Eben darum ist beim Linearbetrieb der minimale <math>R_{DS(ON)}</math> in den meisten Fällen unwichtig und man kann auch eher hochohmige, ältere MOSFETs verwenden, wie z.B. den BUZ11.<br />
<br />
Hier wirkt vielmehr der negative Temperaturkoeffizient (TK) der Thresholdspannung <math>U_{GS(thr)}</math>, vergleichbar dem negativen TK der Basis-Emitter-Spannung von Bipolartransistoren. D.h. mit steigender Temperatur und konstanter Gate-Source-Spannung steigt der Stromfluss der Drain-Source Strecke. In einer Parallelschaltung von MOSFETs würde dies bedeuten, dass der MOSFET mit dem geringfügig größeren Drainstrom (Fertigungstoleranzen) wärmer wird, was zu einem weiter steigenden Drainstrom und damit noch mehr Wärme führt. Damit ist die Schaltung thermisch instabil und würde zum Durchbrennen der MOSFETs führen, einer nach dem Anderen. <br />
<br />
Um das zu verhindern muss man relativ große Ausgleichswiderstände in die Source-Leitung der einzelnen MOSFETs schalten, um diese Drift zu kompensieren. Dadurch verschlechtert sich natürlich der Wirkungsgrad des Verstärkers. MOSFETs haben einen TK von typisch -5mV/K für <math>U_{GS(thr)}</math>, das ist mehr als das doppelte von Bipolartransistoren mit typisch -2mV/K, weshalb die Symmetrierungswiderstände mehr als doppelt so groß sein müssen. Weiterhin muss man beachten, dass die Toleranzen von <math>U_{GS(thr)}</math> sehr groß sind, im Bereich von Volt! Das kann man sinnvoll nicht mehr mit Gatewiderständen symmetrieren, hier muss man die MOSFETs ausmessen und Gruppen mit geringen Toleranzen in einer Schaltung verwenden (engl. matching). <br />
<br />
Eine andere Möglichkeit ist die getrennte Ansteuerung der einzelnen MOSFETs, das wird oft in elektronischen Lasten bzw. [[Konstantstromquelle#Konstantstromquelle mit Operationsverstärker und Transistor | Konstantstromquellen]] gemacht. Hier treten keine zusätzlichen Verluste auf und der Mehraufwand in der Ansteuerung ist meist unkritisch.<br />
<br />
Weiterhin muss man beachten, dass viele der heutigen HochleistungsMOSFETs intern eine Parallelschaltung vieler kleiner MOSFET-Zellen (z.B. sogenannte Trench-FET) sind, und somit oft für den Linearbetrieb ungeeignet sind. Denn auch dort können einzelne Zellen überhitzen und durchbrennen (Hot Spot). Ob ein MOSFET für den Linearbetrieb tauglich ist steht manchmal im Datenblatt, oft aber eher nicht, eben weil die meisten MOSFETs als Schalter entwickelt und gebaut sind. Typische Vertreter für Linearbetrieb findet man in der [[MOSFET-Übersicht]]. Ein wichtiges Indiz für Linearbetrieb ist eine Kurve für DC im [[#SOA_Diagramm | SOA-Diagramm]]. Meist geht es dort nur bis 10ms, DC fehlt, eben weil DC (engl. '''D'''irect '''C'''urrent = Gleichstrom = Linearbetrieb) nicht zulässig ist. Manchmal hat der Hersteller auch "vergessen", die Kennlinie für DC mit reinzuschreiben, wie z.B. bei [http://www.irf.com/product-info/hi-rel/alerts/fv5-p-09-01-A.pdf IRF], wie in diesem [http://www.mikrocontroller.net/topic/291760#3106758 Beitrag] zu erfahren ist.<br />
Ein recht gutes Indiz dafür, ob ein FET für den Linearbetrieb taugt, ist die Vorwärtssteilheit. Diese kennzeichnet die Abhängigkeit des Drainstromes von der Ansteuerung am Gate als <math>S = \Delta i_d/\Delta u_{gs}</math>. Moderne Trench-FET erreichen heute Steilheiten im dreistelligen Bereich und sind für Linearanwendungen völlig unbrauchbar. Zum Vergleich: Der BUZ11 kommt mit gerade einmal 4 bis 5 Siemens daher.<br />
<br />
In diesem Beitrag wird die DC-Linie im SOA-Diagramm noch genauer erklärt: [http://www.mikrocontroller.net/topic/319961#3473567 Re: MOSFET Linearbetrieb möglich?]<br />
<br />
<br />
== Siehe auch ==<br />
<br />
* [[Leistungselektronik]]<br />
* [[Mosfet-Übersicht]]<br />
* [[IGBT]]<br />
* [[TRIAC]]<br />
* [[Kühlkörper]] <br />
* [[Zwischenkreiskapazität]]<br />
* [[Treiber]]<br />
* [[Snippets#Wie_schlie.C3.9Fe_ich_einen_MOSFET_an_einen_Mikrocontroller_an.3F|Wie schließe ich einen Mosfet an einen Mikrocontroller an?]]<br />
* [http://www.mikrocontroller.net/articles/H-Br%C3%BCcken_%C3%9Cbersicht Übersicht H-Brücken]<br />
* [http://www.mikrocontroller.net/topic/168218#1609684 Forumsbeitrag]: MOSFETs im Linearbetrieb<br />
* [http://www.mikrocontroller.net/topic/186785#new Forumsbeitrag]: nochmal MOSFETs im Linearbetrieb<br />
* [http://www.mikrocontroller.net/topic/319961#3473567 Forumsbeitrag]: sehr ausführlicher Forumsbeitrag über MOSFETs im Linearbetrieb. Berücksichtigt auch den Spirito-Effekt.<br />
* [http://www.mikrocontroller.net/topic/143324#new Forumsbeitrag]: Über eine elektronische Last, sehr lang<br />
*[http://www.mikrocontroller.net/topic/246449#2519459 Forumsbeitrag]: Logic Level MOSFETs direkt mit einem [[AVR]] treiben.<br />
* [http://www.mikrocontroller.net/topic/267254#2787855 Forumsbeitrag]: MOSFETs im Linearbetrieb, Laborerfahrungen<br />
* [http://www.mikrocontroller.net/topic/267254#2787945 Forumsbeitrag]: MOSFETs für Linearbetrieb<br />
* [https://www.mikrocontroller.net/topic/269642?goto=2820617#2820617 Forumsbeitrag]: Verpol- und Überspannungsschutz mit MOSFETs<br />
* [https://www.mikrocontroller.net/topic/425414#4981611 Forumsbeitrag]: Linearbetrieb von MOSFETs<br />
<br />
== Weblinks ==<br />
<br />
* [http://www.elektronikinfo.de/strom/feldeffekttransistoren.htm Feldeffekttransistoren bei elektronikinfo.de]<br />
* [http://www.elektronik-kompendium.de/sites/bau/0207011.htm FET im ELKO]<br />
* [http://www.elektronik-kompendium.de/sites/bau/0510161.htm MOSFET im ELKO]<br />
* [http://www.sprut.de/electronic/switch/nkanal/nkanal.html MOSFET bei sprut.de]<br />
* [http://sound.westhost.com/articles/hexfet.htm#51 MOSFETs in Audioendstufen, engl.]<br />
* [http://irf.custhelp.com/cgi-bin/irf.cfg/php/enduser/std_adp.php?p_faqid=214&p_created=1019728945&p_sid=pt9ITiCj&p_accessibility=0&p_redirect=&p_lva=&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9MTQsMTQmcF9wcm9kcz0mcF9jYXRzPSZwX3B2PSZwX2N2PSZwX3BhZ2U9MSZwX3NlYXJjaF90ZXh0PWxpbmVhcg**&p_li=&p_topview=1 FAQ Answer ID 214 bei IRF zum Linearbetrieb]<br />
* [http://www.nxp.com/documents/application_note/AN11158.pdf AN11158 - Understanding power MOSFET data sheet parameters] von NXP (PDF)<br />
* [https://assets.nexperia.com/documents/technical-note/TN00008.pdf TN00008 - Power MOSFET frequently asked questions and answers] von nexperia (PDF)<br />
* [http://www.infineon.com/dgdl/Infineon+-+Application+Note+-+PowerMOSFETs+-+OptiMOS%E2%84%A2+-+Linear+Mode+Operation+and+SOA+Power+MOSFETs.pdf?fileId=db3a30433e30e4bf013e3646e9381200 AN: Linear Mode Operation andSafe Operating Diagram of Power-MOSFETs] von Infineon (PDF)<br />
* [http://www.ixys.com/Documents/Articles/Article_Linear_Power_MOSFETs.pdf MOSFETs Withstand Stress of Linear-Mode Operation] Neuentwickelte MOSFETs für Linearbetrieb (PDF)<br />
<br />
[[Kategorie:Bauteile]] [[Kategorie:Leistungselektronik]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=FET&diff=107026FET2024-07-19T16:42:18Z<p>Heha: /* FET-Typen */</p>
<hr />
<div>Dieser Artikel versteht sich als Unterpunkt zum Artikel [[Leistungselektronik]]<br />
<br />
<br />
Ein FET (engl. '''F'''ield '''E'''ffect '''T'''ransistor) ist ein Feldeffekttransistor. Der FET ist ein Bauelement, das im Gegensatz zum Bipolartransistor (engl. '''B'''ipolar '''J'''unction '''T'''ransistor, BJT) mit Spannung und nicht mit Strom gesteuert wird. Unterschieden werden<br />
* MOSFET = engl. '''M'''etall '''O'''xide '''S'''emiconductor '''F'''ield '''E'''ffect '''T'''ransistor; Metalloxidschicht-FET, größte Teilgruppe der FETs mit isoliertem Gate <br />
* JFET = engl. '''J'''unction '''F'''ield '''E'''ffect '''T'''ransistor, Übergangszonen FET, der steuerbare Kanal wird durch einen PN-Übergang wie in einer Diode gebildet<br />
<br />
Die drei Anschlüsse eines FETs werden ''Gate'', ''Drain'' und ''Source'' genannt. Unter Umständen ist ein vierter Anschluß vorhanden, der ''Bulk'' genannt wird. Normalerweise ist Bulk intern mit Source verbunden. Wenn dies nicht der Fall ist, muss diese Verbindung durch den Designer in der Schaltung hergestellt werden.<br />
<br />
== FET-Typen ==<br />
<br />
FETs werden hauptsächlich unterschieden in N-Kanal und P-Kanal, sowie "selbst sperrend = Anreicherungstyp" (engl. enhancement type) und "selbst leitend = Verarmungstyp" (engl. depletion type). Beim selbstleitenden FET ist der Transistor bei 0V Gate-Source Spannung maximal leitend (durchgesteuert) und wird durch Anlegen einer Spannung ans Gate gesperrt. Beim selbstsperrenden FET (größte Gruppe) ist der Transistor bei 0V Gate-Source Spannung gesperrt und wird durch Anlegen einer Spannung ans Gate leitend. Ist die Linie zwischen Drain und Source durchgezogen handelt es sich um einen selbstleitenden, bei einer gestrichelten Linie um einen selbstsperrenden FET. JFETs gibt es nur als Verarmungstyp.<br />
<br />
Im weiteren Artikel wird nur der '''selbstsperrende''' MOSFET betrachtet, weil nur dieser einen althergebrachten Bipolartransistor „ersetzen“ kann.<br />
<br />
{| class="wikitable"<br />
|+ '''Typen von Feldeffekttransistoren<br/>&nbsp;'''<br />
|-<br />
! style="width:10em" | Typ <br />
! N-Kanal <br />
! P-Kanal<br />
|- valign="top"<br />
| JFET<br/>SFET<br/>(selbst leitend) || [[bild:JFET-N.png|center]]<br />
* drittgrößte Gruppe<br />
* bislang nur für kleine Leistungen verfügbar<br />
* JFETs mit hoher Leistung sind im Kommen<br />
* Eingangsstufen von OPVs<br />
* Eingangsstufen von HF-Verstärkern bis in den GHz-Bereich<br />
* als einfache [[Konstantstromquelle]] geeignet<br />
| [[bild:JFET-P.png|center]]<br />
* selten<br />
* ersatzhalber für „fehlenden“ P-Kanal-Verarmungs-MOSFET<br />
* Ältester Vertreter der Unipolartransistoren<br />
|- valign="top"<br />
| MOSFET<br/>Anreicherungstyp<br/>(selbst sperrend)<br/>''Enhancement Mode'' || [[bild:MOS-EN.png|center]]<br />
* Mit Abstand größte Gruppe; wenn nicht besonders erwähnt ist ''dieser'' gemeint<br />
* Eingangsstufen von HF-Verstärkern bis in den GHz-Bereich<br />
** Typen mit zwei Gates zum Regeln und Mischen üblich<br />
* Auch als Doppel-MOSFET oder zusammen mit P-Kanal-MOSFET in einem Gehäuse gängig<br />
| [[bild:MOS-EP.png|center]]<br />
* zweitgrößte Gruppe<br />
* bei gleicher Geometrie etwas schlechter als ein N-Kanal-Typ, da „Löcherleitung“ (aus „Defektelektronen“ = gedachte positive Ladungsträger) vorliegt<br />
* Auch als Doppel-MOSFET oder zusammen mit N-Kanal-MOSFET in einem Gehäuse gängig<br />
|- valign="top"<br />
| MOSFET<br/>Verarmungstyp<br/>(selbst leitend)<br/>''Depletion Mode'' || [[bild:MOS-DN.png|center]]<br />
* selten aber käuflich<br />
* Sinnvolle Anwendungen ergeben sich vor allem in Reihenschaltungen<br />
| [[bild:MOS-DP.png|center]]<br />
* Nicht in freier Wildbahn gesichtet<br />
|}<br />
<br />
=== Vorteile des FET ===<br />
<br />
* Niedrigere Verluste als bei Bipolartransistoren.<br />
* Sehr schnelles Schalten möglich, daher für sehr hohe Frequenzen geeignet (keine Speicherzeit wie beim BJT).<br />
* Einfaches Parallelschalten im Schaltbetrieb, da Unterschiede im <math>R_{DS,on}</math> durch den positiven Temperaturkoeffizienten ausgeglichen werden.<br />
* Leistungslose Ansteuerung im statischen Fall, jedoch hohe Umladeverluste am Gate!<br />
* oft preiswerter als vergleichbare Bipolartransistoren (engl. '''B'''ipolar '''J'''unction '''T'''ransistor, BJT)<br />
* Relativ unempfindlich gegen Überspannung zwischen Drain und Source. Bei Überschreitung der Maximalspannung zwischen Drain und Source findet ein sogenannter "Durchbruch" statt. Dies ist vergleichbar mit dem Zener-Effekt. Ist die Energiemenge begrenzt, ist dieser Durchbruch reversibel und der FET wird NICHT zerstört. Beim Bipolartransistor ist die dafür zulässige Energiemenge viel kleiner, weil die den Strom durchquerende Fläche zu Hotspots neigt.<br />
<br />
=== Nachteile des FET ===<br />
<br />
* Nur bedingt für hohe Spannungen [[Transistor#Wann setzt man einen MOSFET, Bipolartransistor, IGBT oder Thyristor ein ? |geeignet]], die ON-Verluste sind ab ca. 250V höher als bei einem [[IGBT]]. <br />
* Parasitäre Diode parallel zur Drain-Source Strecke ist immer enthalten, das (Ab-)Schaltverhalten dieser Dioden ist meist schlechter als separate Dioden, was häufig zu unerwünschten Schwingungen führt.<br />
* Empfindlicher gegen ESD am Gate als BJT<br />
* Positiver Temperaturkoeffizient (TK), der <math>R_{DS,on}</math> ist stark temperaturabhängig und steigt von 25°C (Datenblattangabe) auf 150°C ungefähr um den Faktor 2. Dadurch steigen auch die Verluste und damit die Erwärmung des Bauteiles.<br />
<br />
=== Erklärung der wichtigsten Datenblattwerte ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! style="width:12em" | '''Parameter'''<br />
! style="width:7em" | '''Symbol'''<br />
! style="width:6em" | Beispiel<br />
! '''Erklärung'''<br />
|-<br />
| Drain Source Voltage <br>(Breakdown) || V(BR)_DSS <br> V_DS || 75 V || Maximale Spannungsfestigkeit des Bauteiles zwischen Drain und Source<br />
|-<br />
| Continuous Drain Current || I_D(on) || 55 A @ 125 °C || Maximaler Dauerstrom bei 125°C Gehäusetemperatur <br />
|-<br />
| Pulsed Drain Current || ID_pulse <br> I_CD(on) || 240 A || Maximaler Pulsstrom (Achtung die zulässige Zeitdauer des Pulses kann nur über die maximale Junctiontemperatur ermittelt werden)<br />
|-<br />
| Gate Charge || Q<sub>GS</sub> || 320 nC || Gate-Ladung in Coloumb oder Amperesekunden, die zum Ein- oder Ausschalten des MOSFET erforderlich ist. Dies berücksichtigt die Nichtlinearität der Kapazität und (richtig?) den Miller-Effekt. Mit dieser Angabe wird der für das Schalten von Leistungs-MOSFET benötigte Gatestrom für eine bestimmte Schaltzeit ermittelt. Dieser liegt üblicherweise im einstelligen Ampere-Bereich. Moderne Typen mit extra geringer Gate-Ladung können so schneller schalten.<br />
|-<br />
| Repetetive Avalanche Energy || t_sc || 280 mJ || Maximale Energie, welche beim Avalanche Durchbruch bei Überschreiten der maximalen Drain-Source Spannung im MOSFET bei z.&nbsp;B. 1% Puls/Pausen Verhältnis regelmäßig auftreten darf, ohne den FET zu schädigen<br />
|-<br />
| Drain-Source<br>ON Resistance || R<sub>DS_ON</sub> || 0,01 Ω || Widerstand des eingeschalteten FETs bei '''25°C''', V_GS = 10V und ID = 30A<br />
|-<br />
| Drain-Source<br>ON Resistance || R<sub>DS_on</sub> || 0,021 Ω || Widerstand des eingeschalteten FETs bei '''175°C''', V_GS = 10V und ID = 30A<br />
|-<br />
| Thermal Resistance<br>(junction-case) || R<sub>th_JC</sub> || 0,8 K/W || Thermischer Widerstand im Transistor vom der „Sperrschicht“ (junction eines Bipolartransistors, ja altmodischer Index, hier besser „Kanal“) bis zur Rückseite oder bestmöglichen Kühlmöglichkeit des Transistorgehäuses (case)<br />
|-<br />
| Gate-Source<br>Threshold Voltage || V_GS(th) || 2,0-4,5 V || Gatespannung, ab welcher der Transistor minimal leitend wird (I_D typisch 100-200µA), große Toleranz, typisch 1:2 zwischen Minimum und Maximum<br />
|-<br />
| Turn-on Delay || t_d(on) || 40 ns || Verzögerung zwischen dem Einschalten am Gate bis zur Reaktion im Drainstrom<br />
|-<br />
| Rise Time || t_r || 200 ns || Anstiegszeit des Transistorstromes am Drain<br />
|-<br />
| Turn-off Delay || t_d(off) || 120 ns || Verzögerung zwischen Abschalten am Gate bis zur Reaktion im Drainstrom<br />
|-<br />
| Fall Time || t_f || 60 ns || Abfallzeit des Transistorstromes am Drain <br />
|}<br />
<br />
Die oben genannten Zeiten gelten ausschließlich unter den angegebenen Messbedingungen (Gatewiderstand, Treiberspannung, sowie einer '''FET-Teperatur von 25°C!''') und müssen für die eigene Anwendung ggf. neu berechnet werden. Meist wird man sie eher messen, weil die Rechung zu aufwändig und bisweilen unmöglich ist. <br />
<br />
==== Gate-Source Threshold Voltage ====<br />
Gerade bei der '''Gate-Source Threshold Voltage <math>V_{GS}(th)</math>''' gibt es hier immer wieder Verwirrung. Sie gibt an, ab welcher Spannung der MOSFET anfängt, minimal leitfähig zu werden. Diese Spannung ist technologisch bedingt auch heute noch einer starken Toleranz unterworfen, typischerweise hat der Bereich bei dem der FET zu leiten beginnt eine Spreizung von etwa 1:2 zwischen Minimum und Maximum. Welche Spannung man nun wirklich anlegen muss, um den gewünschten <math>R_{DS}(on)</math> zu erreichen kann der Tabelle im jeweiligen Datenblatt entnommen werden. Dabei unbedingt die angegebene Gatespannung beachten, nur dieser Wert ist garantiert!.<br />
<br />
[[bild: IRLZ34N_R_DS_ON.png | thumb | 800px | R_DS_ON im Datenblatt des IRLZ34N]]<br />
{{Clear}}<br />
<br />
Die Kurvenschar von <math>I_D</math> über <math>U_{DS}</math> in Abhängigkeit von <math>U_{GS}</math> stellt immer nur typische Werte dar, keine garantierten Extremwerte (engl. worst case). Als Standardwerte kann man 10-15V für einen Standardtypen und ca. 3-5V für einen Logic Level MOSFET (LL-FET) ansetzen. Kleinsignal-FETs leiten schon ab ca 1V. Bei Ansteuerung mit 5V benötigt man also einen Typen, der '''sicher''' bei 5V voll durchgesteuert ist, z.B. IRLZ34N. Bei 3,3V ist er bereits nicht mehr zuverlässig nutzbar. Es gibt auch Typen mit noch geringerer Spannung für Vollaussteuerung. Wer einen BUZ11 (<math>V_{GS}(th)</math> 4V max.) mit 5V ansteuert riskiert ein Abfackeln des MOSFETs, denn je nach Toleranz kann er bereit ganz gut aufgesteuert sein oder auch nicht. Das soll in den nachfolgenden Diagrammen dargestellt werden. Zunächst die Transferkennlinie. Sie gibt an, wieviel Drainstrom in Abhängigkeit der Gatespannung fließen kann, wobei die Drainspannung konstant ist, hier im Beispiel 25V. Ein typischer BUZ11 (mittlere, schwarze Kurve) fängt bei 3V zu leiten an und erreicht bei 6V am Gate ca. 17A. Erwischt man nun ein kritisches Exemplar, das erst bei 4V zu leiten anfängt (rechte, rote Kurve um 1V parallel verschoben), so kann dieser bei 6V nur 8A leiten, für 17A braucht er 7V. Der günstige Fall, daß der BUZ11 schon bei 2V anfängt zu leiten sieht man in der linken, roten Kurve.<br />
<br />
[[bild: BUZ11_UGS_ID.png | thumb | 800px | Transferkennlinie des BUZ11]]<br />
{{Clear}}<br />
<br />
Wenn man die drei Fälle (min, typ, max) mit 5V ansteuert, erhält man die Arbeitspunkte 1-3 mit einem maximal schaltbaren Drainstrom von 2,5, 8 und 17A. Diese kann man in das Ausgangskennlinienfeld übertragen. Wir nehmen max. 1V U_DS an. Es ergeben sie die gleichen Ströme. Der maximale Drainstrom weicht um -5,5/+9A vom typischen Fall ab. Erhöht man nun die Gate-Source Spannung auf 10V (Arbeitspunkt 4), schwankt der maximal schaltbare Drainstrom nur noch um -2/+2A, außerdem liegt er mit 30A deutlich höher. Der BUZ11 ist somit sicher durchgesteuert.<br />
<br />
[[bild: BUZ11_UDS_ID_UGS.png | thumb | 800px | Ausgangskennlinie des BUZ11]]<br />
{{Clear}}<br />
<br />
==== Parasitäre Diode ====<br />
<br />
Der Schwerpunkt in der FET-Entwicklung liegt auf den geringst-möglichen <math>R_{DS}(on)</math>, die Diode entsteht auf Grund des Herstellungsprozesses, und wird nur nachrangig verbessert, da viele Optimierungsversuche auch einen Einfluss auf wichtige Kennwerte des FETs hatten und haben.<br />
Daher muss sorgfältig geprüft werden, ob die Schaltgeschwindigkeit, die Recovery-Time und die damit verbundenen Verluste sowie die dabei erzeugte unerwünschte EMV-Abstahlung tolerierbar ist, oder nicht.<br />
Hier hilft es oft eine optimierte Diode / Schottky-Diode zum FET parallel zu schalten. Ganz ausblenden läßt sich die parasitäre Diode jedoch nicht, jedoch kann man den Anteil des Stromes beeinflussen, der über die intere Diode fliest.<br />
<br />
{| class="wikitable"<br />
|+ ''' Parasitäre Diode des FETs '''<br />
|-<br />
! style="width:10em" | '''Parameter'''<br />
! style="width:6em" | '''Symbol'''<br />
! style="width:6em" | '''Beispiel'''<br />
! '''Erklärung'''<br />
|-<br />
| Continuous Current || I_S || 75A || Maximaler Dauerstrom der parasitären Diode, meist identisch zum maximalen Dauerstrom des MOSFETs<br />
|-<br />
| Forward Voltage || V_SD || 1,3V || Spannungsfall an der parasitären Diode <br />
|-<br />
| Reverse Recovery Time || t_rr || 120ns || Zeit, welche die Elektronen brauchen um aus der leitenden Diode vollständig abzufließen. Während dieser Zeit fließt der Strom in '''Rückwärtsrichtung''' durch die Diode und erzeugt relativ viel Verlustleistung. <br />
|-<br />
| Reverse Recovery Charge || Q_rr || 60nC || Ladungsmenge, die während t_rr rückwärts durch die Diode fließt. <br />
|}<br />
<br />
== Haupttypen und Gatespannungslevel ==<br />
<br />
===Unterschied N-Kanal / P-Kanal FET===<br />
<br />
Im Schaltsymbol werden die MOSFET-Typen meist durch die Pfeilrichtung in der Mitte des Symbols (eigentlich "Bulk") vom oder zum Gate unterschieden. Zeigt der Pfeil zum Gate hin, handelt es sich um einen N-Kanal-FET, zeigt der Pfeil vom Gate weg um einen P-Kanal FET.<br />
<br />
Der große Vorteil des N-Kanal FETs (Elektronenleitung) ist, daß er immer niederohmiger ist, als ein gleich großer P-Kanal FET (Löcherleitung). Daher sind P-Kanal Typen bei vergleichbaren Werten auch immer größer = teuerer da weniger Chips auf einem Wafer Platz haben.<br />
<br />
Beim N-Kanal FET muss die Gatespannung positiv gegenüber Source sein. Dabei wird der FET dann leitend, wenn die sogenannte "threshold voltage" (Schwellenspannung) erreicht wird. Eine typische Anwendung ist z.&nbsp;B. ein '''Low-Side Schalter''': Source an GND, Drain an die Last, Ansteuerung des N-Kanal FETs mit 12V gleichbedeutend mit 12V ÜBER den Source = GND Potential.<br />
<br />
Beim P-Kanal FET als HS-Schalter muss die Gatespannung negativer=niedriger als das Sourcepotential sein.Beispiel.<br />
Beispiel: <br />
Lastspannung = 400V d.h. Source an 400V, Last zwischen Drain und GND, Ansteuerung des P-Kanal FETs mit 388V, also 12V UNTER dem Sourcepotential.<br />
<br />
Beim N-Kanal FET als HS-Schalter muss die Gatespannung positver=höher als das Sourcepotential sein.<br />
Beispiel:<br />
Lastspannung = 400V d.h. Drain an 400V, die Last zwischen Source und GND, Ansteuerung des N-Kanal FETs mit 412V, also 12V ÜBER dem Sourcepotential.<br />
In diesem Fall ist aber eine zusätzliche Spannungsquelle erforderlich, denn der FET wird mit einer Spannung über der Lastspannung eingeschaltet. <br />
<br />
'''Weblinks'''<br />
* [https://www.eetimes.com/a-primer-on-high-side-fet-load-switches-part-1-of-2/?utm_source=eetimes&utm_medium=networksearch A primer on high-side FET load switches (Part 1 of 2)], Qi Deng, Senior Product Marketing Manager, Mixed-Signal Products, Micrel, Inc., 5/3/2007 4:14 PM EDT, www.eetimes.com<br />
* [https://www.eetimes.com/a-primer-on-high-side-fet-load-switches-part-2-of-2/ A primer on high-side FET load switches (Part 2 of 2)], Qi Deng, Senior Product Marketing Manager, Mixed-Signal Products. Micrel, Inc., 5/7/2007 1:36 PM EDT, www.eetimes.com<br />
* [http://www.vishay.com/docs/70611/70611.pdf AN804 P-Channel MOSFETs, the Best Choice for High-Side Switching (PDF)] von Vishay Siliconix<br />
<br />
===Unterschied Logic-Level / "Normal"-Level===<br />
<br />
Den meisten FETs ist gemein, daß sie mit einer Spannung von 10..15V angesteuert werden müssen, um den minimalen Einschaltwiderstand zu erreichen. Diese FETs lassen sich nicht ohne weiteres mit einem CMOS-Pegel von 5V ansteuern. Es gibt jedoch für diesen Anwendungsfall sogenannte "Logic Level" (LL) FETs, die schon bei einer Gatespannung von etwa 4,5V voll durchgesteuert sind. Einige Kleinsignal-FETs sind schon ab ca. 1,2V voll durchgesteuert.<br />
<br />
== Beispiel zur Bauteiledimensionierung ==<br />
<br />
=== Spannungsfestigkeit ===<br />
<br />
Die höchste vorkommende Betriebsspannung + Abschaltüberspannung soll kleiner als ca. 80% der Spannungsfestigkeit des Bauteiles sein. <br />
<br />
Achtung: Zwischen dem je nach Anwendungsfall erforderlichen Pufferkondensator und dem FET wird es immer eine parasitäre Induktivität geben.<br />
Abhängig von Schaltgeschwindigkeit und Induktivität wird im Schaltmoment eine mehr oder weniger große Übrspannungsspitze produziert. Dieser Peak<br />
addiert sich auf die aktuelle Versorgungsspannung.<br />
<br />
Überschlagsrechnung als Beispiel:<br />
* Schaltgeschwindigkeit: dI/dt = -100A/µs (= Abschalten von 5A innerhalb 50ns),<br />
* Induktivität: L = 1µH (~ 1 m loses, ungebündeltes Kabel)<br />
* dU=-L*dI/dt = -1µH * (-100A / 1µs) = 100V<br />
<br />
Dies bedeutet, daß an der "Induktivität" zwischen Transistor und Kondensator - Aufgrund von Selbstinduktion im Schaltmoment - ein Überspannungspuls von ca. 100V entsteht, der auf die Betriebsspannung aufzuschlagen ist, also lieber die Leitung kürzer machen, und - sofern möglich - nicht ganz so schnell schalten.<br />
<br />
=== Stromtragfähigkeit ===<br />
<br />
In jedem Datenblatt ist eine Stromtragfähigkeit bei 25°C, und meist noch bei einer höheren Temperatur z.B. 125°C, 150°C oder 175°C Kühlfahnentemperatur angegeben. Dieser Wert ist als ERSTE Entscheidungsgrundlage ausreichend, aber aus der theoretisch abführbaren Verlustleistung errechnet, und<br />
* dient zum qualitativen Vergleich von Transistoren bezüglich ihres R_ds(on) und ihres Wärmewiderstands.<br />
* ist für die Dimensionierung einer Schaltung nur als Richtwert zu interpretieren. <br />
* ist ohne Schaltverluste genannt, und daher nur für einen Schaltbetrieb von wenigen Hz gültig. Außerdem wird ein annähernd idealer Kühlkörper unterstellt, der trotz der Verlustleistung das Gehäuse des Transistors auf der angegebenen Temperatur halten kann.<br />
* entbindet einen nicht davon den Kopf einzuschalten... siehe die nachfolgenden Zeilen.<br />
* Liegt der Strom für den die Schaltung entwickelt wird mit ca. 10..20% Abstand unter dem Datenblattwert von 125°C ist dieses Bauteil vermutlich verwendbar (siehe Detailberechnungen unten !). <br />
* Ist der benötigte Strom im Bereich oder größer als der zulässige bei 125°C sollte entweder ein anderer Typ eingesetzt oder mehrere FETs ''des gleichen Typs'' parallelgeschaltet werden.<br />
<br />
== Verlustleistung ==<br />
<br />
Hier wird eine Näherung für eine getaktete Anwendung betrachtet. In einem Transistor treten sowohl beim Ein- und Ausschalten, als auch während der Einschaltphase Verluste im Bauteil auf. Diese Verluste führen zu einer Bauteilerwärmung. Die dabei entstehende Temperatur darf die maximal zulässige Bauteiletemperatur nie überschreiten. Bei den ersten Projekten ist zu empfehlen eine berechnete Chiptemperatur von ca. 125°C nicht zu überschreiten. Fast alle aktuell verfügbaren FETs nennen im Datenblatt eine Temperatur von 175°C als ihre maximale Chiptemperatur.<br />
<br />
{| class="wikitable" style="width:32em" <br />
|+ '''Beispiel'''<br />
|-<br />
! Parameter<br />
! style="width:8em" | Symbol<br />
! style="width:8em" | Wert<br />
|-<br />
| Betriebsspannung || U<sub>N</sub> || 70 V<br />
|-<br />
| Nennstrom || I<sub>N</sub> || 30 A<br />
|-<br />
| Drain-Source Widerstand bei<br>Chiptemperatur: 125°C<br> Gatespannung: 10V || R<sub>DS<sub>on</sub></sub> || 17 mΩ<br />
|-<br />
| Pulsbreite || t<sub>on</sub> || 150 µs<br />
|-<br />
| Schaltfrequenz || ƒ<sub>schalt</sub> || 5 kHz<br>T = 200µs<br />
|-<br />
| Einschaltzeit (risetime) || t<sub>r</sub> || 500 ns<br />
|-<br />
| Ausschaltzeit (falltime) || t<sub>ƒ</sub> || 800 ns <br />
|-<br />
|}<br />
<br />
==== Leitend-Verluste ====<br />
<br />
Während der FET bei [[PWM]]-Ansteuerung eingeschaltet ist, erzeugt er Verlustleistung.<br />
<br />
<math><br />
P_\text{ON}<br />
= {I_\mathrm{N}}^2 \cdot R_\mathrm{DS_\mathrm{ON}} \cdot \frac{t_\mathrm{ON}}{T}<br />
= 30^2A^2 \cdot 17m\Omega \cdot \frac{150\mu s}{200\mu s} = 11{,}5W<br />
</math><br />
<br />
==== Schalt-Verluste ====<br />
<br />
Vereinfachter Ansatz.<br />
<br />
Einschalten:<br />
<br />
:<math>\begin{align}<br />
P_\mathrm{SW_r}<br />
&= \tfrac14 \cdot U_N \cdot I_N \cdot \frac{t_r}{T} \\<br />
&= \tfrac14 \cdot 70V \cdot 30A \cdot \frac{500ns}{200\mu s}=1{,}3W<br />
\end{align}</math><br />
<br />
Ausschalten:<br />
<br />
:<math>\begin{align}<br />
P_\mathrm{SW_f} <br />
&=\tfrac14 \cdot U_N \cdot I_N \cdot \frac{t_f}{T}\\<br />
&=\tfrac14 \cdot 70V \cdot 30A \cdot \frac{800ns}{200\mu s}=2{,}1W<br />
\end{align}</math><br />
<br />
Alternativ und genauer kann man rechnen, wenn die Ein- Ausschaltenergie im Datenblatt angegeben ist. Aber Achtung! Die Randbedingungen unter denen die genannte Energie ermittelt wurde, müssen genau so zutreffen.<br />
:<math>\begin{align}<br />
P_{SW_f} = f_{schalt} \cdot E_{ON}<br />
\end{align}</math><br />
:<math>\begin{align}<br />
P_{SW_r} = f_{schalt} \cdot E_{OFF}<br />
\end{align}</math><br />
<br />
Die Gesamtverlustleistung beträgt also in etwa 15W.<br />
<br />
Damit muß ein entsprechender [[Kühlkörper]] ausgelegt und die Chiptemperatur berechnet werden. z.&nbsp;B.:<br />
* Kühlkörper mit einem R_th von 0,2K/W<br />
* max. Umgebungstemperatur +60°C<br />
* R_th "junction-case" des FETs 0,8K/W<br />
* R_th der Wärmeleitfolie zwischen FET und Kühlkörper ca. 2,0K/W<br />
* R_th gesamt: 3,0K/W <br><br />
* Bei einer Verlustleistung von 18W und einer Umgebungstemperatur von 60°C hat der Chip eine Temperatur von ca. 18W * 3,0K/W +60°C = 114°C. ==> o.k.!<br />
<br />
Unter Berücksichtigung der Tatsache, daß hier viele Vereinfachungen vorgenommen, und die Art der Last nicht beachtet wurde ist es sinnvoll, einen gewissen Sicherheitsabstand zu den zulässigen Maximalwerten einzuhalten. Daher ist es empfehlenswert, die Chiptemperatur auf ca. 125°C zu beschränken. <br />
<br />
Des Weiteren ist hier die parasitäre Diode im FET nicht berücksichtigt.<br />
Wenn während der "off" Zeit ein Strom über die Diode fließt (Reverse recovery current oder Freilaufstrom), muß die dadurch '''zusätzlich''' entstehende Verlustleistung in die obige Berechnung der maximalen Chiptemperatur mit einfließen.<br />
<br />
==Treiberleistung==<br />
<br />
Auch wenn der MOSFET ein spannungsgesteuertes Bauelement ist, muss trotzdem bei jedem Einschalten und bei jedem Ausschalten die Gatekapazität umgeladen werden. Bei älteren Leistungs-FET - oder bei einem schlechten Design (!) - muss sogar teilweise mit negativer Spannung am Gate gearbeitet werden, um eine vollständige Sperrung zu erreichen.<br />
Diese Umladung muss möglichst schnell erfolgen, um die Verluste im FET während der Umschaltphase zu minimieren. Dazu findet ein [[Mosfet-Übersicht#MOSFET-Treiber|MOSFET-Treiber]] Verwendung. Hier eine detaillierte Beschreibung zum [[Treiber]].<br />
<br />
Da die Gatekapazität nicht direkt im Datenblatt enthalten ist kann man sich mit der Eingangskapazität Ciss behelfen. Im Arbeitspunkt ist die Gatekapazität ungefähr 5x größer als der im Datenblatt für Ciss angegebene Wert. <br />
Daher berechnet sich die Treiberleistung wie folgt: <br />
<br />
:<math>P_\text{Treiber} = C \cdot U^2 \cdot f = 5 \cdot C_\text{íss} \cdot U_\text{Gate}^2 \cdot f_\text{schalt}</math><br />
<br />
1.Beispiel, kleine MOSFET-Steuerung mit niedriger Leistung und Frequenz.<br />
<br />
:<math>P_\text{treiber} = 5 \cdot 4{,}8\,\text{nF} \cdot 15\,\text{V}^2 \cdot 10\,\text{kHz} = 54\,\text{mW}</math><br />
<br />
2.Beispiel, sehr große MOSFET-Steuerung für Induktionsheizung mit sehr hoher Leistung und Frequenz.<br />
<br />
:<math>P_\text{treiber} = 5 \cdot 24\,\text{nF} \cdot 15\,\text{V}^2 \cdot 250\,\text{kHz} = 6{,}75\,\text{W}</math><br />
<br />
Aber Achtung, so ein MOSFET-Treiber hat auch einen Eigenverbrauch, der leicht zwischen 0,5 und 1 W liegen kann.<br />
<br />
Bei niedrigen PWM-Frequenzen kann man Logic Level MOSFETs auch direkt per CMOS-Ausgang ansteuern, z.B. mit einem [[AVR]], wie in diesem [http://www.mikrocontroller.net/topic/246449#2519459 Forumsbeitrag] zu sehen ist.<br />
<br />
== Low- und High-Side ==<br />
<br />
Definition LS- und HS:<br />
<br />
;Low-Side Schalter: Der FET schaltet eine Last gegen GND - auch als LS-Schalter bezeichnet.<br />
;High-Side Schalter: Der FET schaltet eine Last an die Versorgungsspannung – auch als HS-Schalter bezeichnet.<br />
<br />
Anregungen oder Fragen auch gerne per Email an [http://www.mikrocontroller.net/user/show/powerfreak Powerfreak]. Dieser Artikel kann dadurch regelmäßig erweitert und ggf. durch ein FAQ ergänzt werden.<br />
<br />
<br />
== SOA Diagramm ==<br />
<br />
SOA-Diagramm (engl. '''S'''afe '''O'''perating '''A'''rea, sicherer Arbeitsbereich) beschreibt die zulässige Verlustleistung eines Transistors in Anhängigkeit des Drainstroms (I_D), der Drain-Source Spannung (U_DS) und der Pulsbreite. Als Beispiel sei hier der BUZ 11 genannt. Im nachfolgenden Diagramm ist das SOA-Diagramm dargestellt. Wie ist es zu verstehen? Zunächst gibt es eine Grenze auf der linken Seite, die schräge, dunkelblaue Line. Diese wird durch den minimalen R_DS_ON festgelegt, hier wirkt der MOSFET wie ein ohmscher Widerstand. Mehr Strom kann bei einer bestimmten Spannung nicht fließen. Die zweite Grenzlinie ist ganz rechts die pinkfarbene Linie, sie stellt die maximale Sperrspannung des MOSFET dar. Die dritte Grenze ist der maximal zulässige Drainstrom, hier im Beispiel 120A, dargestellt durch die gelbe Linie. Die maximale Spannung zwischen Drain und Source sowie der Drainstrom sind abhängig von der Pulsbreite, mit welcher der MOSFET betrieben wird. Bei nur 2,5µs Pulsbreite (Rechteckimpuls) müssen die beiden Parameter sich innerhalb der Fläche bewegen, welche durch die dunkelblaue, gelbe und die pinkfarbene Line begrenzt wird. Im Extremfall dürfen 50V anliegen und 120A fließen, das sind satte 6kW Pulsleistung! Werden die Pulse breiter, so sinken die zulässigen Ströme und Spannungen, bei 1ms (dunkelblaue Linie bis zur braunen Linie, dann zur pinkfarbenen Linie) sind maximal noch 50V und 7A zulässig, also nur noch 350W. Die letzte Linie stellt den Fall für Gleichstrom (engl. '''D'''irect '''C'''urrent), also Dauerbelastung dar, hier sind bei 50V maximal 1,5A zulässig, was einer Dauerverlustleistung von 75W entspricht. MOSFETs, welche nur für Schaltbetrieb und nicht für [[#Linearbetrieb von MOSFETs | Linearbetrieb]] geeignet sind, haben keine Kennlinie für DC. Im normalen Schaltbetrieb liegt der Arbeitspunkt auf der linken Grenzlinie R_DS_ON_MIN. Nur im Linearbetrieb liegt der Arbeitspunkt innerhalb der Fläche, welche durch die Außenlinien begrenzt wird.<br />
<br />
[[bild: SOA-BUZ11.png | thumb | 300px| SOA-Diagramm]]<br />
<br />
Bei der Anwendung des Diagramms gilt es einiges zu beachten. Die Pulsleistungen sind nur zulässig, wenn der MOSFET vorher kalt ist, sprich ca. 25°C Sperrschichttemperatur hat. War er vorher schon heiß, reduziert sich die zulässige Belastung deutlich. Ebenso dürfen die Pulse nicht zu schnell wiederholt werden, denn dann ist der MOSFET noch vom vorherigen Puls aufgeheizt. Im Fall von DC sind 75W Verlustleistung auch eher ein theoretischer Wert, welcher real nur schwer erreicht werden kann, wenn der MOSFET auf einem sehr großen [[Kühlkörper]] optimal montiert ist. Praktisch liegen die erreichbaren Werte eher bei der Hälfte.<br />
<br />
(Anm. Eigentlich müsste für die R_DS_ON Grenzlinie R = U / I der minimale R_DS_ON rauskommen, hier ~40mOhm, es kommen aber ~80mOhm raus. Die Ursache dafür ist unklar, möglicherweise liegt hier ein Sicherheitsfaktor zu grunde).<br />
<br />
{{Clear}}<br />
<br />
== Linearbetrieb von MOSFETs ==<br />
<br />
Der Großteil der Anwendungen nutzt MOSFETs als Schalter, d.h. der MOSFET ist entweder voll gesperrt oder voll durchgesteuert. Dafür gelten auch all die Hinweise in diesem Artikel. In bestimmten Anwendungen werden MOSFETs aber auch im Linearbetrieb eingesetzt, z.B in linearen Endstufen für Audio, Video, elektronischen Lasten und Stromquellen. Hier muss man einiges beachten. Ein verbreiteter Irrtum besteht darin zu glauben, MOSFETs könne man im Linearbetrieb einfach parallel schalten, weil der positive Temperaturkoeffizient von <math>R_{DS(ON)}</math> eine Symmetrierung bewirkt, ähnlich den Emitterwiderständen bei parallelgeschalteten Bipolartransistoren. Das ist ''ausschließlich'' im Schaltbetrieb möglich, und daher falsch! Im Linearbetrieb spielt der Temperaturkoeffizient von <math>R_{DS(ON)}</math> keine Rolle, weil der MOSFET selten bis nie komplett durchgesteuert ist. Eben darum ist beim Linearbetrieb der minimale <math>R_{DS(ON)}</math> in den meisten Fällen unwichtig und man kann auch eher hochohmige, ältere MOSFETs verwenden, wie z.B. den BUZ11.<br />
<br />
Hier wirkt vielmehr der negative Temperaturkoeffizient (TK) der Thresholdspannung <math>U_{GS(thr)}</math>, vergleichbar dem negativen TK der Basis-Emitter-Spannung von Bipolartransistoren. D.h. mit steigender Temperatur und konstanter Gate-Source-Spannung steigt der Stromfluss der Drain-Source Strecke. In einer Parallelschaltung von MOSFETs würde dies bedeuten, dass der MOSFET mit dem geringfügig größeren Drainstrom (Fertigungstoleranzen) wärmer wird, was zu einem weiter steigenden Drainstrom und damit noch mehr Wärme führt. Damit ist die Schaltung thermisch instabil und würde zum Durchbrennen der MOSFETs führen, einer nach dem Anderen. <br />
<br />
Um das zu verhindern muss man relativ große Ausgleichswiderstände in die Source-Leitung der einzelnen MOSFETs schalten, um diese Drift zu kompensieren. Dadurch verschlechtert sich natürlich der Wirkungsgrad des Verstärkers. MOSFETs haben einen TK von typisch -5mV/K für <math>U_{GS(thr)}</math>, das ist mehr als das doppelte von Bipolartransistoren mit typisch -2mV/K, weshalb die Symmetrierungswiderstände mehr als doppelt so groß sein müssen. Weiterhin muss man beachten, dass die Toleranzen von <math>U_{GS(thr)}</math> sehr groß sind, im Bereich von Volt! Das kann man sinnvoll nicht mehr mit Gatewiderständen symmetrieren, hier muss man die MOSFETs ausmessen und Gruppen mit geringen Toleranzen in einer Schaltung verwenden (engl. matching). <br />
<br />
Eine andere Möglichkeit ist die getrennte Ansteuerung der einzelnen MOSFETs, das wird oft in elektronischen Lasten bzw. [[Konstantstromquelle#Konstantstromquelle mit Operationsverstärker und Transistor | Konstantstromquellen]] gemacht. Hier treten keine zusätzlichen Verluste auf und der Mehraufwand in der Ansteuerung ist meist unkritisch.<br />
<br />
Weiterhin muss man beachten, dass viele der heutigen HochleistungsMOSFETs intern eine Parallelschaltung vieler kleiner MOSFET-Zellen (z.B. sogenannte Trench-FET) sind, und somit oft für den Linearbetrieb ungeeignet sind. Denn auch dort können einzelne Zellen überhitzen und durchbrennen (Hot Spot). Ob ein MOSFET für den Linearbetrieb tauglich ist steht manchmal im Datenblatt, oft aber eher nicht, eben weil die meisten MOSFETs als Schalter entwickelt und gebaut sind. Typische Vertreter für Linearbetrieb findet man in der [[MOSFET-Übersicht]]. Ein wichtiges Indiz für Linearbetrieb ist eine Kurve für DC im [[#SOA_Diagramm | SOA-Diagramm]]. Meist geht es dort nur bis 10ms, DC fehlt, eben weil DC (engl. '''D'''irect '''C'''urrent = Gleichstrom = Linearbetrieb) nicht zulässig ist. Manchmal hat der Hersteller auch "vergessen", die Kennlinie für DC mit reinzuschreiben, wie z.B. bei [http://www.irf.com/product-info/hi-rel/alerts/fv5-p-09-01-A.pdf IRF], wie in diesem [http://www.mikrocontroller.net/topic/291760#3106758 Beitrag] zu erfahren ist.<br />
Ein recht gutes Indiz dafür, ob ein FET für den Linearbetrieb taugt, ist die Vorwärtssteilheit. Diese kennzeichnet die Abhängigkeit des Drainstromes von der Ansteuerung am Gate als <math>S = \Delta i_d/\Delta u_{gs}</math>. Moderne Trench-FET erreichen heute Steilheiten im dreistelligen Bereich und sind für Linearanwendungen völlig unbrauchbar. Zum Vergleich: Der BUZ11 kommt mit gerade einmal 4 bis 5 Siemens daher.<br />
<br />
In diesem Beitrag wird die DC-Linie im SOA-Diagramm noch genauer erklärt: [http://www.mikrocontroller.net/topic/319961#3473567 Re: MOSFET Linearbetrieb möglich?]<br />
<br />
<br />
== Siehe auch ==<br />
<br />
* [[Leistungselektronik]]<br />
* [[Mosfet-Übersicht]]<br />
* [[IGBT]]<br />
* [[TRIAC]]<br />
* [[Kühlkörper]] <br />
* [[Zwischenkreiskapazität]]<br />
* [[Treiber]]<br />
* [[Snippets#Wie_schlie.C3.9Fe_ich_einen_MOSFET_an_einen_Mikrocontroller_an.3F|Wie schließe ich einen Mosfet an einen Mikrocontroller an?]]<br />
* [http://www.mikrocontroller.net/articles/H-Br%C3%BCcken_%C3%9Cbersicht Übersicht H-Brücken]<br />
* [http://www.mikrocontroller.net/topic/168218#1609684 Forumsbeitrag]: MOSFETs im Linearbetrieb<br />
* [http://www.mikrocontroller.net/topic/186785#new Forumsbeitrag]: nochmal MOSFETs im Linearbetrieb<br />
* [http://www.mikrocontroller.net/topic/319961#3473567 Forumsbeitrag]: sehr ausführlicher Forumsbeitrag über MOSFETs im Linearbetrieb. Berücksichtigt auch den Spirito-Effekt.<br />
* [http://www.mikrocontroller.net/topic/143324#new Forumsbeitrag]: Über eine elektronische Last, sehr lang<br />
*[http://www.mikrocontroller.net/topic/246449#2519459 Forumsbeitrag]: Logic Level MOSFETs direkt mit einem [[AVR]] treiben.<br />
* [http://www.mikrocontroller.net/topic/267254#2787855 Forumsbeitrag]: MOSFETs im Linearbetrieb, Laborerfahrungen<br />
* [http://www.mikrocontroller.net/topic/267254#2787945 Forumsbeitrag]: MOSFETs für Linearbetrieb<br />
* [https://www.mikrocontroller.net/topic/269642?goto=2820617#2820617 Forumsbeitrag]: Verpol- und Überspannungsschutz mit MOSFETs<br />
* [https://www.mikrocontroller.net/topic/425414#4981611 Forumsbeitrag]: Linearbetrieb von MOSFETs<br />
<br />
== Weblinks ==<br />
<br />
* [http://www.elektronikinfo.de/strom/feldeffekttransistoren.htm Feldeffekttransistoren bei elektronikinfo.de]<br />
* [http://www.elektronik-kompendium.de/sites/bau/0207011.htm FET im ELKO]<br />
* [http://www.elektronik-kompendium.de/sites/bau/0510161.htm MOSFET im ELKO]<br />
* [http://www.sprut.de/electronic/switch/nkanal/nkanal.html MOSFET bei sprut.de]<br />
* [http://sound.westhost.com/articles/hexfet.htm#51 MOSFETs in Audioendstufen, engl.]<br />
* [http://irf.custhelp.com/cgi-bin/irf.cfg/php/enduser/std_adp.php?p_faqid=214&p_created=1019728945&p_sid=pt9ITiCj&p_accessibility=0&p_redirect=&p_lva=&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9MTQsMTQmcF9wcm9kcz0mcF9jYXRzPSZwX3B2PSZwX2N2PSZwX3BhZ2U9MSZwX3NlYXJjaF90ZXh0PWxpbmVhcg**&p_li=&p_topview=1 FAQ Answer ID 214 bei IRF zum Linearbetrieb]<br />
* [http://www.nxp.com/documents/application_note/AN11158.pdf AN11158 - Understanding power MOSFET data sheet parameters] von NXP (PDF)<br />
* [https://assets.nexperia.com/documents/technical-note/TN00008.pdf TN00008 - Power MOSFET frequently asked questions and answers] von nexperia (PDF)<br />
* [http://www.infineon.com/dgdl/Infineon+-+Application+Note+-+PowerMOSFETs+-+OptiMOS%E2%84%A2+-+Linear+Mode+Operation+and+SOA+Power+MOSFETs.pdf?fileId=db3a30433e30e4bf013e3646e9381200 AN: Linear Mode Operation andSafe Operating Diagram of Power-MOSFETs] von Infineon (PDF)<br />
* [http://www.ixys.com/Documents/Articles/Article_Linear_Power_MOSFETs.pdf MOSFETs Withstand Stress of Linear-Mode Operation] Neuentwickelte MOSFETs für Linearbetrieb (PDF)<br />
<br />
[[Kategorie:Bauteile]] [[Kategorie:Leistungselektronik]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=FET&diff=107025FET2024-07-19T16:31:47Z<p>Heha: /* FET-Typen */</p>
<hr />
<div>Dieser Artikel versteht sich als Unterpunkt zum Artikel [[Leistungselektronik]]<br />
<br />
<br />
Ein FET (engl. '''F'''ield '''E'''ffect '''T'''ransistor) ist ein Feldeffekttransistor. Der FET ist ein Bauelement, das im Gegensatz zum Bipolartransistor (engl. '''B'''ipolar '''J'''unction '''T'''ransistor, BJT) mit Spannung und nicht mit Strom gesteuert wird. Unterschieden werden<br />
* MOSFET = engl. '''M'''etall '''O'''xide '''S'''emiconductor '''F'''ield '''E'''ffect '''T'''ransistor; Metalloxidschicht-FET, größte Teilgruppe der FETs mit isoliertem Gate <br />
* JFET = engl. '''J'''unction '''F'''ield '''E'''ffect '''T'''ransistor, Übergangszonen FET, der steuerbare Kanal wird durch einen PN-Übergang wie in einer Diode gebildet<br />
<br />
Die drei Anschlüsse eines FETs werden ''Gate'', ''Drain'' und ''Source'' genannt. Unter Umständen ist ein vierter Anschluß vorhanden, der ''Bulk'' genannt wird. Normalerweise ist Bulk intern mit Source verbunden. Wenn dies nicht der Fall ist, muss diese Verbindung durch den Designer in der Schaltung hergestellt werden.<br />
<br />
== FET-Typen ==<br />
<br />
FETs werden hauptsächlich unterschieden in N-Kanal und P-Kanal, sowie "selbst sperrend = Anreicherungstyp" (engl. enhancement type) und "selbst leitend = Verarmungstyp" (engl. depletion type). Beim selbstleitenden FET ist der Transistor bei 0V Gate-Source Spannung maximal leitend (durchgesteuert) und wird durch Anlegen einer Spannung ans Gate gesperrt. Beim selbstsperrenden FET (größte Gruppe) ist der Transistor bei 0V Gate-Source Spannung gesperrt und wird durch Anlegen einer Spannung ans Gate leitend. Ist die Linie zwischen Drain und Source durchgezogen handelt es sich um einen selbstleitenden, bei einer gestrichelten Linie um einen selbstsperrenden FET. JFETs gibt es nur als Verarmungstyp.<br />
<br />
Im weiteren Artikel wird nur der '''selbstsperrende''' MOSFET betrachtet, weil nur dieser einen althergebrachten Bipolartransistor „ersetzen“ kann.<br />
<br />
{| class="wikitable"<br />
|+ '''Typen von Feldeffekttransistoren<br/>&nbsp;'''<br />
|-<br />
! style="width:10em" | Typ <br />
! N-Kanal <br />
! P-Kanal<br />
|- valign="top"<br />
| JFET<br/>SFET<br/>(selbst leitend) || [[bild:JFET-N.png|center]]<br />
* drittgrößte Gruppe<br />
* bislang nur für kleine Leistungen verfügbar<br />
* JFETs mit hoher Leistung sind im Kommen<br />
* Eingangsstufen von OPVs<br />
* Eingangsstufen von HF-Verstärkern bis in den GHz-Bereich<br />
** Typen mit zwei Gates zum Regeln und Mischen üblich<br />
* als einfache [[Konstantstromquelle]] geeignet<br />
| [[bild:JFET-P.png|center]]<br />
* selten<br />
* ersatzhalber für „fehlenden“ P-Kanal-Verarmungs-MOSFET<br />
* Ältester Vertreter der Unipolartransistoren<br />
|- valign="top"<br />
| MOSFET<br/>Anreicherungstyp<br/>(selbst sperrend)<br/>''Enhancement Mode'' || [[bild:MOS-EN.png|center]]<br />
* Mit Abstand größte Gruppe; wenn nicht besonders erwähnt ist ''dieser'' gemeint<br />
* sehr viele Typen erhältlich<br />
* Auch als Doppel-MOSFET oder zusammen mit P-Kanal-MOSFET in einem Gehäuse gängig<br />
| [[bild:MOS-EP.png|center]]<br />
* zweitgrößte Gruppe<br />
* bei gleicher Geometrie etwas schlechter als ein N-Kanal Typ<br />
* Auch als Doppel-MOSFET oder zusammen mit N-Kanal-MOSFET in einem Gehäuse gängig<br />
|- valign="top"<br />
| MOSFET<br/>Verarmungstyp<br/>(selbst leitend)<br/>''Depletion Mode'' || [[bild:MOS-DN.png|center]]<br />
* selten aber käuflich<br />
* Sinnvolle Anwendungen ergeben sich vor allem in Reihenschaltungen<br />
| [[bild:MOS-DP.png|center]]<br />
* Nicht in freier Wildbahn gesichtet<br />
|}<br />
<br />
=== Vorteile des FET ===<br />
<br />
* Niedrigere Verluste als bei Bipolartransistoren.<br />
* Sehr schnelles Schalten möglich, daher für sehr hohe Frequenzen geeignet (keine Speicherzeit wie beim BJT).<br />
* Einfaches Parallelschalten im Schaltbetrieb, da Unterschiede im <math>R_{DS,on}</math> durch den positiven Temperaturkoeffizienten ausgeglichen werden.<br />
* Leistungslose Ansteuerung im statischen Fall, jedoch hohe Umladeverluste am Gate!<br />
* oft preiswerter als vergleichbare Bipolartransistoren (engl. '''B'''ipolar '''J'''unction '''T'''ransistor, BJT)<br />
* Relativ unempfindlich gegen Überspannung zwischen Drain und Source. Bei Überschreitung der Maximalspannung zwischen Drain und Source findet ein sogenannter "Durchbruch" statt. Dies ist vergleichbar mit dem Zener-Effekt. Ist die Energiemenge begrenzt, ist dieser Durchbruch reversibel und der FET wird NICHT zerstört. Beim Bipolartransistor ist die dafür zulässige Energiemenge viel kleiner, weil die den Strom durchquerende Fläche zu Hotspots neigt.<br />
<br />
=== Nachteile des FET ===<br />
<br />
* Nur bedingt für hohe Spannungen [[Transistor#Wann setzt man einen MOSFET, Bipolartransistor, IGBT oder Thyristor ein ? |geeignet]], die ON-Verluste sind ab ca. 250V höher als bei einem [[IGBT]]. <br />
* Parasitäre Diode parallel zur Drain-Source Strecke ist immer enthalten, das (Ab-)Schaltverhalten dieser Dioden ist meist schlechter als separate Dioden, was häufig zu unerwünschten Schwingungen führt.<br />
* Empfindlicher gegen ESD am Gate als BJT<br />
* Positiver Temperaturkoeffizient (TK), der <math>R_{DS,on}</math> ist stark temperaturabhängig und steigt von 25°C (Datenblattangabe) auf 150°C ungefähr um den Faktor 2. Dadurch steigen auch die Verluste und damit die Erwärmung des Bauteiles.<br />
<br />
=== Erklärung der wichtigsten Datenblattwerte ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! style="width:12em" | '''Parameter'''<br />
! style="width:7em" | '''Symbol'''<br />
! style="width:6em" | Beispiel<br />
! '''Erklärung'''<br />
|-<br />
| Drain Source Voltage <br>(Breakdown) || V(BR)_DSS <br> V_DS || 75 V || Maximale Spannungsfestigkeit des Bauteiles zwischen Drain und Source<br />
|-<br />
| Continuous Drain Current || I_D(on) || 55 A @ 125 °C || Maximaler Dauerstrom bei 125°C Gehäusetemperatur <br />
|-<br />
| Pulsed Drain Current || ID_pulse <br> I_CD(on) || 240 A || Maximaler Pulsstrom (Achtung die zulässige Zeitdauer des Pulses kann nur über die maximale Junctiontemperatur ermittelt werden)<br />
|-<br />
| Gate Charge || Q<sub>GS</sub> || 320 nC || Gate-Ladung in Coloumb oder Amperesekunden, die zum Ein- oder Ausschalten des MOSFET erforderlich ist. Dies berücksichtigt die Nichtlinearität der Kapazität und (richtig?) den Miller-Effekt. Mit dieser Angabe wird der für das Schalten von Leistungs-MOSFET benötigte Gatestrom für eine bestimmte Schaltzeit ermittelt. Dieser liegt üblicherweise im einstelligen Ampere-Bereich. Moderne Typen mit extra geringer Gate-Ladung können so schneller schalten.<br />
|-<br />
| Repetetive Avalanche Energy || t_sc || 280 mJ || Maximale Energie, welche beim Avalanche Durchbruch bei Überschreiten der maximalen Drain-Source Spannung im MOSFET bei z.&nbsp;B. 1% Puls/Pausen Verhältnis regelmäßig auftreten darf, ohne den FET zu schädigen<br />
|-<br />
| Drain-Source<br>ON Resistance || R<sub>DS_ON</sub> || 0,01 Ω || Widerstand des eingeschalteten FETs bei '''25°C''', V_GS = 10V und ID = 30A<br />
|-<br />
| Drain-Source<br>ON Resistance || R<sub>DS_on</sub> || 0,021 Ω || Widerstand des eingeschalteten FETs bei '''175°C''', V_GS = 10V und ID = 30A<br />
|-<br />
| Thermal Resistance<br>(junction-case) || R<sub>th_JC</sub> || 0,8 K/W || Thermischer Widerstand im Transistor vom der „Sperrschicht“ (junction eines Bipolartransistors, ja altmodischer Index, hier besser „Kanal“) bis zur Rückseite oder bestmöglichen Kühlmöglichkeit des Transistorgehäuses (case)<br />
|-<br />
| Gate-Source<br>Threshold Voltage || V_GS(th) || 2,0-4,5 V || Gatespannung, ab welcher der Transistor minimal leitend wird (I_D typisch 100-200µA), große Toleranz, typisch 1:2 zwischen Minimum und Maximum<br />
|-<br />
| Turn-on Delay || t_d(on) || 40 ns || Verzögerung zwischen dem Einschalten am Gate bis zur Reaktion im Drainstrom<br />
|-<br />
| Rise Time || t_r || 200 ns || Anstiegszeit des Transistorstromes am Drain<br />
|-<br />
| Turn-off Delay || t_d(off) || 120 ns || Verzögerung zwischen Abschalten am Gate bis zur Reaktion im Drainstrom<br />
|-<br />
| Fall Time || t_f || 60 ns || Abfallzeit des Transistorstromes am Drain <br />
|}<br />
<br />
Die oben genannten Zeiten gelten ausschließlich unter den angegebenen Messbedingungen (Gatewiderstand, Treiberspannung, sowie einer '''FET-Teperatur von 25°C!''') und müssen für die eigene Anwendung ggf. neu berechnet werden. Meist wird man sie eher messen, weil die Rechung zu aufwändig und bisweilen unmöglich ist. <br />
<br />
==== Gate-Source Threshold Voltage ====<br />
Gerade bei der '''Gate-Source Threshold Voltage <math>V_{GS}(th)</math>''' gibt es hier immer wieder Verwirrung. Sie gibt an, ab welcher Spannung der MOSFET anfängt, minimal leitfähig zu werden. Diese Spannung ist technologisch bedingt auch heute noch einer starken Toleranz unterworfen, typischerweise hat der Bereich bei dem der FET zu leiten beginnt eine Spreizung von etwa 1:2 zwischen Minimum und Maximum. Welche Spannung man nun wirklich anlegen muss, um den gewünschten <math>R_{DS}(on)</math> zu erreichen kann der Tabelle im jeweiligen Datenblatt entnommen werden. Dabei unbedingt die angegebene Gatespannung beachten, nur dieser Wert ist garantiert!.<br />
<br />
[[bild: IRLZ34N_R_DS_ON.png | thumb | 800px | R_DS_ON im Datenblatt des IRLZ34N]]<br />
{{Clear}}<br />
<br />
Die Kurvenschar von <math>I_D</math> über <math>U_{DS}</math> in Abhängigkeit von <math>U_{GS}</math> stellt immer nur typische Werte dar, keine garantierten Extremwerte (engl. worst case). Als Standardwerte kann man 10-15V für einen Standardtypen und ca. 3-5V für einen Logic Level MOSFET (LL-FET) ansetzen. Kleinsignal-FETs leiten schon ab ca 1V. Bei Ansteuerung mit 5V benötigt man also einen Typen, der '''sicher''' bei 5V voll durchgesteuert ist, z.B. IRLZ34N. Bei 3,3V ist er bereits nicht mehr zuverlässig nutzbar. Es gibt auch Typen mit noch geringerer Spannung für Vollaussteuerung. Wer einen BUZ11 (<math>V_{GS}(th)</math> 4V max.) mit 5V ansteuert riskiert ein Abfackeln des MOSFETs, denn je nach Toleranz kann er bereit ganz gut aufgesteuert sein oder auch nicht. Das soll in den nachfolgenden Diagrammen dargestellt werden. Zunächst die Transferkennlinie. Sie gibt an, wieviel Drainstrom in Abhängigkeit der Gatespannung fließen kann, wobei die Drainspannung konstant ist, hier im Beispiel 25V. Ein typischer BUZ11 (mittlere, schwarze Kurve) fängt bei 3V zu leiten an und erreicht bei 6V am Gate ca. 17A. Erwischt man nun ein kritisches Exemplar, das erst bei 4V zu leiten anfängt (rechte, rote Kurve um 1V parallel verschoben), so kann dieser bei 6V nur 8A leiten, für 17A braucht er 7V. Der günstige Fall, daß der BUZ11 schon bei 2V anfängt zu leiten sieht man in der linken, roten Kurve.<br />
<br />
[[bild: BUZ11_UGS_ID.png | thumb | 800px | Transferkennlinie des BUZ11]]<br />
{{Clear}}<br />
<br />
Wenn man die drei Fälle (min, typ, max) mit 5V ansteuert, erhält man die Arbeitspunkte 1-3 mit einem maximal schaltbaren Drainstrom von 2,5, 8 und 17A. Diese kann man in das Ausgangskennlinienfeld übertragen. Wir nehmen max. 1V U_DS an. Es ergeben sie die gleichen Ströme. Der maximale Drainstrom weicht um -5,5/+9A vom typischen Fall ab. Erhöht man nun die Gate-Source Spannung auf 10V (Arbeitspunkt 4), schwankt der maximal schaltbare Drainstrom nur noch um -2/+2A, außerdem liegt er mit 30A deutlich höher. Der BUZ11 ist somit sicher durchgesteuert.<br />
<br />
[[bild: BUZ11_UDS_ID_UGS.png | thumb | 800px | Ausgangskennlinie des BUZ11]]<br />
{{Clear}}<br />
<br />
==== Parasitäre Diode ====<br />
<br />
Der Schwerpunkt in der FET-Entwicklung liegt auf den geringst-möglichen <math>R_{DS}(on)</math>, die Diode entsteht auf Grund des Herstellungsprozesses, und wird nur nachrangig verbessert, da viele Optimierungsversuche auch einen Einfluss auf wichtige Kennwerte des FETs hatten und haben.<br />
Daher muss sorgfältig geprüft werden, ob die Schaltgeschwindigkeit, die Recovery-Time und die damit verbundenen Verluste sowie die dabei erzeugte unerwünschte EMV-Abstahlung tolerierbar ist, oder nicht.<br />
Hier hilft es oft eine optimierte Diode / Schottky-Diode zum FET parallel zu schalten. Ganz ausblenden läßt sich die parasitäre Diode jedoch nicht, jedoch kann man den Anteil des Stromes beeinflussen, der über die intere Diode fliest.<br />
<br />
{| class="wikitable"<br />
|+ ''' Parasitäre Diode des FETs '''<br />
|-<br />
! style="width:10em" | '''Parameter'''<br />
! style="width:6em" | '''Symbol'''<br />
! style="width:6em" | '''Beispiel'''<br />
! '''Erklärung'''<br />
|-<br />
| Continuous Current || I_S || 75A || Maximaler Dauerstrom der parasitären Diode, meist identisch zum maximalen Dauerstrom des MOSFETs<br />
|-<br />
| Forward Voltage || V_SD || 1,3V || Spannungsfall an der parasitären Diode <br />
|-<br />
| Reverse Recovery Time || t_rr || 120ns || Zeit, welche die Elektronen brauchen um aus der leitenden Diode vollständig abzufließen. Während dieser Zeit fließt der Strom in '''Rückwärtsrichtung''' durch die Diode und erzeugt relativ viel Verlustleistung. <br />
|-<br />
| Reverse Recovery Charge || Q_rr || 60nC || Ladungsmenge, die während t_rr rückwärts durch die Diode fließt. <br />
|}<br />
<br />
== Haupttypen und Gatespannungslevel ==<br />
<br />
===Unterschied N-Kanal / P-Kanal FET===<br />
<br />
Im Schaltsymbol werden die MOSFET-Typen meist durch die Pfeilrichtung in der Mitte des Symbols (eigentlich "Bulk") vom oder zum Gate unterschieden. Zeigt der Pfeil zum Gate hin, handelt es sich um einen N-Kanal-FET, zeigt der Pfeil vom Gate weg um einen P-Kanal FET.<br />
<br />
Der große Vorteil des N-Kanal FETs (Elektronenleitung) ist, daß er immer niederohmiger ist, als ein gleich großer P-Kanal FET (Löcherleitung). Daher sind P-Kanal Typen bei vergleichbaren Werten auch immer größer = teuerer da weniger Chips auf einem Wafer Platz haben.<br />
<br />
Beim N-Kanal FET muss die Gatespannung positiv gegenüber Source sein. Dabei wird der FET dann leitend, wenn die sogenannte "threshold voltage" (Schwellenspannung) erreicht wird. Eine typische Anwendung ist z.&nbsp;B. ein '''Low-Side Schalter''': Source an GND, Drain an die Last, Ansteuerung des N-Kanal FETs mit 12V gleichbedeutend mit 12V ÜBER den Source = GND Potential.<br />
<br />
Beim P-Kanal FET als HS-Schalter muss die Gatespannung negativer=niedriger als das Sourcepotential sein.Beispiel.<br />
Beispiel: <br />
Lastspannung = 400V d.h. Source an 400V, Last zwischen Drain und GND, Ansteuerung des P-Kanal FETs mit 388V, also 12V UNTER dem Sourcepotential.<br />
<br />
Beim N-Kanal FET als HS-Schalter muss die Gatespannung positver=höher als das Sourcepotential sein.<br />
Beispiel:<br />
Lastspannung = 400V d.h. Drain an 400V, die Last zwischen Source und GND, Ansteuerung des N-Kanal FETs mit 412V, also 12V ÜBER dem Sourcepotential.<br />
In diesem Fall ist aber eine zusätzliche Spannungsquelle erforderlich, denn der FET wird mit einer Spannung über der Lastspannung eingeschaltet. <br />
<br />
'''Weblinks'''<br />
* [https://www.eetimes.com/a-primer-on-high-side-fet-load-switches-part-1-of-2/?utm_source=eetimes&utm_medium=networksearch A primer on high-side FET load switches (Part 1 of 2)], Qi Deng, Senior Product Marketing Manager, Mixed-Signal Products, Micrel, Inc., 5/3/2007 4:14 PM EDT, www.eetimes.com<br />
* [https://www.eetimes.com/a-primer-on-high-side-fet-load-switches-part-2-of-2/ A primer on high-side FET load switches (Part 2 of 2)], Qi Deng, Senior Product Marketing Manager, Mixed-Signal Products. Micrel, Inc., 5/7/2007 1:36 PM EDT, www.eetimes.com<br />
* [http://www.vishay.com/docs/70611/70611.pdf AN804 P-Channel MOSFETs, the Best Choice for High-Side Switching (PDF)] von Vishay Siliconix<br />
<br />
===Unterschied Logic-Level / "Normal"-Level===<br />
<br />
Den meisten FETs ist gemein, daß sie mit einer Spannung von 10..15V angesteuert werden müssen, um den minimalen Einschaltwiderstand zu erreichen. Diese FETs lassen sich nicht ohne weiteres mit einem CMOS-Pegel von 5V ansteuern. Es gibt jedoch für diesen Anwendungsfall sogenannte "Logic Level" (LL) FETs, die schon bei einer Gatespannung von etwa 4,5V voll durchgesteuert sind. Einige Kleinsignal-FETs sind schon ab ca. 1,2V voll durchgesteuert.<br />
<br />
== Beispiel zur Bauteiledimensionierung ==<br />
<br />
=== Spannungsfestigkeit ===<br />
<br />
Die höchste vorkommende Betriebsspannung + Abschaltüberspannung soll kleiner als ca. 80% der Spannungsfestigkeit des Bauteiles sein. <br />
<br />
Achtung: Zwischen dem je nach Anwendungsfall erforderlichen Pufferkondensator und dem FET wird es immer eine parasitäre Induktivität geben.<br />
Abhängig von Schaltgeschwindigkeit und Induktivität wird im Schaltmoment eine mehr oder weniger große Übrspannungsspitze produziert. Dieser Peak<br />
addiert sich auf die aktuelle Versorgungsspannung.<br />
<br />
Überschlagsrechnung als Beispiel:<br />
* Schaltgeschwindigkeit: dI/dt = -100A/µs (= Abschalten von 5A innerhalb 50ns),<br />
* Induktivität: L = 1µH (~ 1 m loses, ungebündeltes Kabel)<br />
* dU=-L*dI/dt = -1µH * (-100A / 1µs) = 100V<br />
<br />
Dies bedeutet, daß an der "Induktivität" zwischen Transistor und Kondensator - Aufgrund von Selbstinduktion im Schaltmoment - ein Überspannungspuls von ca. 100V entsteht, der auf die Betriebsspannung aufzuschlagen ist, also lieber die Leitung kürzer machen, und - sofern möglich - nicht ganz so schnell schalten.<br />
<br />
=== Stromtragfähigkeit ===<br />
<br />
In jedem Datenblatt ist eine Stromtragfähigkeit bei 25°C, und meist noch bei einer höheren Temperatur z.B. 125°C, 150°C oder 175°C Kühlfahnentemperatur angegeben. Dieser Wert ist als ERSTE Entscheidungsgrundlage ausreichend, aber aus der theoretisch abführbaren Verlustleistung errechnet, und<br />
* dient zum qualitativen Vergleich von Transistoren bezüglich ihres R_ds(on) und ihres Wärmewiderstands.<br />
* ist für die Dimensionierung einer Schaltung nur als Richtwert zu interpretieren. <br />
* ist ohne Schaltverluste genannt, und daher nur für einen Schaltbetrieb von wenigen Hz gültig. Außerdem wird ein annähernd idealer Kühlkörper unterstellt, der trotz der Verlustleistung das Gehäuse des Transistors auf der angegebenen Temperatur halten kann.<br />
* entbindet einen nicht davon den Kopf einzuschalten... siehe die nachfolgenden Zeilen.<br />
* Liegt der Strom für den die Schaltung entwickelt wird mit ca. 10..20% Abstand unter dem Datenblattwert von 125°C ist dieses Bauteil vermutlich verwendbar (siehe Detailberechnungen unten !). <br />
* Ist der benötigte Strom im Bereich oder größer als der zulässige bei 125°C sollte entweder ein anderer Typ eingesetzt oder mehrere FETs ''des gleichen Typs'' parallelgeschaltet werden.<br />
<br />
== Verlustleistung ==<br />
<br />
Hier wird eine Näherung für eine getaktete Anwendung betrachtet. In einem Transistor treten sowohl beim Ein- und Ausschalten, als auch während der Einschaltphase Verluste im Bauteil auf. Diese Verluste führen zu einer Bauteilerwärmung. Die dabei entstehende Temperatur darf die maximal zulässige Bauteiletemperatur nie überschreiten. Bei den ersten Projekten ist zu empfehlen eine berechnete Chiptemperatur von ca. 125°C nicht zu überschreiten. Fast alle aktuell verfügbaren FETs nennen im Datenblatt eine Temperatur von 175°C als ihre maximale Chiptemperatur.<br />
<br />
{| class="wikitable" style="width:32em" <br />
|+ '''Beispiel'''<br />
|-<br />
! Parameter<br />
! style="width:8em" | Symbol<br />
! style="width:8em" | Wert<br />
|-<br />
| Betriebsspannung || U<sub>N</sub> || 70 V<br />
|-<br />
| Nennstrom || I<sub>N</sub> || 30 A<br />
|-<br />
| Drain-Source Widerstand bei<br>Chiptemperatur: 125°C<br> Gatespannung: 10V || R<sub>DS<sub>on</sub></sub> || 17 mΩ<br />
|-<br />
| Pulsbreite || t<sub>on</sub> || 150 µs<br />
|-<br />
| Schaltfrequenz || ƒ<sub>schalt</sub> || 5 kHz<br>T = 200µs<br />
|-<br />
| Einschaltzeit (risetime) || t<sub>r</sub> || 500 ns<br />
|-<br />
| Ausschaltzeit (falltime) || t<sub>ƒ</sub> || 800 ns <br />
|-<br />
|}<br />
<br />
==== Leitend-Verluste ====<br />
<br />
Während der FET bei [[PWM]]-Ansteuerung eingeschaltet ist, erzeugt er Verlustleistung.<br />
<br />
<math><br />
P_\text{ON}<br />
= {I_\mathrm{N}}^2 \cdot R_\mathrm{DS_\mathrm{ON}} \cdot \frac{t_\mathrm{ON}}{T}<br />
= 30^2A^2 \cdot 17m\Omega \cdot \frac{150\mu s}{200\mu s} = 11{,}5W<br />
</math><br />
<br />
==== Schalt-Verluste ====<br />
<br />
Vereinfachter Ansatz.<br />
<br />
Einschalten:<br />
<br />
:<math>\begin{align}<br />
P_\mathrm{SW_r}<br />
&= \tfrac14 \cdot U_N \cdot I_N \cdot \frac{t_r}{T} \\<br />
&= \tfrac14 \cdot 70V \cdot 30A \cdot \frac{500ns}{200\mu s}=1{,}3W<br />
\end{align}</math><br />
<br />
Ausschalten:<br />
<br />
:<math>\begin{align}<br />
P_\mathrm{SW_f} <br />
&=\tfrac14 \cdot U_N \cdot I_N \cdot \frac{t_f}{T}\\<br />
&=\tfrac14 \cdot 70V \cdot 30A \cdot \frac{800ns}{200\mu s}=2{,}1W<br />
\end{align}</math><br />
<br />
Alternativ und genauer kann man rechnen, wenn die Ein- Ausschaltenergie im Datenblatt angegeben ist. Aber Achtung! Die Randbedingungen unter denen die genannte Energie ermittelt wurde, müssen genau so zutreffen.<br />
:<math>\begin{align}<br />
P_{SW_f} = f_{schalt} \cdot E_{ON}<br />
\end{align}</math><br />
:<math>\begin{align}<br />
P_{SW_r} = f_{schalt} \cdot E_{OFF}<br />
\end{align}</math><br />
<br />
Die Gesamtverlustleistung beträgt also in etwa 15W.<br />
<br />
Damit muß ein entsprechender [[Kühlkörper]] ausgelegt und die Chiptemperatur berechnet werden. z.&nbsp;B.:<br />
* Kühlkörper mit einem R_th von 0,2K/W<br />
* max. Umgebungstemperatur +60°C<br />
* R_th "junction-case" des FETs 0,8K/W<br />
* R_th der Wärmeleitfolie zwischen FET und Kühlkörper ca. 2,0K/W<br />
* R_th gesamt: 3,0K/W <br><br />
* Bei einer Verlustleistung von 18W und einer Umgebungstemperatur von 60°C hat der Chip eine Temperatur von ca. 18W * 3,0K/W +60°C = 114°C. ==> o.k.!<br />
<br />
Unter Berücksichtigung der Tatsache, daß hier viele Vereinfachungen vorgenommen, und die Art der Last nicht beachtet wurde ist es sinnvoll, einen gewissen Sicherheitsabstand zu den zulässigen Maximalwerten einzuhalten. Daher ist es empfehlenswert, die Chiptemperatur auf ca. 125°C zu beschränken. <br />
<br />
Des Weiteren ist hier die parasitäre Diode im FET nicht berücksichtigt.<br />
Wenn während der "off" Zeit ein Strom über die Diode fließt (Reverse recovery current oder Freilaufstrom), muß die dadurch '''zusätzlich''' entstehende Verlustleistung in die obige Berechnung der maximalen Chiptemperatur mit einfließen.<br />
<br />
==Treiberleistung==<br />
<br />
Auch wenn der MOSFET ein spannungsgesteuertes Bauelement ist, muss trotzdem bei jedem Einschalten und bei jedem Ausschalten die Gatekapazität umgeladen werden. Bei älteren Leistungs-FET - oder bei einem schlechten Design (!) - muss sogar teilweise mit negativer Spannung am Gate gearbeitet werden, um eine vollständige Sperrung zu erreichen.<br />
Diese Umladung muss möglichst schnell erfolgen, um die Verluste im FET während der Umschaltphase zu minimieren. Dazu findet ein [[Mosfet-Übersicht#MOSFET-Treiber|MOSFET-Treiber]] Verwendung. Hier eine detaillierte Beschreibung zum [[Treiber]].<br />
<br />
Da die Gatekapazität nicht direkt im Datenblatt enthalten ist kann man sich mit der Eingangskapazität Ciss behelfen. Im Arbeitspunkt ist die Gatekapazität ungefähr 5x größer als der im Datenblatt für Ciss angegebene Wert. <br />
Daher berechnet sich die Treiberleistung wie folgt: <br />
<br />
:<math>P_\text{Treiber} = C \cdot U^2 \cdot f = 5 \cdot C_\text{íss} \cdot U_\text{Gate}^2 \cdot f_\text{schalt}</math><br />
<br />
1.Beispiel, kleine MOSFET-Steuerung mit niedriger Leistung und Frequenz.<br />
<br />
:<math>P_\text{treiber} = 5 \cdot 4{,}8\,\text{nF} \cdot 15\,\text{V}^2 \cdot 10\,\text{kHz} = 54\,\text{mW}</math><br />
<br />
2.Beispiel, sehr große MOSFET-Steuerung für Induktionsheizung mit sehr hoher Leistung und Frequenz.<br />
<br />
:<math>P_\text{treiber} = 5 \cdot 24\,\text{nF} \cdot 15\,\text{V}^2 \cdot 250\,\text{kHz} = 6{,}75\,\text{W}</math><br />
<br />
Aber Achtung, so ein MOSFET-Treiber hat auch einen Eigenverbrauch, der leicht zwischen 0,5 und 1 W liegen kann.<br />
<br />
Bei niedrigen PWM-Frequenzen kann man Logic Level MOSFETs auch direkt per CMOS-Ausgang ansteuern, z.B. mit einem [[AVR]], wie in diesem [http://www.mikrocontroller.net/topic/246449#2519459 Forumsbeitrag] zu sehen ist.<br />
<br />
== Low- und High-Side ==<br />
<br />
Definition LS- und HS:<br />
<br />
;Low-Side Schalter: Der FET schaltet eine Last gegen GND - auch als LS-Schalter bezeichnet.<br />
;High-Side Schalter: Der FET schaltet eine Last an die Versorgungsspannung – auch als HS-Schalter bezeichnet.<br />
<br />
Anregungen oder Fragen auch gerne per Email an [http://www.mikrocontroller.net/user/show/powerfreak Powerfreak]. Dieser Artikel kann dadurch regelmäßig erweitert und ggf. durch ein FAQ ergänzt werden.<br />
<br />
<br />
== SOA Diagramm ==<br />
<br />
SOA-Diagramm (engl. '''S'''afe '''O'''perating '''A'''rea, sicherer Arbeitsbereich) beschreibt die zulässige Verlustleistung eines Transistors in Anhängigkeit des Drainstroms (I_D), der Drain-Source Spannung (U_DS) und der Pulsbreite. Als Beispiel sei hier der BUZ 11 genannt. Im nachfolgenden Diagramm ist das SOA-Diagramm dargestellt. Wie ist es zu verstehen? Zunächst gibt es eine Grenze auf der linken Seite, die schräge, dunkelblaue Line. Diese wird durch den minimalen R_DS_ON festgelegt, hier wirkt der MOSFET wie ein ohmscher Widerstand. Mehr Strom kann bei einer bestimmten Spannung nicht fließen. Die zweite Grenzlinie ist ganz rechts die pinkfarbene Linie, sie stellt die maximale Sperrspannung des MOSFET dar. Die dritte Grenze ist der maximal zulässige Drainstrom, hier im Beispiel 120A, dargestellt durch die gelbe Linie. Die maximale Spannung zwischen Drain und Source sowie der Drainstrom sind abhängig von der Pulsbreite, mit welcher der MOSFET betrieben wird. Bei nur 2,5µs Pulsbreite (Rechteckimpuls) müssen die beiden Parameter sich innerhalb der Fläche bewegen, welche durch die dunkelblaue, gelbe und die pinkfarbene Line begrenzt wird. Im Extremfall dürfen 50V anliegen und 120A fließen, das sind satte 6kW Pulsleistung! Werden die Pulse breiter, so sinken die zulässigen Ströme und Spannungen, bei 1ms (dunkelblaue Linie bis zur braunen Linie, dann zur pinkfarbenen Linie) sind maximal noch 50V und 7A zulässig, also nur noch 350W. Die letzte Linie stellt den Fall für Gleichstrom (engl. '''D'''irect '''C'''urrent), also Dauerbelastung dar, hier sind bei 50V maximal 1,5A zulässig, was einer Dauerverlustleistung von 75W entspricht. MOSFETs, welche nur für Schaltbetrieb und nicht für [[#Linearbetrieb von MOSFETs | Linearbetrieb]] geeignet sind, haben keine Kennlinie für DC. Im normalen Schaltbetrieb liegt der Arbeitspunkt auf der linken Grenzlinie R_DS_ON_MIN. Nur im Linearbetrieb liegt der Arbeitspunkt innerhalb der Fläche, welche durch die Außenlinien begrenzt wird.<br />
<br />
[[bild: SOA-BUZ11.png | thumb | 300px| SOA-Diagramm]]<br />
<br />
Bei der Anwendung des Diagramms gilt es einiges zu beachten. Die Pulsleistungen sind nur zulässig, wenn der MOSFET vorher kalt ist, sprich ca. 25°C Sperrschichttemperatur hat. War er vorher schon heiß, reduziert sich die zulässige Belastung deutlich. Ebenso dürfen die Pulse nicht zu schnell wiederholt werden, denn dann ist der MOSFET noch vom vorherigen Puls aufgeheizt. Im Fall von DC sind 75W Verlustleistung auch eher ein theoretischer Wert, welcher real nur schwer erreicht werden kann, wenn der MOSFET auf einem sehr großen [[Kühlkörper]] optimal montiert ist. Praktisch liegen die erreichbaren Werte eher bei der Hälfte.<br />
<br />
(Anm. Eigentlich müsste für die R_DS_ON Grenzlinie R = U / I der minimale R_DS_ON rauskommen, hier ~40mOhm, es kommen aber ~80mOhm raus. Die Ursache dafür ist unklar, möglicherweise liegt hier ein Sicherheitsfaktor zu grunde).<br />
<br />
{{Clear}}<br />
<br />
== Linearbetrieb von MOSFETs ==<br />
<br />
Der Großteil der Anwendungen nutzt MOSFETs als Schalter, d.h. der MOSFET ist entweder voll gesperrt oder voll durchgesteuert. Dafür gelten auch all die Hinweise in diesem Artikel. In bestimmten Anwendungen werden MOSFETs aber auch im Linearbetrieb eingesetzt, z.B in linearen Endstufen für Audio, Video, elektronischen Lasten und Stromquellen. Hier muss man einiges beachten. Ein verbreiteter Irrtum besteht darin zu glauben, MOSFETs könne man im Linearbetrieb einfach parallel schalten, weil der positive Temperaturkoeffizient von <math>R_{DS(ON)}</math> eine Symmetrierung bewirkt, ähnlich den Emitterwiderständen bei parallelgeschalteten Bipolartransistoren. Das ist ''ausschließlich'' im Schaltbetrieb möglich, und daher falsch! Im Linearbetrieb spielt der Temperaturkoeffizient von <math>R_{DS(ON)}</math> keine Rolle, weil der MOSFET selten bis nie komplett durchgesteuert ist. Eben darum ist beim Linearbetrieb der minimale <math>R_{DS(ON)}</math> in den meisten Fällen unwichtig und man kann auch eher hochohmige, ältere MOSFETs verwenden, wie z.B. den BUZ11.<br />
<br />
Hier wirkt vielmehr der negative Temperaturkoeffizient (TK) der Thresholdspannung <math>U_{GS(thr)}</math>, vergleichbar dem negativen TK der Basis-Emitter-Spannung von Bipolartransistoren. D.h. mit steigender Temperatur und konstanter Gate-Source-Spannung steigt der Stromfluss der Drain-Source Strecke. In einer Parallelschaltung von MOSFETs würde dies bedeuten, dass der MOSFET mit dem geringfügig größeren Drainstrom (Fertigungstoleranzen) wärmer wird, was zu einem weiter steigenden Drainstrom und damit noch mehr Wärme führt. Damit ist die Schaltung thermisch instabil und würde zum Durchbrennen der MOSFETs führen, einer nach dem Anderen. <br />
<br />
Um das zu verhindern muss man relativ große Ausgleichswiderstände in die Source-Leitung der einzelnen MOSFETs schalten, um diese Drift zu kompensieren. Dadurch verschlechtert sich natürlich der Wirkungsgrad des Verstärkers. MOSFETs haben einen TK von typisch -5mV/K für <math>U_{GS(thr)}</math>, das ist mehr als das doppelte von Bipolartransistoren mit typisch -2mV/K, weshalb die Symmetrierungswiderstände mehr als doppelt so groß sein müssen. Weiterhin muss man beachten, dass die Toleranzen von <math>U_{GS(thr)}</math> sehr groß sind, im Bereich von Volt! Das kann man sinnvoll nicht mehr mit Gatewiderständen symmetrieren, hier muss man die MOSFETs ausmessen und Gruppen mit geringen Toleranzen in einer Schaltung verwenden (engl. matching). <br />
<br />
Eine andere Möglichkeit ist die getrennte Ansteuerung der einzelnen MOSFETs, das wird oft in elektronischen Lasten bzw. [[Konstantstromquelle#Konstantstromquelle mit Operationsverstärker und Transistor | Konstantstromquellen]] gemacht. Hier treten keine zusätzlichen Verluste auf und der Mehraufwand in der Ansteuerung ist meist unkritisch.<br />
<br />
Weiterhin muss man beachten, dass viele der heutigen HochleistungsMOSFETs intern eine Parallelschaltung vieler kleiner MOSFET-Zellen (z.B. sogenannte Trench-FET) sind, und somit oft für den Linearbetrieb ungeeignet sind. Denn auch dort können einzelne Zellen überhitzen und durchbrennen (Hot Spot). Ob ein MOSFET für den Linearbetrieb tauglich ist steht manchmal im Datenblatt, oft aber eher nicht, eben weil die meisten MOSFETs als Schalter entwickelt und gebaut sind. Typische Vertreter für Linearbetrieb findet man in der [[MOSFET-Übersicht]]. Ein wichtiges Indiz für Linearbetrieb ist eine Kurve für DC im [[#SOA_Diagramm | SOA-Diagramm]]. Meist geht es dort nur bis 10ms, DC fehlt, eben weil DC (engl. '''D'''irect '''C'''urrent = Gleichstrom = Linearbetrieb) nicht zulässig ist. Manchmal hat der Hersteller auch "vergessen", die Kennlinie für DC mit reinzuschreiben, wie z.B. bei [http://www.irf.com/product-info/hi-rel/alerts/fv5-p-09-01-A.pdf IRF], wie in diesem [http://www.mikrocontroller.net/topic/291760#3106758 Beitrag] zu erfahren ist.<br />
Ein recht gutes Indiz dafür, ob ein FET für den Linearbetrieb taugt, ist die Vorwärtssteilheit. Diese kennzeichnet die Abhängigkeit des Drainstromes von der Ansteuerung am Gate als <math>S = \Delta i_d/\Delta u_{gs}</math>. Moderne Trench-FET erreichen heute Steilheiten im dreistelligen Bereich und sind für Linearanwendungen völlig unbrauchbar. Zum Vergleich: Der BUZ11 kommt mit gerade einmal 4 bis 5 Siemens daher.<br />
<br />
In diesem Beitrag wird die DC-Linie im SOA-Diagramm noch genauer erklärt: [http://www.mikrocontroller.net/topic/319961#3473567 Re: MOSFET Linearbetrieb möglich?]<br />
<br />
<br />
== Siehe auch ==<br />
<br />
* [[Leistungselektronik]]<br />
* [[Mosfet-Übersicht]]<br />
* [[IGBT]]<br />
* [[TRIAC]]<br />
* [[Kühlkörper]] <br />
* [[Zwischenkreiskapazität]]<br />
* [[Treiber]]<br />
* [[Snippets#Wie_schlie.C3.9Fe_ich_einen_MOSFET_an_einen_Mikrocontroller_an.3F|Wie schließe ich einen Mosfet an einen Mikrocontroller an?]]<br />
* [http://www.mikrocontroller.net/articles/H-Br%C3%BCcken_%C3%9Cbersicht Übersicht H-Brücken]<br />
* [http://www.mikrocontroller.net/topic/168218#1609684 Forumsbeitrag]: MOSFETs im Linearbetrieb<br />
* [http://www.mikrocontroller.net/topic/186785#new Forumsbeitrag]: nochmal MOSFETs im Linearbetrieb<br />
* [http://www.mikrocontroller.net/topic/319961#3473567 Forumsbeitrag]: sehr ausführlicher Forumsbeitrag über MOSFETs im Linearbetrieb. Berücksichtigt auch den Spirito-Effekt.<br />
* [http://www.mikrocontroller.net/topic/143324#new Forumsbeitrag]: Über eine elektronische Last, sehr lang<br />
*[http://www.mikrocontroller.net/topic/246449#2519459 Forumsbeitrag]: Logic Level MOSFETs direkt mit einem [[AVR]] treiben.<br />
* [http://www.mikrocontroller.net/topic/267254#2787855 Forumsbeitrag]: MOSFETs im Linearbetrieb, Laborerfahrungen<br />
* [http://www.mikrocontroller.net/topic/267254#2787945 Forumsbeitrag]: MOSFETs für Linearbetrieb<br />
* [https://www.mikrocontroller.net/topic/269642?goto=2820617#2820617 Forumsbeitrag]: Verpol- und Überspannungsschutz mit MOSFETs<br />
* [https://www.mikrocontroller.net/topic/425414#4981611 Forumsbeitrag]: Linearbetrieb von MOSFETs<br />
<br />
== Weblinks ==<br />
<br />
* [http://www.elektronikinfo.de/strom/feldeffekttransistoren.htm Feldeffekttransistoren bei elektronikinfo.de]<br />
* [http://www.elektronik-kompendium.de/sites/bau/0207011.htm FET im ELKO]<br />
* [http://www.elektronik-kompendium.de/sites/bau/0510161.htm MOSFET im ELKO]<br />
* [http://www.sprut.de/electronic/switch/nkanal/nkanal.html MOSFET bei sprut.de]<br />
* [http://sound.westhost.com/articles/hexfet.htm#51 MOSFETs in Audioendstufen, engl.]<br />
* [http://irf.custhelp.com/cgi-bin/irf.cfg/php/enduser/std_adp.php?p_faqid=214&p_created=1019728945&p_sid=pt9ITiCj&p_accessibility=0&p_redirect=&p_lva=&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9MTQsMTQmcF9wcm9kcz0mcF9jYXRzPSZwX3B2PSZwX2N2PSZwX3BhZ2U9MSZwX3NlYXJjaF90ZXh0PWxpbmVhcg**&p_li=&p_topview=1 FAQ Answer ID 214 bei IRF zum Linearbetrieb]<br />
* [http://www.nxp.com/documents/application_note/AN11158.pdf AN11158 - Understanding power MOSFET data sheet parameters] von NXP (PDF)<br />
* [https://assets.nexperia.com/documents/technical-note/TN00008.pdf TN00008 - Power MOSFET frequently asked questions and answers] von nexperia (PDF)<br />
* [http://www.infineon.com/dgdl/Infineon+-+Application+Note+-+PowerMOSFETs+-+OptiMOS%E2%84%A2+-+Linear+Mode+Operation+and+SOA+Power+MOSFETs.pdf?fileId=db3a30433e30e4bf013e3646e9381200 AN: Linear Mode Operation andSafe Operating Diagram of Power-MOSFETs] von Infineon (PDF)<br />
* [http://www.ixys.com/Documents/Articles/Article_Linear_Power_MOSFETs.pdf MOSFETs Withstand Stress of Linear-Mode Operation] Neuentwickelte MOSFETs für Linearbetrieb (PDF)<br />
<br />
[[Kategorie:Bauteile]] [[Kategorie:Leistungselektronik]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=FET&diff=107024FET2024-07-19T16:28:17Z<p>Heha: Depletion-Mode-Ergänzung Verfügbarkeit</p>
<hr />
<div>Dieser Artikel versteht sich als Unterpunkt zum Artikel [[Leistungselektronik]]<br />
<br />
<br />
Ein FET (engl. '''F'''ield '''E'''ffect '''T'''ransistor) ist ein Feldeffekttransistor. Der FET ist ein Bauelement, das im Gegensatz zum Bipolartransistor (engl. '''B'''ipolar '''J'''unction '''T'''ransistor, BJT) mit Spannung und nicht mit Strom gesteuert wird. Unterschieden werden<br />
* MOSFET = engl. '''M'''etall '''O'''xide '''S'''emiconductor '''F'''ield '''E'''ffect '''T'''ransistor; Metalloxidschicht-FET, größte Teilgruppe der FETs mit isoliertem Gate <br />
* JFET = engl. '''J'''unction '''F'''ield '''E'''ffect '''T'''ransistor, Übergangszonen FET, der steuerbare Kanal wird durch einen PN-Übergang wie in einer Diode gebildet<br />
<br />
Die drei Anschlüsse eines FETs werden ''Gate'', ''Drain'' und ''Source'' genannt. Unter Umständen ist ein vierter Anschluß vorhanden, der ''Bulk'' genannt wird. Normalerweise ist Bulk intern mit Source verbunden. Wenn dies nicht der Fall ist, muss diese Verbindung durch den Designer in der Schaltung hergestellt werden.<br />
<br />
== FET-Typen ==<br />
<br />
<br />
FETs werden hauptsächlich unterschieden in N-Kanal und P-Kanal, sowie "selbst sperrend = Anreicherungstyp" (engl. enhancement type) und "selbst leitend = Verarmungstyp" (engl. depletion type). Beim selbstleitenden FET ist der Transistor bei 0V Gate-Source Spannung maximal leitend (durchgesteuert) und wird durch Anlegen einer Spannung ans Gate gesperrt. Beim selbstsperrenden FET (größte Gruppe) ist der Transistor bei 0V Gate-Source Spannung gesperrt und wird durch Anlegen einer Spannung ans Gate leitend. Ist die Linie zwischen Drain und Source durchgezogen handelt es sich um einen selbstleitenden, bei einer gestrichelten Linie um einen selbstsperrenden FET. JFETs gibt es nur als Verarmungstyp. Im weiteren Artikel wird nur mehr der "selbstsperrende" MOSFET betrachtet.<br />
<br />
{| class="wikitable"<br />
|+ '''Typen von Feldeffekttransistoren<br/>&nbsp;'''<br />
|-<br />
! style="width:10em" | Typ <br />
! N-Kanal <br />
! P-Kanal<br />
|- valign="top"<br />
| JFET<br/>SFET<br/>(selbst leitend) || [[bild:JFET-N.png|center]]<br />
* drittgrößte Gruppe<br />
* bislang nur für kleine Leistungen verfügbar<br />
* JFETs mit hoher Leistung sind im Kommen<br />
* Eingangsstufen von OPVs<br />
* Eingangsstufen von HF-Verstärkern bis in den GHz-Bereich<br />
** Typen mit zwei Gates zum Regeln und Mischen üblich<br />
* als einfache [[Konstantstromquelle]] geeignet<br />
| [[bild:JFET-P.png|center]]<br />
* selten<br />
* ersatzhalber für „fehlenden“ P-Kanal-Verarmungs-MOSFET<br />
* Ältester Vertreter der Unipolartransistoren<br />
|- valign="top"<br />
| MOSFET<br/>Anreicherungstyp<br/>(selbst sperrend)<br/>''Enhancement Mode'' || [[bild:MOS-EN.png|center]]<br />
* Mit Abstand größte Gruppe; wenn nicht besonders erwähnt ist ''dieser'' gemeint<br />
* sehr viele Typen erhältlich<br />
* Auch als Doppel-MOSFET oder zusammen mit P-Kanal-MOSFET in einem Gehäuse gängig<br />
| [[bild:MOS-EP.png|center]]<br />
* zweitgrößte Gruppe<br />
* bei gleicher Geometrie etwas schlechter als ein N-Kanal Typ<br />
* Auch als Doppel-MOSFET oder zusammen mit N-Kanal-MOSFET in einem Gehäuse gängig<br />
|- valign="top"<br />
| MOSFET<br/>Verarmungstyp<br/>(selbst leitend)<br/>''Depletion Mode'' || [[bild:MOS-DN.png|center]]<br />
* selten aber käuflich<br />
* Sinnvolle Anwendungen ergeben sich vor allem in Reihenschaltungen<br />
| [[bild:MOS-DP.png|center]]<br />
* Nicht in freier Wildbahn gesichtet<br />
|}<br />
<br />
=== Vorteile des FET ===<br />
<br />
* Niedrigere Verluste als bei Bipolartransistoren.<br />
* Sehr schnelles Schalten möglich, daher für sehr hohe Frequenzen geeignet (keine Speicherzeit wie beim BJT).<br />
* Einfaches Parallelschalten im Schaltbetrieb, da Unterschiede im <math>R_{DS,on}</math> durch den positiven Temperaturkoeffizienten ausgeglichen werden.<br />
* Leistungslose Ansteuerung im statischen Fall, jedoch hohe Umladeverluste am Gate!<br />
* oft preiswerter als vergleichbare Bipolartransistoren (engl. '''B'''ipolar '''J'''unction '''T'''ransistor, BJT)<br />
* Relativ unempfindlich gegen Überspannung zwischen Drain und Source. Bei Überschreitung der Maximalspannung zwischen Drain und Source findet ein sogenannter "Durchbruch" statt. Dies ist vergleichbar mit dem Zener-Effekt. Ist die Energiemenge begrenzt, ist dieser Durchbruch reversibel und der FET wird NICHT zerstört. Beim Bipolartransistor ist die dafür zulässige Energiemenge viel kleiner, weil die den Strom durchquerende Fläche zu Hotspots neigt.<br />
<br />
=== Nachteile des FET ===<br />
<br />
* Nur bedingt für hohe Spannungen [[Transistor#Wann setzt man einen MOSFET, Bipolartransistor, IGBT oder Thyristor ein ? |geeignet]], die ON-Verluste sind ab ca. 250V höher als bei einem [[IGBT]]. <br />
* Parasitäre Diode parallel zur Drain-Source Strecke ist immer enthalten, das (Ab-)Schaltverhalten dieser Dioden ist meist schlechter als separate Dioden, was häufig zu unerwünschten Schwingungen führt.<br />
* Empfindlicher gegen ESD am Gate als BJT<br />
* Positiver Temperaturkoeffizient (TK), der <math>R_{DS,on}</math> ist stark temperaturabhängig und steigt von 25°C (Datenblattangabe) auf 150°C ungefähr um den Faktor 2. Dadurch steigen auch die Verluste und damit die Erwärmung des Bauteiles.<br />
<br />
=== Erklärung der wichtigsten Datenblattwerte ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! style="width:12em" | '''Parameter'''<br />
! style="width:7em" | '''Symbol'''<br />
! style="width:6em" | Beispiel<br />
! '''Erklärung'''<br />
|-<br />
| Drain Source Voltage <br>(Breakdown) || V(BR)_DSS <br> V_DS || 75 V || Maximale Spannungsfestigkeit des Bauteiles zwischen Drain und Source<br />
|-<br />
| Continuous Drain Current || I_D(on) || 55 A @ 125 °C || Maximaler Dauerstrom bei 125°C Gehäusetemperatur <br />
|-<br />
| Pulsed Drain Current || ID_pulse <br> I_CD(on) || 240 A || Maximaler Pulsstrom (Achtung die zulässige Zeitdauer des Pulses kann nur über die maximale Junctiontemperatur ermittelt werden)<br />
|-<br />
| Gate Charge || Q<sub>GS</sub> || 320 nC || Gate-Ladung in Coloumb oder Amperesekunden, die zum Ein- oder Ausschalten des MOSFET erforderlich ist. Dies berücksichtigt die Nichtlinearität der Kapazität und (richtig?) den Miller-Effekt. Mit dieser Angabe wird der für das Schalten von Leistungs-MOSFET benötigte Gatestrom für eine bestimmte Schaltzeit ermittelt. Dieser liegt üblicherweise im einstelligen Ampere-Bereich. Moderne Typen mit extra geringer Gate-Ladung können so schneller schalten.<br />
|-<br />
| Repetetive Avalanche Energy || t_sc || 280 mJ || Maximale Energie, welche beim Avalanche Durchbruch bei Überschreiten der maximalen Drain-Source Spannung im MOSFET bei z.&nbsp;B. 1% Puls/Pausen Verhältnis regelmäßig auftreten darf, ohne den FET zu schädigen<br />
|-<br />
| Drain-Source<br>ON Resistance || R<sub>DS_ON</sub> || 0,01 Ω || Widerstand des eingeschalteten FETs bei '''25°C''', V_GS = 10V und ID = 30A<br />
|-<br />
| Drain-Source<br>ON Resistance || R<sub>DS_on</sub> || 0,021 Ω || Widerstand des eingeschalteten FETs bei '''175°C''', V_GS = 10V und ID = 30A<br />
|-<br />
| Thermal Resistance<br>(junction-case) || R<sub>th_JC</sub> || 0,8 K/W || Thermischer Widerstand im Transistor vom der „Sperrschicht“ (junction eines Bipolartransistors, ja altmodischer Index, hier besser „Kanal“) bis zur Rückseite oder bestmöglichen Kühlmöglichkeit des Transistorgehäuses (case)<br />
|-<br />
| Gate-Source<br>Threshold Voltage || V_GS(th) || 2,0-4,5 V || Gatespannung, ab welcher der Transistor minimal leitend wird (I_D typisch 100-200µA), große Toleranz, typisch 1:2 zwischen Minimum und Maximum<br />
|-<br />
| Turn-on Delay || t_d(on) || 40 ns || Verzögerung zwischen dem Einschalten am Gate bis zur Reaktion im Drainstrom<br />
|-<br />
| Rise Time || t_r || 200 ns || Anstiegszeit des Transistorstromes am Drain<br />
|-<br />
| Turn-off Delay || t_d(off) || 120 ns || Verzögerung zwischen Abschalten am Gate bis zur Reaktion im Drainstrom<br />
|-<br />
| Fall Time || t_f || 60 ns || Abfallzeit des Transistorstromes am Drain <br />
|}<br />
<br />
Die oben genannten Zeiten gelten ausschließlich unter den angegebenen Messbedingungen (Gatewiderstand, Treiberspannung, sowie einer '''FET-Teperatur von 25°C!''') und müssen für die eigene Anwendung ggf. neu berechnet werden. Meist wird man sie eher messen, weil die Rechung zu aufwändig und bisweilen unmöglich ist. <br />
<br />
==== Gate-Source Threshold Voltage ====<br />
Gerade bei der '''Gate-Source Threshold Voltage <math>V_{GS}(th)</math>''' gibt es hier immer wieder Verwirrung. Sie gibt an, ab welcher Spannung der MOSFET anfängt, minimal leitfähig zu werden. Diese Spannung ist technologisch bedingt auch heute noch einer starken Toleranz unterworfen, typischerweise hat der Bereich bei dem der FET zu leiten beginnt eine Spreizung von etwa 1:2 zwischen Minimum und Maximum. Welche Spannung man nun wirklich anlegen muss, um den gewünschten <math>R_{DS}(on)</math> zu erreichen kann der Tabelle im jeweiligen Datenblatt entnommen werden. Dabei unbedingt die angegebene Gatespannung beachten, nur dieser Wert ist garantiert!.<br />
<br />
[[bild: IRLZ34N_R_DS_ON.png | thumb | 800px | R_DS_ON im Datenblatt des IRLZ34N]]<br />
{{Clear}}<br />
<br />
Die Kurvenschar von <math>I_D</math> über <math>U_{DS}</math> in Abhängigkeit von <math>U_{GS}</math> stellt immer nur typische Werte dar, keine garantierten Extremwerte (engl. worst case). Als Standardwerte kann man 10-15V für einen Standardtypen und ca. 3-5V für einen Logic Level MOSFET (LL-FET) ansetzen. Kleinsignal-FETs leiten schon ab ca 1V. Bei Ansteuerung mit 5V benötigt man also einen Typen, der '''sicher''' bei 5V voll durchgesteuert ist, z.B. IRLZ34N. Bei 3,3V ist er bereits nicht mehr zuverlässig nutzbar. Es gibt auch Typen mit noch geringerer Spannung für Vollaussteuerung. Wer einen BUZ11 (<math>V_{GS}(th)</math> 4V max.) mit 5V ansteuert riskiert ein Abfackeln des MOSFETs, denn je nach Toleranz kann er bereit ganz gut aufgesteuert sein oder auch nicht. Das soll in den nachfolgenden Diagrammen dargestellt werden. Zunächst die Transferkennlinie. Sie gibt an, wieviel Drainstrom in Abhängigkeit der Gatespannung fließen kann, wobei die Drainspannung konstant ist, hier im Beispiel 25V. Ein typischer BUZ11 (mittlere, schwarze Kurve) fängt bei 3V zu leiten an und erreicht bei 6V am Gate ca. 17A. Erwischt man nun ein kritisches Exemplar, das erst bei 4V zu leiten anfängt (rechte, rote Kurve um 1V parallel verschoben), so kann dieser bei 6V nur 8A leiten, für 17A braucht er 7V. Der günstige Fall, daß der BUZ11 schon bei 2V anfängt zu leiten sieht man in der linken, roten Kurve.<br />
<br />
[[bild: BUZ11_UGS_ID.png | thumb | 800px | Transferkennlinie des BUZ11]]<br />
{{Clear}}<br />
<br />
Wenn man die drei Fälle (min, typ, max) mit 5V ansteuert, erhält man die Arbeitspunkte 1-3 mit einem maximal schaltbaren Drainstrom von 2,5, 8 und 17A. Diese kann man in das Ausgangskennlinienfeld übertragen. Wir nehmen max. 1V U_DS an. Es ergeben sie die gleichen Ströme. Der maximale Drainstrom weicht um -5,5/+9A vom typischen Fall ab. Erhöht man nun die Gate-Source Spannung auf 10V (Arbeitspunkt 4), schwankt der maximal schaltbare Drainstrom nur noch um -2/+2A, außerdem liegt er mit 30A deutlich höher. Der BUZ11 ist somit sicher durchgesteuert.<br />
<br />
[[bild: BUZ11_UDS_ID_UGS.png | thumb | 800px | Ausgangskennlinie des BUZ11]]<br />
{{Clear}}<br />
<br />
==== Parasitäre Diode ====<br />
<br />
Der Schwerpunkt in der FET-Entwicklung liegt auf den geringst-möglichen <math>R_{DS}(on)</math>, die Diode entsteht auf Grund des Herstellungsprozesses, und wird nur nachrangig verbessert, da viele Optimierungsversuche auch einen Einfluss auf wichtige Kennwerte des FETs hatten und haben.<br />
Daher muss sorgfältig geprüft werden, ob die Schaltgeschwindigkeit, die Recovery-Time und die damit verbundenen Verluste sowie die dabei erzeugte unerwünschte EMV-Abstahlung tolerierbar ist, oder nicht.<br />
Hier hilft es oft eine optimierte Diode / Schottky-Diode zum FET parallel zu schalten. Ganz ausblenden läßt sich die parasitäre Diode jedoch nicht, jedoch kann man den Anteil des Stromes beeinflussen, der über die intere Diode fliest.<br />
<br />
{| class="wikitable"<br />
|+ ''' Parasitäre Diode des FETs '''<br />
|-<br />
! style="width:10em" | '''Parameter'''<br />
! style="width:6em" | '''Symbol'''<br />
! style="width:6em" | '''Beispiel'''<br />
! '''Erklärung'''<br />
|-<br />
| Continuous Current || I_S || 75A || Maximaler Dauerstrom der parasitären Diode, meist identisch zum maximalen Dauerstrom des MOSFETs<br />
|-<br />
| Forward Voltage || V_SD || 1,3V || Spannungsfall an der parasitären Diode <br />
|-<br />
| Reverse Recovery Time || t_rr || 120ns || Zeit, welche die Elektronen brauchen um aus der leitenden Diode vollständig abzufließen. Während dieser Zeit fließt der Strom in '''Rückwärtsrichtung''' durch die Diode und erzeugt relativ viel Verlustleistung. <br />
|-<br />
| Reverse Recovery Charge || Q_rr || 60nC || Ladungsmenge, die während t_rr rückwärts durch die Diode fließt. <br />
|}<br />
<br />
== Haupttypen und Gatespannungslevel ==<br />
<br />
===Unterschied N-Kanal / P-Kanal FET===<br />
<br />
Im Schaltsymbol werden die MOSFET-Typen meist durch die Pfeilrichtung in der Mitte des Symbols (eigentlich "Bulk") vom oder zum Gate unterschieden. Zeigt der Pfeil zum Gate hin, handelt es sich um einen N-Kanal-FET, zeigt der Pfeil vom Gate weg um einen P-Kanal FET.<br />
<br />
Der große Vorteil des N-Kanal FETs (Elektronenleitung) ist, daß er immer niederohmiger ist, als ein gleich großer P-Kanal FET (Löcherleitung). Daher sind P-Kanal Typen bei vergleichbaren Werten auch immer größer = teuerer da weniger Chips auf einem Wafer Platz haben.<br />
<br />
Beim N-Kanal FET muss die Gatespannung positiv gegenüber Source sein. Dabei wird der FET dann leitend, wenn die sogenannte "threshold voltage" (Schwellenspannung) erreicht wird. Eine typische Anwendung ist z.&nbsp;B. ein '''Low-Side Schalter''': Source an GND, Drain an die Last, Ansteuerung des N-Kanal FETs mit 12V gleichbedeutend mit 12V ÜBER den Source = GND Potential.<br />
<br />
Beim P-Kanal FET als HS-Schalter muss die Gatespannung negativer=niedriger als das Sourcepotential sein.Beispiel.<br />
Beispiel: <br />
Lastspannung = 400V d.h. Source an 400V, Last zwischen Drain und GND, Ansteuerung des P-Kanal FETs mit 388V, also 12V UNTER dem Sourcepotential.<br />
<br />
Beim N-Kanal FET als HS-Schalter muss die Gatespannung positver=höher als das Sourcepotential sein.<br />
Beispiel:<br />
Lastspannung = 400V d.h. Drain an 400V, die Last zwischen Source und GND, Ansteuerung des N-Kanal FETs mit 412V, also 12V ÜBER dem Sourcepotential.<br />
In diesem Fall ist aber eine zusätzliche Spannungsquelle erforderlich, denn der FET wird mit einer Spannung über der Lastspannung eingeschaltet. <br />
<br />
'''Weblinks'''<br />
* [https://www.eetimes.com/a-primer-on-high-side-fet-load-switches-part-1-of-2/?utm_source=eetimes&utm_medium=networksearch A primer on high-side FET load switches (Part 1 of 2)], Qi Deng, Senior Product Marketing Manager, Mixed-Signal Products, Micrel, Inc., 5/3/2007 4:14 PM EDT, www.eetimes.com<br />
* [https://www.eetimes.com/a-primer-on-high-side-fet-load-switches-part-2-of-2/ A primer on high-side FET load switches (Part 2 of 2)], Qi Deng, Senior Product Marketing Manager, Mixed-Signal Products. Micrel, Inc., 5/7/2007 1:36 PM EDT, www.eetimes.com<br />
* [http://www.vishay.com/docs/70611/70611.pdf AN804 P-Channel MOSFETs, the Best Choice for High-Side Switching (PDF)] von Vishay Siliconix<br />
<br />
===Unterschied Logic-Level / "Normal"-Level===<br />
<br />
Den meisten FETs ist gemein, daß sie mit einer Spannung von 10..15V angesteuert werden müssen, um den minimalen Einschaltwiderstand zu erreichen. Diese FETs lassen sich nicht ohne weiteres mit einem CMOS-Pegel von 5V ansteuern. Es gibt jedoch für diesen Anwendungsfall sogenannte "Logic Level" (LL) FETs, die schon bei einer Gatespannung von etwa 4,5V voll durchgesteuert sind. Einige Kleinsignal-FETs sind schon ab ca. 1,2V voll durchgesteuert.<br />
<br />
== Beispiel zur Bauteiledimensionierung ==<br />
<br />
=== Spannungsfestigkeit ===<br />
<br />
Die höchste vorkommende Betriebsspannung + Abschaltüberspannung soll kleiner als ca. 80% der Spannungsfestigkeit des Bauteiles sein. <br />
<br />
Achtung: Zwischen dem je nach Anwendungsfall erforderlichen Pufferkondensator und dem FET wird es immer eine parasitäre Induktivität geben.<br />
Abhängig von Schaltgeschwindigkeit und Induktivität wird im Schaltmoment eine mehr oder weniger große Übrspannungsspitze produziert. Dieser Peak<br />
addiert sich auf die aktuelle Versorgungsspannung.<br />
<br />
Überschlagsrechnung als Beispiel:<br />
* Schaltgeschwindigkeit: dI/dt = -100A/µs (= Abschalten von 5A innerhalb 50ns),<br />
* Induktivität: L = 1µH (~ 1 m loses, ungebündeltes Kabel)<br />
* dU=-L*dI/dt = -1µH * (-100A / 1µs) = 100V<br />
<br />
Dies bedeutet, daß an der "Induktivität" zwischen Transistor und Kondensator - Aufgrund von Selbstinduktion im Schaltmoment - ein Überspannungspuls von ca. 100V entsteht, der auf die Betriebsspannung aufzuschlagen ist, also lieber die Leitung kürzer machen, und - sofern möglich - nicht ganz so schnell schalten.<br />
<br />
=== Stromtragfähigkeit ===<br />
<br />
In jedem Datenblatt ist eine Stromtragfähigkeit bei 25°C, und meist noch bei einer höheren Temperatur z.B. 125°C, 150°C oder 175°C Kühlfahnentemperatur angegeben. Dieser Wert ist als ERSTE Entscheidungsgrundlage ausreichend, aber aus der theoretisch abführbaren Verlustleistung errechnet, und<br />
* dient zum qualitativen Vergleich von Transistoren bezüglich ihres R_ds(on) und ihres Wärmewiderstands.<br />
* ist für die Dimensionierung einer Schaltung nur als Richtwert zu interpretieren. <br />
* ist ohne Schaltverluste genannt, und daher nur für einen Schaltbetrieb von wenigen Hz gültig. Außerdem wird ein annähernd idealer Kühlkörper unterstellt, der trotz der Verlustleistung das Gehäuse des Transistors auf der angegebenen Temperatur halten kann.<br />
* entbindet einen nicht davon den Kopf einzuschalten... siehe die nachfolgenden Zeilen.<br />
* Liegt der Strom für den die Schaltung entwickelt wird mit ca. 10..20% Abstand unter dem Datenblattwert von 125°C ist dieses Bauteil vermutlich verwendbar (siehe Detailberechnungen unten !). <br />
* Ist der benötigte Strom im Bereich oder größer als der zulässige bei 125°C sollte entweder ein anderer Typ eingesetzt oder mehrere FETs ''des gleichen Typs'' parallelgeschaltet werden.<br />
<br />
== Verlustleistung ==<br />
<br />
Hier wird eine Näherung für eine getaktete Anwendung betrachtet. In einem Transistor treten sowohl beim Ein- und Ausschalten, als auch während der Einschaltphase Verluste im Bauteil auf. Diese Verluste führen zu einer Bauteilerwärmung. Die dabei entstehende Temperatur darf die maximal zulässige Bauteiletemperatur nie überschreiten. Bei den ersten Projekten ist zu empfehlen eine berechnete Chiptemperatur von ca. 125°C nicht zu überschreiten. Fast alle aktuell verfügbaren FETs nennen im Datenblatt eine Temperatur von 175°C als ihre maximale Chiptemperatur.<br />
<br />
{| class="wikitable" style="width:32em" <br />
|+ '''Beispiel'''<br />
|-<br />
! Parameter<br />
! style="width:8em" | Symbol<br />
! style="width:8em" | Wert<br />
|-<br />
| Betriebsspannung || U<sub>N</sub> || 70 V<br />
|-<br />
| Nennstrom || I<sub>N</sub> || 30 A<br />
|-<br />
| Drain-Source Widerstand bei<br>Chiptemperatur: 125°C<br> Gatespannung: 10V || R<sub>DS<sub>on</sub></sub> || 17 mΩ<br />
|-<br />
| Pulsbreite || t<sub>on</sub> || 150 µs<br />
|-<br />
| Schaltfrequenz || ƒ<sub>schalt</sub> || 5 kHz<br>T = 200µs<br />
|-<br />
| Einschaltzeit (risetime) || t<sub>r</sub> || 500 ns<br />
|-<br />
| Ausschaltzeit (falltime) || t<sub>ƒ</sub> || 800 ns <br />
|-<br />
|}<br />
<br />
==== Leitend-Verluste ====<br />
<br />
Während der FET bei [[PWM]]-Ansteuerung eingeschaltet ist, erzeugt er Verlustleistung.<br />
<br />
<math><br />
P_\text{ON}<br />
= {I_\mathrm{N}}^2 \cdot R_\mathrm{DS_\mathrm{ON}} \cdot \frac{t_\mathrm{ON}}{T}<br />
= 30^2A^2 \cdot 17m\Omega \cdot \frac{150\mu s}{200\mu s} = 11{,}5W<br />
</math><br />
<br />
==== Schalt-Verluste ====<br />
<br />
Vereinfachter Ansatz.<br />
<br />
Einschalten:<br />
<br />
:<math>\begin{align}<br />
P_\mathrm{SW_r}<br />
&= \tfrac14 \cdot U_N \cdot I_N \cdot \frac{t_r}{T} \\<br />
&= \tfrac14 \cdot 70V \cdot 30A \cdot \frac{500ns}{200\mu s}=1{,}3W<br />
\end{align}</math><br />
<br />
Ausschalten:<br />
<br />
:<math>\begin{align}<br />
P_\mathrm{SW_f} <br />
&=\tfrac14 \cdot U_N \cdot I_N \cdot \frac{t_f}{T}\\<br />
&=\tfrac14 \cdot 70V \cdot 30A \cdot \frac{800ns}{200\mu s}=2{,}1W<br />
\end{align}</math><br />
<br />
Alternativ und genauer kann man rechnen, wenn die Ein- Ausschaltenergie im Datenblatt angegeben ist. Aber Achtung! Die Randbedingungen unter denen die genannte Energie ermittelt wurde, müssen genau so zutreffen.<br />
:<math>\begin{align}<br />
P_{SW_f} = f_{schalt} \cdot E_{ON}<br />
\end{align}</math><br />
:<math>\begin{align}<br />
P_{SW_r} = f_{schalt} \cdot E_{OFF}<br />
\end{align}</math><br />
<br />
Die Gesamtverlustleistung beträgt also in etwa 15W.<br />
<br />
Damit muß ein entsprechender [[Kühlkörper]] ausgelegt und die Chiptemperatur berechnet werden. z.&nbsp;B.:<br />
* Kühlkörper mit einem R_th von 0,2K/W<br />
* max. Umgebungstemperatur +60°C<br />
* R_th "junction-case" des FETs 0,8K/W<br />
* R_th der Wärmeleitfolie zwischen FET und Kühlkörper ca. 2,0K/W<br />
* R_th gesamt: 3,0K/W <br><br />
* Bei einer Verlustleistung von 18W und einer Umgebungstemperatur von 60°C hat der Chip eine Temperatur von ca. 18W * 3,0K/W +60°C = 114°C. ==> o.k.!<br />
<br />
Unter Berücksichtigung der Tatsache, daß hier viele Vereinfachungen vorgenommen, und die Art der Last nicht beachtet wurde ist es sinnvoll, einen gewissen Sicherheitsabstand zu den zulässigen Maximalwerten einzuhalten. Daher ist es empfehlenswert, die Chiptemperatur auf ca. 125°C zu beschränken. <br />
<br />
Des Weiteren ist hier die parasitäre Diode im FET nicht berücksichtigt.<br />
Wenn während der "off" Zeit ein Strom über die Diode fließt (Reverse recovery current oder Freilaufstrom), muß die dadurch '''zusätzlich''' entstehende Verlustleistung in die obige Berechnung der maximalen Chiptemperatur mit einfließen.<br />
<br />
==Treiberleistung==<br />
<br />
Auch wenn der MOSFET ein spannungsgesteuertes Bauelement ist, muss trotzdem bei jedem Einschalten und bei jedem Ausschalten die Gatekapazität umgeladen werden. Bei älteren Leistungs-FET - oder bei einem schlechten Design (!) - muss sogar teilweise mit negativer Spannung am Gate gearbeitet werden, um eine vollständige Sperrung zu erreichen.<br />
Diese Umladung muss möglichst schnell erfolgen, um die Verluste im FET während der Umschaltphase zu minimieren. Dazu findet ein [[Mosfet-Übersicht#MOSFET-Treiber|MOSFET-Treiber]] Verwendung. Hier eine detaillierte Beschreibung zum [[Treiber]].<br />
<br />
Da die Gatekapazität nicht direkt im Datenblatt enthalten ist kann man sich mit der Eingangskapazität Ciss behelfen. Im Arbeitspunkt ist die Gatekapazität ungefähr 5x größer als der im Datenblatt für Ciss angegebene Wert. <br />
Daher berechnet sich die Treiberleistung wie folgt: <br />
<br />
:<math>P_\text{Treiber} = C \cdot U^2 \cdot f = 5 \cdot C_\text{íss} \cdot U_\text{Gate}^2 \cdot f_\text{schalt}</math><br />
<br />
1.Beispiel, kleine MOSFET-Steuerung mit niedriger Leistung und Frequenz.<br />
<br />
:<math>P_\text{treiber} = 5 \cdot 4{,}8\,\text{nF} \cdot 15\,\text{V}^2 \cdot 10\,\text{kHz} = 54\,\text{mW}</math><br />
<br />
2.Beispiel, sehr große MOSFET-Steuerung für Induktionsheizung mit sehr hoher Leistung und Frequenz.<br />
<br />
:<math>P_\text{treiber} = 5 \cdot 24\,\text{nF} \cdot 15\,\text{V}^2 \cdot 250\,\text{kHz} = 6{,}75\,\text{W}</math><br />
<br />
Aber Achtung, so ein MOSFET-Treiber hat auch einen Eigenverbrauch, der leicht zwischen 0,5 und 1 W liegen kann.<br />
<br />
Bei niedrigen PWM-Frequenzen kann man Logic Level MOSFETs auch direkt per CMOS-Ausgang ansteuern, z.B. mit einem [[AVR]], wie in diesem [http://www.mikrocontroller.net/topic/246449#2519459 Forumsbeitrag] zu sehen ist.<br />
<br />
== Low- und High-Side ==<br />
<br />
Definition LS- und HS:<br />
<br />
;Low-Side Schalter: Der FET schaltet eine Last gegen GND - auch als LS-Schalter bezeichnet.<br />
;High-Side Schalter: Der FET schaltet eine Last an die Versorgungsspannung – auch als HS-Schalter bezeichnet.<br />
<br />
Anregungen oder Fragen auch gerne per Email an [http://www.mikrocontroller.net/user/show/powerfreak Powerfreak]. Dieser Artikel kann dadurch regelmäßig erweitert und ggf. durch ein FAQ ergänzt werden.<br />
<br />
<br />
== SOA Diagramm ==<br />
<br />
SOA-Diagramm (engl. '''S'''afe '''O'''perating '''A'''rea, sicherer Arbeitsbereich) beschreibt die zulässige Verlustleistung eines Transistors in Anhängigkeit des Drainstroms (I_D), der Drain-Source Spannung (U_DS) und der Pulsbreite. Als Beispiel sei hier der BUZ 11 genannt. Im nachfolgenden Diagramm ist das SOA-Diagramm dargestellt. Wie ist es zu verstehen? Zunächst gibt es eine Grenze auf der linken Seite, die schräge, dunkelblaue Line. Diese wird durch den minimalen R_DS_ON festgelegt, hier wirkt der MOSFET wie ein ohmscher Widerstand. Mehr Strom kann bei einer bestimmten Spannung nicht fließen. Die zweite Grenzlinie ist ganz rechts die pinkfarbene Linie, sie stellt die maximale Sperrspannung des MOSFET dar. Die dritte Grenze ist der maximal zulässige Drainstrom, hier im Beispiel 120A, dargestellt durch die gelbe Linie. Die maximale Spannung zwischen Drain und Source sowie der Drainstrom sind abhängig von der Pulsbreite, mit welcher der MOSFET betrieben wird. Bei nur 2,5µs Pulsbreite (Rechteckimpuls) müssen die beiden Parameter sich innerhalb der Fläche bewegen, welche durch die dunkelblaue, gelbe und die pinkfarbene Line begrenzt wird. Im Extremfall dürfen 50V anliegen und 120A fließen, das sind satte 6kW Pulsleistung! Werden die Pulse breiter, so sinken die zulässigen Ströme und Spannungen, bei 1ms (dunkelblaue Linie bis zur braunen Linie, dann zur pinkfarbenen Linie) sind maximal noch 50V und 7A zulässig, also nur noch 350W. Die letzte Linie stellt den Fall für Gleichstrom (engl. '''D'''irect '''C'''urrent), also Dauerbelastung dar, hier sind bei 50V maximal 1,5A zulässig, was einer Dauerverlustleistung von 75W entspricht. MOSFETs, welche nur für Schaltbetrieb und nicht für [[#Linearbetrieb von MOSFETs | Linearbetrieb]] geeignet sind, haben keine Kennlinie für DC. Im normalen Schaltbetrieb liegt der Arbeitspunkt auf der linken Grenzlinie R_DS_ON_MIN. Nur im Linearbetrieb liegt der Arbeitspunkt innerhalb der Fläche, welche durch die Außenlinien begrenzt wird.<br />
<br />
[[bild: SOA-BUZ11.png | thumb | 300px| SOA-Diagramm]]<br />
<br />
Bei der Anwendung des Diagramms gilt es einiges zu beachten. Die Pulsleistungen sind nur zulässig, wenn der MOSFET vorher kalt ist, sprich ca. 25°C Sperrschichttemperatur hat. War er vorher schon heiß, reduziert sich die zulässige Belastung deutlich. Ebenso dürfen die Pulse nicht zu schnell wiederholt werden, denn dann ist der MOSFET noch vom vorherigen Puls aufgeheizt. Im Fall von DC sind 75W Verlustleistung auch eher ein theoretischer Wert, welcher real nur schwer erreicht werden kann, wenn der MOSFET auf einem sehr großen [[Kühlkörper]] optimal montiert ist. Praktisch liegen die erreichbaren Werte eher bei der Hälfte.<br />
<br />
(Anm. Eigentlich müsste für die R_DS_ON Grenzlinie R = U / I der minimale R_DS_ON rauskommen, hier ~40mOhm, es kommen aber ~80mOhm raus. Die Ursache dafür ist unklar, möglicherweise liegt hier ein Sicherheitsfaktor zu grunde).<br />
<br />
{{Clear}}<br />
<br />
== Linearbetrieb von MOSFETs ==<br />
<br />
Der Großteil der Anwendungen nutzt MOSFETs als Schalter, d.h. der MOSFET ist entweder voll gesperrt oder voll durchgesteuert. Dafür gelten auch all die Hinweise in diesem Artikel. In bestimmten Anwendungen werden MOSFETs aber auch im Linearbetrieb eingesetzt, z.B in linearen Endstufen für Audio, Video, elektronischen Lasten und Stromquellen. Hier muss man einiges beachten. Ein verbreiteter Irrtum besteht darin zu glauben, MOSFETs könne man im Linearbetrieb einfach parallel schalten, weil der positive Temperaturkoeffizient von <math>R_{DS(ON)}</math> eine Symmetrierung bewirkt, ähnlich den Emitterwiderständen bei parallelgeschalteten Bipolartransistoren. Das ist ''ausschließlich'' im Schaltbetrieb möglich, und daher falsch! Im Linearbetrieb spielt der Temperaturkoeffizient von <math>R_{DS(ON)}</math> keine Rolle, weil der MOSFET selten bis nie komplett durchgesteuert ist. Eben darum ist beim Linearbetrieb der minimale <math>R_{DS(ON)}</math> in den meisten Fällen unwichtig und man kann auch eher hochohmige, ältere MOSFETs verwenden, wie z.B. den BUZ11.<br />
<br />
Hier wirkt vielmehr der negative Temperaturkoeffizient (TK) der Thresholdspannung <math>U_{GS(thr)}</math>, vergleichbar dem negativen TK der Basis-Emitter-Spannung von Bipolartransistoren. D.h. mit steigender Temperatur und konstanter Gate-Source-Spannung steigt der Stromfluss der Drain-Source Strecke. In einer Parallelschaltung von MOSFETs würde dies bedeuten, dass der MOSFET mit dem geringfügig größeren Drainstrom (Fertigungstoleranzen) wärmer wird, was zu einem weiter steigenden Drainstrom und damit noch mehr Wärme führt. Damit ist die Schaltung thermisch instabil und würde zum Durchbrennen der MOSFETs führen, einer nach dem Anderen. <br />
<br />
Um das zu verhindern muss man relativ große Ausgleichswiderstände in die Source-Leitung der einzelnen MOSFETs schalten, um diese Drift zu kompensieren. Dadurch verschlechtert sich natürlich der Wirkungsgrad des Verstärkers. MOSFETs haben einen TK von typisch -5mV/K für <math>U_{GS(thr)}</math>, das ist mehr als das doppelte von Bipolartransistoren mit typisch -2mV/K, weshalb die Symmetrierungswiderstände mehr als doppelt so groß sein müssen. Weiterhin muss man beachten, dass die Toleranzen von <math>U_{GS(thr)}</math> sehr groß sind, im Bereich von Volt! Das kann man sinnvoll nicht mehr mit Gatewiderständen symmetrieren, hier muss man die MOSFETs ausmessen und Gruppen mit geringen Toleranzen in einer Schaltung verwenden (engl. matching). <br />
<br />
Eine andere Möglichkeit ist die getrennte Ansteuerung der einzelnen MOSFETs, das wird oft in elektronischen Lasten bzw. [[Konstantstromquelle#Konstantstromquelle mit Operationsverstärker und Transistor | Konstantstromquellen]] gemacht. Hier treten keine zusätzlichen Verluste auf und der Mehraufwand in der Ansteuerung ist meist unkritisch.<br />
<br />
Weiterhin muss man beachten, dass viele der heutigen HochleistungsMOSFETs intern eine Parallelschaltung vieler kleiner MOSFET-Zellen (z.B. sogenannte Trench-FET) sind, und somit oft für den Linearbetrieb ungeeignet sind. Denn auch dort können einzelne Zellen überhitzen und durchbrennen (Hot Spot). Ob ein MOSFET für den Linearbetrieb tauglich ist steht manchmal im Datenblatt, oft aber eher nicht, eben weil die meisten MOSFETs als Schalter entwickelt und gebaut sind. Typische Vertreter für Linearbetrieb findet man in der [[MOSFET-Übersicht]]. Ein wichtiges Indiz für Linearbetrieb ist eine Kurve für DC im [[#SOA_Diagramm | SOA-Diagramm]]. Meist geht es dort nur bis 10ms, DC fehlt, eben weil DC (engl. '''D'''irect '''C'''urrent = Gleichstrom = Linearbetrieb) nicht zulässig ist. Manchmal hat der Hersteller auch "vergessen", die Kennlinie für DC mit reinzuschreiben, wie z.B. bei [http://www.irf.com/product-info/hi-rel/alerts/fv5-p-09-01-A.pdf IRF], wie in diesem [http://www.mikrocontroller.net/topic/291760#3106758 Beitrag] zu erfahren ist.<br />
Ein recht gutes Indiz dafür, ob ein FET für den Linearbetrieb taugt, ist die Vorwärtssteilheit. Diese kennzeichnet die Abhängigkeit des Drainstromes von der Ansteuerung am Gate als <math>S = \Delta i_d/\Delta u_{gs}</math>. Moderne Trench-FET erreichen heute Steilheiten im dreistelligen Bereich und sind für Linearanwendungen völlig unbrauchbar. Zum Vergleich: Der BUZ11 kommt mit gerade einmal 4 bis 5 Siemens daher.<br />
<br />
In diesem Beitrag wird die DC-Linie im SOA-Diagramm noch genauer erklärt: [http://www.mikrocontroller.net/topic/319961#3473567 Re: MOSFET Linearbetrieb möglich?]<br />
<br />
<br />
== Siehe auch ==<br />
<br />
* [[Leistungselektronik]]<br />
* [[Mosfet-Übersicht]]<br />
* [[IGBT]]<br />
* [[TRIAC]]<br />
* [[Kühlkörper]] <br />
* [[Zwischenkreiskapazität]]<br />
* [[Treiber]]<br />
* [[Snippets#Wie_schlie.C3.9Fe_ich_einen_MOSFET_an_einen_Mikrocontroller_an.3F|Wie schließe ich einen Mosfet an einen Mikrocontroller an?]]<br />
* [http://www.mikrocontroller.net/articles/H-Br%C3%BCcken_%C3%9Cbersicht Übersicht H-Brücken]<br />
* [http://www.mikrocontroller.net/topic/168218#1609684 Forumsbeitrag]: MOSFETs im Linearbetrieb<br />
* [http://www.mikrocontroller.net/topic/186785#new Forumsbeitrag]: nochmal MOSFETs im Linearbetrieb<br />
* [http://www.mikrocontroller.net/topic/319961#3473567 Forumsbeitrag]: sehr ausführlicher Forumsbeitrag über MOSFETs im Linearbetrieb. Berücksichtigt auch den Spirito-Effekt.<br />
* [http://www.mikrocontroller.net/topic/143324#new Forumsbeitrag]: Über eine elektronische Last, sehr lang<br />
*[http://www.mikrocontroller.net/topic/246449#2519459 Forumsbeitrag]: Logic Level MOSFETs direkt mit einem [[AVR]] treiben.<br />
* [http://www.mikrocontroller.net/topic/267254#2787855 Forumsbeitrag]: MOSFETs im Linearbetrieb, Laborerfahrungen<br />
* [http://www.mikrocontroller.net/topic/267254#2787945 Forumsbeitrag]: MOSFETs für Linearbetrieb<br />
* [https://www.mikrocontroller.net/topic/269642?goto=2820617#2820617 Forumsbeitrag]: Verpol- und Überspannungsschutz mit MOSFETs<br />
* [https://www.mikrocontroller.net/topic/425414#4981611 Forumsbeitrag]: Linearbetrieb von MOSFETs<br />
<br />
== Weblinks ==<br />
<br />
* [http://www.elektronikinfo.de/strom/feldeffekttransistoren.htm Feldeffekttransistoren bei elektronikinfo.de]<br />
* [http://www.elektronik-kompendium.de/sites/bau/0207011.htm FET im ELKO]<br />
* [http://www.elektronik-kompendium.de/sites/bau/0510161.htm MOSFET im ELKO]<br />
* [http://www.sprut.de/electronic/switch/nkanal/nkanal.html MOSFET bei sprut.de]<br />
* [http://sound.westhost.com/articles/hexfet.htm#51 MOSFETs in Audioendstufen, engl.]<br />
* [http://irf.custhelp.com/cgi-bin/irf.cfg/php/enduser/std_adp.php?p_faqid=214&p_created=1019728945&p_sid=pt9ITiCj&p_accessibility=0&p_redirect=&p_lva=&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9MTQsMTQmcF9wcm9kcz0mcF9jYXRzPSZwX3B2PSZwX2N2PSZwX3BhZ2U9MSZwX3NlYXJjaF90ZXh0PWxpbmVhcg**&p_li=&p_topview=1 FAQ Answer ID 214 bei IRF zum Linearbetrieb]<br />
* [http://www.nxp.com/documents/application_note/AN11158.pdf AN11158 - Understanding power MOSFET data sheet parameters] von NXP (PDF)<br />
* [https://assets.nexperia.com/documents/technical-note/TN00008.pdf TN00008 - Power MOSFET frequently asked questions and answers] von nexperia (PDF)<br />
* [http://www.infineon.com/dgdl/Infineon+-+Application+Note+-+PowerMOSFETs+-+OptiMOS%E2%84%A2+-+Linear+Mode+Operation+and+SOA+Power+MOSFETs.pdf?fileId=db3a30433e30e4bf013e3646e9381200 AN: Linear Mode Operation andSafe Operating Diagram of Power-MOSFETs] von Infineon (PDF)<br />
* [http://www.ixys.com/Documents/Articles/Article_Linear_Power_MOSFETs.pdf MOSFETs Withstand Stress of Linear-Mode Operation] Neuentwickelte MOSFETs für Linearbetrieb (PDF)<br />
<br />
[[Kategorie:Bauteile]] [[Kategorie:Leistungselektronik]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=Forth&diff=107022Forth2024-07-16T16:15:27Z<p>Heha: Vor- und Nachteile</p>
<hr />
<div>'''Forth''' ist eine stack-orientierte Programmiersprache, die von Chuck Moore Ende der 1960er zur Steuerung von astronomischen Radio-Teleskopen entwickelt und in den 1970ern kommerzialisiert wurde. Forth-Systeme lassen sich für praktisch jeden Mikrocontroller mit einer Mindestmenge an RAM erstellen und es gibt Implementierungen in Hardware.<br />
<br />
Forth-Programme bestehen üblicherweise aus vielen kurzen Unterprogrammen (Forth-Worte), was gut geschriebene Programme sehr übersichtlich macht. Weil Parameter über einen separaten Daten-Stack übergeben werden, beeinträchtigt diese Programmierweise die Ausführungsgeschwindigkeit nicht wesentlich.<br />
<br />
Forth-Derivate findet man an vielen Stellen, von HP-Taschenrechnern bis zu OpenFirmware. Chip-Implementierungen (die also Forth als Maschinensprache verstehen und etwa beide Stacks in Hardware implementieren) gelten als sehr effektiv, sowohl im Verhältnis von erzielbarer Rechenleistung und Anzahl der Transistoren, als auch bei Energieverbrauch oder bei Context-Wechsel.<br />
<br />
Der Grundumfang von Forth, samt Interpreter/Compiler haben benötigt in der Regel nur wenige kByte Code. Da die Sprache ihre eigene Erweiterung unterstützt werden dennoch auch umfangreiche Projekte darin realisiert. Es heißt, dass erfahrene Forth-Programmierer innerhalb eines Projektes aus Forth eine auf das Problem zugeschnittene Sprache schaffen, so dass Sprache und Anwendung nicht mehr direkt unterscheidbar sind. Dies hat in der Vergangenheit oft zu Akzeptanzproblemen geführt.<br />
<br />
Es wird oft vermutet, dass einer weiteren Verbreitung von Forth vor allem die späte Standardisierung und die Hardwareabhängigkeit des Codes im Wege standen. Dies mag bei der Verwendung von Forth als allgemeine Programmiersprache für Anwendungen zutreffen. Bei Embedded-Software spielt die Portierbarkeit von Code gegenüber dem Einsatz geeigneter Abstraktionen jedoch eine eher untergeordnete Rolle.<br />
<br />
Bei modernen Forth-Systemen für Mikrocontroller ist die Einstiegshürde eher niedriger als etwa bei "C", da Programme stufenweise aufgebaut und interaktiv getestet werden können. <br />
<br />
Die besonderen Reize von Forth für die Programmierung von Mikrocontrollern liegen:<br />
<br />
# in der Kompaktheit des Codes (die Wiederverwendung von kleinsten Codesegmenten kann man in anderen Hochsprachen aus Gründen der Übersichtlichkeit und der Performance nicht realisieren)<br />
# in der Bandbreite von hardware-nahen Operationen bis zu komplexen Aufgaben<br />
# in der Interaktivität: über eine serielle Verbindung mit dem Controller kann man direkt den Interpreter auf dem µC nutzen, um direkte Hardwarezugriffe zu steuern oder Programmteile zu testen; es entfällt der Umweg über Debugcode->Compilieren->Flashen->Testen<br />
<br />
Den Vorteil der Interaktivität ist bei viele µC-Implementierungen von Forth eingeschränkt, da sie die Compilierung in den Entwickler-PC verlagern; dabei sinkt zwar die Codegröße (Befehlsnamen etc. müssen nicht mehr im Flash stehen), aber es lässt sich nicht mehr interaktiv debuggen.<br />
<br />
Forth unterscheidet prinzipiell nicht zwischen Programm und Daten, was bei Implementierungen auf Prozessoren mit [[Harvard-Architektur]] wie AVR zunächst hinderlich ist. Durch die Verwendung eines "innerer Interpreters" lassen sich aber auch diese Systeme mit Forth betreiben. <br />
<br />
== Vorteile ==<br />
* Sehr kleiner Interpreter/Compiler, der sogar auf AVR laufen kann. Beste Lösung für einen (Kommadozeilen-)Interpreter/Compiler auf der Mikrocontroller-Zielplattform.<br />
* Forth-Denkschema „verbietet“ Gleitkommazahlen und baut auf Ganzzahlen, ggf. mit Festkomma. Assemblernaher Ansatz, ideal für Controller ohne eingebaute Gleitkomma-Hardware<br />
* Umformulierung von Infix-Notation in UPN zur Berechnung ist gut zum Verstehen des Compilerbaus — und hält den Forth-Interpreter/Compiler klein<br />
<br />
== Nachteile ==<br />
* Gewöhnungsbedürftige Syntax<br />
* Fixierung des Ur-Forth auf Systeme mit externem Massenspeicher in Blöcken — ein heutzutage ausgestorbenes Denkschema, Dateien sind, wenn überhaupt vorhanden, ''Array of Byte''<br />
* Fixierung des Ur-Forth auf 16-Bit-Prozessoren — sind heutzutage im Mikrocontrollerbereich nahezu ausgestorben, und es dominieren 8 und 32 Bit.<br />
* Fixierung des Ur-Forth auf Von-Neumann-Systeme mit durchgehend RAM — Meistens haben Mikrocontroller viel zu wenig RAM, dafür ausreichend ROM (Flash).<br />
* Den in (Ur-)Forth eingebauten Texteditor will keiner ernsthaft noch verwenden — Toter Code.<br />
* Für Zeichenkettenverarbeitung ist Forth nicht gerade gemacht.<br />
<br />
== Weblinks ==<br />
<br />
* Weitere Informationen zur Sprache Forth findet man auf [http://de.wikipedia.org/wiki/Forth_(Programmiersprache) Wikipedia]<br />
* [http://www.forth-ev.de/ Forth-Gesellschaft e.V.] <br />
<br />
* ARM<br />
** [http://pygmy.utoh.org/riscy/ Riscy Pygness] - Pygmy Forth for the [[ARM]]<br />
** [http://www.forth-ev.de/article.php/20080312083818313 hForth-IAR Port of hForth] für AT91SAM7<br />
** [http://mecrisp.sourceforge.net/ Mecrisp-Stellaris]<br />
** [http://www.forth-ev.de/filemgmt/singlefile.php?lid=602 ARM Sonderheft] des Forth-Magazins ''Vierte Dimension'' (44 Seiten)<br />
<br />
* AVR<br />
** [http://claymore.engineer.gvsu.edu/%7Esteriana/Software/pfavr/index.html PFAVR] - eine ANS Forth Anpassung für [[AVR]] (req.: min. 13K words FLASH and 32Kbytes external RAM)<br />
** [http://krue.net/avrforth/ avrforth] von Daniel Kruszyna<br />
** [http://amforth.sourceforge.net amforth] Forth für [[AVR]] Atmega µC (req: nur der Mikrocontroller)<br />
** [http://www.mikrocontroller.net/topic/94193 Forth-Computer mit ATMega 32 und Videoausgabe] - Forumsbeitrag von Christian Berger<br />
** [http://www.forth-ev.de/filemgmt/singlefile.php?lid=134 Vierte Dimension Sonderheft AVR], 2007<br />
** [http://www.forth-ev.de/article.php/20110423154127859 Neues von amForth (Erich Waelde)]. Video und Folien von der Forth Tagung 2011 in Goslar<br />
** [https://gitlab.com/jjonethal/eforth328 eForth328], eForth für ATMega328 von Dr.C.H. Ting v2.21 mit Dokumentation, 2011 <br />
<br />
* AVR und PIC:<br />
** [http://flashforth.com/ FlashForth] - ein Forth für PIC18, PIC24/30/33, AVR Atmega<br />
<br />
* Arduni Yún & Raspberry Pi<br />
** [http://thebeez.home.xs4all.nl/4tH/ 4th] - ein Forth-Compiler für viele Systeme<br />
<br />
* MSP430<br />
** [http://www.camelforth.com/page.php?8 CamelForth/430 ], ein ANS Forth für TI [[MSP430]]<br />
** [http://mecrisp.sourceforge.net/ Mecrisp MSP430 Forth]<br />
** [https://gitlab.com/Jean-Michel/FastForthForMSP430fr5xxx Fast Forth] für MSP430FR5xxx mit SD CARD LOAD, READ and WRITE<br />
<br />
* R8C<br />
** Anpassung von [http://www.jwdt.com/~paysan/gforth.html Gforth] EC für [[R8C]]<br />
<br />
* STM8<br />
** [http://www.forth.org/svfig/kk/07-2010.html STM8EF eForth für STM8S Discovery] Demo C.H.Ting SVFIG Meeting, July 2010<br />
** [https://github.com/TG9541/stm8ef STM8 eForth für die STM8 Familie] mit Flash, Multitasking und Erweiterungen, s. [https://wiki.forth-ev.de/lib/exe/fetch.php/events:stm8_eforth._ein_semi-tethered_forth.pdf Vortrag Forth-eV Tagung 2018]<br />
<br />
* 1802, 6809, 8051, 8052/C8051F, 8086, Z80<br />
** [http://www.camelforth.com CamelForth] <br />
<br />
* ARM, RISC-V, Motorola 68000, PDP-11 und asm.js<br />
** [https://github.com/larsbrinkhoff/lbForth lbForth] Compiler, Interpreter und Meta-Compiler der Cross-Compilierung auch für 6502, 8051, AVR, Cortex-M, MSP430, PDP-8, PIC und STM8 unterstützt<br />
<br />
[[Category:Programmiersprachen]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=Transistor&diff=107012Transistor2024-07-11T10:43:33Z<p>Heha: Triac oder Thyristor ?</p>
<hr />
<div>Kunstwort aus "transfer resistor", was etwa so viel bedeutet wie "übertragener [[Widerstand]]".<br />
<br />
In den 1950-ern als praktische Anwendung des [[Halbleiter]]-Effekts erfundenes "solid state" Schalt- und Verstärkerelement, welches sehr klein ist, ohne bewegte Teile auskommt (anders als ein klassisches Relais) und keine energiefressende Heizung benötigt (anders als eine Röhre).<br />
<br />
Vom "bipolaren Transistor" (PNP, NPN) weiterentwickelt zum "Feldeffekt-Transistor" ([[FET]]), der heute - gefertigt mit einem preiswerten Verfahren unter Verwendung von Metall-Oxid-Schichten (MOS) - ein wesentliches Element integrierter Schaltkreise (ICs, integrated circuits) darstellt, und damit natürlich auch von [[Mikrocontroller]]n, um die es in diesem Wiki hauptsächlich geht (bzw. gehen sollte).<br />
<br />
== Schaltzeichen ==<br />
[https://electronicsclub.info/images/transbce.gif]<br />
<br />
* E: Emitter<br />
* B: Basis<br />
* C: Collector <br />
<br />
<br />
In ASCII Schaltplänen sehen Transistoren so aus:<br />
<pre> <br />
|> |/<br />
NPN |> oder -| oder -|<br />
|\ |><br />
<br />
|< |/<br />
PNP: |< oder -| oder -|<br />
|\ |<<br />
</pre><br />
<br />
Um zu erkennen, ob ein NPN oder PNP Transistor im Schaltplan verwendet wird, gibt es Eselsbrücken:<br />
*Für Dichter: '''Tut der Pfeil der Basis weh, handelt's sich um PNP.'''<br />
*Für Praktiker: '''PNP heisst "Pfeil Nach Platte"'''.<br />
*Mit Dialekt: '''NPN "'naus, Pfeil, 'naus"'''.<br />
*..und für Gleichberechtigungsverfechter: '''NPN means "Not Pointing iN"'''.<br />
<br />
<br />
<br />
JFET: [[Bild:Transistor_JFET.png]]<br />
<br />
MOSFET: [[Bild:Transistor_MOSFET.png]]<br />
<br />
* S: Source<br />
* G: Gate<br />
* D: Drain<br />
<br />
Eigentlich haben MOSFETs noch einen vierten Anschluss namens Bulk. Der ist aber nur bei Spezialtypen als Pin herausgeführt. Im Normalfall kann man ihn vergessen, da er nicht gesondert beschaltet werden muss, er ist praktisch und auch im Symbol mit Source verbunden.<br />
<br />
'''Achtung:''' Die NPN/PNP Eselsbrücken funktionieren bei FETs nicht, denn bei einem P-Kanal FET zeigt der Pfeil weg vom FET!<br />
Ein Bipolartransistor, im Englischen als bipolar junction transistor (BJT) bezeichnet, ist ein Transistor, bei dem Ladungsträger – negativ geladene Elektronen und positiv geladene Defektelektronen – zum Stromtransport durch den Bipolartransistor beitragen. Der BJT wird mittels eines elektrischen Stroms gesteuert und wird zum Schalten und Verstärken von Signalen ohne mechanisch bewegte Teile eingesetzt.<br />
<br />
Bipolare Leistungstransistoren sind für das Schalten und Verstärken von Signalen höherer Stromstärken und Spannungen ausgelegt.<br />
<br />
== Typbezeichnungen == <br />
<br />
Neben den Typbezeichnungen wie 2Nxxxx, TIPxxx, MJxxx, MJExx gibt es noch die in Europa geläufigere Kennzeichnung bestehend aus zwei Buchstaben und drei Ziffern. Die diversen Kennzeichnungsmöglichkeiten sind in einem eigenen Artikel ([[Kennzeichnung von Halbleitern]]) zusammengefasst.<br />
<br />
== Kenndaten/Parameter ==<br />
<br />
Im [http://www.mikrocontroller.net/topic/197676#1938546 Beitrag: Transistorparameter Erklärung] sind Links zu Erläuterungen spezieller Kürzel.<br />
<br />
== Transistor Grundschaltungen ==<br />
<br />
Generell gilt, dass Strom vom Kollektor zum Emitter nur dann fließen kann, wenn die Basis positiver (NPN) bzw. negativer (PNP) wird als der Emitter. Dabei darf die Basis nicht direkt mit Vcc (NPN) oder GND (PNP) verbunden werden, da der Basisstrom sonst zu gross wird. Es muss jeweils ein geeigneter Basiswiderstand (R_Basis) gewählt werden.<br />
<br />
'''Weitere Links:'''<br />
* Artikel [[Basiswiderstand]]<br />
* [http://www.elektronik-kompendium.de/sites/slt/0203111.htm Transistor Grundschaltungen im ElKo]<br />
* [http://www.roboternetz.de/wissen/index.php/Transistor Transistor bei RoboterNetz.de]<br />
<br />
Es gibt drei Grundschaltungen. Der Name beschreibt den Anschluss, welcher sich auf einem festen Potential (Spannung) befindet. Die beiden anderen Anschlüsse haben bedingt durch die Schaltung ein veränderliches Potential.<br />
<br />
=== Kollektorschaltung (Emitterfolger)===<br />
<br />
'''Anwendung:'''<br />
* Impedanzwandler<br />
* Darlington-Schaltung<br />
* Schalter<br />
<br />
'''Eigenschaften:'''<br />
* Keine Phasendrehung<br />
* Hohe Stromverstärkung<br />
* Keine Spannungsverstärkung<br />
<br />
'''Beispiel: Transistor als Schalter'''<br />
<br />
* NPN: Kollektor mit Vcc verbinden, Last an Emitter<br />
* PNP: Kollektor mit GND verbinden, Last an Emitter<br />
<br />
In diesem Fall regelt der Transistor die Spannungen am Emitter, daher wird die Last am Emitter angeschlossen. Die Spannung am Emitter entspricht immer der an der Basis minus 0,6V, sie folgt der Basisspannung, deswegen auch der Name Emitterfolger. Daher ist diese Schaltung nicht geeignet, um 12V mit 5V zu schalten. <br />
<br />
{|<br />
|-<br />
| [[Bild:NPN_Collector.gif | framed | center | NPN Transistor in Kollektorschaltung]] <br />
|| [[Bild:PNP_Collector.gif | framed | center | PNP Transistor in Kollektorschaltung]] <br />
|}<br />
* NPN: Wird <math>R_{Poti}</math> (Spannungsteiler) erhöht, '''steigt''' die Spannung <math>U_{Last}</math> letztlich bis auf VCC-0,6V (Basis-Emitter-Übergang).<br />
* PNP: Wird <math>R_{Poti}</math> (Spannungsteiler) erhöht, '''sinkt''' Spannung an <math>U_{Last}</math> letztlich bis auf 0,6V (Basis-Emitter-Übergang).<br />
<br />
'''Weitere Links:'''<br />
* [http://www.elektronik-kompendium.de/sites/slt/0204133.htm Kollektorschaltung im ElKo]<br />
<br />
=== Emitterschaltung ===<br />
<br />
Die Emitterschaltung bietet hohe Spannungs- und Stromverstärkung.<br />
<br />
'''Anwendung:'''<br />
* NF- und HF-Verstärker<br />
* Leistungsverstärker<br />
* Transistor als Schalter<br />
<br />
'''Eigenschaften:'''<br />
* Phasendrehung 180°<br />
* Hohe Spannungsverstärkung<br />
* Hohe Stromverstärkung<br />
<br />
<br />
'''Beispiel: Transistor als Schalter'''<br />
<br />
Die Last liegt am Kollektor. Der Strom durch den Schalter oder an U_Schalt steuert den Strom zwischen Kollektor und Emitter. Wird der Schalter geschlossen, fließt ein Strom.<br />
<br />
[[Bild:NPN_Schalter.gif | framed | center | NPN Transistor als Schalter]]<br />
<pre><br />
___ ___<br />
Vcc/+ o-----------------------+ Vcc/+ o-----------------------+<br />
| |<br />
___ |< U_schalt (-) ___ |< PNP <br />
+------|___|---| PNP o------------|___|----|<br />
| R_Basis |\ R_Basis |\<br />
Schalter \ | |<br />
| ___ | ___ |<br />
GND/- o------+------|___|-----+ GND/- o-------------|___|-----+<br />
R_Last R_Last <br />
<br />
</pre><br />
<br />
<br />
'''Weitere Links:'''<br />
* [http://www.elektronik-kompendium.de/sites/slt/0204302.htm Emitterschaltung im ElKo]<br />
<br />
=== Basisschaltung ===<br />
<br />
Die Basisschaltung findet sich vor allem in Eingangsstufen in der HF-Technik. Im Schaltbetrieb wird sie praktisch nur zur [[Pegelwandler#STEP-UP: 5V -> 9..15V | Pegelwandlung]] für nachfolgende Stufen verwendet.<br />
<br />
'''Eigenschaften:'''<br />
* Geringe Eingangsimpedanz<br />
* Keine Phasenverschiebung<br />
* Hohe Bandbreite<br />
<br />
'''Weitere Links:'''<br />
* [http://www.elektronik-kompendium.de/sites/slt/0205081.htm Basisschaltung im ElKo<br />
<br />
== FAQ aus dem Forum ==<br />
<br />
=== PNP/NPN als Schalter, wohin mit der Last? === <br />
Für viele einfache Anwendungen kann man sich merken: '''Bei Schaltanwendungen darf der Basisstrom nicht durch die Last fließen''' (… wenn die zu schaltende Spannung höher ist als die Steuerspannung). Normalerweise kommt dabei die Emitterschaltung zum Einsatz, die Last kommt also an den Kollektor.<br />
<br />
<pre><br />
Ucc o─────────────┐ Ucc o───────────┐<br />
│ │<br />
┏┷┓ An: GND ___ ┃<<br />
┃ ┃ R_Last o───┤___├──┨ PNP<br />
┗┯┛ Aus: Ucc ┃\<br />
│ │<br />
An: Ucc ___ ┃/ ┏┷┓<br />
o───┤___├────┨ NPN ┃ ┃ R_Last<br />
Aus: GND ┃> ┗┯┛<br />
│ │<br />
GND o─────────────┘ GND o───────────┘<br />
</pre><br />
<br />
Siehe [[Basiswiderstand]] zur Berechnung des notwendigen Basiswiderstandes bei gegebener Last R_Last für einen Transistor als Schalter.<br />
<br />
Siehe auch Threads im Forum: <br />
* http://www.mikrocontroller.net/topic/58567 <br />
* http://www.mikrocontroller.net/topic/119841<br />
* oder im [http://www.elektronik-kompendium.de/sites/slt/0208031.htm Elektronik-Kompendium-Forum]<br />
<br />
Ist die zu schaltende Spannung '''genauso hoch''' wie die Steuerspannung darf die Last an den Emitter, und der Basiswiderstand entfällt. Der Transistor arbeitet als ''Impedanzwandler'' und steigert die Treiberfähigkeit des Mikrocontroller-Ausgangs in den Ampere-Bereich. Dieser Trick funktioniert '''nur''' mit Bipolartransistoren.<br />
<br />
Ist die effektive Invertierung des Schaltzustandes im oben angegebenen Bild lästig '''und''' der Strom geringer als der Ausgangsstrom, kann man den Transistor am Emitter steuern. Eine solche Schaltung funktioniert noch besser mit (Logik-Level-)MOSFETs und stellt eine einfache Kopplung zwischen Systemen mit unterschiedlicher Betriebsspannung (bspw. 1,8 V und 3,3 V) her. MOSFETs werden dazu am Source-Pin gesteuert, während das Gate an der „gegenüberliegenden“ Speisespannung „fixiert“ wird.<br />
<br />
=== Wie kann ich mit 5V vom Mikrocontroller 12V und mehr schalten? === <br />
Schau mal hier:<br />
* Wikiartikel [[Pegelwandler]]<br />
* [http://www.elektronik-kompendium.de/sites/praxis/bausatz_pegelwandler-mit-transistoren.htm Pegelwandler im ElKo]<br />
* [http://dl6gl.de/grundlagen/schalten-mit-transistoren schalten-mit-transistoren]<br />
<br />
oder in diesen Threads:<br />
*[http://www.mikrocontroller.net/topic/17899 Transistor als Schalter]<br />
*[http://www.mikrocontroller.net/topic/14437 Vcc schalten mit MOSFET]<br />
*[http://www.mikrocontroller.net/topic/29830 Schalten mit PNP-Transistor]<br />
*[http://www.mikrocontroller.net/topic/104027 Transistorschalter für Versorgungsspannung]<br />
*[http://www.mikrocontroller.net/topic/104951#921417 7-50V strombegrenzt schalten]<br />
*[http://www.mikrocontroller.net/topic/103116#900247 P-Kanal MOSFET ansteuern]<br />
*[https://www.mikrocontroller.net/topic/383039#4367479 5V/15mA mit 3,3V schalten]<br />
*[https://www.mikrocontroller.net/topic/401317#4638354 High Side Treiber mit Ladungspumpe]<br />
*[https://www.mikrocontroller.net/topic/347885?goto=3855574#3855574 minus -12V mit 3,3V schalten]<br />
*[https://www.mikrocontroller.net/topic/516373?goto=6650986#6650986 Kurzschlußfester Schalter für VCC]<br />
<br />
Bei der Kollektor-Schaltung entspricht die Spannung am Emitter immer der an der Basis, daher ist sie nur bedingt geeignet. Zum Schalten können die folgenden Emitter-Schaltungen verwendet werden. Achtung: In der zweiten davon arbeitet T1 in Basisschaltung.<br />
<br />
Schalten gegen GND<br />
<br />
<pre><br />
+12V o------------------------+<br />
|<br />
.-. <br />
( X ) <br />
'-'<br />
|<br />
___ |/ T1,NPN <br />
uC PIN o---|___|-----| BC547 <br />
R2,4K7 |><br />
|<br />
GND o---------o--------------+<br />
</pre><br />
<br />
<br />
Schalten gegen +12V<br />
<br />
<pre><br />
+12V o--------------+----------------------+<br />
| |<br />
| ____ |< T2, PNP<br />
+--|____|----+--------| BC557<br />
R1,4K7 | |\<br />
|/T1,NPN |<br />
Vcc/+5V o--------------| BC547 |<br />
|> |<br />
___ | .-. <br />
uC PIN o-----|___|------+ ( X ) <br />
R2,4K7 '-'<br />
|<br />
GND o----------o--------------------------+<br />
</pre><br />
<br />
=== Transistor an µC ohne Vorwiderstand === <br />
<br />
Normalerweise sind IO Pins vom µC nicht in der Lage, große Ströme zu treiben, beim AVR maximal ~20mA. Für einen kleinen Transistor ist das immer noch zu viel und es wäre auch Stromverschwendung.<br />
<br />
Deshalb kann man den IO-Pin des AVRs einfach als Tristate Eingang einstellen (Portpin als Eingang und Pullup deaktivieren), damit kein Basisstrom fließt.<br />
<br />
Aktiviert man nun den internen Pullup-Widerstand des AVRs, agiert dieser als Basisvorwiderstand, und es fließt nur ein geringer Basisstrom (die Pullups eines AVRs liegen irgendwo bei 50k bis 100k Ohm - siehe Datenblatt).<br />
<br />
Nur sollte man bei kleinen Transistoren aufpassen, dass man den Portpin in der Software nie als aktiven Ausgang schaltet. <br />
<br />
Wenn der verwendete µC zuschaltbare Pulldown-Widerstände an seinen Pins besitzt, kann man das gleiche auch mit einem PNP-Transistor machen (natürlich nur den Pulldown aktivieren).<br />
<br />
Eine Anwendung wären z.&nbsp;B. Nixie-Röhren-Kathodentreiber (geringe Stromverstärkung nötig).<br />
<br />
=== Wann bipolare (NPN/PNP) und wann FETs (insbesonders, wenn LEDs im Spiel sind)?=== <br />
Oft sind bipolare Transistoren (NPN/PNP) schon ausreichend, vor allem wenn "normale" LEDs (20mA) verwendet werden. FETs sind u.a. dann gut, wenn mit geringen Eingangsströmen hohe Ausgangsströme (über 300 mA) geschaltet werden sollen, also bei den Power-LEDs (Luxeon...).<br />
<br />
Ein Grenzfall: 500mA/5V schalten, siehe http://www.mikrocontroller.net/topic/62327.<br />
<br />
=== Wieso gehen bei einer Multiplex-Anzeige mit Schieberegister 74HC595 und (Darlington-)Transistor als Zeilentreiber die LED nicht ganz aus? ===<br />
Das liegt an der '''Miller-Kapazität''' des übersteuerten (Darlington-)Transistors. Der braucht erst mal einige 10µs, um zu sperren. Du mußt also erstmal beide Zeilen ausschalten, dann etwas warten und dann die nächste Zeile an. Oder Du ersetzt die Darlington durch P-FETs. [http://www.mikrocontroller.net/topic/132545]<br />
<br />
=== Wie steuert man ein Relais? ===<br />
Normalerweise verwendet man zur Ansteuerung von Relais NPN-Transistoren in Emitterschaltung. Freilaufdiode nicht vergessen! <br />
<br />
Siehe auch:<br />
* [[Relais mit Logik ansteuern]]<br />
* [http://www.mikrocontroller.net/attachment/22023/Relaisanteuerung.png Schaltbilder aus dem Forum]<br />
<br />
=== Was ist die Spannung <math>U_{BE\_sat}</math> (lt. Datenblatt max. 1,2V)? ===<br />
Bekanntlich verhält sich die Basis-Emitter Strecke eines Transistors wie eine Diode und <math>U_{BE\_sat}</math> ist die bei maximal zulässigem Basisstrom anliegende Vorwärtsspannung.<br />
<br />
=== Was bewirkt ein Kondensator (100µF-1nF) parallel zur Basis-Emitter-Strecke nach Masse? === <br />
Er wirkt mit dem Basisvorwiderstand als RC-Tiefpass. Damit wird der Transistor eigentlich nicht mehr als Schalter, sondern als Linearregler betrieben. Manche Verstärker-Schaltungen sind, gerade bei hohen Lasten, sehr schwingfreudig. Deswegen ist bei PWM so ein C nicht sinnvoll.<br />
<br />
=== Gibt es einen IC, der wie mehrere Transistoren funktioniert? ===<br />
<br />
Gibt es! Beispielsweise der '''ULN2803''' ist ein 8-fach Darlington Transistor Array mit [[Ausgangsstufen_Logik-ICs#Open_Collector|Open-Collector Ausgang]]. Und sogar die Freilaufdioden sind schon drin.<br />
Damit lässt sich z.&nbsp;B. ein Leistungstreiber zur Ansteuerung von Schrittmotoren, Relais und anderen induktiven Lasten aufbauen.<br />
<br />
=== Gibt es ein Transistor-Array wie ULN28xx, das gegen Vcc schaltet? ===<br />
<br />
Such mal nach UDN29xx, z.&nbsp;B. UDN2981, UDN2987 ...<br />
<br />
Allegro hat zwischenzeitlich seinen Source-Treiber umbenannt. Die Bauteile heißen jetzt A2981, A2982 usw... Die Datenblätter sind identisch geblieben.<br />
<br />
Nachteil eines Darlington-Source-Treibers ist die hohe Sättigungsspannung (VceSat) von typisch 1,2 V. Die Eingangsspannung sollte dementsprechend höher ausgelegt werden oder gleich ein Source-Treiber mit MOSFET-Transistoren gewählt werden (z.B. Infineon ProFETs).<br />
<br />
=== Wann setzt man einen MOSFET, Bipolartransistor, IGBT oder Thyristor ein? ===<br />
siehe [[Leistungselektronik]]<br />
<br />
Die Summe allen Übels ist konstant. Man muss wissen, welches Bauteil sich wofür besonders eignet.<br />
<br />
====[[FET | MOSFET]]====<br />
<br />
Vorteile<br />
* Bei niedrigen Spannungen <100V sehr gut geeignet, <200V gut geeignet, sehr geringe R_DS-ON Widerstände möglich (einstelliger mOhm-Bereich)<br />
* Hohe Schaltgeschwindigkeiten möglich<br />
* Geringe An- und Ausschaltverluste<br />
* Statisch praktisch leistungslos steuerbar<br />
* Bodydiode kann als Freilaufdiode in H-Brücken verwendet werden<br />
* 2. Durchbruch bei Überschreiten der max. Drain-Source Sperrspannung zerstört das Bauteil nicht, wenn der Strom sowie die Energie begrenzt werden. (Verhalten wie [[Diode | Z-Diode]])<br />
<br />
Nachteile<br />
*Antiparallele Diode (Bodydiode) ist in nahezu allen MOSFETs unvermeidlich, daduch Sperren nur in einer Polarität möglich, Stromfluss über den MOSFET aber in beiden Richtungen möglich (Inversbetrieb, Synchrongleichrichter)<br />
* Bei Sperrspannungen >100V deutlich steigende Einschaltwiderstände (R_DS-ON)<br />
* Schnelles Umschalten erfordert hohe Lade-und Entladeströme ([[MOSFET-Übersicht#Mosfet-Treiber|MOSFET-Treiber]])<br />
* Leitverluste quadratisch proportional zum Strom, Pv = I²*R_DS-ON<br />
<br />
====[[Transistor | Bipolartransistor]]====<br />
<br />
Vorteile<br />
* Hohe Spannungsfestigkeiten möglich, bis zu 2000V<br />
* Sehr hohe Schaltgeschwindigkeiten möglich<br />
* Leitverluste etwa linear proportional zum Strom und Kollektor-Emitter-Sättigungsspannung, Pv = I * Uce-sat, U_CEC-sat typ 0,1...2.5 V<br />
<br />
Nachteile<br />
* Stromgesteuert, damit wird immer eine gewisse Ansteuerleistung benötigt<br />
* Bei grossen Kollektorströmen nimmt die Stromverstärkung deutlich ab, dann wird ein großer Basisstrom benötigt<br />
* 2. Durchbruch bei Überschreiten der max. Kollektor-Emitter Sperrspannung zerstört das Bauteil<br />
<br />
====[[IGBT]]====<br />
<br />
Vorteile<br />
* Hohe Spannungsfestigkeiten möglich, bis zu 6600V, in üblichen Bauformen bis ca 1700V gut verfügbar<br />
* Statisch praktisch leistungslos steuerbar<br />
* Mit oder ohne antiparallele Diode zur Kollektor-Emitter-Strecke verfügbar<br />
* Leitverluste linear proportional zum Strom und Kollektor-Emitter-Sättigungsspannung, Pv = I * Uce-sat, U_CE-sat typ. 2V<br />
<br />
Nachteile<br />
* Nur mäßige Schaltfrequenzen möglich (typ. <30..50kHz)<br />
* Schnelles Umschalten erfordert hohe Lade-und Entladeströme ([[MOSFET-Übersicht#Mosfet-Treiber|MOSFET-Treiber]])<br />
* 2. Durchbruch bei Überschreiten der max. Kollektor-Emitter Sperrspannung zerstört das Bauteil<br />
<br />
====[[TRIAC|Triac]] / Thyristor====<br />
<br />
Vorteile:<br />
* Sehr hohe Spannungsfestigkeiten möglich (800V...mehrere kV, Thyristoren bis 12kV)<br />
* Mit kurzen Pulsen einschaltbar, danach Selbsthaltung des Stromflusses<br />
* Leitverluste linear proportional zum Strom, Pv = I * Uak, Uak typ. 0,8...1,5 V <br />
<br />
Nachteile<br />
* Auf niedrige Schaltfrequenzen beschränkt (kHz-Bereich, Schaltzeit im Bereich von µs)<br />
* Anstiegsgeschwindigkeit des Stromes muss begrenzt werden, sonst kommt es zu Bauteilschäden<br />
* Anstiegsgeschwindigkeit der Spannung muss begrenzt werden, sonst kommt es zum ungewollten Zünden<br />
* Stromfluss kann nicht ausgeschaltet werden, damit meist nur Einsatz an Wechselspannung<br />
<br />
{| class="wikitable" style="width:50em"<br />
|- <br />
! style="width:10em" | Bauteil <br />
! style="width:12em" | optimales<br>Einsatzgebiet<br />
! Kommentar<br />
|-<br />
| MOSFET || 0..200V, 0..500A || im Kleinspannungsbereich meist die beste Wahl als Schalter<br />
|-<br />
| Bipolartransistor || 0..1000V, 0..10A || wird mehr und mehr von MOSFETs verdrängt<br />
|-<br />
| IGBT || 200..1700V, 0..500A || optimal für hohe Spannungen und hohe Ströme<br />
|-<br />
| Triac/Thyristor || 230V, 400V, 680V,<br>bis mehrere kV, 0..100A || meist für Wechselspannung, <br>Thyristoren bis 1000A im Dauerbetrieb, <br>im Pulsbetrieb einige kA. (Scheibenzelle)<br />
|}<br />
<br />
Triac oder Thyristor?<br />
* Im Kleinleistungsbereich (< 1 W) überwiegen Thyristoren, da das Einsatzgebiet ''nicht'' das Steuern von Wechselspannungsverbrauchern sondern etwa Spannungsbegrenzung (Crowbar) ist. Typische Bauform: TO92.<br />
* Im Haushaltleistungsbereich (< 2000 W) werden ausschließlich Triacs verwendet. Für induktive Lasten (= hoher Spannungsanstieg beim Ausschalten beim Strom-Nulldurchgang) gibt es „snubberless“-Typen mit verringerter Miller-Kapazität. Typisch für alle Triacs ist ein eingebauter Gate-KA-Widerstand von ≈ 100 Ω. Typische Bauform: TO220.<br />
* Genauso wie netzfrequente Dioden kommen Thyristoren und Triacs mit einem wesentlich (Richtwert: Faktor 10) höheren Strom als ihrem Nennstrom zurecht, ''sofern'' diese Belastung auf ''eine'' Netzhalbwelle begrenzt ist. Danach muss die Strombelastung sinken bis zum Nennwert. Die Strombelastung ist der <u>gleichgerichtete Mittelwert</u>. Achtung: Die Spannungsbelastbarkeit bezieht sich hingegen auf den <u>Scheitelwert</u>! Welche Grenzen einzuhalten sind steht im Datenblatt.<br />
* Bei Strömen > 40 A werden 2 antiparallele Thyristoren günstiger, weil sich der Strom und die Wärmeentwicklung auf 2 Bauelemente verteilt. Antiparallele Thyristoren gibt es im gemeinsamen Gehäuse. Mit Optokoppler integriert nennt man diese Halbleiterrelais, Festkörperrelais oder ''solid state relay''. Keine typische Bauform.<br />
* Für höhere Spannungen als ≈ 1 kV gibt es nur noch Thyristoren. Dabei ist deren Ansteuerung mit Zündtransformator üblich.<br />
<br />
=== Wie finde ich den richtigen Transistor für eine LED-Ansteuerung? ===<br />
<br />
Quelle: Beiträge [http://www.mikrocontroller.net/topic/157763#1493623] und [http://www.mikrocontroller.net/topic/157763#1494972] von yalu<br />
<br />
Um am Anfang wenigstens ein bisschen den Durchblick im Transistordschungel zu behalten, kannst du folgendermaßen vorgehen:<br />
<br />
'''Nomenklatur'''<br />
<br />
Nach der amerikanischen Nomenklatur beginnen die Transistornamen meist mit 2N (z.&nbsp;B. 2N2222 oder 2N3055) und nach der japanischen mit 2S (z.&nbsp;B. 2SC1815). Für den Anfang kann man sich auf europäische Transistoren beschränken, da es diese in ausreichender Auswahl gibt und die Bezeichnungen relativ gut den Transistortyp wiedergeben:<br />
<br />
Der erste Buchstabe bezeichnet das Halbleitermaterial (A=Germanium, B=Silizium). Germaniumtransistoren werden heute nur noch selten verwendet.<br />
<br />
Der zweite Buchstabe steht für den Einsatzzweck (C=Universal, D=hohe Leistung, F=Hochfrequenz, U=hohe Spannung).<br />
<br />
So ist also ein ACxxx ein Germaniumuniversaltransistor und ein BDxxx ein Siliziumleistungstransistor.<br />
<br />
'''Auswahl'''<br />
<br />
Wenn du dich für einen Grundtyp entschieden hast (für die LED ist ein BC-Typ das Richtige), gehst du auf die Webseite eines Elektronikhändlers (Reichelt, Kessler usw.), schlägst die Seite mit den BC-Transistoren auf. Da gibt es natürlich sehr viele davon, und du brauchst jetzt eine<br />
Suchreihenfolge. Als erstes Auswahlkriterium nimmst du den Preis, denn:<br />
<br />
* Zuviel Geld hast wahrscheinlich nicht einmal du.<br />
* Billig ist meist das, was in großen Stückzahlen hergestellt wird. Was für die Masse gut ist, ist (zumindest in diesem Fall) meist auch für dich gut.<br />
* Was billig und damit in Massen verkauft wird, bekommst du auch bei anderen Händlern und auch noch in 10 Jahren. Das ist wichtig, wenn deine Schaltung irgendwann einmal in Serie gefertigt werden soll.<br />
<br />
Gleich als nächstes überlegst du, ob du einen NPN- oder einen PNP-Typ brauchst. Das ergibt sich aus der Anordnung der Bauteile in deiner Schaltung. Hast du die Möglichkeit, die Schaltung wahlweise für einen NPN- oder einen PNP-Typ auszulegen, wählst du die Variante mit dem NPN-Typ. Um einfach eine LED über einen Mikrocontroller einzuschalten, ist i.Allg. ein NPN-Typ in Emitterschaltung richtig.<br />
<br />
Ein weiteres wichtiges Kriterium ist die Befestigungstechnik: Wenn dir die SMD-Löterei etwas suspekt ist, lässt du die entsprechenden Modelle erst einmal alle außen vor. Ein typisches Nicht-SMD-Gehäuse für Universaltransistoren ist TO-92. Es gibt im Internet bebilderte Listen mit den einzelnen Gehäuseformen ([[IC-Gehäuseformen#Weblinks]])<br />
<br />
Wenn du jetzt also bei Reichelt die BC-Transistoren nach Preis aufsteigend sortiert hast, siehst du erst einen Schwung SMD-Tranistoren. Dann kommen ein paar Transistoren im TO-92-Gehäuse, die sind aber PNP. Etwas weiter unten kommt der erste NPN-Transistor in TO-92, nämlich der BC547C. Netterweise stehen gleich ein paar Eckdaten dabei:<br />
<br />
<pre><br />
BC547C 45V 0,1A 0,5W<br />
</pre><br />
<br />
Die 45V sind die maximale Kollektor-Emitter-Spannung, in deinem Fall also die Spannung, die du maximal schalten kannst. Da die LED bei Weitem keine 45V braucht und deine Versorgungsspannung eher in der Gegend von 5V liegt, bist du auf jeden Fall auf der sicheren Seite.<br />
<br />
Deine LED wird typisch mit 20mA (max. 30mA) betrieben. Der BC547C kann 100mA, also ist auch hier noch Luft.<br />
<br />
Zur maximalen Verlustleistung (0,5W): Wenn deine LED eingeschaltet ist, fließen bspw. 20mA. Ist der Transistor voll durchgesteuert (in Sättigung) beträgt die Kollektor-Emitter-Spannung bei diesem geringen Strom typischerweise zwischen 0,1V und 0,2V (Genaueres steht im Datenblatt). Am Transistor wird also maximal die Leistung 20mA·0,2V=4mW in Wärme umgesetzt. Bis zu 500mW dürfen es sein, also ebenfalls ok.<br />
<br />
Nachdem du den Transistor in engere Auswahl gezogen hast, lohnt sich auf jeden Fall ein Blick ins Datenblatt. Aus den Tabellen und Diagrammen erfährst du bspw., wie hoch der Basisstrom sein muss, um den Kollektorstrom von mindestens 20mA bei ausreichend geringer CE-Spannung bereitzustellen. Dort ist auch erklärt warum es einen BC547A, BC547B und BC547C gibt. Der letzte Buchstabe gibt nämlich die Stromverstärkungsklasse an. Da eine hohe Stromverstärkung meist wünschenswert ist und in diesem Fall keinen Aufpreis kostet, ziehst du den BC547C den anderen beiden vor.<br />
<br />
Da in deiner Anwendung HF- und Rauschverhalten keine Rolle spielen, bist du schon am Ziel angelangt.<br />
<br />
Würde deine LED 100mA statt 20mA benötigen, wären die max. 100mA des BC547 etwas knapp bemessen. Du blätterst also in der Reichelt-Liste weiter und stößt auf den BC337-40 mit 45V, 0,5A und 0,525W. Das ist genau das, wonach du suchst. Bei diesem Transistor sind die Stromverstärkungsklassen durch die Endungen -16, -25 und -40 gekennzeichnet. Es wäre ja auch<br />
zu einfach, wenn immer nur A, B und C verwendet würde ;-)<br />
<br />
Bei Strömen ab etwa 500mA kommt man an die Grenze der Leistungsfähigkeit der BC-Typen. Dann geht es weiter mit BD. Der BD135 geht bspw. schon bis 1,5A. Das Problem bei solchen größeren Transistoren: Die Stromverstärkung ist nicht besonders hoch, so dass irgendwann der Mikrocontroller nicht mehr den benötigten Basisstrom liefern kann. Dann muss dem großen Transistor ein kleiner vorangeschaltet werden, um den erhöhten Basisstrom bereitszustellen. Man kann diese Kombination von zwei Transistoren auch fertig als Darlington-Transistor kaufen, von denen ebenfalls einige in der BD-Reihe zu finden sind (z.&nbsp;B. BD647). Ein Transistortyp, der sich sehr gut zum Schalten höherer Ströme eignet, ist der [[FET | MOSFET]].<br />
<br />
Wie schon oben angedeutet: Wenn die 30-80V die die meisten BC- und BD-Transistoren abkönnen, nicht ausreichen, suchst du weiter bei BU.<br />
<br />
Steigst du in die HF-Technik ein, sind BF-Transistoren eher das Richtige, wobei bei HF-Anwendungen die Auswahl der Transistoren nicht mehr das Schwierigste ist ;-)<br />
<br />
'''Und wie geht's weiter?'''<br />
<br />
Man könnte natürlich noch viel mehr zu diesem Thema schreiben. Ich hoffe aber, dass das Geschriebene dir wenigstens grob zeigt, wie man bei nicht allzu speziellem Anforderungen relativ schnell zu einem gewünschten Transistortyp kommt, der nicht nur die technischen Anforderungen erfüllt, sondern auch leicht beschaffbar ist.<br />
<br />
Werden die Anforderungen spezieller, helfen oft die Selektionstabellen auf den Webseiten der einschlägigen Hersteller weiter. Auch Händler wie Farnell haben teilweise ganz gute Auswahlwerkzeuge. <br />
<br />
Wenn du dich intensiv mit Elektronik beschäftigst, wirst du wahrscheinlich noch viele Schaltungen von Leuten zu Gesicht bekommen, die vielleicht schon etwas weiter fortgeschritten sind. Dabei wirst du immer wieder auf bestimmte Standardtypen von Transistoren (und auch anderen Bauteilen wie Operationsverstärker u.ä.) stoßen und sehen, welche [[Standardbauelemente]] "man" üblicherweise für bestimmte Anwendungen einsetzt. Mit der Zeit setzt sich dann eine Auswahl von bspw. 10 oder 20 verschiedenen Transistoren und 5 bis 10 verschiedenen OpAmps im Kopf fest, von denen man die wesentlichen Parameter auswendig kennt, so dass man ohne aufwendige Suche eine schnelle Auswahl treffen kann. Auch hier in der Artikelsammlung gibt es eine solche [[Transistor-Übersicht]].<br />
<br />
=== Wo ist die Antwort auf meine Frage? ===<br />
<br />
Vielleicht im Forum? Falls du sie da findest, dann pack das ganze doch hier rein.<br />
<br />
[http://www.mikrocontroller.net/topic/165580 Gegen Vcc oder GND schalten]<br />
<br />
== Siehe auch ==<br />
* [[Basiswiderstand]]<br />
* [[Transistor-Übersicht]]<br />
* [[AVR_Transistortester]] - neu (Weiterentwickelt von Karl-Heinz Kübbeler)<br />
* [[AVR-Transistortester]] - alte (von Markus Frejek)<br />
* [[Leistungselektronik]]<br />
<br />
== Gehäusebauformen von Transistoren ==<br />
<br />
=== TO-92 ===<br />
Ein kleiner Aufsatz über TO-92 Transistorgehäuse und Footprints findet sich unter: [[Media:TO-92-Gehaeuse_RevB2.pdf]]. <br />
<br />
<br />
<br />
== Weblinks ==<br />
* [http://de.wikipedia.org/wiki/transistor "Transistor" bei Wikipedia]<br />
* [http://www.elektronik-kompendium.de www.elektronik-kompendium.de]<br />
** [http://www.elektronik-kompendium.de/sites/bau/0201291.htm Elko/Transistor]<br />
* http://www.elektronikinfo.de/strom/bipolartransistoren.htm<br />
* http://www.ferromel.de/tronic_1870.htm<br />
* [http://www.DieElektronikerseite.de Die Elektronikerseite] Lehrgang: Der Transistor - Ein Tausendsassa<br />
* [http://www.infoplease.com/encyclopedia/science/transistor-types-transistors.html Transistortypen]<br />
* [http://electronics-electrical.exportersindia.com/electronic-components/transistors.htm Transistoren Industrieunternehmen Geschäftsauflistungen]<br />
<br />
[[Category:Bauteile]]<br />
[[Category:Grundlagen]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=Transistor&diff=107011Transistor2024-07-11T10:10:14Z<p>Heha: /* Gibt es einen IC, der wie mehrere Transistoren funktioniert? */</p>
<hr />
<div>Kunstwort aus "transfer resistor", was etwa so viel bedeutet wie "übertragener [[Widerstand]]".<br />
<br />
In den 1950-ern als praktische Anwendung des [[Halbleiter]]-Effekts erfundenes "solid state" Schalt- und Verstärkerelement, welches sehr klein ist, ohne bewegte Teile auskommt (anders als ein klassisches Relais) und keine energiefressende Heizung benötigt (anders als eine Röhre).<br />
<br />
Vom "bipolaren Transistor" (PNP, NPN) weiterentwickelt zum "Feldeffekt-Transistor" ([[FET]]), der heute - gefertigt mit einem preiswerten Verfahren unter Verwendung von Metall-Oxid-Schichten (MOS) - ein wesentliches Element integrierter Schaltkreise (ICs, integrated circuits) darstellt, und damit natürlich auch von [[Mikrocontroller]]n, um die es in diesem Wiki hauptsächlich geht (bzw. gehen sollte).<br />
<br />
== Schaltzeichen ==<br />
[https://electronicsclub.info/images/transbce.gif]<br />
<br />
* E: Emitter<br />
* B: Basis<br />
* C: Collector <br />
<br />
<br />
In ASCII Schaltplänen sehen Transistoren so aus:<br />
<pre> <br />
|> |/<br />
NPN |> oder -| oder -|<br />
|\ |><br />
<br />
|< |/<br />
PNP: |< oder -| oder -|<br />
|\ |<<br />
</pre><br />
<br />
Um zu erkennen, ob ein NPN oder PNP Transistor im Schaltplan verwendet wird, gibt es Eselsbrücken:<br />
*Für Dichter: '''Tut der Pfeil der Basis weh, handelt's sich um PNP.'''<br />
*Für Praktiker: '''PNP heisst "Pfeil Nach Platte"'''.<br />
*Mit Dialekt: '''NPN "'naus, Pfeil, 'naus"'''.<br />
*..und für Gleichberechtigungsverfechter: '''NPN means "Not Pointing iN"'''.<br />
<br />
<br />
<br />
JFET: [[Bild:Transistor_JFET.png]]<br />
<br />
MOSFET: [[Bild:Transistor_MOSFET.png]]<br />
<br />
* S: Source<br />
* G: Gate<br />
* D: Drain<br />
<br />
Eigentlich haben MOSFETs noch einen vierten Anschluss namens Bulk. Der ist aber nur bei Spezialtypen als Pin herausgeführt. Im Normalfall kann man ihn vergessen, da er nicht gesondert beschaltet werden muss, er ist praktisch und auch im Symbol mit Source verbunden.<br />
<br />
'''Achtung:''' Die NPN/PNP Eselsbrücken funktionieren bei FETs nicht, denn bei einem P-Kanal FET zeigt der Pfeil weg vom FET!<br />
Ein Bipolartransistor, im Englischen als bipolar junction transistor (BJT) bezeichnet, ist ein Transistor, bei dem Ladungsträger – negativ geladene Elektronen und positiv geladene Defektelektronen – zum Stromtransport durch den Bipolartransistor beitragen. Der BJT wird mittels eines elektrischen Stroms gesteuert und wird zum Schalten und Verstärken von Signalen ohne mechanisch bewegte Teile eingesetzt.<br />
<br />
Bipolare Leistungstransistoren sind für das Schalten und Verstärken von Signalen höherer Stromstärken und Spannungen ausgelegt.<br />
<br />
== Typbezeichnungen == <br />
<br />
Neben den Typbezeichnungen wie 2Nxxxx, TIPxxx, MJxxx, MJExx gibt es noch die in Europa geläufigere Kennzeichnung bestehend aus zwei Buchstaben und drei Ziffern. Die diversen Kennzeichnungsmöglichkeiten sind in einem eigenen Artikel ([[Kennzeichnung von Halbleitern]]) zusammengefasst.<br />
<br />
== Kenndaten/Parameter ==<br />
<br />
Im [http://www.mikrocontroller.net/topic/197676#1938546 Beitrag: Transistorparameter Erklärung] sind Links zu Erläuterungen spezieller Kürzel.<br />
<br />
== Transistor Grundschaltungen ==<br />
<br />
Generell gilt, dass Strom vom Kollektor zum Emitter nur dann fließen kann, wenn die Basis positiver (NPN) bzw. negativer (PNP) wird als der Emitter. Dabei darf die Basis nicht direkt mit Vcc (NPN) oder GND (PNP) verbunden werden, da der Basisstrom sonst zu gross wird. Es muss jeweils ein geeigneter Basiswiderstand (R_Basis) gewählt werden.<br />
<br />
'''Weitere Links:'''<br />
* Artikel [[Basiswiderstand]]<br />
* [http://www.elektronik-kompendium.de/sites/slt/0203111.htm Transistor Grundschaltungen im ElKo]<br />
* [http://www.roboternetz.de/wissen/index.php/Transistor Transistor bei RoboterNetz.de]<br />
<br />
Es gibt drei Grundschaltungen. Der Name beschreibt den Anschluss, welcher sich auf einem festen Potential (Spannung) befindet. Die beiden anderen Anschlüsse haben bedingt durch die Schaltung ein veränderliches Potential.<br />
<br />
=== Kollektorschaltung (Emitterfolger)===<br />
<br />
'''Anwendung:'''<br />
* Impedanzwandler<br />
* Darlington-Schaltung<br />
* Schalter<br />
<br />
'''Eigenschaften:'''<br />
* Keine Phasendrehung<br />
* Hohe Stromverstärkung<br />
* Keine Spannungsverstärkung<br />
<br />
'''Beispiel: Transistor als Schalter'''<br />
<br />
* NPN: Kollektor mit Vcc verbinden, Last an Emitter<br />
* PNP: Kollektor mit GND verbinden, Last an Emitter<br />
<br />
In diesem Fall regelt der Transistor die Spannungen am Emitter, daher wird die Last am Emitter angeschlossen. Die Spannung am Emitter entspricht immer der an der Basis minus 0,6V, sie folgt der Basisspannung, deswegen auch der Name Emitterfolger. Daher ist diese Schaltung nicht geeignet, um 12V mit 5V zu schalten. <br />
<br />
{|<br />
|-<br />
| [[Bild:NPN_Collector.gif | framed | center | NPN Transistor in Kollektorschaltung]] <br />
|| [[Bild:PNP_Collector.gif | framed | center | PNP Transistor in Kollektorschaltung]] <br />
|}<br />
* NPN: Wird <math>R_{Poti}</math> (Spannungsteiler) erhöht, '''steigt''' die Spannung <math>U_{Last}</math> letztlich bis auf VCC-0,6V (Basis-Emitter-Übergang).<br />
* PNP: Wird <math>R_{Poti}</math> (Spannungsteiler) erhöht, '''sinkt''' Spannung an <math>U_{Last}</math> letztlich bis auf 0,6V (Basis-Emitter-Übergang).<br />
<br />
'''Weitere Links:'''<br />
* [http://www.elektronik-kompendium.de/sites/slt/0204133.htm Kollektorschaltung im ElKo]<br />
<br />
=== Emitterschaltung ===<br />
<br />
Die Emitterschaltung bietet hohe Spannungs- und Stromverstärkung.<br />
<br />
'''Anwendung:'''<br />
* NF- und HF-Verstärker<br />
* Leistungsverstärker<br />
* Transistor als Schalter<br />
<br />
'''Eigenschaften:'''<br />
* Phasendrehung 180°<br />
* Hohe Spannungsverstärkung<br />
* Hohe Stromverstärkung<br />
<br />
<br />
'''Beispiel: Transistor als Schalter'''<br />
<br />
Die Last liegt am Kollektor. Der Strom durch den Schalter oder an U_Schalt steuert den Strom zwischen Kollektor und Emitter. Wird der Schalter geschlossen, fließt ein Strom.<br />
<br />
[[Bild:NPN_Schalter.gif | framed | center | NPN Transistor als Schalter]]<br />
<pre><br />
___ ___<br />
Vcc/+ o-----------------------+ Vcc/+ o-----------------------+<br />
| |<br />
___ |< U_schalt (-) ___ |< PNP <br />
+------|___|---| PNP o------------|___|----|<br />
| R_Basis |\ R_Basis |\<br />
Schalter \ | |<br />
| ___ | ___ |<br />
GND/- o------+------|___|-----+ GND/- o-------------|___|-----+<br />
R_Last R_Last <br />
<br />
</pre><br />
<br />
<br />
'''Weitere Links:'''<br />
* [http://www.elektronik-kompendium.de/sites/slt/0204302.htm Emitterschaltung im ElKo]<br />
<br />
=== Basisschaltung ===<br />
<br />
Die Basisschaltung findet sich vor allem in Eingangsstufen in der HF-Technik. Im Schaltbetrieb wird sie praktisch nur zur [[Pegelwandler#STEP-UP: 5V -> 9..15V | Pegelwandlung]] für nachfolgende Stufen verwendet.<br />
<br />
'''Eigenschaften:'''<br />
* Geringe Eingangsimpedanz<br />
* Keine Phasenverschiebung<br />
* Hohe Bandbreite<br />
<br />
'''Weitere Links:'''<br />
* [http://www.elektronik-kompendium.de/sites/slt/0205081.htm Basisschaltung im ElKo<br />
<br />
== FAQ aus dem Forum ==<br />
<br />
=== PNP/NPN als Schalter, wohin mit der Last? === <br />
Für viele einfache Anwendungen kann man sich merken: '''Bei Schaltanwendungen darf der Basisstrom nicht durch die Last fließen''' (… wenn die zu schaltende Spannung höher ist als die Steuerspannung). Normalerweise kommt dabei die Emitterschaltung zum Einsatz, die Last kommt also an den Kollektor.<br />
<br />
<pre><br />
Ucc o─────────────┐ Ucc o───────────┐<br />
│ │<br />
┏┷┓ An: GND ___ ┃<<br />
┃ ┃ R_Last o───┤___├──┨ PNP<br />
┗┯┛ Aus: Ucc ┃\<br />
│ │<br />
An: Ucc ___ ┃/ ┏┷┓<br />
o───┤___├────┨ NPN ┃ ┃ R_Last<br />
Aus: GND ┃> ┗┯┛<br />
│ │<br />
GND o─────────────┘ GND o───────────┘<br />
</pre><br />
<br />
Siehe [[Basiswiderstand]] zur Berechnung des notwendigen Basiswiderstandes bei gegebener Last R_Last für einen Transistor als Schalter.<br />
<br />
Siehe auch Threads im Forum: <br />
* http://www.mikrocontroller.net/topic/58567 <br />
* http://www.mikrocontroller.net/topic/119841<br />
* oder im [http://www.elektronik-kompendium.de/sites/slt/0208031.htm Elektronik-Kompendium-Forum]<br />
<br />
Ist die zu schaltende Spannung '''genauso hoch''' wie die Steuerspannung darf die Last an den Emitter, und der Basiswiderstand entfällt. Der Transistor arbeitet als ''Impedanzwandler'' und steigert die Treiberfähigkeit des Mikrocontroller-Ausgangs in den Ampere-Bereich. Dieser Trick funktioniert '''nur''' mit Bipolartransistoren.<br />
<br />
Ist die effektive Invertierung des Schaltzustandes im oben angegebenen Bild lästig '''und''' der Strom geringer als der Ausgangsstrom, kann man den Transistor am Emitter steuern. Eine solche Schaltung funktioniert noch besser mit (Logik-Level-)MOSFETs und stellt eine einfache Kopplung zwischen Systemen mit unterschiedlicher Betriebsspannung (bspw. 1,8 V und 3,3 V) her. MOSFETs werden dazu am Source-Pin gesteuert, während das Gate an der „gegenüberliegenden“ Speisespannung „fixiert“ wird.<br />
<br />
=== Wie kann ich mit 5V vom Mikrocontroller 12V und mehr schalten? === <br />
Schau mal hier:<br />
* Wikiartikel [[Pegelwandler]]<br />
* [http://www.elektronik-kompendium.de/sites/praxis/bausatz_pegelwandler-mit-transistoren.htm Pegelwandler im ElKo]<br />
* [http://dl6gl.de/grundlagen/schalten-mit-transistoren schalten-mit-transistoren]<br />
<br />
oder in diesen Threads:<br />
*[http://www.mikrocontroller.net/topic/17899 Transistor als Schalter]<br />
*[http://www.mikrocontroller.net/topic/14437 Vcc schalten mit MOSFET]<br />
*[http://www.mikrocontroller.net/topic/29830 Schalten mit PNP-Transistor]<br />
*[http://www.mikrocontroller.net/topic/104027 Transistorschalter für Versorgungsspannung]<br />
*[http://www.mikrocontroller.net/topic/104951#921417 7-50V strombegrenzt schalten]<br />
*[http://www.mikrocontroller.net/topic/103116#900247 P-Kanal MOSFET ansteuern]<br />
*[https://www.mikrocontroller.net/topic/383039#4367479 5V/15mA mit 3,3V schalten]<br />
*[https://www.mikrocontroller.net/topic/401317#4638354 High Side Treiber mit Ladungspumpe]<br />
*[https://www.mikrocontroller.net/topic/347885?goto=3855574#3855574 minus -12V mit 3,3V schalten]<br />
*[https://www.mikrocontroller.net/topic/516373?goto=6650986#6650986 Kurzschlußfester Schalter für VCC]<br />
<br />
Bei der Kollektor-Schaltung entspricht die Spannung am Emitter immer der an der Basis, daher ist sie nur bedingt geeignet. Zum Schalten können die folgenden Emitter-Schaltungen verwendet werden. Achtung: In der zweiten davon arbeitet T1 in Basisschaltung.<br />
<br />
Schalten gegen GND<br />
<br />
<pre><br />
+12V o------------------------+<br />
|<br />
.-. <br />
( X ) <br />
'-'<br />
|<br />
___ |/ T1,NPN <br />
uC PIN o---|___|-----| BC547 <br />
R2,4K7 |><br />
|<br />
GND o---------o--------------+<br />
</pre><br />
<br />
<br />
Schalten gegen +12V<br />
<br />
<pre><br />
+12V o--------------+----------------------+<br />
| |<br />
| ____ |< T2, PNP<br />
+--|____|----+--------| BC557<br />
R1,4K7 | |\<br />
|/T1,NPN |<br />
Vcc/+5V o--------------| BC547 |<br />
|> |<br />
___ | .-. <br />
uC PIN o-----|___|------+ ( X ) <br />
R2,4K7 '-'<br />
|<br />
GND o----------o--------------------------+<br />
</pre><br />
<br />
=== Transistor an µC ohne Vorwiderstand === <br />
<br />
Normalerweise sind IO Pins vom µC nicht in der Lage, große Ströme zu treiben, beim AVR maximal ~20mA. Für einen kleinen Transistor ist das immer noch zu viel und es wäre auch Stromverschwendung.<br />
<br />
Deshalb kann man den IO-Pin des AVRs einfach als Tristate Eingang einstellen (Portpin als Eingang und Pullup deaktivieren), damit kein Basisstrom fließt.<br />
<br />
Aktiviert man nun den internen Pullup-Widerstand des AVRs, agiert dieser als Basisvorwiderstand, und es fließt nur ein geringer Basisstrom (die Pullups eines AVRs liegen irgendwo bei 50k bis 100k Ohm - siehe Datenblatt).<br />
<br />
Nur sollte man bei kleinen Transistoren aufpassen, dass man den Portpin in der Software nie als aktiven Ausgang schaltet. <br />
<br />
Wenn der verwendete µC zuschaltbare Pulldown-Widerstände an seinen Pins besitzt, kann man das gleiche auch mit einem PNP-Transistor machen (natürlich nur den Pulldown aktivieren).<br />
<br />
Eine Anwendung wären z.&nbsp;B. Nixie-Röhren-Kathodentreiber (geringe Stromverstärkung nötig).<br />
<br />
=== Wann bipolare (NPN/PNP) und wann FETs (insbesonders, wenn LEDs im Spiel sind)?=== <br />
Oft sind bipolare Transistoren (NPN/PNP) schon ausreichend, vor allem wenn "normale" LEDs (20mA) verwendet werden. FETs sind u.a. dann gut, wenn mit geringen Eingangsströmen hohe Ausgangsströme (über 300 mA) geschaltet werden sollen, also bei den Power-LEDs (Luxeon...).<br />
<br />
Ein Grenzfall: 500mA/5V schalten, siehe http://www.mikrocontroller.net/topic/62327.<br />
<br />
=== Wieso gehen bei einer Multiplex-Anzeige mit Schieberegister 74HC595 und (Darlington-)Transistor als Zeilentreiber die LED nicht ganz aus? ===<br />
Das liegt an der '''Miller-Kapazität''' des übersteuerten (Darlington-)Transistors. Der braucht erst mal einige 10µs, um zu sperren. Du mußt also erstmal beide Zeilen ausschalten, dann etwas warten und dann die nächste Zeile an. Oder Du ersetzt die Darlington durch P-FETs. [http://www.mikrocontroller.net/topic/132545]<br />
<br />
=== Wie steuert man ein Relais? ===<br />
Normalerweise verwendet man zur Ansteuerung von Relais NPN-Transistoren in Emitterschaltung. Freilaufdiode nicht vergessen! <br />
<br />
Siehe auch:<br />
* [[Relais mit Logik ansteuern]]<br />
* [http://www.mikrocontroller.net/attachment/22023/Relaisanteuerung.png Schaltbilder aus dem Forum]<br />
<br />
=== Was ist die Spannung <math>U_{BE\_sat}</math> (lt. Datenblatt max. 1,2V)? ===<br />
Bekanntlich verhält sich die Basis-Emitter Strecke eines Transistors wie eine Diode und <math>U_{BE\_sat}</math> ist die bei maximal zulässigem Basisstrom anliegende Vorwärtsspannung.<br />
<br />
=== Was bewirkt ein Kondensator (100µF-1nF) parallel zur Basis-Emitter-Strecke nach Masse? === <br />
Er wirkt mit dem Basisvorwiderstand als RC-Tiefpass. Damit wird der Transistor eigentlich nicht mehr als Schalter, sondern als Linearregler betrieben. Manche Verstärker-Schaltungen sind, gerade bei hohen Lasten, sehr schwingfreudig. Deswegen ist bei PWM so ein C nicht sinnvoll.<br />
<br />
=== Gibt es einen IC, der wie mehrere Transistoren funktioniert? ===<br />
<br />
Gibt es! Beispielsweise der '''ULN2803''' ist ein 8-fach Darlington Transistor Array mit [[Ausgangsstufen_Logik-ICs#Open_Collector|Open-Collector Ausgang]]. Und sogar die Freilaufdioden sind schon drin.<br />
Damit lässt sich z.&nbsp;B. ein Leistungstreiber zur Ansteuerung von Schrittmotoren, Relais und anderen induktiven Lasten aufbauen.<br />
<br />
=== Gibt es ein Transistor-Array wie ULN28xx, das gegen Vcc schaltet? ===<br />
<br />
Such mal nach UDN29xx, z.&nbsp;B. UDN2981, UDN2987 ...<br />
<br />
Allegro hat zwischenzeitlich seinen Source-Treiber umbenannt. Die Bauteile heißen jetzt A2981, A2982 usw... Die Datenblätter sind identisch geblieben.<br />
<br />
Nachteil eines Darlington-Source-Treibers ist die hohe Sättigungsspannung (VceSat) von typisch 1,2 V. Die Eingangsspannung sollte dementsprechend höher ausgelegt werden oder gleich ein Source-Treiber mit MOSFET-Transistoren gewählt werden (z.B. Infineon ProFETs).<br />
<br />
=== Wann setzt man einen MOSFET, Bipolartransistor, IGBT oder Thyristor ein? ===<br />
siehe [[Leistungselektronik]]<br />
<br />
Die Summe allen Übels ist konstant. Man muss wissen, welches Bauteil sich wofür besonders eignet.<br />
<br />
====[[FET | MOSFET]]====<br />
<br />
Vorteile<br />
* Bei niedrigen Spannungen <100V sehr gut geeignet, <200V gut geeignet, sehr geringe R_DS-ON Widerstände möglich (einstelliger mOhm-Bereich)<br />
* Hohe Schaltgeschwindigkeiten möglich<br />
* Geringe An- und Ausschaltverluste<br />
* Statisch praktisch leistungslos steuerbar<br />
* Bodydiode kann als Freilaufdiode in H-Brücken verwendet werden<br />
* 2. Durchbruch bei Überschreiten der max. Drain-Source Sperrspannung zerstört das Bauteil nicht, wenn der Strom sowie die Energie begrenzt werden. (Verhalten wie [[Diode | Z-Diode]])<br />
<br />
Nachteile<br />
*Antiparallele Diode (Bodydiode) ist in nahezu allen MOSFETs unvermeidlich, daduch Sperren nur in einer Polarität möglich, Stromfluss über den MOSFET aber in beiden Richtungen möglich (Inversbetrieb, Synchrongleichrichter)<br />
* Bei Sperrspannungen >100V deutlich steigende Einschaltwiderstände (R_DS-ON)<br />
* Schnelles Umschalten erfordert hohe Lade-und Entladeströme ([[MOSFET-Übersicht#Mosfet-Treiber|MOSFET-Treiber]])<br />
* Leitverluste quadratisch proportional zum Strom, Pv = I²*R_DS-ON<br />
<br />
====[[Transistor | Bipolartransistor]]====<br />
<br />
Vorteile<br />
* Hohe Spannungsfestigkeiten möglich, bis zu 2000V<br />
* Sehr hohe Schaltgeschwindigkeiten möglich<br />
* Leitverluste etwa linear proportional zum Strom und Kollektor-Emitter-Sättigungsspannung, Pv = I * Uce-sat, U_CEC-sat typ 0,1...2.5 V<br />
<br />
Nachteile<br />
* Stromgesteuert, damit wird immer eine gewisse Ansteuerleistung benötigt<br />
* Bei grossen Kollektorströmen nimmt die Stromverstärkung deutlich ab, dann wird ein großer Basisstrom benötigt<br />
* 2. Durchbruch bei Überschreiten der max. Kollektor-Emitter Sperrspannung zerstört das Bauteil<br />
<br />
====[[IGBT]]====<br />
<br />
Vorteile<br />
* Hohe Spannungsfestigkeiten möglich, bis zu 6600V, in üblichen Bauformen bis ca 1700V gut verfügbar<br />
* Statisch praktisch leistungslos steuerbar<br />
* Mit oder ohne antiparallele Diode zur Kollektor-Emitter-Strecke verfügbar<br />
* Leitverluste linear proportional zum Strom und Kollektor-Emitter-Sättigungsspannung, Pv = I * Uce-sat, U_CE-sat typ. 2V<br />
<br />
Nachteile<br />
* Nur mäßige Schaltfrequenzen möglich (typ. <30..50kHz)<br />
* Schnelles Umschalten erfordert hohe Lade-und Entladeströme ([[MOSFET-Übersicht#Mosfet-Treiber|MOSFET-Treiber]])<br />
* 2. Durchbruch bei Überschreiten der max. Kollektor-Emitter Sperrspannung zerstört das Bauteil<br />
<br />
====[[TRIAC]]/Thyristor====<br />
<br />
Vorteile:<br />
* Sehr hohe Spannungsfestigkeiten möglich (800V...mehrere kV, Thyristoren bis 12kV)<br />
* Mit kurzen Pulsen einschaltbar, danach Selbsthaltung des Stromflusses<br />
* Leitverluste linear proportional zum Strom, Pv = I * Uak, Uak typ. 0,8...1,5 V <br />
<br />
Nachteile<br />
* Auf niedrige Schaltfrequenzen beschränkt (kHz-Bereich, Schaltzeit im Bereich von µs)<br />
* Anstiegsgeschwindigkeit des Stromes muss begrenzt werden, sonst kommt es zu Bauteilschäden<br />
* Anstiegsgeschwindigkeit der Spannung muss begrenzt werden, sonst kommt es zum ungewollten Zünden<br />
* Stromfluss kann nicht ausgeschaltet werden, damit meist nur Einsatz an Wechselspannung<br />
<br />
{| class="wikitable" style="width:50em"<br />
|- <br />
! style="width:10em" | Bauteil <br />
! style="width:12em" | optimales<br>Einsatzgebiet<br />
! Kommentar<br />
|-<br />
| MOSFET || 0..200V, 0..500A || im Kleinspannungsbereich meist die beste Wahl als Schalter<br />
|-<br />
| Bipolartransistor || 0..1000V, 0..10A || wird mehr und mehr von MOSFETs verdrängt<br />
|-<br />
| IGBT || 200..1700V, 0..500A || optimal für hohe Spannungen und hohe Ströme<br />
|-<br />
| Triac/Thyristor || 230V, 400V, 680V,<br>bis mehrere kV, 0..100A || meist für Wechselspannung, <br>Thyristoren bis 1000A im Dauerbetrieb, <br>im Pulsbetrieb einige kA. (Scheibenzelle)<br />
|}<br />
<br />
=== Wie finde ich den richtigen Transistor für eine LED-Ansteuerung? ===<br />
<br />
Quelle: Beiträge [http://www.mikrocontroller.net/topic/157763#1493623] und [http://www.mikrocontroller.net/topic/157763#1494972] von yalu<br />
<br />
Um am Anfang wenigstens ein bisschen den Durchblick im Transistordschungel zu behalten, kannst du folgendermaßen vorgehen:<br />
<br />
'''Nomenklatur'''<br />
<br />
Nach der amerikanischen Nomenklatur beginnen die Transistornamen meist mit 2N (z.&nbsp;B. 2N2222 oder 2N3055) und nach der japanischen mit 2S (z.&nbsp;B. 2SC1815). Für den Anfang kann man sich auf europäische Transistoren beschränken, da es diese in ausreichender Auswahl gibt und die Bezeichnungen relativ gut den Transistortyp wiedergeben:<br />
<br />
Der erste Buchstabe bezeichnet das Halbleitermaterial (A=Germanium, B=Silizium). Germaniumtransistoren werden heute nur noch selten verwendet.<br />
<br />
Der zweite Buchstabe steht für den Einsatzzweck (C=Universal, D=hohe Leistung, F=Hochfrequenz, U=hohe Spannung).<br />
<br />
So ist also ein ACxxx ein Germaniumuniversaltransistor und ein BDxxx ein Siliziumleistungstransistor.<br />
<br />
'''Auswahl'''<br />
<br />
Wenn du dich für einen Grundtyp entschieden hast (für die LED ist ein BC-Typ das Richtige), gehst du auf die Webseite eines Elektronikhändlers (Reichelt, Kessler usw.), schlägst die Seite mit den BC-Transistoren auf. Da gibt es natürlich sehr viele davon, und du brauchst jetzt eine<br />
Suchreihenfolge. Als erstes Auswahlkriterium nimmst du den Preis, denn:<br />
<br />
* Zuviel Geld hast wahrscheinlich nicht einmal du.<br />
* Billig ist meist das, was in großen Stückzahlen hergestellt wird. Was für die Masse gut ist, ist (zumindest in diesem Fall) meist auch für dich gut.<br />
* Was billig und damit in Massen verkauft wird, bekommst du auch bei anderen Händlern und auch noch in 10 Jahren. Das ist wichtig, wenn deine Schaltung irgendwann einmal in Serie gefertigt werden soll.<br />
<br />
Gleich als nächstes überlegst du, ob du einen NPN- oder einen PNP-Typ brauchst. Das ergibt sich aus der Anordnung der Bauteile in deiner Schaltung. Hast du die Möglichkeit, die Schaltung wahlweise für einen NPN- oder einen PNP-Typ auszulegen, wählst du die Variante mit dem NPN-Typ. Um einfach eine LED über einen Mikrocontroller einzuschalten, ist i.Allg. ein NPN-Typ in Emitterschaltung richtig.<br />
<br />
Ein weiteres wichtiges Kriterium ist die Befestigungstechnik: Wenn dir die SMD-Löterei etwas suspekt ist, lässt du die entsprechenden Modelle erst einmal alle außen vor. Ein typisches Nicht-SMD-Gehäuse für Universaltransistoren ist TO-92. Es gibt im Internet bebilderte Listen mit den einzelnen Gehäuseformen ([[IC-Gehäuseformen#Weblinks]])<br />
<br />
Wenn du jetzt also bei Reichelt die BC-Transistoren nach Preis aufsteigend sortiert hast, siehst du erst einen Schwung SMD-Tranistoren. Dann kommen ein paar Transistoren im TO-92-Gehäuse, die sind aber PNP. Etwas weiter unten kommt der erste NPN-Transistor in TO-92, nämlich der BC547C. Netterweise stehen gleich ein paar Eckdaten dabei:<br />
<br />
<pre><br />
BC547C 45V 0,1A 0,5W<br />
</pre><br />
<br />
Die 45V sind die maximale Kollektor-Emitter-Spannung, in deinem Fall also die Spannung, die du maximal schalten kannst. Da die LED bei Weitem keine 45V braucht und deine Versorgungsspannung eher in der Gegend von 5V liegt, bist du auf jeden Fall auf der sicheren Seite.<br />
<br />
Deine LED wird typisch mit 20mA (max. 30mA) betrieben. Der BC547C kann 100mA, also ist auch hier noch Luft.<br />
<br />
Zur maximalen Verlustleistung (0,5W): Wenn deine LED eingeschaltet ist, fließen bspw. 20mA. Ist der Transistor voll durchgesteuert (in Sättigung) beträgt die Kollektor-Emitter-Spannung bei diesem geringen Strom typischerweise zwischen 0,1V und 0,2V (Genaueres steht im Datenblatt). Am Transistor wird also maximal die Leistung 20mA·0,2V=4mW in Wärme umgesetzt. Bis zu 500mW dürfen es sein, also ebenfalls ok.<br />
<br />
Nachdem du den Transistor in engere Auswahl gezogen hast, lohnt sich auf jeden Fall ein Blick ins Datenblatt. Aus den Tabellen und Diagrammen erfährst du bspw., wie hoch der Basisstrom sein muss, um den Kollektorstrom von mindestens 20mA bei ausreichend geringer CE-Spannung bereitzustellen. Dort ist auch erklärt warum es einen BC547A, BC547B und BC547C gibt. Der letzte Buchstabe gibt nämlich die Stromverstärkungsklasse an. Da eine hohe Stromverstärkung meist wünschenswert ist und in diesem Fall keinen Aufpreis kostet, ziehst du den BC547C den anderen beiden vor.<br />
<br />
Da in deiner Anwendung HF- und Rauschverhalten keine Rolle spielen, bist du schon am Ziel angelangt.<br />
<br />
Würde deine LED 100mA statt 20mA benötigen, wären die max. 100mA des BC547 etwas knapp bemessen. Du blätterst also in der Reichelt-Liste weiter und stößt auf den BC337-40 mit 45V, 0,5A und 0,525W. Das ist genau das, wonach du suchst. Bei diesem Transistor sind die Stromverstärkungsklassen durch die Endungen -16, -25 und -40 gekennzeichnet. Es wäre ja auch<br />
zu einfach, wenn immer nur A, B und C verwendet würde ;-)<br />
<br />
Bei Strömen ab etwa 500mA kommt man an die Grenze der Leistungsfähigkeit der BC-Typen. Dann geht es weiter mit BD. Der BD135 geht bspw. schon bis 1,5A. Das Problem bei solchen größeren Transistoren: Die Stromverstärkung ist nicht besonders hoch, so dass irgendwann der Mikrocontroller nicht mehr den benötigten Basisstrom liefern kann. Dann muss dem großen Transistor ein kleiner vorangeschaltet werden, um den erhöhten Basisstrom bereitszustellen. Man kann diese Kombination von zwei Transistoren auch fertig als Darlington-Transistor kaufen, von denen ebenfalls einige in der BD-Reihe zu finden sind (z.&nbsp;B. BD647). Ein Transistortyp, der sich sehr gut zum Schalten höherer Ströme eignet, ist der [[FET | MOSFET]].<br />
<br />
Wie schon oben angedeutet: Wenn die 30-80V die die meisten BC- und BD-Transistoren abkönnen, nicht ausreichen, suchst du weiter bei BU.<br />
<br />
Steigst du in die HF-Technik ein, sind BF-Transistoren eher das Richtige, wobei bei HF-Anwendungen die Auswahl der Transistoren nicht mehr das Schwierigste ist ;-)<br />
<br />
'''Und wie geht's weiter?'''<br />
<br />
Man könnte natürlich noch viel mehr zu diesem Thema schreiben. Ich hoffe aber, dass das Geschriebene dir wenigstens grob zeigt, wie man bei nicht allzu speziellem Anforderungen relativ schnell zu einem gewünschten Transistortyp kommt, der nicht nur die technischen Anforderungen erfüllt, sondern auch leicht beschaffbar ist.<br />
<br />
Werden die Anforderungen spezieller, helfen oft die Selektionstabellen auf den Webseiten der einschlägigen Hersteller weiter. Auch Händler wie Farnell haben teilweise ganz gute Auswahlwerkzeuge. <br />
<br />
Wenn du dich intensiv mit Elektronik beschäftigst, wirst du wahrscheinlich noch viele Schaltungen von Leuten zu Gesicht bekommen, die vielleicht schon etwas weiter fortgeschritten sind. Dabei wirst du immer wieder auf bestimmte Standardtypen von Transistoren (und auch anderen Bauteilen wie Operationsverstärker u.ä.) stoßen und sehen, welche [[Standardbauelemente]] "man" üblicherweise für bestimmte Anwendungen einsetzt. Mit der Zeit setzt sich dann eine Auswahl von bspw. 10 oder 20 verschiedenen Transistoren und 5 bis 10 verschiedenen OpAmps im Kopf fest, von denen man die wesentlichen Parameter auswendig kennt, so dass man ohne aufwendige Suche eine schnelle Auswahl treffen kann. Auch hier in der Artikelsammlung gibt es eine solche [[Transistor-Übersicht]].<br />
<br />
=== Wo ist die Antwort auf meine Frage? ===<br />
<br />
Vielleicht im Forum? Falls du sie da findest, dann pack das ganze doch hier rein.<br />
<br />
[http://www.mikrocontroller.net/topic/165580 Gegen Vcc oder GND schalten]<br />
<br />
== Siehe auch ==<br />
* [[Basiswiderstand]]<br />
* [[Transistor-Übersicht]]<br />
* [[AVR_Transistortester]] - neu (Weiterentwickelt von Karl-Heinz Kübbeler)<br />
* [[AVR-Transistortester]] - alte (von Markus Frejek)<br />
* [[Leistungselektronik]]<br />
<br />
== Gehäusebauformen von Transistoren ==<br />
<br />
=== TO-92 ===<br />
Ein kleiner Aufsatz über TO-92 Transistorgehäuse und Footprints findet sich unter: [[Media:TO-92-Gehaeuse_RevB2.pdf]]. <br />
<br />
<br />
<br />
== Weblinks ==<br />
* [http://de.wikipedia.org/wiki/transistor "Transistor" bei Wikipedia]<br />
* [http://www.elektronik-kompendium.de www.elektronik-kompendium.de]<br />
** [http://www.elektronik-kompendium.de/sites/bau/0201291.htm Elko/Transistor]<br />
* http://www.elektronikinfo.de/strom/bipolartransistoren.htm<br />
* http://www.ferromel.de/tronic_1870.htm<br />
* [http://www.DieElektronikerseite.de Die Elektronikerseite] Lehrgang: Der Transistor - Ein Tausendsassa<br />
* [http://www.infoplease.com/encyclopedia/science/transistor-types-transistors.html Transistortypen]<br />
* [http://electronics-electrical.exportersindia.com/electronic-components/transistors.htm Transistoren Industrieunternehmen Geschäftsauflistungen]<br />
<br />
[[Category:Bauteile]]<br />
[[Category:Grundlagen]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=Transistor&diff=107010Transistor2024-07-11T10:07:30Z<p>Heha: /* PNP/NPN als Schalter, wohin mit der Last? */</p>
<hr />
<div>Kunstwort aus "transfer resistor", was etwa so viel bedeutet wie "übertragener [[Widerstand]]".<br />
<br />
In den 1950-ern als praktische Anwendung des [[Halbleiter]]-Effekts erfundenes "solid state" Schalt- und Verstärkerelement, welches sehr klein ist, ohne bewegte Teile auskommt (anders als ein klassisches Relais) und keine energiefressende Heizung benötigt (anders als eine Röhre).<br />
<br />
Vom "bipolaren Transistor" (PNP, NPN) weiterentwickelt zum "Feldeffekt-Transistor" ([[FET]]), der heute - gefertigt mit einem preiswerten Verfahren unter Verwendung von Metall-Oxid-Schichten (MOS) - ein wesentliches Element integrierter Schaltkreise (ICs, integrated circuits) darstellt, und damit natürlich auch von [[Mikrocontroller]]n, um die es in diesem Wiki hauptsächlich geht (bzw. gehen sollte).<br />
<br />
== Schaltzeichen ==<br />
[https://electronicsclub.info/images/transbce.gif]<br />
<br />
* E: Emitter<br />
* B: Basis<br />
* C: Collector <br />
<br />
<br />
In ASCII Schaltplänen sehen Transistoren so aus:<br />
<pre> <br />
|> |/<br />
NPN |> oder -| oder -|<br />
|\ |><br />
<br />
|< |/<br />
PNP: |< oder -| oder -|<br />
|\ |<<br />
</pre><br />
<br />
Um zu erkennen, ob ein NPN oder PNP Transistor im Schaltplan verwendet wird, gibt es Eselsbrücken:<br />
*Für Dichter: '''Tut der Pfeil der Basis weh, handelt's sich um PNP.'''<br />
*Für Praktiker: '''PNP heisst "Pfeil Nach Platte"'''.<br />
*Mit Dialekt: '''NPN "'naus, Pfeil, 'naus"'''.<br />
*..und für Gleichberechtigungsverfechter: '''NPN means "Not Pointing iN"'''.<br />
<br />
<br />
<br />
JFET: [[Bild:Transistor_JFET.png]]<br />
<br />
MOSFET: [[Bild:Transistor_MOSFET.png]]<br />
<br />
* S: Source<br />
* G: Gate<br />
* D: Drain<br />
<br />
Eigentlich haben MOSFETs noch einen vierten Anschluss namens Bulk. Der ist aber nur bei Spezialtypen als Pin herausgeführt. Im Normalfall kann man ihn vergessen, da er nicht gesondert beschaltet werden muss, er ist praktisch und auch im Symbol mit Source verbunden.<br />
<br />
'''Achtung:''' Die NPN/PNP Eselsbrücken funktionieren bei FETs nicht, denn bei einem P-Kanal FET zeigt der Pfeil weg vom FET!<br />
Ein Bipolartransistor, im Englischen als bipolar junction transistor (BJT) bezeichnet, ist ein Transistor, bei dem Ladungsträger – negativ geladene Elektronen und positiv geladene Defektelektronen – zum Stromtransport durch den Bipolartransistor beitragen. Der BJT wird mittels eines elektrischen Stroms gesteuert und wird zum Schalten und Verstärken von Signalen ohne mechanisch bewegte Teile eingesetzt.<br />
<br />
Bipolare Leistungstransistoren sind für das Schalten und Verstärken von Signalen höherer Stromstärken und Spannungen ausgelegt.<br />
<br />
== Typbezeichnungen == <br />
<br />
Neben den Typbezeichnungen wie 2Nxxxx, TIPxxx, MJxxx, MJExx gibt es noch die in Europa geläufigere Kennzeichnung bestehend aus zwei Buchstaben und drei Ziffern. Die diversen Kennzeichnungsmöglichkeiten sind in einem eigenen Artikel ([[Kennzeichnung von Halbleitern]]) zusammengefasst.<br />
<br />
== Kenndaten/Parameter ==<br />
<br />
Im [http://www.mikrocontroller.net/topic/197676#1938546 Beitrag: Transistorparameter Erklärung] sind Links zu Erläuterungen spezieller Kürzel.<br />
<br />
== Transistor Grundschaltungen ==<br />
<br />
Generell gilt, dass Strom vom Kollektor zum Emitter nur dann fließen kann, wenn die Basis positiver (NPN) bzw. negativer (PNP) wird als der Emitter. Dabei darf die Basis nicht direkt mit Vcc (NPN) oder GND (PNP) verbunden werden, da der Basisstrom sonst zu gross wird. Es muss jeweils ein geeigneter Basiswiderstand (R_Basis) gewählt werden.<br />
<br />
'''Weitere Links:'''<br />
* Artikel [[Basiswiderstand]]<br />
* [http://www.elektronik-kompendium.de/sites/slt/0203111.htm Transistor Grundschaltungen im ElKo]<br />
* [http://www.roboternetz.de/wissen/index.php/Transistor Transistor bei RoboterNetz.de]<br />
<br />
Es gibt drei Grundschaltungen. Der Name beschreibt den Anschluss, welcher sich auf einem festen Potential (Spannung) befindet. Die beiden anderen Anschlüsse haben bedingt durch die Schaltung ein veränderliches Potential.<br />
<br />
=== Kollektorschaltung (Emitterfolger)===<br />
<br />
'''Anwendung:'''<br />
* Impedanzwandler<br />
* Darlington-Schaltung<br />
* Schalter<br />
<br />
'''Eigenschaften:'''<br />
* Keine Phasendrehung<br />
* Hohe Stromverstärkung<br />
* Keine Spannungsverstärkung<br />
<br />
'''Beispiel: Transistor als Schalter'''<br />
<br />
* NPN: Kollektor mit Vcc verbinden, Last an Emitter<br />
* PNP: Kollektor mit GND verbinden, Last an Emitter<br />
<br />
In diesem Fall regelt der Transistor die Spannungen am Emitter, daher wird die Last am Emitter angeschlossen. Die Spannung am Emitter entspricht immer der an der Basis minus 0,6V, sie folgt der Basisspannung, deswegen auch der Name Emitterfolger. Daher ist diese Schaltung nicht geeignet, um 12V mit 5V zu schalten. <br />
<br />
{|<br />
|-<br />
| [[Bild:NPN_Collector.gif | framed | center | NPN Transistor in Kollektorschaltung]] <br />
|| [[Bild:PNP_Collector.gif | framed | center | PNP Transistor in Kollektorschaltung]] <br />
|}<br />
* NPN: Wird <math>R_{Poti}</math> (Spannungsteiler) erhöht, '''steigt''' die Spannung <math>U_{Last}</math> letztlich bis auf VCC-0,6V (Basis-Emitter-Übergang).<br />
* PNP: Wird <math>R_{Poti}</math> (Spannungsteiler) erhöht, '''sinkt''' Spannung an <math>U_{Last}</math> letztlich bis auf 0,6V (Basis-Emitter-Übergang).<br />
<br />
'''Weitere Links:'''<br />
* [http://www.elektronik-kompendium.de/sites/slt/0204133.htm Kollektorschaltung im ElKo]<br />
<br />
=== Emitterschaltung ===<br />
<br />
Die Emitterschaltung bietet hohe Spannungs- und Stromverstärkung.<br />
<br />
'''Anwendung:'''<br />
* NF- und HF-Verstärker<br />
* Leistungsverstärker<br />
* Transistor als Schalter<br />
<br />
'''Eigenschaften:'''<br />
* Phasendrehung 180°<br />
* Hohe Spannungsverstärkung<br />
* Hohe Stromverstärkung<br />
<br />
<br />
'''Beispiel: Transistor als Schalter'''<br />
<br />
Die Last liegt am Kollektor. Der Strom durch den Schalter oder an U_Schalt steuert den Strom zwischen Kollektor und Emitter. Wird der Schalter geschlossen, fließt ein Strom.<br />
<br />
[[Bild:NPN_Schalter.gif | framed | center | NPN Transistor als Schalter]]<br />
<pre><br />
___ ___<br />
Vcc/+ o-----------------------+ Vcc/+ o-----------------------+<br />
| |<br />
___ |< U_schalt (-) ___ |< PNP <br />
+------|___|---| PNP o------------|___|----|<br />
| R_Basis |\ R_Basis |\<br />
Schalter \ | |<br />
| ___ | ___ |<br />
GND/- o------+------|___|-----+ GND/- o-------------|___|-----+<br />
R_Last R_Last <br />
<br />
</pre><br />
<br />
<br />
'''Weitere Links:'''<br />
* [http://www.elektronik-kompendium.de/sites/slt/0204302.htm Emitterschaltung im ElKo]<br />
<br />
=== Basisschaltung ===<br />
<br />
Die Basisschaltung findet sich vor allem in Eingangsstufen in der HF-Technik. Im Schaltbetrieb wird sie praktisch nur zur [[Pegelwandler#STEP-UP: 5V -> 9..15V | Pegelwandlung]] für nachfolgende Stufen verwendet.<br />
<br />
'''Eigenschaften:'''<br />
* Geringe Eingangsimpedanz<br />
* Keine Phasenverschiebung<br />
* Hohe Bandbreite<br />
<br />
'''Weitere Links:'''<br />
* [http://www.elektronik-kompendium.de/sites/slt/0205081.htm Basisschaltung im ElKo<br />
<br />
== FAQ aus dem Forum ==<br />
<br />
=== PNP/NPN als Schalter, wohin mit der Last? === <br />
Für viele einfache Anwendungen kann man sich merken: '''Bei Schaltanwendungen darf der Basisstrom nicht durch die Last fließen''' (… wenn die zu schaltende Spannung höher ist als die Steuerspannung). Normalerweise kommt dabei die Emitterschaltung zum Einsatz, die Last kommt also an den Kollektor.<br />
<br />
<pre><br />
Ucc o─────────────┐ Ucc o───────────┐<br />
│ │<br />
┏┷┓ An: GND ___ ┃<<br />
┃ ┃ R_Last o───┤___├──┨ PNP<br />
┗┯┛ Aus: Ucc ┃\<br />
│ │<br />
An: Ucc ___ ┃/ ┏┷┓<br />
o───┤___├────┨ NPN ┃ ┃ R_Last<br />
Aus: GND ┃> ┗┯┛<br />
│ │<br />
GND o─────────────┘ GND o───────────┘<br />
</pre><br />
<br />
Siehe [[Basiswiderstand]] zur Berechnung des notwendigen Basiswiderstandes bei gegebener Last R_Last für einen Transistor als Schalter.<br />
<br />
Siehe auch Threads im Forum: <br />
* http://www.mikrocontroller.net/topic/58567 <br />
* http://www.mikrocontroller.net/topic/119841<br />
* oder im [http://www.elektronik-kompendium.de/sites/slt/0208031.htm Elektronik-Kompendium-Forum]<br />
<br />
Ist die zu schaltende Spannung '''genauso hoch''' wie die Steuerspannung darf die Last an den Emitter, und der Basiswiderstand entfällt. Der Transistor arbeitet als ''Impedanzwandler'' und steigert die Treiberfähigkeit des Mikrocontroller-Ausgangs in den Ampere-Bereich. Dieser Trick funktioniert '''nur''' mit Bipolartransistoren.<br />
<br />
Ist die effektive Invertierung des Schaltzustandes im oben angegebenen Bild lästig '''und''' der Strom geringer als der Ausgangsstrom, kann man den Transistor am Emitter steuern. Eine solche Schaltung funktioniert noch besser mit (Logik-Level-)MOSFETs und stellt eine einfache Kopplung zwischen Systemen mit unterschiedlicher Betriebsspannung (bspw. 1,8 V und 3,3 V) her. MOSFETs werden dazu am Source-Pin gesteuert, während das Gate an der „gegenüberliegenden“ Speisespannung „fixiert“ wird.<br />
<br />
=== Wie kann ich mit 5V vom Mikrocontroller 12V und mehr schalten? === <br />
Schau mal hier:<br />
* Wikiartikel [[Pegelwandler]]<br />
* [http://www.elektronik-kompendium.de/sites/praxis/bausatz_pegelwandler-mit-transistoren.htm Pegelwandler im ElKo]<br />
* [http://dl6gl.de/grundlagen/schalten-mit-transistoren schalten-mit-transistoren]<br />
<br />
oder in diesen Threads:<br />
*[http://www.mikrocontroller.net/topic/17899 Transistor als Schalter]<br />
*[http://www.mikrocontroller.net/topic/14437 Vcc schalten mit MOSFET]<br />
*[http://www.mikrocontroller.net/topic/29830 Schalten mit PNP-Transistor]<br />
*[http://www.mikrocontroller.net/topic/104027 Transistorschalter für Versorgungsspannung]<br />
*[http://www.mikrocontroller.net/topic/104951#921417 7-50V strombegrenzt schalten]<br />
*[http://www.mikrocontroller.net/topic/103116#900247 P-Kanal MOSFET ansteuern]<br />
*[https://www.mikrocontroller.net/topic/383039#4367479 5V/15mA mit 3,3V schalten]<br />
*[https://www.mikrocontroller.net/topic/401317#4638354 High Side Treiber mit Ladungspumpe]<br />
*[https://www.mikrocontroller.net/topic/347885?goto=3855574#3855574 minus -12V mit 3,3V schalten]<br />
*[https://www.mikrocontroller.net/topic/516373?goto=6650986#6650986 Kurzschlußfester Schalter für VCC]<br />
<br />
Bei der Kollektor-Schaltung entspricht die Spannung am Emitter immer der an der Basis, daher ist sie nur bedingt geeignet. Zum Schalten können die folgenden Emitter-Schaltungen verwendet werden. Achtung: In der zweiten davon arbeitet T1 in Basisschaltung.<br />
<br />
Schalten gegen GND<br />
<br />
<pre><br />
+12V o------------------------+<br />
|<br />
.-. <br />
( X ) <br />
'-'<br />
|<br />
___ |/ T1,NPN <br />
uC PIN o---|___|-----| BC547 <br />
R2,4K7 |><br />
|<br />
GND o---------o--------------+<br />
</pre><br />
<br />
<br />
Schalten gegen +12V<br />
<br />
<pre><br />
+12V o--------------+----------------------+<br />
| |<br />
| ____ |< T2, PNP<br />
+--|____|----+--------| BC557<br />
R1,4K7 | |\<br />
|/T1,NPN |<br />
Vcc/+5V o--------------| BC547 |<br />
|> |<br />
___ | .-. <br />
uC PIN o-----|___|------+ ( X ) <br />
R2,4K7 '-'<br />
|<br />
GND o----------o--------------------------+<br />
</pre><br />
<br />
=== Transistor an µC ohne Vorwiderstand === <br />
<br />
Normalerweise sind IO Pins vom µC nicht in der Lage, große Ströme zu treiben, beim AVR maximal ~20mA. Für einen kleinen Transistor ist das immer noch zu viel und es wäre auch Stromverschwendung.<br />
<br />
Deshalb kann man den IO-Pin des AVRs einfach als Tristate Eingang einstellen (Portpin als Eingang und Pullup deaktivieren), damit kein Basisstrom fließt.<br />
<br />
Aktiviert man nun den internen Pullup-Widerstand des AVRs, agiert dieser als Basisvorwiderstand, und es fließt nur ein geringer Basisstrom (die Pullups eines AVRs liegen irgendwo bei 50k bis 100k Ohm - siehe Datenblatt).<br />
<br />
Nur sollte man bei kleinen Transistoren aufpassen, dass man den Portpin in der Software nie als aktiven Ausgang schaltet. <br />
<br />
Wenn der verwendete µC zuschaltbare Pulldown-Widerstände an seinen Pins besitzt, kann man das gleiche auch mit einem PNP-Transistor machen (natürlich nur den Pulldown aktivieren).<br />
<br />
Eine Anwendung wären z.&nbsp;B. Nixie-Röhren-Kathodentreiber (geringe Stromverstärkung nötig).<br />
<br />
=== Wann bipolare (NPN/PNP) und wann FETs (insbesonders, wenn LEDs im Spiel sind)?=== <br />
Oft sind bipolare Transistoren (NPN/PNP) schon ausreichend, vor allem wenn "normale" LEDs (20mA) verwendet werden. FETs sind u.a. dann gut, wenn mit geringen Eingangsströmen hohe Ausgangsströme (über 300 mA) geschaltet werden sollen, also bei den Power-LEDs (Luxeon...).<br />
<br />
Ein Grenzfall: 500mA/5V schalten, siehe http://www.mikrocontroller.net/topic/62327.<br />
<br />
=== Wieso gehen bei einer Multiplex-Anzeige mit Schieberegister 74HC595 und (Darlington-)Transistor als Zeilentreiber die LED nicht ganz aus? ===<br />
Das liegt an der '''Miller-Kapazität''' des übersteuerten (Darlington-)Transistors. Der braucht erst mal einige 10µs, um zu sperren. Du mußt also erstmal beide Zeilen ausschalten, dann etwas warten und dann die nächste Zeile an. Oder Du ersetzt die Darlington durch P-FETs. [http://www.mikrocontroller.net/topic/132545]<br />
<br />
=== Wie steuert man ein Relais? ===<br />
Normalerweise verwendet man zur Ansteuerung von Relais NPN-Transistoren in Emitterschaltung. Freilaufdiode nicht vergessen! <br />
<br />
Siehe auch:<br />
* [[Relais mit Logik ansteuern]]<br />
* [http://www.mikrocontroller.net/attachment/22023/Relaisanteuerung.png Schaltbilder aus dem Forum]<br />
<br />
=== Was ist die Spannung <math>U_{BE\_sat}</math> (lt. Datenblatt max. 1,2V)? ===<br />
Bekanntlich verhält sich die Basis-Emitter Strecke eines Transistors wie eine Diode und <math>U_{BE\_sat}</math> ist die bei maximal zulässigem Basisstrom anliegende Vorwärtsspannung.<br />
<br />
=== Was bewirkt ein Kondensator (100µF-1nF) parallel zur Basis-Emitter-Strecke nach Masse? === <br />
Er wirkt mit dem Basisvorwiderstand als RC-Tiefpass. Damit wird der Transistor eigentlich nicht mehr als Schalter, sondern als Linearregler betrieben. Manche Verstärker-Schaltungen sind, gerade bei hohen Lasten, sehr schwingfreudig. Deswegen ist bei PWM so ein C nicht sinnvoll.<br />
<br />
=== Gibt es einen IC, der wie mehrere Transistoren funktioniert? ===<br />
<br />
Gibt es! Beispielsweise der '''ULN2803''' ist ein 8-fach Darlington Transistor Array mit [[Ausgangsstufen_Logik-ICs#Open_Collector|Open-Collector Ausgang]]. Damit lässt sich z.&nbsp;B. ein Leistungstreiber zur Ansteuerung von Schrittmotoren, Relais und anderen induktiven Lasten aufbauen.<br />
<br />
=== Gibt es ein Transistor-Array wie ULN28xx, das gegen Vcc schaltet? ===<br />
<br />
Such mal nach UDN29xx, z.&nbsp;B. UDN2981, UDN2987 ...<br />
<br />
Allegro hat zwischenzeitlich seinen Source-Treiber umbenannt. Die Bauteile heißen jetzt A2981, A2982 usw... Die Datenblätter sind identisch geblieben.<br />
<br />
Nachteil eines Darlington-Source-Treibers ist die hohe Sättigungsspannung (VceSat) von typisch 1,2 V. Die Eingangsspannung sollte dementsprechend höher ausgelegt werden oder gleich ein Source-Treiber mit MOSFET-Transistoren gewählt werden (z.B. Infineon ProFETs).<br />
<br />
=== Wann setzt man einen MOSFET, Bipolartransistor, IGBT oder Thyristor ein? ===<br />
siehe [[Leistungselektronik]]<br />
<br />
Die Summe allen Übels ist konstant. Man muss wissen, welches Bauteil sich wofür besonders eignet.<br />
<br />
====[[FET | MOSFET]]====<br />
<br />
Vorteile<br />
* Bei niedrigen Spannungen <100V sehr gut geeignet, <200V gut geeignet, sehr geringe R_DS-ON Widerstände möglich (einstelliger mOhm-Bereich)<br />
* Hohe Schaltgeschwindigkeiten möglich<br />
* Geringe An- und Ausschaltverluste<br />
* Statisch praktisch leistungslos steuerbar<br />
* Bodydiode kann als Freilaufdiode in H-Brücken verwendet werden<br />
* 2. Durchbruch bei Überschreiten der max. Drain-Source Sperrspannung zerstört das Bauteil nicht, wenn der Strom sowie die Energie begrenzt werden. (Verhalten wie [[Diode | Z-Diode]])<br />
<br />
Nachteile<br />
*Antiparallele Diode (Bodydiode) ist in nahezu allen MOSFETs unvermeidlich, daduch Sperren nur in einer Polarität möglich, Stromfluss über den MOSFET aber in beiden Richtungen möglich (Inversbetrieb, Synchrongleichrichter)<br />
* Bei Sperrspannungen >100V deutlich steigende Einschaltwiderstände (R_DS-ON)<br />
* Schnelles Umschalten erfordert hohe Lade-und Entladeströme ([[MOSFET-Übersicht#Mosfet-Treiber|MOSFET-Treiber]])<br />
* Leitverluste quadratisch proportional zum Strom, Pv = I²*R_DS-ON<br />
<br />
====[[Transistor | Bipolartransistor]]====<br />
<br />
Vorteile<br />
* Hohe Spannungsfestigkeiten möglich, bis zu 2000V<br />
* Sehr hohe Schaltgeschwindigkeiten möglich<br />
* Leitverluste etwa linear proportional zum Strom und Kollektor-Emitter-Sättigungsspannung, Pv = I * Uce-sat, U_CEC-sat typ 0,1...2.5 V<br />
<br />
Nachteile<br />
* Stromgesteuert, damit wird immer eine gewisse Ansteuerleistung benötigt<br />
* Bei grossen Kollektorströmen nimmt die Stromverstärkung deutlich ab, dann wird ein großer Basisstrom benötigt<br />
* 2. Durchbruch bei Überschreiten der max. Kollektor-Emitter Sperrspannung zerstört das Bauteil<br />
<br />
====[[IGBT]]====<br />
<br />
Vorteile<br />
* Hohe Spannungsfestigkeiten möglich, bis zu 6600V, in üblichen Bauformen bis ca 1700V gut verfügbar<br />
* Statisch praktisch leistungslos steuerbar<br />
* Mit oder ohne antiparallele Diode zur Kollektor-Emitter-Strecke verfügbar<br />
* Leitverluste linear proportional zum Strom und Kollektor-Emitter-Sättigungsspannung, Pv = I * Uce-sat, U_CE-sat typ. 2V<br />
<br />
Nachteile<br />
* Nur mäßige Schaltfrequenzen möglich (typ. <30..50kHz)<br />
* Schnelles Umschalten erfordert hohe Lade-und Entladeströme ([[MOSFET-Übersicht#Mosfet-Treiber|MOSFET-Treiber]])<br />
* 2. Durchbruch bei Überschreiten der max. Kollektor-Emitter Sperrspannung zerstört das Bauteil<br />
<br />
====[[TRIAC]]/Thyristor====<br />
<br />
Vorteile:<br />
* Sehr hohe Spannungsfestigkeiten möglich (800V...mehrere kV, Thyristoren bis 12kV)<br />
* Mit kurzen Pulsen einschaltbar, danach Selbsthaltung des Stromflusses<br />
* Leitverluste linear proportional zum Strom, Pv = I * Uak, Uak typ. 0,8...1,5 V <br />
<br />
Nachteile<br />
* Auf niedrige Schaltfrequenzen beschränkt (kHz-Bereich, Schaltzeit im Bereich von µs)<br />
* Anstiegsgeschwindigkeit des Stromes muss begrenzt werden, sonst kommt es zu Bauteilschäden<br />
* Anstiegsgeschwindigkeit der Spannung muss begrenzt werden, sonst kommt es zum ungewollten Zünden<br />
* Stromfluss kann nicht ausgeschaltet werden, damit meist nur Einsatz an Wechselspannung<br />
<br />
{| class="wikitable" style="width:50em"<br />
|- <br />
! style="width:10em" | Bauteil <br />
! style="width:12em" | optimales<br>Einsatzgebiet<br />
! Kommentar<br />
|-<br />
| MOSFET || 0..200V, 0..500A || im Kleinspannungsbereich meist die beste Wahl als Schalter<br />
|-<br />
| Bipolartransistor || 0..1000V, 0..10A || wird mehr und mehr von MOSFETs verdrängt<br />
|-<br />
| IGBT || 200..1700V, 0..500A || optimal für hohe Spannungen und hohe Ströme<br />
|-<br />
| Triac/Thyristor || 230V, 400V, 680V,<br>bis mehrere kV, 0..100A || meist für Wechselspannung, <br>Thyristoren bis 1000A im Dauerbetrieb, <br>im Pulsbetrieb einige kA. (Scheibenzelle)<br />
|}<br />
<br />
=== Wie finde ich den richtigen Transistor für eine LED-Ansteuerung? ===<br />
<br />
Quelle: Beiträge [http://www.mikrocontroller.net/topic/157763#1493623] und [http://www.mikrocontroller.net/topic/157763#1494972] von yalu<br />
<br />
Um am Anfang wenigstens ein bisschen den Durchblick im Transistordschungel zu behalten, kannst du folgendermaßen vorgehen:<br />
<br />
'''Nomenklatur'''<br />
<br />
Nach der amerikanischen Nomenklatur beginnen die Transistornamen meist mit 2N (z.&nbsp;B. 2N2222 oder 2N3055) und nach der japanischen mit 2S (z.&nbsp;B. 2SC1815). Für den Anfang kann man sich auf europäische Transistoren beschränken, da es diese in ausreichender Auswahl gibt und die Bezeichnungen relativ gut den Transistortyp wiedergeben:<br />
<br />
Der erste Buchstabe bezeichnet das Halbleitermaterial (A=Germanium, B=Silizium). Germaniumtransistoren werden heute nur noch selten verwendet.<br />
<br />
Der zweite Buchstabe steht für den Einsatzzweck (C=Universal, D=hohe Leistung, F=Hochfrequenz, U=hohe Spannung).<br />
<br />
So ist also ein ACxxx ein Germaniumuniversaltransistor und ein BDxxx ein Siliziumleistungstransistor.<br />
<br />
'''Auswahl'''<br />
<br />
Wenn du dich für einen Grundtyp entschieden hast (für die LED ist ein BC-Typ das Richtige), gehst du auf die Webseite eines Elektronikhändlers (Reichelt, Kessler usw.), schlägst die Seite mit den BC-Transistoren auf. Da gibt es natürlich sehr viele davon, und du brauchst jetzt eine<br />
Suchreihenfolge. Als erstes Auswahlkriterium nimmst du den Preis, denn:<br />
<br />
* Zuviel Geld hast wahrscheinlich nicht einmal du.<br />
* Billig ist meist das, was in großen Stückzahlen hergestellt wird. Was für die Masse gut ist, ist (zumindest in diesem Fall) meist auch für dich gut.<br />
* Was billig und damit in Massen verkauft wird, bekommst du auch bei anderen Händlern und auch noch in 10 Jahren. Das ist wichtig, wenn deine Schaltung irgendwann einmal in Serie gefertigt werden soll.<br />
<br />
Gleich als nächstes überlegst du, ob du einen NPN- oder einen PNP-Typ brauchst. Das ergibt sich aus der Anordnung der Bauteile in deiner Schaltung. Hast du die Möglichkeit, die Schaltung wahlweise für einen NPN- oder einen PNP-Typ auszulegen, wählst du die Variante mit dem NPN-Typ. Um einfach eine LED über einen Mikrocontroller einzuschalten, ist i.Allg. ein NPN-Typ in Emitterschaltung richtig.<br />
<br />
Ein weiteres wichtiges Kriterium ist die Befestigungstechnik: Wenn dir die SMD-Löterei etwas suspekt ist, lässt du die entsprechenden Modelle erst einmal alle außen vor. Ein typisches Nicht-SMD-Gehäuse für Universaltransistoren ist TO-92. Es gibt im Internet bebilderte Listen mit den einzelnen Gehäuseformen ([[IC-Gehäuseformen#Weblinks]])<br />
<br />
Wenn du jetzt also bei Reichelt die BC-Transistoren nach Preis aufsteigend sortiert hast, siehst du erst einen Schwung SMD-Tranistoren. Dann kommen ein paar Transistoren im TO-92-Gehäuse, die sind aber PNP. Etwas weiter unten kommt der erste NPN-Transistor in TO-92, nämlich der BC547C. Netterweise stehen gleich ein paar Eckdaten dabei:<br />
<br />
<pre><br />
BC547C 45V 0,1A 0,5W<br />
</pre><br />
<br />
Die 45V sind die maximale Kollektor-Emitter-Spannung, in deinem Fall also die Spannung, die du maximal schalten kannst. Da die LED bei Weitem keine 45V braucht und deine Versorgungsspannung eher in der Gegend von 5V liegt, bist du auf jeden Fall auf der sicheren Seite.<br />
<br />
Deine LED wird typisch mit 20mA (max. 30mA) betrieben. Der BC547C kann 100mA, also ist auch hier noch Luft.<br />
<br />
Zur maximalen Verlustleistung (0,5W): Wenn deine LED eingeschaltet ist, fließen bspw. 20mA. Ist der Transistor voll durchgesteuert (in Sättigung) beträgt die Kollektor-Emitter-Spannung bei diesem geringen Strom typischerweise zwischen 0,1V und 0,2V (Genaueres steht im Datenblatt). Am Transistor wird also maximal die Leistung 20mA·0,2V=4mW in Wärme umgesetzt. Bis zu 500mW dürfen es sein, also ebenfalls ok.<br />
<br />
Nachdem du den Transistor in engere Auswahl gezogen hast, lohnt sich auf jeden Fall ein Blick ins Datenblatt. Aus den Tabellen und Diagrammen erfährst du bspw., wie hoch der Basisstrom sein muss, um den Kollektorstrom von mindestens 20mA bei ausreichend geringer CE-Spannung bereitzustellen. Dort ist auch erklärt warum es einen BC547A, BC547B und BC547C gibt. Der letzte Buchstabe gibt nämlich die Stromverstärkungsklasse an. Da eine hohe Stromverstärkung meist wünschenswert ist und in diesem Fall keinen Aufpreis kostet, ziehst du den BC547C den anderen beiden vor.<br />
<br />
Da in deiner Anwendung HF- und Rauschverhalten keine Rolle spielen, bist du schon am Ziel angelangt.<br />
<br />
Würde deine LED 100mA statt 20mA benötigen, wären die max. 100mA des BC547 etwas knapp bemessen. Du blätterst also in der Reichelt-Liste weiter und stößt auf den BC337-40 mit 45V, 0,5A und 0,525W. Das ist genau das, wonach du suchst. Bei diesem Transistor sind die Stromverstärkungsklassen durch die Endungen -16, -25 und -40 gekennzeichnet. Es wäre ja auch<br />
zu einfach, wenn immer nur A, B und C verwendet würde ;-)<br />
<br />
Bei Strömen ab etwa 500mA kommt man an die Grenze der Leistungsfähigkeit der BC-Typen. Dann geht es weiter mit BD. Der BD135 geht bspw. schon bis 1,5A. Das Problem bei solchen größeren Transistoren: Die Stromverstärkung ist nicht besonders hoch, so dass irgendwann der Mikrocontroller nicht mehr den benötigten Basisstrom liefern kann. Dann muss dem großen Transistor ein kleiner vorangeschaltet werden, um den erhöhten Basisstrom bereitszustellen. Man kann diese Kombination von zwei Transistoren auch fertig als Darlington-Transistor kaufen, von denen ebenfalls einige in der BD-Reihe zu finden sind (z.&nbsp;B. BD647). Ein Transistortyp, der sich sehr gut zum Schalten höherer Ströme eignet, ist der [[FET | MOSFET]].<br />
<br />
Wie schon oben angedeutet: Wenn die 30-80V die die meisten BC- und BD-Transistoren abkönnen, nicht ausreichen, suchst du weiter bei BU.<br />
<br />
Steigst du in die HF-Technik ein, sind BF-Transistoren eher das Richtige, wobei bei HF-Anwendungen die Auswahl der Transistoren nicht mehr das Schwierigste ist ;-)<br />
<br />
'''Und wie geht's weiter?'''<br />
<br />
Man könnte natürlich noch viel mehr zu diesem Thema schreiben. Ich hoffe aber, dass das Geschriebene dir wenigstens grob zeigt, wie man bei nicht allzu speziellem Anforderungen relativ schnell zu einem gewünschten Transistortyp kommt, der nicht nur die technischen Anforderungen erfüllt, sondern auch leicht beschaffbar ist.<br />
<br />
Werden die Anforderungen spezieller, helfen oft die Selektionstabellen auf den Webseiten der einschlägigen Hersteller weiter. Auch Händler wie Farnell haben teilweise ganz gute Auswahlwerkzeuge. <br />
<br />
Wenn du dich intensiv mit Elektronik beschäftigst, wirst du wahrscheinlich noch viele Schaltungen von Leuten zu Gesicht bekommen, die vielleicht schon etwas weiter fortgeschritten sind. Dabei wirst du immer wieder auf bestimmte Standardtypen von Transistoren (und auch anderen Bauteilen wie Operationsverstärker u.ä.) stoßen und sehen, welche [[Standardbauelemente]] "man" üblicherweise für bestimmte Anwendungen einsetzt. Mit der Zeit setzt sich dann eine Auswahl von bspw. 10 oder 20 verschiedenen Transistoren und 5 bis 10 verschiedenen OpAmps im Kopf fest, von denen man die wesentlichen Parameter auswendig kennt, so dass man ohne aufwendige Suche eine schnelle Auswahl treffen kann. Auch hier in der Artikelsammlung gibt es eine solche [[Transistor-Übersicht]].<br />
<br />
=== Wo ist die Antwort auf meine Frage? ===<br />
<br />
Vielleicht im Forum? Falls du sie da findest, dann pack das ganze doch hier rein.<br />
<br />
[http://www.mikrocontroller.net/topic/165580 Gegen Vcc oder GND schalten]<br />
<br />
== Siehe auch ==<br />
* [[Basiswiderstand]]<br />
* [[Transistor-Übersicht]]<br />
* [[AVR_Transistortester]] - neu (Weiterentwickelt von Karl-Heinz Kübbeler)<br />
* [[AVR-Transistortester]] - alte (von Markus Frejek)<br />
* [[Leistungselektronik]]<br />
<br />
== Gehäusebauformen von Transistoren ==<br />
<br />
=== TO-92 ===<br />
Ein kleiner Aufsatz über TO-92 Transistorgehäuse und Footprints findet sich unter: [[Media:TO-92-Gehaeuse_RevB2.pdf]]. <br />
<br />
<br />
<br />
== Weblinks ==<br />
* [http://de.wikipedia.org/wiki/transistor "Transistor" bei Wikipedia]<br />
* [http://www.elektronik-kompendium.de www.elektronik-kompendium.de]<br />
** [http://www.elektronik-kompendium.de/sites/bau/0201291.htm Elko/Transistor]<br />
* http://www.elektronikinfo.de/strom/bipolartransistoren.htm<br />
* http://www.ferromel.de/tronic_1870.htm<br />
* [http://www.DieElektronikerseite.de Die Elektronikerseite] Lehrgang: Der Transistor - Ein Tausendsassa<br />
* [http://www.infoplease.com/encyclopedia/science/transistor-types-transistors.html Transistortypen]<br />
* [http://electronics-electrical.exportersindia.com/electronic-components/transistors.htm Transistoren Industrieunternehmen Geschäftsauflistungen]<br />
<br />
[[Category:Bauteile]]<br />
[[Category:Grundlagen]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=Transistor&diff=107009Transistor2024-07-11T10:06:04Z<p>Heha: /* PNP/NPN als Schalter, wohin mit der Last? */</p>
<hr />
<div>Kunstwort aus "transfer resistor", was etwa so viel bedeutet wie "übertragener [[Widerstand]]".<br />
<br />
In den 1950-ern als praktische Anwendung des [[Halbleiter]]-Effekts erfundenes "solid state" Schalt- und Verstärkerelement, welches sehr klein ist, ohne bewegte Teile auskommt (anders als ein klassisches Relais) und keine energiefressende Heizung benötigt (anders als eine Röhre).<br />
<br />
Vom "bipolaren Transistor" (PNP, NPN) weiterentwickelt zum "Feldeffekt-Transistor" ([[FET]]), der heute - gefertigt mit einem preiswerten Verfahren unter Verwendung von Metall-Oxid-Schichten (MOS) - ein wesentliches Element integrierter Schaltkreise (ICs, integrated circuits) darstellt, und damit natürlich auch von [[Mikrocontroller]]n, um die es in diesem Wiki hauptsächlich geht (bzw. gehen sollte).<br />
<br />
== Schaltzeichen ==<br />
[https://electronicsclub.info/images/transbce.gif]<br />
<br />
* E: Emitter<br />
* B: Basis<br />
* C: Collector <br />
<br />
<br />
In ASCII Schaltplänen sehen Transistoren so aus:<br />
<pre> <br />
|> |/<br />
NPN |> oder -| oder -|<br />
|\ |><br />
<br />
|< |/<br />
PNP: |< oder -| oder -|<br />
|\ |<<br />
</pre><br />
<br />
Um zu erkennen, ob ein NPN oder PNP Transistor im Schaltplan verwendet wird, gibt es Eselsbrücken:<br />
*Für Dichter: '''Tut der Pfeil der Basis weh, handelt's sich um PNP.'''<br />
*Für Praktiker: '''PNP heisst "Pfeil Nach Platte"'''.<br />
*Mit Dialekt: '''NPN "'naus, Pfeil, 'naus"'''.<br />
*..und für Gleichberechtigungsverfechter: '''NPN means "Not Pointing iN"'''.<br />
<br />
<br />
<br />
JFET: [[Bild:Transistor_JFET.png]]<br />
<br />
MOSFET: [[Bild:Transistor_MOSFET.png]]<br />
<br />
* S: Source<br />
* G: Gate<br />
* D: Drain<br />
<br />
Eigentlich haben MOSFETs noch einen vierten Anschluss namens Bulk. Der ist aber nur bei Spezialtypen als Pin herausgeführt. Im Normalfall kann man ihn vergessen, da er nicht gesondert beschaltet werden muss, er ist praktisch und auch im Symbol mit Source verbunden.<br />
<br />
'''Achtung:''' Die NPN/PNP Eselsbrücken funktionieren bei FETs nicht, denn bei einem P-Kanal FET zeigt der Pfeil weg vom FET!<br />
Ein Bipolartransistor, im Englischen als bipolar junction transistor (BJT) bezeichnet, ist ein Transistor, bei dem Ladungsträger – negativ geladene Elektronen und positiv geladene Defektelektronen – zum Stromtransport durch den Bipolartransistor beitragen. Der BJT wird mittels eines elektrischen Stroms gesteuert und wird zum Schalten und Verstärken von Signalen ohne mechanisch bewegte Teile eingesetzt.<br />
<br />
Bipolare Leistungstransistoren sind für das Schalten und Verstärken von Signalen höherer Stromstärken und Spannungen ausgelegt.<br />
<br />
== Typbezeichnungen == <br />
<br />
Neben den Typbezeichnungen wie 2Nxxxx, TIPxxx, MJxxx, MJExx gibt es noch die in Europa geläufigere Kennzeichnung bestehend aus zwei Buchstaben und drei Ziffern. Die diversen Kennzeichnungsmöglichkeiten sind in einem eigenen Artikel ([[Kennzeichnung von Halbleitern]]) zusammengefasst.<br />
<br />
== Kenndaten/Parameter ==<br />
<br />
Im [http://www.mikrocontroller.net/topic/197676#1938546 Beitrag: Transistorparameter Erklärung] sind Links zu Erläuterungen spezieller Kürzel.<br />
<br />
== Transistor Grundschaltungen ==<br />
<br />
Generell gilt, dass Strom vom Kollektor zum Emitter nur dann fließen kann, wenn die Basis positiver (NPN) bzw. negativer (PNP) wird als der Emitter. Dabei darf die Basis nicht direkt mit Vcc (NPN) oder GND (PNP) verbunden werden, da der Basisstrom sonst zu gross wird. Es muss jeweils ein geeigneter Basiswiderstand (R_Basis) gewählt werden.<br />
<br />
'''Weitere Links:'''<br />
* Artikel [[Basiswiderstand]]<br />
* [http://www.elektronik-kompendium.de/sites/slt/0203111.htm Transistor Grundschaltungen im ElKo]<br />
* [http://www.roboternetz.de/wissen/index.php/Transistor Transistor bei RoboterNetz.de]<br />
<br />
Es gibt drei Grundschaltungen. Der Name beschreibt den Anschluss, welcher sich auf einem festen Potential (Spannung) befindet. Die beiden anderen Anschlüsse haben bedingt durch die Schaltung ein veränderliches Potential.<br />
<br />
=== Kollektorschaltung (Emitterfolger)===<br />
<br />
'''Anwendung:'''<br />
* Impedanzwandler<br />
* Darlington-Schaltung<br />
* Schalter<br />
<br />
'''Eigenschaften:'''<br />
* Keine Phasendrehung<br />
* Hohe Stromverstärkung<br />
* Keine Spannungsverstärkung<br />
<br />
'''Beispiel: Transistor als Schalter'''<br />
<br />
* NPN: Kollektor mit Vcc verbinden, Last an Emitter<br />
* PNP: Kollektor mit GND verbinden, Last an Emitter<br />
<br />
In diesem Fall regelt der Transistor die Spannungen am Emitter, daher wird die Last am Emitter angeschlossen. Die Spannung am Emitter entspricht immer der an der Basis minus 0,6V, sie folgt der Basisspannung, deswegen auch der Name Emitterfolger. Daher ist diese Schaltung nicht geeignet, um 12V mit 5V zu schalten. <br />
<br />
{|<br />
|-<br />
| [[Bild:NPN_Collector.gif | framed | center | NPN Transistor in Kollektorschaltung]] <br />
|| [[Bild:PNP_Collector.gif | framed | center | PNP Transistor in Kollektorschaltung]] <br />
|}<br />
* NPN: Wird <math>R_{Poti}</math> (Spannungsteiler) erhöht, '''steigt''' die Spannung <math>U_{Last}</math> letztlich bis auf VCC-0,6V (Basis-Emitter-Übergang).<br />
* PNP: Wird <math>R_{Poti}</math> (Spannungsteiler) erhöht, '''sinkt''' Spannung an <math>U_{Last}</math> letztlich bis auf 0,6V (Basis-Emitter-Übergang).<br />
<br />
'''Weitere Links:'''<br />
* [http://www.elektronik-kompendium.de/sites/slt/0204133.htm Kollektorschaltung im ElKo]<br />
<br />
=== Emitterschaltung ===<br />
<br />
Die Emitterschaltung bietet hohe Spannungs- und Stromverstärkung.<br />
<br />
'''Anwendung:'''<br />
* NF- und HF-Verstärker<br />
* Leistungsverstärker<br />
* Transistor als Schalter<br />
<br />
'''Eigenschaften:'''<br />
* Phasendrehung 180°<br />
* Hohe Spannungsverstärkung<br />
* Hohe Stromverstärkung<br />
<br />
<br />
'''Beispiel: Transistor als Schalter'''<br />
<br />
Die Last liegt am Kollektor. Der Strom durch den Schalter oder an U_Schalt steuert den Strom zwischen Kollektor und Emitter. Wird der Schalter geschlossen, fließt ein Strom.<br />
<br />
[[Bild:NPN_Schalter.gif | framed | center | NPN Transistor als Schalter]]<br />
<pre><br />
___ ___<br />
Vcc/+ o-----------------------+ Vcc/+ o-----------------------+<br />
| |<br />
___ |< U_schalt (-) ___ |< PNP <br />
+------|___|---| PNP o------------|___|----|<br />
| R_Basis |\ R_Basis |\<br />
Schalter \ | |<br />
| ___ | ___ |<br />
GND/- o------+------|___|-----+ GND/- o-------------|___|-----+<br />
R_Last R_Last <br />
<br />
</pre><br />
<br />
<br />
'''Weitere Links:'''<br />
* [http://www.elektronik-kompendium.de/sites/slt/0204302.htm Emitterschaltung im ElKo]<br />
<br />
=== Basisschaltung ===<br />
<br />
Die Basisschaltung findet sich vor allem in Eingangsstufen in der HF-Technik. Im Schaltbetrieb wird sie praktisch nur zur [[Pegelwandler#STEP-UP: 5V -> 9..15V | Pegelwandlung]] für nachfolgende Stufen verwendet.<br />
<br />
'''Eigenschaften:'''<br />
* Geringe Eingangsimpedanz<br />
* Keine Phasenverschiebung<br />
* Hohe Bandbreite<br />
<br />
'''Weitere Links:'''<br />
* [http://www.elektronik-kompendium.de/sites/slt/0205081.htm Basisschaltung im ElKo<br />
<br />
== FAQ aus dem Forum ==<br />
<br />
=== PNP/NPN als Schalter, wohin mit der Last? === <br />
Für viele einfache Anwendungen kann man sich merken: '''Bei Schaltanwendungen darf der Basisstrom nicht durch die Last fließen''' (… wenn die zu schaltende Spannung höher ist als die Steuerspannung). Normalerweise kommt dabei die Emitterschaltung zum Einsatz, die Last kommt also an den Kollektor.<br />
<br />
<pre><br />
Vcc o─────────────┐ Vcc o───────────┐<br />
│ │<br />
┏┷┓ An: GND ___ ┃<<br />
┃ ┃ R_Last o───┤___├──┨ PNP<br />
┗┯┛ Aus: Vcc ┃\<br />
│ │<br />
An: Vcc ___ ┃/ ┏┷┓<br />
o───┤___├────┨ NPN ┃ ┃ R_Last<br />
Aus: GND ┃> ┗┯┛<br />
│ │<br />
GND o─────────────┘ GND o───────────┘<br />
</pre><br />
<br />
Siehe [[Basiswiderstand]] zur Berechnung des notwendigen Basiswiderstandes bei gegebener Last R_Last für einen Transistor als Schalter.<br />
<br />
Siehe auch Threads im Forum: <br />
* http://www.mikrocontroller.net/topic/58567 <br />
* http://www.mikrocontroller.net/topic/119841<br />
* oder im [http://www.elektronik-kompendium.de/sites/slt/0208031.htm Elektronik-Kompendium-Forum]<br />
<br />
Ist die zu schaltende Spannung '''genauso hoch''' wie die Steuerspannung darf die Last an den Emitter, und der Basiswiderstand entfällt. Der Transistor arbeitet als ''Impedanzwandler'' und steigert die Treiberfähigkeit des Mikrocontroller-Ausgangs in den Ampere-Bereich. Dieser Trick funktioniert '''nur''' mit Bipolartransistoren.<br />
<br />
Ist die effektive Invertierung des Schaltzustandes im oben angegebenen Bild lästig '''und''' der Strom geringer als der Ausgangsstrom, kann man den Transistor am Emitter steuern. Eine solche Schaltung funktioniert noch besser mit (Logik-Level-)MOSFETs und stellt eine einfache Kopplung zwischen Systemen mit unterschiedlicher Betriebsspannung (bspw. 1,8 V und 3,3 V) her. MOSFETs werden dazu am Source-Pin gesteuert, während das Gate an der „gegenüberliegenden“ Speisespannung „fixiert“ wird.<br />
<br />
=== Wie kann ich mit 5V vom Mikrocontroller 12V und mehr schalten? === <br />
Schau mal hier:<br />
* Wikiartikel [[Pegelwandler]]<br />
* [http://www.elektronik-kompendium.de/sites/praxis/bausatz_pegelwandler-mit-transistoren.htm Pegelwandler im ElKo]<br />
* [http://dl6gl.de/grundlagen/schalten-mit-transistoren schalten-mit-transistoren]<br />
<br />
oder in diesen Threads:<br />
*[http://www.mikrocontroller.net/topic/17899 Transistor als Schalter]<br />
*[http://www.mikrocontroller.net/topic/14437 Vcc schalten mit MOSFET]<br />
*[http://www.mikrocontroller.net/topic/29830 Schalten mit PNP-Transistor]<br />
*[http://www.mikrocontroller.net/topic/104027 Transistorschalter für Versorgungsspannung]<br />
*[http://www.mikrocontroller.net/topic/104951#921417 7-50V strombegrenzt schalten]<br />
*[http://www.mikrocontroller.net/topic/103116#900247 P-Kanal MOSFET ansteuern]<br />
*[https://www.mikrocontroller.net/topic/383039#4367479 5V/15mA mit 3,3V schalten]<br />
*[https://www.mikrocontroller.net/topic/401317#4638354 High Side Treiber mit Ladungspumpe]<br />
*[https://www.mikrocontroller.net/topic/347885?goto=3855574#3855574 minus -12V mit 3,3V schalten]<br />
*[https://www.mikrocontroller.net/topic/516373?goto=6650986#6650986 Kurzschlußfester Schalter für VCC]<br />
<br />
Bei der Kollektor-Schaltung entspricht die Spannung am Emitter immer der an der Basis, daher ist sie nur bedingt geeignet. Zum Schalten können die folgenden Emitter-Schaltungen verwendet werden. Achtung: In der zweiten davon arbeitet T1 in Basisschaltung.<br />
<br />
Schalten gegen GND<br />
<br />
<pre><br />
+12V o------------------------+<br />
|<br />
.-. <br />
( X ) <br />
'-'<br />
|<br />
___ |/ T1,NPN <br />
uC PIN o---|___|-----| BC547 <br />
R2,4K7 |><br />
|<br />
GND o---------o--------------+<br />
</pre><br />
<br />
<br />
Schalten gegen +12V<br />
<br />
<pre><br />
+12V o--------------+----------------------+<br />
| |<br />
| ____ |< T2, PNP<br />
+--|____|----+--------| BC557<br />
R1,4K7 | |\<br />
|/T1,NPN |<br />
Vcc/+5V o--------------| BC547 |<br />
|> |<br />
___ | .-. <br />
uC PIN o-----|___|------+ ( X ) <br />
R2,4K7 '-'<br />
|<br />
GND o----------o--------------------------+<br />
</pre><br />
<br />
=== Transistor an µC ohne Vorwiderstand === <br />
<br />
Normalerweise sind IO Pins vom µC nicht in der Lage, große Ströme zu treiben, beim AVR maximal ~20mA. Für einen kleinen Transistor ist das immer noch zu viel und es wäre auch Stromverschwendung.<br />
<br />
Deshalb kann man den IO-Pin des AVRs einfach als Tristate Eingang einstellen (Portpin als Eingang und Pullup deaktivieren), damit kein Basisstrom fließt.<br />
<br />
Aktiviert man nun den internen Pullup-Widerstand des AVRs, agiert dieser als Basisvorwiderstand, und es fließt nur ein geringer Basisstrom (die Pullups eines AVRs liegen irgendwo bei 50k bis 100k Ohm - siehe Datenblatt).<br />
<br />
Nur sollte man bei kleinen Transistoren aufpassen, dass man den Portpin in der Software nie als aktiven Ausgang schaltet. <br />
<br />
Wenn der verwendete µC zuschaltbare Pulldown-Widerstände an seinen Pins besitzt, kann man das gleiche auch mit einem PNP-Transistor machen (natürlich nur den Pulldown aktivieren).<br />
<br />
Eine Anwendung wären z.&nbsp;B. Nixie-Röhren-Kathodentreiber (geringe Stromverstärkung nötig).<br />
<br />
=== Wann bipolare (NPN/PNP) und wann FETs (insbesonders, wenn LEDs im Spiel sind)?=== <br />
Oft sind bipolare Transistoren (NPN/PNP) schon ausreichend, vor allem wenn "normale" LEDs (20mA) verwendet werden. FETs sind u.a. dann gut, wenn mit geringen Eingangsströmen hohe Ausgangsströme (über 300 mA) geschaltet werden sollen, also bei den Power-LEDs (Luxeon...).<br />
<br />
Ein Grenzfall: 500mA/5V schalten, siehe http://www.mikrocontroller.net/topic/62327.<br />
<br />
=== Wieso gehen bei einer Multiplex-Anzeige mit Schieberegister 74HC595 und (Darlington-)Transistor als Zeilentreiber die LED nicht ganz aus? ===<br />
Das liegt an der '''Miller-Kapazität''' des übersteuerten (Darlington-)Transistors. Der braucht erst mal einige 10µs, um zu sperren. Du mußt also erstmal beide Zeilen ausschalten, dann etwas warten und dann die nächste Zeile an. Oder Du ersetzt die Darlington durch P-FETs. [http://www.mikrocontroller.net/topic/132545]<br />
<br />
=== Wie steuert man ein Relais? ===<br />
Normalerweise verwendet man zur Ansteuerung von Relais NPN-Transistoren in Emitterschaltung. Freilaufdiode nicht vergessen! <br />
<br />
Siehe auch:<br />
* [[Relais mit Logik ansteuern]]<br />
* [http://www.mikrocontroller.net/attachment/22023/Relaisanteuerung.png Schaltbilder aus dem Forum]<br />
<br />
=== Was ist die Spannung <math>U_{BE\_sat}</math> (lt. Datenblatt max. 1,2V)? ===<br />
Bekanntlich verhält sich die Basis-Emitter Strecke eines Transistors wie eine Diode und <math>U_{BE\_sat}</math> ist die bei maximal zulässigem Basisstrom anliegende Vorwärtsspannung.<br />
<br />
=== Was bewirkt ein Kondensator (100µF-1nF) parallel zur Basis-Emitter-Strecke nach Masse? === <br />
Er wirkt mit dem Basisvorwiderstand als RC-Tiefpass. Damit wird der Transistor eigentlich nicht mehr als Schalter, sondern als Linearregler betrieben. Manche Verstärker-Schaltungen sind, gerade bei hohen Lasten, sehr schwingfreudig. Deswegen ist bei PWM so ein C nicht sinnvoll.<br />
<br />
=== Gibt es einen IC, der wie mehrere Transistoren funktioniert? ===<br />
<br />
Gibt es! Beispielsweise der '''ULN2803''' ist ein 8-fach Darlington Transistor Array mit [[Ausgangsstufen_Logik-ICs#Open_Collector|Open-Collector Ausgang]]. Damit lässt sich z.&nbsp;B. ein Leistungstreiber zur Ansteuerung von Schrittmotoren, Relais und anderen induktiven Lasten aufbauen.<br />
<br />
=== Gibt es ein Transistor-Array wie ULN28xx, das gegen Vcc schaltet? ===<br />
<br />
Such mal nach UDN29xx, z.&nbsp;B. UDN2981, UDN2987 ...<br />
<br />
Allegro hat zwischenzeitlich seinen Source-Treiber umbenannt. Die Bauteile heißen jetzt A2981, A2982 usw... Die Datenblätter sind identisch geblieben.<br />
<br />
Nachteil eines Darlington-Source-Treibers ist die hohe Sättigungsspannung (VceSat) von typisch 1,2 V. Die Eingangsspannung sollte dementsprechend höher ausgelegt werden oder gleich ein Source-Treiber mit MOSFET-Transistoren gewählt werden (z.B. Infineon ProFETs).<br />
<br />
=== Wann setzt man einen MOSFET, Bipolartransistor, IGBT oder Thyristor ein? ===<br />
siehe [[Leistungselektronik]]<br />
<br />
Die Summe allen Übels ist konstant. Man muss wissen, welches Bauteil sich wofür besonders eignet.<br />
<br />
====[[FET | MOSFET]]====<br />
<br />
Vorteile<br />
* Bei niedrigen Spannungen <100V sehr gut geeignet, <200V gut geeignet, sehr geringe R_DS-ON Widerstände möglich (einstelliger mOhm-Bereich)<br />
* Hohe Schaltgeschwindigkeiten möglich<br />
* Geringe An- und Ausschaltverluste<br />
* Statisch praktisch leistungslos steuerbar<br />
* Bodydiode kann als Freilaufdiode in H-Brücken verwendet werden<br />
* 2. Durchbruch bei Überschreiten der max. Drain-Source Sperrspannung zerstört das Bauteil nicht, wenn der Strom sowie die Energie begrenzt werden. (Verhalten wie [[Diode | Z-Diode]])<br />
<br />
Nachteile<br />
*Antiparallele Diode (Bodydiode) ist in nahezu allen MOSFETs unvermeidlich, daduch Sperren nur in einer Polarität möglich, Stromfluss über den MOSFET aber in beiden Richtungen möglich (Inversbetrieb, Synchrongleichrichter)<br />
* Bei Sperrspannungen >100V deutlich steigende Einschaltwiderstände (R_DS-ON)<br />
* Schnelles Umschalten erfordert hohe Lade-und Entladeströme ([[MOSFET-Übersicht#Mosfet-Treiber|MOSFET-Treiber]])<br />
* Leitverluste quadratisch proportional zum Strom, Pv = I²*R_DS-ON<br />
<br />
====[[Transistor | Bipolartransistor]]====<br />
<br />
Vorteile<br />
* Hohe Spannungsfestigkeiten möglich, bis zu 2000V<br />
* Sehr hohe Schaltgeschwindigkeiten möglich<br />
* Leitverluste etwa linear proportional zum Strom und Kollektor-Emitter-Sättigungsspannung, Pv = I * Uce-sat, U_CEC-sat typ 0,1...2.5 V<br />
<br />
Nachteile<br />
* Stromgesteuert, damit wird immer eine gewisse Ansteuerleistung benötigt<br />
* Bei grossen Kollektorströmen nimmt die Stromverstärkung deutlich ab, dann wird ein großer Basisstrom benötigt<br />
* 2. Durchbruch bei Überschreiten der max. Kollektor-Emitter Sperrspannung zerstört das Bauteil<br />
<br />
====[[IGBT]]====<br />
<br />
Vorteile<br />
* Hohe Spannungsfestigkeiten möglich, bis zu 6600V, in üblichen Bauformen bis ca 1700V gut verfügbar<br />
* Statisch praktisch leistungslos steuerbar<br />
* Mit oder ohne antiparallele Diode zur Kollektor-Emitter-Strecke verfügbar<br />
* Leitverluste linear proportional zum Strom und Kollektor-Emitter-Sättigungsspannung, Pv = I * Uce-sat, U_CE-sat typ. 2V<br />
<br />
Nachteile<br />
* Nur mäßige Schaltfrequenzen möglich (typ. <30..50kHz)<br />
* Schnelles Umschalten erfordert hohe Lade-und Entladeströme ([[MOSFET-Übersicht#Mosfet-Treiber|MOSFET-Treiber]])<br />
* 2. Durchbruch bei Überschreiten der max. Kollektor-Emitter Sperrspannung zerstört das Bauteil<br />
<br />
====[[TRIAC]]/Thyristor====<br />
<br />
Vorteile:<br />
* Sehr hohe Spannungsfestigkeiten möglich (800V...mehrere kV, Thyristoren bis 12kV)<br />
* Mit kurzen Pulsen einschaltbar, danach Selbsthaltung des Stromflusses<br />
* Leitverluste linear proportional zum Strom, Pv = I * Uak, Uak typ. 0,8...1,5 V <br />
<br />
Nachteile<br />
* Auf niedrige Schaltfrequenzen beschränkt (kHz-Bereich, Schaltzeit im Bereich von µs)<br />
* Anstiegsgeschwindigkeit des Stromes muss begrenzt werden, sonst kommt es zu Bauteilschäden<br />
* Anstiegsgeschwindigkeit der Spannung muss begrenzt werden, sonst kommt es zum ungewollten Zünden<br />
* Stromfluss kann nicht ausgeschaltet werden, damit meist nur Einsatz an Wechselspannung<br />
<br />
{| class="wikitable" style="width:50em"<br />
|- <br />
! style="width:10em" | Bauteil <br />
! style="width:12em" | optimales<br>Einsatzgebiet<br />
! Kommentar<br />
|-<br />
| MOSFET || 0..200V, 0..500A || im Kleinspannungsbereich meist die beste Wahl als Schalter<br />
|-<br />
| Bipolartransistor || 0..1000V, 0..10A || wird mehr und mehr von MOSFETs verdrängt<br />
|-<br />
| IGBT || 200..1700V, 0..500A || optimal für hohe Spannungen und hohe Ströme<br />
|-<br />
| Triac/Thyristor || 230V, 400V, 680V,<br>bis mehrere kV, 0..100A || meist für Wechselspannung, <br>Thyristoren bis 1000A im Dauerbetrieb, <br>im Pulsbetrieb einige kA. (Scheibenzelle)<br />
|}<br />
<br />
=== Wie finde ich den richtigen Transistor für eine LED-Ansteuerung? ===<br />
<br />
Quelle: Beiträge [http://www.mikrocontroller.net/topic/157763#1493623] und [http://www.mikrocontroller.net/topic/157763#1494972] von yalu<br />
<br />
Um am Anfang wenigstens ein bisschen den Durchblick im Transistordschungel zu behalten, kannst du folgendermaßen vorgehen:<br />
<br />
'''Nomenklatur'''<br />
<br />
Nach der amerikanischen Nomenklatur beginnen die Transistornamen meist mit 2N (z.&nbsp;B. 2N2222 oder 2N3055) und nach der japanischen mit 2S (z.&nbsp;B. 2SC1815). Für den Anfang kann man sich auf europäische Transistoren beschränken, da es diese in ausreichender Auswahl gibt und die Bezeichnungen relativ gut den Transistortyp wiedergeben:<br />
<br />
Der erste Buchstabe bezeichnet das Halbleitermaterial (A=Germanium, B=Silizium). Germaniumtransistoren werden heute nur noch selten verwendet.<br />
<br />
Der zweite Buchstabe steht für den Einsatzzweck (C=Universal, D=hohe Leistung, F=Hochfrequenz, U=hohe Spannung).<br />
<br />
So ist also ein ACxxx ein Germaniumuniversaltransistor und ein BDxxx ein Siliziumleistungstransistor.<br />
<br />
'''Auswahl'''<br />
<br />
Wenn du dich für einen Grundtyp entschieden hast (für die LED ist ein BC-Typ das Richtige), gehst du auf die Webseite eines Elektronikhändlers (Reichelt, Kessler usw.), schlägst die Seite mit den BC-Transistoren auf. Da gibt es natürlich sehr viele davon, und du brauchst jetzt eine<br />
Suchreihenfolge. Als erstes Auswahlkriterium nimmst du den Preis, denn:<br />
<br />
* Zuviel Geld hast wahrscheinlich nicht einmal du.<br />
* Billig ist meist das, was in großen Stückzahlen hergestellt wird. Was für die Masse gut ist, ist (zumindest in diesem Fall) meist auch für dich gut.<br />
* Was billig und damit in Massen verkauft wird, bekommst du auch bei anderen Händlern und auch noch in 10 Jahren. Das ist wichtig, wenn deine Schaltung irgendwann einmal in Serie gefertigt werden soll.<br />
<br />
Gleich als nächstes überlegst du, ob du einen NPN- oder einen PNP-Typ brauchst. Das ergibt sich aus der Anordnung der Bauteile in deiner Schaltung. Hast du die Möglichkeit, die Schaltung wahlweise für einen NPN- oder einen PNP-Typ auszulegen, wählst du die Variante mit dem NPN-Typ. Um einfach eine LED über einen Mikrocontroller einzuschalten, ist i.Allg. ein NPN-Typ in Emitterschaltung richtig.<br />
<br />
Ein weiteres wichtiges Kriterium ist die Befestigungstechnik: Wenn dir die SMD-Löterei etwas suspekt ist, lässt du die entsprechenden Modelle erst einmal alle außen vor. Ein typisches Nicht-SMD-Gehäuse für Universaltransistoren ist TO-92. Es gibt im Internet bebilderte Listen mit den einzelnen Gehäuseformen ([[IC-Gehäuseformen#Weblinks]])<br />
<br />
Wenn du jetzt also bei Reichelt die BC-Transistoren nach Preis aufsteigend sortiert hast, siehst du erst einen Schwung SMD-Tranistoren. Dann kommen ein paar Transistoren im TO-92-Gehäuse, die sind aber PNP. Etwas weiter unten kommt der erste NPN-Transistor in TO-92, nämlich der BC547C. Netterweise stehen gleich ein paar Eckdaten dabei:<br />
<br />
<pre><br />
BC547C 45V 0,1A 0,5W<br />
</pre><br />
<br />
Die 45V sind die maximale Kollektor-Emitter-Spannung, in deinem Fall also die Spannung, die du maximal schalten kannst. Da die LED bei Weitem keine 45V braucht und deine Versorgungsspannung eher in der Gegend von 5V liegt, bist du auf jeden Fall auf der sicheren Seite.<br />
<br />
Deine LED wird typisch mit 20mA (max. 30mA) betrieben. Der BC547C kann 100mA, also ist auch hier noch Luft.<br />
<br />
Zur maximalen Verlustleistung (0,5W): Wenn deine LED eingeschaltet ist, fließen bspw. 20mA. Ist der Transistor voll durchgesteuert (in Sättigung) beträgt die Kollektor-Emitter-Spannung bei diesem geringen Strom typischerweise zwischen 0,1V und 0,2V (Genaueres steht im Datenblatt). Am Transistor wird also maximal die Leistung 20mA·0,2V=4mW in Wärme umgesetzt. Bis zu 500mW dürfen es sein, also ebenfalls ok.<br />
<br />
Nachdem du den Transistor in engere Auswahl gezogen hast, lohnt sich auf jeden Fall ein Blick ins Datenblatt. Aus den Tabellen und Diagrammen erfährst du bspw., wie hoch der Basisstrom sein muss, um den Kollektorstrom von mindestens 20mA bei ausreichend geringer CE-Spannung bereitzustellen. Dort ist auch erklärt warum es einen BC547A, BC547B und BC547C gibt. Der letzte Buchstabe gibt nämlich die Stromverstärkungsklasse an. Da eine hohe Stromverstärkung meist wünschenswert ist und in diesem Fall keinen Aufpreis kostet, ziehst du den BC547C den anderen beiden vor.<br />
<br />
Da in deiner Anwendung HF- und Rauschverhalten keine Rolle spielen, bist du schon am Ziel angelangt.<br />
<br />
Würde deine LED 100mA statt 20mA benötigen, wären die max. 100mA des BC547 etwas knapp bemessen. Du blätterst also in der Reichelt-Liste weiter und stößt auf den BC337-40 mit 45V, 0,5A und 0,525W. Das ist genau das, wonach du suchst. Bei diesem Transistor sind die Stromverstärkungsklassen durch die Endungen -16, -25 und -40 gekennzeichnet. Es wäre ja auch<br />
zu einfach, wenn immer nur A, B und C verwendet würde ;-)<br />
<br />
Bei Strömen ab etwa 500mA kommt man an die Grenze der Leistungsfähigkeit der BC-Typen. Dann geht es weiter mit BD. Der BD135 geht bspw. schon bis 1,5A. Das Problem bei solchen größeren Transistoren: Die Stromverstärkung ist nicht besonders hoch, so dass irgendwann der Mikrocontroller nicht mehr den benötigten Basisstrom liefern kann. Dann muss dem großen Transistor ein kleiner vorangeschaltet werden, um den erhöhten Basisstrom bereitszustellen. Man kann diese Kombination von zwei Transistoren auch fertig als Darlington-Transistor kaufen, von denen ebenfalls einige in der BD-Reihe zu finden sind (z.&nbsp;B. BD647). Ein Transistortyp, der sich sehr gut zum Schalten höherer Ströme eignet, ist der [[FET | MOSFET]].<br />
<br />
Wie schon oben angedeutet: Wenn die 30-80V die die meisten BC- und BD-Transistoren abkönnen, nicht ausreichen, suchst du weiter bei BU.<br />
<br />
Steigst du in die HF-Technik ein, sind BF-Transistoren eher das Richtige, wobei bei HF-Anwendungen die Auswahl der Transistoren nicht mehr das Schwierigste ist ;-)<br />
<br />
'''Und wie geht's weiter?'''<br />
<br />
Man könnte natürlich noch viel mehr zu diesem Thema schreiben. Ich hoffe aber, dass das Geschriebene dir wenigstens grob zeigt, wie man bei nicht allzu speziellem Anforderungen relativ schnell zu einem gewünschten Transistortyp kommt, der nicht nur die technischen Anforderungen erfüllt, sondern auch leicht beschaffbar ist.<br />
<br />
Werden die Anforderungen spezieller, helfen oft die Selektionstabellen auf den Webseiten der einschlägigen Hersteller weiter. Auch Händler wie Farnell haben teilweise ganz gute Auswahlwerkzeuge. <br />
<br />
Wenn du dich intensiv mit Elektronik beschäftigst, wirst du wahrscheinlich noch viele Schaltungen von Leuten zu Gesicht bekommen, die vielleicht schon etwas weiter fortgeschritten sind. Dabei wirst du immer wieder auf bestimmte Standardtypen von Transistoren (und auch anderen Bauteilen wie Operationsverstärker u.ä.) stoßen und sehen, welche [[Standardbauelemente]] "man" üblicherweise für bestimmte Anwendungen einsetzt. Mit der Zeit setzt sich dann eine Auswahl von bspw. 10 oder 20 verschiedenen Transistoren und 5 bis 10 verschiedenen OpAmps im Kopf fest, von denen man die wesentlichen Parameter auswendig kennt, so dass man ohne aufwendige Suche eine schnelle Auswahl treffen kann. Auch hier in der Artikelsammlung gibt es eine solche [[Transistor-Übersicht]].<br />
<br />
=== Wo ist die Antwort auf meine Frage? ===<br />
<br />
Vielleicht im Forum? Falls du sie da findest, dann pack das ganze doch hier rein.<br />
<br />
[http://www.mikrocontroller.net/topic/165580 Gegen Vcc oder GND schalten]<br />
<br />
== Siehe auch ==<br />
* [[Basiswiderstand]]<br />
* [[Transistor-Übersicht]]<br />
* [[AVR_Transistortester]] - neu (Weiterentwickelt von Karl-Heinz Kübbeler)<br />
* [[AVR-Transistortester]] - alte (von Markus Frejek)<br />
* [[Leistungselektronik]]<br />
<br />
== Gehäusebauformen von Transistoren ==<br />
<br />
=== TO-92 ===<br />
Ein kleiner Aufsatz über TO-92 Transistorgehäuse und Footprints findet sich unter: [[Media:TO-92-Gehaeuse_RevB2.pdf]]. <br />
<br />
<br />
<br />
== Weblinks ==<br />
* [http://de.wikipedia.org/wiki/transistor "Transistor" bei Wikipedia]<br />
* [http://www.elektronik-kompendium.de www.elektronik-kompendium.de]<br />
** [http://www.elektronik-kompendium.de/sites/bau/0201291.htm Elko/Transistor]<br />
* http://www.elektronikinfo.de/strom/bipolartransistoren.htm<br />
* http://www.ferromel.de/tronic_1870.htm<br />
* [http://www.DieElektronikerseite.de Die Elektronikerseite] Lehrgang: Der Transistor - Ein Tausendsassa<br />
* [http://www.infoplease.com/encyclopedia/science/transistor-types-transistors.html Transistortypen]<br />
* [http://electronics-electrical.exportersindia.com/electronic-components/transistors.htm Transistoren Industrieunternehmen Geschäftsauflistungen]<br />
<br />
[[Category:Bauteile]]<br />
[[Category:Grundlagen]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=Transistor&diff=107008Transistor2024-07-11T10:05:44Z<p>Heha: /* PNP/NPN als Schalter, wohin mit der Last? */</p>
<hr />
<div>Kunstwort aus "transfer resistor", was etwa so viel bedeutet wie "übertragener [[Widerstand]]".<br />
<br />
In den 1950-ern als praktische Anwendung des [[Halbleiter]]-Effekts erfundenes "solid state" Schalt- und Verstärkerelement, welches sehr klein ist, ohne bewegte Teile auskommt (anders als ein klassisches Relais) und keine energiefressende Heizung benötigt (anders als eine Röhre).<br />
<br />
Vom "bipolaren Transistor" (PNP, NPN) weiterentwickelt zum "Feldeffekt-Transistor" ([[FET]]), der heute - gefertigt mit einem preiswerten Verfahren unter Verwendung von Metall-Oxid-Schichten (MOS) - ein wesentliches Element integrierter Schaltkreise (ICs, integrated circuits) darstellt, und damit natürlich auch von [[Mikrocontroller]]n, um die es in diesem Wiki hauptsächlich geht (bzw. gehen sollte).<br />
<br />
== Schaltzeichen ==<br />
[https://electronicsclub.info/images/transbce.gif]<br />
<br />
* E: Emitter<br />
* B: Basis<br />
* C: Collector <br />
<br />
<br />
In ASCII Schaltplänen sehen Transistoren so aus:<br />
<pre> <br />
|> |/<br />
NPN |> oder -| oder -|<br />
|\ |><br />
<br />
|< |/<br />
PNP: |< oder -| oder -|<br />
|\ |<<br />
</pre><br />
<br />
Um zu erkennen, ob ein NPN oder PNP Transistor im Schaltplan verwendet wird, gibt es Eselsbrücken:<br />
*Für Dichter: '''Tut der Pfeil der Basis weh, handelt's sich um PNP.'''<br />
*Für Praktiker: '''PNP heisst "Pfeil Nach Platte"'''.<br />
*Mit Dialekt: '''NPN "'naus, Pfeil, 'naus"'''.<br />
*..und für Gleichberechtigungsverfechter: '''NPN means "Not Pointing iN"'''.<br />
<br />
<br />
<br />
JFET: [[Bild:Transistor_JFET.png]]<br />
<br />
MOSFET: [[Bild:Transistor_MOSFET.png]]<br />
<br />
* S: Source<br />
* G: Gate<br />
* D: Drain<br />
<br />
Eigentlich haben MOSFETs noch einen vierten Anschluss namens Bulk. Der ist aber nur bei Spezialtypen als Pin herausgeführt. Im Normalfall kann man ihn vergessen, da er nicht gesondert beschaltet werden muss, er ist praktisch und auch im Symbol mit Source verbunden.<br />
<br />
'''Achtung:''' Die NPN/PNP Eselsbrücken funktionieren bei FETs nicht, denn bei einem P-Kanal FET zeigt der Pfeil weg vom FET!<br />
Ein Bipolartransistor, im Englischen als bipolar junction transistor (BJT) bezeichnet, ist ein Transistor, bei dem Ladungsträger – negativ geladene Elektronen und positiv geladene Defektelektronen – zum Stromtransport durch den Bipolartransistor beitragen. Der BJT wird mittels eines elektrischen Stroms gesteuert und wird zum Schalten und Verstärken von Signalen ohne mechanisch bewegte Teile eingesetzt.<br />
<br />
Bipolare Leistungstransistoren sind für das Schalten und Verstärken von Signalen höherer Stromstärken und Spannungen ausgelegt.<br />
<br />
== Typbezeichnungen == <br />
<br />
Neben den Typbezeichnungen wie 2Nxxxx, TIPxxx, MJxxx, MJExx gibt es noch die in Europa geläufigere Kennzeichnung bestehend aus zwei Buchstaben und drei Ziffern. Die diversen Kennzeichnungsmöglichkeiten sind in einem eigenen Artikel ([[Kennzeichnung von Halbleitern]]) zusammengefasst.<br />
<br />
== Kenndaten/Parameter ==<br />
<br />
Im [http://www.mikrocontroller.net/topic/197676#1938546 Beitrag: Transistorparameter Erklärung] sind Links zu Erläuterungen spezieller Kürzel.<br />
<br />
== Transistor Grundschaltungen ==<br />
<br />
Generell gilt, dass Strom vom Kollektor zum Emitter nur dann fließen kann, wenn die Basis positiver (NPN) bzw. negativer (PNP) wird als der Emitter. Dabei darf die Basis nicht direkt mit Vcc (NPN) oder GND (PNP) verbunden werden, da der Basisstrom sonst zu gross wird. Es muss jeweils ein geeigneter Basiswiderstand (R_Basis) gewählt werden.<br />
<br />
'''Weitere Links:'''<br />
* Artikel [[Basiswiderstand]]<br />
* [http://www.elektronik-kompendium.de/sites/slt/0203111.htm Transistor Grundschaltungen im ElKo]<br />
* [http://www.roboternetz.de/wissen/index.php/Transistor Transistor bei RoboterNetz.de]<br />
<br />
Es gibt drei Grundschaltungen. Der Name beschreibt den Anschluss, welcher sich auf einem festen Potential (Spannung) befindet. Die beiden anderen Anschlüsse haben bedingt durch die Schaltung ein veränderliches Potential.<br />
<br />
=== Kollektorschaltung (Emitterfolger)===<br />
<br />
'''Anwendung:'''<br />
* Impedanzwandler<br />
* Darlington-Schaltung<br />
* Schalter<br />
<br />
'''Eigenschaften:'''<br />
* Keine Phasendrehung<br />
* Hohe Stromverstärkung<br />
* Keine Spannungsverstärkung<br />
<br />
'''Beispiel: Transistor als Schalter'''<br />
<br />
* NPN: Kollektor mit Vcc verbinden, Last an Emitter<br />
* PNP: Kollektor mit GND verbinden, Last an Emitter<br />
<br />
In diesem Fall regelt der Transistor die Spannungen am Emitter, daher wird die Last am Emitter angeschlossen. Die Spannung am Emitter entspricht immer der an der Basis minus 0,6V, sie folgt der Basisspannung, deswegen auch der Name Emitterfolger. Daher ist diese Schaltung nicht geeignet, um 12V mit 5V zu schalten. <br />
<br />
{|<br />
|-<br />
| [[Bild:NPN_Collector.gif | framed | center | NPN Transistor in Kollektorschaltung]] <br />
|| [[Bild:PNP_Collector.gif | framed | center | PNP Transistor in Kollektorschaltung]] <br />
|}<br />
* NPN: Wird <math>R_{Poti}</math> (Spannungsteiler) erhöht, '''steigt''' die Spannung <math>U_{Last}</math> letztlich bis auf VCC-0,6V (Basis-Emitter-Übergang).<br />
* PNP: Wird <math>R_{Poti}</math> (Spannungsteiler) erhöht, '''sinkt''' Spannung an <math>U_{Last}</math> letztlich bis auf 0,6V (Basis-Emitter-Übergang).<br />
<br />
'''Weitere Links:'''<br />
* [http://www.elektronik-kompendium.de/sites/slt/0204133.htm Kollektorschaltung im ElKo]<br />
<br />
=== Emitterschaltung ===<br />
<br />
Die Emitterschaltung bietet hohe Spannungs- und Stromverstärkung.<br />
<br />
'''Anwendung:'''<br />
* NF- und HF-Verstärker<br />
* Leistungsverstärker<br />
* Transistor als Schalter<br />
<br />
'''Eigenschaften:'''<br />
* Phasendrehung 180°<br />
* Hohe Spannungsverstärkung<br />
* Hohe Stromverstärkung<br />
<br />
<br />
'''Beispiel: Transistor als Schalter'''<br />
<br />
Die Last liegt am Kollektor. Der Strom durch den Schalter oder an U_Schalt steuert den Strom zwischen Kollektor und Emitter. Wird der Schalter geschlossen, fließt ein Strom.<br />
<br />
[[Bild:NPN_Schalter.gif | framed | center | NPN Transistor als Schalter]]<br />
<pre><br />
___ ___<br />
Vcc/+ o-----------------------+ Vcc/+ o-----------------------+<br />
| |<br />
___ |< U_schalt (-) ___ |< PNP <br />
+------|___|---| PNP o------------|___|----|<br />
| R_Basis |\ R_Basis |\<br />
Schalter \ | |<br />
| ___ | ___ |<br />
GND/- o------+------|___|-----+ GND/- o-------------|___|-----+<br />
R_Last R_Last <br />
<br />
</pre><br />
<br />
<br />
'''Weitere Links:'''<br />
* [http://www.elektronik-kompendium.de/sites/slt/0204302.htm Emitterschaltung im ElKo]<br />
<br />
=== Basisschaltung ===<br />
<br />
Die Basisschaltung findet sich vor allem in Eingangsstufen in der HF-Technik. Im Schaltbetrieb wird sie praktisch nur zur [[Pegelwandler#STEP-UP: 5V -> 9..15V | Pegelwandlung]] für nachfolgende Stufen verwendet.<br />
<br />
'''Eigenschaften:'''<br />
* Geringe Eingangsimpedanz<br />
* Keine Phasenverschiebung<br />
* Hohe Bandbreite<br />
<br />
'''Weitere Links:'''<br />
* [http://www.elektronik-kompendium.de/sites/slt/0205081.htm Basisschaltung im ElKo<br />
<br />
== FAQ aus dem Forum ==<br />
<br />
=== PNP/NPN als Schalter, wohin mit der Last? === <br />
Für viele einfache Anwendungen kann man sich merken: '''Bei Schaltanwendungen darf der Basisstrom nicht durch die Last fließen''' (… wenn die zu schaltende Spannung höher ist als die Steuerspannung). Normalerweise kommt dabei die Emitterschaltung zum Einsatz, die Last kommt also an den Kollektor.<br />
<br />
<pre>─│┌┐└┘├┤┬┴ ━┃┏┓┗┛┷┯<br />
Vcc o─────────────┐ Vcc o───────────┐<br />
│ │<br />
┏┷┓ An: GND ___ ┃<<br />
┃ ┃ R_Last o───┤___├──┨ PNP<br />
┗┯┛ Aus: Vcc ┃\<br />
│ │<br />
An: Vcc ___ ┃/ ┏┷┓<br />
o───┤___├────┨ NPN ┃ ┃ R_Last<br />
Aus: GND ┃> ┗┯┛<br />
│ │<br />
GND o─────────────┘ GND o───────────┘<br />
</pre><br />
<br />
Siehe [[Basiswiderstand]] zur Berechnung des notwendigen Basiswiderstandes bei gegebener Last R_Last für einen Transistor als Schalter.<br />
<br />
Siehe auch Threads im Forum: <br />
* http://www.mikrocontroller.net/topic/58567 <br />
* http://www.mikrocontroller.net/topic/119841<br />
* oder im [http://www.elektronik-kompendium.de/sites/slt/0208031.htm Elektronik-Kompendium-Forum]<br />
<br />
Ist die zu schaltende Spannung '''genauso hoch''' wie die Steuerspannung darf die Last an den Emitter, und der Basiswiderstand entfällt. Der Transistor arbeitet als ''Impedanzwandler'' und steigert die Treiberfähigkeit des Mikrocontroller-Ausgangs in den Ampere-Bereich. Dieser Trick funktioniert '''nur''' mit Bipolartransistoren.<br />
<br />
Ist die effektive Invertierung des Schaltzustandes im oben angegebenen Bild lästig '''und''' der Strom geringer als der Ausgangsstrom, kann man den Transistor am Emitter steuern. Eine solche Schaltung funktioniert noch besser mit (Logik-Level-)MOSFETs und stellt eine einfache Kopplung zwischen Systemen mit unterschiedlicher Betriebsspannung (bspw. 1,8 V und 3,3 V) her. MOSFETs werden dazu am Source-Pin gesteuert, während das Gate an der „gegenüberliegenden“ Speisespannung „fixiert“ wird.<br />
<br />
=== Wie kann ich mit 5V vom Mikrocontroller 12V und mehr schalten? === <br />
Schau mal hier:<br />
* Wikiartikel [[Pegelwandler]]<br />
* [http://www.elektronik-kompendium.de/sites/praxis/bausatz_pegelwandler-mit-transistoren.htm Pegelwandler im ElKo]<br />
* [http://dl6gl.de/grundlagen/schalten-mit-transistoren schalten-mit-transistoren]<br />
<br />
oder in diesen Threads:<br />
*[http://www.mikrocontroller.net/topic/17899 Transistor als Schalter]<br />
*[http://www.mikrocontroller.net/topic/14437 Vcc schalten mit MOSFET]<br />
*[http://www.mikrocontroller.net/topic/29830 Schalten mit PNP-Transistor]<br />
*[http://www.mikrocontroller.net/topic/104027 Transistorschalter für Versorgungsspannung]<br />
*[http://www.mikrocontroller.net/topic/104951#921417 7-50V strombegrenzt schalten]<br />
*[http://www.mikrocontroller.net/topic/103116#900247 P-Kanal MOSFET ansteuern]<br />
*[https://www.mikrocontroller.net/topic/383039#4367479 5V/15mA mit 3,3V schalten]<br />
*[https://www.mikrocontroller.net/topic/401317#4638354 High Side Treiber mit Ladungspumpe]<br />
*[https://www.mikrocontroller.net/topic/347885?goto=3855574#3855574 minus -12V mit 3,3V schalten]<br />
*[https://www.mikrocontroller.net/topic/516373?goto=6650986#6650986 Kurzschlußfester Schalter für VCC]<br />
<br />
Bei der Kollektor-Schaltung entspricht die Spannung am Emitter immer der an der Basis, daher ist sie nur bedingt geeignet. Zum Schalten können die folgenden Emitter-Schaltungen verwendet werden. Achtung: In der zweiten davon arbeitet T1 in Basisschaltung.<br />
<br />
Schalten gegen GND<br />
<br />
<pre><br />
+12V o------------------------+<br />
|<br />
.-. <br />
( X ) <br />
'-'<br />
|<br />
___ |/ T1,NPN <br />
uC PIN o---|___|-----| BC547 <br />
R2,4K7 |><br />
|<br />
GND o---------o--------------+<br />
</pre><br />
<br />
<br />
Schalten gegen +12V<br />
<br />
<pre><br />
+12V o--------------+----------------------+<br />
| |<br />
| ____ |< T2, PNP<br />
+--|____|----+--------| BC557<br />
R1,4K7 | |\<br />
|/T1,NPN |<br />
Vcc/+5V o--------------| BC547 |<br />
|> |<br />
___ | .-. <br />
uC PIN o-----|___|------+ ( X ) <br />
R2,4K7 '-'<br />
|<br />
GND o----------o--------------------------+<br />
</pre><br />
<br />
=== Transistor an µC ohne Vorwiderstand === <br />
<br />
Normalerweise sind IO Pins vom µC nicht in der Lage, große Ströme zu treiben, beim AVR maximal ~20mA. Für einen kleinen Transistor ist das immer noch zu viel und es wäre auch Stromverschwendung.<br />
<br />
Deshalb kann man den IO-Pin des AVRs einfach als Tristate Eingang einstellen (Portpin als Eingang und Pullup deaktivieren), damit kein Basisstrom fließt.<br />
<br />
Aktiviert man nun den internen Pullup-Widerstand des AVRs, agiert dieser als Basisvorwiderstand, und es fließt nur ein geringer Basisstrom (die Pullups eines AVRs liegen irgendwo bei 50k bis 100k Ohm - siehe Datenblatt).<br />
<br />
Nur sollte man bei kleinen Transistoren aufpassen, dass man den Portpin in der Software nie als aktiven Ausgang schaltet. <br />
<br />
Wenn der verwendete µC zuschaltbare Pulldown-Widerstände an seinen Pins besitzt, kann man das gleiche auch mit einem PNP-Transistor machen (natürlich nur den Pulldown aktivieren).<br />
<br />
Eine Anwendung wären z.&nbsp;B. Nixie-Röhren-Kathodentreiber (geringe Stromverstärkung nötig).<br />
<br />
=== Wann bipolare (NPN/PNP) und wann FETs (insbesonders, wenn LEDs im Spiel sind)?=== <br />
Oft sind bipolare Transistoren (NPN/PNP) schon ausreichend, vor allem wenn "normale" LEDs (20mA) verwendet werden. FETs sind u.a. dann gut, wenn mit geringen Eingangsströmen hohe Ausgangsströme (über 300 mA) geschaltet werden sollen, also bei den Power-LEDs (Luxeon...).<br />
<br />
Ein Grenzfall: 500mA/5V schalten, siehe http://www.mikrocontroller.net/topic/62327.<br />
<br />
=== Wieso gehen bei einer Multiplex-Anzeige mit Schieberegister 74HC595 und (Darlington-)Transistor als Zeilentreiber die LED nicht ganz aus? ===<br />
Das liegt an der '''Miller-Kapazität''' des übersteuerten (Darlington-)Transistors. Der braucht erst mal einige 10µs, um zu sperren. Du mußt also erstmal beide Zeilen ausschalten, dann etwas warten und dann die nächste Zeile an. Oder Du ersetzt die Darlington durch P-FETs. [http://www.mikrocontroller.net/topic/132545]<br />
<br />
=== Wie steuert man ein Relais? ===<br />
Normalerweise verwendet man zur Ansteuerung von Relais NPN-Transistoren in Emitterschaltung. Freilaufdiode nicht vergessen! <br />
<br />
Siehe auch:<br />
* [[Relais mit Logik ansteuern]]<br />
* [http://www.mikrocontroller.net/attachment/22023/Relaisanteuerung.png Schaltbilder aus dem Forum]<br />
<br />
=== Was ist die Spannung <math>U_{BE\_sat}</math> (lt. Datenblatt max. 1,2V)? ===<br />
Bekanntlich verhält sich die Basis-Emitter Strecke eines Transistors wie eine Diode und <math>U_{BE\_sat}</math> ist die bei maximal zulässigem Basisstrom anliegende Vorwärtsspannung.<br />
<br />
=== Was bewirkt ein Kondensator (100µF-1nF) parallel zur Basis-Emitter-Strecke nach Masse? === <br />
Er wirkt mit dem Basisvorwiderstand als RC-Tiefpass. Damit wird der Transistor eigentlich nicht mehr als Schalter, sondern als Linearregler betrieben. Manche Verstärker-Schaltungen sind, gerade bei hohen Lasten, sehr schwingfreudig. Deswegen ist bei PWM so ein C nicht sinnvoll.<br />
<br />
=== Gibt es einen IC, der wie mehrere Transistoren funktioniert? ===<br />
<br />
Gibt es! Beispielsweise der '''ULN2803''' ist ein 8-fach Darlington Transistor Array mit [[Ausgangsstufen_Logik-ICs#Open_Collector|Open-Collector Ausgang]]. Damit lässt sich z.&nbsp;B. ein Leistungstreiber zur Ansteuerung von Schrittmotoren, Relais und anderen induktiven Lasten aufbauen.<br />
<br />
=== Gibt es ein Transistor-Array wie ULN28xx, das gegen Vcc schaltet? ===<br />
<br />
Such mal nach UDN29xx, z.&nbsp;B. UDN2981, UDN2987 ...<br />
<br />
Allegro hat zwischenzeitlich seinen Source-Treiber umbenannt. Die Bauteile heißen jetzt A2981, A2982 usw... Die Datenblätter sind identisch geblieben.<br />
<br />
Nachteil eines Darlington-Source-Treibers ist die hohe Sättigungsspannung (VceSat) von typisch 1,2 V. Die Eingangsspannung sollte dementsprechend höher ausgelegt werden oder gleich ein Source-Treiber mit MOSFET-Transistoren gewählt werden (z.B. Infineon ProFETs).<br />
<br />
=== Wann setzt man einen MOSFET, Bipolartransistor, IGBT oder Thyristor ein? ===<br />
siehe [[Leistungselektronik]]<br />
<br />
Die Summe allen Übels ist konstant. Man muss wissen, welches Bauteil sich wofür besonders eignet.<br />
<br />
====[[FET | MOSFET]]====<br />
<br />
Vorteile<br />
* Bei niedrigen Spannungen <100V sehr gut geeignet, <200V gut geeignet, sehr geringe R_DS-ON Widerstände möglich (einstelliger mOhm-Bereich)<br />
* Hohe Schaltgeschwindigkeiten möglich<br />
* Geringe An- und Ausschaltverluste<br />
* Statisch praktisch leistungslos steuerbar<br />
* Bodydiode kann als Freilaufdiode in H-Brücken verwendet werden<br />
* 2. Durchbruch bei Überschreiten der max. Drain-Source Sperrspannung zerstört das Bauteil nicht, wenn der Strom sowie die Energie begrenzt werden. (Verhalten wie [[Diode | Z-Diode]])<br />
<br />
Nachteile<br />
*Antiparallele Diode (Bodydiode) ist in nahezu allen MOSFETs unvermeidlich, daduch Sperren nur in einer Polarität möglich, Stromfluss über den MOSFET aber in beiden Richtungen möglich (Inversbetrieb, Synchrongleichrichter)<br />
* Bei Sperrspannungen >100V deutlich steigende Einschaltwiderstände (R_DS-ON)<br />
* Schnelles Umschalten erfordert hohe Lade-und Entladeströme ([[MOSFET-Übersicht#Mosfet-Treiber|MOSFET-Treiber]])<br />
* Leitverluste quadratisch proportional zum Strom, Pv = I²*R_DS-ON<br />
<br />
====[[Transistor | Bipolartransistor]]====<br />
<br />
Vorteile<br />
* Hohe Spannungsfestigkeiten möglich, bis zu 2000V<br />
* Sehr hohe Schaltgeschwindigkeiten möglich<br />
* Leitverluste etwa linear proportional zum Strom und Kollektor-Emitter-Sättigungsspannung, Pv = I * Uce-sat, U_CEC-sat typ 0,1...2.5 V<br />
<br />
Nachteile<br />
* Stromgesteuert, damit wird immer eine gewisse Ansteuerleistung benötigt<br />
* Bei grossen Kollektorströmen nimmt die Stromverstärkung deutlich ab, dann wird ein großer Basisstrom benötigt<br />
* 2. Durchbruch bei Überschreiten der max. Kollektor-Emitter Sperrspannung zerstört das Bauteil<br />
<br />
====[[IGBT]]====<br />
<br />
Vorteile<br />
* Hohe Spannungsfestigkeiten möglich, bis zu 6600V, in üblichen Bauformen bis ca 1700V gut verfügbar<br />
* Statisch praktisch leistungslos steuerbar<br />
* Mit oder ohne antiparallele Diode zur Kollektor-Emitter-Strecke verfügbar<br />
* Leitverluste linear proportional zum Strom und Kollektor-Emitter-Sättigungsspannung, Pv = I * Uce-sat, U_CE-sat typ. 2V<br />
<br />
Nachteile<br />
* Nur mäßige Schaltfrequenzen möglich (typ. <30..50kHz)<br />
* Schnelles Umschalten erfordert hohe Lade-und Entladeströme ([[MOSFET-Übersicht#Mosfet-Treiber|MOSFET-Treiber]])<br />
* 2. Durchbruch bei Überschreiten der max. Kollektor-Emitter Sperrspannung zerstört das Bauteil<br />
<br />
====[[TRIAC]]/Thyristor====<br />
<br />
Vorteile:<br />
* Sehr hohe Spannungsfestigkeiten möglich (800V...mehrere kV, Thyristoren bis 12kV)<br />
* Mit kurzen Pulsen einschaltbar, danach Selbsthaltung des Stromflusses<br />
* Leitverluste linear proportional zum Strom, Pv = I * Uak, Uak typ. 0,8...1,5 V <br />
<br />
Nachteile<br />
* Auf niedrige Schaltfrequenzen beschränkt (kHz-Bereich, Schaltzeit im Bereich von µs)<br />
* Anstiegsgeschwindigkeit des Stromes muss begrenzt werden, sonst kommt es zu Bauteilschäden<br />
* Anstiegsgeschwindigkeit der Spannung muss begrenzt werden, sonst kommt es zum ungewollten Zünden<br />
* Stromfluss kann nicht ausgeschaltet werden, damit meist nur Einsatz an Wechselspannung<br />
<br />
{| class="wikitable" style="width:50em"<br />
|- <br />
! style="width:10em" | Bauteil <br />
! style="width:12em" | optimales<br>Einsatzgebiet<br />
! Kommentar<br />
|-<br />
| MOSFET || 0..200V, 0..500A || im Kleinspannungsbereich meist die beste Wahl als Schalter<br />
|-<br />
| Bipolartransistor || 0..1000V, 0..10A || wird mehr und mehr von MOSFETs verdrängt<br />
|-<br />
| IGBT || 200..1700V, 0..500A || optimal für hohe Spannungen und hohe Ströme<br />
|-<br />
| Triac/Thyristor || 230V, 400V, 680V,<br>bis mehrere kV, 0..100A || meist für Wechselspannung, <br>Thyristoren bis 1000A im Dauerbetrieb, <br>im Pulsbetrieb einige kA. (Scheibenzelle)<br />
|}<br />
<br />
=== Wie finde ich den richtigen Transistor für eine LED-Ansteuerung? ===<br />
<br />
Quelle: Beiträge [http://www.mikrocontroller.net/topic/157763#1493623] und [http://www.mikrocontroller.net/topic/157763#1494972] von yalu<br />
<br />
Um am Anfang wenigstens ein bisschen den Durchblick im Transistordschungel zu behalten, kannst du folgendermaßen vorgehen:<br />
<br />
'''Nomenklatur'''<br />
<br />
Nach der amerikanischen Nomenklatur beginnen die Transistornamen meist mit 2N (z.&nbsp;B. 2N2222 oder 2N3055) und nach der japanischen mit 2S (z.&nbsp;B. 2SC1815). Für den Anfang kann man sich auf europäische Transistoren beschränken, da es diese in ausreichender Auswahl gibt und die Bezeichnungen relativ gut den Transistortyp wiedergeben:<br />
<br />
Der erste Buchstabe bezeichnet das Halbleitermaterial (A=Germanium, B=Silizium). Germaniumtransistoren werden heute nur noch selten verwendet.<br />
<br />
Der zweite Buchstabe steht für den Einsatzzweck (C=Universal, D=hohe Leistung, F=Hochfrequenz, U=hohe Spannung).<br />
<br />
So ist also ein ACxxx ein Germaniumuniversaltransistor und ein BDxxx ein Siliziumleistungstransistor.<br />
<br />
'''Auswahl'''<br />
<br />
Wenn du dich für einen Grundtyp entschieden hast (für die LED ist ein BC-Typ das Richtige), gehst du auf die Webseite eines Elektronikhändlers (Reichelt, Kessler usw.), schlägst die Seite mit den BC-Transistoren auf. Da gibt es natürlich sehr viele davon, und du brauchst jetzt eine<br />
Suchreihenfolge. Als erstes Auswahlkriterium nimmst du den Preis, denn:<br />
<br />
* Zuviel Geld hast wahrscheinlich nicht einmal du.<br />
* Billig ist meist das, was in großen Stückzahlen hergestellt wird. Was für die Masse gut ist, ist (zumindest in diesem Fall) meist auch für dich gut.<br />
* Was billig und damit in Massen verkauft wird, bekommst du auch bei anderen Händlern und auch noch in 10 Jahren. Das ist wichtig, wenn deine Schaltung irgendwann einmal in Serie gefertigt werden soll.<br />
<br />
Gleich als nächstes überlegst du, ob du einen NPN- oder einen PNP-Typ brauchst. Das ergibt sich aus der Anordnung der Bauteile in deiner Schaltung. Hast du die Möglichkeit, die Schaltung wahlweise für einen NPN- oder einen PNP-Typ auszulegen, wählst du die Variante mit dem NPN-Typ. Um einfach eine LED über einen Mikrocontroller einzuschalten, ist i.Allg. ein NPN-Typ in Emitterschaltung richtig.<br />
<br />
Ein weiteres wichtiges Kriterium ist die Befestigungstechnik: Wenn dir die SMD-Löterei etwas suspekt ist, lässt du die entsprechenden Modelle erst einmal alle außen vor. Ein typisches Nicht-SMD-Gehäuse für Universaltransistoren ist TO-92. Es gibt im Internet bebilderte Listen mit den einzelnen Gehäuseformen ([[IC-Gehäuseformen#Weblinks]])<br />
<br />
Wenn du jetzt also bei Reichelt die BC-Transistoren nach Preis aufsteigend sortiert hast, siehst du erst einen Schwung SMD-Tranistoren. Dann kommen ein paar Transistoren im TO-92-Gehäuse, die sind aber PNP. Etwas weiter unten kommt der erste NPN-Transistor in TO-92, nämlich der BC547C. Netterweise stehen gleich ein paar Eckdaten dabei:<br />
<br />
<pre><br />
BC547C 45V 0,1A 0,5W<br />
</pre><br />
<br />
Die 45V sind die maximale Kollektor-Emitter-Spannung, in deinem Fall also die Spannung, die du maximal schalten kannst. Da die LED bei Weitem keine 45V braucht und deine Versorgungsspannung eher in der Gegend von 5V liegt, bist du auf jeden Fall auf der sicheren Seite.<br />
<br />
Deine LED wird typisch mit 20mA (max. 30mA) betrieben. Der BC547C kann 100mA, also ist auch hier noch Luft.<br />
<br />
Zur maximalen Verlustleistung (0,5W): Wenn deine LED eingeschaltet ist, fließen bspw. 20mA. Ist der Transistor voll durchgesteuert (in Sättigung) beträgt die Kollektor-Emitter-Spannung bei diesem geringen Strom typischerweise zwischen 0,1V und 0,2V (Genaueres steht im Datenblatt). Am Transistor wird also maximal die Leistung 20mA·0,2V=4mW in Wärme umgesetzt. Bis zu 500mW dürfen es sein, also ebenfalls ok.<br />
<br />
Nachdem du den Transistor in engere Auswahl gezogen hast, lohnt sich auf jeden Fall ein Blick ins Datenblatt. Aus den Tabellen und Diagrammen erfährst du bspw., wie hoch der Basisstrom sein muss, um den Kollektorstrom von mindestens 20mA bei ausreichend geringer CE-Spannung bereitzustellen. Dort ist auch erklärt warum es einen BC547A, BC547B und BC547C gibt. Der letzte Buchstabe gibt nämlich die Stromverstärkungsklasse an. Da eine hohe Stromverstärkung meist wünschenswert ist und in diesem Fall keinen Aufpreis kostet, ziehst du den BC547C den anderen beiden vor.<br />
<br />
Da in deiner Anwendung HF- und Rauschverhalten keine Rolle spielen, bist du schon am Ziel angelangt.<br />
<br />
Würde deine LED 100mA statt 20mA benötigen, wären die max. 100mA des BC547 etwas knapp bemessen. Du blätterst also in der Reichelt-Liste weiter und stößt auf den BC337-40 mit 45V, 0,5A und 0,525W. Das ist genau das, wonach du suchst. Bei diesem Transistor sind die Stromverstärkungsklassen durch die Endungen -16, -25 und -40 gekennzeichnet. Es wäre ja auch<br />
zu einfach, wenn immer nur A, B und C verwendet würde ;-)<br />
<br />
Bei Strömen ab etwa 500mA kommt man an die Grenze der Leistungsfähigkeit der BC-Typen. Dann geht es weiter mit BD. Der BD135 geht bspw. schon bis 1,5A. Das Problem bei solchen größeren Transistoren: Die Stromverstärkung ist nicht besonders hoch, so dass irgendwann der Mikrocontroller nicht mehr den benötigten Basisstrom liefern kann. Dann muss dem großen Transistor ein kleiner vorangeschaltet werden, um den erhöhten Basisstrom bereitszustellen. Man kann diese Kombination von zwei Transistoren auch fertig als Darlington-Transistor kaufen, von denen ebenfalls einige in der BD-Reihe zu finden sind (z.&nbsp;B. BD647). Ein Transistortyp, der sich sehr gut zum Schalten höherer Ströme eignet, ist der [[FET | MOSFET]].<br />
<br />
Wie schon oben angedeutet: Wenn die 30-80V die die meisten BC- und BD-Transistoren abkönnen, nicht ausreichen, suchst du weiter bei BU.<br />
<br />
Steigst du in die HF-Technik ein, sind BF-Transistoren eher das Richtige, wobei bei HF-Anwendungen die Auswahl der Transistoren nicht mehr das Schwierigste ist ;-)<br />
<br />
'''Und wie geht's weiter?'''<br />
<br />
Man könnte natürlich noch viel mehr zu diesem Thema schreiben. Ich hoffe aber, dass das Geschriebene dir wenigstens grob zeigt, wie man bei nicht allzu speziellem Anforderungen relativ schnell zu einem gewünschten Transistortyp kommt, der nicht nur die technischen Anforderungen erfüllt, sondern auch leicht beschaffbar ist.<br />
<br />
Werden die Anforderungen spezieller, helfen oft die Selektionstabellen auf den Webseiten der einschlägigen Hersteller weiter. Auch Händler wie Farnell haben teilweise ganz gute Auswahlwerkzeuge. <br />
<br />
Wenn du dich intensiv mit Elektronik beschäftigst, wirst du wahrscheinlich noch viele Schaltungen von Leuten zu Gesicht bekommen, die vielleicht schon etwas weiter fortgeschritten sind. Dabei wirst du immer wieder auf bestimmte Standardtypen von Transistoren (und auch anderen Bauteilen wie Operationsverstärker u.ä.) stoßen und sehen, welche [[Standardbauelemente]] "man" üblicherweise für bestimmte Anwendungen einsetzt. Mit der Zeit setzt sich dann eine Auswahl von bspw. 10 oder 20 verschiedenen Transistoren und 5 bis 10 verschiedenen OpAmps im Kopf fest, von denen man die wesentlichen Parameter auswendig kennt, so dass man ohne aufwendige Suche eine schnelle Auswahl treffen kann. Auch hier in der Artikelsammlung gibt es eine solche [[Transistor-Übersicht]].<br />
<br />
=== Wo ist die Antwort auf meine Frage? ===<br />
<br />
Vielleicht im Forum? Falls du sie da findest, dann pack das ganze doch hier rein.<br />
<br />
[http://www.mikrocontroller.net/topic/165580 Gegen Vcc oder GND schalten]<br />
<br />
== Siehe auch ==<br />
* [[Basiswiderstand]]<br />
* [[Transistor-Übersicht]]<br />
* [[AVR_Transistortester]] - neu (Weiterentwickelt von Karl-Heinz Kübbeler)<br />
* [[AVR-Transistortester]] - alte (von Markus Frejek)<br />
* [[Leistungselektronik]]<br />
<br />
== Gehäusebauformen von Transistoren ==<br />
<br />
=== TO-92 ===<br />
Ein kleiner Aufsatz über TO-92 Transistorgehäuse und Footprints findet sich unter: [[Media:TO-92-Gehaeuse_RevB2.pdf]]. <br />
<br />
<br />
<br />
== Weblinks ==<br />
* [http://de.wikipedia.org/wiki/transistor "Transistor" bei Wikipedia]<br />
* [http://www.elektronik-kompendium.de www.elektronik-kompendium.de]<br />
** [http://www.elektronik-kompendium.de/sites/bau/0201291.htm Elko/Transistor]<br />
* http://www.elektronikinfo.de/strom/bipolartransistoren.htm<br />
* http://www.ferromel.de/tronic_1870.htm<br />
* [http://www.DieElektronikerseite.de Die Elektronikerseite] Lehrgang: Der Transistor - Ein Tausendsassa<br />
* [http://www.infoplease.com/encyclopedia/science/transistor-types-transistors.html Transistortypen]<br />
* [http://electronics-electrical.exportersindia.com/electronic-components/transistors.htm Transistoren Industrieunternehmen Geschäftsauflistungen]<br />
<br />
[[Category:Bauteile]]<br />
[[Category:Grundlagen]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=Transistor&diff=107006Transistor2024-07-10T17:08:27Z<p>Heha: /* PNP/NPN als Schalter, wohin mit der Last? */</p>
<hr />
<div>Kunstwort aus "transfer resistor", was etwa so viel bedeutet wie "übertragener [[Widerstand]]".<br />
<br />
In den 1950-ern als praktische Anwendung des [[Halbleiter]]-Effekts erfundenes "solid state" Schalt- und Verstärkerelement, welches sehr klein ist, ohne bewegte Teile auskommt (anders als ein klassisches Relais) und keine energiefressende Heizung benötigt (anders als eine Röhre).<br />
<br />
Vom "bipolaren Transistor" (PNP, NPN) weiterentwickelt zum "Feldeffekt-Transistor" ([[FET]]), der heute - gefertigt mit einem preiswerten Verfahren unter Verwendung von Metall-Oxid-Schichten (MOS) - ein wesentliches Element integrierter Schaltkreise (ICs, integrated circuits) darstellt, und damit natürlich auch von [[Mikrocontroller]]n, um die es in diesem Wiki hauptsächlich geht (bzw. gehen sollte).<br />
<br />
== Schaltzeichen ==<br />
[https://electronicsclub.info/images/transbce.gif]<br />
<br />
* E: Emitter<br />
* B: Basis<br />
* C: Collector <br />
<br />
<br />
In ASCII Schaltplänen sehen Transistoren so aus:<br />
<pre> <br />
|> |/<br />
NPN |> oder -| oder -|<br />
|\ |><br />
<br />
|< |/<br />
PNP: |< oder -| oder -|<br />
|\ |<<br />
</pre><br />
<br />
Um zu erkennen, ob ein NPN oder PNP Transistor im Schaltplan verwendet wird, gibt es Eselsbrücken:<br />
*Für Dichter: '''Tut der Pfeil der Basis weh, handelt's sich um PNP.'''<br />
*Für Praktiker: '''PNP heisst "Pfeil Nach Platte"'''.<br />
*Mit Dialekt: '''NPN "'naus, Pfeil, 'naus"'''.<br />
*..und für Gleichberechtigungsverfechter: '''NPN means "Not Pointing iN"'''.<br />
<br />
<br />
<br />
JFET: [[Bild:Transistor_JFET.png]]<br />
<br />
MOSFET: [[Bild:Transistor_MOSFET.png]]<br />
<br />
* S: Source<br />
* G: Gate<br />
* D: Drain<br />
<br />
Eigentlich haben MOSFETs noch einen vierten Anschluss namens Bulk. Der ist aber nur bei Spezialtypen als Pin herausgeführt. Im Normalfall kann man ihn vergessen, da er nicht gesondert beschaltet werden muss, er ist praktisch und auch im Symbol mit Source verbunden.<br />
<br />
'''Achtung:''' Die NPN/PNP Eselsbrücken funktionieren bei FETs nicht, denn bei einem P-Kanal FET zeigt der Pfeil weg vom FET!<br />
Ein Bipolartransistor, im Englischen als bipolar junction transistor (BJT) bezeichnet, ist ein Transistor, bei dem Ladungsträger – negativ geladene Elektronen und positiv geladene Defektelektronen – zum Stromtransport durch den Bipolartransistor beitragen. Der BJT wird mittels eines elektrischen Stroms gesteuert und wird zum Schalten und Verstärken von Signalen ohne mechanisch bewegte Teile eingesetzt.<br />
<br />
Bipolare Leistungstransistoren sind für das Schalten und Verstärken von Signalen höherer Stromstärken und Spannungen ausgelegt.<br />
<br />
== Typbezeichnungen == <br />
<br />
Neben den Typbezeichnungen wie 2Nxxxx, TIPxxx, MJxxx, MJExx gibt es noch die in Europa geläufigere Kennzeichnung bestehend aus zwei Buchstaben und drei Ziffern. Die diversen Kennzeichnungsmöglichkeiten sind in einem eigenen Artikel ([[Kennzeichnung von Halbleitern]]) zusammengefasst.<br />
<br />
== Kenndaten/Parameter ==<br />
<br />
Im [http://www.mikrocontroller.net/topic/197676#1938546 Beitrag: Transistorparameter Erklärung] sind Links zu Erläuterungen spezieller Kürzel.<br />
<br />
== Transistor Grundschaltungen ==<br />
<br />
Generell gilt, dass Strom vom Kollektor zum Emitter nur dann fließen kann, wenn die Basis positiver (NPN) bzw. negativer (PNP) wird als der Emitter. Dabei darf die Basis nicht direkt mit Vcc (NPN) oder GND (PNP) verbunden werden, da der Basisstrom sonst zu gross wird. Es muss jeweils ein geeigneter Basiswiderstand (R_Basis) gewählt werden.<br />
<br />
'''Weitere Links:'''<br />
* Artikel [[Basiswiderstand]]<br />
* [http://www.elektronik-kompendium.de/sites/slt/0203111.htm Transistor Grundschaltungen im ElKo]<br />
* [http://www.roboternetz.de/wissen/index.php/Transistor Transistor bei RoboterNetz.de]<br />
<br />
Es gibt drei Grundschaltungen. Der Name beschreibt den Anschluss, welcher sich auf einem festen Potential (Spannung) befindet. Die beiden anderen Anschlüsse haben bedingt durch die Schaltung ein veränderliches Potential.<br />
<br />
=== Kollektorschaltung (Emitterfolger)===<br />
<br />
'''Anwendung:'''<br />
* Impedanzwandler<br />
* Darlington-Schaltung<br />
* Schalter<br />
<br />
'''Eigenschaften:'''<br />
* Keine Phasendrehung<br />
* Hohe Stromverstärkung<br />
* Keine Spannungsverstärkung<br />
<br />
'''Beispiel: Transistor als Schalter'''<br />
<br />
* NPN: Kollektor mit Vcc verbinden, Last an Emitter<br />
* PNP: Kollektor mit GND verbinden, Last an Emitter<br />
<br />
In diesem Fall regelt der Transistor die Spannungen am Emitter, daher wird die Last am Emitter angeschlossen. Die Spannung am Emitter entspricht immer der an der Basis minus 0,6V, sie folgt der Basisspannung, deswegen auch der Name Emitterfolger. Daher ist diese Schaltung nicht geeignet, um 12V mit 5V zu schalten. <br />
<br />
{|<br />
|-<br />
| [[Bild:NPN_Collector.gif | framed | center | NPN Transistor in Kollektorschaltung]] <br />
|| [[Bild:PNP_Collector.gif | framed | center | PNP Transistor in Kollektorschaltung]] <br />
|}<br />
* NPN: Wird <math>R_{Poti}</math> (Spannungsteiler) erhöht, '''steigt''' die Spannung <math>U_{Last}</math> letztlich bis auf VCC-0,6V (Basis-Emitter-Übergang).<br />
* PNP: Wird <math>R_{Poti}</math> (Spannungsteiler) erhöht, '''sinkt''' Spannung an <math>U_{Last}</math> letztlich bis auf 0,6V (Basis-Emitter-Übergang).<br />
<br />
'''Weitere Links:'''<br />
* [http://www.elektronik-kompendium.de/sites/slt/0204133.htm Kollektorschaltung im ElKo]<br />
<br />
=== Emitterschaltung ===<br />
<br />
Die Emitterschaltung bietet hohe Spannungs- und Stromverstärkung.<br />
<br />
'''Anwendung:'''<br />
* NF- und HF-Verstärker<br />
* Leistungsverstärker<br />
* Transistor als Schalter<br />
<br />
'''Eigenschaften:'''<br />
* Phasendrehung 180°<br />
* Hohe Spannungsverstärkung<br />
* Hohe Stromverstärkung<br />
<br />
<br />
'''Beispiel: Transistor als Schalter'''<br />
<br />
Die Last liegt am Kollektor. Der Strom durch den Schalter oder an U_Schalt steuert den Strom zwischen Kollektor und Emitter. Wird der Schalter geschlossen, fließt ein Strom.<br />
<br />
[[Bild:NPN_Schalter.gif | framed | center | NPN Transistor als Schalter]]<br />
<pre><br />
___ ___<br />
Vcc/+ o-----------------------+ Vcc/+ o-----------------------+<br />
| |<br />
___ |< U_schalt (-) ___ |< PNP <br />
+------|___|---| PNP o------------|___|----|<br />
| R_Basis |\ R_Basis |\<br />
Schalter \ | |<br />
| ___ | ___ |<br />
GND/- o------+------|___|-----+ GND/- o-------------|___|-----+<br />
R_Last R_Last <br />
<br />
</pre><br />
<br />
<br />
'''Weitere Links:'''<br />
* [http://www.elektronik-kompendium.de/sites/slt/0204302.htm Emitterschaltung im ElKo]<br />
<br />
=== Basisschaltung ===<br />
<br />
Die Basisschaltung findet sich vor allem in Eingangsstufen in der HF-Technik. Im Schaltbetrieb wird sie praktisch nur zur [[Pegelwandler#STEP-UP: 5V -> 9..15V | Pegelwandlung]] für nachfolgende Stufen verwendet.<br />
<br />
'''Eigenschaften:'''<br />
* Geringe Eingangsimpedanz<br />
* Keine Phasenverschiebung<br />
* Hohe Bandbreite<br />
<br />
'''Weitere Links:'''<br />
* [http://www.elektronik-kompendium.de/sites/slt/0205081.htm Basisschaltung im ElKo<br />
<br />
== FAQ aus dem Forum ==<br />
<br />
=== PNP/NPN als Schalter, wohin mit der Last? === <br />
Für viele einfache Anwendungen kann man sich merken: '''Bei Schaltanwendungen darf der Basisstrom nicht durch die Last fließen''' (… wenn die zu schaltende Spannung höher ist als die Steuerspannung). Normalerweise kommt dabei die Emitterschaltung zum Einsatz, die Last kommt also an den Kollektor.<br />
<br />
<pre><br />
Vcc o-------------+ Vcc o-----------+<br />
| |<br />
.-. An: GND ___ |<<br />
| | R_Last o---|___|--| PNP<br />
'-' Aus: Vcc |\<br />
| |<br />
An: Vcc ___ |/ .-.<br />
o---|___|----| NPN | | R_Last<br />
Aus: GND |> '-'<br />
| |<br />
GND o─────────────┘ GND o-----------+<br />
</pre><br />
<br />
Siehe [[Basiswiderstand]] zur Berechnung des notwendigen Basiswiderstandes bei gegebener Last R_Last für einen Transistor als Schalter.<br />
<br />
Siehe auch Threads im Forum: <br />
* http://www.mikrocontroller.net/topic/58567 <br />
* http://www.mikrocontroller.net/topic/119841<br />
* oder im [http://www.elektronik-kompendium.de/sites/slt/0208031.htm Elektronik-Kompendium-Forum]<br />
<br />
Ist die zu schaltende Spannung '''genauso hoch''' wie die Steuerspannung darf die Last an den Emitter, und der Basiswiderstand entfällt. Der Transistor arbeitet als ''Impedanzwandler'' und steigert die Treiberfähigkeit des Mikrocontroller-Ausgangs in den Ampere-Bereich. Dieser Trick funktioniert '''nur''' mit Bipolartransistoren.<br />
<br />
Ist die effektive Invertierung des Schaltzustandes im oben angegebenen Bild lästig '''und''' der Strom geringer als der Ausgangsstrom, kann man den Transistor am Emitter steuern. Eine solche Schaltung funktioniert noch besser mit (Logik-Level-)MOSFETs und stellt eine einfache Kopplung zwischen Systemen mit unterschiedlicher Betriebsspannung (bspw. 1,8 V und 3,3 V) her. MOSFETs werden dazu am Source-Pin gesteuert, während das Gate an der „gegenüberliegenden“ Speisespannung „fixiert“ wird.<br />
<br />
=== Wie kann ich mit 5V vom Mikrocontroller 12V und mehr schalten? === <br />
Schau mal hier:<br />
* Wikiartikel [[Pegelwandler]]<br />
* [http://www.elektronik-kompendium.de/sites/praxis/bausatz_pegelwandler-mit-transistoren.htm Pegelwandler im ElKo]<br />
* [http://dl6gl.de/grundlagen/schalten-mit-transistoren schalten-mit-transistoren]<br />
<br />
oder in diesen Threads:<br />
*[http://www.mikrocontroller.net/topic/17899 Transistor als Schalter]<br />
*[http://www.mikrocontroller.net/topic/14437 Vcc schalten mit MOSFET]<br />
*[http://www.mikrocontroller.net/topic/29830 Schalten mit PNP-Transistor]<br />
*[http://www.mikrocontroller.net/topic/104027 Transistorschalter für Versorgungsspannung]<br />
*[http://www.mikrocontroller.net/topic/104951#921417 7-50V strombegrenzt schalten]<br />
*[http://www.mikrocontroller.net/topic/103116#900247 P-Kanal MOSFET ansteuern]<br />
*[https://www.mikrocontroller.net/topic/383039#4367479 5V/15mA mit 3,3V schalten]<br />
*[https://www.mikrocontroller.net/topic/401317#4638354 High Side Treiber mit Ladungspumpe]<br />
*[https://www.mikrocontroller.net/topic/347885?goto=3855574#3855574 minus -12V mit 3,3V schalten]<br />
*[https://www.mikrocontroller.net/topic/516373?goto=6650986#6650986 Kurzschlußfester Schalter für VCC]<br />
<br />
Bei der Kollektor-Schaltung entspricht die Spannung am Emitter immer der an der Basis, daher ist sie nur bedingt geeignet. Zum Schalten können die folgenden Emitter-Schaltungen verwendet werden. Achtung: In der zweiten davon arbeitet T1 in Basisschaltung.<br />
<br />
Schalten gegen GND<br />
<br />
<pre><br />
+12V o------------------------+<br />
|<br />
.-. <br />
( X ) <br />
'-'<br />
|<br />
___ |/ T1,NPN <br />
uC PIN o---|___|-----| BC547 <br />
R2,4K7 |><br />
|<br />
GND o---------o--------------+<br />
</pre><br />
<br />
<br />
Schalten gegen +12V<br />
<br />
<pre><br />
+12V o--------------+----------------------+<br />
| |<br />
| ____ |< T2, PNP<br />
+--|____|----+--------| BC557<br />
R1,4K7 | |\<br />
|/T1,NPN |<br />
Vcc/+5V o--------------| BC547 |<br />
|> |<br />
___ | .-. <br />
uC PIN o-----|___|------+ ( X ) <br />
R2,4K7 '-'<br />
|<br />
GND o----------o--------------------------+<br />
</pre><br />
<br />
=== Transistor an µC ohne Vorwiderstand === <br />
<br />
Normalerweise sind IO Pins vom µC nicht in der Lage, große Ströme zu treiben, beim AVR maximal ~20mA. Für einen kleinen Transistor ist das immer noch zu viel und es wäre auch Stromverschwendung.<br />
<br />
Deshalb kann man den IO-Pin des AVRs einfach als Tristate Eingang einstellen (Portpin als Eingang und Pullup deaktivieren), damit kein Basisstrom fließt.<br />
<br />
Aktiviert man nun den internen Pullup-Widerstand des AVRs, agiert dieser als Basisvorwiderstand, und es fließt nur ein geringer Basisstrom (die Pullups eines AVRs liegen irgendwo bei 50k bis 100k Ohm - siehe Datenblatt).<br />
<br />
Nur sollte man bei kleinen Transistoren aufpassen, dass man den Portpin in der Software nie als aktiven Ausgang schaltet. <br />
<br />
Wenn der verwendete µC zuschaltbare Pulldown-Widerstände an seinen Pins besitzt, kann man das gleiche auch mit einem PNP-Transistor machen (natürlich nur den Pulldown aktivieren).<br />
<br />
Eine Anwendung wären z.&nbsp;B. Nixie-Röhren-Kathodentreiber (geringe Stromverstärkung nötig).<br />
<br />
=== Wann bipolare (NPN/PNP) und wann FETs (insbesonders, wenn LEDs im Spiel sind)?=== <br />
Oft sind bipolare Transistoren (NPN/PNP) schon ausreichend, vor allem wenn "normale" LEDs (20mA) verwendet werden. FETs sind u.a. dann gut, wenn mit geringen Eingangsströmen hohe Ausgangsströme (über 300 mA) geschaltet werden sollen, also bei den Power-LEDs (Luxeon...).<br />
<br />
Ein Grenzfall: 500mA/5V schalten, siehe http://www.mikrocontroller.net/topic/62327.<br />
<br />
=== Wieso gehen bei einer Multiplex-Anzeige mit Schieberegister 74HC595 und (Darlington-)Transistor als Zeilentreiber die LED nicht ganz aus? ===<br />
Das liegt an der '''Miller-Kapazität''' des übersteuerten (Darlington-)Transistors. Der braucht erst mal einige 10µs, um zu sperren. Du mußt also erstmal beide Zeilen ausschalten, dann etwas warten und dann die nächste Zeile an. Oder Du ersetzt die Darlington durch P-FETs. [http://www.mikrocontroller.net/topic/132545]<br />
<br />
=== Wie steuert man ein Relais? ===<br />
Normalerweise verwendet man zur Ansteuerung von Relais NPN-Transistoren in Emitterschaltung. Freilaufdiode nicht vergessen! <br />
<br />
Siehe auch:<br />
* [[Relais mit Logik ansteuern]]<br />
* [http://www.mikrocontroller.net/attachment/22023/Relaisanteuerung.png Schaltbilder aus dem Forum]<br />
<br />
=== Was ist die Spannung <math>U_{BE\_sat}</math> (lt. Datenblatt max. 1,2V)? ===<br />
Bekanntlich verhält sich die Basis-Emitter Strecke eines Transistors wie eine Diode und <math>U_{BE\_sat}</math> ist die bei maximal zulässigem Basisstrom anliegende Vorwärtsspannung.<br />
<br />
=== Was bewirkt ein Kondensator (100µF-1nF) parallel zur Basis-Emitter-Strecke nach Masse? === <br />
Er wirkt mit dem Basisvorwiderstand als RC-Tiefpass. Damit wird der Transistor eigentlich nicht mehr als Schalter, sondern als Linearregler betrieben. Manche Verstärker-Schaltungen sind, gerade bei hohen Lasten, sehr schwingfreudig. Deswegen ist bei PWM so ein C nicht sinnvoll.<br />
<br />
=== Gibt es einen IC, der wie mehrere Transistoren funktioniert? ===<br />
<br />
Gibt es! Beispielsweise der '''ULN2803''' ist ein 8-fach Darlington Transistor Array mit [[Ausgangsstufen_Logik-ICs#Open_Collector|Open-Collector Ausgang]]. Damit lässt sich z.&nbsp;B. ein Leistungstreiber zur Ansteuerung von Schrittmotoren, Relais und anderen induktiven Lasten aufbauen.<br />
<br />
=== Gibt es ein Transistor-Array wie ULN28xx, das gegen Vcc schaltet? ===<br />
<br />
Such mal nach UDN29xx, z.&nbsp;B. UDN2981, UDN2987 ...<br />
<br />
Allegro hat zwischenzeitlich seinen Source-Treiber umbenannt. Die Bauteile heißen jetzt A2981, A2982 usw... Die Datenblätter sind identisch geblieben.<br />
<br />
Nachteil eines Darlington-Source-Treibers ist die hohe Sättigungsspannung (VceSat) von typisch 1,2 V. Die Eingangsspannung sollte dementsprechend höher ausgelegt werden oder gleich ein Source-Treiber mit MOSFET-Transistoren gewählt werden (z.B. Infineon ProFETs).<br />
<br />
=== Wann setzt man einen MOSFET, Bipolartransistor, IGBT oder Thyristor ein? ===<br />
siehe [[Leistungselektronik]]<br />
<br />
Die Summe allen Übels ist konstant. Man muss wissen, welches Bauteil sich wofür besonders eignet.<br />
<br />
====[[FET | MOSFET]]====<br />
<br />
Vorteile<br />
* Bei niedrigen Spannungen <100V sehr gut geeignet, <200V gut geeignet, sehr geringe R_DS-ON Widerstände möglich (einstelliger mOhm-Bereich)<br />
* Hohe Schaltgeschwindigkeiten möglich<br />
* Geringe An- und Ausschaltverluste<br />
* Statisch praktisch leistungslos steuerbar<br />
* Bodydiode kann als Freilaufdiode in H-Brücken verwendet werden<br />
* 2. Durchbruch bei Überschreiten der max. Drain-Source Sperrspannung zerstört das Bauteil nicht, wenn der Strom sowie die Energie begrenzt werden. (Verhalten wie [[Diode | Z-Diode]])<br />
<br />
Nachteile<br />
*Antiparallele Diode (Bodydiode) ist in nahezu allen MOSFETs unvermeidlich, daduch Sperren nur in einer Polarität möglich, Stromfluss über den MOSFET aber in beiden Richtungen möglich (Inversbetrieb, Synchrongleichrichter)<br />
* Bei Sperrspannungen >100V deutlich steigende Einschaltwiderstände (R_DS-ON)<br />
* Schnelles Umschalten erfordert hohe Lade-und Entladeströme ([[MOSFET-Übersicht#Mosfet-Treiber|MOSFET-Treiber]])<br />
* Leitverluste quadratisch proportional zum Strom, Pv = I²*R_DS-ON<br />
<br />
====[[Transistor | Bipolartransistor]]====<br />
<br />
Vorteile<br />
* Hohe Spannungsfestigkeiten möglich, bis zu 2000V<br />
* Sehr hohe Schaltgeschwindigkeiten möglich<br />
* Leitverluste etwa linear proportional zum Strom und Kollektor-Emitter-Sättigungsspannung, Pv = I * Uce-sat, U_CEC-sat typ 0,1...2.5 V<br />
<br />
Nachteile<br />
* Stromgesteuert, damit wird immer eine gewisse Ansteuerleistung benötigt<br />
* Bei grossen Kollektorströmen nimmt die Stromverstärkung deutlich ab, dann wird ein großer Basisstrom benötigt<br />
* 2. Durchbruch bei Überschreiten der max. Kollektor-Emitter Sperrspannung zerstört das Bauteil<br />
<br />
====[[IGBT]]====<br />
<br />
Vorteile<br />
* Hohe Spannungsfestigkeiten möglich, bis zu 6600V, in üblichen Bauformen bis ca 1700V gut verfügbar<br />
* Statisch praktisch leistungslos steuerbar<br />
* Mit oder ohne antiparallele Diode zur Kollektor-Emitter-Strecke verfügbar<br />
* Leitverluste linear proportional zum Strom und Kollektor-Emitter-Sättigungsspannung, Pv = I * Uce-sat, U_CE-sat typ. 2V<br />
<br />
Nachteile<br />
* Nur mäßige Schaltfrequenzen möglich (typ. <30..50kHz)<br />
* Schnelles Umschalten erfordert hohe Lade-und Entladeströme ([[MOSFET-Übersicht#Mosfet-Treiber|MOSFET-Treiber]])<br />
* 2. Durchbruch bei Überschreiten der max. Kollektor-Emitter Sperrspannung zerstört das Bauteil<br />
<br />
====[[TRIAC]]/Thyristor====<br />
<br />
Vorteile:<br />
* Sehr hohe Spannungsfestigkeiten möglich (800V...mehrere kV, Thyristoren bis 12kV)<br />
* Mit kurzen Pulsen einschaltbar, danach Selbsthaltung des Stromflusses<br />
* Leitverluste linear proportional zum Strom, Pv = I * Uak, Uak typ. 0,8...1,5 V <br />
<br />
Nachteile<br />
* Auf niedrige Schaltfrequenzen beschränkt (kHz-Bereich, Schaltzeit im Bereich von µs)<br />
* Anstiegsgeschwindigkeit des Stromes muss begrenzt werden, sonst kommt es zu Bauteilschäden<br />
* Anstiegsgeschwindigkeit der Spannung muss begrenzt werden, sonst kommt es zum ungewollten Zünden<br />
* Stromfluss kann nicht ausgeschaltet werden, damit meist nur Einsatz an Wechselspannung<br />
<br />
{| class="wikitable" style="width:50em"<br />
|- <br />
! style="width:10em" | Bauteil <br />
! style="width:12em" | optimales<br>Einsatzgebiet<br />
! Kommentar<br />
|-<br />
| MOSFET || 0..200V, 0..500A || im Kleinspannungsbereich meist die beste Wahl als Schalter<br />
|-<br />
| Bipolartransistor || 0..1000V, 0..10A || wird mehr und mehr von MOSFETs verdrängt<br />
|-<br />
| IGBT || 200..1700V, 0..500A || optimal für hohe Spannungen und hohe Ströme<br />
|-<br />
| Triac/Thyristor || 230V, 400V, 680V,<br>bis mehrere kV, 0..100A || meist für Wechselspannung, <br>Thyristoren bis 1000A im Dauerbetrieb, <br>im Pulsbetrieb einige kA. (Scheibenzelle)<br />
|}<br />
<br />
=== Wie finde ich den richtigen Transistor für eine LED-Ansteuerung? ===<br />
<br />
Quelle: Beiträge [http://www.mikrocontroller.net/topic/157763#1493623] und [http://www.mikrocontroller.net/topic/157763#1494972] von yalu<br />
<br />
Um am Anfang wenigstens ein bisschen den Durchblick im Transistordschungel zu behalten, kannst du folgendermaßen vorgehen:<br />
<br />
'''Nomenklatur'''<br />
<br />
Nach der amerikanischen Nomenklatur beginnen die Transistornamen meist mit 2N (z.&nbsp;B. 2N2222 oder 2N3055) und nach der japanischen mit 2S (z.&nbsp;B. 2SC1815). Für den Anfang kann man sich auf europäische Transistoren beschränken, da es diese in ausreichender Auswahl gibt und die Bezeichnungen relativ gut den Transistortyp wiedergeben:<br />
<br />
Der erste Buchstabe bezeichnet das Halbleitermaterial (A=Germanium, B=Silizium). Germaniumtransistoren werden heute nur noch selten verwendet.<br />
<br />
Der zweite Buchstabe steht für den Einsatzzweck (C=Universal, D=hohe Leistung, F=Hochfrequenz, U=hohe Spannung).<br />
<br />
So ist also ein ACxxx ein Germaniumuniversaltransistor und ein BDxxx ein Siliziumleistungstransistor.<br />
<br />
'''Auswahl'''<br />
<br />
Wenn du dich für einen Grundtyp entschieden hast (für die LED ist ein BC-Typ das Richtige), gehst du auf die Webseite eines Elektronikhändlers (Reichelt, Kessler usw.), schlägst die Seite mit den BC-Transistoren auf. Da gibt es natürlich sehr viele davon, und du brauchst jetzt eine<br />
Suchreihenfolge. Als erstes Auswahlkriterium nimmst du den Preis, denn:<br />
<br />
* Zuviel Geld hast wahrscheinlich nicht einmal du.<br />
* Billig ist meist das, was in großen Stückzahlen hergestellt wird. Was für die Masse gut ist, ist (zumindest in diesem Fall) meist auch für dich gut.<br />
* Was billig und damit in Massen verkauft wird, bekommst du auch bei anderen Händlern und auch noch in 10 Jahren. Das ist wichtig, wenn deine Schaltung irgendwann einmal in Serie gefertigt werden soll.<br />
<br />
Gleich als nächstes überlegst du, ob du einen NPN- oder einen PNP-Typ brauchst. Das ergibt sich aus der Anordnung der Bauteile in deiner Schaltung. Hast du die Möglichkeit, die Schaltung wahlweise für einen NPN- oder einen PNP-Typ auszulegen, wählst du die Variante mit dem NPN-Typ. Um einfach eine LED über einen Mikrocontroller einzuschalten, ist i.Allg. ein NPN-Typ in Emitterschaltung richtig.<br />
<br />
Ein weiteres wichtiges Kriterium ist die Befestigungstechnik: Wenn dir die SMD-Löterei etwas suspekt ist, lässt du die entsprechenden Modelle erst einmal alle außen vor. Ein typisches Nicht-SMD-Gehäuse für Universaltransistoren ist TO-92. Es gibt im Internet bebilderte Listen mit den einzelnen Gehäuseformen ([[IC-Gehäuseformen#Weblinks]])<br />
<br />
Wenn du jetzt also bei Reichelt die BC-Transistoren nach Preis aufsteigend sortiert hast, siehst du erst einen Schwung SMD-Tranistoren. Dann kommen ein paar Transistoren im TO-92-Gehäuse, die sind aber PNP. Etwas weiter unten kommt der erste NPN-Transistor in TO-92, nämlich der BC547C. Netterweise stehen gleich ein paar Eckdaten dabei:<br />
<br />
<pre><br />
BC547C 45V 0,1A 0,5W<br />
</pre><br />
<br />
Die 45V sind die maximale Kollektor-Emitter-Spannung, in deinem Fall also die Spannung, die du maximal schalten kannst. Da die LED bei Weitem keine 45V braucht und deine Versorgungsspannung eher in der Gegend von 5V liegt, bist du auf jeden Fall auf der sicheren Seite.<br />
<br />
Deine LED wird typisch mit 20mA (max. 30mA) betrieben. Der BC547C kann 100mA, also ist auch hier noch Luft.<br />
<br />
Zur maximalen Verlustleistung (0,5W): Wenn deine LED eingeschaltet ist, fließen bspw. 20mA. Ist der Transistor voll durchgesteuert (in Sättigung) beträgt die Kollektor-Emitter-Spannung bei diesem geringen Strom typischerweise zwischen 0,1V und 0,2V (Genaueres steht im Datenblatt). Am Transistor wird also maximal die Leistung 20mA·0,2V=4mW in Wärme umgesetzt. Bis zu 500mW dürfen es sein, also ebenfalls ok.<br />
<br />
Nachdem du den Transistor in engere Auswahl gezogen hast, lohnt sich auf jeden Fall ein Blick ins Datenblatt. Aus den Tabellen und Diagrammen erfährst du bspw., wie hoch der Basisstrom sein muss, um den Kollektorstrom von mindestens 20mA bei ausreichend geringer CE-Spannung bereitzustellen. Dort ist auch erklärt warum es einen BC547A, BC547B und BC547C gibt. Der letzte Buchstabe gibt nämlich die Stromverstärkungsklasse an. Da eine hohe Stromverstärkung meist wünschenswert ist und in diesem Fall keinen Aufpreis kostet, ziehst du den BC547C den anderen beiden vor.<br />
<br />
Da in deiner Anwendung HF- und Rauschverhalten keine Rolle spielen, bist du schon am Ziel angelangt.<br />
<br />
Würde deine LED 100mA statt 20mA benötigen, wären die max. 100mA des BC547 etwas knapp bemessen. Du blätterst also in der Reichelt-Liste weiter und stößt auf den BC337-40 mit 45V, 0,5A und 0,525W. Das ist genau das, wonach du suchst. Bei diesem Transistor sind die Stromverstärkungsklassen durch die Endungen -16, -25 und -40 gekennzeichnet. Es wäre ja auch<br />
zu einfach, wenn immer nur A, B und C verwendet würde ;-)<br />
<br />
Bei Strömen ab etwa 500mA kommt man an die Grenze der Leistungsfähigkeit der BC-Typen. Dann geht es weiter mit BD. Der BD135 geht bspw. schon bis 1,5A. Das Problem bei solchen größeren Transistoren: Die Stromverstärkung ist nicht besonders hoch, so dass irgendwann der Mikrocontroller nicht mehr den benötigten Basisstrom liefern kann. Dann muss dem großen Transistor ein kleiner vorangeschaltet werden, um den erhöhten Basisstrom bereitszustellen. Man kann diese Kombination von zwei Transistoren auch fertig als Darlington-Transistor kaufen, von denen ebenfalls einige in der BD-Reihe zu finden sind (z.&nbsp;B. BD647). Ein Transistortyp, der sich sehr gut zum Schalten höherer Ströme eignet, ist der [[FET | MOSFET]].<br />
<br />
Wie schon oben angedeutet: Wenn die 30-80V die die meisten BC- und BD-Transistoren abkönnen, nicht ausreichen, suchst du weiter bei BU.<br />
<br />
Steigst du in die HF-Technik ein, sind BF-Transistoren eher das Richtige, wobei bei HF-Anwendungen die Auswahl der Transistoren nicht mehr das Schwierigste ist ;-)<br />
<br />
'''Und wie geht's weiter?'''<br />
<br />
Man könnte natürlich noch viel mehr zu diesem Thema schreiben. Ich hoffe aber, dass das Geschriebene dir wenigstens grob zeigt, wie man bei nicht allzu speziellem Anforderungen relativ schnell zu einem gewünschten Transistortyp kommt, der nicht nur die technischen Anforderungen erfüllt, sondern auch leicht beschaffbar ist.<br />
<br />
Werden die Anforderungen spezieller, helfen oft die Selektionstabellen auf den Webseiten der einschlägigen Hersteller weiter. Auch Händler wie Farnell haben teilweise ganz gute Auswahlwerkzeuge. <br />
<br />
Wenn du dich intensiv mit Elektronik beschäftigst, wirst du wahrscheinlich noch viele Schaltungen von Leuten zu Gesicht bekommen, die vielleicht schon etwas weiter fortgeschritten sind. Dabei wirst du immer wieder auf bestimmte Standardtypen von Transistoren (und auch anderen Bauteilen wie Operationsverstärker u.ä.) stoßen und sehen, welche [[Standardbauelemente]] "man" üblicherweise für bestimmte Anwendungen einsetzt. Mit der Zeit setzt sich dann eine Auswahl von bspw. 10 oder 20 verschiedenen Transistoren und 5 bis 10 verschiedenen OpAmps im Kopf fest, von denen man die wesentlichen Parameter auswendig kennt, so dass man ohne aufwendige Suche eine schnelle Auswahl treffen kann. Auch hier in der Artikelsammlung gibt es eine solche [[Transistor-Übersicht]].<br />
<br />
=== Wo ist die Antwort auf meine Frage? ===<br />
<br />
Vielleicht im Forum? Falls du sie da findest, dann pack das ganze doch hier rein.<br />
<br />
[http://www.mikrocontroller.net/topic/165580 Gegen Vcc oder GND schalten]<br />
<br />
== Siehe auch ==<br />
* [[Basiswiderstand]]<br />
* [[Transistor-Übersicht]]<br />
* [[AVR_Transistortester]] - neu (Weiterentwickelt von Karl-Heinz Kübbeler)<br />
* [[AVR-Transistortester]] - alte (von Markus Frejek)<br />
* [[Leistungselektronik]]<br />
<br />
== Gehäusebauformen von Transistoren ==<br />
<br />
=== TO-92 ===<br />
Ein kleiner Aufsatz über TO-92 Transistorgehäuse und Footprints findet sich unter: [[Media:TO-92-Gehaeuse_RevB2.pdf]]. <br />
<br />
<br />
<br />
== Weblinks ==<br />
* [http://de.wikipedia.org/wiki/transistor "Transistor" bei Wikipedia]<br />
* [http://www.elektronik-kompendium.de www.elektronik-kompendium.de]<br />
** [http://www.elektronik-kompendium.de/sites/bau/0201291.htm Elko/Transistor]<br />
* http://www.elektronikinfo.de/strom/bipolartransistoren.htm<br />
* http://www.ferromel.de/tronic_1870.htm<br />
* [http://www.DieElektronikerseite.de Die Elektronikerseite] Lehrgang: Der Transistor - Ein Tausendsassa<br />
* [http://www.infoplease.com/encyclopedia/science/transistor-types-transistors.html Transistortypen]<br />
* [http://electronics-electrical.exportersindia.com/electronic-components/transistors.htm Transistoren Industrieunternehmen Geschäftsauflistungen]<br />
<br />
[[Category:Bauteile]]<br />
[[Category:Grundlagen]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=FET&diff=107005FET2024-07-10T16:51:40Z<p>Heha: /* Erklärung der wichtigsten Datenblattwerte */</p>
<hr />
<div>Dieser Artikel versteht sich als Unterpunkt zum Artikel [[Leistungselektronik]]<br />
<br />
<br />
Ein FET (engl. '''F'''ield '''E'''ffect '''T'''ransistor) ist ein Feldeffekttransistor. Der FET ist ein Bauelement, das im Gegensatz zum Bipolartransistor (engl. '''B'''ipolar '''J'''unction '''T'''ransistor, BJT) mit Spannung und nicht mit Strom gesteuert wird. Unterschieden werden<br />
* MOSFET = engl. '''M'''etall '''O'''xide '''S'''emiconductor '''F'''ield '''E'''ffect '''T'''ransistor; Metalloxidschicht-FET, größte Teilgruppe der FETs mit isoliertem Gate <br />
* JFET = engl. '''J'''unction '''F'''ield '''E'''ffect '''T'''ransistor, Übergangszonen FET, der steuerbare Kanal wird durch einen PN-Übergang wie in einer Diode gebildet<br />
<br />
Die drei Anschlüsse eines FETs werden ''Gate'', ''Drain'' und ''Source'' genannt. Unter Umständen ist ein vierter Anschluß vorhanden, der ''Bulk'' genannt wird. Normalerweise ist Bulk intern mit Source verbunden. Wenn dies nicht der Fall ist, muss diese Verbindung durch den Designer in der Schaltung hergestellt werden.<br />
<br />
== FET-Typen ==<br />
<br />
<br />
FETs werden hauptsächlich unterschieden in N-Kanal und P-Kanal, sowie "selbst sperrend = Anreicherungstyp" (engl. enhancement type) und "selbst leitend = Verarmungstyp" (engl. depletion type). Beim selbstleitenden FET ist der Transistor bei 0V Gate-Source Spannung maximal leitend (durchgesteuert) und wird durch Anlegen einer Spannung ans Gate gesperrt. Beim selbstsperrenden FET (größte Gruppe) ist der Transistor bei 0V Gate-Source Spannung gesperrt und wird durch Anlegen einer Spannung ans Gate leitend. Ist die Linie zwischen Drain und Source durchgezogen handelt es sich um einen selbstleitenden, bei einer gestrichelten Linie um einen selbstsperrenden FET. JFETs gibt es nur als Verarmungstyp. Im weiteren Artikel wird nur mehr der "selbstsperrende" MOSFET betrachtet.<br />
<br />
{| class="wikitable"<br />
|+ '''Typen von Feldeffekttransistoren<br/>&nbsp;'''<br />
|-<br />
! style="width:10em" | Typ <br />
! N-Kanal <br />
! P-Kanal<br />
|- valign="top"<br />
| JFET || [[bild:JFET-N.png|center]]<br />
* drittgrößte Gruppe<br />
* bislang nur für kleine Leistungen verfügbar<br />
* JFETs mit hoher Leistung sind im Kommen<br />
* Eingangsstufen von OPVs<br />
* Eingangsstufen von HF-Verstärkern bis in den GHz-Bereich<br />
* als einfache [[Konstantstromquelle]] geeignet<br />
| [[bild:JFET-P.png|center]]<br />
* selten <br />
|- valign="top"<br />
| MOSFET<br/>Anreicherungstyp<br/>(selbst sperrend) || [[bild:MOS-EN.png|center]]<br />
* größte Gruppe<br />
* sehr viele Typen erhältlich<br />
| [[bild:MOS-EP.png|center]]<br />
* zweitgrößte Gruppe<br />
* bei gleicher Geometrie etwas schlechter als ein N-Kanal Typ<br />
|- valign="top"<br />
| MOSFET<br/>Verarmungstyp<br/>(selbst leitend) || [[bild:MOS-DN.png|center]]<br />
* selten<br />
| [[bild:MOS-DP.png|center]]<br />
* sehr selten<br />
|}<br />
<br />
=== Vorteile des FET ===<br />
<br />
* Niedrigere Verluste als bei Bipolartransistoren.<br />
* Sehr schnelles Schalten möglich, daher für sehr hohe Frequenzen geeignet (keine Speicherzeit wie beim BJT).<br />
* Einfaches Parallelschalten im Schaltbetrieb, da Unterschiede im <math>R_{DS,on}</math> durch den positiven Temperaturkoeffizienten ausgeglichen werden.<br />
* Leistungslose Ansteuerung im statischen Fall, jedoch hohe Umladeverluste am Gate!<br />
* oft preiswerter als vergleichbare Bipolartransistoren (engl. '''B'''ipolar '''J'''unction '''T'''ransistor, BJT)<br />
* Relativ unempfindlich gegen Überspannung zwischen Drain und Source. Bei Überschreitung der Maximalspannung zwischen Drain und Source findet ein sogenannter "Durchbruch" statt. Dies ist vergleichbar mit dem Zener-Effekt. Ist die Energiemenge begrenzt, ist dieser Durchbruch reversibel und der FET wird NICHT zerstört. Beim Bipolartransistor ist die dafür zulässige Energiemenge viel kleiner, weil die den Strom durchquerende Fläche zu Hotspots neigt.<br />
<br />
=== Nachteile des FET ===<br />
<br />
* Nur bedingt für hohe Spannungen [[Transistor#Wann setzt man einen MOSFET, Bipolartransistor, IGBT oder Thyristor ein ? |geeignet]], die ON-Verluste sind ab ca. 250V höher als bei einem [[IGBT]]. <br />
* Parasitäre Diode parallel zur Drain-Source Strecke ist immer enthalten, das (Ab-)Schaltverhalten dieser Dioden ist meist schlechter als separate Dioden, was häufig zu unerwünschten Schwingungen führt.<br />
* Empfindlicher gegen ESD am Gate als BJT<br />
* Positiver Temperaturkoeffizient (TK), der <math>R_{DS,on}</math> ist stark temperaturabhängig und steigt von 25°C (Datenblattangabe) auf 150°C ungefähr um den Faktor 2. Dadurch steigen auch die Verluste und damit die Erwärmung des Bauteiles.<br />
<br />
=== Erklärung der wichtigsten Datenblattwerte ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! style="width:12em" | '''Parameter'''<br />
! style="width:7em" | '''Symbol'''<br />
! style="width:6em" | Beispiel<br />
! '''Erklärung'''<br />
|-<br />
| Drain Source Voltage <br>(Breakdown) || V(BR)_DSS <br> V_DS || 75 V || Maximale Spannungsfestigkeit des Bauteiles zwischen Drain und Source<br />
|-<br />
| Continuous Drain Current || I_D(on) || 55 A @ 125 °C || Maximaler Dauerstrom bei 125°C Gehäusetemperatur <br />
|-<br />
| Pulsed Drain Current || ID_pulse <br> I_CD(on) || 240 A || Maximaler Pulsstrom (Achtung die zulässige Zeitdauer des Pulses kann nur über die maximale Junctiontemperatur ermittelt werden)<br />
|-<br />
| Gate Charge || Q<sub>GS</sub> || 320 nC || Gate-Ladung in Coloumb oder Amperesekunden, die zum Ein- oder Ausschalten des MOSFET erforderlich ist. Dies berücksichtigt die Nichtlinearität der Kapazität und (richtig?) den Miller-Effekt. Mit dieser Angabe wird der für das Schalten von Leistungs-MOSFET benötigte Gatestrom für eine bestimmte Schaltzeit ermittelt. Dieser liegt üblicherweise im einstelligen Ampere-Bereich. Moderne Typen mit extra geringer Gate-Ladung können so schneller schalten.<br />
|-<br />
| Repetetive Avalanche Energy || t_sc || 280 mJ || Maximale Energie, welche beim Avalanche Durchbruch bei Überschreiten der maximalen Drain-Source Spannung im MOSFET bei z.&nbsp;B. 1% Puls/Pausen Verhältnis regelmäßig auftreten darf, ohne den FET zu schädigen<br />
|-<br />
| Drain-Source<br>ON Resistance || R<sub>DS_ON</sub> || 0,01 Ω || Widerstand des eingeschalteten FETs bei '''25°C''', V_GS = 10V und ID = 30A<br />
|-<br />
| Drain-Source<br>ON Resistance || R<sub>DS_on</sub> || 0,021 Ω || Widerstand des eingeschalteten FETs bei '''175°C''', V_GS = 10V und ID = 30A<br />
|-<br />
| Thermal Resistance<br>(junction-case) || R<sub>th_JC</sub> || 0,8 K/W || Thermischer Widerstand im Transistor vom der „Sperrschicht“ (junction eines Bipolartransistors, ja altmodischer Index, hier besser „Kanal“) bis zur Rückseite oder bestmöglichen Kühlmöglichkeit des Transistorgehäuses (case)<br />
|-<br />
| Gate-Source<br>Threshold Voltage || V_GS(th) || 2,0-4,5 V || Gatespannung, ab welcher der Transistor minimal leitend wird (I_D typisch 100-200µA), große Toleranz, typisch 1:2 zwischen Minimum und Maximum<br />
|-<br />
| Turn-on Delay || t_d(on) || 40 ns || Verzögerung zwischen dem Einschalten am Gate bis zur Reaktion im Drainstrom<br />
|-<br />
| Rise Time || t_r || 200 ns || Anstiegszeit des Transistorstromes am Drain<br />
|-<br />
| Turn-off Delay || t_d(off) || 120 ns || Verzögerung zwischen Abschalten am Gate bis zur Reaktion im Drainstrom<br />
|-<br />
| Fall Time || t_f || 60 ns || Abfallzeit des Transistorstromes am Drain <br />
|}<br />
<br />
Die oben genannten Zeiten gelten ausschließlich unter den angegebenen Messbedingungen (Gatewiderstand, Treiberspannung, sowie einer '''FET-Teperatur von 25°C!''') und müssen für die eigene Anwendung ggf. neu berechnet werden. Meist wird man sie eher messen, weil die Rechung zu aufwändig und bisweilen unmöglich ist. <br />
<br />
==== Gate-Source Threshold Voltage ====<br />
Gerade bei der '''Gate-Source Threshold Voltage <math>V_{GS}(th)</math>''' gibt es hier immer wieder Verwirrung. Sie gibt an, ab welcher Spannung der MOSFET anfängt, minimal leitfähig zu werden. Diese Spannung ist technologisch bedingt auch heute noch einer starken Toleranz unterworfen, typischerweise hat der Bereich bei dem der FET zu leiten beginnt eine Spreizung von etwa 1:2 zwischen Minimum und Maximum. Welche Spannung man nun wirklich anlegen muss, um den gewünschten <math>R_{DS}(on)</math> zu erreichen kann der Tabelle im jeweiligen Datenblatt entnommen werden. Dabei unbedingt die angegebene Gatespannung beachten, nur dieser Wert ist garantiert!.<br />
<br />
[[bild: IRLZ34N_R_DS_ON.png | thumb | 800px | R_DS_ON im Datenblatt des IRLZ34N]]<br />
{{Clear}}<br />
<br />
Die Kurvenschar von <math>I_D</math> über <math>U_{DS}</math> in Abhängigkeit von <math>U_{GS}</math> stellt immer nur typische Werte dar, keine garantierten Extremwerte (engl. worst case). Als Standardwerte kann man 10-15V für einen Standardtypen und ca. 3-5V für einen Logic Level MOSFET (LL-FET) ansetzen. Kleinsignal-FETs leiten schon ab ca 1V. Bei Ansteuerung mit 5V benötigt man also einen Typen, der '''sicher''' bei 5V voll durchgesteuert ist, z.B. IRLZ34N. Bei 3,3V ist er bereits nicht mehr zuverlässig nutzbar. Es gibt auch Typen mit noch geringerer Spannung für Vollaussteuerung. Wer einen BUZ11 (<math>V_{GS}(th)</math> 4V max.) mit 5V ansteuert riskiert ein Abfackeln des MOSFETs, denn je nach Toleranz kann er bereit ganz gut aufgesteuert sein oder auch nicht. Das soll in den nachfolgenden Diagrammen dargestellt werden. Zunächst die Transferkennlinie. Sie gibt an, wieviel Drainstrom in Abhängigkeit der Gatespannung fließen kann, wobei die Drainspannung konstant ist, hier im Beispiel 25V. Ein typischer BUZ11 (mittlere, schwarze Kurve) fängt bei 3V zu leiten an und erreicht bei 6V am Gate ca. 17A. Erwischt man nun ein kritisches Exemplar, das erst bei 4V zu leiten anfängt (rechte, rote Kurve um 1V parallel verschoben), so kann dieser bei 6V nur 8A leiten, für 17A braucht er 7V. Der günstige Fall, daß der BUZ11 schon bei 2V anfängt zu leiten sieht man in der linken, roten Kurve.<br />
<br />
[[bild: BUZ11_UGS_ID.png | thumb | 800px | Transferkennlinie des BUZ11]]<br />
{{Clear}}<br />
<br />
Wenn man die drei Fälle (min, typ, max) mit 5V ansteuert, erhält man die Arbeitspunkte 1-3 mit einem maximal schaltbaren Drainstrom von 2,5, 8 und 17A. Diese kann man in das Ausgangskennlinienfeld übertragen. Wir nehmen max. 1V U_DS an. Es ergeben sie die gleichen Ströme. Der maximale Drainstrom weicht um -5,5/+9A vom typischen Fall ab. Erhöht man nun die Gate-Source Spannung auf 10V (Arbeitspunkt 4), schwankt der maximal schaltbare Drainstrom nur noch um -2/+2A, außerdem liegt er mit 30A deutlich höher. Der BUZ11 ist somit sicher durchgesteuert.<br />
<br />
[[bild: BUZ11_UDS_ID_UGS.png | thumb | 800px | Ausgangskennlinie des BUZ11]]<br />
{{Clear}}<br />
<br />
==== Parasitäre Diode ====<br />
<br />
Der Schwerpunkt in der FET-Entwicklung liegt auf den geringst-möglichen <math>R_{DS}(on)</math>, die Diode entsteht auf Grund des Herstellungsprozesses, und wird nur nachrangig verbessert, da viele Optimierungsversuche auch einen Einfluss auf wichtige Kennwerte des FETs hatten und haben.<br />
Daher muss sorgfältig geprüft werden, ob die Schaltgeschwindigkeit, die Recovery-Time und die damit verbundenen Verluste sowie die dabei erzeugte unerwünschte EMV-Abstahlung tolerierbar ist, oder nicht.<br />
Hier hilft es oft eine optimierte Diode / Schottky-Diode zum FET parallel zu schalten. Ganz ausblenden läßt sich die parasitäre Diode jedoch nicht, jedoch kann man den Anteil des Stromes beeinflussen, der über die intere Diode fliest.<br />
<br />
{| class="wikitable"<br />
|+ ''' Parasitäre Diode des FETs '''<br />
|-<br />
! style="width:10em" | '''Parameter'''<br />
! style="width:6em" | '''Symbol'''<br />
! style="width:6em" | '''Beispiel'''<br />
! '''Erklärung'''<br />
|-<br />
| Continuous Current || I_S || 75A || Maximaler Dauerstrom der parasitären Diode, meist identisch zum maximalen Dauerstrom des MOSFETs<br />
|-<br />
| Forward Voltage || V_SD || 1,3V || Spannungsfall an der parasitären Diode <br />
|-<br />
| Reverse Recovery Time || t_rr || 120ns || Zeit, welche die Elektronen brauchen um aus der leitenden Diode vollständig abzufließen. Während dieser Zeit fließt der Strom in '''Rückwärtsrichtung''' durch die Diode und erzeugt relativ viel Verlustleistung. <br />
|-<br />
| Reverse Recovery Charge || Q_rr || 60nC || Ladungsmenge, die während t_rr rückwärts durch die Diode fließt. <br />
|}<br />
<br />
== Haupttypen und Gatespannungslevel ==<br />
<br />
===Unterschied N-Kanal / P-Kanal FET===<br />
<br />
Im Schaltsymbol werden die MOSFET-Typen meist durch die Pfeilrichtung in der Mitte des Symbols (eigentlich "Bulk") vom oder zum Gate unterschieden. Zeigt der Pfeil zum Gate hin, handelt es sich um einen N-Kanal-FET, zeigt der Pfeil vom Gate weg um einen P-Kanal FET.<br />
<br />
Der große Vorteil des N-Kanal FETs (Elektronenleitung) ist, daß er immer niederohmiger ist, als ein gleich großer P-Kanal FET (Löcherleitung). Daher sind P-Kanal Typen bei vergleichbaren Werten auch immer größer = teuerer da weniger Chips auf einem Wafer Platz haben.<br />
<br />
Beim N-Kanal FET muss die Gatespannung positiv gegenüber Source sein. Dabei wird der FET dann leitend, wenn die sogenannte "threshold voltage" (Schwellenspannung) erreicht wird. Eine typische Anwendung ist z.&nbsp;B. ein '''Low-Side Schalter''': Source an GND, Drain an die Last, Ansteuerung des N-Kanal FETs mit 12V gleichbedeutend mit 12V ÜBER den Source = GND Potential.<br />
<br />
Beim P-Kanal FET als HS-Schalter muss die Gatespannung negativer=niedriger als das Sourcepotential sein.Beispiel.<br />
Beispiel: <br />
Lastspannung = 400V d.h. Source an 400V, Last zwischen Drain und GND, Ansteuerung des P-Kanal FETs mit 388V, also 12V UNTER dem Sourcepotential.<br />
<br />
Beim N-Kanal FET als HS-Schalter muss die Gatespannung positver=höher als das Sourcepotential sein.<br />
Beispiel:<br />
Lastspannung = 400V d.h. Drain an 400V, die Last zwischen Source und GND, Ansteuerung des N-Kanal FETs mit 412V, also 12V ÜBER dem Sourcepotential.<br />
In diesem Fall ist aber eine zusätzliche Spannungsquelle erforderlich, denn der FET wird mit einer Spannung über der Lastspannung eingeschaltet. <br />
<br />
'''Weblinks'''<br />
* [https://www.eetimes.com/a-primer-on-high-side-fet-load-switches-part-1-of-2/?utm_source=eetimes&utm_medium=networksearch A primer on high-side FET load switches (Part 1 of 2)], Qi Deng, Senior Product Marketing Manager, Mixed-Signal Products, Micrel, Inc., 5/3/2007 4:14 PM EDT, www.eetimes.com<br />
* [https://www.eetimes.com/a-primer-on-high-side-fet-load-switches-part-2-of-2/ A primer on high-side FET load switches (Part 2 of 2)], Qi Deng, Senior Product Marketing Manager, Mixed-Signal Products. Micrel, Inc., 5/7/2007 1:36 PM EDT, www.eetimes.com<br />
* [http://www.vishay.com/docs/70611/70611.pdf AN804 P-Channel MOSFETs, the Best Choice for High-Side Switching (PDF)] von Vishay Siliconix<br />
<br />
===Unterschied Logic-Level / "Normal"-Level===<br />
<br />
Den meisten FETs ist gemein, daß sie mit einer Spannung von 10..15V angesteuert werden müssen, um den minimalen Einschaltwiderstand zu erreichen. Diese FETs lassen sich nicht ohne weiteres mit einem CMOS-Pegel von 5V ansteuern. Es gibt jedoch für diesen Anwendungsfall sogenannte "Logic Level" (LL) FETs, die schon bei einer Gatespannung von etwa 4,5V voll durchgesteuert sind. Einige Kleinsignal-FETs sind schon ab ca. 1,2V voll durchgesteuert.<br />
<br />
== Beispiel zur Bauteiledimensionierung ==<br />
<br />
=== Spannungsfestigkeit ===<br />
<br />
Die höchste vorkommende Betriebsspannung + Abschaltüberspannung soll kleiner als ca. 80% der Spannungsfestigkeit des Bauteiles sein. <br />
<br />
Achtung: Zwischen dem je nach Anwendungsfall erforderlichen Pufferkondensator und dem FET wird es immer eine parasitäre Induktivität geben.<br />
Abhängig von Schaltgeschwindigkeit und Induktivität wird im Schaltmoment eine mehr oder weniger große Übrspannungsspitze produziert. Dieser Peak<br />
addiert sich auf die aktuelle Versorgungsspannung.<br />
<br />
Überschlagsrechnung als Beispiel:<br />
* Schaltgeschwindigkeit: dI/dt = -100A/µs (= Abschalten von 5A innerhalb 50ns),<br />
* Induktivität: L = 1µH (~ 1 m loses, ungebündeltes Kabel)<br />
* dU=-L*dI/dt = -1µH * (-100A / 1µs) = 100V<br />
<br />
Dies bedeutet, daß an der "Induktivität" zwischen Transistor und Kondensator - Aufgrund von Selbstinduktion im Schaltmoment - ein Überspannungspuls von ca. 100V entsteht, der auf die Betriebsspannung aufzuschlagen ist, also lieber die Leitung kürzer machen, und - sofern möglich - nicht ganz so schnell schalten.<br />
<br />
=== Stromtragfähigkeit ===<br />
<br />
In jedem Datenblatt ist eine Stromtragfähigkeit bei 25°C, und meist noch bei einer höheren Temperatur z.B. 125°C, 150°C oder 175°C Kühlfahnentemperatur angegeben. Dieser Wert ist als ERSTE Entscheidungsgrundlage ausreichend, aber aus der theoretisch abführbaren Verlustleistung errechnet, und<br />
* dient zum qualitativen Vergleich von Transistoren bezüglich ihres R_ds(on) und ihres Wärmewiderstands.<br />
* ist für die Dimensionierung einer Schaltung nur als Richtwert zu interpretieren. <br />
* ist ohne Schaltverluste genannt, und daher nur für einen Schaltbetrieb von wenigen Hz gültig. Außerdem wird ein annähernd idealer Kühlkörper unterstellt, der trotz der Verlustleistung das Gehäuse des Transistors auf der angegebenen Temperatur halten kann.<br />
* entbindet einen nicht davon den Kopf einzuschalten... siehe die nachfolgenden Zeilen.<br />
* Liegt der Strom für den die Schaltung entwickelt wird mit ca. 10..20% Abstand unter dem Datenblattwert von 125°C ist dieses Bauteil vermutlich verwendbar (siehe Detailberechnungen unten !). <br />
* Ist der benötigte Strom im Bereich oder größer als der zulässige bei 125°C sollte entweder ein anderer Typ eingesetzt oder mehrere FETs ''des gleichen Typs'' parallelgeschaltet werden.<br />
<br />
== Verlustleistung ==<br />
<br />
Hier wird eine Näherung für eine getaktete Anwendung betrachtet. In einem Transistor treten sowohl beim Ein- und Ausschalten, als auch während der Einschaltphase Verluste im Bauteil auf. Diese Verluste führen zu einer Bauteilerwärmung. Die dabei entstehende Temperatur darf die maximal zulässige Bauteiletemperatur nie überschreiten. Bei den ersten Projekten ist zu empfehlen eine berechnete Chiptemperatur von ca. 125°C nicht zu überschreiten. Fast alle aktuell verfügbaren FETs nennen im Datenblatt eine Temperatur von 175°C als ihre maximale Chiptemperatur.<br />
<br />
{| class="wikitable" style="width:32em" <br />
|+ '''Beispiel'''<br />
|-<br />
! Parameter<br />
! style="width:8em" | Symbol<br />
! style="width:8em" | Wert<br />
|-<br />
| Betriebsspannung || U<sub>N</sub> || 70 V<br />
|-<br />
| Nennstrom || I<sub>N</sub> || 30 A<br />
|-<br />
| Drain-Source Widerstand bei<br>Chiptemperatur: 125°C<br> Gatespannung: 10V || R<sub>DS<sub>on</sub></sub> || 17 mΩ<br />
|-<br />
| Pulsbreite || t<sub>on</sub> || 150 µs<br />
|-<br />
| Schaltfrequenz || ƒ<sub>schalt</sub> || 5 kHz<br>T = 200µs<br />
|-<br />
| Einschaltzeit (risetime) || t<sub>r</sub> || 500 ns<br />
|-<br />
| Ausschaltzeit (falltime) || t<sub>ƒ</sub> || 800 ns <br />
|-<br />
|}<br />
<br />
==== Leitend-Verluste ====<br />
<br />
Während der FET bei [[PWM]]-Ansteuerung eingeschaltet ist, erzeugt er Verlustleistung.<br />
<br />
<math><br />
P_\text{ON}<br />
= {I_\mathrm{N}}^2 \cdot R_\mathrm{DS_\mathrm{ON}} \cdot \frac{t_\mathrm{ON}}{T}<br />
= 30^2A^2 \cdot 17m\Omega \cdot \frac{150\mu s}{200\mu s} = 11{,}5W<br />
</math><br />
<br />
==== Schalt-Verluste ====<br />
<br />
Vereinfachter Ansatz.<br />
<br />
Einschalten:<br />
<br />
:<math>\begin{align}<br />
P_\mathrm{SW_r}<br />
&= \tfrac14 \cdot U_N \cdot I_N \cdot \frac{t_r}{T} \\<br />
&= \tfrac14 \cdot 70V \cdot 30A \cdot \frac{500ns}{200\mu s}=1{,}3W<br />
\end{align}</math><br />
<br />
Ausschalten:<br />
<br />
:<math>\begin{align}<br />
P_\mathrm{SW_f} <br />
&=\tfrac14 \cdot U_N \cdot I_N \cdot \frac{t_f}{T}\\<br />
&=\tfrac14 \cdot 70V \cdot 30A \cdot \frac{800ns}{200\mu s}=2{,}1W<br />
\end{align}</math><br />
<br />
Alternativ und genauer kann man rechnen, wenn die Ein- Ausschaltenergie im Datenblatt angegeben ist. Aber Achtung! Die Randbedingungen unter denen die genannte Energie ermittelt wurde, müssen genau so zutreffen.<br />
:<math>\begin{align}<br />
P_{SW_f} = f_{schalt} \cdot E_{ON}<br />
\end{align}</math><br />
:<math>\begin{align}<br />
P_{SW_r} = f_{schalt} \cdot E_{OFF}<br />
\end{align}</math><br />
<br />
Die Gesamtverlustleistung beträgt also in etwa 15W.<br />
<br />
Damit muß ein entsprechender [[Kühlkörper]] ausgelegt und die Chiptemperatur berechnet werden. z.&nbsp;B.:<br />
* Kühlkörper mit einem R_th von 0,2K/W<br />
* max. Umgebungstemperatur +60°C<br />
* R_th "junction-case" des FETs 0,8K/W<br />
* R_th der Wärmeleitfolie zwischen FET und Kühlkörper ca. 2,0K/W<br />
* R_th gesamt: 3,0K/W <br><br />
* Bei einer Verlustleistung von 18W und einer Umgebungstemperatur von 60°C hat der Chip eine Temperatur von ca. 18W * 3,0K/W +60°C = 114°C. ==> o.k.!<br />
<br />
Unter Berücksichtigung der Tatsache, daß hier viele Vereinfachungen vorgenommen, und die Art der Last nicht beachtet wurde ist es sinnvoll, einen gewissen Sicherheitsabstand zu den zulässigen Maximalwerten einzuhalten. Daher ist es empfehlenswert, die Chiptemperatur auf ca. 125°C zu beschränken. <br />
<br />
Des Weiteren ist hier die parasitäre Diode im FET nicht berücksichtigt.<br />
Wenn während der "off" Zeit ein Strom über die Diode fließt (Reverse recovery current oder Freilaufstrom), muß die dadurch '''zusätzlich''' entstehende Verlustleistung in die obige Berechnung der maximalen Chiptemperatur mit einfließen.<br />
<br />
==Treiberleistung==<br />
<br />
Auch wenn der MOSFET ein spannungsgesteuertes Bauelement ist, muss trotzdem bei jedem Einschalten und bei jedem Ausschalten die Gatekapazität umgeladen werden. Bei älteren Leistungs-FET - oder bei einem schlechten Design (!) - muss sogar teilweise mit negativer Spannung am Gate gearbeitet werden, um eine vollständige Sperrung zu erreichen.<br />
Diese Umladung muss möglichst schnell erfolgen, um die Verluste im FET während der Umschaltphase zu minimieren. Dazu findet ein [[Mosfet-Übersicht#MOSFET-Treiber|MOSFET-Treiber]] Verwendung. Hier eine detaillierte Beschreibung zum [[Treiber]].<br />
<br />
Da die Gatekapazität nicht direkt im Datenblatt enthalten ist kann man sich mit der Eingangskapazität Ciss behelfen. Im Arbeitspunkt ist die Gatekapazität ungefähr 5x größer als der im Datenblatt für Ciss angegebene Wert. <br />
Daher berechnet sich die Treiberleistung wie folgt: <br />
<br />
:<math>P_\text{Treiber} = C \cdot U^2 \cdot f = 5 \cdot C_\text{íss} \cdot U_\text{Gate}^2 \cdot f_\text{schalt}</math><br />
<br />
1.Beispiel, kleine MOSFET-Steuerung mit niedriger Leistung und Frequenz.<br />
<br />
:<math>P_\text{treiber} = 5 \cdot 4{,}8\,\text{nF} \cdot 15\,\text{V}^2 \cdot 10\,\text{kHz} = 54\,\text{mW}</math><br />
<br />
2.Beispiel, sehr große MOSFET-Steuerung für Induktionsheizung mit sehr hoher Leistung und Frequenz.<br />
<br />
:<math>P_\text{treiber} = 5 \cdot 24\,\text{nF} \cdot 15\,\text{V}^2 \cdot 250\,\text{kHz} = 6{,}75\,\text{W}</math><br />
<br />
Aber Achtung, so ein MOSFET-Treiber hat auch einen Eigenverbrauch, der leicht zwischen 0,5 und 1 W liegen kann.<br />
<br />
Bei niedrigen PWM-Frequenzen kann man Logic Level MOSFETs auch direkt per CMOS-Ausgang ansteuern, z.B. mit einem [[AVR]], wie in diesem [http://www.mikrocontroller.net/topic/246449#2519459 Forumsbeitrag] zu sehen ist.<br />
<br />
== Low- und High-Side ==<br />
<br />
Definition LS- und HS:<br />
<br />
;Low-Side Schalter: Der FET schaltet eine Last gegen GND - auch als LS-Schalter bezeichnet.<br />
;High-Side Schalter: Der FET schaltet eine Last an die Versorgungsspannung – auch als HS-Schalter bezeichnet.<br />
<br />
Anregungen oder Fragen auch gerne per Email an [http://www.mikrocontroller.net/user/show/powerfreak Powerfreak]. Dieser Artikel kann dadurch regelmäßig erweitert und ggf. durch ein FAQ ergänzt werden.<br />
<br />
<br />
== SOA Diagramm ==<br />
<br />
SOA-Diagramm (engl. '''S'''afe '''O'''perating '''A'''rea, sicherer Arbeitsbereich) beschreibt die zulässige Verlustleistung eines Transistors in Anhängigkeit des Drainstroms (I_D), der Drain-Source Spannung (U_DS) und der Pulsbreite. Als Beispiel sei hier der BUZ 11 genannt. Im nachfolgenden Diagramm ist das SOA-Diagramm dargestellt. Wie ist es zu verstehen? Zunächst gibt es eine Grenze auf der linken Seite, die schräge, dunkelblaue Line. Diese wird durch den minimalen R_DS_ON festgelegt, hier wirkt der MOSFET wie ein ohmscher Widerstand. Mehr Strom kann bei einer bestimmten Spannung nicht fließen. Die zweite Grenzlinie ist ganz rechts die pinkfarbene Linie, sie stellt die maximale Sperrspannung des MOSFET dar. Die dritte Grenze ist der maximal zulässige Drainstrom, hier im Beispiel 120A, dargestellt durch die gelbe Linie. Die maximale Spannung zwischen Drain und Source sowie der Drainstrom sind abhängig von der Pulsbreite, mit welcher der MOSFET betrieben wird. Bei nur 2,5µs Pulsbreite (Rechteckimpuls) müssen die beiden Parameter sich innerhalb der Fläche bewegen, welche durch die dunkelblaue, gelbe und die pinkfarbene Line begrenzt wird. Im Extremfall dürfen 50V anliegen und 120A fließen, das sind satte 6kW Pulsleistung! Werden die Pulse breiter, so sinken die zulässigen Ströme und Spannungen, bei 1ms (dunkelblaue Linie bis zur braunen Linie, dann zur pinkfarbenen Linie) sind maximal noch 50V und 7A zulässig, also nur noch 350W. Die letzte Linie stellt den Fall für Gleichstrom (engl. '''D'''irect '''C'''urrent), also Dauerbelastung dar, hier sind bei 50V maximal 1,5A zulässig, was einer Dauerverlustleistung von 75W entspricht. MOSFETs, welche nur für Schaltbetrieb und nicht für [[#Linearbetrieb von MOSFETs | Linearbetrieb]] geeignet sind, haben keine Kennlinie für DC. Im normalen Schaltbetrieb liegt der Arbeitspunkt auf der linken Grenzlinie R_DS_ON_MIN. Nur im Linearbetrieb liegt der Arbeitspunkt innerhalb der Fläche, welche durch die Außenlinien begrenzt wird.<br />
<br />
[[bild: SOA-BUZ11.png | thumb | 300px| SOA-Diagramm]]<br />
<br />
Bei der Anwendung des Diagramms gilt es einiges zu beachten. Die Pulsleistungen sind nur zulässig, wenn der MOSFET vorher kalt ist, sprich ca. 25°C Sperrschichttemperatur hat. War er vorher schon heiß, reduziert sich die zulässige Belastung deutlich. Ebenso dürfen die Pulse nicht zu schnell wiederholt werden, denn dann ist der MOSFET noch vom vorherigen Puls aufgeheizt. Im Fall von DC sind 75W Verlustleistung auch eher ein theoretischer Wert, welcher real nur schwer erreicht werden kann, wenn der MOSFET auf einem sehr großen [[Kühlkörper]] optimal montiert ist. Praktisch liegen die erreichbaren Werte eher bei der Hälfte.<br />
<br />
(Anm. Eigentlich müsste für die R_DS_ON Grenzlinie R = U / I der minimale R_DS_ON rauskommen, hier ~40mOhm, es kommen aber ~80mOhm raus. Die Ursache dafür ist unklar, möglicherweise liegt hier ein Sicherheitsfaktor zu grunde).<br />
<br />
{{Clear}}<br />
<br />
== Linearbetrieb von MOSFETs ==<br />
<br />
Der Großteil der Anwendungen nutzt MOSFETs als Schalter, d.h. der MOSFET ist entweder voll gesperrt oder voll durchgesteuert. Dafür gelten auch all die Hinweise in diesem Artikel. In bestimmten Anwendungen werden MOSFETs aber auch im Linearbetrieb eingesetzt, z.B in linearen Endstufen für Audio, Video, elektronischen Lasten und Stromquellen. Hier muss man einiges beachten. Ein verbreiteter Irrtum besteht darin zu glauben, MOSFETs könne man im Linearbetrieb einfach parallel schalten, weil der positive Temperaturkoeffizient von <math>R_{DS(ON)}</math> eine Symmetrierung bewirkt, ähnlich den Emitterwiderständen bei parallelgeschalteten Bipolartransistoren. Das ist ''ausschließlich'' im Schaltbetrieb möglich, und daher falsch! Im Linearbetrieb spielt der Temperaturkoeffizient von <math>R_{DS(ON)}</math> keine Rolle, weil der MOSFET selten bis nie komplett durchgesteuert ist. Eben darum ist beim Linearbetrieb der minimale <math>R_{DS(ON)}</math> in den meisten Fällen unwichtig und man kann auch eher hochohmige, ältere MOSFETs verwenden, wie z.B. den BUZ11.<br />
<br />
Hier wirkt vielmehr der negative Temperaturkoeffizient (TK) der Thresholdspannung <math>U_{GS(thr)}</math>, vergleichbar dem negativen TK der Basis-Emitter-Spannung von Bipolartransistoren. D.h. mit steigender Temperatur und konstanter Gate-Source-Spannung steigt der Stromfluss der Drain-Source Strecke. In einer Parallelschaltung von MOSFETs würde dies bedeuten, dass der MOSFET mit dem geringfügig größeren Drainstrom (Fertigungstoleranzen) wärmer wird, was zu einem weiter steigenden Drainstrom und damit noch mehr Wärme führt. Damit ist die Schaltung thermisch instabil und würde zum Durchbrennen der MOSFETs führen, einer nach dem Anderen. <br />
<br />
Um das zu verhindern muss man relativ große Ausgleichswiderstände in die Source-Leitung der einzelnen MOSFETs schalten, um diese Drift zu kompensieren. Dadurch verschlechtert sich natürlich der Wirkungsgrad des Verstärkers. MOSFETs haben einen TK von typisch -5mV/K für <math>U_{GS(thr)}</math>, das ist mehr als das doppelte von Bipolartransistoren mit typisch -2mV/K, weshalb die Symmetrierungswiderstände mehr als doppelt so groß sein müssen. Weiterhin muss man beachten, dass die Toleranzen von <math>U_{GS(thr)}</math> sehr groß sind, im Bereich von Volt! Das kann man sinnvoll nicht mehr mit Gatewiderständen symmetrieren, hier muss man die MOSFETs ausmessen und Gruppen mit geringen Toleranzen in einer Schaltung verwenden (engl. matching). <br />
<br />
Eine andere Möglichkeit ist die getrennte Ansteuerung der einzelnen MOSFETs, das wird oft in elektronischen Lasten bzw. [[Konstantstromquelle#Konstantstromquelle mit Operationsverstärker und Transistor | Konstantstromquellen]] gemacht. Hier treten keine zusätzlichen Verluste auf und der Mehraufwand in der Ansteuerung ist meist unkritisch.<br />
<br />
Weiterhin muss man beachten, dass viele der heutigen HochleistungsMOSFETs intern eine Parallelschaltung vieler kleiner MOSFET-Zellen (z.B. sogenannte Trench-FET) sind, und somit oft für den Linearbetrieb ungeeignet sind. Denn auch dort können einzelne Zellen überhitzen und durchbrennen (Hot Spot). Ob ein MOSFET für den Linearbetrieb tauglich ist steht manchmal im Datenblatt, oft aber eher nicht, eben weil die meisten MOSFETs als Schalter entwickelt und gebaut sind. Typische Vertreter für Linearbetrieb findet man in der [[MOSFET-Übersicht]]. Ein wichtiges Indiz für Linearbetrieb ist eine Kurve für DC im [[#SOA_Diagramm | SOA-Diagramm]]. Meist geht es dort nur bis 10ms, DC fehlt, eben weil DC (engl. '''D'''irect '''C'''urrent = Gleichstrom = Linearbetrieb) nicht zulässig ist. Manchmal hat der Hersteller auch "vergessen", die Kennlinie für DC mit reinzuschreiben, wie z.B. bei [http://www.irf.com/product-info/hi-rel/alerts/fv5-p-09-01-A.pdf IRF], wie in diesem [http://www.mikrocontroller.net/topic/291760#3106758 Beitrag] zu erfahren ist.<br />
Ein recht gutes Indiz dafür, ob ein FET für den Linearbetrieb taugt, ist die Vorwärtssteilheit. Diese kennzeichnet die Abhängigkeit des Drainstromes von der Ansteuerung am Gate als <math>S = \Delta i_d/\Delta u_{gs}</math>. Moderne Trench-FET erreichen heute Steilheiten im dreistelligen Bereich und sind für Linearanwendungen völlig unbrauchbar. Zum Vergleich: Der BUZ11 kommt mit gerade einmal 4 bis 5 Siemens daher.<br />
<br />
In diesem Beitrag wird die DC-Linie im SOA-Diagramm noch genauer erklärt: [http://www.mikrocontroller.net/topic/319961#3473567 Re: MOSFET Linearbetrieb möglich?]<br />
<br />
<br />
== Siehe auch ==<br />
<br />
* [[Leistungselektronik]]<br />
* [[Mosfet-Übersicht]]<br />
* [[IGBT]]<br />
* [[TRIAC]]<br />
* [[Kühlkörper]] <br />
* [[Zwischenkreiskapazität]]<br />
* [[Treiber]]<br />
* [[Snippets#Wie_schlie.C3.9Fe_ich_einen_MOSFET_an_einen_Mikrocontroller_an.3F|Wie schließe ich einen Mosfet an einen Mikrocontroller an?]]<br />
* [http://www.mikrocontroller.net/articles/H-Br%C3%BCcken_%C3%9Cbersicht Übersicht H-Brücken]<br />
* [http://www.mikrocontroller.net/topic/168218#1609684 Forumsbeitrag]: MOSFETs im Linearbetrieb<br />
* [http://www.mikrocontroller.net/topic/186785#new Forumsbeitrag]: nochmal MOSFETs im Linearbetrieb<br />
* [http://www.mikrocontroller.net/topic/319961#3473567 Forumsbeitrag]: sehr ausführlicher Forumsbeitrag über MOSFETs im Linearbetrieb. Berücksichtigt auch den Spirito-Effekt.<br />
* [http://www.mikrocontroller.net/topic/143324#new Forumsbeitrag]: Über eine elektronische Last, sehr lang<br />
*[http://www.mikrocontroller.net/topic/246449#2519459 Forumsbeitrag]: Logic Level MOSFETs direkt mit einem [[AVR]] treiben.<br />
* [http://www.mikrocontroller.net/topic/267254#2787855 Forumsbeitrag]: MOSFETs im Linearbetrieb, Laborerfahrungen<br />
* [http://www.mikrocontroller.net/topic/267254#2787945 Forumsbeitrag]: MOSFETs für Linearbetrieb<br />
* [https://www.mikrocontroller.net/topic/269642?goto=2820617#2820617 Forumsbeitrag]: Verpol- und Überspannungsschutz mit MOSFETs<br />
* [https://www.mikrocontroller.net/topic/425414#4981611 Forumsbeitrag]: Linearbetrieb von MOSFETs<br />
<br />
== Weblinks ==<br />
<br />
* [http://www.elektronikinfo.de/strom/feldeffekttransistoren.htm Feldeffekttransistoren bei elektronikinfo.de]<br />
* [http://www.elektronik-kompendium.de/sites/bau/0207011.htm FET im ELKO]<br />
* [http://www.elektronik-kompendium.de/sites/bau/0510161.htm MOSFET im ELKO]<br />
* [http://www.sprut.de/electronic/switch/nkanal/nkanal.html MOSFET bei sprut.de]<br />
* [http://sound.westhost.com/articles/hexfet.htm#51 MOSFETs in Audioendstufen, engl.]<br />
* [http://irf.custhelp.com/cgi-bin/irf.cfg/php/enduser/std_adp.php?p_faqid=214&p_created=1019728945&p_sid=pt9ITiCj&p_accessibility=0&p_redirect=&p_lva=&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9MTQsMTQmcF9wcm9kcz0mcF9jYXRzPSZwX3B2PSZwX2N2PSZwX3BhZ2U9MSZwX3NlYXJjaF90ZXh0PWxpbmVhcg**&p_li=&p_topview=1 FAQ Answer ID 214 bei IRF zum Linearbetrieb]<br />
* [http://www.nxp.com/documents/application_note/AN11158.pdf AN11158 - Understanding power MOSFET data sheet parameters] von NXP (PDF)<br />
* [https://assets.nexperia.com/documents/technical-note/TN00008.pdf TN00008 - Power MOSFET frequently asked questions and answers] von nexperia (PDF)<br />
* [http://www.infineon.com/dgdl/Infineon+-+Application+Note+-+PowerMOSFETs+-+OptiMOS%E2%84%A2+-+Linear+Mode+Operation+and+SOA+Power+MOSFETs.pdf?fileId=db3a30433e30e4bf013e3646e9381200 AN: Linear Mode Operation andSafe Operating Diagram of Power-MOSFETs] von Infineon (PDF)<br />
* [http://www.ixys.com/Documents/Articles/Article_Linear_Power_MOSFETs.pdf MOSFETs Withstand Stress of Linear-Mode Operation] Neuentwickelte MOSFETs für Linearbetrieb (PDF)<br />
<br />
[[Kategorie:Bauteile]] [[Kategorie:Leistungselektronik]]</div>Hehahttps://www.mikrocontroller.net/index.php?title=FET&diff=107004FET2024-07-10T16:36:24Z<p>Heha: Auch beim Bipolartransistor führt der "Second Breakdown" nicht zwangsläufig zu seinem Tod. Meistens schon.</p>
<hr />
<div>Dieser Artikel versteht sich als Unterpunkt zum Artikel [[Leistungselektronik]]<br />
<br />
<br />
Ein FET (engl. '''F'''ield '''E'''ffect '''T'''ransistor) ist ein Feldeffekttransistor. Der FET ist ein Bauelement, das im Gegensatz zum Bipolartransistor (engl. '''B'''ipolar '''J'''unction '''T'''ransistor, BJT) mit Spannung und nicht mit Strom gesteuert wird. Unterschieden werden<br />
* MOSFET = engl. '''M'''etall '''O'''xide '''S'''emiconductor '''F'''ield '''E'''ffect '''T'''ransistor; Metalloxidschicht-FET, größte Teilgruppe der FETs mit isoliertem Gate <br />
* JFET = engl. '''J'''unction '''F'''ield '''E'''ffect '''T'''ransistor, Übergangszonen FET, der steuerbare Kanal wird durch einen PN-Übergang wie in einer Diode gebildet<br />
<br />
Die drei Anschlüsse eines FETs werden ''Gate'', ''Drain'' und ''Source'' genannt. Unter Umständen ist ein vierter Anschluß vorhanden, der ''Bulk'' genannt wird. Normalerweise ist Bulk intern mit Source verbunden. Wenn dies nicht der Fall ist, muss diese Verbindung durch den Designer in der Schaltung hergestellt werden.<br />
<br />
== FET-Typen ==<br />
<br />
<br />
FETs werden hauptsächlich unterschieden in N-Kanal und P-Kanal, sowie "selbst sperrend = Anreicherungstyp" (engl. enhancement type) und "selbst leitend = Verarmungstyp" (engl. depletion type). Beim selbstleitenden FET ist der Transistor bei 0V Gate-Source Spannung maximal leitend (durchgesteuert) und wird durch Anlegen einer Spannung ans Gate gesperrt. Beim selbstsperrenden FET (größte Gruppe) ist der Transistor bei 0V Gate-Source Spannung gesperrt und wird durch Anlegen einer Spannung ans Gate leitend. Ist die Linie zwischen Drain und Source durchgezogen handelt es sich um einen selbstleitenden, bei einer gestrichelten Linie um einen selbstsperrenden FET. JFETs gibt es nur als Verarmungstyp. Im weiteren Artikel wird nur mehr der "selbstsperrende" MOSFET betrachtet.<br />
<br />
{| class="wikitable"<br />
|+ '''Typen von Feldeffekttransistoren<br/>&nbsp;'''<br />
|-<br />
! style="width:10em" | Typ <br />
! N-Kanal <br />
! P-Kanal<br />
|- valign="top"<br />
| JFET || [[bild:JFET-N.png|center]]<br />
* drittgrößte Gruppe<br />
* bislang nur für kleine Leistungen verfügbar<br />
* JFETs mit hoher Leistung sind im Kommen<br />
* Eingangsstufen von OPVs<br />
* Eingangsstufen von HF-Verstärkern bis in den GHz-Bereich<br />
* als einfache [[Konstantstromquelle]] geeignet<br />
| [[bild:JFET-P.png|center]]<br />
* selten <br />
|- valign="top"<br />
| MOSFET<br/>Anreicherungstyp<br/>(selbst sperrend) || [[bild:MOS-EN.png|center]]<br />
* größte Gruppe<br />
* sehr viele Typen erhältlich<br />
| [[bild:MOS-EP.png|center]]<br />
* zweitgrößte Gruppe<br />
* bei gleicher Geometrie etwas schlechter als ein N-Kanal Typ<br />
|- valign="top"<br />
| MOSFET<br/>Verarmungstyp<br/>(selbst leitend) || [[bild:MOS-DN.png|center]]<br />
* selten<br />
| [[bild:MOS-DP.png|center]]<br />
* sehr selten<br />
|}<br />
<br />
=== Vorteile des FET ===<br />
<br />
* Niedrigere Verluste als bei Bipolartransistoren.<br />
* Sehr schnelles Schalten möglich, daher für sehr hohe Frequenzen geeignet (keine Speicherzeit wie beim BJT).<br />
* Einfaches Parallelschalten im Schaltbetrieb, da Unterschiede im <math>R_{DS,on}</math> durch den positiven Temperaturkoeffizienten ausgeglichen werden.<br />
* Leistungslose Ansteuerung im statischen Fall, jedoch hohe Umladeverluste am Gate!<br />
* oft preiswerter als vergleichbare Bipolartransistoren (engl. '''B'''ipolar '''J'''unction '''T'''ransistor, BJT)<br />
* Relativ unempfindlich gegen Überspannung zwischen Drain und Source. Bei Überschreitung der Maximalspannung zwischen Drain und Source findet ein sogenannter "Durchbruch" statt. Dies ist vergleichbar mit dem Zener-Effekt. Ist die Energiemenge begrenzt, ist dieser Durchbruch reversibel und der FET wird NICHT zerstört. Beim Bipolartransistor ist die dafür zulässige Energiemenge viel kleiner, weil die den Strom durchquerende Fläche zu Hotspots neigt.<br />
<br />
=== Nachteile des FET ===<br />
<br />
* Nur bedingt für hohe Spannungen [[Transistor#Wann setzt man einen MOSFET, Bipolartransistor, IGBT oder Thyristor ein ? |geeignet]], die ON-Verluste sind ab ca. 250V höher als bei einem [[IGBT]]. <br />
* Parasitäre Diode parallel zur Drain-Source Strecke ist immer enthalten, das (Ab-)Schaltverhalten dieser Dioden ist meist schlechter als separate Dioden, was häufig zu unerwünschten Schwingungen führt.<br />
* Empfindlicher gegen ESD am Gate als BJT<br />
* Positiver Temperaturkoeffizient (TK), der <math>R_{DS,on}</math> ist stark temperaturabhängig und steigt von 25°C (Datenblattangabe) auf 150°C ungefähr um den Faktor 2. Dadurch steigen auch die Verluste und damit die Erwärmung des Bauteiles.<br />
<br />
=== Erklärung der wichtigsten Datenblattwerte ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! style="width:12em" | '''Parameter'''<br />
! style="width:7em" | '''Symbol'''<br />
! style="width:6em" | Beispiel<br />
! '''Erklärung'''<br />
|-<br />
| Drain Source Voltage <br>(Breakdown) || V(BR)_DSS <br> V_DS || 75V || Maximale Spannungsfestigkeit des Bauteiles zwischen Drain und Source<br />
|-<br />
| Continuous Drain Current || I_D(on) || 55A @125°C || Maximaler Dauerstrom bei 125°C Gehäusetemperatur <br />
|-<br />
| Pulsed Drain Current || ID_pulse <br> I_CD(on) || 240A || Maximaler Pulsstrom (Achtung die zulässige Zeitdauer des Pulses kann nur über die maximale Junctiontemperatur ermittelt werden)<br />
|-<br />
| Repetetive Avalanche Energy || t_sc || 280mJ || Maximale Energie, welche beim Avalanche Durchbruch bei Überschreiten der maximalen Drain-Source Spannung im MOSFET bei z.&nbsp;B. 1% Puls/Pausen Verhältnis regelmäßig auftreten darf, ohne den FET zu schädigen<br />
|-<br />
| Drain-Source<br>ON Resistance || R_DS_ON || 0,01Ω || Widerstand des eingeschalteten FETs bei '''25°C''', V_GS = 10V und ID = 30A<br />
|-<br />
| Drain-Source<br>ON Resistance || R_DS_on || 0,021Ω || Widerstand des eingeschalteten FETs bei '''175°C''', V_GS = 10V und ID = 30A<br />
|-<br />
| Thermal Resistance<br>(junction-case) || R_th_JC || 0,8K/W || Thermischer Widerstand im Transistor vom eigentlichen Chip im Inneren (junction) bis zur Rückseite des Transistorgehäuses (case)<br />
|-<br />
| Gate-Source<br>Threshold Voltage || V_GS(th) || 2,0-4,5V || Gatespannung, ab welcher der Transistor minimal leitend wird (I_D typisch 100-200µA), große Toleranz, typisch 1:2 zwischen Minimum und Maximum<br />
|-<br />
| Turn-on Delay || t_d(on) || 40ns || Verzögerung zwischen dem Einschalten am Gate bis zur Reaktion im Drainstrom<br />
|-<br />
| Rise Time || t_r || 200ns || Anstiegszeit des Transistorstromes am Drain<br />
|-<br />
| Turn-off Delay || t_d(off) || 120ns || Verzögerung zwischen Abschalten am Gate bis zur Reaktion im Drainstrom<br />
|-<br />
| Fall Time || t_f || 60ns || Abfallzeit des Transistorstromes am Drain <br />
|}<br />
<br />
Die oben genannten Zeiten gelten ausschließlich unter den angegebenen Messbedingungen (Gatewiderstand, Treiberspannung, sowie einer '''FET-Teperatur von 25°C!''') und müssen für die eigene Anwendung ggf. neu berechnet werden. Meist wird man sie eher messen, weil die Rechung zu aufwändig und bisweilen unmöglich ist. <br />
<br />
==== Gate-Source Threshold Voltage ====<br />
Gerade bei der '''Gate-Source Threshold Voltage <math>V_{GS}(th)</math>''' gibt es hier immer wieder Verwirrung. Sie gibt an, ab welcher Spannung der MOSFET anfängt, minimal leitfähig zu werden. Diese Spannung ist technologisch bedingt auch heute noch einer starken Toleranz unterworfen, typischerweise hat der Bereich bei dem der FET zu leiten beginnt eine Spreizung von etwa 1:2 zwischen Minimum und Maximum. Welche Spannung man nun wirklich anlegen muss, um den gewünschten <math>R_{DS}(on)</math> zu erreichen kann der Tabelle im jeweiligen Datenblatt entnommen werden. Dabei unbedingt die angegebene Gatespannung beachten, nur dieser Wert ist garantiert!.<br />
<br />
[[bild: IRLZ34N_R_DS_ON.png | thumb | 800px | R_DS_ON im Datenblatt des IRLZ34N]]<br />
{{Clear}}<br />
<br />
Die Kurvenschar von <math>I_D</math> über <math>U_{DS}</math> in Abhängigkeit von <math>U_{GS}</math> stellt immer nur typische Werte dar, keine garantierten Extremwerte (engl. worst case). Als Standardwerte kann man 10-15V für einen Standardtypen und ca. 3-5V für einen Logic Level MOSFET (LL-FET) ansetzen. Kleinsignal-FETs leiten schon ab ca 1V. Bei Ansteuerung mit 5V benötigt man also einen Typen, der '''sicher''' bei 5V voll durchgesteuert ist, z.B. IRLZ34N. Bei 3,3V ist er bereits nicht mehr zuverlässig nutzbar. Es gibt auch Typen mit noch geringerer Spannung für Vollaussteuerung. Wer einen BUZ11 (<math>V_{GS}(th)</math> 4V max.) mit 5V ansteuert riskiert ein Abfackeln des MOSFETs, denn je nach Toleranz kann er bereit ganz gut aufgesteuert sein oder auch nicht. Das soll in den nachfolgenden Diagrammen dargestellt werden. Zunächst die Transferkennlinie. Sie gibt an, wieviel Drainstrom in Abhängigkeit der Gatespannung fließen kann, wobei die Drainspannung konstant ist, hier im Beispiel 25V. Ein typischer BUZ11 (mittlere, schwarze Kurve) fängt bei 3V zu leiten an und erreicht bei 6V am Gate ca. 17A. Erwischt man nun ein kritisches Exemplar, das erst bei 4V zu leiten anfängt (rechte, rote Kurve um 1V parallel verschoben), so kann dieser bei 6V nur 8A leiten, für 17A braucht er 7V. Der günstige Fall, daß der BUZ11 schon bei 2V anfängt zu leiten sieht man in der linken, roten Kurve.<br />
<br />
[[bild: BUZ11_UGS_ID.png | thumb | 800px | Transferkennlinie des BUZ11]]<br />
{{Clear}}<br />
<br />
Wenn man die drei Fälle (min, typ, max) mit 5V ansteuert, erhält man die Arbeitspunkte 1-3 mit einem maximal schaltbaren Drainstrom von 2,5, 8 und 17A. Diese kann man in das Ausgangskennlinienfeld übertragen. Wir nehmen max. 1V U_DS an. Es ergeben sie die gleichen Ströme. Der maximale Drainstrom weicht um -5,5/+9A vom typischen Fall ab. Erhöht man nun die Gate-Source Spannung auf 10V (Arbeitspunkt 4), schwankt der maximal schaltbare Drainstrom nur noch um -2/+2A, außerdem liegt er mit 30A deutlich höher. Der BUZ11 ist somit sicher durchgesteuert.<br />
<br />
[[bild: BUZ11_UDS_ID_UGS.png | thumb | 800px | Ausgangskennlinie des BUZ11]]<br />
{{Clear}}<br />
<br />
==== Parasitäre Diode ====<br />
<br />
Der Schwerpunkt in der FET-Entwicklung liegt auf den geringst-möglichen <math>R_{DS}(on)</math>, die Diode entsteht auf Grund des Herstellungsprozesses, und wird nur nachrangig verbessert, da viele Optimierungsversuche auch einen Einfluss auf wichtige Kennwerte des FETs hatten und haben.<br />
Daher muss sorgfältig geprüft werden, ob die Schaltgeschwindigkeit, die Recovery-Time und die damit verbundenen Verluste sowie die dabei erzeugte unerwünschte EMV-Abstahlung tolerierbar ist, oder nicht.<br />
Hier hilft es oft eine optimierte Diode / Schottky-Diode zum FET parallel zu schalten. Ganz ausblenden läßt sich die parasitäre Diode jedoch nicht, jedoch kann man den Anteil des Stromes beeinflussen, der über die intere Diode fliest.<br />
<br />
{| class="wikitable"<br />
|+ ''' Parasitäre Diode des FETs '''<br />
|-<br />
! style="width:10em" | '''Parameter'''<br />
! style="width:6em" | '''Symbol'''<br />
! style="width:6em" | '''Beispiel'''<br />
! '''Erklärung'''<br />
|-<br />
| Continuous Current || I_S || 75A || Maximaler Dauerstrom der parasitären Diode, meist identisch zum maximalen Dauerstrom des MOSFETs<br />
|-<br />
| Forward Voltage || V_SD || 1,3V || Spannungsfall an der parasitären Diode <br />
|-<br />
| Reverse Recovery Time || t_rr || 120ns || Zeit, welche die Elektronen brauchen um aus der leitenden Diode vollständig abzufließen. Während dieser Zeit fließt der Strom in '''Rückwärtsrichtung''' durch die Diode und erzeugt relativ viel Verlustleistung. <br />
|-<br />
| Reverse Recovery Charge || Q_rr || 60nC || Ladungsmenge, die während t_rr rückwärts durch die Diode fließt. <br />
|}<br />
<br />
== Haupttypen und Gatespannungslevel ==<br />
<br />
===Unterschied N-Kanal / P-Kanal FET===<br />
<br />
Im Schaltsymbol werden die MOSFET-Typen meist durch die Pfeilrichtung in der Mitte des Symbols (eigentlich "Bulk") vom oder zum Gate unterschieden. Zeigt der Pfeil zum Gate hin, handelt es sich um einen N-Kanal-FET, zeigt der Pfeil vom Gate weg um einen P-Kanal FET.<br />
<br />
Der große Vorteil des N-Kanal FETs (Elektronenleitung) ist, daß er immer niederohmiger ist, als ein gleich großer P-Kanal FET (Löcherleitung). Daher sind P-Kanal Typen bei vergleichbaren Werten auch immer größer = teuerer da weniger Chips auf einem Wafer Platz haben.<br />
<br />
Beim N-Kanal FET muss die Gatespannung positiv gegenüber Source sein. Dabei wird der FET dann leitend, wenn die sogenannte "threshold voltage" (Schwellenspannung) erreicht wird. Eine typische Anwendung ist z.&nbsp;B. ein '''Low-Side Schalter''': Source an GND, Drain an die Last, Ansteuerung des N-Kanal FETs mit 12V gleichbedeutend mit 12V ÜBER den Source = GND Potential.<br />
<br />
Beim P-Kanal FET als HS-Schalter muss die Gatespannung negativer=niedriger als das Sourcepotential sein.Beispiel.<br />
Beispiel: <br />
Lastspannung = 400V d.h. Source an 400V, Last zwischen Drain und GND, Ansteuerung des P-Kanal FETs mit 388V, also 12V UNTER dem Sourcepotential.<br />
<br />
Beim N-Kanal FET als HS-Schalter muss die Gatespannung positver=höher als das Sourcepotential sein.<br />
Beispiel:<br />
Lastspannung = 400V d.h. Drain an 400V, die Last zwischen Source und GND, Ansteuerung des N-Kanal FETs mit 412V, also 12V ÜBER dem Sourcepotential.<br />
In diesem Fall ist aber eine zusätzliche Spannungsquelle erforderlich, denn der FET wird mit einer Spannung über der Lastspannung eingeschaltet. <br />
<br />
'''Weblinks'''<br />
* [https://www.eetimes.com/a-primer-on-high-side-fet-load-switches-part-1-of-2/?utm_source=eetimes&utm_medium=networksearch A primer on high-side FET load switches (Part 1 of 2)], Qi Deng, Senior Product Marketing Manager, Mixed-Signal Products, Micrel, Inc., 5/3/2007 4:14 PM EDT, www.eetimes.com<br />
* [https://www.eetimes.com/a-primer-on-high-side-fet-load-switches-part-2-of-2/ A primer on high-side FET load switches (Part 2 of 2)], Qi Deng, Senior Product Marketing Manager, Mixed-Signal Products. Micrel, Inc., 5/7/2007 1:36 PM EDT, www.eetimes.com<br />
* [http://www.vishay.com/docs/70611/70611.pdf AN804 P-Channel MOSFETs, the Best Choice for High-Side Switching (PDF)] von Vishay Siliconix<br />
<br />
===Unterschied Logic-Level / "Normal"-Level===<br />
<br />
Den meisten FETs ist gemein, daß sie mit einer Spannung von 10..15V angesteuert werden müssen, um den minimalen Einschaltwiderstand zu erreichen. Diese FETs lassen sich nicht ohne weiteres mit einem CMOS-Pegel von 5V ansteuern. Es gibt jedoch für diesen Anwendungsfall sogenannte "Logic Level" (LL) FETs, die schon bei einer Gatespannung von etwa 4,5V voll durchgesteuert sind. Einige Kleinsignal-FETs sind schon ab ca. 1,2V voll durchgesteuert.<br />
<br />
== Beispiel zur Bauteiledimensionierung ==<br />
<br />
=== Spannungsfestigkeit ===<br />
<br />
Die höchste vorkommende Betriebsspannung + Abschaltüberspannung soll kleiner als ca. 80% der Spannungsfestigkeit des Bauteiles sein. <br />
<br />
Achtung: Zwischen dem je nach Anwendungsfall erforderlichen Pufferkondensator und dem FET wird es immer eine parasitäre Induktivität geben.<br />
Abhängig von Schaltgeschwindigkeit und Induktivität wird im Schaltmoment eine mehr oder weniger große Übrspannungsspitze produziert. Dieser Peak<br />
addiert sich auf die aktuelle Versorgungsspannung.<br />
<br />
Überschlagsrechnung als Beispiel:<br />
* Schaltgeschwindigkeit: dI/dt = -100A/µs (= Abschalten von 5A innerhalb 50ns),<br />
* Induktivität: L = 1µH (~ 1 m loses, ungebündeltes Kabel)<br />
* dU=-L*dI/dt = -1µH * (-100A / 1µs) = 100V<br />
<br />
Dies bedeutet, daß an der "Induktivität" zwischen Transistor und Kondensator - Aufgrund von Selbstinduktion im Schaltmoment - ein Überspannungspuls von ca. 100V entsteht, der auf die Betriebsspannung aufzuschlagen ist, also lieber die Leitung kürzer machen, und - sofern möglich - nicht ganz so schnell schalten.<br />
<br />
=== Stromtragfähigkeit ===<br />
<br />
In jedem Datenblatt ist eine Stromtragfähigkeit bei 25°C, und meist noch bei einer höheren Temperatur z.B. 125°C, 150°C oder 175°C Kühlfahnentemperatur angegeben. Dieser Wert ist als ERSTE Entscheidungsgrundlage ausreichend, aber aus der theoretisch abführbaren Verlustleistung errechnet, und<br />
* dient zum qualitativen Vergleich von Transistoren bezüglich ihres R_ds(on) und ihres Wärmewiderstands.<br />
* ist für die Dimensionierung einer Schaltung nur als Richtwert zu interpretieren. <br />
* ist ohne Schaltverluste genannt, und daher nur für einen Schaltbetrieb von wenigen Hz gültig. Außerdem wird ein annähernd idealer Kühlkörper unterstellt, der trotz der Verlustleistung das Gehäuse des Transistors auf der angegebenen Temperatur halten kann.<br />
* entbindet einen nicht davon den Kopf einzuschalten... siehe die nachfolgenden Zeilen.<br />
* Liegt der Strom für den die Schaltung entwickelt wird mit ca. 10..20% Abstand unter dem Datenblattwert von 125°C ist dieses Bauteil vermutlich verwendbar (siehe Detailberechnungen unten !). <br />
* Ist der benötigte Strom im Bereich oder größer als der zulässige bei 125°C sollte entweder ein anderer Typ eingesetzt oder mehrere FETs ''des gleichen Typs'' parallelgeschaltet werden.<br />
<br />
== Verlustleistung ==<br />
<br />
Hier wird eine Näherung für eine getaktete Anwendung betrachtet. In einem Transistor treten sowohl beim Ein- und Ausschalten, als auch während der Einschaltphase Verluste im Bauteil auf. Diese Verluste führen zu einer Bauteilerwärmung. Die dabei entstehende Temperatur darf die maximal zulässige Bauteiletemperatur nie überschreiten. Bei den ersten Projekten ist zu empfehlen eine berechnete Chiptemperatur von ca. 125°C nicht zu überschreiten. Fast alle aktuell verfügbaren FETs nennen im Datenblatt eine Temperatur von 175°C als ihre maximale Chiptemperatur.<br />
<br />
{| class="wikitable" style="width:32em" <br />
|+ '''Beispiel'''<br />
|-<br />
! Parameter<br />
! style="width:8em" | Symbol<br />
! style="width:8em" | Wert<br />
|-<br />
| Betriebsspannung || U<sub>N</sub> || 70 V<br />
|-<br />
| Nennstrom || I<sub>N</sub> || 30 A<br />
|-<br />
| Drain-Source Widerstand bei<br>Chiptemperatur: 125°C<br> Gatespannung: 10V || R<sub>DS<sub>on</sub></sub> || 17 mΩ<br />
|-<br />
| Pulsbreite || t<sub>on</sub> || 150 µs<br />
|-<br />
| Schaltfrequenz || ƒ<sub>schalt</sub> || 5 kHz<br>T = 200µs<br />
|-<br />
| Einschaltzeit (risetime) || t<sub>r</sub> || 500 ns<br />
|-<br />
| Ausschaltzeit (falltime) || t<sub>ƒ</sub> || 800 ns <br />
|-<br />
|}<br />
<br />
==== Leitend-Verluste ====<br />
<br />
Während der FET bei [[PWM]]-Ansteuerung eingeschaltet ist, erzeugt er Verlustleistung.<br />
<br />
<math><br />
P_\text{ON}<br />
= {I_\mathrm{N}}^2 \cdot R_\mathrm{DS_\mathrm{ON}} \cdot \frac{t_\mathrm{ON}}{T}<br />
= 30^2A^2 \cdot 17m\Omega \cdot \frac{150\mu s}{200\mu s} = 11{,}5W<br />
</math><br />
<br />
==== Schalt-Verluste ====<br />
<br />
Vereinfachter Ansatz.<br />
<br />
Einschalten:<br />
<br />
:<math>\begin{align}<br />
P_\mathrm{SW_r}<br />
&= \tfrac14 \cdot U_N \cdot I_N \cdot \frac{t_r}{T} \\<br />
&= \tfrac14 \cdot 70V \cdot 30A \cdot \frac{500ns}{200\mu s}=1{,}3W<br />
\end{align}</math><br />
<br />
Ausschalten:<br />
<br />
:<math>\begin{align}<br />
P_\mathrm{SW_f} <br />
&=\tfrac14 \cdot U_N \cdot I_N \cdot \frac{t_f}{T}\\<br />
&=\tfrac14 \cdot 70V \cdot 30A \cdot \frac{800ns}{200\mu s}=2{,}1W<br />
\end{align}</math><br />
<br />
Alternativ und genauer kann man rechnen, wenn die Ein- Ausschaltenergie im Datenblatt angegeben ist. Aber Achtung! Die Randbedingungen unter denen die genannte Energie ermittelt wurde, müssen genau so zutreffen.<br />
:<math>\begin{align}<br />
P_{SW_f} = f_{schalt} \cdot E_{ON}<br />
\end{align}</math><br />
:<math>\begin{align}<br />
P_{SW_r} = f_{schalt} \cdot E_{OFF}<br />
\end{align}</math><br />
<br />
Die Gesamtverlustleistung beträgt also in etwa 15W.<br />
<br />
Damit muß ein entsprechender [[Kühlkörper]] ausgelegt und die Chiptemperatur berechnet werden. z.&nbsp;B.:<br />
* Kühlkörper mit einem R_th von 0,2K/W<br />
* max. Umgebungstemperatur +60°C<br />
* R_th "junction-case" des FETs 0,8K/W<br />
* R_th der Wärmeleitfolie zwischen FET und Kühlkörper ca. 2,0K/W<br />
* R_th gesamt: 3,0K/W <br><br />
* Bei einer Verlustleistung von 18W und einer Umgebungstemperatur von 60°C hat der Chip eine Temperatur von ca. 18W * 3,0K/W +60°C = 114°C. ==> o.k.!<br />
<br />
Unter Berücksichtigung der Tatsache, daß hier viele Vereinfachungen vorgenommen, und die Art der Last nicht beachtet wurde ist es sinnvoll, einen gewissen Sicherheitsabstand zu den zulässigen Maximalwerten einzuhalten. Daher ist es empfehlenswert, die Chiptemperatur auf ca. 125°C zu beschränken. <br />
<br />
Des Weiteren ist hier die parasitäre Diode im FET nicht berücksichtigt.<br />
Wenn während der "off" Zeit ein Strom über die Diode fließt (Reverse recovery current oder Freilaufstrom), muß die dadurch '''zusätzlich''' entstehende Verlustleistung in die obige Berechnung der maximalen Chiptemperatur mit einfließen.<br />
<br />
==Treiberleistung==<br />
<br />
Auch wenn der MOSFET ein spannungsgesteuertes Bauelement ist, muss trotzdem bei jedem Einschalten und bei jedem Ausschalten die Gatekapazität umgeladen werden. Bei älteren Leistungs-FET - oder bei einem schlechten Design (!) - muss sogar teilweise mit negativer Spannung am Gate gearbeitet werden, um eine vollständige Sperrung zu erreichen.<br />
Diese Umladung muss möglichst schnell erfolgen, um die Verluste im FET während der Umschaltphase zu minimieren. Dazu findet ein [[Mosfet-Übersicht#MOSFET-Treiber|MOSFET-Treiber]] Verwendung. Hier eine detaillierte Beschreibung zum [[Treiber]].<br />
<br />
Da die Gatekapazität nicht direkt im Datenblatt enthalten ist kann man sich mit der Eingangskapazität Ciss behelfen. Im Arbeitspunkt ist die Gatekapazität ungefähr 5x größer als der im Datenblatt für Ciss angegebene Wert. <br />
Daher berechnet sich die Treiberleistung wie folgt: <br />
<br />
:<math>P_\text{Treiber} = C \cdot U^2 \cdot f = 5 \cdot C_\text{íss} \cdot U_\text{Gate}^2 \cdot f_\text{schalt}</math><br />
<br />
1.Beispiel, kleine MOSFET-Steuerung mit niedriger Leistung und Frequenz.<br />
<br />
:<math>P_\text{treiber} = 5 \cdot 4{,}8\,\text{nF} \cdot 15\,\text{V}^2 \cdot 10\,\text{kHz} = 54\,\text{mW}</math><br />
<br />
2.Beispiel, sehr große MOSFET-Steuerung für Induktionsheizung mit sehr hoher Leistung und Frequenz.<br />
<br />
:<math>P_\text{treiber} = 5 \cdot 24\,\text{nF} \cdot 15\,\text{V}^2 \cdot 250\,\text{kHz} = 6{,}75\,\text{W}</math><br />
<br />
Aber Achtung, so ein MOSFET-Treiber hat auch einen Eigenverbrauch, der leicht zwischen 0,5 und 1 W liegen kann.<br />
<br />
Bei niedrigen PWM-Frequenzen kann man Logic Level MOSFETs auch direkt per CMOS-Ausgang ansteuern, z.B. mit einem [[AVR]], wie in diesem [http://www.mikrocontroller.net/topic/246449#2519459 Forumsbeitrag] zu sehen ist.<br />
<br />
== Low- und High-Side ==<br />
<br />
Definition LS- und HS:<br />
<br />
;Low-Side Schalter: Der FET schaltet eine Last gegen GND - auch als LS-Schalter bezeichnet.<br />
;High-Side Schalter: Der FET schaltet eine Last an die Versorgungsspannung – auch als HS-Schalter bezeichnet.<br />
<br />
Anregungen oder Fragen auch gerne per Email an [http://www.mikrocontroller.net/user/show/powerfreak Powerfreak]. Dieser Artikel kann dadurch regelmäßig erweitert und ggf. durch ein FAQ ergänzt werden.<br />
<br />
<br />
== SOA Diagramm ==<br />
<br />
SOA-Diagramm (engl. '''S'''afe '''O'''perating '''A'''rea, sicherer Arbeitsbereich) beschreibt die zulässige Verlustleistung eines Transistors in Anhängigkeit des Drainstroms (I_D), der Drain-Source Spannung (U_DS) und der Pulsbreite. Als Beispiel sei hier der BUZ 11 genannt. Im nachfolgenden Diagramm ist das SOA-Diagramm dargestellt. Wie ist es zu verstehen? Zunächst gibt es eine Grenze auf der linken Seite, die schräge, dunkelblaue Line. Diese wird durch den minimalen R_DS_ON festgelegt, hier wirkt der MOSFET wie ein ohmscher Widerstand. Mehr Strom kann bei einer bestimmten Spannung nicht fließen. Die zweite Grenzlinie ist ganz rechts die pinkfarbene Linie, sie stellt die maximale Sperrspannung des MOSFET dar. Die dritte Grenze ist der maximal zulässige Drainstrom, hier im Beispiel 120A, dargestellt durch die gelbe Linie. Die maximale Spannung zwischen Drain und Source sowie der Drainstrom sind abhängig von der Pulsbreite, mit welcher der MOSFET betrieben wird. Bei nur 2,5µs Pulsbreite (Rechteckimpuls) müssen die beiden Parameter sich innerhalb der Fläche bewegen, welche durch die dunkelblaue, gelbe und die pinkfarbene Line begrenzt wird. Im Extremfall dürfen 50V anliegen und 120A fließen, das sind satte 6kW Pulsleistung! Werden die Pulse breiter, so sinken die zulässigen Ströme und Spannungen, bei 1ms (dunkelblaue Linie bis zur braunen Linie, dann zur pinkfarbenen Linie) sind maximal noch 50V und 7A zulässig, also nur noch 350W. Die letzte Linie stellt den Fall für Gleichstrom (engl. '''D'''irect '''C'''urrent), also Dauerbelastung dar, hier sind bei 50V maximal 1,5A zulässig, was einer Dauerverlustleistung von 75W entspricht. MOSFETs, welche nur für Schaltbetrieb und nicht für [[#Linearbetrieb von MOSFETs | Linearbetrieb]] geeignet sind, haben keine Kennlinie für DC. Im normalen Schaltbetrieb liegt der Arbeitspunkt auf der linken Grenzlinie R_DS_ON_MIN. Nur im Linearbetrieb liegt der Arbeitspunkt innerhalb der Fläche, welche durch die Außenlinien begrenzt wird.<br />
<br />
[[bild: SOA-BUZ11.png | thumb | 300px| SOA-Diagramm]]<br />
<br />
Bei der Anwendung des Diagramms gilt es einiges zu beachten. Die Pulsleistungen sind nur zulässig, wenn der MOSFET vorher kalt ist, sprich ca. 25°C Sperrschichttemperatur hat. War er vorher schon heiß, reduziert sich die zulässige Belastung deutlich. Ebenso dürfen die Pulse nicht zu schnell wiederholt werden, denn dann ist der MOSFET noch vom vorherigen Puls aufgeheizt. Im Fall von DC sind 75W Verlustleistung auch eher ein theoretischer Wert, welcher real nur schwer erreicht werden kann, wenn der MOSFET auf einem sehr großen [[Kühlkörper]] optimal montiert ist. Praktisch liegen die erreichbaren Werte eher bei der Hälfte.<br />
<br />
(Anm. Eigentlich müsste für die R_DS_ON Grenzlinie R = U / I der minimale R_DS_ON rauskommen, hier ~40mOhm, es kommen aber ~80mOhm raus. Die Ursache dafür ist unklar, möglicherweise liegt hier ein Sicherheitsfaktor zu grunde).<br />
<br />
{{Clear}}<br />
<br />
== Linearbetrieb von MOSFETs ==<br />
<br />
Der Großteil der Anwendungen nutzt MOSFETs als Schalter, d.h. der MOSFET ist entweder voll gesperrt oder voll durchgesteuert. Dafür gelten auch all die Hinweise in diesem Artikel. In bestimmten Anwendungen werden MOSFETs aber auch im Linearbetrieb eingesetzt, z.B in linearen Endstufen für Audio, Video, elektronischen Lasten und Stromquellen. Hier muss man einiges beachten. Ein verbreiteter Irrtum besteht darin zu glauben, MOSFETs könne man im Linearbetrieb einfach parallel schalten, weil der positive Temperaturkoeffizient von <math>R_{DS(ON)}</math> eine Symmetrierung bewirkt, ähnlich den Emitterwiderständen bei parallelgeschalteten Bipolartransistoren. Das ist ''ausschließlich'' im Schaltbetrieb möglich, und daher falsch! Im Linearbetrieb spielt der Temperaturkoeffizient von <math>R_{DS(ON)}</math> keine Rolle, weil der MOSFET selten bis nie komplett durchgesteuert ist. Eben darum ist beim Linearbetrieb der minimale <math>R_{DS(ON)}</math> in den meisten Fällen unwichtig und man kann auch eher hochohmige, ältere MOSFETs verwenden, wie z.B. den BUZ11.<br />
<br />
Hier wirkt vielmehr der negative Temperaturkoeffizient (TK) der Thresholdspannung <math>U_{GS(thr)}</math>, vergleichbar dem negativen TK der Basis-Emitter-Spannung von Bipolartransistoren. D.h. mit steigender Temperatur und konstanter Gate-Source-Spannung steigt der Stromfluss der Drain-Source Strecke. In einer Parallelschaltung von MOSFETs würde dies bedeuten, dass der MOSFET mit dem geringfügig größeren Drainstrom (Fertigungstoleranzen) wärmer wird, was zu einem weiter steigenden Drainstrom und damit noch mehr Wärme führt. Damit ist die Schaltung thermisch instabil und würde zum Durchbrennen der MOSFETs führen, einer nach dem Anderen. <br />
<br />
Um das zu verhindern muss man relativ große Ausgleichswiderstände in die Source-Leitung der einzelnen MOSFETs schalten, um diese Drift zu kompensieren. Dadurch verschlechtert sich natürlich der Wirkungsgrad des Verstärkers. MOSFETs haben einen TK von typisch -5mV/K für <math>U_{GS(thr)}</math>, das ist mehr als das doppelte von Bipolartransistoren mit typisch -2mV/K, weshalb die Symmetrierungswiderstände mehr als doppelt so groß sein müssen. Weiterhin muss man beachten, dass die Toleranzen von <math>U_{GS(thr)}</math> sehr groß sind, im Bereich von Volt! Das kann man sinnvoll nicht mehr mit Gatewiderständen symmetrieren, hier muss man die MOSFETs ausmessen und Gruppen mit geringen Toleranzen in einer Schaltung verwenden (engl. matching). <br />
<br />
Eine andere Möglichkeit ist die getrennte Ansteuerung der einzelnen MOSFETs, das wird oft in elektronischen Lasten bzw. [[Konstantstromquelle#Konstantstromquelle mit Operationsverstärker und Transistor | Konstantstromquellen]] gemacht. Hier treten keine zusätzlichen Verluste auf und der Mehraufwand in der Ansteuerung ist meist unkritisch.<br />
<br />
Weiterhin muss man beachten, dass viele der heutigen HochleistungsMOSFETs intern eine Parallelschaltung vieler kleiner MOSFET-Zellen (z.B. sogenannte Trench-FET) sind, und somit oft für den Linearbetrieb ungeeignet sind. Denn auch dort können einzelne Zellen überhitzen und durchbrennen (Hot Spot). Ob ein MOSFET für den Linearbetrieb tauglich ist steht manchmal im Datenblatt, oft aber eher nicht, eben weil die meisten MOSFETs als Schalter entwickelt und gebaut sind. Typische Vertreter für Linearbetrieb findet man in der [[MOSFET-Übersicht]]. Ein wichtiges Indiz für Linearbetrieb ist eine Kurve für DC im [[#SOA_Diagramm | SOA-Diagramm]]. Meist geht es dort nur bis 10ms, DC fehlt, eben weil DC (engl. '''D'''irect '''C'''urrent = Gleichstrom = Linearbetrieb) nicht zulässig ist. Manchmal hat der Hersteller auch "vergessen", die Kennlinie für DC mit reinzuschreiben, wie z.B. bei [http://www.irf.com/product-info/hi-rel/alerts/fv5-p-09-01-A.pdf IRF], wie in diesem [http://www.mikrocontroller.net/topic/291760#3106758 Beitrag] zu erfahren ist.<br />
Ein recht gutes Indiz dafür, ob ein FET für den Linearbetrieb taugt, ist die Vorwärtssteilheit. Diese kennzeichnet die Abhängigkeit des Drainstromes von der Ansteuerung am Gate als <math>S = \Delta i_d/\Delta u_{gs}</math>. Moderne Trench-FET erreichen heute Steilheiten im dreistelligen Bereich und sind für Linearanwendungen völlig unbrauchbar. Zum Vergleich: Der BUZ11 kommt mit gerade einmal 4 bis 5 Siemens daher.<br />
<br />
In diesem Beitrag wird die DC-Linie im SOA-Diagramm noch genauer erklärt: [http://www.mikrocontroller.net/topic/319961#3473567 Re: MOSFET Linearbetrieb möglich?]<br />
<br />
<br />
== Siehe auch ==<br />
<br />
* [[Leistungselektronik]]<br />
* [[Mosfet-Übersicht]]<br />
* [[IGBT]]<br />
* [[TRIAC]]<br />
* [[Kühlkörper]] <br />
* [[Zwischenkreiskapazität]]<br />
* [[Treiber]]<br />
* [[Snippets#Wie_schlie.C3.9Fe_ich_einen_MOSFET_an_einen_Mikrocontroller_an.3F|Wie schließe ich einen Mosfet an einen Mikrocontroller an?]]<br />
* [http://www.mikrocontroller.net/articles/H-Br%C3%BCcken_%C3%9Cbersicht Übersicht H-Brücken]<br />
* [http://www.mikrocontroller.net/topic/168218#1609684 Forumsbeitrag]: MOSFETs im Linearbetrieb<br />
* [http://www.mikrocontroller.net/topic/186785#new Forumsbeitrag]: nochmal MOSFETs im Linearbetrieb<br />
* [http://www.mikrocontroller.net/topic/319961#3473567 Forumsbeitrag]: sehr ausführlicher Forumsbeitrag über MOSFETs im Linearbetrieb. Berücksichtigt auch den Spirito-Effekt.<br />
* [http://www.mikrocontroller.net/topic/143324#new Forumsbeitrag]: Über eine elektronische Last, sehr lang<br />
*[http://www.mikrocontroller.net/topic/246449#2519459 Forumsbeitrag]: Logic Level MOSFETs direkt mit einem [[AVR]] treiben.<br />
* [http://www.mikrocontroller.net/topic/267254#2787855 Forumsbeitrag]: MOSFETs im Linearbetrieb, Laborerfahrungen<br />
* [http://www.mikrocontroller.net/topic/267254#2787945 Forumsbeitrag]: MOSFETs für Linearbetrieb<br />
* [https://www.mikrocontroller.net/topic/269642?goto=2820617#2820617 Forumsbeitrag]: Verpol- und Überspannungsschutz mit MOSFETs<br />
* [https://www.mikrocontroller.net/topic/425414#4981611 Forumsbeitrag]: Linearbetrieb von MOSFETs<br />
<br />
== Weblinks ==<br />
<br />
* [http://www.elektronikinfo.de/strom/feldeffekttransistoren.htm Feldeffekttransistoren bei elektronikinfo.de]<br />
* [http://www.elektronik-kompendium.de/sites/bau/0207011.htm FET im ELKO]<br />
* [http://www.elektronik-kompendium.de/sites/bau/0510161.htm MOSFET im ELKO]<br />
* [http://www.sprut.de/electronic/switch/nkanal/nkanal.html MOSFET bei sprut.de]<br />
* [http://sound.westhost.com/articles/hexfet.htm#51 MOSFETs in Audioendstufen, engl.]<br />
* [http://irf.custhelp.com/cgi-bin/irf.cfg/php/enduser/std_adp.php?p_faqid=214&p_created=1019728945&p_sid=pt9ITiCj&p_accessibility=0&p_redirect=&p_lva=&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9MTQsMTQmcF9wcm9kcz0mcF9jYXRzPSZwX3B2PSZwX2N2PSZwX3BhZ2U9MSZwX3NlYXJjaF90ZXh0PWxpbmVhcg**&p_li=&p_topview=1 FAQ Answer ID 214 bei IRF zum Linearbetrieb]<br />
* [http://www.nxp.com/documents/application_note/AN11158.pdf AN11158 - Understanding power MOSFET data sheet parameters] von NXP (PDF)<br />
* [https://assets.nexperia.com/documents/technical-note/TN00008.pdf TN00008 - Power MOSFET frequently asked questions and answers] von nexperia (PDF)<br />
* [http://www.infineon.com/dgdl/Infineon+-+Application+Note+-+PowerMOSFETs+-+OptiMOS%E2%84%A2+-+Linear+Mode+Operation+and+SOA+Power+MOSFETs.pdf?fileId=db3a30433e30e4bf013e3646e9381200 AN: Linear Mode Operation andSafe Operating Diagram of Power-MOSFETs] von Infineon (PDF)<br />
* [http://www.ixys.com/Documents/Articles/Article_Linear_Power_MOSFETs.pdf MOSFETs Withstand Stress of Linear-Mode Operation] Neuentwickelte MOSFETs für Linearbetrieb (PDF)<br />
<br />
[[Kategorie:Bauteile]] [[Kategorie:Leistungselektronik]]</div>Heha