Mikrocontroller.net - Benutzerbeiträge [de]

Operationsverstärker-Grundschaltungen

2025-05-18T17:22:08Z

Maybee: /* Ein- und Ausgangsbereich */ Typo

== Idealisiertes Modell eines OPV==

[[Bild:Opamp-symbol.png]]

=== Anschlüsse ===
Ein Operationsverstärker hat zwei Eingänge (+) und (-) und einen Ausgang
(UA). Außerdem verfügt er über eine positive und eine negative
Spannungsversorgung (V+) und (V-).

=== Spannungsversorgungen ===
Die Spannungsversorgungen sollen zunächst nicht interessieren. Sie
werden in Schaltungen oft nicht eingezeichnet.
In der Praxis ist es jedoch wichtig zu wissen, dass die Ausgangsspannung immer zwischen (V+) und (V-) liegt. Die Ausgangsspannung des OPV kommt schließlich dadurch zustande, dass der Ausgang über einen Transistor mehr oder weniger hochohmig mit den beiden Versorgungsspannungen verbunden wird.

Wenn man einen OPV also mit +5V versorgt, so kann der OPV im besten Fall am Ausgang +5V erzeugen. Man würde in diesem Fall von einem "Rail-to-Rail" Operationsverstärker sprechen.
Bei vielen Operationsverstärkern ist die maximal mögliche Ausgangsspannung geringer als die Versorgungsspannung. Ein mit +5V Spannungsversorgung beschalteter OPV kann dann beispielsweise nur +4V Ausgangsspannung erzeugen.

=== Ausgang ===
Der Ausgang des OPV ist eine ideale Spannungsquelle. Das bedeutet, dass die
Ausgangsspannung unabhängig davon ist, was ausgangsseitig an den OPV
angeschlossen wird.
In der Praxis gilt dieses Modell häufig nur bei "sinnvollen Anwendungen". So ist beispielsweise der Ausgangsstrom des OPV nach oben begrenzt (typischerweise im mA-Bereich), und manche OPV schwingen sehr leicht, wenn man sie kapazitiv belastet.

=== Eingänge ===
Die Eingänge eines OPV sind hochohmig, d. h., es handelt sich nur um "Messfühler", die keinen Strom führen.
Achtung: Die Eingangsschutzbeschaltung (Dioden von GND und gegen VCC) bei manchen OPVs kann jedoch dazu führen, dass Strom in den Eingang fliesst, wenn dessen Betriebsspannung z.B. abgeschaltet ist.

=== Funktionsweise ===
Der OPV mißt zu jeder Zeit die Differenz <math>U_D = U(+) - U(-)</math> der
Eingangsspannungen.

Ist die Spannung an (+) größer als an (-), so erhöht der OPV die
Ausgangsspannung.
Ist die Spannung an (+) niedriger als an (-), so vermindert der OPV die
Ausgangsspannung.

Das Ergebnis dieses Vorgangs wird häufig über die Gleichung:

<math>U_a = v \cdot U_D</math>

beschrieben, wobei <math>v</math> eine sehr große Zahl (10^4...10^6) ist.

Mit Hilfe der beschriebenen Funktionsweise lassen sich alle grundlegenden Schaltungen herleiten.

=== Beispiel ===

Betrachtet wird die invertierende Grundschaltung nach Abbildung a) im Abschnitt [[Operationsverstärker-Grundschaltungen#Verstärkergrundschaltungen|Verstärkergrundschaltungen]].

[[Bild:Op-verstaerker-a.png]]

Für die Pfeilrichtungen der Spannungen und Ströme gilt:
* <math>U_e</math>: von oben nach unten
* <math>I_{R3}</math>: von links nach rechts

Die Spannung am (+)Eingang ist gleich Null. Die Spannung am (-)Eingang wird durch die Spannungsquelle <math>U_e</math> und durch die im OPV befindliche und mit dem Ausgang verbundene Spannungsquelle des OPV manipuliert.

* Ist die Spannung am (-)Eingang negativ, so erhöht der Operationsverstärker die Ausgangsspannung. Dadurch wird durch die Rückführung über den Widerstand auch die Spannung am (-)Eingang positiver. Und zwar so lange, bis die Spannung am (-)Eingang gleich groß ist, wie die Spannung am (+)Eingang, also U(-)=0V.
* Ist die Spannung am (-)Eingang positiv, so vermindert der Operationsverstärker die Ausgangsspannung. Dadurch wird durch die Rückführung über den Widerstand auch die Spannung am (-)Eingang negativer. Und zwar so lange, bis die Spannung am (-)Eingang gleich groß ist, wie die Spannung am (+)Eingang, also U(-)=0V.

Der Operationsverstärker wird also die Spannungen an (+) und (-) angleichen. Das passiert immer dann, wenn der Ausgang mit dem (-)Eingang verbunden ist. Der Trick in dieser Schaltung besteht darin, dass von der Ausgangsspannung nur ein Teil wieder rückgeführt wird. Die Spannung U_e ist daher höher, als der Teil der benötigt wird, um die Spannungen an den Eingängen aneinander anzugleichen.
Man nennt das Prinzip "Gegenkopplung". Auf diese Art und Weise funktionieren alle analogen OPV-Schaltungen.

Da an (+) Massepotential anliegt, wird somit auch (-) daran angeglichen, und so liegt an <math>R_3</math> die Spannung <math>U_e</math> an. Daher gilt:
<math>I_{R3}=\frac{U_e}{R_3}.</math>

Da der (-)Eingang hochohmig ist, fließt <math>I_{R3}</math> über <math>R_4</math> weiter zum OPV-Ausgang.

Ua ist die Spannung vom Ausgang zur (virtuellen) Masse am (-)Eingang.
(--> Pfeil einzeichnen und klarmachen, daß es egal ist, ob der Pfeil vom
Ausgang zur Masse geht oder vom Ausgang "entgegen der Stromrichtung" zur
virtuellen Masse an (-)!)

Mit Hilfe von <math>I_{R3}=\frac{U_e}{R_3}</math> ergibt sich:

<math>U_a = -R_4 \cdot I_{R3} = -{{R_4} \over {R_3}} \cdot U_e.</math>

Die Energie für den Stromtransport über <math>R_4</math> stammt vom OPV! Sobald die Ladungen ausgehend von der Spannungsquelle <math>U_e</math> die virtuelle Masse an (-) erreicht haben, hat <math>U_e</math> seine gesamte Energie abgegeben.

== Reale OPVs / Kennwerte ==
Abweichend vom idealen OPV besitzen reale OPVs diverse Einschränkungen und Kennwerte, die sie für verschiedene Einsätze mehr oder weniger prädestinieren.

=== Leerlaufverstärkung ===
Die Leerlaufverstärkung gibt an, wie stark sich das Ausgangssignal i.A. der Änderung eines Eingangsignals statisch ändert, bzw nach dem Einschwingen erreichen könnte, wenn es nicht durch die Betriebsgrenzen limitiert wäre.

=== Verstärkungs-Bandbreiteprodukt ===
Das Verstärkungs-Bandbreiteprodukt gibt an, bei welcher Verstärkung welche Bandbreite erreicht werden kann. Durch Rückkopplung kann die Verstärkung eingestellt werden. Bei kleinerer Verstärkung ergibt sich somit eine höhere Bandbreite, wenn das Produkt aus beiden konstant ist. Die Bandbreite bei der Verstärkung eins heißt Transitfrequenz (englisch "Unity Gain Frequency"). Das Verstärkungs-Bandbreiteprodukt ist entscheidend für das Kleinsignalverhalten.

=== Anstiegsgeschwindigkeit ===
Bestimmend für das Großsignalverhalten ist neben dem Verstärkungs-Bandbreiteprodukt die Anstiegsgeschwindigkeit (slew rate), da bei hohen Ausgangsamplituden die Ausgangskurve eventuell zu steil wird, um richtig wiedergegeben zu werden.

=== Gleichtaktverstärkung ===
Infolge des inhomogenen Aufbaus der internen Verstärkerstufen werden die beiden Eingangssignale nicht exakt gleich verstärkt, was in einen Gleichanteil und einen Differenzanteil aufgeteilt werden kann. Die nicht erwünschte Gleichtaktverstärkung bzw. ihr Gegenstück, die Gleichtaktunterdrückung (engl. ''common mode rejection ratio, CMRR'') ist dabei ein Maß für die Qualität des OPVs. Klassische (VFB) OPV haben immer ein mit der Frequenz fallendes (-20 dB/Dekade) CMRR.

=== Ein- und Ausgangsbereich ===
Wie weiter oben schon angesprochen ist die Ausgangsspannung eines OPVs begrenzt von der Versorgungsspannung und dem internen Aufbau des OPVs. Standard-OPV erreichen meist einen Ausgangsbereich, der bis circa 1-2 V an Versorgungsspannungen heran reicht, während sogenannte Rail-to-Rail (R2R) OPV sehr nah (bei niedriger Last bis auf wenige mV) an die Versorgungsspannungen herankommt. Das ist jedoch mit Abstrichen verbunden, sodass es in der Regel besser ist R2R OPV nur wenn nötig zu verwenden.

Ähnliche Beschränkungen gibt es auch für die Eingänge eines OPVs, hier werden im Wesentlichen drei Arten unterschieden:

* Klassisch: Eingangsspannung darf nur bis wenige Volt an die Versorgung herankommen.
* Ground-Sensing: Die Eingangsspannung darf bis zur negativen Versorgung heruntergehen, klassische Vertreter sind LM324/LM358.
* Rail-to-Rail Input/Output (RRIO): R2R OPV, wo sowohl Eingänge als auch Ausgänge bis an die Versorgungsspannungen reichen.

Bei klassischen Operationsverstärkern ist zu beachten, dass manche ein Verhalten namens ''phase reversal'' (Phasenumkehr) zeigen, wenn die Eingangsspannung den zulässigen Bereich überschreitet. Bei der Phasenumkehr dreht sich die Phase in der Eingangsstufe des OPVs um 180° und Rückkopplung wird zur Mitkopplung. Ein bekannter Vertreter dieser Art ist die TL06x/TL07x/TL08x Familie von OPV.

== Verstärkergrundschaltungen ==
=== Grundbeschaltung mit Berechnung ===
[[Bild:Op-verstaerker-a.png]] [[Bild:Op-verstaerker-b.png]]

In a) und b) verwenden wir den OPV als Verstärker und nutzen hier die Möglichkeit der Gegenkopplung, um definierte Verstärkungen zu erhalten. Wir gehen wieder davon aus, dass der OPV ein ideales Bauteil ist und daher seine Leerlaufverstärkung unendlich ist. Ebenso betrachten wir den Eingangswiderstand als unendlich.

In '''a)''' ist ein invertierender Verstärker mit einem OPV dargestellt. Durch die Widerstände R3 und R4 wird die Verstärkung bestimmt:

:<math>V = \frac{U_a}{U_e} = -\frac{R_4}{R_3}</math>

Das Verhältnis der beiden Widerstände bestimmt also die Verstärkung und somit die Ausgangsspannung:

:<math>U_a = -\frac{R_4}{R_3} \cdot U_e </math>

oder auch

:<math>U_a = V \cdot U_e</math>

Das negative Vorzeichen drückt aus, dass es sich um einen invertierenden Verstärker handelt.

Beim nichtinvertierenden Verstärker '''b)''' finden wir auch eine Rückkopplung über R6 zum invertierenden Eingang des OPVs. Die Verstärkung wird durch das Gegenkopplungsnetzwerk R6 und R7 bestimmt. Hier ist:

:<math>V = 1 + \frac{R_6}{R_7}</math>

Eine Verstärkung von 1 ist sinnvoll, wenn eingangsseitig eine Spannungsquelle mit hohem Innenwiderstand verwendet wird. Für <math>\frac{R_6}{R_7} \to 0</math> heißt die Schaltung "Spannungsfolger".

Kleinere Werte als 1 lassen sich nicht realisieren. Die Ausgangsspannung errechnet sich also so:

:<math>U_a = U_e \cdot \left (1 + \frac{R_6}{R_7}\right )</math>

Beispiel: Eine Eingangsspannung von 0,5 V soll auf den Wert 5 V verstärkt werden, es ist also eine Verstärkung V von 10 benötigt. R7 ist mit 10 kΩ vorgegeben. Also ist das Verhältnis

:<math>\frac{R_6}{R_7} = V - 1</math>

Bei einem Wert von 10 kΩ für R7 errechnet sich R6 zu

:<math>
R_6 = (V - 1) \cdot R_7
= (10 - 1) \cdot 10\,\mathrm{k\Omega}
= 90\,\mathrm{k\Omega}
</math>

Die Ausgangsspannung Ua wird also:

:<math>
U_a = U_e \cdot \left (1 + \frac{R_6}{R_7}\right )
= 0{,}5\,\mathrm{V} \cdot \left (1 + \frac{90\,\mathrm{k\Omega}}{10\,\mathrm{k\Omega}}\right)
= 5\,\mathrm{V}
</math>

=== Nichtinvertierender Verstärker mit Offset ===
Eine Abwandlung des nichtinvertierenden Verstärkers erlaubt es, einen konstanten Offset vorzugeben. D.h. von der zu verstärkenden Eingangsspannung U(e) wird eine konstante Spannung U(o) abgezogen und die Differenz verstärkt. Auf der Ausgangsspannung U(a) findet sich die Offsetspannung U(o) allerdings wieder.

[[Bild:Op-verstaerker-offset.png]]

Es gilt:

Offsetspannung:
:<math>
U_o = U_V \cdot \frac{R_2}{R_1 + R_2}
</math>
mit U(V) = Versorgungsspannung an R1

Verstärkung:
:<math>
V = 1 + \frac{R_3}{\frac{R_1 \cdot R_2}{R_1 + R_2}}
</math>

Ausgangsspannung:
:<math>
U_a = (U_e - U_o) \cdot V + U_o
</math>

Der Vorteil dieser Schaltung ist, daß nur die Differenz verstärkt wird. Damit kann eine größere Verstärkung gewählt werden. Zu berücksichtigen ist dabei, dass die Ausgangsspannung U(a) um die Offsetspannung U(o) verschoben ist.

=== Spannungsfolger (Impedanzwandler) ===

[[Bild:Op-spannungsfolger1.png]]

Eine Abart des nichtinvertierenden Verstärkers stellt der Spannungsfolger dar. Beim nichtinvertierenden Verstärker errechnet sich die Ausgangsspannung aus:

:<math>U_a = U_e \cdot \left (1 + \frac{R_2}{R_1}\right )</math>

Wenn wir R2 auf 0Ω (mit R1 > 0) oder R1 auf unendlich (mit R2 < ∞) ändern, erhalten wir daher:

:<math>V = 1 + \frac{R_2}{R_1} = 1</math>

Ein Spannungsfolger hat also eine Verstärkung V von 1.

Umgezeichnet sieht die Schaltung dann so aus:

[[Bild:Op-spannungsfolger2.png]]

Man erhält den klassischen Elektrometerverstärker. Der Zweck dieser Schaltung ist die sogenannte Impedanzwandlung. Man nutzt die Eigenschaft, dass ein idealer OP einen unendlichen Eingangswiderstand und einen Ausgangswiderstand von 0Ω hat. Zwar sieht das real natürlich anders aus - so liegt der Eingangswiderstand Re bei normalen OPs in der Größenordnung von 1MOhm bis <math>10^{15} \Omega</math>, der Ausgangswiderstand Ra im Bereich 20Ω bis 1kOhm - trotzdem kann man mit einer solchen Schaltung aus einer relativ hochohmigen Spannungsquelle eine niederohmige, durch Folgeschaltungen belastbare Spannungsquelle machen.

[[Bild:Op-spannungsfolger3.png|left]]

In dem nebenstehenden Beispiel ist eine einfache Möglichkeit zur Erzeugung einer Referenzspannung gezeigt: Es kommt eine normale Stabilisierungsschaltung mit einer Z-Diode (früher "Zenerdiode") und einem Widerstand zur Anwendung, die aber nicht mehr die schlechten Eigenschaften der Standardbeschaltung hat. Trotz des steilen Durchbruchverhaltens einer Z-enerdiode hängt die genaue Spannung davon ab, welcher Strom durch sie fließt. Dieser Strom würde sich aber ändern, wenn ein Verbraucher die Zenerdiode direkt mit einem ungleichmäßigen Stromfluss belasten würde. Als Folge davon würde die Spannungslage der Zenerdiode je nach Verbraucherlast schwanken. Durch den Spannungsfolger wird das verhindert, weil dieser den vom Verbraucher gezogenen Strom bereitstellt und durch den Widerstand an der Z-Diode praktisch immer derselbe Strom fließt. Ein Einfluss ist nur noch durch die Versorgungsspannung gegeben, weil deren Änderung einen minimal geänderten Stromfluss in der Z-Diode auslöst, der bei großen Änderungen wieder Spannungsänderungen bewirkt. Bei Chips in denen sehr genaue Spannungen benötigt werden, kommen daher 2 verkettete Stufen dieser Art zum Einsatz. Die erste stabilisiert den Eingang, die zweite den Ausgang.

{{Clear}}

[[Bild:Op-spannungsfolger4.png|left]]

Eine weitere Anwendungsmöglichkeit wäre das hochohmige Auskoppeln einer Brückenspannung. Die Brückenschaltung selbst wird durch Folgeschaltungen nicht mehr belastet, alle anderen Eigenschaften bleiben erhalten.

{{Clear}}

=== Der Komparator ===

[[Bild:Op-komp-a.png]] [[Bild:Op-komp-b.png]]

In der einfachsten Beschaltung des Operationsverstärkers erhält man einen Komparator. Es fällt auf, dass kein Gegenkopplungsnetzwerk vorhanden ist. Der OP arbeitet daher mit seiner vollen Leerlaufverstärkung Vo. Dies bedeutet, dass bereits eine kleine Eingangsspannung genügt, um den OP in die Begrenzung zu treiben. Das heißt, die Ausgangsspannung Ua wird annähernd die Betriebsspannung erreichen.

Achtung: nicht jeder OP ist als Komparator verwendbar! Manche haben Schutzdioden zwischen invertierendem und nichtinvertierendem Eingang, die bei einem zu großen Spannungsunterschied das Signal kurzschließen. Ob das bei einem konkreten OP-Typ der Fall ist, findet man im Datenblatt: bei den absolute maximum ratings ist die "Differential Input Voltage" angegeben. Wenn dort nur 1 bis 2 Volt stehen, ist der OP nicht als Komparator einsetzbar.
Die sichere Alternative ist jedoch, einen speziellen Komparator-IC zu verwenden. Diese sind im Grunde auch nur OPs, aber für den Komparator-Betrieb optimiert.

Beim Komparator gibt es zwei Möglichkeiten der Beschaltung: die invertierende nach a) und die nichtinvertierende Beschaltung nach b).

'''Berechnungsbeispiel für Schaltung b)'''

Angenommen die Leerlaufverstärkung Vo von 40000 und eine Eingangsspannung von 0,1 Volt. Die Betriebsspannungen Vcc und Vee legen wir auf +/- 24 V fest. Damit ergibt sich theoretisch für Ua:

:<math>U_a = V_0 \cdot U_e = 40000 \cdot 0{,}1\,\mathrm{V} = 4000\,\mathrm{V}</math>

Das ist natürlich ein unrealistischer Wert, da Ua nicht höher sein kann als die Betriebsspannung. Also anders ausgedrückt: Bei welcher Spannung Ue erreicht der OP seine Aussteuerungsgrenze?

:<math>U_e = V_{cc} / V_0 = 24\,\mathrm{V} / 40000 = 0{,}6\,\mathrm{mV}</math>

Das bedeutet, dass eine Spannung von 0,6 mV ausreicht um den Komparator in die Begrenzung zu treiben.

Das gleiche gilt auch für den invertierenden Komparator, allerdings wird hier der OP in die negative Begrenzung gebracht.

:<math>-U_a = V_0 \cdot U_e</math>

Diese beiden einfachsten Komparatorschaltungen werden so nur sehr selten verwendet, weil sie keine Hysterese haben. D.h. es gibt nur eine Umschaltschwelle. Dadurch kann der Ausgang schwingen, wenn das Eingangssignal sehr nah an der Umschaltschwelle liegt, weil kleinste Störungen im Signal den Komparator mehrfach schalten lassen (dafür reichen wenige mV!). Ausserdem sind Operationsverstärker als Komparator relativ langsam, das liegt am inneren Aufbau. Echte Komparatoren sind deutlich schneller und sie haben auch kein Problem damit, wenn der Ausgang in die Sättigung geht. Darum beschaltet man einen OPV bzw. Komparator meistens mit Hysterese. Das nennt man dann einen [[Schmitt-Trigger]].

=== Der Addierer (Summierverstärker) ===

[[Bild:Op-addierer.png]]

Ein als invertierender Verstärker beschalteter OP lässt sich so beschalten, dass ein Summensignal aus den Eingangsspannungen gebildet wird. Um die Funktion deutlich zu machen, ist eine Betrachtung der einzelnen Ströme nötig.

In einem invertierenden Verstärker wird sich die Ausgangsspannung immer so einstellen, dass der invertierende Eingang Massepotential hat. Die virtuelle Masse (VM) unterscheidet sich von einer "normalen" Masse dadurch, dass das Potential durch einen Regelungsvorgang zustande kommt.
An der virtuellen Masse (VM) gilt die Knotenpunktregel, wonach die Summe der zufließenden Ströme gleich der Summe der abfließenden Ströme ist.

:<math>I_1 + I_2 = -I_3</math>

Sofern <math>U_{e1}</math> und <math>U_{e2}</math> bekannt sind, lässt sich die Gleichung umformen in:

:<math>\frac{U_{e1}}{R_1} + \frac{U_{e2}}{R_2} = -\frac{U_a}{R_3}</math>

Nach Ua aufgelöst ergibt sich:

:<math>-U_a = \left (U_{e1} \cdot \frac{R_3}{R_1}\right ) + \left (U_{e2} \cdot \frac{R_3}{R_2}\right ) + ... + \left (U_{en} \cdot \frac{R_3}{R_n}\right )</math>

Einen Sonderfall gibt es, wenn die Widerstände R1 und R2 gleich sind. Dann gilt

:<math>R_1 = R_2 = R_x</math>

und damit

:<math>-U_a = \frac{R_3}{R_x} \cdot (U_{e1} + U_{e2})</math>.

=== Der Subtrahierer (Differenzverstärker) ===

[[Bild:Op-subtrahierer.png]]

Ein Subtrahierer ist die Zusammenschaltung eines invertierenden und eines nichtinvertierenden Verstärkers. Schliessen wir Punkt Ue1 nach Masse kurz und steuern Ue2 an, arbeitet die Schaltung als nichtinvertierender Verstärker. Wird Ue2 nach Masse verbunden und Ue1 angesteuert, verhält sich die Schaltung als invertierender Verstärker (R7 vorerst nicht beachten).

Für den 1. Fall (nichtinvertierender Verstärker) gilt:

:Ua = Ue2 (1 + R6\R4 )

Für den 2. Fall (invertierender Verstärker) gilt:

:Ua = -Ue1 R6\R4

Der dritte Fall ist die Ansteuerung beider Eingänge:

:Ua = -Ue1 R6\R4 + Ue2 (1 + R6\R4 )

Diese Schaltung ist gut für eine Erklärung, praktisch aber taugt sie nichts. Denn liegen an den Eingängen gleiche Spannungen an, ist die Ausgangsspannung nicht 0, wie eigentlich zu vermuten wäre. Deshalb ändern wir die Schaltung und fügen R7 ein. Jetzt stellt sich am Punkt + des OPs die Spannung

:Ue2+ = Ue2 R7\(R5 + R7)

ein. Wenn wir das berücksichtigen, erhalten wir endlich einen richtigen Subtrahierer:

:Ua = Ue2 (1 + R6\R4 ) R7\(R5 + R7) - R6\R4 Ue1

Dies gilt für alle Subtrahierer, obwohl es natürlich auch hier wieder zwei Sonderfälle gibt; nämlich a) wenn alle Gegenkopplungswiderstände gleich sind:

:R6 = R7 = R4 = R5

dann ist

:Ua = Ue2 - Ue1

oder b) wenn die Widerstandsverhältnisse gleich sind :

:R6\R4 = R7\R5

Dann ergibt sich für Ua:

:Ua = (Ue2 R7\R5 ) - (Ue1 R6\R4 )

oder noch einfacher:

:Ua = (Ue2 -Ue1) R6\R4

=== Addierer/Subtrahierer mit unterschiedlichen Faktoren ===
Legt man nicht den + sondern den - Eingang des Operationsverstärkers als Bezugspunkt zur Masse mit einem Widerstand fest, übernimmt der Vorwiderstand vom - Eingang, R4 die Aufgabe von R5.

[[Bild:Op-addsub.png]]

Hier die Schaltung die addieren und subtrahieren kann, mit unterschiedlichen Faktoren.
Sie kann verwendet werden für Aufgaben wie: Gesucht ist eine Schaltung, die aus 0...2.56 V eine Spannung von -10V...10V macht. Für dieses Beispiel wird hier die Dimensionierung durchgeführt:

{| class="wikitable" style="text-align: left"
|<math>U_{e1} = 5\,\mathrm{V}</math>
|Einfach festgelegt, muss nur ein positiver Wert sein
|-
|<math>R_6 = 200\,\mathrm{k\Omega}</math>
|Einfach festgelegt, könnte auch 100k oder 500k sein
|-
|<math>U_{e2i} = 0\,\mathrm{V},\, U_{ai} = -10\,\mathrm{V}</math>
|gewählter momentaner ''Zustand 1'', Ue2 = 0V ist günstig für Berechnung, Ua ist die dazupassende Ausgangsspannung
|-
|<math>U_{e2ii} = 2{,}56\,\mathrm{V},\, U_{aii} = 10\,\mathrm{V}</math>
|gewählter beliebiger ''Zustand 2''
|-
|<math>U_m = U_{e2}</math>
|Gleichgewicht am Eingang
|-
|<math>I_a + I_b = I_c</math>
|In den Eingang fließt "kein" Strom
|-
|<math>\frac{U_a-U_{e2}}{R_6} + \frac{U_{e1}-U_{e2}}{R_4} = \frac{U_{e2}}{R_c}</math>
|Gleichung mit den Unbekannten R4 und Rc
|-
|<math>\frac{U_{ai}-U_{e2i}}{R_6} + \frac{U_{e1}-U_{e2i}}{R_4} = \frac{U_{e2i}}{R_c}</math>
|Variablen für ''Zustand 1'' eingesetzt, bildet 1. Gleichung
|-
|<math>\frac{U_{aii}-U_{e2ii}}{R_6} + \frac{U_{e1}-U_{e2ii}}{R_4} = \frac{U_{e2ii}}{R_c}</math>
|Variablen für ''Zustand 2'' eingesetzt, bildet 2. Gleichung
|-
|<math>R_4=-\frac{R_6\cdot U_{e1}}{U_{ai}}</math>
|2 Gleichungen mit 2 Unbekannten, Lösung durch Umformen der 1. Gleichung nach R4 und einsetzen von Ue2i=0 (freundlicherweise fällt die 2. Unbekannte dabei raus)
|-
|<math>R_4 = 100\,\mathrm{k\Omega}</math>
|restliche Werte eingesetzt
|-
|<math>R_c=\frac{R_6\cdot U_{e1}\cdot U_{e2ii}}{U_{aii}\cdot U_{e1}-U_{ai}\cdot (U_{e1}-U_{e2ii})-U_{e1}\cdot U_{e2ii}}</math>
|Ergebnis für R4 in die 2. Gleichung einsetzen und Umformen nach Rc
|-
|<math>R_c = 41{,}6\,\mathrm{k\Omega}</math>
|Werte eingesetzt
|}

=== Der Instrumenten-Verstärker ===

[[Bild:Instrument.png]]

Ein Nachteil des Subtrahierers ist sein geringer Eingangswiderstand. Um den nahezu unendlichen Eingangswiderstand des verwendeten Operationsverstärkers zu erreichen, kann man einfach vor beide Eingänge je einen Impedanzwandler vorschalten.
Die hier beschriebene Schaltung ist um drei Widerstände erweitert und ermöglicht die Einstellung der Differenz-Verstärkung über nur einen Widerstand, nämlich R2.

Am invertierenden Eingang von IC1A gilt (Knotenregel):

:<math>\frac{U_{a1}-U_{e1}}{R_1}-\frac{U_{e1}-U_{e2}}{R_2}=0</math>

Am invertierenden Eingang von IC1C gilt (Knotenregel):

:<math>\frac{U_{a2}-U_{e2}}{R_1}+\frac{U_{e1}-U_{e2}}{R_2}=0</math>

Subtrahiert man die beiden Gleichungen voneinander, erhält man:

:<math>U_{a2}-U_{a1}=(U_{e2}-U_{e1})\cdot\left (1+\frac{2\cdot R_1}{R_2}\right )</math>

Letztere Differenz ist die Eingangsspannung eines normalen Subtrahierers mit der Verstärkung 1.

Also ergibt sich als Ausgangsspannung:

:<math>U_a=(U_{e2}-U_{e1}) \cdot \left (1+\frac{2\cdot R_1}{R_2}\right )</math>

Die Differenzverstärkung beträgt demnach:

:<math>V=\left (1+\frac{2\cdot R_1}{R_2} \right )</math>

Anwendung: Auswertung von Brückenschaltungen, wie Drucksensoren oder Dehnungsmessstreifen, die durch den Eingangswiderstand der Messschaltung nicht belastet werden dürfen. 
Instrumenten-Verstärker kann man auch fertig kaufen. Im INA102 ist die komplette Schaltung integriert. Für R2 sind 3 verschiedene Werte eingebaut, die bei passender Verschaltung eine Verstärkung von 1, 10, 100 oder 1000 ermöglichen.

Da die Gleichtaktunterdrückung hauptsächlich von der Übereinstimmung der Widerstände abhängt, sind für viele Standardanwendungen, insbesondere solche mit niedriger erforderlicher Bandbreite, integrierte Instrumentenverstärker zu bevorzugen.

=== Der Potentialdifferenzverstärker ===

[[Datei:Potentialdifferenzverstärker.png|400px]]

Der Potentialdifferenzverstärker ist eine OPV-Schaltung zum gewichteten Addieren und Subtrahieren beliebiger Spannungen.

Falls die Bedingung
<math>
\sum\frac{R_{0}}{R_{i}}=\sum\frac{R_{0}^{'}}{R_{i}^{'}}
</math>
erfüllt ist, vereinfacht sich der Term für die Ausgangsspannung zu folgendem Term:

<math>
U_{a}=\sum\frac{R_{0}^{'}}{R_{i}^{'}}U_{i}^{'}-\sum\frac{R_{0}}{R_{i}}U_{i}
</math>

== Rechenschaltungen ==

=== Der Integrator ===

Der Integrator wird verwendet, um die Integration eines Signales vorzunehmen. Sein Verhalten entspricht im wesentlichem der mathematischen Integration.

=== Der Differentiator ===

Der Differentiator wird verwendet, um die Differentiation (Ableitung) eines Signales vorzunehmen. Er funktioniert ähnlich wie ein Hochpass. Die Ausgangsspannung ist proportional zur Änderung der Eingangsspannung. Die Dimensionierung für eine stabile Funktion ist nicht ganz einfach, dadurch wird diese Schaltung selten verwendet.

=== Der Logarithmierer ===

Logarithmierer werden mit der Kennlinie einer Diode konstruiert, die einen eingeprägten Strom in eine Spannung übersetzt.

=== Potenzieren ===

= Spannungsversorgung und Beschaltung =

== Betrieb mit einfacher Versorgungsspannung ==

Häufig möchte man eine Wechselspannung wie z.B. ein Audiosignal, das auch negative Spannungen enthält, mit einem Opamp verstärken, hat aber nur eine einfache, in Bezug zu Masse positive Versorgungsspannung zur Verfügung. Dafür bieten sich folgende Schaltungen an, die in der Literatur leider häufig vernachlässigt werden.

Durch die Kondensatoren können die Operationsverstärker in geeigneten Arbeitspunkten betrieben werden, obwohl die Eingangs- und Ausgangsspannungen echte Wechselspannungen sind. Nachteil ist die Hochpasswirkung der Kondensatoren in Verbindung mit den verwendeten Widerständen. Die Grenzfrequenz der Hochpässe muss tief genung gewählt werden, um den gewünschten Frequenzbereich verstärken zu können. Zur Verstärkung von Gleichspannungen (z.B. aus Temperatursensoren) sind diese Schaltungen nicht geeignet.

=== Nichtinvertierender Verstärker ===

[[Bild: Ss_opamp1.png]]

Der positive Eingang wird mit einem Spannungsteiler (R3 und R5) auf die halbe Betriebsspannung gelegt. Dieser Spannung wird dann die zu verstärkende Eingangswechselspannung überlagert. Mit den Kondensatoren am Eingang (C1) und Ausgang (C2) wird der Gleichspannungsanteil abgekoppelt.

Die Verstärkung hat in diesem Beispiel für Wechselspannung den Wert 11 (Formel wie oben), für Gleichspannung aber den Wert 1, da C4 für Gleichspannung einen unendlichen Widerstand darstellt. C3 sollte dorthin führen, wo das Eingangssignal seinen Bezugspunkt hat, also die Abschirmung der Cinch-Buchse, während R5 dorthin führt, von wo der Operationsverstärker seine negative Versorgungsspannung bekommt, falls das nicht die gleichen Potentiale, hier GND, sein sollten.

=== Invertierender Verstärker ===

Das Prinzip funktioniert analog auch für die invertierende Beschaltung:

[[Bild: Ss_opamp2.png]]

== Betrieb mit negativer Hilfsspannung ==

Alternativ lässt sich auch eine negative Hilfsspannung erzeugen. Damit bekommt der Operationsverstärker seine "Plus-Minus"-Versorgung, und er kann Wechselspannungen um das Ground-Potential herum problemlos verstärken.

Die negative Hilfsspannung erzeugt man zweckmässigerweise mit einer Ladungspumpe. Dazu bieten sich zwei Möglichkeiten an:

* einen speziellen IC nach der Art eines ICL 7660
* eine Rechteckspannung auf einen Spannungsverdoppler geben. Dieser besteht aus 2 Dioden und 2 Kondensatoren. Die Konfiguration sollte natürlich so sein, dass eine negative Hilfsspannung erzeugt wird. Schaltbeispiele gibt's im Netz. Als Rechteckspannung kann ein unbenutzter PWM-Ausgang dienen, der mit 50% Tastverhältnis läuft.

Ein Ripple auf der negativen Hilfsspannung wird von modernen Operationsverstärkern wirkungsvoll unterdrückt. Die PSRR (power supply rejection ratio) weist oft Werte um 120 dB auf (bei 120 Hz, darüber fällt sie meist mit 20 dB/Dekade).

Siehe auch http://de.wikipedia.org/wiki/Ladungspumpe#Negative_Ausgangsspannungen

= Kaufempfehlung =
LM358 2 OPs in einem Gehäuse oder
LM324 4 OPs in einem Gehäuse

MCP6001/6004 CMOS OPs mit Rail to Rail Input und Output, tiefem Stromverbrauch, und geringer Versorgungsspannung

Preis jeweils ca. 0,30€ aus Deutschland oder ca. 2 bis 4 cent aus China (AliExpress, ebay, …).

Siehe auch [[Standardbauelemente#Operationsverst.C3.A4rker|Standardbauelemente - Operationsverstärker]].

Wer Audio OpAmps sucht - tangentsoft.net hat mal welche unter die Lupe genommen: [http://www.tangentsoft.net/audio/opamps.html Notes on Audio OpAmps]

= Siehe auch =
* [[Schmitt-Trigger]]
* [[Aktiver RC-Bandpass]]
* [https://www.mikrocontroller.net/topic/396747#4567112 Forumsbeitrag]: Pegelanpassung 0 bis 3V auf -15 bis +20V
* [https://www.mikrocontroller.net/topic/466046?goto=5686087#5686087 Forumsbeitrag]: Strommessung an der Versorgungsspannung, Fehlerbetrachtung und verbesserte Schaltung
* [https://www.mikrocontroller.net/topic/510652?goto=6542833#6542656 Forumsbeitrag]: "bouncing ball" Schaltung gesucht
* [https://www.mikrocontroller.net/topic/512469#6575560 Forumsbeitrag]: Maximum von zwei 4-20mA Eingängen auf einen 4-20mA Ausgang bilden
* [https://www.mikrocontroller.net/topic/514936#new Forumsbeitrag]: 1500V Linearverstärker
* [https://www.mikrocontroller.net/topic/519089#6704061 Forumsbeitrag]: Suche OpAmp RRIO bis 36V out
* [https://www.mikrocontroller.net/topic/524737?goto=6822386#6820279 Forumsbeitrag]: Sinusgenerator mit HV-Endstufe gesucht
* [https://www.mikrocontroller.net/topic/532820?goto=6981066#6980991 Forumsbeitrag]: Differenzverstärker für hohe Eingangsspannungen
* [https://www.mikrocontroller.net/topic/158333?goto=2439071#2439071 Forumsbeitrag]: Audioverstärker mit +/-120V Ausgangsspannung
* [https://www.mikrocontroller.net/topic/555507?goto=7434148#7434148 Forumsbeitrag]: High Voltage Amplifier

= Weblinks =
*[http://www.ti.com/ww/en/bobpease/assets/AN-31.pdf AN-31] - National Semiconductor Application Note 31 mit vielen weiteren OP-Schaltungen
*[https://e2echina.ti.com/cfs-file/__key/telligent-evolution-components-attachments/00-52-01-00-00-04-59-46/OP-amp-for-everyone.pdf Op Amps for Everyone], sehr umfangreiches Dokument zu OPV und deren Anwendung, englisch 
* [http://www.elektronik-kompendium.de/sites/bau/0209092.htm Operationsverstärker im ElKo]
*[http://www.inf.fu-berlin.de/lehre/WS00/peg/folien/Peg_v7a.pdf OP Teil 1], [http://www.inf.fu-berlin.de/lehre/WS00/peg/folien/Peg_v7b.pdf OP Teil 2] - OP-Schaltungen (deutsch)
* [http://www.roboternetz.de/wissen/index.php/Operationsverst%C3%A4rker RN-Wissen Operationsverstärker]
* [http://www.national.com/AU/design/0,4706,268_0_,00.html Online Seminar] von National Semiconductor
* [http://www.franzis.de/elo-das-magazin/grundlagen-und-ausbildung/operationsverstaerker/der-operationsverstaerker ELO-Online-Magazin, Franzis-Verlag], [http://www.franzis.de/online-shop/elektronik/lernpakete-elektronik/lernpaket-elektronik-mit-ics Lernpaket Elektronik mit ICs] "Elektronische Experimente mit integriertem Schaltkreis", Kasten mit Steckbrett/Bauelementen (ca. 40EUR),
* [https://web.archive.org/web/20130828131053/http://elektronikwissen.net/opamp/9-opamp-wissen.html OpAmp Praxis], Praktikertipps + schwingende Operationsverstärker in den Griff bekommen 
* [https://en.wikipedia.org/wiki/Frequency_multiplier Frequenzvervielfacher]
* [https://sound-au.com/appnotes/an001.htm Präzisionsgleichrichter], engl.
* [https://play.google.com/store/apps/details?id=com.wdcreative.elektropro ElektroEasy-App], Berechnung von OPVs
* [http://www.elektronikinfo.de/strom/operationsverstaerker.htm Grundlagen Operationsverstärker]
* [http://www.elektronikinfo.de/strom/op_rauschen.htm Rauschverhalten von OpAmps]
* [https://www.edn.com/class-ab-inverting-amp-uses-two-floating-amplifier-cells/ Class AB inverting amp uses two floating-amplifier cells], HV-Verstärker mit +/-500V Ausgangsspannung
* [https://www.youtube.com/watch?v=qNeOWJz2oUw#t=21m11s A deeper insight into Differential Amplifiers with high common mode voltage], Youtube-Video
* [http://www.rinck-electronics.de/ Rinck Electronics GmbH], Messtechnik - Stromversorgung - Anzeigen - Handbedienebenen
* [https://www.youtube.com/watch?v=1voyXXpq-k0#t=27m TSP #246] - High-Voltage Amplification, Signal Generation, Power Supply Design Tutorial & Experiments
* [https://tlk-energy.de/blog/pid-regler-einstellen PID Regler einstellen]
* [https://www.youtube.com/playlist?list=PLMKxBlyAyypxuaI7pbfRkSryvTDef_Y1S The Bob Pease Show], Youtube Playlist
* [https://www.youtube.com/watch?v=qC7hrYJVvD8 Was macht ein PID-Regler?] Youtube Video (engl.)

[[Category:Grundlagen]]
[[Category:Bauteile]]

Entprellung

2016-11-13T15:53:59Z

Maybee:

== Problembeschreibung ==
Mechanische stromführende Komponenten wie [[Schalter]] und [[Taster]] neigen beim Ein- und Ausschalten zum sogenannten '''Prellen''', d.h sie schalten schnell mehrfach aus und ein, was durch mechanische Vibrationen des Schaltkontaktes verursacht wird, sofern sie nicht mit aufwändigen mechanischen Maßnahmen dagegen geschützt sind. Besonders die [[Drehgeber]] sind aufgrund der Raststellungen und der Bewegung des Bedieners dafür empfindlich. Auch optoelektronische Bauelemente und chemische Kontaktschalter, sowie Flüssigkeitsschalter haben das Problem.

Vereinfacht dargestellt, sieht eine von einem prellenden Schalter oder Taster geschaltete Spannung wie folgt aus:
[[Bild:Entprellen.png]]

Es existieren also mehrere kurze Einschaltimpulse, welche bei Tastern als Mehrfachbefehl und bei Drehgebern als falsche Winkelbewegung interpretiert werden kann. Bei Schaltern wiederum, kommt es in der elektronischen Baugruppe zu mehreren Resets und Einschaltvorgängen, die unnötig Strom ziehen oder im schlechtesten Fall die Schaltung stressen oder beschädigen können. Wichtige Schalter und solche, die hohe Ströme führen sollen, werden dazu mit geeigneten Maßnahmen wie Redundanz, Stufenschaltkonzepten oder bei Gas- und Flüssigkeitschaltern durch elektrochemische Maßnahmen abgesichert. Bei einfachen Schaltern spart man sich dies jedoch.

Da es bei diesen einfachen, ungeschützten Schaltern keine sichere Möglichkeit gibt, diese Effekte zu vermeiden, muss das falsche Signal durch die Elektronik sinnvoll ausgewertet werden. Dafür gibt es verschiedene Ansätze:

== Hardwareentprellung ==

===Prellfreie Schalter===

Wie bereits angedeutet, hält die elektromechanische Industrie für Spezialanwendungen verschiedene Sonderkonstruktionen bereit, die saubere Schaltzustände nach Aussen generieren, indem sie entweder eine mechanische Dämpfung in Form eines selbsthemmenden Federmechanismus oder eine integrierte elektronische Signalverzögerung benutzen. Solche Systeme sind jedoch teuer und werden meist nur im Leistungsbereich eingesetzt. Zudem sind sie nicht 100% sicher und fallen alterungsbedingt aus. Wo immer es geht, werden daher weitere Maßnahmen getroffen, ein Prellen zu unterdrücken.

===Wechselschalter===

Für die Entprellung von Wechselschaltern (engl. Double Throw Switch) kann ein klassisches RS-[[Flipflop]] genutzt werden. Bei dieser Variante werden neben zwei NAND-Gattern nur noch zwei Pull-Up Widerstände benötigt.

[[Bild:NAND_debouncer.png|thumb|left|350px|'''Taster entprellen mit NAND-RS-Flipflop''']]

 

In der gezeigten Schalterstellung liegt an der Position /S der Pegel 0 an. Damit ist das Flipflop gesetzt und der Ausgang auf dem Pegel 1. Schließt der Schalter zwischen den Kontakten 2 und 3, liegt an der Postion /R der Pegel 0 an. Dies bedeutet, dass der Ausgang des Flipflops auf den Pegel 0 geht. Sobald der Schalter von einem zum anderen Kontakt wechselt, beginnt er in der Regel zu prellen. Während des Prellens wechselt der Schalter zwischen den beiden Zuständen "Schalter berührt Kontakt" und "Schalter ist frei in der Luft". Der Ausgang des Flipflops bleibt in dieser Prellzeit aber stabil, da der Schalter während des Prellens nie den gegenüberliegenden Kontakt berührt und das RS-Flipflop seinen Zustand allein halten kann. Die Prellzeit ist stark vom Schaltertyp abhängig und liegt zwischen 0,1 und 10ms. Die Dimensionierung der Widerstände ist relativ unkritisch. Als Richtwert können hier 100kOhm verwendet werden.

====Wechselschalter ohne Flip-Flop====

Wenn man mal gerade kein Flip-Flop zur Hand hat, kann man sich auch mit dieser Schaltung behelfen.

[[Bild:WechselEntprellC.PNG|thumb|left|350px|'''Wechsler entprellen mit Kondensator''']]

 

Zur Funktionsweise:
Beim Umschalten wird der Kondensator immer sofort umgeladen.
Während der Kontakt prellt, befindet er sich in der Luft und hat keinerlei Verbindung. Während dieser Zeit übernimmt der Kondensator das halten des Pegels.

Dimensionierung:
Ist der entprellte Taster an ein IC Angeschlossen, ist der ''Input Leakage Current'' der ausschlaggebende Strom. Falls weitere Ströme fließen sind diese mit zu berücksichtigen. Bei einem Mikrocontroller von Atmel sind 1µA typisch.
Es gilt:
:<math>\frac{dU}{dt} = \frac{I}{C}</math>
Da eine Prellung ca. 10ms dauert und die Spannung in dieser Zeit beispielsweise um maximal 0,5V fallen soll kommt man auf folgende Kapazität:
:<math> C = \frac{I \cdot dt}{dU} = \frac{1\mu A \cdot 10ms}{0,5V} = 20nF </math>

Um Stromspitzen zu verringern kann ein Widerstand mit eingefügt werden. Eine Zeitkonstante von 1µs bis 1ms scheint sinnvoll. Also 500 Ohm bis 500kOhm sind nutzbar, wobei bei niedrigem Widerstand die Stromspitzen höher sind, und bei 500kOhm der Pinstrom störend wird.

===Einfacher Taster===

Auch wenn das RS-Flipflop sehr effektiv ist, wird diese Variante der Entprellung nur selten angewendet. Grund dafür ist, dass in Schaltungen häufiger einfache Taster eingesetzt werden. Diese sind oft kleiner und preisgünstiger. Um einfache Taster (engl. Single Throw Switch) zu entprellen, kann ein einfacher RC-Tiefpass eingesetzt werden. Hierbei wird ein Kondensator über einen Widerstand je nach Schalterstellung auf- oder entladen. Das RC-Glied bildet einen Tiefpass, sodass die Spannung über den Kondensator nicht von einen Pegel auf den anderen springen kann.

[[Bild:RC_debouncer.png|thumb|left|300px|Taster entprellen mit RC-Entpreller]]

[[Datei:Entprellen1a.png|thumb|350px| Entstehender Spannungsverlauf]]
{{Absatz}}

Wenn der Schalter geöffnet ist, lädt sich der Kondensator langsam über die beiden Widerstände R1 und R2 auf Vcc auf. Beim Erreichen der Umschaltschwelle springt der Ausgang auf den Pegel 0. Wird der Schalter geschlossen, entlädt sich der Kondensator langsam über den Widerstand R2. Demnach ändert sich der Ausgang des Inverters auf den Pegel 1. Während der Taster prellt, kann sich die Spannung über dem Kondensator nicht sprunghaft ändern, da das Auf- und Entladen eher langsam über die Widerstände erfolgt. Außerdem sind die Schaltschwellen für den Übergang LOW->HIGH und HIGH->LOW stark verschieden (Hysterese, siehe Artikel [[Schmitt-Trigger]]). Bei richtiger Dimensionierung der Bauelemente wird somit der Ausgang des Inverters prellfrei.

Zu beachten ist, dass der Inverter '''unbedingt''' einer mit [[Schmitt-Trigger]]-Eingängen sein muss, weil bei Standard-Logikeingängen im Bereich von üblicherweise 0,8V - 2,0V der Ausgang nicht definiert ist. Als Inverter kann zum Beispiel der 74HC14 oder der CD40106 (pinkompatibel) eingesetzt werden. Alternativ kann auch ein CD4093 eingesetzt werden. Bei dem CD4093 handelt es sich um NAND-Gatter mit Schmitt-Trigger-Eingängen. Um aus einem NAND-Gatter einen Inverter zu machen, müssen einfach nur die beiden Eingänge verbunden werden oder ein Eingang fest auf HIGH gelegt werden.

Für eine geeignete Dimensionierung muss man etwas mit den Standardformeln für einen Kondensator jonglieren. Die Spannung über den Kondensator beim Entladen berechnet sich nach:
:<math>U_C(t) = U_0 \cdot e^{\frac{-t}{R_2 C_1}}</math>

Damit der Ausgang des Inverters stabil ist, muss die Spannung über den Kondensator und damit die Spannung am Eingang des Inverters über der Spannung bleiben, bei welcher der Inverter umschaltet. Diese Schwellwertspannung ist genau die zeitabhängige Spannung über den Kondensator.
:<math>U_C(t)\!\ = U_{th}</math>

Durch Umstellen der Formel ergibt sich nun:
:<math>R_2=\frac{-t}{C_1 \cdot ln\left(\frac{U_{th}}{U_0} \right)}</math>

Ein Taster prellt üblicherweise etwa 10ms. Zur Sicherheit kann bei der Berechnung des Widerstandes eine Prellzeit von 20ms angenommen werden. U_0 ist die Betriebsspannung also Vcc. Die Schwellwertspannung muss aus dem Datenblatt des eingesetzten Schmitt-Triggers abgelesen werden. Beim 74HC14 beträgt der gesuchte Wert 2,0V. Nimmt man für den Kondensator 1µF und beträgt die Betriebsspannung 5V, ergibt sich für den Widerstand ein Wert von etwa 22kOhm.

Wird der Schalter geöffnet, lädt sich der Kondensator nach folgender Formel auf:
:<math>U_C(t) = U_0 \cdot \left( 1-e^{\frac{-t}{(R_1+R_2)\cdot C_1}} \right)</math>

Mit U_th=U_C ergibt das Umstellen nach (R_1+R_2):
:<math>R_1+R_2 = \frac{-t}{C_1 \cdot ln\left(1-\frac{U_{th}}{U_0} \right)} </math>

Für die Schwellspannung lässt sich aus dem Datenblatt ein Wert von 2,3V ablesen. Mit diesem Wert und den Annahmen von oben ergibt sich für R_1+R_2 ein Wert von 32kOhm. Somit ergibt sich für R_1 ein Wert von etwa 10kOhm.

Anmerkung: Beim 74LS14 von Hitachi z. B. sind die oberen und unteren Schaltschwellwerte unterschiedlich. Es muss darauf geachtet werden, dass U_{th} beim Entladen die untere Schwelle und U_{th} beim Laden die obere Schwelle einnimmt.

== Softwareentprellung ==

In den Zeiten der elektronischen Auswertung von Tastern und Schaltern ist das softwaretechnische Entprellen oft billiger, als die Benutzung eines teuren Schalters. Daher werden heute z.B. auch Computertastaturen nicht mehr mit prellarmen Tasten oder Entprellkondensatoren ausgestattet.

Bei Verwendung des in den meisten Geräten ohnehin vorhandenen Mikrocontrollers z.B., kann man sich die zusätzliche Hardware sparen, da die Entprellung in Software praktisch genauso gut funktioniert. Dabei ist nur zu beachten, dass zusätzliche Rechenleistung und je nach Umsetzung auch einige Hardwareressourcen (z.B. Timer) benötigt werden. Dafür hat man aber den Vorteil, kurze Pulse, die offensichtlich keine Tastenbetätigung sein können sondern z. B. durch Einstreuungen hervorgerufen werden, einfach ausfiltern zu können.

=== Flankenerkennung ===
Bei einem Taster gibt es insgesamt 4 theoretische Zustände:

* 1. war nicht gedrückt und ist nicht gedrückt
* 2. war nicht gedrückt und ist gedrückt (steigende Flanke)
* 3. war gedrückt und ist immer noch gedrückt
* 4. war gedrückt und ist nicht mehr gedrückt (fallende Flanke)

Diese einzelnen Zustände lassen sich jetzt bequem abfragen/durchlaufen. Die Entprellung geschieht dabei durch die ganze Laufzeit des Programms. Die Taster werden hierbei als Active-Low angeschlossen, um die internen Pull-Ups zu nutzen.

Diese Routine gibt für den Zustand "steigende Flanke" den Wert "1" zurück, sonst "0"

<syntaxhighlight lang="c">
#define TASTERPORT PINC
#define TASTERBIT PINC1

char taster(void)
{
static unsigned char zustand;
char rw = 0;

if(zustand == 0 && !(TASTERPORT & (1<<TASTERBIT))) //Taster wird gedrueckt (steigende Flanke)
{
zustand = 1;
rw = 1;
}
else if (zustand == 1 && !(TASTERPORT & (1<<TASTERBIT))) //Taster wird gehalten
{
zustand = 2;
rw = 0;
}
else if (zustand == 2 && (TASTERPORT & (1<<TASTERBIT))) //Taster wird losgelassen (fallende Flanke)
{
zustand = 3;
rw = 0;
}
else if (zustand == 3 && (TASTERPORT & (1<<TASTERBIT))) //Taster losgelassen
{
zustand = 0;
rw = 0;
}

return rw;
}
</syntaxhighlight>

Eine Erweiterung, damit beliebig lange das Halten einer Taste erkannt wird kann man ganz einfach so implementieren:

<syntaxhighlight lang="c">
// zustand kann entweder zum ersten mal als gehalten detektiert werden oder aber jedes weitere mal
else if (((zustand == 1) || (zustand == 2)) && !(TASTERPORT & (1<<TASTERBIT))) //Taster wird gehalten
{
zustand = 2;
rw = 0;
}
</syntaxhighlight>

=== Warteschleifen-Verfahren ===

Soll nun mit einem Mikrocontroller gezählt werden, wie oft ein Kontakt oder ein Relais geschaltet wird, muss das Prellen des Kontaktes exakt berücksichtigt - und von einem gewollten Mehrfachschalten abgegrenzt werden, da sonst möglicherweise Fehlimpulse gezählt- oder andererseits echte Schaltvorgänge übersprungen werden. Dies muss beim Schreiben des Programms hinsichtlich des Abtastens des Kontaktes unbedingt Rechnung getragen werden.

Beim folgenden einfachen Beispiel für eine Entprellung ist zu beachten, dass der AVR im Falle eines Tastendrucks 200ms wartet, also brach liegt. Bei zeitkritischen Anwendungen sollte man ein anderes Verfahren nutzen (z. B. Abfrage der Tastenzustände in einer Timer-Interrupt-Service-Routine).

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <inttypes.h>
#ifndef F_CPU
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h> /* bei alter avr-libc: #include <avr/delay.h> */

/* Einfache Funktion zum Entprellen eines Tasters */
inline uint8_t debounce(volatile uint8_t *port, uint8_t pin)
{
if ( !(*port & (1 << pin)) )
{
/* Pin wurde auf Masse gezogen, 100ms warten */
_delay_ms(50); // Maximalwert des Parameters an _delay_ms
_delay_ms(50); // beachten, vgl. Dokumentation der avr-libc
if ( *port & (1 << pin) )
{
/* Anwender Zeit zum Loslassen des Tasters geben */
_delay_ms(50);
_delay_ms(50);
return 1;
}
}
return 0;
}

int main(void)
{
DDRB &= ~( 1 << PB0 ); /* PIN PB0 auf Eingang Taster) */
PORTB |= ( 1 << PB0 ); /* Pullup-Widerstand aktivieren */
...
if (debounce(&PINB, PB0))
{
/* Falls Taster an PIN PB0 gedrueckt */
/* LED an Port PD7 an- bzw. ausschalten: */
PORTD = PORTD ^ ( 1 << PD7 );
}
...
}
</syntaxhighlight>

Die obige Routine hat leider mehrere Nachteile:
* sie detektiert nur das Loslassen (unergonomisch)
* sie verzögert die Mainloop immer um 100ms bei gedrückter Taste
* sie verliert Tastendrücke, je mehr die Mainloop zu tun hat.

Eine ähnlich einfach zu benutzende Routine, aber ohne all diese Nachteile findet sich im Forenthread
[http://www.mikrocontroller.net/topic/164194#new Entprellung für Anfänger]

Der ''DEBOUNCE'' Befehl in dem BASIC-Dialekt BASCOM für AVR ist ebenfalls nach dem Warteschleifen-Verfahren programmiert. Die Wartezeit beträgt standardmäßig 25 ms, kann aber vom Anwender überschrieben werden. Vgl. [http://avrhelp.mcselec.com/bascom-avr.html?DEBOUNCE BASCOM Online-Manual zu DEBOUNCE].

Eine C-Implementierung für eine Tastenabfrage mit Warteschleife ist im Artikel [[AVR-GCC-Tutorial#IO-Register_als_Parameter_und_Variablen|AVR-GCC-Tutorial: IO-Register als Parameter und Variablen]] angeben.

Der Nachteil dieses Verfahrens ist, dass der Controller durch die Warteschleife blockiert wird. Günstiger ist die Implementierung mit einem Timer-Interrupt.

==== Warteschleifenvariante mit Maske und Pointer (nach Christian Riggenbach) ====

Hier eine weitere Funktion, um Taster zu entprellen: Durch den zusätzlichen Code kann eine Entprellzeit von durchschnittlich 1-3ms (mindestens 8*150µs = 1ms) erreicht werden. Grundsätzlich prüft die Funktion den Pegel der Pins auf einem bestimmten Port. Wenn die/der Pegel 8 Mal konstant war, wird die Schleife verlassen. Diese Funktion kann sehr gut eingesetzt werden, um in einer Endlosschleife Taster anzufragen, da sie, wie erwähnt, eine kurze Wartezeit hat.

<syntaxhighlight lang="c">
void entprellung( volatile uint8_t *port, uint8_t maske ) {
uint8_t port_puffer;
uint8_t entprellungs_puffer;

for( entprellungs_puffer=0 ; entprellungs_puffer!=0xff ; ) {
entprellungs_puffer<<=1;
port_puffer = *port;
_delay_us(150);
if( (*port & maske) == (port_puffer & maske) )
entprellungs_puffer |= 0x01;
}
}
</syntaxhighlight>
Die Funktion wird wie folgt aufgerufen:
<syntaxhighlight lang="c">
// Bugfix 20100414
// http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass
entprellung( &PINB, (1<<PINB2) ); // ggf. Prellen abwarten
if( PINB & (1<<PINB2) ) // dann stabilen Wert einlesen
{
// mach was
}
else
{
// mach was anderes
}
</syntaxhighlight>
Als Maske kann ein beliebiger Wert übergeben werden. Sie verhindert, dass nichtverwendete Taster die Entprellzeit negativ beeinflussen.

==== Debounce-Makro von Peter Dannegger ====

Peter Dannegger hat in [http://www.mikrocontroller.net/topic/164194#1566921 "Entprellen für Anfänger"] folgende vereinfachtes Entprellverfahren beschrieben. Das Makro arbeitet in der Originalversion mit ''active low'' geschalteten Tastern, kann aber einfach für ''active high'' geschaltete Taster angepasst werden ([[Pollin Funk-AVR-Evaluationsboard#Tasty Reloaded|Tasty Reloaded]]).

<syntaxhighlight lang="c">
/************************************************************************/
/* */
/* Not so powerful Debouncing Example */
/* No Interrupt needed */
/* */
/* Author: Peter Dannegger */
/* */
/************************************************************************/
// Target: ATtiny13

#include <avr/io.h>
#define F_CPU 9.6e6
#include <util/delay.h>

#define debounce( port, pin ) \
({ \
static uint8_t flag = 0; /* new variable on every macro usage */ \
uint8_t i = 0; \
\
if( flag ){ /* check for key release: */ \
for(;;){ /* loop ... */ \
if( !(port & 1<<pin) ){ /* ... until key pressed or ... */ \
i = 0; /* 0 = bounce */ \
break; \
} \
_delay_us( 98 ); /* * 256 = 25ms */ \
if( --i == 0 ){ /* ... until key >25ms released */ \
flag = 0; /* clear press flag */ \
i = 0; /* 0 = key release debounced */ \
break; \
} \
} \
}else{ /* else check for key press: */ \
for(;;){ /* loop ... */ \
if( (port & 1<<pin) ){ /* ... until key released or ... */ \
i = 0; /* 0 = bounce */ \
break; \
} \
_delay_us( 98 ); /* * 256 = 25ms */ \
if( --i == 0 ){ /* ... until key >25ms pressed */ \
flag = 1; /* set press flag */ \
i = 1; /* 1 = key press debounced */ \
break; \
} \
} \
} \
i; /* return value of Macro */ \
})

/*
Testapplication
*/
int main(void)
{
DDRB &= ~(1<<PB0);
PORTB |= 1<<PB0;
DDRB |= 1<<PB2;
DDRB &= ~(1<<PB1);
PORTB |= 1<<PB1;
DDRB |= 1<<PB3;
for(;;){
if( debounce( PINB, PB1 ) )
PORTB ^= 1<<PB2;
if( debounce( PINB, PB0 ) )
PORTB ^= 1<<PB3;
}
}

</syntaxhighlight>

Wenn das Makro für die gleiche Taste (Pin) an mehreren Stellen aufgerufen werden soll, muss eine Funktion angelegt werden, damit beide Aufrufe an die gleiche Zustandsvariable ''flag'' auswerten [http://www.mikrocontroller.net/topic/195914#1918727]:

<syntaxhighlight lang="c">
// Hilfsfunktion
uint8_t debounce_C1( void )
{
return debounce(PINC, PC1);
}

// Beispielanwendung
int main(void)
{
DDRB |= 1<<PB2;
DDRB |= 1<<PB3;
DDRC &= ~(1<<PC1);
PORTC |= 1<<PC1; // Pullup für Taster

for(;;){
if( debounce_C1() ) // nicht: debounce(PINC, PC1)
PORTB ^= 1<<PB2;
if( debounce_C1() ) // nicht: debounce(PINC, PC1)
PORTB ^= 1<<PB3;
}
}
</syntaxhighlight>

=== Timer-Verfahren (nach Peter Dannegger) ===

==== Grundroutine (AVR Assembler) ====

Siehe dazu: [http://www.mikrocontroller.net/forum/read-4-20435.html#new Forum]

Vorteile
* besonders kurzer Code
* schnell

Außerdem können 8 Tasten (aktiv low) gleichzeitig bearbeitet werden, es dürfen also
alle exakt zur selben Zeit gedrückt werden. Andere Routinen können z. B. nur eine Taste verarbeiten, d.h. die zuerst oder zuletzt gedrückte gewinnt, oder es kommt Unsinn heraus.

Die eigentliche Einlese- und Entprellroutine ist nur 8 Instruktionen
kurz. Der entprellte Tastenzustand ist im Register ''key_state''. Mit nur 2 weiteren Instruktionen wird dann der Wechsel von ''Taste offen'' zu
''Taste gedrückt'' erkannt und im Register ''key_press'' abgelegt. Im Beispielcode werden dann damit 8 LEDs ein- und ausgeschaltet. Jede Taste entspricht einem Bit in den Registern, d.h. die Verarbeitung erfolgt bitweise mit logischen Operationen. Zum Verständnis empfiehlt es sich daher, die Logikgleichungen mit Gattern für ein Bit = eine Taste aufzumalen. Die Register kann man sich als Flipflops denken, die mit der Entprellzeit als Takt arbeiten. D.h. man kann das auch so z. B. in einem GAL22V10 realisieren.

Als Kommentar sind neben den einzelnen Instruktionen alle 8 möglichen
Kombinationen der 3 Signale dargestellt.

Beispielcode für AVR (Assembler):

<syntaxhighlight lang="avrasm">
.nolist
.include "c:\avr\inc\1200def.inc"
.list
.def save_sreg = r0
.def iwr0 = r1
.def iwr1 = r2

.def key_old = r3
.def key_state = r4
.def key_press = r5

.def leds = r16
.def wr0 = r17

.equ key_port = pind
.equ led_port = portb

rjmp init
.org OVF0addr ;timer interrupt 24ms
in save_sreg, SREG
get8key: ;/old state iwr1 iwr0
mov iwr0, key_old ;00110011 10101010 00110011
in key_old, key_port ;11110000
eor iwr0, key_old ; 11000011
com key_old ;00001111
mov iwr1, key_state ; 10101010
or key_state, iwr0 ; 11101011
and iwr0, key_old ; 00000011
eor key_state, iwr0 ; 11101000
and iwr1, iwr0 ; 00000010
or key_press, iwr1 ;store key press detect
;
; insert other timer functions here
;
out SREG, save_sreg
reti
;-------------------------------------------------------------------------
init:
ldi wr0, 0xFF
out ddrb, wr0
ldi wr0, 1<<CS02 | 1<<CS00 ;divide by 1024 * 256
out TCCR0, wr0
ldi wr0, 1<<TOIE0 ;enable timer interrupt
out TIMSK, wr0

clr key_old
clr key_state
clr key_press
ldi leds, 0xFF
main: cli
eor leds, key_press ;toggle LEDs
clr key_press ;clear, if key press action done
sei
out led_port, leds
rjmp main
;-------------------------------------------------------------
</syntaxhighlight>

==== Komfortroutine (C für AVR) ====

Siehe dazu: [http://www.mikrocontroller.net/forum/read-4-310276.html Forum]

'''Anmerkung''' Wenn statt active-low (Ruhezustand High) active-high (Ruhezustand Low) verwendet wird muss eine Zeile geändert werden siehe:
[http://www.mikrocontroller.net/forum/read-4-310276.html gesamter Beitrag im Forum],
[http://www.mikrocontroller.net/topic/48465#606555 Stelle 1 im Beitrag], ([http://www.mikrocontroller.net/topic/48465#2306398 Stelle 2 im Beitrag] muss *nicht* geändert werden, da hier die Polarität gar keinen Einfluß hat).

'''Anmerkung 2''' Zur Initialisierung siehe [http://www.mikrocontroller.net/topic/48465#3572793 Forum]

Funktionsprinzip wie oben plus zusätzliche Features:
* Kann Tasten sparen durch unterschiedliche Aktionen bei kurzem oder langem Drücken
* Wiederholfunktion, z. B. für die Eingabe von Werten

Das Programm ist für avr-gcc/avr-libc geschrieben, kann aber mit ein paar Anpassungen auch mit anderen Compilern und Mikrocontrollern verwendet werden. Eine Portierung für den AT91SAM7 findet man [http://www.google.com/codesearch?q=show:ac2viP-2E2Y:pzkOO5QRsoc:RPICuprYy-A&sa=N&cd=1&ct=rc&cs_p=svn://mikrocontroller.net/mp3dec/trunk&cs_f=keys.c#a0 hier] (aus dem Projekt [[ARM MP3/AAC Player]]).
<syntaxhighlight lang="c">
/************************************************************************/
/* */
/* Debouncing 8 Keys */
/* Sampling 4 Times */
/* With Repeat Function */
/* */
/* Author: Peter Dannegger */
/* danni@specs.de */
/* */
/************************************************************************/

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

#ifndef F_CPU
#define F_CPU 1000000 // processor clock frequency
#warning kein F_CPU definiert
#endif

#define KEY_DDR DDRB
#define KEY_PORT PORTB
#define KEY_PIN PINB
#define KEY0 0
#define KEY1 1
#define KEY2 2
#define ALL_KEYS (1<<KEY0 | 1<<KEY1 | 1<<KEY2)

#define REPEAT_MASK (1<<KEY1 | 1<<KEY2) // repeat: key1, key2
#define REPEAT_START 50 // after 500ms
#define REPEAT_NEXT 20 // every 200ms

#define LED_DDR DDRA
#define LED_PORT PORTA
#define LED0 0
#define LED1 1
#define LED2 2

volatile uint8_t key_state; // debounced and inverted key state:
// bit = 1: key pressed
volatile uint8_t key_press; // key press detect

volatile uint8_t key_rpt; // key long press and repeat

ISR( TIMER0_OVF_vect ) // every 10ms
{
static uint8_t ct0 = 0xFF, ct1 = 0xFF, rpt;
uint8_t i;

TCNT0 = (uint8_t)(int16_t)-(F_CPU / 1024 * 10e-3 + 0.5); // preload for 10ms

i = key_state ^ ~KEY_PIN; // key changed ?
ct0 = ~( ct0 & i ); // reset or count ct0
ct1 = ct0 ^ (ct1 & i); // reset or count ct1
i &= ct0 & ct1; // count until roll over ?
key_state ^= i; // then toggle debounced state
key_press |= key_state & i; // 0->1: key press detect

if( (key_state & REPEAT_MASK) == 0 ) // check repeat function
rpt = REPEAT_START; // start delay
if( --rpt == 0 ){
rpt = REPEAT_NEXT; // repeat delay
key_rpt |= key_state & REPEAT_MASK;
}
}

///////////////////////////////////////////////////////////////////
//
// check if a key has been pressed. Each pressed key is reported
// only once
//
uint8_t get_key_press( uint8_t key_mask )
{
cli(); // read and clear atomic !
key_mask &= key_press; // read key(s)
key_press ^= key_mask; // clear key(s)
sei();
return key_mask;
}

///////////////////////////////////////////////////////////////////
//
// check if a key has been pressed long enough such that the
// key repeat functionality kicks in. After a small setup delay
// the key is reported being pressed in subsequent calls
// to this function. This simulates the user repeatedly
// pressing and releasing the key.
//
uint8_t get_key_rpt( uint8_t key_mask )
{
cli(); // read and clear atomic !
key_mask &= key_rpt; // read key(s)
key_rpt ^= key_mask; // clear key(s)
sei();
return key_mask;
}

///////////////////////////////////////////////////////////////////
//
// check if a key is pressed right now
//
uint8_t get_key_state( uint8_t key_mask )

{
key_mask &= key_state;
return key_mask;
}

///////////////////////////////////////////////////////////////////
//
uint8_t get_key_short( uint8_t key_mask )
{
cli(); // read key state and key press atomic !
return get_key_press( ~key_state & key_mask );
}

///////////////////////////////////////////////////////////////////
//
uint8_t get_key_long( uint8_t key_mask )
{
return get_key_press( get_key_rpt( key_mask ));
}

int main( void )
{
LED_PORT = 0xFF;
LED_DDR = 0xFF;

// Configure debouncing routines
KEY_DDR &= ~ALL_KEYS; // configure key port for input
KEY_PORT |= ALL_KEYS; // and turn on pull up resistors

TCCR0 = (1<<CS02)|(1<<CS00); // divide by 1024
TCNT0 = (uint8_t)(int16_t)-(F_CPU / 1024 * 10e-3 + 0.5); // preload for 10ms
TIMSK |= 1<<TOIE0; // enable timer interrupt

sei();

while(1){
if( get_key_short( 1<<KEY1 ))
LED_PORT ^= 1<<LED1;

if( get_key_long( 1<<KEY1 ))
LED_PORT ^= 1<<LED2;

// single press and repeat

if( get_key_press( 1<<KEY2 ) || get_key_rpt( 1<<KEY2 )){
uint8_t i = LED_PORT;

i = (i & 0x07) | ((i << 1) & 0xF0);
if( i < 0xF0 )
i |= 0x08;
LED_PORT = i;
}
}
}
</syntaxhighlight>

Das single-press-und-repeat-Beispiel geht nicht in jeder Beschaltung; folgendes Beispiel sollte universeller sein (einzelne LED an/aus):
<syntaxhighlight lang="c">
// single press and repeat
if( get_key_press( 1<<KEY2 ) || get_key_rpt( 1<<KEY2 ))
LED_PORT ^=0x08;
</syntaxhighlight>

Neuere Variante, die einer Taste folgende Funktionen erlaubt:
https://www.mikrocontroller.net/topic/48465?goto=1753367#1753367
<syntaxhighlight lang="c">
- get_key_press()
- get_key_rpt()
- get_key_press() mit get_key_rpt()
- get_key_short() mit get_key_long()
- get_key_short() mit get_key_long_r() und get_key_rpt_l()
</syntaxhighlight>
Erweiterung für die Erkennung von zwei gleichzeitig gedrückten Tasten:
https://www.mikrocontroller.net/topic/48465?goto=1753367#1753367
<syntaxhighlight lang="c">
- get_key_common()
</syntaxhighlight>

===== Funktionsweise =====
Der Code basiert auf 8 parallelen vertikalen Zählern, die über die Variablen ct0 und ct1 aufgebaut werden

[[Bild:VertCount.png|framed|center|'''8 vertikale Zähler in 2 8-Bit Variablen''']]

wobei jeweils ein Bit in ct0 mit dem gleichwertigen Bit in ct1 zusammengenommen einen 2-Bit-Zähler bildet.
Der Code der sich um die 8 Zähler kümmert, ist so geschrieben, daß er alle 8 Zähler gemeinsam parallel behandelt.

<syntaxhighlight lang="c">
i = key_state ^ ~KEY_PIN; // key changed ?
</syntaxhighlight>
i enthält an dieser Stelle für jede Taste, die sich im Vergleich mit dem vorhergehenden entprellten Zustand (keystate) verändert hat, ein 1 Bit.

<syntaxhighlight lang="c">
ct0 = ~( ct0 & i ); // reset or count ct0
ct1 = ct0 ^ (ct1 & i); // reset or count ct1
</syntaxhighlight>

Diese beiden Anweisungen erniedrigen den 2-Bit Zähler ct0/ct1 für jedes Bit um 1, welches in i gesetzt ist. Liegt an der entsprechenden Stelle in i ein 0 Bit vor (keine Änderung des Zustands), so wird der Zähler ct0/ct1 für dieses Bit auf 1 gesetzt.
Der Grundzustand des Zählers ist als ct0 == 1 und ct1 == 1 (Wert 3). Der Zähler zählt daher mit jedem ISR Aufruf, bei dem die Taste im Vergleich zu keystate als verändert erkannt wurde

ct1 ct0
1 1 // 3
1 0 // 2
0 1 // 1
0 0 // 0
1 1 // 3

<syntaxhighlight lang="c">
i &= ct0 & ct1; // count until roll over ?
</syntaxhighlight>
in i bleibt nur dort ein 1-Bit erhalten, wo sowohl in ct1 als auch in ct0 ein 1 Bit vorgefunden wird, der betreffende Zähler also bis 3 zählen konnte. Durch die zusätzliche Verundung mit i wird der Fall abgefangen, dass ein konstanter Zählerwert von 3 in i ein 1 Bit hinterlässt. Im Endergebnis bedeutet dass, dass nur ein Zählerwechsel von 0 auf 3 zu einem 1 Bit an der betreffenden Stelle in i führt, aber auch nur dann, wenn in i an dieser Bitposition ebenfalls ein 1 Bit war (welches wiederrum deswegen auf 1 war, weil an diesem Eingabeport eine Veränderung zum letzten bekannten entprellten Zustand festgestellt wurde). Alles zusammengenommen heißt das, dass ein Tastendruck dann erkannt wird, wenn die Taste 4 mal hintereinander in einem anderen Zustand vorgefunden wurde als dem zuletzt bekannten entprellten Tastenzustand.

An dieser Stelle ist i daher ein Vektor von 8 Bits, von denen jedes einzelne der Bits darüber Auskunft gibt, ob die entsprechende Taste mehrmals hintereinander im selben Zustand angetroffen wurde, der nicht mit dem zuletzt bekannten Tastenzustand übereinstimmt. Ist das der Fall, dann wird eine entsprechende Veränderung des Tastenzustands in key_state registriert
<syntaxhighlight lang="c">
key_state ^= i; // then toggle debounced state
</syntaxhighlight>
und wenn sich in key_state das entsprechende Bit von 0 auf 1 verändert hat, wird dieses Ereignis als 'Taste wurde niedergedrückt' gewertet.
<syntaxhighlight lang="c">
key_press |= key_state & i; // 0->1: key press detect
</syntaxhighlight>

Damit ist der Tasteneingang entprellt. Und zwar sowohl beim Drücken einer Taste als auch beim Loslassen (damit Tastenpreller beim Loslassen nicht mit dem Niederdrücken einer Taste verwechselt werden). Der weitere Code beschäftigt sich dann nur noch damit, diesen entprellten Tastenzustand weiter zu verarbeiten.

Der Codeteil sieht durch die Verwendung der vielen bitweisen Operationen relativ komplex aus. Behält man aber im Hinterkopf, dass einige der bitweisen wie ein 'paralles If' gleichzeitig auf allen 8 Bits eingesetzt werden, dann vereinfacht sich vieles. Ein
<syntaxhighlight lang="c">
key_press |= key_state & i;
</syntaxhighlight>
ist nichts anderes als ein
<syntaxhighlight lang="c">
// teste ob Bit 0 sowohl in key_state als auch in i gesetzt ist
// und setze Bit 0 in key_press, wenn das der Fall ist
if( ( key_state & ( 1 << 0 ) ) &&
( i & ( 1 << 0 ) )
key_press |= ( 1 << 0 );

// Bit 1
if( ( key_state & ( 1 << 1 ) ) &&
( i & ( 1 << 1 ) )
key_press |= ( 1 << 1 );

// Bit 2
if( ( key_state & ( 1 << 2 ) ) &&
( i & ( 1 << 2 ) )
key_press |= ( 1 << 2 );

...
</syntaxhighlight>
nur als wesentlich kompaktere Operation ausgeführt und für alle 8 Bits gleichzeitig.
Die Kürze und Effizienz dieser paar Codezeilen ergibt sich aus dem Umstand, dass jedes Bit in den Variablen für eine Taste steht und alle 8 (maximal möglichen) Tasten gleichzeitig die Operationen durchlaufen.

Funktionsweisen der verschienden Modi anhand von Zeitstrahlen erklärt:
https://www.mikrocontroller.net/topic/48465?goto=1753367#1844458

"Walkthrough" der verschiedenen Zuständer der Einzelnen Variablen anhand eines Tastendrucks (avrfreaks.net)
http://www.avrfreaks.net/comment/726676#comment-726676

===== Reduziert auf lediglich 1 Taste =====
Diskussionen im Forum zeigen immer wieder, dass viele eine Abneigung gegen diesen Code haben, weil er ihnen sehr kompliziert vorkommt.

Der Code ist nicht leicht zu analysieren und er zieht alle Register dessen, was möglich ist, um sowohl Laufzeit als auch Speicherverbrauch einzusparen. Oft hört man auch das Argument: Ich benötige ja nur eine Entprellung für 1 Taste, gibt es da nichts Einfacheres?

Hier ist die 'Langform' des Codes, so wie man das für lediglich 1 Taste schreiben würde, wenn man exakt dasselbe Entprellverfahren einsetzen würde. Man sieht: Da ist keine Hexerei dabei: In key_state wird der letzte bekannte entprellte Zustand der Taste gehalten. Der Pin-Eingang wird mit diesem Zustand verglichen und wenn sich die beiden unterscheiden, dann wird ein Zähler heruntergezählt. Produziert dieses herunterzählen einen Unterlauf des Zählers, dann gilt die Taste als entprellt und wenn dann auch noch die Taste gerade gedrückt ist, dann wird dieses in key_press entsprechend vermerkt.

<syntaxhighlight lang="c">
uint8_t key_state;
uint8_t key_counter;
volatile uint8_t key_press;

ISR( ... Overflow ... )
{
uint8_t input = KEY_PIN & ( 1 << KEY0 );

if( input != key_state ) {
key_counter--;
if( key_counter == 0xFF ) {
key_counter = 3;
key_state = input;
if( input )
key_press = TRUE;
}
}
else
key_counter = 3;

}

uint8_t get_key_press()
{
uint8_t result;

cli();
result = key_press;
key_press = FALSE;
sei();

return result;
}
</syntaxhighlight>

Der vollständige Entprellcode, wie weiter oben gelistet, besticht jetzt aber darin, dass er compiliert kleiner ist als diese anschaulichere Variante für lediglich 1 Taste. Und das bei gleichzeitig erhöhter Funktionalität. Denn zb. ein Autorepeat ist in diesem Code noch gar nicht eingebaut. Und spätestens wenn man dann eine 2.te Taste entprellen möchte, dann ist auch der SRAM-Speicherverbrauch dieser Langform höher als der des Originals für 8 Tasten. Daraus folgt: Selbst für lediglich 1 Taste ist die Originalroutine die bessere Wahl.

Und wegen der Komplexität mal eine Frage: Sind Sie selbst in der Lage eine entsprechend effiziente sqrt() Funktion zu schreiben, wie die, die sie in der Standard-C-Bibliothek vorfinden? Nein? Dann dürften Sie eigentlich Ihrer Argumentation nach die Bibliotheksfunktion sqrt() nicht verwenden, sondern müssten sich statt dessen selbst eine Wurzel-Funktion schreiben.

=== Selbstsättigendes Filter (nach Jürgen Schuhmacher) ===
Durch die Nutzung der diskreten Signalanalyse in Software kann die Funktionalität einer einfachen Entprellung mit einem Widerstand, einem Kondensator und einem Schmitttrigger wie in Hardware nachgebildet werden, indem ein abstraktes IIR-Filter benutzt wird, der eine Kondensatorladekurve emuliert. Mit der Vorschrift Y(t) = k Y(t-1) + Input wird ein einfaches Filter erzeugt, dass dem Eingangswert träge folgt. Bei Überschreiten eines bestimmten Wertes erfolgt mit einer einfachen Abfrage das Schalten des Ausgangssignals.

Für Assembler und VHDL bei FPGAs eignet sich aufgrund der leicht zu implementierenden binären Operationen folgende Darstellung mit einer Auflösung des Filterwertspeichers von nur 8 bit: Wert_Neu = Wert_Alt - Wert_Alt/16 + 16*(Taste = True). Der Filterwert bildet dann den gedämpften Verlauf des Eingangs (flankenverschliffen) ab und kann Prellen bis nahe an den Grenzbereich zum schnellen Tasten unterdrücken. Der Ausgangswert ist dann einfach das höchstwertige Bit des Filterwertes.

[[Datei:Entprellung mit IIR-Filter.gif]]

Dazu muss das Signal des Tasters idealerweise um den Faktor 10-20 schneller abgetastet werden, als die höchste gewünschte Tippgeschwindigkeit vorgibt. Noch schneller abzutasten ist möglich, führt aber zu mehr Bedarf an Bits beim Filter. Die Schmittriggerfunktion kann dadurch gebildet werden, dass eine 1 am Ausgang bei z.B. Überschreiten einer 55% Grenze und eine 0 bei Unterschreitung der 45%-Grenze ausgeben wird. Im Zwischenbereich wird der alte Wert gehalten. Die realen Grenzen dieser [[Hysterese]] müssen an die Applikation angepasst werden, da zu enge Grenzen sonst zu empfindlich gegenüber Störungen wären.

=== Einfaches Mittelwertfilter (nach Lothar Miller) ===
Für digitale Schaltungen oder PLDs empfiehlt sich ein FIR-Filter mit aneinandergereihten FlipFlops. Man schiebt das Eingangssignal in eine FlipFlop-Kette und schaltet oberhalb der Mitte um:

SignalInput -> FF1 -> FF2 -> FF3 -> FF4 -> FF5 -> FF6 -> FF7 -> FF8

Wenn alle FFs = 1 (Summe der FFs=8) dann SignalOutput = 1 
Wenn alle FFs = 0 (Summe der FFs=0) dann SignalOutput = 0

Dieses Verfahren kann sehr einfach in Logik abgebildet werden, weil für die Berechnung des Ausgangs nur ein NOR bz. ein AND Gatter nötig ist.

Das reale Signal muss dazu aber genügend langsam abgetastet werden, sodaß die Filterperiode die Prelldauer übersteigt, um zu verhindern, daß nicht inmitten einer passiven Phase eines Prellvorgangs ein 8fach 1 gesehen wird. Damit wird die Interetation vergleichsweise langsam.

== Gegenüberstellung der Verfahren ==
* HW - "entprellte Schalter": Sehr teuer, grosse Bauform, verschleissbelastet, geringe Haltbarkeit
* HW - "Umschalter" : benötigt aufwändigeren Schalter, benötigt Elektronik
* HW - "Umschalter ohne FF" : benötigt aufwändigeren Schalter und kleinen Kondensator
* HW - "Kondensatorentprellung" : benötigt etwas mehr Platz, kommt mit schlechten Schaltern zurecht

* SW - Flankenverfahren:
* SW - Warteschleife: Durch die Warteschleifen eine nicht zu vernachlässigende Verzögerung im Code. Speziell wenn mehrere Tasten zu überwachen sind, nicht unproblematisch
* SW - Timer: Universalfunktionalität, die durch geringen Speicherverbrauch, geringen Rechenzeitverbrauch und gute Funktion besticht. Der 'Verbrauch' eines Timers sieht auf den ersten Blick schlimmer aus, als er ist, denn in den meisten Programmen hat man sowieso einen Basistimer für die Zeitsteuerung des Programms im Einsatz, der für die Tastenentprellung mitbenutzt werden kann.
* SW - Filter: sehr geringer Platzbedarf in FPGAs, relativ gute Wirkung
* SW - Filter 2: sehr geringer Platzbedarf, gute Wirkung

== Links zum Thema ==

* [http://www.edn.com/design/analog/4324067/Contact-debouncing-algorithm-emulates-Schmitt-trigger Contact-debouncing algorithm (Artikel)], [http://www.edn.com/Pdf/ViewPdf?contentItemId=4324067 als PDF]
* [[AVR-Tutorial: Tasten]]
* [[AVR-GCC-Tutorial#.28Tasten-.29Entprellung|AVR-GCC-Tutorial Tastenentprellung]]
* [http://www.mikrocontroller.net/forum/read-4-20435.html Beitrag im Forum, AVR Assembler]
* [http://www.ganssle.com/debouncing.pdf A guide to debouncing (engl.), praktische Erläuterungen zum Entprellen in Soft- und Hardware]
* [http://www.pololu.com/docs/0J16/all Understanding Destructive LC Voltage Spikes]

[[Kategorie:AVR]]
[[Kategorie:Signalverarbeitung]]

WordClock mit WS2812

2016-01-24T21:35:13Z

Maybee: Typo

Dieser Artikel ist der Nachfolger der beiden Projekte [[Word_Clock]] und [[WordClock24h]]. Diese Projekte werden hier zusammengefasst und mit ein- und derselben Hard- und Software realisiert. Es ist damit der Bau einer 12-Stunden WordClock und einer minutengenauen 24-Stunden WordClock möglich.

Um die beiden Varianten zu unterscheiden, wird die 12-Stunden-Variante im folgenden '''WordClock12h''' und die 24-Stunden-Variante '''WordClock24h''' genannt.

Zugehöriger Thread im Forum: https://www.mikrocontroller.net/topic/385955

'''WordClock12h:'''

[[Datei:wordclock-frontplatte-v2.png| |WordClock12h]]

'''WordClock24h:'''

[[Datei:WordClock24h-Frontplatte-800x800.png|400px|WordClock24h]]

= Software =

Die Software ist sowohl auf dem STM32F401RE oder STM32F411RE [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]] als auch auf einem [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|STM32F103-Mini-Development-Board]] lauffähig.

=== Features ===

Die Software wird ständig weiterentwickelt. Folgende Punkte wurden bereits umgesetzt:

* Lauffähig auf STM32F401 [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo]], STM32F411 [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo]] und [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|STM32F103-Mini-Development-Board]]
* Anbindung IR-Fernbedienung mittels [[IRMP]]
* [[WordClock_mit_WS2812#MCURSES-Monitor|Monitoring]]/Benutzeroberfläche mittels [[MCURSES]]
* Einstellen des Anzeigemodus ("Sprache") und der Farbe per IR-Fernbedienung
* Anbindung von LED-Stripes des Typs [[WordClock_mit_WS2812#WS2812|WS2812]] und [[WordClock_mit_WS2812#WS2812|WS2812B]]
* Sanftes Überblenden der Uhrzeiten auf den LEDs
* Wählbare Animationen bei Uhrzeitwechsel
* Automatische Helligkeitsregelung mittels [[WordClock_mit_WS2812#LDR|LDR]] (optional)
* Anbindung einer externen DS3231-[[WordClock_mit_WS2812#RTC_und_EEPROM|RTC]]
* Anbindung eines externen I2C-[[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROM]]
* Optionale Anbindung eines [[WordClock_mit_WS2812#DCF77|DCF77]]-Moduls
* Optionale Anbindung eines [[WordClock_mit_WS2812#ESP8266|ESP8266]]-WLAN-Moduls
* Holen der Uhrzeit per TIME- oder NTP-Protokoll aus dem Internet
* Optionale Temperaturmessung und -Anzeige mit [[WordClock_mit_WS2812#Temperatur-Sensor|DS18xxx-Sensor]]
* Fernsteuerung per [[WordClock_mit_WS2812#Android_App|Android App]]
* Ambilight

=== Geplante Features ===

Die nächsten geplanten Punkte sind:

* Konfiguration der Nachtzeit(en)
* Farbprogramme (Wählen der Farbe, optional automatisches Wechseln)
* Spiele wie TRON und TETRIS

=== Download ===

'''EM::Blocks-Projekt, Version 1.6.3 vom 24.01.2016:''' [http://www.mikrocontroller.net/svnbrowser/wordclock24h/?view=tar Tarball]

'''SVN hier auf mikrocontroller.net:''' svn://mikrocontroller.net/wordclock24h/

'''Repo-Browser''': [http://www.mikrocontroller.net/svnbrowser/wordclock24h/ WordClock24h im SVN]

Hex-Dateien, wenn man - ohne zu compilieren - direkt flashen will:

* '''WC12h''' Version 1.6.3 Nucleo401-Board: [[Datei:Wc12h-nucleo401.hex]]
* '''WC12h''' Version 1.6.3 Nucleo411-Board: [[Datei:Wc12h-nucleo411.hex]]
* '''WC12h''' Version 1.6.3 STM32F103-Board: [[Datei:Wc12h-STM32F103.hex]]

* '''WC24h''' Version 1.6.3 Nucleo401-Board: [[Datei:Wc24h-nucleo401.hex]]
* '''WC24h''' Version 1.6.3 Nucleo411-Board: [[Datei:Wc24h-nucleo411.hex]]
* '''WC24h''' Version 1.6.3 STM32F103-Board: [[Datei:Wc24h-STM32F103.hex]]

* [[WordClock_mit_WS2812#Android_App|Android App]] 1.5: [[Datei:WC24h.apk]]

Wie man diese APK unter Android installiert, kann man hier nachlesen:

http://www.pcwelt.de/ratgeber/Android-Smartphones-Apps-ausserhalb-des-Android-Market-installieren-1929591.html

Am einfachsten erlaubt man die Installation von Apps "aus unbekannten Quellen" und klickt anschließend direkt auf dem Android-Gerät auf den [[WordClock_mit_WS2812#Download|Download]]-Link. Dann kann man das Programm direkt nach dem Download installieren.

=== Software für Windows ===

* EM::Blocks IDE, siehe http://www.emblocks.org/, '''nur notwendig, wenn man selber die Sources übersetzen möchte!'''
* ST-Link/V2 Software zum Flashen, siehe: http://www.st.com/web/catalog/tools/FM146/CL1984/SC724/SS1677/PF251168
* STM32 Virtual COM Port Driver: http://www.st.com/web/en/catalog/tools/PF257938
* PuTTY (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) oder andere Terminal-Emulation

=== WordClock-Quellcode selbst übersetzen ===

Dieser Vorgang ist nur notwendig, wenn man an den Quellen etwas ändern möchte. Im Normalfall braucht man lediglich eine der oben im [[WordClock_mit_WS2812#Download|Download]]-Kapitel angegebenen Hex-Dateien auszuwählen und diese auf den Prozessor flashen.

Wenn man an dem Programm etwas ändern oder erweitern möchte, dann startet man die zuvor installierte EM::Blocks-IDE. Aus dem SVN lädt man sich den Tarball (Link siehe Kapitel [[WordClock_mit_WS2812#Download|Download]]) und entpackt diesen unter C:\EmBlocksProjects.

Nach dem Entpacken findet man dann im Unterverzeichnis wclock24h die Projekt-Datei '''wclock24h.ebp''', um den Quellcode für ein [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]] zu compilieren. In der EM::Blocks-Ide kann man nun mit '''File -> Open''' die Projekt-Datei laden.

Möchte man jedoch den Quellcode für das [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|STM32F103-Mini-Board]] übersetzen, dann lädt man die Projektdatei '''wclock24h-F103.ebp''' aus dem Unterverzeichnis '''wclock24h-F103'''.

Anschließend wählt man in der oberen Zeile in der Mitte das Ziel aus, wofür man den Quellcode übersetzen möchte.

Beim [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo]]-Projekt werden folgende Alternativen angeboten:

WC24h:

* WC24h-Nucleo401-Debug
* WC24h-Nucleo401-Release

* WC24h-Nucleo411-Debug
* WC24h-Nucleo411-Release

WC12h:

* WC12h-Nucleo401-Debug
* WC12h-Nucleo401-Release

* WC12h-Nucleo411-Debug
* WC12h-Nucleo411-Release

In der F103-Projektdatei können folgende Varianten ausgewählt werden:

WC24h:

* WC24h-STM32F103-Debug
* WC24h-STM32F103-Release

WC12h:

* WC12h-STM32F103-Debug
* WC12h-STM32F103-Release

Die Debug-Varianten sind lediglich für die Bugsuche im Programm vonnöten. Es empfiehlt sich daher im Normalfall, die entsprechende Release-Variante auszuwählen.

Nach der Auswahl kann man dann unter '''Build -> Rebuild all target files''' den Übersetzungsvorgang starten. Danach findet man im Unterverzeichnis bin\\Release die dazugehörige Hex-Datei mit dem ST-Link-Programm dann auf dem Ziel geflasht werden kann. Das wars!

= Hardware =

== STM32F103C8T6 Mini-Development Board ==

[[Datei:STM32F103C8T6.png|miniatur|STM32F103C8T6 Mini-Development Board]]
[[Datei:WordClock24h-an-STM32F103-C8T6.png|mini|STM32F103C8T6 an STM32F103 Mini-Development Board]]

Dies ist ein kleines, platzsparendes Board mit ausreichendem 32Bit-Mikrocontroller. Der STM32F103C8T6 hat 64 KB Flash und 20KB RAM. Bei ebay ist er für kleines Geld (unter 4 EUR) zu haben: Einfach dort nach "STM32F103C8T6" suchen. Die Anbieter sind meist in China. Aber es gibt auch Anbieter aus Deutschland, wo das bestellte Board dann auch schon nach 2 Tagen im Briefkasten steckt. Meist sind die deutschen Anbieter aber etwas teurer.

Während die [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Boards]] bereits den "Programmer" ST-Link-V2 zum Programmieren des Flashs on-Board haben, ist dies hier nicht der Fall. Hier muss ein separates ST-Link-V2 zum einmaligen Programmieren verwendet werden. Hat man schon ein [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]] zuhause, kann der darauf befindliche ST-Link verwendet werden. Oder man beschafft sich einen eigenen Programmer. Bei eBay erhält man sie bereits im einstelligen Euro-Bereich, wenn man nach "ST-Link V2" sucht.

Der Vorteil dieses Boards gegenüber dem Nucleo ist der geringe Platzbedarf. Es müssen lediglich ein paar Verbindungen zu den weiter unten erläuterten Modulen wie [[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROM und RTC]] sowie [[WordClock_mit_WS2812#ESP8266|ESP8266]] ESP01 gezogen werden.

Rechts ist die Anschluss-Skizze der WordClock an das [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|STM32F103-Mini-Development-Board]] zu sehen.

== STM32F401RE Nucleo und STM32F411RE Nucleo ==

[[Datei:WC24h-Nucleo-Oberseite.jpg|miniatur|Nucleo: Zusätzliche Drahtbrücken R35 + R37 + 8MHz Quarz]]
[[Datei:WC24h-Nucleo-Unterseite.jpg|miniatur|Nucleo: Zu entfernende Lötbrücken + anzulötende 22pf Kondensatoren]]
[[Datei:WC24h-Nucleo-Shield.jpg|miniatur|Prototyp-Shield für das Nucleo-Board mit TSOP, ESP8266 und 3,3V Spannungsregler, später noch Anschluss für DCF77/EEPROM/RTC]]

Es kann sowohl das 401er als auch das 411er [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]] verwendet werden. Beide werden identisch genutzt.

Damit das Board später für den Einbau nur noch (incl. Shield) 2cm hoch ist, sollte man die überstehenden Enden der Steckerleisten auf der '''Unterseite''' mit einer Kneifzange kürzen. Die beiden Jumper auf der Unterseite (beim ST-Link-Device-Teil) können dabei auf die Oberseite gesteckt werden.

Es gibt zwei verschiedene Revisionen von den Nucleo-Boards:

* "MB1136 C01": Der STM32F4x1 läuft nur mit dem ungenauen internen Oszillator
* "MB1136 C02": Der STM32F4x1 erhält seinen 8MHz Takt vom ST-Link-Devices

Damit auch das Board mit der Revision "MB1136 C01" zuverlässig im HSE-Modus mit 84MHz läuft, sind folgende Hardware-Änderungen notwendig:

* Lötbrücken SB54 und SB55 entfernen (mit Lötkolben erhitzen und wegschnippen)
* Lötbrücken SB16 und SB50 entfernen (dito)
* R35 und R37 jeweils mit einem Stück Draht oder 0R-Widerstand bestücken
* Quarz X3 (8 MHz) einlöten
* C33 und C34 mit jeweils 22pF bestücken.

C33 und C34 können auch normale THT-Bauteile sein, wenn man die Drähte vorher kürzt. Ich habe sie auf der Unterseite direkt an den Quarz-Anschlüssen angebracht, siehe Foto rechts. Es geht aber auch auf der Oberseite direkt an den dafür vorgesehenen Lötstellen - dann aber vorzugsweise mit 0603 SMD-Kondensatoren.

'''Man sollte auf jeden Fall erst die beiden Drahtbrücken R35 & R37 einlöten, bevor man den Quarz bestückt. Dann hat man wesentlich mehr Platz für den Lötkolben ;-)'''

Es emfiehlt sich jedoch, diese Änderungen auch mit dem Board der Revision "MB1136 C02" durchzuführen, da wir später für die endgültige Uhr den ST-Link-Teil der Platine absägen werden. Dafür ist extra eine Bruchstelle vorgesehen. Nur so ist das Board dann schmal genug, damit es hinter den 7,5cm schmalen Rand der Frontplatte passt.

Nicht wundern: Je nach Revision des Boards sind einige der oben genannten Lötbrücken erst gar nicht bestückt. Dann braucht da auch nichts entfernt zu werden. Das hier beschriebene stellt also den gewünschten Endzustand dar.

Diese Arbeit ist in ca. 10 Minuten erledigt. Besondere SMD-Lötkenntnisse benötigt man dafür nicht.

== Anschluss TSOP31238 ==

Anschlüsse am [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]]:

TSOP-Pin1 an GND, TSOP-Pin2 an 3,3 oder 5V, TSOP-Pin3 an PC10

Anschlüsse am [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|STM32F103-Mini-Development-Board]]:

TSOP-Pin1 an GND, TSOP-Pin2 an 3,3V oder 5V, TSOP-Pin3 an PB3

== Anschluss WS2812 ==

Bei der WordClock24h wird eine 16x18-Matrix verwendet, bei der WordClock12h eine 10x11-Matrix.

Die [[WordClock_mit_WS2812#WS2812|WS2812]]-LEDs werden dabei folgendermaßen verdrahtet:

==== Anschluss WS2812-Streifen für WordClock12h ====

'''NEU''':

Hier wird eine Spezialanferigung von WS2812-Stripes eingesetzt - nämlich mit einem Rastermaß von 28,1mm. Damit ist die WordClock12h von den Maßen her kompatibel zum bisherigen [[Word_Clock]]-Projekt. Das hat den Vorteil, dass bisherige Frontplatten und Zwischenböden weiterverwendet werden können.

Auch bei der Wordclock12h steht jeder zweite Streifen "auf dem Kopf":

M4 +-------+ M1
O---------+ µC --------| R220 |--------O
| | +-------+ |
| | |
| 1 2 3 4 ... 11 |
| O--O--O--O--O--O--O--O--O--O--O--+ |
| | |
| 22 12 | |
| O--O--O--O--O--O--O--O--O--O--O--+ |
| | |
| | |
| O--O--O--O--O--O--O--O--O--O--O-- |
| 23 24 .... |
| |
| |
O----------------------------------------------------O
M3 M2

Dabei sind M1-M4 die 4 Minutenpunkte in den Ecken. Es wird keine Status-LED wie in der WordClock24 verwendet. Tatsächlich werden hier dafür die Minutenpunkte zur zusätzlichen Statusausgabe mitbenutzt.

Weitere 100 LEDs hinter der Buchstabenkette werden als Ambilight unterstützt. Diese müssen einfach hinter der LED für den letzten Buchstaben in der Kette angeschlossen werden. Die Anzahl ist variabel, maximal 100 Ambilight-LEDs sind möglich.

==== Anschluss WS2812-Streifen für WordClock24h ====

Verwendet werden Standard-WS2812-Stripes mit '''60 LEDs pro Meter'''. Dabei steht jeder zweite Streifen "auf dem Kopf":

+-------------------------------------------------------+
| |
1 2 3 4 ... 18 |
O--O--O--O--O--O--O--O--O--O--O--O--O--O--O--O--+ |
| |
36 20 19 | |
O--O--O--O--O--O--O--O--O--O--O--O--O--O--O--O--+ |
| |
| |
O--O--O--O--O--O--O--O--O--O--O--O--O--O--O--O-- |
37 38 .... |
|
|
+-------+ Status-LED |
µC -------| R220 |------------------O-------------------------------+
+-------+

Auch hier können bis zu 100 Ambilight LEDs hinter der LED für den letzten Buchstaben in der Kette angeschlossen werden.

Anschlüsse am [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]]:

* Stripe +5V an externe Stromversorgung +5V
* Stripe DI über einen Serienwiderstand von 220 Ohm an PC6
* Stripe GND an externe Stromversorgung GND und(!) an GND des Boards

Anschlüsse am [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|STM32F103-Mini-Development-Board]]:

* Stripe +5V an externe Stromversorgung +5V
* Stripe DI über einen Serienwiderstand von 220 Ohm an PA8
* Stripe GND an externe Stromversorgung GND und(!) an GND des Boards

== Anschluss Temperatur-Sensor ==

Optional: [[WordClock_mit_WS2812#Temperatur-Sensor|DS18xxx]] als Temperatur-Sensor

Es werden unterstützt:

* DS1820
* DS18S20
* DS1822
* DS18B20

Anschlüsse am [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]]:

* DS18xx-GND (Pin 1) an GND
* DS18xx-DQ (Pin 2) an PD2 und über Pullup 4,7k an DS18xx-VDD
* DS18xx-VDD (Pin 3) an Board-interne oder externe 3,3V

Anschlüsse am STM32F103 [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|STM32F103-Mini-Development-Board]]:

* DS18xx-GND (Pin 1) an GND
* DS18xx-DQ (Pin 2) an PB5 und über Pullup 4,7k an DS18xx-VDD
* DS18xx-VDD (Pin 3) an Board-interne oder externe 3,3V

'''Ist kein DS18xx Temperatur-Sensor angeschlossen, wird die Temperatur über die RTC (DS3231) ermittelt.'''

== Anschluss LDR ==

Optional: [[WordClock_mit_WS2812#LDR|LDR]] zur Messung der Umgebungshelligkeit

Schaltung:

AGND -----+
|
R = 1K
|
µC ------+
|
LDR (Reichelt: "LDR 07")
|
3,3V -----+

Anschluss am [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]]: PC4
Anschluss am STM32F103 Board: PA5

'''Wird kein [[WordClock_mit_WS2812#LDR|LDR]] benutzt, muss der µC-Eingang per 10k-Pullup auf 3,3V gelegt werden!'''

== Anschluss DCF77 ==

Optional: [[WordClock_mit_WS2812#DCF77|DCF77]] Modul

Anschlüsse am [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]]:

* DCF77 GND an GND
* DCF77 V+ an 3,3V
* DCF77 Out an PC11

Anschlüsse am STM32F103 [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|STM32F103-Mini-Development-Board]]:

* DCF77 GND an GND
* DCF77 V+ an 3,3V
* DCF77 Out an PB4

Getestet wurde die Software mit dem Reichelt-[[WordClock_mit_WS2812#DCF77|DCF77]]-Modul, das aber lediglich ein befriedigendes Empfangsverhalten hat.

Wird ein [[WordClock_mit_WS2812#DCF77|DCF77]]-Modul benutzt, welches einen Open-Collector-Ausgang verwendet, muss an PC11 noch ein 100k Pullup (zu 3,3V) angeschlossen werden.

'''Wird KEIN DCF-Modul verwendet, sollte der µC-Eingang per 100k Pullup auf 3,3V gelegt werden!'''

== Anschluss ESP8266 ==

Optional: [[WordClock_mit_WS2812#ESP8266|ESP8266]] ESP-01: WLAN Modul

[[Datei:WC24h-ESP8266-ESP-01.png|miniatur|Anschlussbelegung ESP8266 ESP-01 - Bauteilseite!]]

Anschlüsse [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]]:

* ESP8266 GND an GND
* ESP8266 VCC an '''externe''' 3,3V (Vorsicht: Modul zieht bis zu 200mA!)
* ESP8266 CH_PD an PA6
* ESP8266 RST an PA7
* ESP8266 TXD an USART6 RX (PA12)
* ESP8266 RXD an USART6 TX (PA11)

Anschlüsse [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|STM32F103-Mini-Development-Board]]:

* ESP8266 GND an GND
* ESP8266 VCC an '''externe''' 3,3V (Vorsicht: Modul zieht bis zu 200mA!)
* ESP8266 CH_PD an PA1
* ESP8266 RST an PA0
* ESP8266 TXD an USART2 RX (PA3)
* ESP8266 RXD an USART2 TX (PA2)

'''Wird KEIN [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Modul verwendet, ist nichts weiter zu beachten, da die Erkennung automatisch erfolgt.'''

== Anschluss RTC und EEPROM ==

I2C-Modul mit DS3231 als RTC und EEPROM

[[Datei:WC24h-DS3231-EEPROM.png|miniatur|DS3231 RTC + EEPROM]]

Dieses Modul (siehe auch Foto rechts) findet man bei eBay oder Amazon ab ca. 2 EUR, wenn man als Suchbegriff "DS3231 EEPROM" eingibt. Es wird als Echtzeituhrt und für die Speicherung der Konfigurationsparameter verwendet. Ist kein DS18xx als Temperatursensor angeschlossen, wird die RTC auch zur Temperaturmessung genutzt.

Anschlüsse [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]]:

* I2C GND an GND
* I2C VCC an Board-interne oder externe 3,3V
* I2C SCL an PA8
* I2C SDA an PC9

Anschlüsse [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|STM32F103-Mini-Development-Board]]:

* I2C GND an GND
* I2C VCC an Board-interne oder externe 3,3V
* I2C SCL an PB6
* I2C SDA an PB7

'''NEU: AB Version 1.0 werden auch [[WordClock_mit_WS2812#RTC_und_EEPROM|RTC/EEPROM]]-Module mit DS1307 erkannt.'''

Da die Module aus China teilweise auch ohne bestückte Batterien gesendet werden, sollte man sich
genau überlegen, ob man die Batterie CR2032 oder den Akku LiR2032 einbaut.

Sind sowohl die Diode 1N4148 als auch der Widerstand neben dem [[WordClock_mit_WS2812#RTC_und_EEPROM|RTC]]-IC bestückt, dann kann man auch den Akku (relativ teuren) LiR2032 einsetzen. In diesem Fall muss das Modul aber mit +5V statt 3,3V betreiben, damit der Akku überhaupt geladen wird. Sonst ist er aufgrund der Selbstendladung irgendwann leer.

Sinnvollerweise sollte man das Modul eher mit einer CR2032 Batterie betreiben. Dann sollte man aber sicherheitshalber die Diode oder den Widerstand (neben der Diode) auf dem Modul entfernen (falls vorhanden, siehe Bild), damit keine Ladung (und Überhitzung) der Batterie passiert. Das ist zwar eigentlich erst ab einer Betriebsspannung von ca. 3,7V möglich, aber sicher ist sicher. Im Normalfall reicht eine CR2032 Batterie für 5-10 Jahre.

Es ist wenig ratsam, ein [[WordClock_mit_WS2812#DCF77|DCF77]]- und das [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Modul gleichzeitig einzusetzen, da das [[WordClock_mit_WS2812#ESP8266|ESP8266]]-WLAN-Modul den [[WordClock_mit_WS2812#DCF77|DCF77]]-Empfänger stören kann. Im Zweifel sollte man sich für eine der beiden Möglichkeiten entscheiden.

== Anschlusstabelle ==

{| {{Tabelle}}
|+ '''Anschlüsse'''
|- style="background-color:#eeeeee"
! Device || [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]] || [[WordClock_mit_WS2812#STM32F103C8T6_Mini-Development_Board|STM32F103-Mini-Development-Board]]
|-
| [[WordClock_mit_WS2812#TSOP31238|TSOP31238]] ([[IRMP]]) || GPIO: PC10 || GPIO: PB3
|-
| [[WordClock_mit_WS2812#DCF77|DCF77]] || GPIO: PC11 || GPIO: PB4
|-
| [[WordClock_mit_WS2812#Temperatur-Sensor|DS18xxx]] || GPIO: PD2 || GPIO: PB5
|-
| [[WordClock_mit_WS2812#LDR|LDR]] || GPIO: PC4 || GPIO: PA5
|-
| [[MCURSES]] terminal (USB) || USART2: TX=PA2 RX=PA3 || USART1: TX=PA9 RX=PA10
|-
| [[WordClock_mit_WS2812#ESP8266|ESP8266]] || USART6: TX=PA11 RX=PA12 || USART2: TX=PA2 RX=PA3
|-
| [[WordClock_mit_WS2812#ESP8266|ESP8266]] || GPIO: RST=PA7 CH_PD=PA6 || GPIO: RST=PA0 CH_PD=PA1
|-
| [[WordClock_mit_WS2812#ESP8266|ESP8266]] Debug (opt) || USART1: TX=PA9 RX=PA10 || USART3: TX=PB10 RX=PB11
|-
| [[WordClock_mit_WS2812#RTC_und_EEPROM|RTC / EEPROM]] || I2C3: SCL=PA8 SDA=PC9 || I2C1: SCL=PB6 SDA=PB7
|-
| [[WordClock_mit_WS2812#WS2812|WS2812]] || DMA1: PC6 || DMA1: PA8
|}

= Start =

Dieses Kapitel beschreibt den Download der Software auf das verwendete Board und die erstmalige Prüfung und Konfiguration.

Geflasht wird mit dem ST-Link-Programm, siehe oben.

Zur Überprüfung sämtlicher Funktionen und zur Konfiguration dienst der [[MCURSES]]-[[WordClock_mit_WS2812#MCURSES-Monitor|Monitor]]. Dazu benötigt man ein Terminal-Emulationsprogramm (wie zum Beispiel PuTTY) und ein Mini-USB-Kabel für das [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]].

Laut http://www.mikrocontroller.net/topic/356203#3979181 sollte man dabei die "blauen" USB3.0-Buchsen möglichst meiden.

== Ablauf ==

* [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]] und PC mit Mini-USB-Kabel verbinden (zum Flashen, Debuggen und als COM-Schnittstelle)
* Wenn man die EM::Blocks-IDE einsetzt: Nach [[WordClock_mit_WS2812#WordClock-Quellcode_selbst_.C3.BCbersetzen|Anleitung: WordClock-Quellcode selbst übersetzen]] vorgehen
* Die entsprechende Hex-Datei (aus dem Ordner wclock24h\bin\Release oder direkt hier herunterladen) flashen
* PuTTY starten
* PuTTY einstellen: Auswahl "Serial", Serial Line: COM11 (kann abweichen, s.u.), Speed: 115200
* Einen Session-Namen eingeben, z.B. "Nucleo"
* Auf SAVE klicken, dann kann man die Session später wieder auswählen
* Open anklicken
* RESET-Button am [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]] drücken

'''Wichtig für [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]]:''': Die COM-Schnittstelle ist immer aktiv, egal, ob das Programm gerade läuft oder nicht. Wird PuTTY erst nach dem Programmstart gestartet, sieht man im Terminal nur die Änderungen, also im allgemeinen nur die Uhrzeit. Mit der ENTER-Taste sollte man dann einen kompletten Bildschirm-Refresh erzwingen. Alternativ drückt man auf dem Board einfach den Reset-Knopf, um die komplette Ausgabe im [[WordClock_mit_WS2812#MCURSES-Monitor|Monitor]] nachzuvollziehen.

Sollte man Probleme mit dem Finden der richtigen COM-Schnittstelle haben, hilft der Geräte-Manager aus der Systemsteuerung weiter.

== [[MCURSES]]-Monitor ==

[[Datei:Wclock24-in-putty.png|miniatur|WordClock24h in PuTTY]]

Der [[WordClock_mit_WS2812#MCURSES-Monitor|Monitor]] dient zur Überprüfung sämtlicher Funktionen und der Konfiguration des WLAN-Moduls.

Dafür ist es sinnvoll, noch den Zeichensatz auf ISO8858-1 umzustellen. das geht folgendermaßen:

Change Settings -> Window -> Translation -> ISO-8859-1:1998 (Latin-1, West Europe)
Anschließend zurück über "Session" oben links und: "Save".

Dann klappts auch mit den Sonderzeichen.

Möchte man lieber schwarz auf weiß statt weiß auf schwarz, kann man das folgendermaßen umstellen:

Change Settings -> Window -> Colours:

Default Foreground: 2 2 2
Default Bold Foreground: 0 0 0
Default Background: 245 245 245
Default Bold Background: 255 255 255
Cursor Text: 0 0 0
Cursor Color: 255 0 0
(Rest kann man so lassen)

Anschließend zurück über "Session" oben links und: "Save".

Dann sollte das Ergebnis so aussehen wie rechts im Bild.

{| {{Tabelle}}
|+ '''Tasten im [[MCURSES]]-[[WordClock_mit_WS2812#MCURSES-Monitor|Monitor]]'''
|- style="background-color:#eeeeee"
! Taste || Funktion
|-
| d/D || Anzeigemodus +/-
|-
| a/A || Animation +/-
|-
| h/H || Stunden +/-
|-
| m/M || Minuten +/-
|-
| r/R || Helligkeit Rot +/-
|-
| g/G || Helligkeit Grün +/-
|-
| b/B || Helligkeit Blau +/-
|-
| w/W || Grundhelligkeit +/- ('''NEU!''')
|-
| q || Automatische Helligkeitsregelung ein/aus ('''NEU!''')
|-
| n || Zeit von einem Timeserver holen
|-
| t || Temperatur-Anzeige für 5 Sekunden ('''NEU!''')
|-
| T || LED-Testprogramm ('''NEU!''')
|-
| i || IR-Anlernroutine
|-
| c || Konfiguration (WLAN, Timeserver und [[WordClock_mit_WS2812#LDR|LDR]])
|-
| o || Okay, Save. Damit werden die Einstellungen im [[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROM]] gespeichert.
|-
| e || [[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROM]]-Hexdump zur Kontrolle des Inhalts
|-
| p || Power On/Off. Hiermit kann man die Anzeige ein- und ausschalten.
|-
| l || Logout. Die Ausgabe über das Terminal wird eingestellt, bis zur nächsten ENTER-Taste
|-
| ENTER || Login. Der komplette Bildschirm-Inhalt wird dabei neu geschrieben
|}

Die Uhrzeit wird jede Sekunde in Real Time hochgezählt. Desweiteren erscheinen Infos über empfangene Uhrzeiten per [[WordClock_mit_WS2812#RTC_und_EEPROM|RTC]], [[WordClock_mit_WS2812#DCF77|DCF77]] und [[WordClock_mit_WS2812#ESP8266|ESP8266]]. Ebenso lassen sich die Farben der LEDs und der Anzeigemodus einstellen. Außerdem unterstützt der [[MCURSES]]-[[WordClock_mit_WS2812#MCURSES-Monitor|Monitor]] beim Anlernen einer IR-Fernbedienung.

== Konfiguration des WLAN-Moduls ==

=== Access-Point ===

2 Sekunden nach dem Start wird von der STM32-Software getestet, ob ein [[WordClock_mit_WS2812#ESP8266|ESP8266]]-WLAN-Modul angeschlossen ist. Wird das Modul gefunden, erscheint im [[MCURSES]]-[[WordClock_mit_WS2812#MCURSES-Monitor|Monitor]] die Meldung '''"ESP8266 up"'''.

25 Sekunden nach dem Start wird davon ausgegangen, dass das [[WordClock_mit_WS2812#ESP8266|ESP8266]]-WLAN-Modul mittlerweile eine Verbindung zu einem Access-Point ("AP") hat. Wenn dies der Fall ist, wird im [[MCURSES]]-[[WordClock_mit_WS2812#MCURSES-Monitor|Monitor]] die Meldung '''"ESP8266 online"''' ausgegeben.

Sobald die Up-Meldung ausgegeben wurde, kann man die Access-Point-Einstellungen für das (optionale) WLAN-Modul folgendermaßen konfigurieren:

* Taste 'c' (klein!) drücken

Nach Eingabe von "1" für "Configure Network Module ESP8266" erscheint dann folgenes Menü:

1. Configure access to AP
2. Configure time server
3. Configure time zone
0. Exit

* Taste 1 drücken
* SSID eingeben (oder durch leere Eingabe per ENTER abbrechen)
* Key eingeben (oder durch leere Eingabe per ENTER abbrechen)

Es wird jetzt für eine gewisse Zeit versucht, eine Verbindung mit dem AP aufzunehmen. Hat das Modul nach ca. 30 Sekunden immer noch keine stabile Verbindung, sollte man das Modul einmal komplett vom Strom trennen. Die Einstellungen sind aber im [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Modul gespeichert und sollten nach dem Wiedereinschalten der Spannung automatisch funktionieren. '''Eine erneute Konfiguration ist also in der Regel nicht mehr erforderlich.'''

=== Timeserver ===

Den Timeserver konfiguriert man folgendermaßen:

* Taste 'c' (klein!), danach '1' drücken

Es erscheint dann folgendes Menü:

1. Configure access to AP
2. Configure time server
3. Configure time zone
0. Exit

* Taste 2 drücken
* IP-Adress des neuen Timeservers eingeben oder ausgegebene IP-Adresse wiederholen (leere Eingabe bricht ab)

Der Timeserver muss ein RFC 868 konformer Timeserver oder NTP-Server sein. Voreingestellt ist ntp3.ptb.de (192.53.103.103). Dieser kann sowohl über TIME (RFC 868) oder NTP angesprochen werden. Da dieser Server oft ausgelastet ist, kann man auch auf time.nist.gov (216.229.0.179) ausweichen. Als Zeitzone ist standardmäßig GMT+1 gesetzt.

Eine Liste von Timeservern, welche RFC 868 genügen, findet man u.a. hier: http://tf.nist.gov/tf-cgi/servers.cgi

Nach der Eingabe der IP-Adresse des Timeservers wird zunächst geprüft, ob der Timeserver das NTP-Protokoll beherrscht und ob die Firmware des [[WordClock_mit_WS2812#ESP8266|ESP8266]] eine dafür nötige UDP-Verbindung aufnehmen kann. Wenn nicht, wird von NTP auf TIME (TCP) gewechselt.

Die aktuelle Uhrzeit wird einmal pro Stunde vom Timeserver geholt, nämlich immer um xx:10:17 Uhr. Im [[MCURSES]]-[[WordClock_mit_WS2812#MCURSES-Monitor|Monitor]] kann man aber auch jederzeit die Taste 'n' drücken, um ad hoc die Zeit zu holen. Das funktioniert auch mit einer angelernten IR-Fernbedienung.

=== Zeitzone ===

Die Einstellung der Zeitzone geht folgendermaßen:

* Taste 'c' (klein!) gefolgt von '1' drücken

Es erscheint dann wieder das bekannte Menü:

1. Configure access to AP
2. Configure time server
3. Configure time zone
0. Exit

* Taste 3 drücken
* Zeitzone eingeben, z.B. '''+1''' für GMT'''+1''' - also für unsere mitteleuropäische Zeit.

== Konfiguration des LDR (Umgebungslicht-Messer) ==

Die automatische Helligkeitsregelung muss explizit konfiguriert werden.

* Im [[MCURSES]]-[[WordClock_mit_WS2812#MCURSES-Monitor|Monitor]] Taste 'c' (klein!) drücken

Es erscheint dann ein Menü:

1. Configure Network Module ESP8266
2. Configure LDR
0. Exit

* Taste 2 drücken

Dann kann man den [[WordClock_mit_WS2812#LDR|LDR]] ein- oder ausschalten:

Current configuration: LDR connected

1. LDR connected
2. LDR not connected
0. Exit

Mit '1' wird der [[WordClock_mit_WS2812#LDR|LDR]] aktiviert, mit 2 wird er deaktiviert. Die Einstellung wird im [[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROM]] gespeichert.

Geplant ist hier später noch eine Kalibrierung, d.h. Anpassung an die Gegebenheiten der Umgebung.

== IR-Fernbedienung ==

In den ersten 3 Sekunden leuchtet die Status-LED mit der Farbe weiß, um zu signalisieren, dass nun eine IR-Fernbedienung angelernt werden kann. Wird währenddessen irgendein gültiger IR-Code empfangen, wechselt die Status-LED für eine Sekunde auf rot (FB-Knopf loslassen!) und es wird in die Anlernroutine gesprungen. Wird kein IR-Signal empfangen, startet das Programm wie gewohnt.

Die Anlernroutine kann man auch mit dem blauen User-Button auf dem [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]] aktivieren. Desweiteren ist dies auch mit der Taste 'i' möglich, wenn man den [[MCURSES]]-[[WordClock_mit_WS2812#MCURSES-Monitor|Monitor]] nutzt. Dort wird man dann aufgefordert, folgende FB-Tasten zu drücken:

{| {{Tabelle}}
|+ '''Tasten für IR-Fernbedienung'''
|- style="background-color:#eeeeee"
! Taste || Funktion || LED || Buchstabe
|-
| Power || Anzeige ein/aus || LED1 || style="text-align:center"| E
|-
| OK || Speichern der Einstellungen || LED2 || style="text-align:center"| S
|-
| MODE- || Anzeigemodus erniedrigen || LED3 || style="text-align:center"| A
|-
| MODE+ || Anzeigemodus erhöhen || LED4 || style="text-align:center"| I
|-
| ANIM- || Animation erniedrigen || LED5 || style="text-align:center"| S
|-
| ANIM+ || Animation erhöhen || LED6 || style="text-align:center"| T
|-
| HOUR- || Stunde erniedrigen || LED7 || style="text-align:center"| O
|-
| HOUR+ || Stunde erhöhen || LED8 || style="text-align:center"| V
|-
| MIN- || Minute erniedrigen || LED9 || style="text-align:center"| I
|-
| MIN+ || Minute erhöhen || LED10 || style="text-align:center"| E
|-
| RED- || Helligkeit der Farbe Rot erniedrigen || LED11 || style="text-align:center"| R
|-
| RED+ || Helligkeit der Farbe Rot erhöhen || LED12 || style="text-align:center"| T
|-
| GREEN- || Helligkeit der Farbe Grün erniedrigen || LED13 || style="text-align:center"| E
|-
| GREEN+ || Helligkeit der Farbe Grün erhöhen || LED14 || style="text-align:center"| L
|-
| BLUE- || Helligkeit der Farbe Blau erniedrigen || LED15 || style="text-align:center"| E
|-
| BLUE+ || Helligkeit der Farbe Blau erhöhen || LED16 || style="text-align:center"| I
|-
| BRIGHT- || Grundhelligkeit erniedrigen || LED17 || style="text-align:center"| N
|-
| BRIGHT+ || Grundhelligkeit erhöhen || LED18 || style="text-align:center"| S
|-
| AUTO+ || Automatische Helligkeitsregelung ein/aus || LED19 || style="text-align:center"| D (2. Zeile)
|-
| TEMP || Anzeige der Temperatur für 5 Sekunden || LED20 || style="text-align:center"| R (2. Zeile)
|}

Dabei leuchtet die oben angegebene LED hinter dem jeweiligen Buchstaben auf dem Display in der obersten Zeile ('''ES#IST#VIERTELEINS'''), damit der Anlernvorgang auch ohne [[MCURSES]]-[[WordClock_mit_WS2812#MCURSES-Monitor|Monitor]] vorgenommen werden kann. Sind die FB-Tasten angelernt, kann man die Uhrzeit, den Anzeigemodus und auch die Farben mittels IR-Fernbedienung einstellen.

Es sind nur die gebräuchlichsten IR-Protokolle aktiviert, nämlich:

* SIRCS (Sony)
* NEC (Viele Hersteller, sehr verbreitet)
* SAMSUNG
* MATSUSHITA
* KASEIKYO

[[IRMP]] "versteht" jedoch bis zu 40 Protokolle. Braucht man weitere - wie RC5 oder RC6 - kann man sie in irmp/irmp-config.h freischalten. Bei Problemen empfiehlt sich die Lektüre des [[IRMP]]-Artikels.

== Android App ==

[[Datei:Wc24h-Android.png|miniatur|WC24h Android App]]

'''Für die STM32-Software-Version 1.5.0 muss die [[WordClock_mit_WS2812#Android_App|Android App]] mindestens die Version 1.4 oder höher haben!'''

Ist ein [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Modul angeschlossen und korrekt konfiguriert, kann die Uhr ab Software-Version 1.0 per [[WordClock_mit_WS2812#Android_App|Android App]] ferngesteuert werden.

Momentan können folgende Einstellungen vorgenommen werden:

* Ein-/Ausschalten der Uhr
* Einstellen der Farben
* Manuelle Einstellung einer Grundhelligkeit ('''Neu''')
* Automatische Helligkeitsregelung per [[WordClock_mit_WS2812#LDR|LDR]] ein/aus ('''Neu''')
* Einstellung des Anzeigemodus
* Einstellung der Animation (Überblenden, Rollen, Explosion etc.)

Weitere Features werden folgen.

Bevor man mit der App Daten senden kann, muss man die IP-Adresse, die das [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Modul bekommen hat, in der App einstellen. Dies geht über den Menü-Eintrag "Server".

= Mechanik =

== Anbringung der WS2812-Streifen ==

[[Datei:Wclock24h-WS2812-auf-Alu-Platte.jpg|miniatur|16 WS2812-Streifen auf Alu-Platte]]
[[Datei:Wclock24h-16-pol-Wanne.png|miniatur|16pol Wanne zum Verbinden des Netzteils und der Streifen]]
[[Datei:Wclock24h-Spannungsvergung-Streifen.jpg|miniatur|Anschluss der Streifen an die Spannungsversorgung]]

'''WordClock24h:'''

Am besten verwendet man eine Alu-Platte mit den Maßen 310mmx310mm und 1mm Stärke. Darauf lassen sich nicht nur einfach die WS2812-LED-Streifen aufkleben, auch dient die Alu-Platte der Wärmeabfuhr. Die Alu-Platte kann man sich von einem der eBay-Händler für ca. 3,50 Euro zurechtschneiden lassen.

Den LED-Streifen schneidet man 16 Streifen à 18 LEDs. Bevor man sie auf die LED-Platte klebt, sollte man senkrecht je einen Tesa-Streifen links und rechts auf die Alu-Platte kleben, da sich gezeigt hat, dass die Schnittkanten der Streifen gern einen Kurzschluss mit der Alu-Platte bilden.

Die LED-Streifen werden dann im Zieharmonika-Verfahren aufgeklebt. Dabei steht jeder 2. Streifen auf dem Kopf. Das hat den Vorteil, dass die Verbindungen zwischen den Streifen möglichst kurz sind. Auf der rechten Seite verbindet man dann die Anschlüsse +5V mit +5V, GND mit GND und DO mit DI - siehe Bild. Man verbindet also den ersten mit dem zweiten Streifen, den dritten mit dem vierten Streifen usw.

Auf der linken Seite verbindet man lediglich DO mit DI, also den zweiten Streifen mit dem dritten, den vierten mit dem fünften usw. An den verbleibenden Lötpunkten +5V und GND lötet man an jedem *zweiten* Streifen (1, 3, 5 usw.) die Spannungsversorgung an. Praktisch ist die Verwendung eines 16-poligen Flachbandkabels, welches man auf einen Flachbandkabel-Stecker aufquetscht. Pin 1 und 2 gehen dann an 5V/GND des ersten Streifens, 3 und 4 an 5V/GND des dritten Streifens usw.

Dann kann man mittels 16-poligem Wannenstecker, den man auf eine Lochrasterplatine lötet, die Spannungsversorgung einfach verpolungssicher anstecken. Unter der Lochrasterplatine werden die geradzahligen Pins und die ungeraden Pins je mit einem Kupferdraht verbunden. Mit einer 2-poligen Schraubklemme auf der Lochrasterplatine kann dann das Netzteil angeschlossen werden - siehe Bild rechts.

'''WordClock12h:'''

(In Arbeit)

== Zwischenplatten ==

(in Arbeit)

== Frontplatten ==

(in Arbeit)

= Sammelbestellungen =

== WC12h Sammelbestellung LED Stripes ==

Hier wird eine Spezialanfertigung mit einem Rastermaß von 28,1mm eingesetzt.

(Kapitel noch in Arbeit)

== WC12h Sammelbestellung Zwischenböden ==

(Kapitel noch in Arbeit)

== WC12h Sammelbestellung Frontplatten ==

(Kapitel noch in Arbeit)

== WC24h Sammelbestellung LED Stripes ==

(Kapitel noch in Arbeit)

== WC24h Sammelbestellung Zwischenböden ==

(Kapitel noch in Arbeit)

== WC24h Sammelbestellung Frontplatten ==

(Kapitel noch in Arbeit)

= Anhang =

=== Historie der Software-Versionen ===

Version 1.6.3:

* WordClock12h: Anzeige der Temperatur durch Laufschrift
* Neue Anschlusspins für TSOP und DS18xxx am STM32F103
* Optimierung des WS2812-DMA-Transfers für STM32F103
* Temperaturmessung mit DS3231, wenn kein DS18xx angeschlossen
* Umstrukturierung der C-Sources

Version 1.6.2:

* Problem beim Verbindungsaufbau Andoid App -> WordClock behoben

Version 1.6.1:

* Zusätzliche Unterstützung der "klassischen" WordClock12h mit 10x11 LEDs
* Anpassung der [[MCURSES]]-[[WordClock_mit_WS2812#MCURSES-Monitor|Monitor]]-Oberfläche an WordClock12h-Variante
* Portierung auf STM32F103 abgeschlossen (IDE-Projekt folgt mit 1.6.2)
* Zusätzliche Unterstützung von neueren [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Firmware-Versionen 1.0.1, 1.4.0 und 1.5.0.
* Optionales [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Debugging auf zusätzlichem USART - nur für Entwickler

Version 1.6.0:

* Neben dem TIME-Protokoll (TCP) wird nun auch NTP (UDP) unterstützt - für ESP-Firmware-Versionen ab 0018000902.

Version 1.5.9:

* Unterstützung der neueren ESP Versionen 0020000903 und AT 0.21.0.0
* Vergrößerung der UART-FIFOs
* Verallgemeinerung der UART-Funktionen zwecks besserer Konfiguration
* Überarbeitung der [[MCURSES]]-[[WordClock_mit_WS2812#MCURSES-Monitor|Monitor]]-Oberfläche

Version 1.5.8:

* Bugfix: Fehler in 1.5.7 (Falsche Behandlung des DMA-Buffers) wurde behoben
* Neu: Bis zu 100 weitere LEDs hinter der Buchstabenkette werden als Ambilight angesteuert

Version 1.5.7:

* Bug in uart-Code für STM32F103 beseitigt - irrelevant für Nucleo STM324xx
* Timing für WS2812B angepasst, es werden nun WS2812 und WS2812B unterstützt
* Anzahl der möglichen [[WordClock_mit_WS2812#WS2812|WS2812]]-LEDs ist nun variabel gehalten. Das ist Voraussetzung für das demnächst verfügbare Ambilight.

Version 1.5.6:

* Unterstützung von [[WordClock_mit_WS2812#ESP8266|ESP8266]] mit neuerer Firmware, welche \r\n statt \r erwartet
* Unterstützung von verschiedenen Baudraten des [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Moduls
* Automatische Umschaltung von 9600Bd auf 115200Bd beim [[WordClock_mit_WS2812#ESP8266|ESP8266]]

Version 1.5.5:

* Optimierungen im LED-Display-Code
* Diverse Anpassungen an STM32F103

Version 1.5.4:

* Automatische IR-Anlernroutine in den ersten 3 Sekunden ab Programmstart
* Kleiner Bugfix bei den möglichen Helligkeitsstufen (Dimmer)

Version 1.5.2:

* Anzeige der Firmware-Version des [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Moduls im [[MCURSES]]-[[WordClock_mit_WS2812#MCURSES-Monitor|Monitor]]
* Korrektur in den Worttabellen für die Wörter ACHT und VIER in der zehnten Reihe

Version 1.5.1:

* Manuelle Helligkeitsregelung per [[MCURSES]]-[[WordClock_mit_WS2812#MCURSES-Monitor|Monitor]] / IR-Fernbedienung / [[WordClock_mit_WS2812#Android_App|Android App]] eingebaut
* Automatische Helligkeitsregelung per [[WordClock_mit_WS2812#LDR|LDR]] nun über [[MCURSES]]-[[WordClock_mit_WS2812#MCURSES-Monitor|Monitor]] / IR-Fernbedienung / [[WordClock_mit_WS2812#Android_App|Android App]] ein-/ausschaltbar

Version 1.4.2:

* Die geladenen aus dem [[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROM]] RGB-Werte wurden nach dem Boot nicht mehr sofort übernommen. Ist korrigiert.

Version 1.4.1:

* Initialisierung des ADC korrigiert
* Automatische Helligkeitsregelung dunkelt nicht mehr so stark ab.

Version 1.4.0:

* Automatische Helligkeitsregelung mittels [[WordClock_mit_WS2812#LDR|LDR]]
* Helligkeitsstufen von 32 auf 64 erhöht
* LED-Testprogramm eingebaut (Taste 'T' im [[MCURSES]]-[[WordClock_mit_WS2812#MCURSES-Monitor|Monitor]])
* Anzeige des [[WordClock_mit_WS2812#Temperatur-Sensor|DS18xxx]]-Typs im [[MCURSES]]-[[WordClock_mit_WS2812#MCURSES-Monitor|Monitor]])
* Unterstützung für Status-LED '''(beachte geändertes LED-Anschluss-Schema!)'''
* [[WordClock_mit_WS2812#Android_App|Android App]] an 64 Helligkeitsstufen angepasst

Version 1.3.1:

* Sporaisches Hangup-Problem nach Auslesen der Temperatur behoben
* Fehler bei der Erkennung des Family-Codes für [[WordClock_mit_WS2812#Temperatur-Sensor|DS18xxx]] beseitigt
* Optimierung des Zeitverhaltens beim Zugriff auf OneWire-Bus
* Optimierung des [[WordClock_mit_WS2812#WS2812|WS2812]]-Codes

Version 1.3.0:

* Unterstützung von [[WordClock_mit_WS2812#Temperatur-Sensor|DS18xxx]]-Temperatursensoren
* Temperatur-Anzeige innerhalb +10°C und 39,5°C
* Korrektur Sommerzeitumstellung
* Keine Unterstützung mehr von STM32F4-Discovery

Version 1.2.0:

* IRMP-Konfigurationsfehler behoben

Version 1.1.0:

* Animationen hinzugefügt
* Neue Tabellen für Uhrzeit und Temperatur

Version 1.0.0:

* Test auf verschiedene Adressen des I2C-[[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROMs]]
* [[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROM]]-Speicherplatzverbrauch minimiert
* [[WordClock_mit_WS2812#RTC_und_EEPROM|RTC]] DS3231-Routinen auf DS1307 verallgemeinert
* Network Listener (UDP) zum Fernsteuern der Uhr über WLAN
* [[WordClock_mit_WS2812#Android_App|Android App]] zum Fernsteuern der Uhr (Ein/Aus, Farben, Anzeigemodus)

Version 0.9.1:

* [[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROM]]-Hexdump im [[MCURSES]]-[[WordClock_mit_WS2812#MCURSES-Monitor|Monitor]] eingebaut
* Zusätzliche Waitstates beim Beschreiben des [[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROMs]]

Version 0.9:

* Zusätzlicher Anschluss von RST und CH_PD des [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Moduls
* Verbesserung der [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Konfiguration dank Hardware-Reset
* Nutzung des Stromsparmodus im [[WordClock_mit_WS2812#ESP8266|ESP8266]], wenn die Anzeige abgeschaltet wird
* Konfiguration der Zeitzone über [[MCURSES]]-[[WordClock_mit_WS2812#MCURSES-Monitor|Monitor]]
* Test und Überarbeitung der [[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROM]] und [[WordClock_mit_WS2812#RTC_und_EEPROM|RTC]]-Funktionen
* Synchronisation der [[WordClock_mit_WS2812#RTC_und_EEPROM|RTC]]-Zeit mit dem µC-Timer
* Speichern folgender Daten im [[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROM]]:

EEPROM-Version
IRMP-Daten einer angelernten IR-Fernbedienung
Aktuell eingestellte Farben und Anzeigemodus
IP-Adresse des Timeservers
Zeitzone

Version 0.8:

* Neue IR-Fernbedienungs-Tasten POWER und OK
* Einbau einer konfigurierbaren "Nachtzeit", in der sich die Uhr selbstständig abschaltet
* Konfiguration des Timeservers über [[MCURSES]]-[[WordClock_mit_WS2812#MCURSES-Monitor|Monitor]]
* Speichern/Laden sämtlicher Konfigurations-Daten in externem EEPROM
* Initialisierung des [[WordClock_mit_WS2812#ESP8266|ESP8266]] verbessert (warten, bis nach PowerOn eine WLAN-Verbindung besteht)
* Aufteilung der Anzeige-Logik und des [[MCURSES]]-[[WordClock_mit_WS2812#MCURSES-Monitor|Monitor]]s auf dsp.c und monitor.c
* Aufteilung der [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Routinen auf esp8266.c (low-level) und timeserver.c (high-level)
* Diverse Optimierungen - u.a. durch Einsatz von uint_fast8_t
* Diverse Bugfixes

Version 0.7.1:

* Portierung der Software auf STM32F411RE [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]]

Version 0.7:

* Portierung der Software auf STM32F401RE [[WordClock_mit_WS2812#STM32F401RE_Nucleo_und_STM32F411RE_Nucleo|Nucleo-Board]]
* uart2.c generalisiert auf uart.c (verschiedene UARTs möglich)
* Bugfix im UART-Ringbuffer-Code (Interrupt-Sperre)
* Anzeige der Online-Devices ([[WordClock_mit_WS2812#ESP8266|ESP8266]], [[WordClock_mit_WS2812#DCF77|DCF77]], EEPROM, [[WordClock_mit_WS2812#RTC_und_EEPROM|RTC]]) im Terminal
* Verschiedene Optimierungen

Version 0.6:

* Konfiguration des WLAN-Moduls (SSID & Key) nun über Terminal statt fest im Code verdrahtet.
* Einstellung der Zeitzone möglich. Standard ist GMT+1, also mitteleuropäische Zeit.
* [[WordClock_mit_WS2812#DCF77|DCF77]]- und [[WordClock_mit_WS2812#ESP8266|ESP8266]]-Modul-Aktivierung automatisch - keine Einstellung mehr im Code notwendig.
* I2C-Lib hinzugefügt (noch ungetestet und daher noch nicht verwendet).
* I2C-[[WordClock_mit_WS2812#RTC_und_EEPROM|EEPROM]]-Modul hinzugefügt (noch ungetestet und daher noch nicht verwendet).
* I2C-[[WordClock_mit_WS2812#RTC_und_EEPROM|RTC]]-Modul (DS3231) hinzugefügt (noch ungetestet und daher noch nicht verwendet).

AVR-GCC-Codeoptimierung

2015-12-21T05:13:01Z

Maybee: Änderung 90492 von Mfgkw (Diskussion) rückgängig gemacht. Der Wert 59.1 ist schon richtig.

Entstanden aus diesem [http://www.mikrocontroller.net/topic/66690 Thread] sollen hier ein paar Hinweise/Erfahrungen gegeben werden, um den Quellcode in Punkto Größe und Geschwindigkeit zu optimieren. ''En detail'' ist das Thema komplex, da es stark von der Codeoptimierung des Compilers abhängt. Es ist im Einzelfall ratsam zu prüfen, ob die eigenen Maßnahmen auch erfolgreich waren. Die Diskussionen [http://www.mikrocontroller.net/topic/132624] bzw. [http://www.mikrocontroller.net/topic/180800#new] können als Anhaltspunkte dienen, wie eine solche Prüfung ablaufen kann.

== Prinzipien der Optimierung ==

Wie so oft sollte man nicht einfach wild drauf los optimieren und sich zunächst ein paar Dinge klar machen.

* Warum will ich optimieren?
* Was kann man sinnvoll optimieren?
* Wieviel Rechenzeit oder Speicher soll dabei gespart werden?
* Wie kann optimiert werden?
* '''"Verfrühte Optimierung ist die Wurzel allen Übels!"'''

Viele Optimierungen sind "Angst-Optimierungen", die nicht wirklich nötig sind. Die Gefahr mit Optimierungen ist, den Code tot zu optimieren, sprich Lesbarkeit, Portierbarkeit und ggf. Fehlerfreiheit sinken massgeblich. Kurz und knapp in diesem [http://blogs.msdn.com/b/audiofool/archive/2007/06/14/the-rules-of-code-optimization.aspx BLOG] formuliert.

=== Warum ===

Optimieren sollte man nur, wenn
* der Speicher nicht mehr ausreicht (RAM, Flash)
* Die Laufzeit für bestimmte Programmteile zu groß wird und somit bestimmte (Echtzeit-)Ausgaben nicht im erforderlichen Zeitrahmen erledigt werden

Weiter sollte man folgende Punkte gegeneinander abwägen:

* Codeverbrauch
* Datenverbrauch. Statisch/Stack/Heap
* Mittlere Laufzeit/maximale Laufzeit
* Entwicklungszeit
* Portabilität (Compiler, Hardware, ...)
* Verständlichkeit der Quelle, siehe [[Strukturierte Programmierung auf Mikrocontrollern]]
* ABI-Konformität

=== Was ===

Die goldene Regel lautet:

'''90% der Rechenleistung werden in 10% des Codes verbraucht.'''

Diese 10% muss man finden und zum richtigen Zeitpunkt optimieren. Der Rest muss nur sauber und lesbar geschrieben sein. Was jedoch nichts bringt, ist eine Funktion, die von 1 Minute Programmlaufzeit lediglich 1 Sekunde verbraucht, um den Faktor 10 schneller zu machen. Die Programmlaufzeit sinkt dann von 60 Sekunden auf 59.1 Sekunden. Der Aufwand, die Funktion um einen Faktor 10 schneller zu machen ist aber meistens beträchtlich! Kann ich aber den Code, der für die 59 Sekunden verantwortlich ist um lediglich einen Faktor 2 schneller machen (was immer noch oft schwer genug ist, aber auf jeden Fall leichter als ein Faktor 10), dann sinkt die Gesamtlaufzeit von 60 Sekunden auf 30.5 Sekunden. Dort bringt Optimieren augenscheinlich viel mehr!

Um die optimierungswürdigen Stellen zu finden, muss man sein Programm analysieren. Dazu gibt es verschiedene Möglichkeiten.

====Speicherverbrauch nach Funktionen aufschlüsseln====

;map-File:
:dort sind alle globalen und statischen Variablen enthalten. Eine Map-Datei kann mit den GNU-Tools während des Linkens angelegt werden:
::<pre>> avr-gcc ... -Wl,-Map,foo.map</pre>
: Die Option -Wl bewirkt, daß avr-gcc die angehängen Optionen unverändert an den Linker weiterreicht. Dieser erzeugt dann das Mapfile "foo.map", eine Textdatei.
;avr-size: Mit Tools wie avr-size kann die Platzbelegung einzelner Module ermittelt werden:
::<pre>> avr-size -x foo1.o foo2.o ...</pre>
:bzw. die Platzbelegung der elf-Datei:
::<pre>> avr-size foo.elf</pre>
;avr-nm:
::<pre>> avr-nm --size-sort -S foo.elf</pre>
:ergibt eine Liste mit der Größe aller Objekte: der erste Spalte enthälte die Adresse, die zweite Spalte die Größe, die dritte den Typ und die vierte Spalte den zugehörigen Symbolnamen. Der Typ ergibt sich aus der folgenden Zuordnung, wobei Großbuchstaben globale Symbole kennzeichnen und Kleinbuchstaben Symbole, die Modul-lokal sind:
:;T/t: Objekte in der text-Section: Funktionen, Daten im Flash
:;D/d: Objekte im data-Segment (initialisierte Daten)
:;B/b: Objekte im bss-Segment (Null-initialisierte Daten)

;avr-gcc: Der Compiler hat bereits Informationen über die übersetzten Funktionen, die man direkt zur Analyse verwenden kann. Dazu lässt man avr-gcc die Assembler-Ausgabe, die ohne weiteres Zutun nur als temporäre Datei angelegt wird, abspeichern. Etwa für die Quelldatei foo.c:
::<pre>> avr-gcc -save-temps foo.c -c ...</pre>
:Die Assembler-Datei wird damit als foo.s angelegt und nicht gelöscht. (Das ebenfalls angelegte Präcompilat foo.i wird nicht benötigt). Für jede Funktion gibt avr-gcc 3.4.x im Prolog einen Kommentar der Form<ref>Für avr-gcc 4.x sehen die Kommentare anders aus oder fehlen je nach Compilerversion ganz</ref>
::<pre>/* prologue: frame size=0 */</pre>
:aus, was die Größe des aktuellen Frames angibt. Dies ist der Platz auf dem Stack, der für lokale Variablen benötigt wird. Am besten ist es, wenn die Frame-Size wie im Beispiel gleich 0 ist. Ansonsten sollte man versuchen, diese Größe auf Null zu bringen. Für Variablen, die nicht in Registern gehalten werden können, müssen Speicherzugriffe in den Stack erzeugt werden. Diese machen das Programm sowohl größer aus auch langsamer. Zudem reserviert avr-gcc bei solche Funktionen das Y-Register als Frame-Pointer; das Y-Register steht damit nicht mehr für lokale Variablen zur Verfügung was sich ebenfalls ungünstig auf die Codegüte auswirkt. Ein Grund für das Anlegen eines Frames können zu viele lokale Variablen sein (zB lokale Puffer/Arrays) oder lokale Variablen/Strukturen/Parameter mit ungünstigen Größen, etwa eine 3-Byte große Struktur.

: Neben dieser Information gibt avr-gcc Kommentare der Gestalt
::<pre>/* prologue end (size=2) */</pre>
:aus die darüber informieren, wie viele Register auf dem Stack gesichert wurden.

: Zusammen mit Werkzeugen wie grep, die in jedem Linux und jeder WinAVR-Distribution enthalten sind, findet man schnell Übeltäter wie Funktionen mit Frame.

;Assembler-Code sichten: Ein kurzer Blick auf den erzeugten Assembler-Code zeigt oft, wie gut der Compiler den Code umgesetzt hat. Den erzeugten Assembler-Code zu überfliegen ist wesentlich zeitsparender als selbst in Assembler zu programmieren. Je nach Gusto verwendet man zur Einsicht den Assembler-Code, den avr-gcc ausgibt (s.o.), Assembler-Dumps des Assemblers, List-Files oder HEX-Dumps. Siehe auch<ref>[http://rn-wissen.de/index.php/Assembler-Dump_erstellen_mit_avr-gcc roboternetz.de: Assembler-Dump erstellen mit avr-gcc]</ref>

;Hilfsmittel: einkaufen oder selber bauen. Es gilt herauszufinden, welche Funktion massig Stack durch lokale Variablen verbraucht. Stacktracer können das. Wenn man keinen hat, dann muss man sich eben selber einen bauen, indem man den Stackpointer mitloggt. Zur Not einen Code-Review machen: Alle Funktionen optisch durchgehen und die identifizieren, die viele Variablen anlegen. Dann die Aufrufhierarchie der Funktion feststellen: Wirken sich die vielen Variablen überhaupt aus oder entsteht mein Problem durch eine tiefe Funktionsaufrufhierarchie, bei der zwar wenige Variablen pro Funktion im Spiel sind, aber die Menge der ineinandergeschachtelten Aufrufe 'das Kraut fett macht'
;Profitools: können das alles fast auf Knopfdruck, kosten aber viel Geld

====Laufzeit messen====

*Simulator
*In Echtzeit mittels Testpin, welche an Anfang einer Funktion/Blocks gesetzt wird und am Ende wieder gelöscht wird. Mit einem [[Oszilloskop]] kann man so sehr einfach die Laufzeit messen.

; Anmerkung: Solche Messverfahren liefern immer nur eine ''untere'' Schranke für die Laufzeit, niemals eine obere Schranke. Eine obere Schranke, wie man sie etwa in sicherheitsktitischen Systemen benötigt, liefert eine statische Codeanalyse.

=== Wieviel ===

Der Aufwand von Optimierungen wächst exponentiell. Die letzten paar Prozent brauchen überproportional viel Aufwand.

=== Wie ===

Meist muss man die Wahl treffen ob man Speicher oder Rechenzeit sparen will, beides gleichzeitg geht meist nicht. Das Konzept heißt 'Space for Time' und kann in beide Richtungen verwendet werden. Als Beispiel soll eine komplizierte Berechnung dienen. Diese kann man relativ kompakt in eine Funktion packen, welche dann aber eher langsam ist. Oder man benutzt eine sehr große Tabelle, in welcher die Ergebnisse schon für jeden Eingangswert vorausberechnet wurden. Diese Lösung ist sehr schnell, verbraucht aber sehr viel Speicher.

* Inlining von Funktionen erhöht den Speicherverbrauch, senkt aber die Laufzeit. Beispiel: Funktion A ist 50 Byte groß und wird 10 mal im Programm aufgerufen. Ein Aufruf kostet 10 Byte:
** Ohne Inline: 10 * 10Byte + 50 Byte = 150 Byte Platzverbrauch
** Mit Inline: 10 * 50 Byte = 500 Byte
* Optimierer einschalten
* möglichst keine Floating Point Operationen, besser ist meist [[Festkommaarithmetik]]
* Formeln umstellen und zusammenfassen
* Variablen so klein wie möglich, uint8_t wo's nur geht.
* Wirklich zeitkritische Funktionen und Interrupts als Assemblercode in separater Datei

== GCC-Optionen ==

=== Optimierungs-Level ===

avr-gcc kennt mehrere Optimierungsstufen:
;<tt>-O0</tt>: Keine Optimierung des erzeugten Codes. Diese Optimierungsstufe optimiert den Resourcenverbrauch des ''Hostrechners'' und die Nachvollziehbarkeit der erzeugten Codes anhand von Debug-Information. Alle lokalen Variablen werden auf dem Stack angelegt und nicht in Registern gehalten. Es werden keine komplexen Optimierungsalgorithmen angewandt; lediglich Konstanten wie 1+2 werden zu 3 gefaltet.

;<tt>-O1</tt>: Je höher die Optimierungsstufe, desto schwieriger ist der erzeugte Code nachvollziehbar — auch mit Debugger. Diese O-Stufe ist ein Kompromiss zwischen aggressiver Optimierung und Nachvollziehbarkeit des erzeugten Codes. Ein ehernes Gesetz in GCC ist, dass er den gleichen Code erzeugen muss unabhängig davon, ob Debug-Information erzeugt wird oder nicht. Im Umkehrschluss erlaubt volle Debug-Unterstützung nicht alle Optimierungen, wozu diese Optimierungsstufe dient.

;<tt>-O2</tt>: Optimierung auf Geschwindigkeit. Für AVR nur mässig sinnvoll, da sich der Codezuwachs nicht in einen entsprechenden Geschwindigkeitszuwachs transformiert. Dies liegt vor allem daran, daß Sprünge und Funktionsaufrufe auf AVR im Vergleich zu anderen Architekturen sehr billig sind. Es bringt also kaum einen Geschwindigkeitszuwachs, einen Block zu kopieren um einen Sprung zu sparen. Hingegen vergrößert dies den Code deutlich.

;<tt>-O3</tt>: Dito. Auf Teufel-komm-raus Funktionen zu inlinen, Schleifen aufzurollen oder gar Funktionen mehrfach für unterschiedliche Aufruf-Szenarien zu implementieren, ist auf einem kleinen µC wie AVR der Overkill.

;<tt>-Os</tt>: Optimierung auf Codegröße. Die bevorzugte Optimierungsstufe für AVR und viele andere µC.

Jede O-Option ist ein Sammlung von verschiedenen Schaltern, welche bestimmte Optimierungsstrategien aktivieren. Um zu sehen, welche Schalter dies genau sind, erzeugt man wie oben beschrieben mit den Schalten
-save-temps -fverbose-asm
die Assembler-Ausgabe von gcc und schaut die Optionen im s-File nach. Einzelne Optionen lassen sich gezielt aktivieren bzw. deaktivieren und damit zum Beispiel zum <tt>-Os</tt>-Paket hinzufügen.

Eine Ausnahme bildet <tt>-O0</tt>: Hier ist Code-Optimierung generell deaktiviert, und Optimierungsschalter bleiben ohne Wirkung.

=== Feinabstimmung der Optimizer ===

Kandidaten für Optimierungsoptionen sind folgende Schalter. <tt>-m</tt> kennzeichnet maschinenspezifische Schalter, die nur für AVR gültig sind. <tt>-f</tt> bzw. <tt>-fno-</tt> sind maschinenunabhängige Schalter, die auch für andere Architekturen verfügbar sind.

;<tt>-fno-split-wide-types</tt>: Je nach Quelle kann die Deaktivierung von <tt>-fsplit-wide-types</tt> besseren Code ergeben.

;<tt>-fno-inline-small-functions</tt>: Relativ kleine Funktionen /immer/ zu inlinen kann den Code unnötig vergrößern, dieser Schalter unterbindet das automatische Inlinen kleiner Funktionen.

;<tt>-finline-limit=</tt>''wert'': Maximalwert für automatisch geinlinte Funktionen. In einschlägigen Foren werden kleine Werte für ''wert'' vorgeschlagen, z.B. 1…3

;<tt>-mcall-prologues</tt>: Die für aufwändige Funktionen mitunter recht langen push/pop-Sequenzen werden durch Hilfsfunktionen ersetzt. Das kann vor allem bei grossen Programmen Platz sparen. Die Ausführungszeit steigt an.

;<tt>-fno-jump-tables</tt>: Switch-Statements werden hierdurch mitunter deutlich kürzer.

;<tt>-fno-move-loop-invariants -fno-tree-loop-optimize</tt>: Einige Schleifenoptimierungen, welche die Registerlast erhöhen und für AVR kaum zu einem Geschwindigkeitszuwachs führen, werden deaktiviert.

;<tt>-fno-tree-switch-conversion</tt>: Neue GCC-Versionen können switch/case Anweisungen u.U. in Lookup-Tabellen umwandeln, die im RAM abgelegt werden, siehe auch [http://gcc.gnu.org/PR49857 PR49857]. Dieser Optimierung ist bei RAM-Knappheit in Betracht zu ziehen, bring aber natürlich nur dann etwas, wenn diese Optimierung auch ausgeführt wurde.

;<tt>-fno-optimize-sibling-calls</tt>: Ab 4.7 wirksam: Tailcall-Optimierung kann den Code vergrößern, wenn Epiloge mehrfach erzeugt werden. In diesem Fall deaktiviert man die Tailcall-Optimierung.

;<tt>-maccumulate-args</tt>: Ab 4.7: Funktionen, die mehrere printf-artige Aufrufe enthalten und viele Artumente per Stack an diese übergeben, werden u.U kleiner.

;<tt>-mstrict-X</tt>: Ab 4.7: Beeinflusst die Art und Weise, wie das X-Register zur Adressierung verwendet wird.

;<tt>-mbranch-cost=</tt>''wert'': Ab 4.7: Setzt die Kosten, mit der der Compiler einen bedingten Sprunge veranschlagt. Default-Wert ist ''wert''<tt>=0</tt>.

;<tt>-fno-caller-saves</tt>: Kann zu effizienteren Pro-/Epilogen beitragen.

;<tt>-fno-tree-ter</tt>: Es gibt Fälle, in denen der Compiler die Berechnung temporärer Variablen über volatile-Zugriffe und Memory-Barriers zieht, siehe [http://gcc.gnu.org/PR53033 PR53033]. Von der C-Spezifikation her ist dies zulässig, kann aber zu unerwünschter Umsortierung der volatile-Operation führe, z.B. wenn es sich dabei um eine <tt>SEI</tt>-Instruktion handelt. Ohne diese Optimierung wird der Code evtl. etwas größer, aber Probleme wie im PR beschrieben können vermieden werden.

;<tt>--param case-values-threshold=</tt>''wert'': Ab 4.7: Schwellwert an Einträgen in einem switch/case, ab dem anstatt eines binären if/else-Entscheidungsbaums eine Sprungtabelle zu den case-Labels erzeugt wird. Voreinstellung ab 4.7 ist ''wert''<tt>=7</tt>. Ältere Compilerversionen verwenden andere Werte. Siehe auch <tt>-f[no-]jump-tables</tt>.

Generell gilt für all diese Optionen, daß sie abhängig vom Projekt zu einer Codeverbesserung oder -verschlechterung führen können — dies ist i.d.R. vom Projektcode abhängig.

=== Linker-Optionen ===

;<tt>-ffunction-sections -Wl,--gc-sections</tt>: Der Linker wirft nicht referenzierte Sections weg, was die Codegröße günstig beeinflussen kann. Diese Optimierung verkleinert den Code nur dann, wenn nicht verwendete Funktionen in der Anwendung rumgammeln. Weil der Linker nur auf Section-Ebene optimieren kann, muss zusätzlich der Compiler mit <tt>-ffunction-sections</tt> aufgerufen werden, um die Anwendung auf möglichst viele Sections zu verteilen.

;<tt>-Wl,--relax -mrelax</tt>: Der Linker fasst Tail-Calls wie
::<tt>CALL some_function RET</tt>
: zusammen als
::<tt>JMP some_function</tt>
: Siehe auch die Compiler-Option <tt>-f[no-]optimize-sibling-calls</tt> von oben. Zudem wird <tt>CALL</tt> umgewandelt zur kürzeren <tt>RCALL</tt>-Instruktion falls das Sprungziel im ±4 KiB-Zielbereich von <tt>RCALL</tt> liegt. Analog für <tt>JMP</tt> zu <tt>RJMP</tt>.

: Die beiden Optionen sind gleichwertig; die erste Variante veranlasst den Compiler, den Linker mit <tt>--relax</tt> aufzurufen. Die zweite Variante verwendet den allgemeinen <tt>-Wl</tt>-Mechanismus, um eine Option von der Compiler-Kommandozeile an den Linker durchzureichen.

=== Weitere Optionen ===

;<tt>-mtiny-stack</tt>: Der Compiler ändert nur das Low-Byte des Stackpointers (SP), was auf Controllern mit 16-Bit SP zu kleinerem Code führen kann. Benötigt der Code Platz auf dem Stack, so erzeugt der Compiler u.U. Code, der den SP liest, einen Offset aufaddiert/abzieht und den SP dann zurückschreibt. Dies ist aufwändig. Für den Fall, daß sich dabei das High-Byte SP nicht ändert, kann Code eingespart werden.

:Beispiel: ATtiny44 hat RAM von <tt>0x60</tt> bis <tt>0x15f</tt>. Braucht die Anwendung nicht mehr als <tt>0x60</tt> = 96 Bytes an Stack, dann kann mit <tt>-mtiny-stack</tt> compiliert werden.

=== Änderung des Binärinterfaces per Option ===

{{Warnung|
;Warnung: Im Gegensatz zu den Optionen der vorherigen Abschnitte, bei denen es sich um reine Optimierungsoptionen handelt, ändern die folgenden Optionen das Binärinterface (ABI) des vom Compiler erzeugten Codes und sind daher nur nach eingehender Prüfung anzuwenden! Wird eine Anwendung mit diesen Schaltern übersetzt, dann ist sicher zu stellen, daß ''alle'' Module inclusive Libraries damit derzeugt werden oder die ABI-Änderung sich nicht auf Code in Bibliotheken auswirkt!
}}

Vorsicht in auch deshalb geboten, weil manche Entwicklungsumgebungen wie "Atmel Studio" das ABI ''per Default'' verändern und ohne daß der Anwender es extra anfordert.

;<tt>-funsigned-char</tt>: Anders als im avr-gcc ABI ist der Typ <tt>char</tt> unsigned anstatt signed.
:Besser: Verwende die C99-Typen wie <tt>uint8_t</tt> aus dem C99-Header <tt>stdint.h</tt>.

;<tt>-funsigned-bitfields</tt>: Bitfelder mit Basetype <tt>char</tt>, <tt>short</tt>, <tt>int</tt> <tt>long</tt> und <tt>long long</tt> werden als unsigned implementiert anstatt als signed wie in der avr-gcc ABI.
:Besser: Wenn ein Bitfeld unsigned sein soll, dann mach es unsigned!

;<tt>-fpack-struct</tt>: Im Gegensatz zur avr-gcc ABI werden Strukturen und Unions per default gepackt.
:Besser: Wenn ein zusammengesetzter Typ gepackt werden soll, mache ein Typedef mit explizitem <tt>__attribute__((packed))</tt>!

;<tt>-fshort-enums</tt>: Enum-Typen werden so kurz wie möglich implementiert anstatt als <tt>int</tt> gemäß avr-gcc ABI.

;<tt>-mint8</tt>: Ein <tt>int</tt> ist nur nocht 8 Bits breit. Dies entspricht nicht mehr dem C-Standard und wird nicht durch die C-Bibliotheken wie AVR-Libc oder newlib unterstützt! Die Codegröße von 8-Bit Operationen kann sich verkleinern, weil andere Integer-Promotion Regeln angewandt werden. Literals müssen ggf. angepasst bzw gecastet werden, siehe auch C99-Makros wie <tt>UINT16_C</tt> aus <tt>stdint.h</tt>.

== Anpassungen der Quelle ==

=== Attribute noreturn, OS_main und OS_task ===

Mikrocontroller-Programme laufen normalerweise in einer Endlosschleife, so dass die main-Routine nie verlassen wird.
Teilt man dies dem Compiler mit, kann er bestimmte Optimierungen durchführen.
So ist es zum Beispiel unnötig, Code zum Sichern und Zurücklesen von Registern zu erzeugen.

Das Mitteilen funktioniert beim gcc über Attribute, die man der Deklaration oder bei der Implementierung einer Funktion anhängt:
<syntaxhighlight lang="c">static void main_loop (void) __attribute__((noreturn));
void main_loop (void)
{
while (1)
{
// Hauptschleife
}
}</syntaxhighlight>
oder
<syntaxhighlight lang="c">static void __attribute__((noreturn))
main_loop (void)
{
while (1)
{
// Hauptschleife
}
}</syntaxhighlight>

Die Funktion <tt>main_loop</tt> kann dann in <tt>main</tt> aufgerufen werden:

<syntaxhighlight lang="c">int main (void)
{
main_loop();

return 0;
}</syntaxhighlight>
Das abschließende <tt>return</tt> wird vom Compiler wegoptimiert und belegt keinen Speicher.

<tt>avr-gcc</tt> kennt weiterhin die Attribute <tt>OS_main</tt> und <tt>OS_task</tt>.
Die Verwendung von <tt>OS_main</tt> kann etwa aussehen wie folgt. Natürlich kann auch wie oben die Hauptschleife in einer eigenen Funktion implementiert werden, und das <tt>return</tt> verursacht keinen zusätzlichen Code:
<syntaxhighlight lang="c">int __attribute__((OS_main))
main (void)
{
while (1)
{
// Hauptschleife
}

return 0;
}</syntaxhighlight>

=== Statische Variablen in einer Struktur sammeln ===

Gibt es in einem Programm mehrere inhaltlich zusammengehörende Variablen, dann ist es sinnvoll diese in einer Struktur zu vereinigen. Neben einer klareren Programm- bzw. Datenstruktur kann dies auch zu kleinerem Code führen.

Beispiel ist die folgende kleine Routine, welche die Zeit in der globalen <tt>time</tt>-Strukture um eine Sekunde erhöht:

<syntaxhighlight lang="c">
#include <stdint.h>

typedef struct
{
uint8_t second;
uint8_t minute;
uint8_t hour;
} time_t;

// Globale time-Struktur enthält die Zeit
time_t time;

void next_second (void)
{
// Zeiger auf die globale time-Struktur
time_t *ptime = &time;

// time um 1 Sekunde erhöhen

if (++ptime->second == 60)
{
ptime->second = 0;

if (++ptime->minute == 60)
{
ptime->minute = 0;

if (++ptime->hour == 24)
ptime->hour = 0;
}
}
}
</syntaxhighlight>

Die Funktion enthält mehrere indirekte Zugriffe auf die <tt>time</tt>-Struktur, und es wäre günstig, wenn <tt>avr-gcc</tt> indirekte Adressierung für die Zugriffe verwendet: Alle Zugriffe geschehen über den Struktur-Zeiger <tt>ptime</tt>, und ein indirekter Zugriff per <tt>LD</tt>, <tt>LDD</tt>, <tt>ST</tt> oder <tt>STT</tt> kostet 2 Bytes, während die direkten Spreicherzugriffe <tt>LDS</tt> und <tt>STS</tt> jeweils 4 Bytes verbrauchen.

<tt>avr-gcc</tt> erzeugt mit Optimierung auf Größe jedoch folgenden Code:

<syntaxhighlight lang="c">
next_second:
// if (++ptime->second == 60)
lds r24, time
subi r24, -1
sts time, r24
cpi r24, 60
brne .L1
// ptime->second = 0;
sts time, __zero_reg__
// if (++ptime->minute == 60)
lds r24, time+1
subi r24, -1
sts time+1, r24
cpi r24, 60
brne .L1
// ptime->minute = 0;
sts time+1, __zero_reg__
// if (++ptime->hour == 24)
lds r24,time+2
subi r24, -1
sts time+2, r24
cpi r24, 24
brne .L1
// ptime->hour = 0;
sts time+2, __zero_reg__
.L1:
ret
</syntaxhighlight>
D.h. obwohl der C-Code indirekt zugreift, enthält das Compilat direkte Zugriffe und der Code belegt 56 Bytes an Flash. Grund ist, daß der Compiler den Inhalt der Variablen <tt>ptime</tt> kennt und daher die indirekten Struktur-Zugriffe in direkte umwandelt.

Um indirekte Adressierung im erzeugten Code zu erzwingen, kann man die Struktur-Adresse als Parameter übergeben:
<syntaxhighlight lang="c">
void next_second (time_t *ptime)
</syntaxhighlight>
oder – als hässliche Lösung – dem Compiler des Wissen um den Inhalt von <tt>ptime</tt> per Inline-Assembler nehmen:
<syntaxhighlight lang="c">
asm ("" : "+r" (ptime));
</syntaxhighlight>

Dies führt denn zu folgendem Code, der um 25% kleiner ist und nur noch 42 Bytes Flash belegt:
<syntaxhighlight lang="c">
next_second:
// time_t *ptime = &time;
// asm ("" : "+r" (ptime));
ldi r30, lo8(time)
ldi r31, hi8(time)
// if (++ptime->second == 60)
ld r24, Z
subi r24, -1
st Z, r24
cpi r24, 60
brne .L1
// ptime->second = 0;
st Z, __zero_reg__
// if (++ptime->minute == 60)
ldd r24, Z+1
subi r24, -1
std Z+1, r24
cpi r24, 60
brne .L1
// ptime->minute = 0;
std Z+1, __zero_reg__
// if (++ptime->hour == 24)
ldd r24, Z+2
subi r24, -1
std Z+2, r24
cpi r24, 24
brne .L1
// ptime->hour = 0;
std Z+2, __zero_reg__
.L1:
ret
</syntaxhighlight>

Weil AVRs nur zwei Zeiger-Register haben, die über diese Addressierungsart verfügen (Y und Z), ist diese Optimierung nur eingeschränkt anwendbar.

Werden etwa Z oder Y für andere Zwecke benötigt – etwa für Flash-Adressierung per <tt>LPM</tt> oder Y als Frame-Pointer gebraucht – verkleinert sich das Anwendungsfeld noch weiter. Zudem müssen genügend Struktur-Zugriffe nacheinander erfolgen, damit ein positiven Effekt auf die Codegröße zustande kommt. Immerhin muss die Adresse geladen werden, das Zeiger-Register wird belegt und steht nicht für andere Variablen zur Verfügung, und im Falle von Y kommen <tt>PUSH</tt>/<tt>POP</tt> im Prolog/Epilog hinzu. Werden viele unterschiedliche Struktur-Pointer verwendet ("viele" relativ zur Anzahl der verfügbaren Pointer-Registern), kann die Codegröße auch ansteigen.

Direkte Zugriffe sind in jedem Falle schneller, denn direkte und indirekte Zugriffe kosten die gleiche Zeit. Die Indirekten Zugriffe erfordern jedoch die Initialisierung des Zeiger-Registers und evl <tt>PUSH</tt>/<tt>POP</tt>.

=== Multiplikationen mit Konstanten ===

Der Compiler instanziiert sofort eine teure allgemeine Bibliotheksfunktion, auch wenn es anders ginge. Ich hatte eine einzige 32-bit Multiplikation mit 10 drin, die mir ein mulsi3 beschert hat. Mit a = (b<<3) + (b<<1) geht es in dem Fall kürzer. Wie gesagt, map-File beobachten.

;Anmerkung: Variablen als unsigned definieren, dann sollte der Compiler das selbst machen.

;Anmerkung: Auch Schieben ist teuer auf AVR. Schauen wir uns also mal an, was aus folgendem Code wird:

<syntaxhighlight lang="c">
uint32_t foo (uint32_t i)
{
return i*10;
}

uint32_t bar (uint32_t i)
{
return (i << 1) + (i << 3);
}
</syntaxhighlight>

{{Scrollbox|15ex;|
<pre>
00000032 <foo>:
32: 2a e0 ldi r18, 0x0A ; 10
34: 30 e0 ldi r19, 0x00 ; 0
36: 40 e0 ldi r20, 0x00 ; 0
38: 50 e0 ldi r21, 0x00 ; 0
3a: 19 d0 rcall .+50 ; 0x6e <__mulsi3>
3c: 08 95 ret

0000003e <bar>:
3e: 26 2f mov r18, r22
40: 37 2f mov r19, r23
42: 48 2f mov r20, r24
44: 59 2f mov r21, r25
46: 22 0f add r18, r18
48: 33 1f adc r19, r19
4a: 44 1f adc r20, r20
4c: 55 1f adc r21, r21
4e: e3 e0 ldi r30, 0x03 ; 3
50: 66 0f add r22, r22
52: 77 1f adc r23, r23
54: 88 1f adc r24, r24
56: 99 1f adc r25, r25
58: ea 95 dec r30
5a: d1 f7 brne .-12 ; 0x50 <__SREG__+0x11>
5c: 26 0f add r18, r22
5e: 37 1f adc r19, r23
60: 48 1f adc r20, r24
62: 59 1f adc r21, r25
64: 95 2f mov r25, r21
66: 84 2f mov r24, r20
68: 73 2f mov r23, r19
6a: 62 2f mov r22, r18
6c: 08 95 ret

0000006e <__mulsi3>:
6e: ff 27 eor r31, r31
70: ee 27 eor r30, r30
72: bb 27 eor r27, r27
74: aa 27 eor r26, r26

00000076 <__mulsi3_loop>:
76: 60 ff sbrs r22, 0
78: 04 c0 rjmp .+8 ; 0x82 <__mulsi3_skip1>
7a: a2 0f add r26, r18
7c: b3 1f adc r27, r19
7e: e4 1f adc r30, r20
80: f5 1f adc r31, r21

00000082 <__mulsi3_skip1>:
82: 22 0f add r18, r18
84: 33 1f adc r19, r19
86: 44 1f adc r20, r20
88: 55 1f adc r21, r21
8a: 96 95 lsr r25
8c: 87 95 ror r24
8e: 77 95 ror r23
90: 67 95 ror r22
92: 89 f7 brne .-30 ; 0x76 <__mulsi3_loop>
94: 00 97 sbiw r24, 0x00 ; 0
96: 76 07 cpc r23, r22
98: 71 f7 brne .-36 ; 0x76 <__mulsi3_loop>

0000009a <__mulsi3_exit>:
9a: 9f 2f mov r25, r31
9c: 8e 2f mov r24, r30
9e: 7b 2f mov r23, r27
a0: 6a 2f mov r22, r26
a2: 08 95 ret

</pre>
}}

: Der Funktionsaufruf samt Lib-Funktion ist garnicht sooo teuer. Bereits mit zwei Multiplikationen im Programm — auch einer Multiplikation mit einer anderen Konstanten oder einer Variablen — gewinnt die lib-Version, da der Code wiederverwendet wird. Übrigens sind diese Multiplikationsroutinen und auch die in die libgcc enthaltenen Divisionen keine "normalen" Funktionen wie sie von C erzeugt werden. avr-gcc weiß genau, welche Register diese Routinen belegen und welche nicht. Damit ist der Aufruf einer solchen Funktion billiger als ein herkömmlicher Funktionsaufruf, bei dem die Funktion als Blackbox behandelt werden muss, die alle call-clobbered Register zerstört.

=== Alle Variablen nur so breit wie nötig ===

Hatte ich eigentlich schon, nur an einigen wenigen Stellen war ich da etwas nachlässig. Mitunter reicht ein kleinerer Typ doch, wenn man z. B. vorher geeignet skaliert. Am besten nur die skalaren Typen aus <stdint.h> verwenden, das erleichtert auch das Folgende. Bei RAM Knappheit: kann ich Strings sinnvollerweise aus dem RAM ins Flash verbannen? Kann ich es mir leisten mehrere Flag-Variablen in ein Byte zusammenzufassen, auch wenn dann die Zugriffe möglicherweise etwas langsamer werden.

=== Logische Operatoren werden auf int-Größe erweitert ===

Obwohl der AVR ein 8-Bit Controller ist, verlangt der C-Standard, daß ein <tt>int</tt> mindestens 16 Bits groß ist. Wegen den Promotion-Regeln von C werden 8-Bit Operanden in Operationen auf 16 Bits aufgeweitet. Beispiel:

<syntaxhighlight lang="c">
#include <stdint.h>

uint8_t c;

void foo (uint8_t a, uint8_t b)
{
if (a == ~b)
c = 0;
}
</syntaxhighlight>
Den zweiten Operanden mit dem Komplement weitet der Compiler auf 16 Bit auf, wodurch alle high-Bits von <tt>~b</tt> gesetzt werden. Der Compiler erkennt, daß der Vergleich niemals wahr ist und optimiert ihn weg:
<syntaxhighlight lang="c">
foo:
ret
</syntaxhighlight>

Ein Cast verhindert dieses:
<syntaxhighlight lang="c">
void foo (uint8_t a, uint8_t b)
{
if (a == (uint8_t) ~b)
c = 0;
}
</syntaxhighlight>
was übersetzt wird zu:
<syntaxhighlight lang="c">
foo:
// if (a == (uint8_t) ~b)
com r22
cpse r24, r22
rjmp .L1
// c = 0
sts c, __zero_reg__
.L1:
ret

</syntaxhighlight>

;Achtung: Tatsächlich handelt es sich dabei nicht um ein Optimierungsproblem, sondern einen typischen Programmierfehler. Die beiden Varianten sind keineswegs identisch! Bei Variablen vom Typ <tt>uint8_t</tt> ist der Ausdruck <tt>(a == ~b)</tt> immer falsch! Dies unterstreicht mehr als eindringlich, daß eine gute Kenntnis der Programmiersprache das A und O jedes erfolgreichen Programmierers ist. Kenne zuallerst mal deine Programmiersprache - und zwar auch in den intimen Details!

=== Speichern von globalen Flags ===

Oft werden in den Programmen Flags verwendet um beispielsweise eingetroffene Interrupts in der main-Routine auszuwerten. Hierzu wird üblicherweise eine globale Variable verwendet.

Um den Wert dieser Variable abzufragen, muss sie jedoch erst aus dem SRAM in ein Register geladen werden, und kann dann erst auf ihren Status hin überprüft werden. Eine Möglichkeit ist, der globalen Variablen ein einziges Register fest zuzuordnen:
<syntaxhighlight lang="c">
register uint8_t counter8_1 asm("r2");
register uint8_t counter8_2 asm("r3");
register uint16_t counter16_1 asm("r4"); // r4:r5
register uint16_t counter16_2 asm("r6"); // r6:r7
</syntaxhighlight>
siehe auch: http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_regbind

Als Alternative kann man ein nicht verwendetes Register des I/O-Bereichs verwenden. Dabei würde sich z. B. das Register eines zweiten UARTs, oder das EEPROM-Register anbieten, falls diese nicht benötigt werden.

Neuere AVR-Modelle besitzen für diesen Zweck 3 frei verwendbare Bytes im bitadressierbaren I/O-Bereich: GPIOR0-2, die neueren ATXmegas haben sogar 16 Stück!

{{Warnung|
;Warnung: Dieses Vorgehen verändert das ABI! Um dieses Feature fehlerfrei anzuwenden, ist einiges an Wissen über die Interna von GCC notwendig. Auch ein korrekt funktionierendes Programm ist keine Garantie dafür, daß die globalen Register fehlerfrei implementiert wurden. Unter Umständen bringen erst spätere Codeänderungen/-erweiterung den Fehler zum Vorschein, und weil der Fehler vorher nicht akut war, sucht man sich den Wolf an der falschen Stelle im Code anstatt bei der globalen Registern. Siehe auch [[Globale Register]].}}

=== Puffern von volatile-Variablen ===

Der Compiler behandelt volatile-Variablen bei mehreren Manipulationen wie heiße Kartoffeln. Für jeden einzelnen Vorgang wiederholt sich das Spiel:

* aus dem Speicher holen
* bearbeiten
* zurückspeichern

Unter Umständen ist dieses Verhalten unsinnig. Ein Minimalbeispiel:

<syntaxhighlight lang="c">
volatile char var;

ISR()
{
var++;

if (var > 100)
var = 0;
}

void main (void)
{
while (1)
printf (var);
}
</syntaxhighlight>

Hier wird '''var''' pro [[ISR]]-Ausführung zwei mal aus dem RAM geholt und zurückgeschrieben. Das ist überflüssig, weil die Interruptroutine nicht unterbrochen werden kann. Aus Sicht der ISR bräuchte man eigentlich kein volatile, kann es aber wegen des Zugriffs aus main heraus nicht weglassen. Eine Lösung findet sich im folgenden Schnipsel:

<syntaxhighlight lang="c">
volatile char var;

ISR()
{
char temp = var;

if (++temp > 100)
temp=0;

var = temp;
}

void main (void)
{
while (1)
printf (var);
}
</syntaxhighlight>

Hier wird die globale Variable '''var''' in der lokalen Variable '''temp''' gepuffert. Ein Nachteil durch das Anlegen von '''temp''' ergibt sich nicht, da das dafür verwendete Register für die Manipulation sowieso benötigt wird.

Wie alle Optimierungen kann dieses Vorgehen auch nach hinten losgehen: Wenn Laden und Zurückspeichern von '''var''' weit auseinanderliegen (extrem lange ISR), müllt man sich die Register zu. Im schlimmsten Fall wird '''temp''' sogar zwischenzeitlich auf dem Stack ausgelagert.

=== Schleifen ===

Bei Schleifen, die eine bestimmte Anzahl an Durchläufen ausgeführt werden sollen, ist es besser den Schleifenzähler vorher auf einen Wert zu setzen, und am Ende einer Do-While Schleife diesen zu dekrementieren.
So beschränkt sich die Sprungbedingung auf ein brne (branch if not equal).

Beispiel:
<syntaxhighlight lang="c">
uint8_t counter;
counter = 100;
do
{
// mach irgendetwas
} while (--counter);
</syntaxhighlight>

Achtung: Derartige Optimierungen sind meistens zweifelhaft und sehr Compilerabhängig. Compiler betreiben aufwendige Code- und Datenflussanalysen, in denen sie viele Dinge ins Kalkül ziehen, die ein menschlicher Programmierer im Regelfall nicht mehr überblicken kann. Von einem ordentlichen Compiler kann erwartet werden, dass er derartige Umstellungen (sofern sie möglich sind) in Eigenregie erledigt. Auch wenn es einzelne Compiler bzw. Compilerversionen gibt, in denen ein manueller Umbau einer derartigen Schleife tatsächlich eine Verbesserung bringt, sollte man immer im Hinterkopf behalten, dass sich in der nächsten Compilerversion alles umdrehen kann. Im Zweifelsfall lieber die Schleifenvariante benutzen, die der Situation angemessen ist und die den gewünschten Vorgang am klarsten beschreibt. Wenn dieser Vorgang im weitesten Sinne einen Countdown darstellt, dann ist natürlich nichts gegen eine derartige Schleifenkonstruktion einzuwenden.

=== Schiebeoperationen ===

Oft benötigt man Schiebeoperationen, um Daten Bit für Bit zu [[Bitmanipulation | verarbeiten]], z.B. für [http://www.mikrocontroller.net/articles/AVR-Tutorial:_Schieberegister Soft]-[[SPI]]. Hier empfiehlt es sich DRINGEND, möglichst nur Schiebeoperationen mit konstanten Verschiebungszähler durchzuführen, diese sind auf dem AVR deutlich schneller als Schiebeoperationen mit Variablen, welche meist durch mehrfache Funktionsaufrufe mit Scheifen etc. gelöst werden. Dabei verwendet man oft konstante Bitmasken, um die einzelnen Bits nacheinander zu maskieren.

Noch schneller geht das Schieben von Konstanten um einen konstanten Wert, denn das macht der Compiler bei eingeschalteter Optimierung noch während des Compilierens. Gerade für schnelle IO-Operationen kommt dann meist nur ein einziger ASM-Befehl heraus (sbi, cbi).

Ebenso ist es wenig empfehlenswert, 32 oder gar 64 Bit Datentypen zu schieben, das dauert sehr lange. Besser ist es, die Daten als Array von 8 Bit Werten zu handhaben und diese zu schieben, das ist meist deutlich schneller. Gute Beispiele findet man [http://www.mikrocontroller.net/topic/179566#1729219 hier] und [http://www.mikrocontroller.net/topic/169509#1631439 hier].

<syntaxhighlight lang="c">
#define DATAPORT PORTD
#define IO_BIT PD4

uint8_t a, b, i;

i=5
a = b << i; // variabler Verschiebewert, langsam
a = b << 5; // konstanter Verschiebewert, schnell

DATAPORT |= (1<<IO_BIT); // alles Konstanten, sehr schnell
</syntaxhighlight>

==Optimierung der Ausführungsgeschwindigkeit==

Hierzu gibt es schon eine Application-Note von Atmel. Diese AppNote bezieht sich auf den IAR-Compiler. Die darin genannten "Optimierungen" sind für avr-gcc größtenteils obsolet oder bleiben bestenfalls ohne Effekt.

Weblinks:
* [http://www.atmel.com/dyn/resources/prod_documents/doc1497.pdf AVR035]: Efficient C Coding for AVR
* [http://en.wikipedia.org/wiki/Program_optimization Program optimization] auf Wikipedia, engl.
* [http://bleaklow.com/2012/06/20/sensor_smoothing_and_optimised_maths_on_the_arduino.html Sensor smoothing and optimised maths on the Arduino] - Multiplikation vs. Division

== Fußnoten ==
<references/>

== Links ==
[http://www.atmel.com/Images/doc8453.pdf Atmel AVR4027]: Tips and Tricks to Optimize Your C Code for 8-bit AVR Microcontrollers ([http://www.atmel.com/Images/AVR4027.zip Beispiel-Code])

[[Category:avr-gcc]]

Digitale Signalverarbeitung

2015-12-13T08:32:04Z

Maybee:

== Begriffsdefinition ==

Als 'Digitale Signalverarbeitung' bezeichnet man allgemein die Analyse und Weiterverarbeitung von digitalisierten Analogsignalen und nicht etwa (nur) die Rechnung mit binären Signalen, wenngleich die Berechnung praktisch letztlich im Binärsystem erfolgt.

== Anwendungsgebiete ==

* Modulation/Demodulation zur Datenübertragung (z. B. Telefonmodem, DSL, GSM) - "Software Defined Radio" (SDR)
* Multimediacodierung (MP3, H.264, JPEG)
* Bildverarbeitung (Bildverbesserung)
* Mustererkennung, Objekterkennung, Objektverfolgung
* Audiosignalverarbeitung
* Echo- und Störgeräuschunterdrückung bei Telefonen, Sprechgarnituren (Headsets) und Hörgeräten

== Algorithmen ==

Bei der Verarbeitung von Signalen kommen im Grunde bei allen Anwendungen die selben Algorithmen zum Einsatz, von denen die wichtigsten im Folgenden vorgestellt werden.

=== FIR- und IIR-Filter ===

Die häufigste Aufgabe in der DSV ist das Filtern, das heißt, bestimmte Frequenzanteile zu unterdrücken, zu verstärken oder in der Phase zu verschieben. Man kann grundsätzlich zwischen zwei Filterarten unterscheiden:

Bei den sogenannten '''FIR-Filtern'''n ('''F'''inite '''I'''mpulse '''R'''esponse) wird jeder Ausgangswert aus der Summe einer begrenzten Anzahl unterschiedlich gewichteter Eingangswerte zusammengesetzt, die dazu in Schieberegistern vorgehalten werden. Dabei bezeichnet man die maximale Anzahl an Werten, die bei der Berechnung berücksichtigt werden, als '''Ordnung''' oder auch als Filtertiefe. Je höher diese Ordnungszahl, desto besser nähern sich die Eigenschaften des realen Filters bez. ripple, Steilheit und z.B. Dämpfung dem des theoretischen Ideals an, desto höher ist aber auch der Rechenaufwand.

Werden bei FIR-Filtern zur Bildung des Ausgangswertes zum Zielzeitpunkt nur zurückliegende Werte verwendet, so handelt es sich um ein "look back" - Filter. Dieses ist typisch für real time Anwendungen. Werden aber auch Werte verwendet, die nach dem eigentlichen Bezugzeitpunkt liegen, spricht man von einem look ahead-Filter. Dieses kann naturgemäß nicht in Echtzeit angewendet werden, bzw die Ausgabezeitpunkte müssen um mindestens um die halbe Filtertiefe verzögert werden, womit ein virtueller Bezugspunkt entsteht.

==== Merkmale von FIR-Filtern ====
* immer stabil
* linearer Phasengang -> keine Phasenverzerrungen
* Ordnungen oft im zwei- bis dreistelligen Bereich

==== Beispiel ====
Seien D(0), D(1) ... D(t) die eingehenden Daten, so wäre Y(t) = 1/k * (D(t) + D(t-1) + D(t-2) + ... + D(t-k)) ein einfaches FIR-Filter der Ordnung "k", das als gleitender Mittelwert bezeichnet wird.

Im Gegensatz zu den FIR-Filtern werden bei den sogenannten '''IIR-Filter'''n ('''I'''nfinite '''I'''mpulse '''R'''esponse) formell alle früheren '''Eingangs'''werte in die Berechnung des aktuellen Ausgangswertes mit einbezogen. Dies wird dadurch bewerkstelligt, dass mindestens ein Informationspeicher (entspricht in der Physik einem Energiespeicher) existiert, der mit in die Rechnung einfließt. Im einfachsten Fall ist der Speicher der Ausgangswert selbst. Wie man sich leicht vorstellen kann, kann dadurch die Antwort auf einen Eingangsimpuls theoretisch unendlich lang werden, was die Einordnung dieser Filter in die Gruppe mit unendlicher Antwort erklärt.

====Merkmale von IIR-Filtern====
* durch Rundungsfehler kann das [[Filter]] instabil werden -> "Aufschaukeln" durch Rückkopplung -> schwierigere Realisierung
* kein linearer Phasengang -> verschiedene Frequenzanteile werden durch den Filter unterschiedlich lange verzögert -> "Verzerrung"
* einziger Vorteil gegenüber FIR: Um einen gewünschten Frequenzgang zu erzielen, ist eine sehr viel niedrigere Ordnung ausreichend -> weniger Rechenaufwand
* Ordnung üblicherweise < 10

==== Beispiel====
Seien D(0), D(1) ... D(t) wieder die eingehenden Daten, wie oben und Y(t-1) der um einen Berechnungsschritt zeitlich verzögerte Wert des Filterausgangswertes Y(t), dann wäre Y(t) = Y(t-1) * (1-k) + D(t) * k ein IIR-Filter erster Ordnung, wobei 1/k die Dämpfung und damit die Grenzfrequenz des Filters bestimmt. Das Verhalten dieses Filters entspricht dem einer Kondensatorladekurve.

Viele nützliche Informationen zur Realisierung gibt es im [http://www.dspguru.com/dsp/faqs/ FIR- und IIR-FAQ auf dspguru.com] (der dort erwähnte Sourcecode FirAlgs.c kann [[Media:FirAlgs.c|hier]] direkt heruntergeladen werden).

'''Berechnungssoftware''':
* [http://www.filter-solutions.com/digital.html Beschreibung der Digitalfiltertypen], [http://www.nuhertz.com/download.html hier kostenlose Testversion Filter Free]

=== DFT/FFT und andere Transformationen ===

Die [[FFT]] (Fast Fourier Transform) ist ein schneller Algorithmus zur Berechnung der DFT (Discrete Fourier Transform). Damit bezeichnet man die Transformation eines Zeitsignals (= eine Abfolge von Samples) in den Frequenzbereich (= Frequenzbestandteile des Signals). Die Transformation kann theoretisch auch ohne Verlust umgekehrt durchgeführt werden, also vom Frequenz- in den Zeitbereich (Inverse Discrete Fourier Transform, IDFT). Eine DFT wird praktisch immer mit dem FFT-Algorithmus realisiert, weshalb die Bezeichnungen oft FFT/DFT oft gleichwertig verwendet werden.

Die offensichtlichste Anwendung der FFT ist die Darstellung des Frequenzspektrums eines Signals. Beispiel:

Ein Audiosignal wird mit einer Frequenz von 44,1 kHz abgetastet und mit den erhaltenen Daten eine DFT mit 512 Punkten durchgeführt. Man erhält ein Amplitudenspektrum mit 512 Frequenzwerten von 0 bis 511, wobei die Werte 0 bis 255 zu denen der oberen Hälfte spiegelsymmetrisch sind. Bei der o.g. Abtastfrequenz ergibt sich nach Nyquist ein Frequenzbereich von 0 bis 22,05 kHz, mit einer Auflösung von 44100/512 = 86,13 Hz. Dabei repräsentiert die erste Frequenz 0, den Bereich von 0 Hz bis 86,13 Hz, u.s.w. - die letzte Frequenz 255 den Bereich von 21963,87 bis 22050 Hz.

Die Spektralanalyse ist jedoch nur ein kleiner Teil der Anwendungsmöglichkeiten. Viele Verarbeitungen lassen sich im Frequenzbereich einfacher durchführen als im Zeitbereich, z. B. Korrelationen oder sehr lange FIR-Filter. Das zu verarbeitende Signal wird dazu in den Frequenzbereich transformiert, dort manipuliert, und wieder in den Zeitbereich zurücktransformiert. Das klingt vielleicht umständlich, kann aber in der Praxis sehr viel schneller sein als eine Realisierung im Zeitbereich.

* [http://www.mikrocontroller.net/topic/25095 Diskussion: FFT auf dem AVR]
* [http://sourceforge.net/projects/kissfft/ Kiss FFT] - einfache FFT-Bibliothek, in C, Floating- und Fixed Point, BSD-Lizenz, geeignet für Mikrocontroller
* [http://www.fftw.org/ FFTW] - '''die''' Floating Point FFT-Bibliothek für PCs, GPL-Lizenz
*[http://www.sprut.de/electronic/pic/16bit/dsp/fft/fft.htm FFT - verständlich auch für Nichtakademiker (Deutsch)]
* [http://www.science.smith.edu/departments/Physics/fstaff/gfelder/ffteasy/ ffteasy - Einfache Routinen zur FFT]

Weitere wichtige Transformationen sind z. B. die in der Bildcodierung (JPEG) verwendete DCT (Discrete Cosine Transform), und die WHT (Welsh-Hadamard-Transformation). Im Gegensatz zur DFT wird das Signal nicht mehr in den Frequenzbereich transformiert, sondern in einen nicht mehr ganz so anschaulichen Transformationsbereich. Der Sinn der Transformation ist z.B. bei der Bildkompression, dass die Signalinformation im Transformationsbereich in nur wenigen Koeffizienten konzentriert ist, und sich somit effizienter codieren lässt.

==== Goertzel-Algorithmus ====

Liegt das Interesse bei der Berechnung einer DFT / FFT nur bei wenigen bestimmten Frequenz-Linien, so gibt es eine weniger rechenaufwendige Alternative mit diesem Algorithmus. Die Grenze, ab der Goertzel-Algo nicht mehr effektiv genug ist, liegt grob bei etwa 15% der Spektralfrequenzen.

Das typische Anwendungsgebiet sind DTMF-Dekoder in Software.
Hierfür sind sogar die üblichen 8-bit-AVR-Controller ausreichend schnell.

=== Signalerzeugung ===

Für die Korrelation von Eingangssignalen mit zuvor ausgesendeten oder bekannten Signalformen zwecks Mustererkennung müssen oftmals eigene Signale generiert werden.

Rechteck-, Sägezahn- und Dreieckssignale lassen sich mit einfachen Zählern realisieren.

Möchte man Sinus- oder beliebige andere Signalformen erzeugen, bietet es sich an, vorausberechnete Funktionswerte im Speicher abzulegen und der Reihe nach auszugeben. Eine variable Frequenzeinstellung kann man durch die Methode der Direkten Digitalen Synthese ('''DDS''') realisieren.

* [[Digitaler Funktionsgenerator]] - ausführliche Erklärung des Verfahrens im PDF, Beispielcode für AVR
* http://www.myplace.nu/avr/minidds/ - noch ein AVR-Projekt
* http://www.hit.bme.hu/~papay/sci/DDS/start.htm - noch eine Erklärung
* [http://www.analog.com/static/imported-files/tutorials/450968421DDS_Tutorial_rev12-2-99.pdf Aplication Note von Analog Devices, DDS]
* http://www.mikrocontroller.net/topic/324429 - Sinusschwingung mit IIR-Filter

Eine weitere Methode zur Realisierung von (mehr oder weniger beliebigen) Funktionen ist die '''Polynomapproximation'''. Dabei nähert man die zu erzeugende Funktion durch ein Polynom an und verwendet das Horner-Schema, um die einzelnen Funktionswerte zu berechnen. Für ein Polynom der Ordnung N benötigt man damit pro Wert N+1 Multiplikationen (N ist üblicherweise <= 10).

== Software ==

Zur Entwicklung von Signalverarbeitungsverfahren gibt es eine ganze Reihe von Programmen. Neben kleinen Werkzeugen für den Filterentwurf und spezialisierten Bibliotheken zum Einbinden in eigene Programme existieren mehrere Mathematikprogramme, mit denen sich Signale verarbeiten und darstellen lassen. Die drei wichtigsten sind Matlab, Octave und Scilab.

=== MATLAB ===

MATLAB ist das Standardprogramm für numerische Mathematik. In der digitalen Signalverarbeitung wird es häufig verwendet, um einen Algorithmus vor der Umsetzung in C-Code oder auf einen DSP zu entwickeln und zu testen. Zum schon recht hohen Preis der Grundsoftware muss man noch einige hundert Euro für diverse Toolboxes einplanen (Signal Processing, Filter Design, Image Processing). Die [http://www.mikrocontroller.net/link/isbn/0979223903 Studentenversion] kostet ca. 80 Euro (die Signal Processing Toolbox und ein paar andere sind bereits enthalten).

MATLAB ist für Windows, Linux, Mac OS X, Solaris und HP-UX erhältlich.

'''Weblinks''':
* http://users.ece.gatech.edu/%7Ebonnie/book/TUTORIAL/tutorial.html - Englischsprachiges MATLAB-Tutorial
* http://www.mathworks.com/access/helpdesk/help/techdoc/matlab.shtml - MATLAB-Referenz
* http://www.eng.auburn.edu/~sjreeves/Classes/DSP/DSP.html - MATLAB for DSP (allgemeine Tipps und Hinweise)

=== GNU Octave ===

GNU Octave ist eine (zum größten Teil zu Matlab (R) kompatible) höhere Programmiersprache, die hauptsächlich für numerische Berechnungen gedacht ist. Sie stellt eine komfortable Kommandozeilenschnittstelle zur numerischen Lösung linearer und nichtlinearer Probleme bereit. Durch den hohen Grad an Matlab-Kompatibilität kann man problemlos die Matlab-Online-Hilfe und Matlab-Einführungen zum Lernen verwenden.

Grundsätzlich ist Octave ein reines Kommandozeilenprogramm es wird aber aktiv an einer GUI auf Basis von Qt entwickelt (siehe http://wiki.octave.org/FAQ#Is_there_a_GUI_for_Octave.3F).

Ideone.com bietet seit einiger Zeit einen online-Interpreter auch für Octave an. Hier kann man die Sprache ohne Installation kurz antesten: [http://ideone.com/E5Cxz9 Sombrero und "Hallo Mikrocontroller Leser" Beispiel]

Zum Plotten unter GNU/Linux kann wahlweise gnuplot oder das neue FLTK backend verwendet werden. Unter Windows stehen noch weitere backends wie wxWidgets zur Verfügung.

Octave-Forge beheimatet Pakete, die (noch) nicht in "octave core" aufgenommen wurden. Hier sind auch viele Funktionen der Matlab-Toolboxes enthalten (z.B. Filterdesign, Signalverarbeitung).

Octave kann unter GNU/Linux oder *BSD über den jeweiligen Paketmanager (wie z.B. apt-get, aptitude, synaptics in Ubuntu oder Debian) installiert werden. Für Windows stehen vorkompilierte Pakete mit MinGW, MSVC oder für cygwin zur Verfügung. Für MacOS gibt es Möglichkeiten mit Fink, MacPorts und Homebrew zu installieren.
[http://wiki.octave.org/Main_Page#Installation_Instructions_for_Windows.2C_MacOS_X_and_GNU.2FLinux Octave Wiki Installationsanleitung Windows, MacOS X und GNU/Linux]

'''Weblinks''':
* http://www.gnu.org/software/octave/ Projektseite
* http://wiki.octave.org/Main_Page Wiki, u.A. mit Installationsanleitungen
* http://octave.sourceforge.net/ - Octave-Forge Zusatzpakete

=== Scilab / Scicos ===

Auch das Open-Source-Programmpaket Scilab / Scicos, ähnlich leistungsfähig wie Matlab und seine Zusatzmodule, ist kostenlos und im Quelltext erhältlich. Während die Grundsyntax (Kontrollstrukturen, Ausdrücke) weitgehend Matlab-kompatibel ist, gibt es bei den Funktionen z.T. deutliche Abweichungen. Dafür bietet Scilab / Scicos verglichen mit Octave umfangreichere Möglichkeiten zur grafischen Darstellung, die über das 2D- und 3D-Plotten von Funktionen weit hinausgehen, z. B. lassen sich Linien, Kreise usw. zeichnen.

Scilab / Scicos läuft unter Windows, Linux/Unix und Mac OS X. Für die wichtigsten Linux-Distributionen sind fertige, komplette Binärpakete (RPM, ...) zur einfachen Installation frei verfügbar. Für Windows gibt es ebenfalls ein einfach zu installierendes Komplettpaket.

'''Weblinks''':
* [http://www.scilab.org/ Scilab Homepage (Universelles Wissenschaftlich-Technisches Mathematik-Paket)]
* [http://www.scicos.org/ Scicos Homepage (Modellations- und Simulations-Paket für Scilab, ist im Scilab-Download enthalten)]
* [http://www-rocq.inria.fr/scicos/scicosmodnum.html ModNum Digital communication toolbox zu Scicos]
* [http://www.scilab.org/publications/index_publications.php?page=freebooks Übersicht zur Literatur: Webtexte, Bücher und Zeitschriftenartikel]
'''Bücher''':
* [http://www.scicos.org/book.html Modeling and Simulation in Scilab/Scicos, (für Version 3.0, aktuell ist Version 4.1.2)]
'''Tutorials''':
* [http://wiki.scilab.org/Tutorials?action=AttachFile&do=get&target=signal.pdf Signal Processing with Scilab (1998)], [http://wuarchive.wustl.edu/pub/aminet/misc/math/scilab-doc.lha Beispielfiles dazu lha-gepackt (1996)] [http://aminet.net/package/misc/math/scilab-doc oder hier], [http://viewvc.scilab.org/bin/cgi/viewvc.cgi/trunk/scilab_doc/signal/Nfigs_source/ hier auch einzeln erhältlich]
* [http://www.scilab.org/publications/delicado/scilab.pdf DSP-Tutorial in spanisch, teilweise aus dem englischen Tutorial entnommen]
* [http://www.neurotraces.com/scilab/scilab2/index.html Treatment of neurophysiological signals using Scilab, HTML-Texte mit Kapiteln zu Filtern, FFT usw.]
* [http://www.scilab.org/publications/TELECOM/ComNumSc.zip Digital-Kommunikation - französisches Tutorial, gezipptes Postscript]
* [http://www.mate.tue.nl/mate/pdfs/6827.pdf Beispielprojekt mit Vergleich SciCos und SciLab]

== Hardware ==

Ein DSP ('''D'''igital '''S'''ignal '''P'''rocessor) ist eine spezielle CPU mit einem auf die Verarbeitung von Signalen optimierten Kern und Befehlssatz. Unterschieden wird hauptsächlich zwischen Gleitkomma- und Festkomma-DSPs.

Charakteristisches Merkmal vieler DSPs ist eine VLIW-Architektur ('''V'''ery '''L'''ong '''I'''nstruction '''W'''ord). Dabei werden Anweisungen für mehrere parallele Ausführungseinheiten (Multiplizierer/Addierer/Akkumulatoren) und mehrere Lade-/Speicherbefehle in einem einzigen, langen Befehlswort kodiert, und in einem Takt ausgeführt. Dazu kommen häufig mehrere gleichzeitig adressierbare Speicherbänke, Unterstützung für Ringpuffer, Schleifen ohne Sprung-Overhead, Bit-Reverse-Adressierung (wichtig für FFT) und Arithmetik mit Sättigungs- statt Überlaufverhalten (wichtig für die Realisierung von IIR-Filtern).

Die Grenzen zwischen Mikrocontrollern und DSPs sind mittlerweile schon etwas verschwommen. Viele Mikrocontroller sind mit zusätzlichen DSP-Funktionen ausgestattet ([[PICCOLO]], [[dsPIC]], [[ARM#ARM_Cortex_M4|ARM Cortex M4]]), während DSPs zunehmend in Richtung der Aufgabenbereiche eines Mikrocontrollers oder Allround-Prozessors vordringen und immer öfter um Unterstützung für Betriebssysteme (MMU) oder I/O-Funktionen wie Ethernet oder USB erweitert werden ([[Blackfin]]).

Eine noch größere DSP-Rechenleistung kann mit programmierbaren Logikbausteinen ('''[[FPGA]]'''s) erzielt werden, da die Anzahl gleichzeitig ausführbarer Rechenoperationen nur durch die Größe des FPGAs begrenzt wird. Nachteilig sind die gegenüber DSPs um ein vielfaches höheren Kosten, höherer Stromverbrauch und höherer Entwicklungsaufwand, weshalb FPGAs für Signalverarbeitung nur in sehr speziellen Anwendungen verwendet werden.

Aktuelle '''PC-Prozessoren''' sind sehr gut für Gleitkomma-Signalverarbeitung geeignet. Für Aufgaben bei denen sehr viele Daten parallel verarbeitet werden können kann die Leistungsfähigkeit mit GPUs weiter gesteigert werden (CUDA, OpenCL). Wenn keine besonderen Anforderungen an Echtzeitfähigkeit, Strom- oder Platzbedarf gestellt werden, hat ein normaler PC mit Abstand das beste Preis/Leistungsverhältnis. Der erste Schritt bei einem DSP-Projekt sollte somit eine Implementierung auf dem PC sein. Es macht wenig Sinn, ein Eval-Board für einen Signalprozessor zu kaufen und einfach loszulegen.

=== Fest- oder Gleitkomma? ===

Signalverarbeitung auf einem Gleitkomma- (Floating-Point-) Rechner ist grundsätzlich einfacher als auf einem Festkomma- (Fixed-Point-) Rechner. Da die Ungenauigkeiten bei der Rechnung mit Floating-Point-Zahlen in vielen Fällen vernachlässigbar sind, kann man einen Algorithmus i.d.R. 1:1 in Programmcode umsetzen. Hat man nur Festkomma-Rechenoperationen zur Verfügung wird es etwas ungemütlich. Man muss sich Gedanken um die Skalierung der Daten, die Reihenfolge von Rechenoperationen, Überläufe, Rundungsrauschen usw. machen. Da Gleitkomma-DSPs allerdings teurer sind und mehr Strom verbrauchen, werden für Massenprodukte fast ausschließlich Festkomma-DSPs bzw. ASICs mit Festkomma-Rechenwerken verwendet.

=== TI C2000 ===

Eine komplette 32-bit DSC Controller Familie vom low-cost ([http://www.ti.com/corp/docs/landing/f280xx-piccolo/index.htm PICCOLO]) bis high-end Controller mit FPU ([http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=mcu&sectionId=95&tabId=2108&familyId=1414&paramCriteria=no TMS320F28335]).
Die Peripherie umfasst Mehrkanal A/D Wandler mit 12-bit Aufloesung und bis zu 4 Megasamples Abtastrate. Die PWMs haben einen hochauflösenden Modus, der bis zu 150ps auflösen kann. Als Interface stehen CAN, I2C, schnelle generelle serielle Ports und Quadratureingänge für Drehgeber zur Verfügung.

=== TI C5000 ===

DSP für batteriebetriebene Anwendungen. Die gesamte Architektur wurde auf Stromverbrauch optimiert. Dazu werden spezielle Werkzeuge zur Verfügung gestellt, die zur Anwendung passende Optimierungslösungen generiert. [[TMS320VC5505 eZDSP USB Stick‎]] mit IDE als preisgünstiges Entwicklungssystem ( < 50€)

=== TI C6000 ===

DSP-Familie vom Marktführer Texas Instruments enthält sowohl Fest- als auch Gleitkomma-DSPs.

=== TI DM6400 (DaVinci) ===

DSP für Videoanwendungen. Einige Derivate enthalten auch einen ARM9 als Co-Prozessor. Diese Familie wird unter dem Namen [http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=dsp&sectionId=2&tabId=1852&familyId=1300 DaVinci] vermarktet.

=== TI OMAP ===

Prozessor für mobile Geräte, enthält einen ARM-Kern und einen C6000-DSP. Ein interessantes und mit $149 sehr preisgünstiges Evalboard ist das [http://www.beagleboard.org Beagle Board]. Ein kostenloser Assembler für den DSP ist verfügbar.

=== SHARC/TigerSHARC ===

32-Bit-Gleitkomma-DSP von Analog Devices.

=== Blackfin ===

Der Blackfin ist ein 16/32-Bit-Festkomma-DSP von Analog Devices. Im Gegensatz zu den 16-bittigen Vorgängern ADSP-21xx, die häufig als Co-Prozessoren zur Signalverarbeitung zusammen mit einem Mikrocontroller verwendet werden, geht der Blackfin schon weit in den Einsatzbereich eines Allround-Prozessors hinein. So gibt es z. B. einen Linux-Port für Blackfin, Eval-Boards mit Ethernet, CAN, USB und vielen MB SDRAM. Dank der verbesserten Stromsparfunktionen der BF52x-Reihe ist diese eher neue Architektur vermehrt in mobilen Geräten (Kameras, Mediaplayer, etc.) anzutreffen.

Wichtig für die Entwicklung ist zu wissen:

* Keine Fließkomma-Unterstützung in Hardware
* Keine MMU, keine Unterstützung für virtuellen Speicher (kein Unix fork(), etc.)

Unterstützte Entwicklungswerkzeuge:

* Visual DSP++: Hauseigenes Entwicklungswerkzeug von Analog Devices, kommerziell
* GCC: Freie GNU-Umgebung mit Assembler, Compiler, Linker, Debugger
* Eclipse für uClinux-Entwicklung wie auch 'nackt' ohne OS

Aufgrund der ausgereiften GNU-Toolchain ist der Blackfin eine der kostengünstigsten Plattformen für die Entwicklung. Die Werkzeuge laufen sowohl unter Windows32 als auch Linux, bevorzugt wird jedoch Linux eingesetzt. Für die Kernel-Entwicklung ist Linux unabdingbar.
Dank offener JTAG-Spezifikation existieren einige Werkzeuge von Drittherstellern zum Hardware-Debugging (In-Circuit Emulation) und zur Programmierung:

* [http://www.section5.ch/icebear ICEbear] JTAG: schneller USB->JTAG adapter
* [http://www.ronetix.at/ PEEDI] High end JTAG, Ethernet
* [http://www.bluetechnix.at/rainbow2006/site/blackfin_family/__dev_tools/__gnice_jtag/409/gnice_jtag.aspx gnICE von Bluetechnix]
* [http://www.analog.com/en/processors-dsp/blackfin/emulator-100/processors/product.html JTAG-Adapter von Analog Devices]

Beide Werkzeuge arbeiten auch mit ARM-Prozessoren.

Weitere Links:

* [http://www.bluetechnix.com/rainbow2006/default.aspx Bluetechnix Core-Module]
* [http://www.analog.com/blackfin Herstellerwebsite]
* [http://blackfin.uclinux.org/ uClinux Port und GNU toolchain]

=== dsPIC ===

Der [[dsPIC]] ist ein kleiner 16-Bit-Mikrocontroller mit DSP-Funktionen. Mit dem klassischen 8-Bit-PIC hat er außer dem Namen nichts gemeinsam.

Er basiert auf der modernen RISC-Architektur des PIC24 und bietet zusätzlich 40-Bit-Register und spezielle Befehle für DSP-Anwendungen. Der derzeit schnellste dsPIC33E arbeitet mit bis zu 70MIPS. dsPIC33 gibt es auch im DIL28-Gehäuse.

Ein kostenloser C-Compiler (C30) und eine DSP-Bibliothek werden von Microchip angeboten. Dabei handelt es sich um eine "Light"-Version des kommerziellen C30, bei dem nur eine Optimierungsstufe freigeschaltet ist, aber ansonsten keine Einschränkungen (Codegröße o.ä.) bestehen.

=== Cortex M4 ===

Von mehreren Herstellern gibt es Mikrocontroller mit [[ARM#ARM_Cortex_M4|ARM Cortex M4]]-Kern, welcher DSP-Funktionen wie single-cycle 32 Bit MAC (Multiply-ACcumulate), Addition mit Sättigungsverhalten [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/CHDBHGFC.html], SIMD-Befehle, und bei manchen Exemplaren eine FPU [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/CHDBHGFC.html] beinhaltet. Der große Vorteil gegenüber "echten" DSPs ist, dass für ARM zahlreiche Entwicklungsumgebungen frei verfügbar sind, und man sich nicht an einen bestimmten Hersteller und seine Entwicklungstools bindet. Mit CMSIS-DSP stellt ARM eine Bibliothek mit DSP-Funktionen (Vektoroperationen, FFT, etc.) zur Verfügung [http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php].

=== TriCore ===

Der '''TriCore''' von Infineon ist ein 32-Bit-Mikrocontroller mit DSP-Funktionen, mit derzeitigem Schwerpunkt im Bereich der High Performance Embedded Real-Time Systems für Industrie- und Automobilanwendungen (Beispiele: Motorsteuerungen, Servomotoren, Solarinverter, Multi-Axis-Conrol)

* [http://www.infineon.com/cgi-bin/ifx/portal/ep/channelView.do?channelId=-78991&channelPage=%2Fep%2Fchannel%2FleafNote.jsp&pageTypeId=17099 Übersicht über die '''TriCore''' Produktfamilie]

=== Bezugsquellen für Starterkits/Evalboards ===

* http://www.spectrumdigital.com - große Auswahl an Starterkits mit TI-DSPs, ab $300
* http://www.bluetechnix.com - Blackfin-Module ab € 150
* http://www.zbrain.ch/ - Blackfin-Modul, Preis: ?
* http://www.danvillesignal.com/ - ADSP-218x-Boards ab $200, Sharc-Boards ab $400
* http://docs.blackfin.uclinux.org/doku.php?id=buy_stuff - Blackfin BF533 STAMP $170 (keine analogen Schnittstellen, aber über Pfostenstecker leicht zu erweitern)
* http://www.sundance.com - High-End-Module mit TI C6000
* http://www.spectrumsignal.com/ - TMS320 und SHARC
* http://www.pentek.com/dspcentral/ - TMS430 und PowerPC
* http://www.bittware.com/ - SHARC und TigerSHARC
* http://www.hunteng.co.uk/ - C6000
* http://www.kanecomputing.co.uk
* http://www.dsp-systeme.net - DSP-Module mit DSP von TI und ADI
* http://search.digikey.com/scripts/DkSearch/dksus.dll?lang=de&site=DE&WT.z_homepage_link=hp_go_button&KeyWords=TMDX5505EZDSP&x=22&y=22 eZDSP USB Stick , <50€
* http://www.ehitex.de/artikel.php?xPD=131_132&kat_name= - Infineon TriCore Starter Kits

== Weitere Infos==

===Literatur ===
* Oppenheim, Schaefer: "Discrete Time Signal Processing", ISBN 0131988425
* Proakis: "Digital Signal Processing", ISBN 0131873741
* Lyons: "Understanding Digital Signal Processing", ISBN 0131089897
* Smith: "The Scientist and Engineer's Guide to Digital Signal Processing", ISBN 075067444X (unter http://dspguide.com/ als PDF verfügbar)
* Sanjit K. Mitra: "Handbook for Digital Signal Processing" (1993,1312 Seiten), ISBN 0471619957

=== Foren ===
* [http://www.mikrocontroller.net/forum/list-10-1.html DSP-Forum auf mikrocontroller.net (deutsch)]
* [http://groups.google.de/group/comp.dsp Newsgroup comp.dsp (Englisch)]
* [http://www.dsprelated.com/groups.php Discussion Groups (Englisch)]

=== Webseiten ===
* http://www.dspguru.com/ - FAQs, Infos, Beispielcode, ...
* http://docs.google.com/View?docid=dg2hppb_4gtgk89 - evtl. interessant als Rohmaterial für diesen Artikel
* http://www.dsprelated.com - Blogs, Jobs, Comp.DSP, ...
* http://www.unidsp56.de/ Eine Entwicklungsplattform für den Amateur
* http://de.wikipedia.org/wiki/Datei:Aircraft-recognition-and-tracking-by-dsp-based-signal-processing.jpg
* http://www.micromodeler.com - Online DSP Filter Designer

=== Artikel aus der Kategorie DSP ===

<ncl style=compact maxdepth=2 headings=bullet headstart=2
showcats=1 showarts=1>DSP</ncl>

[[Category:DSP]]

Schmitt-Trigger

2015-11-30T08:37:21Z

Maybee: Typo

== Einleitung ==
Ein Schmitt-Trigger hat einen Eingang und einen Ausgang und liefert abhängig vom Eingangspegel immer einen wohl definierten Ausgangspegel. Dabei gilt stets:
[[Bild:Schmitt-trigger-diagramm.png|thumb|Beispiel]]
* Am Ausgang liegt HIGH an, wenn der Pegel am Eingang eine Spannung UH '''über'''schreitet.
* Am Ausgang liegt LOW an, wenn der Pegel am Eingang eine Spannung UL '''unter'''schreitet.
* Dabei wird der bisherige Ausgangspegel aufrechterhalten, wenn sich der Eingangspegel zwischen UL und UH befindet (Hysterese)
* Der Übergang von LOW auf HIGH bzw. von HIGH auf LOW erfolgt stets mit steiler Flanke.
Dieses Verhalten kann man beispielsweise ausnutzen, um mittels Schmitt-Trigger ein verrauschtes digitales Signal wieder aufzufrischen. Ebenso müssen mechanische Taster bzw. Relaiskontakte [[Entprellung |entprellt]] werden, wenn sie digitale ICs ansteuern sollen, besonders wenn sie Taktsignale generieren sollen.

 

== Integrierte Schmitt-Trigger ==
Es existieren fertige ICs mit Schmitt-Trigger-Funktionalität. In der 74xx-Reihe ist das beispielsweise der 74xx14. Weitere Typen sind unter [[74xx]] aufgeführt. In der 4000er-Serie gibt es die Typen 4093 und 40106. Viele Mikrocontroller wie z. B. der [[AVR]] haben bereits Schmitt-Trigger Eingänge, sodass nur noch die beiden Widerstände und der Kondensator benötigt werden.

[[Bild:taster_entprellen.png|framed|left|'''Taster entprellen mit 74HC14''']]
 

== Schmitt-Trigger mit Operationsverstärker oder Komparator ==

Ein Schmitt-Trigger lässt sich auch mit Hilfe eines [[Operationsverstärker-Grundschaltungen|Operationsverstärkers]] oder besser eines [[Komparator|Komparators]] aufbauen.

=== Nichtinvertierender Schmitt-Trigger ===

[[Bild:st_generic.png | framed | Nichtinvertierender Schmitt-Trigger]]

Am - Eingang des OPV wird die Referenzspannung angelegt. Achtung! Diese liegt im allgemeinen NICHT mittig zwischen den beiden Schaltschwellen. R2 sorgt für die Mitkopplung und damit für die Hysterese. Über das Verhältnis von R1/R2 wird die Hysteresebreite festgelegt. Wird also UH am Eingang überschritten, geht der Operationsverstärker in die positive Sättigung UHA, wird UL unterschritten, geht er in die negative Sättigung ULA.

<math>U_{ref}=U_{LA} + (U_H - U_{LA} ) \frac{R_2}{R_1 + R_2}</math>

<math>U_{ref}=U_{L} + (U_{HA}-U_L) \frac{R_1}{R_1 + R_2}</math>

Durch Gleichsetzen und Umformen der beiden Gleichungen kann man R2 berechnen, wobei R1 vorher festgelegt werden muss.

<math>R_2=R_1 \cdot \frac{U_{HA}-U_{LA}}{U_H - U_L}</math>

Durch Einsetzen in die 1. oder 2. Gleichung kann man abschließend Uref berechnen. Die Referenzspannung kann man direkt aus einer [[Standardbauelemente#Shuntregler/Spannungsreferenz | Spannungsreferenz]] oder mit einem einfachen [[Spannungsteiler]] aus der Betriebsspannung generieren. Bei der Berechung des Spannungsteilers zur Referenzspannungserzeugung kann man einen der Widerstände frei wählen. Alle Berechnungen können mit dieser einfachen [[media:schmitt-trigger.xls | Exceltabelle]] durchgeführt werden.

=== Invertierender Schmitt-Trigger ===

[[Bild:st_generic_inv.png | framed | Invertierender Schmitt-Trigger]]

Durch einfaches Vertauschen von Uein und Uref kann die Schaltung invertierend arbeiten. Dabei ändern sich allerdings die Formeln zur Berechnung der Widerstände bzw. der Referenzspannung. Dafür gelten 2 Formeln.

<math>U_H=U_{ref} + (U_{HA}-U_{ref}) \frac{R_1}{R_1 + R_2}</math>

<math>U_L=U_{ref} - (U_{ref}-U_{LA}) \frac{R_1}{R_1 + R_2}</math>

Durch Umformen und Einsetzen erhält man:

<math>R_2=R_1 \frac{U_H-U_{HA}-U_L+U_{LA}}{U_L-U_H}</math>

<math>U_{ref}= \frac{U_H \cdot(R_1+R_2)-R_1 \cdot U_{LA}}{R_2}</math>

Bei der Berechung des Spannungsteilers zur Erzeugung der Referenzspannung kann man keinen der Widerstände R3 und R4 frei wählen (welche zusammen R1 ersetzen), sie berechnen sich direkt aus R1 und den anderen Eingangsparametern, abgeleitet aus den beiden Formeln.

<math>R_{1}= R3//R4 = \frac{R_3 \cdot R_4}{R_3 + R_4}</math>

<math>U_{ref}= V_{CC} \frac{R_3}{R_3 + R_4}</math>

Durch Umformen und Einsetzen erhält man:

<math>R_{4}= R_1 \cdot \frac{V_{CC}}{U_{ref}}</math>

<math>R_{3}= R_4 \cdot \frac{U_{ref}}{V_{CC} - U_{ref}}</math>

Auch diese Berechungen sind in der [[media:schmitt-trigger.xls | Exceltabelle]] verfügbar.

[[Category:Bauteile]]

Transistor

2015-10-30T07:45:07Z

Maybee:

Kunstwort aus "transfer resistor", was etwa so viel bedeutet wie "übertragener [[Widerstand]]".

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

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

== Schaltzeichen ==
http://electronicsclub.info/images/transbce.gif

* E: Emitter
* B: Basis
* C: Collector

In ASCII Schaltplänen sehen Transistoren so aus:
<pre>
|> |/
NPN |> oder -| oder -|
|\ |>

|< |/
PNP: |< oder -| oder -|
|\ |<
</pre>

Um zu erkennen, ob ein NPN oder PNP Transistor im Schaltplan verwendet wird, gibt es Eselsbrücken:
*Für Dichter: '''Tut der Pfeil der Basis weh, handelt's sich um PNP.'''
*Für Praktiker: '''PNP heisst "Pfeil Nach Platte"'''.
*Mit Dialekt: '''NPN "'naus, Pfeil, 'naus"'''.
*..und für Gleichberechtigungsverfechter: '''NPN means "Not Pointing iN"'''.

JFET: [[Bild:Transistor_JFET.png]]

MOSFET: [[Bild:Transistor_MOSFET.png]]

* S: Source
* G: Gate
* D: Drain

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.

'''Achtung:''' Die NPN/PNP Eselsbrücken funktionieren bei FETs nicht, denn bei einem P-Kanal FET zeigt der Pfeil weg vom FET!
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.

Bipolare Leistungstransistoren sind für das Schalten und Verstärken von Signalen höherer Stromstärken und Spannungen ausgelegt.

== Typbezeichnungen ==

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.

== Kenndaten/Parameter ==

Im [http://www.mikrocontroller.net/topic/197676#1938546 Beitrag: Transistorparameter Erklärung] sind Links zu Erläuterungen spezieller Kürzel.

== Transistor Grundschaltungen ==

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.

'''Weitere Links:'''
* Artikel [[Basiswiderstand]]
* [http://www.elektronik-kompendium.de/sites/slt/0203111.htm Transistor Grundschaltungen im ElKo]
* [http://www.roboternetz.de/wissen/index.php/Transistor Transistor bei RoboterNetz.de]

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.

=== Kollektorschaltung (Emitterfolger)===

'''Anwendung:'''
* Impedanzwandler
* Darlington-Schaltung
* Schalter

'''Eigenschaften:'''
* Keine Phasendrehung
* Hohe Stromverstärkung
* Keine Spannungsverstärkung

'''Beispiel: Transistor als Schalter'''

* NPN: Kollektor mit Vcc verbinden, Last an Emitter
* PNP: Kollektor mit GND verbinden, Last an Emitter

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.

[[Bild:NPN_Collector.gif | framed | center | NPN Transistor in Kollektorschaltung]]

Wird <math>R_{Poti}</math> (Spannungsteiler) erhöht, steigt die Spannung <math>U_{Last}</math> letztlich bis auf Vcc-0,6V (Basis-Emitter-Übergang).

[[Bild:PNP_Collector.gif | framed | center | PNP Transistor in Kollektorschaltung]]

Wird <math>R_{Poti}</math> (Spannungsteiler) erhöht, sinkt Spannung an <math>U_{Last}</math> letztlich bis auf 0,6V (Basis-Emitter-Übergang).

'''Weitere Links:'''
* [http://www.elektronik-kompendium.de/sites/slt/0204133.htm Kollektorschaltung im ElKo]

=== Emitterschaltung ===

Die Emitterschaltung bietet hohe Spannungs- und Stromverstärkung.

'''Anwendung:'''
* NF- und HF-Verstärker
* Leistungsverstärker
* Transistor als Schalter

'''Eigenschaften:'''
* Phasendrehung 180°
* Hohe Spannungsverstärkung
* Hohe Stromverstärkung

'''Beispiel: Transistor als Schalter'''

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.

[[Bild:NPN_Schalter.gif | framed | center | NPN Transistor als Schalter]]
<pre>
___ ___
Vcc/+ o-----------------------+ Vcc/+ o-----------------------+
| |
___ |< U_schalt (-) ___ |< PNP
+------|___|---| PNP o------------|___|----|
| R_Basis |\ R_Basis |\
Schalter \ | |
| ___ | ___ |
GND/- o------+------|___|-----+ GND/- o-------------|___|-----+
R_Last R_Last

</pre>

'''Weitere Links:'''
* [http://www.elektronik-kompendium.de/sites/slt/0204302.htm Emitterschaltung im ElKo]

=== Basisschaltung ===

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.

'''Eigenschaften:'''
* Geringe Eingangsimpedanz
* Keine Phasenverschiebung
* Hohe Bandbreite

'''Weitere Links:'''
* [http://www.elektronik-kompendium.de/sites/slt/0205081.htm Basisschaltung im ElKo

== FAQ aus dem Forum ==

=== PNP/NPN als Schalter, wohin mit der Last? ===
Für viele einfache Anwendungen kann man sich merken: '''Bei Schaltanwendungen darf der Basisstrom nicht durch die Last fließen'''. Normalerweise kommt dabei die Emitterschaltung zum Einsatz, die Last kommt also an den Kollektor.

<pre>
Vcc o-------------+ Vcc o-----------+
| |
.-. An: GND ___ |<
| | R_Last o---|___|--| PNP
'-' Aus: Vcc |\
| |
An: Vcc ___ |/ .-.
o---|___|----| NPN | | R_Last
Aus: GND |> '-'
| |
GND o-------------+ GND o-----------+
</pre>

Siehe [[Basiswiderstand]] zur Berechnung des notwendigen Basiswiderstandes bei gegebener Last R_Last für einen Transistor als Schalter.

Siehe auch Threads im Forum:
* http://www.mikrocontroller.net/topic/58567
* http://www.mikrocontroller.net/topic/119841
* oder im [http://www.elektronik-kompendium.de/sites/slt/0208031.htm Elektronik-Kompendium-Forum]

=== Wie kann ich mit 5V vom Mikrocontroller 12V und mehr schalten? ===
Schau mal hier:
* Wikiartikel [[Pegelwandler]]
* [http://www.elektronik-kompendium.de/sites/praxis/bausatz_pegelwandler-mit-transistoren.htm Pegelwandler im ElKo]
* [http://dl6gl.de/grundlagen/schalten-mit-transistoren schalten-mit-transistoren]

oder in diesen Threads:
*[http://www.mikrocontroller.net/topic/17899 Transistor als Schalter]
*[http://www.mikrocontroller.net/topic/14437 Vcc schalten mit MOSFET]
*[http://www.mikrocontroller.net/topic/29830 Schalten mit PNP-Transistor]
*[http://www.mikrocontroller.net/topic/104027 Transistorschalter für Versorgungsspannung]
*[http://www.mikrocontroller.net/topic/104951#921417 7-50V strombegrenzt schalten]
*[http://www.mikrocontroller.net/topic/103116#900247 P-Kanal MOSFET ansteuern]

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.

Schalten gegen GND

<pre>
+12V o------------------------+
|
.-.
( X )
'-'
|
___ |/ T1,NPN
uC PIN o---|___|-----| BC547
R2,4K7 |>
|
GND o---------o--------------+
</pre>

Schalten gegen +12V

<pre>
+12V o--------------+----------------------+
| |
| ____ |< T2, PNP
+--|____|----+--------| BC557
R1,4K7 | |\
|/T1,NPN |
Vcc/+5V o--------------| BC547 |
|> |
___ | .-.
uC PIN o-----|___|------+ ( X )
R2,4K7 '-'
|
GND o----------o--------------------------+
</pre>

=== Transistor an µC ohne Vorwiderstand ===

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.

Deshalb kann man den IO-Pin des AVRs einfach als Tristate Eingang einstellen (Portpin als Eingang und Pullup deaktivieren), damit kein Basisstrom fließt.

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

Nur sollte man bei kleinen Transistoren aufpassen, dass man den Portpin in der Software nie als aktiven Ausgang schaltet.

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

Eine Anwendung wären z. B. Nixie-Röhren-Kathodentreiber (geringe Stromverstärkung nötig).

=== Wann bipolare (NPN/PNP) und wann FETs (insbesonders, wenn LEDs im Spiel sind)?===
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...).

Ein Grenzfall: 500mA/5V schalten, siehe http://www.mikrocontroller.net/topic/62327.

=== Wieso gehen bei einer Multiplex-Anzeige mit Schieberegister 74HC595 und (Darlington-)Transistor als Zeilentreiber die LED nicht ganz aus? ===
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]

=== Wie steuert man ein Relais? ===
Normalerweise verwendet man zur Ansteuerung von Relais NPN-Transistoren in Emitterschaltung. Freilaufdiode nicht vergessen!

Siehe auch:
* [[Relais mit Logik ansteuern]]
* [http://www.mikrocontroller.net/attachment/22023/Relaisanteuerung.png Schaltbilder aus dem Forum]

=== Was ist die Spannung <math>U_{BE\_sat}</math> (lt. Datenblatt max. 1,2V)? ===
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.

=== Was bewirkt ein Kondensator (100µF-1nF) parallel zur Basis-Emitter-Strecke nach Masse? ===
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.

=== Gibt es einen IC, der wie mehrere Transistoren funktioniert? ===

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. B. ein Leistungstreiber zur Ansteuerung von Schrittmotoren, Relais und anderen induktiven Lasten aufbauen.

=== Gibt es ein Transistor-Array wie ULN28xx, das gegen Vcc schaltet? ===

Such mal nach UDN29xx, z. B. UDN2981, UDN2987 ...

=== Wann setzt man einen MOSFET, Bipolartransistor, IGBT oder Thyristor ein ? ===
siehe [[Leistungselektronik]]

Die Summe allen Übels ist konstant. Man muss wissen, welches Bauteil sich wofür besonders eignet.

====[[FET | MOSFET]]====

Vorteile
* Bei niedrigen Spannungen <100V sehr gut geeignet, <200V gut geeignet, sehr geringe R_DS-ON Widerstände möglich (einstelliger mOhm-Bereich)
* Hohe Schaltgeschwindigkeiten möglich
* Geringe An- und Ausschaltverluste
* Statisch praktisch leistungslos steuerbar
* Bodydiode kann als Freilaufdiode in H-Brücken verwendet werden
* 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]])

Nachteile
*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)
* Bei Sperrspannungen >100V deutlich steigende Einschaltwiderstände (R_DS-ON)
* Schnelles Umschalten erfordert hohe Lade-und Entladeströme ([[MOSFET-Übersicht#Mosfet-Treiber|MOSFET-Treiber]])
* Leitverluste quadratisch proportional zum Strom, Pv = I²*R_DS-ON

====[[Transistor | Bipolartransistor]]====

Vorteile
* Hohe Spannungsfestigkeiten möglich, bis zu 2000V
* Sehr hohe Schaltgeschwindigkeiten möglich
* Leitverluste etwa linear proportional zum Strom und Kollektor-Emitter-Sättigungsspannung, Pv = I * Uce-sat, U_CEC-sat typ 0,1...2.5 V

Nachteile
* Stromgesteuert, damit wird immer eine gewisse Ansteuerleistung benötigt
* Bei grossen Kollektorströmen nimmt die Stromverstärkung deutlich ab, dann wird ein großer Basisstrom benötigt
* 2. Durchbruch bei Überschreiten der max. Kollektor-Emitter Sperrspannung zerstört das Bauteil

====[[IGBT]]====

Vorteile
* Hohe Spannungsfestigkeiten möglich, bis zu 6600V, in üblichen Bauformen bis ca 1700V gut verfügbar
* Statisch praktisch leistungslos steuerbar
* Mit oder ohne antiparallele Diode zur Kollektor-Emitter-Strecke verfügbar
* Leitverluste linear proportional zum Strom und Kollektor-Emitter-Sättigungsspannung, Pv = I * Uce-sat, U_CE-sat typ. 2V

Nachteile
* Nur mäßige Schaltfrequenzen möglich (typ. <30..50kHz)
* Schnelles Umschalten erfordert hohe Lade-und Entladeströme ([[MOSFET-Übersicht#Mosfet-Treiber|MOSFET-Treiber]])
* 2. Durchbruch bei Überschreiten der max. Kollektor-Emitter Sperrspannung zerstört das Bauteil

====[[TRIAC]]/Thyristor====

Vorteile:
* Sehr hohe Spannungsfestigkeiten möglich (800V...mehrere kV, Thyristoren bis 12kV)
* Mit kurzen Pulsen einschaltbar, danach Selbsthaltung des Stromflusses
* Leitverluste linear proportional zum Strom, Pv = I * Uak, Uak typ. 0,8...1,5 V

Nachteile
* Auf niedrige Schaltfrequenzen beschränkt (kHz-Bereich, Schaltzeit im Bereich von µs)
* Anstiegsgeschwindigkeit des Stromes muss begrenzt werden, sonst kommt es zu Bauteilschäden
* Anstiegsgeschwindigkeit der Spannung muss begrenzt werden, sonst kommt es zum ungewollten Zünden
* Stromfluss kann nicht ausgeschaltet werden, damit meist nur Einsatz an Wechselspannung

{| class="wikitable"
|-
! Bauteil || optimales Einsatzgebiet || Kommentar
|-
| MOSFET || 0..200V, 0..500A || im Kleinspannungsbereich meist die beste Wahl als Schalter
|-
| Bipolartransistor || 0..1000V, 0..10A || wird mehr und mehr von MOSFETs verdrängt
|-
| IGBT || 200..1700V, 0..500A || optimal für hohe Spannungen und hohe Ströme
|-
| Triac/Thyristor || 230V, 400V, 680V, bis mehrere kV, 0..100A || meist für Wechselspannung, im Pulsbetrieb einige kA. Thyristoren bis 1000A im Dauerbetrieb (Scheibenzelle)
|}

=== Wie finde ich den richtigen Transistor für eine LED-Ansteuerung? ===

Quelle: Beiträge [http://www.mikrocontroller.net/topic/157763#1493623] und [http://www.mikrocontroller.net/topic/157763#1494972] von yalu

Um am Anfang wenigstens ein bisschen den Durchblick im Transistordschungel zu behalten, kannst du folgendermaßen vorgehen:

'''Nomenklatur'''

Nach der amerikanischen Nomenklatur beginnen die Transistornamen meist mit 2N (z. B. 2N2222 oder 2N3055) und nach der japanischen mit 2S (z. 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:

Der erste Buchstabe bezeichnet das Halbleitermaterial (A=Germanium, B=Silizium). Germaniumtransistoren werden heute nur noch selten verwendet.

Der zweite Buchstabe steht für den Einsatzzweck (C=Universal, D=hohe Leistung, F=Hochfrequenz, U=hohe Spannung).

So ist also ein ACxxx ein Germaniumuniversaltransistor und ein BDxxx ein Siliziumleistungstransistor.

'''Auswahl'''

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
Suchreihenfolge. Als erstes Auswahlkriterium nimmst du den Preis, denn:

* Zuviel Geld hast wahrscheinlich nicht einmal du.
* 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.
* 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.

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.

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]])

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:

<pre>
BC547C 45V 0,1A 0,5W
</pre>

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.

Deine LED wird typisch mit 20mA (max. 30mA) betrieben. Der BC547C kann 100mA, also ist auch hier noch Luft.

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.

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.

Da in deiner Anwendung HF- und Rauschverhalten keine Rolle spielen, bist du schon am Ziel angelangt.

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
zu einfach, wenn immer nur A, B und C verwendet würde ;-)

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. B. BD647). Ein Transistortyp, der sich sehr gut zum Schalten höherer Ströme eignet, ist der [[FET | MOSFET]].

Wie schon oben angedeutet: Wenn die 30-80V die die meisten BC- und BD-Transistoren abkönnen, nicht ausreichen, suchst du weiter bei BU.

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 ;-)

'''Und wie geht's weiter?'''

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.

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.

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

=== Wo ist die Antwort auf meine Frage? ===

Vielleicht im Forum? Falls du sie da findest, dann pack das ganze doch hier rein.

[http://www.mikrocontroller.net/topic/165580 Gegen Vcc oder GND schalten]

== Siehe auch ==
* [[Basiswiderstand]]
* [[Transistor-Übersicht]]
* [[AVR-Transistortester]]
* [[Leistungselektronik]]

== Gehäusebauformen von Transistoren ==

=== TO-92 ===
Ein kleiner Aufsatz über TO-92 Transistorgehäuse und Footprints findet sich unter: [[Media:TO-92-Gehaeuse_RevB2.pdf]].

== Weblinks ==
* [http://de.wikipedia.org/wiki/transistor "Transistor" bei Wikipedia]
* [http://www.elektronik-kompendium.de www.elektronik-kompendium.de]
** [http://www.elektronik-kompendium.de/sites/bau/0201291.htm Elko/Transistor]
* http://www.elektronikinfo.de/strom/bipolartransistoren.htm
* http://www.ferromel.de/tronic_1870.htm
* [http://www.DieElektronikerseite.de Die Elektronikerseite] Lehrgang: Der Transistor - Ein Tausendsassa
* [http://www.infoplease.com/encyclopedia/science/transistor-types-transistors.html Transistortypen]
* [http://electronics-electrical.exportersindia.com/electronic-components/transistors.htm Transistoren Industrieunternehmen Geschäftsauflistungen]

[[Category:Bauteile]]
[[Category:Grundlagen]]

LED-Pendellampe

2015-09-28T08:11:09Z

Maybee: Typo

''von [http://www.mikrocontroller.net/user/show/mclausen Martin Clausen]''

== Einleitung ==
Ziel bei diesem Projekt war die helle, gleichmäßige, farbgetreue und blendfreie Beleuchtung eines Wohnzimmer-Tisches. In einer Variante wird die gleiche Elektronik auch in einer Lampe in der Küche verwendet.
=== Features für den Nutzer ===
* Bedienung über Tasten & Drehencoder oder per IR-Fernbedienung
* Behält Dimstufe auch nach Abschalten der Versorgungsspannung
* Unterstützt Bewegungsmelder, wertet Umgebungshelligkeit aus
* Anpassung der Helligkeit an Umgebungslicht
* Temperaturüberwachung der LED
* RGB-Status-LED
* Konfigurierbar via Menü
* Koppelbar mit anderen Lampen
* LCD optional
* Leuchtet!

=== Technische Eigenschaften ===
* MCU
** NXP 89LPC935, 8051 mit 2-Takt Kern
** 8k Byte Flash (ca. 6,4k Byte ohne LCD belegt), 768 Byte RAM, 512 Byte EEPROM, ISP
** 3 Volt, niedriger Stromverbrauch
** interne Takterzeugung
* Kommunikation
** Empfängt IR-Signale gemäß RC5-Protokoll
* Stromversorgung
** Dimmbares Osram Konstantstrom-Netzteil mit LEDset
** Stellt 12V zur Versorgung der Steuerung bereit
** Standby-Leistungsaufnahme von 1,5W
** Alternativ Netzteil von Meanwell bietet größeren Dimbereich und eine niedrigere Standby-Leistungsaufnahme
** Netzteile können per PWM-Signal oder 0-10V Analogsignal gesteuert werden (Bestückungsoptionen)

* LEDs
** Nichia NS6W183 mit CRI90+ auf Streifen-Alu-Kern-Platinen
** Kann nach zu beliebig angepasst werden
** Überwachung der Temperatur via KTY81-220, bei Überschreitung von ca. 70°C abdimmen, Abschaltung bei 90°C

* Mechanik
** Konstruktion aus eloxierten Aluminium Profilen

* Software
** Open Source C für SDCC 3.3
** Verwendet Stromsparmodi der MCU
** State-Machines für RC5-Dekodierung
** LCD per #define aktivierbar
** Helligkeit wird erst nach einigen Sekunden ohne Bedienvorgang gespeichert, um das EEPROM zu schonen
** Viele Parameter vom Benutzer konfigurierbar

== Bilder ==

* Bei maximaler und minimaler Leistung
[[Bild:PendellampeMax.jpg|200px]]
[[Bild:PendellampeMin.jpg|214px]]
* Variante als Küchenlampe
[[Bild:KuechenlampeMax.jpg|200px]]
[[Bild:KuechenlampeMin.jpg|195px]]

Die Bilder wurden alle bei den gleichen fixen Kamera-Einstellungen aufgenommen. Der effektive dimmbare Bereich liegt zwischen 25 und 100%. Mit dem Netzteil von Meanwell ist ein größer Dim-Bereich möglich.
Die Küchenlampe ist in der Leistung durch die Kühlmöglichkeiten des verwendeten Aluminium-Profils beschränkt. Die Küchenlampe verwendet zwei LED-Module mit einer Farbtemperatur von 2700K.

== Beschreibung ==

=== Bedienung ===

Mit einem kurzem Tastendruck wird zwischen Standby und Betrieb gewechselt. Ein langer Tastendruck aktiviert das Optionsmenü, bzw. verlässt dieses wieder. Bei einem sehr langen Tastendruck wird der Tastendruck ignoriert.

{| class="wikitable"
|+ '''Hauptmenü'''
|-
! Funktion || Status-LED || Erklärung
|-
| Standby || rot || LED nicht bestromt, IR-Signale, Umgebungshelligkeit und Bewegungsmelder werden ausgewertet
|-
| Betrieb || weiß || LED bestromt, IR-Signale und Temperatur werden ausgewertet
|-
| Betrieb || rot aufblinkend || minimale Helligkeit erreicht
|-
| Betrieb || grün aufblinkend || maximale Helligkeit erreicht
|-
| Optionsmenü || blau, blinkend || Wahl der Option über Drehencoder und Taste
|-
| Tastendruck ignorieren || grün || Tastendruck wird nach dem loslassen ignoriert
|-
| Übertemperatur || weiß / rot, blinkend || Temperatur der LED erhöht, Leistung reduziert
|-
| Übertemperatur || rot, blinkend || Temperatur der LED zu hoch, Abschaltung
|}

Im Optionsmenü wird die Option durch die Anzahl der blauen Blitze der Status-LED angezeigt. Bei der Wahl eines Menüpunktes durch Tastendruck, gibt die Status-LED durch ihre Farbe die Einstellung der Option wieder.

{| class="wikitable"
|+ '''Optionsmenü'''
|-
! Nr. || Funktion || Status-LED || Erklärung
|-
| 0 || Min. Light || wechselt Farbe nach Wert || minimale Helligkeit beim Einschalten der LED
|-
| 1 || Offset Light || wechselt Farbe nach Wert || minimales Ausgangssignal, ab dem das Netzteil anfängt die LED zu bestromen, wird auf das Netzteil eingestellt
|-
| 2 || Light Alarm || wechselt Farbe nach Wert || maximale Helligkeit der LED beim Ende eines Alarms
|-
| 3 || Detector Timeout || wechselt Farbe nach Wert || Zeit in Minuten nach der die LED nach der Detektion einer Bewegung ausgeschaltet wird, der Wert null schaltet den Bewegungsmelder ab.
|-
| 4 || Det.Bright.Limit || wechselt Farbe nach Wert || maximale Helligkeit, bei der der Bewegungsmelder noch aktiv ist
|-
| 5 || Set RC Address || wechselt Farbe bei Empfang eines gültigen RC5-Codes || Lernt RC5 Adresse
|-
| 6 || Receiver Mode || wechselt Farbe nach Wert || bestimmt das Zusammenspiel mit anderen Lampen
|-
| 7 || Reset settings || wechselt Farbe für Freigabe des Resets || Setzt Steuerung auf Werkseinstellungen zurück
|-
| 8 || LCD Contrast || - || nur mit LCD
|-
| 9 || Version || - || nur mit LCD
|}

=== Software ===

Die Software besteht aus folgenden Teilen:
* Hauptschleife

* Interrupt-Routinen
** RC5 Decoder, ausgelöst durch Timer 0 mit 4,5kHz, mit Software Timer auch Auswertung der Drehencoder bei 500Hz
** Update PWM-Werte mit 40Hz und Einlesen der Tasten usw., ausgelöst durch Timer aus RTC der MCU bei 10Hz

* Initialisierung der MCU
** Core Funktionen, hauptsächliche Stromsparfunktionen
** I/O Pins
** Interne RTC als 40Hz Taktgeber: 6*10^6/4/128/40
** Watchdog wird abgeschaltet
** ADC fixed channel, single conversion mode für ADC0
** DAC
** CCU output compare: non-inverted PWM, PLL: auf Lock-in abwarten
** Interrupts freischalten

* RC5 Decoder
Der RC5 Decoder beruht auf einer State-Machine, die schrittweise die einzelnen Bits erkennt und dann in Adresse und Daten zerlegt. Nach der Erkennung eines kompletten Komandos wird steht rCounter auf dem Wert 12 und das Hauptprogramm beginnt mit der Decodierung (Aufruf "DecodeRemote()").

* Auswertung Tasten
Es werden die Tasten entprellt und die Dauer des Tastendrucks wird festgestellt.

* Messung der externen Helligkeit
Der SFH320 Fototransistor wird über durch die Portpins umschaltbare Vorwiderstände von 3V aus bestromt. Mittels ADC wird dann der Spannungsabfall über dem Fototransistor gemessen. Am Bereichsende des ADC wird dann entsprechend auf den größeren oder kleiner Vorwiderstand umgeschaltet. Die Portpins wechseln für die Umschaltung zwischen Open-Drain und Push-Pull. Der Ausgabewert ist immer 1. Die Messwerte werden entsprechend ihrem Bereich gewichtet und durchlaufen einen exponentiellen Mittelwert-Filter.
Da der DAC des ADCs für die Helligkeitsmessung für die Ausgabe des Analogsignals an das Netzteil verwendet wird, ist eine Helligkeitsmessung nur im Standby möglich.
Beim Einschalten erfolgt zunächst eine Helligkeitsmessung bevor die LED bestromt wird, um den Strom entsprechend der Umgebungshelligkeit anzupassen.
Der Fototransistor muss gegen das Licht der Status-LED geschirmt werden.

* Bewegungsmelder
Wenn der Eingang Bewegungsmelder aktiviert ist und die Helligkeit unter der eingestellten Schwelle liegt, kann durch ein Pegel von 0V am Pin 1.3 für die zuvor eingestellte Zeit, die LED aktiviert werden.

* Temperaturüberwachung
Die Temperatur wird vom OPV für den ADC in den Bereich zwischen 25°C und 125°C skaliert. Mit 10Hz werden die Werte digitalisiert und dann stark gefiltert. Jeden Zyklus wird geprüft, ob die Temperatur niedrig ist (LED wird nach Helligkeitseinstellung bestromt), über der ersten Schwelle liegt (LED wird weniger als nach nach Helligkeitseinstellung bestromt) oder über der zweiten Schwelle liegt (LED wird abgeschaltet). Nach einer temperaturbedingten Abschaltung wird erst nach dem Unterschreiten der ersten Schwelle wieder eingeschaltet. Während dessen blinkt die Status-LED rot.

=== Elektronik ===

Die Stromversorgung der LED-Kette erfolgt über ein steuerbares Konstantstrom-Netzteil vom Typ Osram OT 45/220-240/700 LTCS ( [http://www.distrelec.de distrelec] , 46,05€). Es bietet eine maximale Ausgangsleistung von 45W und eine maximale Ausgangsspannung von 120V. Je nach Ausgangsspannung werden maximal 350mA (120V) bis 700mA (64V) geliefert. Das Netzteil wird dafür per DIP-Schalter konfiguriert. Zusätzlich gibt es einen LEDset Anschluss, der zur Versorgung von externen Komponenten 12V bei max. 50mA und einen analogen 0-10V Steuereingang bietet.
Negativ fallen der minimale Laststrom von 100mA und der Standby-Verbrauch von 1,5W auf.

Alternativ kann das LED-Netzteil LCM-60 (60W, 2-90V) oder LCM-40 (40W, 2-100V) von Meanwell ([http://www.reichelt.de Reichelt] , 45,20€ bzw.41,75€) verwendet werden, wenn man sich auf auf 2 LED-Module beschränkt. Diese können dann im Strom auch komplett von 0 bis 100% gesteuert werden. Dies kann auch per 10V PWM Signal erfolgen (also nicht direkt vom Mikrocontroller!). Das Netzteil bietet zusätzlich einen Anschluss zur Temperaturüberwachung per NTC. Der Standby-Verbrauch beträgt weniger als 1W.

Die Steuerung gruppiert sich um eine MCU von NXP der 8051 Serie. Das Steuersignal wird per PWM mit der CCU (0/Ub PWM Signal) oder per DAC (0-10V) erzeugt. Das kärgliche On-Chip der klassischen 8051 hat NXP um 512 Byte aufgebessert, was die Programmierung mit dem SDCC erleichtert. Die Einstellungen werden im internen EEPROM abgelegt. Der interne Takt ist für RC5-Dekoder und PWM-Erzeugung ausreichend.
Die Software sollte auch einfach auf einen Atmel AVR o.ä. portiert werden können.

Die MCU und der IR-Empfänger werden durch einen sparsamen Linearspannungsregler mit 3,0V oder 3,3Vversorgt. LP2951-3.X oder LP2950-3.X vertragen die 12V Eingangsspannung leicht. Sie sind jedoch nur mit Tanal-Kondensator am Ausgang zu betreiben. Die Nachbauten von Taiwan Semiconductor (TS295X-3.X) funktionieren auch mit Keramikkondensatoren. Je nach Betriebsspannung muss die Verstärkung des Analogausgangs angepasst werden.

Das Ausgangssignal des DAC wird von einem OPV verstärkt, um den Signalhub bis 10V zu erreichen. Der Ausgang des OPV muss von vom LEDset Ausgang mittels 270 Ohm entkoppelt werden, sonst flackern die LEDs.
Das PWM-Signal wird mittels eines NPN-Transistors auf Betriebsspannungs-Niveau gehoben.
Je nach Anforderung sollte nur '''eine''' Variante also PWM '''oder''' analog Steuerung bestückt werden.

Die Steuerplatine trägt eine 5*2 polige Pfostenleiste, diese dient primär zur Programmierung der MCU, kann aber auch für Erweiterungen verwendet werden.
Statt auf einer geätzten Platine, lässt sich die Schaltung aber auch leicht auf einer Lochrasterplatine aufbauen, wenn man noch einer "sockelbaren" MCU im PLCC habhaft werden kann (oder die Portierung auf eine andere MCU durchführt).

Die MCU wird mit der kostenlosen Software [http://www.flashmagictool.com/ FlashMagic] und einer [http://www.keil.com/mcb900/mcb900-schematics.pdf Schaltung von Keil] über RS232 geflasht. Bei der Inbetriebnahme müssen folgende Punkte beachtet werden:
* Die Kondensatoren auf der Steuerungsplatine müssen schnell genug entladen werden können, damit die MCU beim Start in den Programmiermodus gebracht werden kann. Eine zusätzliche Last von z.B. 100 Ohm über die Betriebsspannung hilft.
* Es muss keine "echte" RS232 Schnittstelle sein. Ein USB-RS232 Adapter mit FTDI-Chip funktioniert bei mir auch.
* Einstellungen Flash Magic:
** Select: 89LPC936 oder 89LPC935 je nach Chip
** Baud Rate: 7200
** Interface: None (ISP)
** Oscillator (MHz): 7,373
** Erase block used by Hex File
* Die Device Configuration wird wie folgt geschrieben: interner Oszillator, Rest-Pin aus, Brown-out an

Nach der Programmierung der MCU muss diese im Optionsmenü unbedingt auf Werkseinstellungen zurückgesetzt werden.

=== Optoelektronik ===

Die Auswahl der LEDs wird primär von den Wünschen nach der Lichtwirkung bestimmt. Es wurden 3 LED-Leisten Typ "PowerBar LED Leiste, 12 Nichia LEDs, CRI 90+" von [http://www.leds.de/LED-Leisten-Module/High-Power-LED-Leisten/PowerBar-LED-Leiste-12-Nichia-LEDs-CRI-90.html Leds.de] in das Leuchtenprofil sorgfältig eingeklebt (WK 709-5ML, [http://www.reichelt.de Reichelt]). Die kalte Variante ist mit 6500K wirklich recht kühl, die meisten werden die Variante mit 2700K bevorzugen.

Kosten ca. 75€ + Kleber

=== Mechanik ===
Bei einer Lampe ist natürlich das Design eine wichtiges Merkmal. Ich bevorzuge ein klares einfaches Design und Materialien wie Glas und eloxiertes Aluminium. Die verwendeten Profile ermöglichen es die Kabel und die Leistungselektronik im Inneren zu verstecken. Zwei IR-Empfänger "schauen" aus den Enden des Vierkant-Rohres nach RC5-Signalen.
Das Alu-Leuchtenprofil gibt es mit opaler oder klarer Abdeckung. Die opale schluckt deutlich Licht, was jedoch genug vorhanden ist, belohnt aber mit gleichmäßiger, blendfreier Beleuchtung.

{| class="wikitable"
|+ '''Mechanik'''
|-
! Anzahl || Länge || Bezeichnung || Preis
|-
| 1 || 850mm || Alu-Leuchtenprofil 80mm breit, Abdeckung opal oder klar, Nr. 9458020, [http://www.pur-led.de/LED-Aluminiumprofile/LED-Alu-U-Profile/LED-Aluminium-U-Profil-80mm-silber-eloxiert-mit-Abdeckung.html pur-led] || 99,75€ mit Zuschnitt
|-
| 2 || - || Abdeckkappen, Nr. 94580201, [http://www.pur-led.de/LED-Aluminium-Profile/LED-Alu-Zubehoer/LED-Endkappe-fuer-LED-Aluminium-U-Profil-Wide-15x23mm-ohne-Kabeldurchgang.html pur-led] || 19,98€
|-
| 1 || 160mm x 22,0mm || Profil-Gehäusehalbschale, KOH-2160, [http://www.reichelt.de Reichelt] || 6,70€
|-
| 1 || 160mm x 42,4mm || Profil-Gehäusehalbschale, KOH-6160, [http://www.reichelt.de Reichelt] || 8,45€
|-
| 1 || 105mm x 64,4mm || Deckelsatz für Profil-Gehäusehalbschale, DPL 2-6, [http://www.reichelt.de Reichelt] || 7,75€
|-
| 8 || - || Kabelzugentlastungschelle, KAZU 0440, [http://www.reichelt.de Reichelt] || 0,36€
|-
| 1 || 850mm || Alu-Vierkantrohr 25mmx25mm, eloxiert, aus dem Baumarkt ||
|-
| 1 || 4m || Leitung für Halogenseilsysteme mit transparenter Isolierung, aus dem Baumarkt ||
|}

Ein 3D-Model für FreeCAD befindet sich weiter unten.

2D-Zeichnungen auf Anfrage per PM bei [http://www.mikrocontroller.net/user/show/mclausen Martin Clausen]

== Downloads ==

* [[Datei:LED-Pendellampe.zip]] Schaltpläne und Layout als Eagle Dateien, hex-File, 3D-Model für FreeCAD
** Es sind noch Platinen und MCU vorhanden, bitte bei Interesse beim Autor melden!
* [http://www.mikrocontroller.net/svnbrowser/nachttischlampe/branch/Lampensteuerung Link zum SVN Repository für Software]

== Siehe auch ==

* [[Nachttischlampe]]
* [[Wake-Up Light]]
* [[LED]]

[[Kategorie:Projekte]]
[[Kategorie:8051]]

AVR Transistortester

2015-08-20T06:57:57Z

Maybee:

== Einleitung ==

Original Entwurf: http://www.mikrocontroller.net/articles/AVR-Transistortester

Weiterentwickelt von Karl-Heinz Kübbeler

Ich habe das Transistortester Projekt von Markus Frejek weitergeführt und speziell die Software weiterentwickelt.
Aufgrund der verbesserten Eigenschaften wurde schon der Name Komponententester vorgeschlagen. Ich selbst sehe aber immer noch die herausragende Eigenschaft in der automatischen Bestimmung von Transistortyp und Eigenschaft, wie sie von
Markus Frejek entwickelt wurde.

Hier möchte ich die wichtigsten '''Eigenschaften''' aufführen

* Arbeitet mit ATmega8, ATmega168 und ATmega328 Prozessoren.
* Anzeige der Meßergebnisse auf ein 2x16 Zeichen LCD.
* Statt dem 2x16 Zeichen LCD kann auch ein graphisches Display mit ST7565 Controller benutzt werden. Auch ein Anschluß eines OLED Display mit SSD1306 Controller ist mit SPI oder I2C Schnittstelle möglich.
* Ein-Tastenbedienung mit automatischer Abschaltung.
* Das Gerät besitzt drei universelle Meßports (Test Pin).
* Automatische Erkennung von NPN, PNP, N- und P-Kanal MOSFET, JFET, Dioden und Kleinsignal Thyristor und TRIAC.
* Automatische Erkennung der Pin-Belegung der Bauteile, die Bauelemente können beliebig angeschlossen werden.
* Messung des Stromverstärkungsfaktors und der Basis-Emitter Spannung für bipolare Transistoren, auch für Darlingtontransistoren.
* Automatische Erkennung eine Schutzdiode für bipolare Transistoren und MOSFETs.
* Bei bipolaren Transistoren mit Schutzdiode wird ein parasitärer Transistor erkannt (NPNp = NPN + parasitär PNP).
* Bis zu zwei Widerstände werden in einer Messung mit einer Auflösung von bis zu 0,1 Ohm gemessen, wobei der Meßbereich bis über 50 MOhm reicht. Widerstandswerte unter 10 Ohm werden für den ATmega168/328 mit der ESR-Meßmethode mit einer Auflösung von 0.01 Ohm angezeigt.
* Ein angeschlossener Kondensator kann gemessen werden im Bereich 35pF bis 100mF mit einer Auflösung von bis zu 1 pF.
* Widerstände und Kondensatoren werden mit ihren Symbolen dargestellt, umgeben von den gefundenen Anschlußpin Nummern.
* Die Widerstands und Kondensator-Werte werden mit bis zu vier Dezimalstellen in der richtigen Dimension angezeigt.
* Bis zu zwei Dioden werden ebenfalls mit ihrer Symboldarstellung flußrichtungsrichtig angezeigt, umgeben von den Anschlußpin Nummern und der zusätzlichen Angabe der Flußspannung.
* Bei einzelnen Dioden wird zusätzlich der Kapazitätswert und ab Version 1.08k auch der Strom in Sperr-Richtung gemessen.
* Für ATmega168/328 ist eine Kalibration der Nullkapazität, des Nullwiderstandes und weiterer Parameter im Selbsttest-Zweig möglich.
* Für ATmega168/328 können auch Induktivitäten von etwa 0.01mH bis über 20H erkannt und gemessen werden.
* Für ATmega168/328 ist eine ESR-Messung (Equivalent Series Resistance) für Kondensatoren über 90 nF mit einer Auflösung von 0.01 Ohm integriert.
* für ATmega168/328 wird für Kondensatoren über 5 nF der Spannungsverlust Vloss nach einem Ladepuls untersucht. Damit läßt sich die Güte der Kondensatoren abschätzen.
* für ATmega328 sind mit einer Menüfunktion, die mit einem längeren Tastendruck (> 0.5 s) aufgerufen werden kann, weitere Funktionen aus einer Liste möglich. Ein kurzer Tastendruck zeigt die nächste Funktion. Ein längerer Tastendruck startet die angezeigte Funktion. Nachfolgend die Liste der bisher eingebauten Zusatzfunktionen:
** Frequenzmessung an dem PD4 Pin, der aber auch für den LCD-Anschluß benutzt wird. Der Pin wird für die Messung auf Eingang umgeschaltet. Die anliegende Frequenz wird zunächst für 1 Sekunde ausgezählt. Wenn die Frequenz unter 25 kHz liegt, wird auch eine mittlere Periode gemessen und daraus eine Frequenz berechnet mit einer Auflösung von bis zu 0.001 mHz.
** Spannungsmessung am PC3 Pin, wenn dieser nicht für die serielle Ausgabe benutzt wird. Bei ATmega328 mit 32 Pins (PLCC) kann aber auch der ADC6 oder ADC7 Pin benutzt werden. Da ein 10:1 Teiler am Eingang benutzt wird, können Spannungen bis zu 50V gemessen werden. Mit einer Erweiterung der Schaltung (DC-DC Konverter) können auch Zenerdioden gemessen werden.
** Frequenzerzeugung am TP2 Port. Über den am PB2 Pin angeschlossenen 680 Ohm Widerstand kann ein Signal mit einer aus einer Liste einstellbaren Frequenz von 1 Hz bis 2 MHz am TP2 Port ausgegeben werden. Der TP1 Port ist dabei auf Masse geschaltet.
** Pulsweitenmodulation mit fester Frequenz und einstellbarer Pulsweite auf dem TP2 Port. Der Zähler 1 wird für diese Funktion als 10-Bit Zähler benutzt. Der TP1 Port ist auf Masse geschaltet. Die Pulsweite kann durch kurzen Tastendruck um 1% und durch längeren Tastendruck um 10% erhöht werden.
** Mit einer separaten Kapazitäts- und ESR-Messung können an TP1 und TP3 angeschlossene Kondensatoren mit einer Kapazität von etwa 2µF bis 50mF meist auch in der Schaltung gemessen werden. Hierbei sollte aber immer sichergestellt sein, daß die Kondensatoren keine Restladung mehr haben.

Die zusätzlichen Funktionen sind zeitbegrenzt wie die Dialogfunktion selbst auch, wenn die POWER_OFF Option in der Konfigurationsdatei (Makefile) eingeschaltet ist.
Ausführlichere Informationen mit Meßbeispielen kann man in den pdf-Dokumentationen in deutscher und englischer Sprache nachlesen. Auch russische Übersetzung der Dokumentationen sind verfügbar.

== Software ==

Die Software wurde basierend auf der Arbeit von Markus F. weiterentwickelt.
Der Teil für die Kondensatormessung wurde komplett neu geschrieben und auch die Widerstandsmessung wurde erheblich überarbeitet. Bei Schwierigkeiten und Problemen sollte man mich über E-mail oder über den Diskussionsteil (thread) benachrichtigen. Nur wenn ich von Problemen weiß, kann ich hoffentlich Abhilfe schaffen.

Weitere Einzelheiten sowie Beschreibung der einzelnen Meßverfahren und Beispiel-Ergebnisse habe ich in der pdf-Dokumentation (deutsche und englische Version) beschrieben. Hier findet man auch Hinweise zum Konfigurieren der Software mit Makefile Parametern und Optionen.
Die Kommentare im Quellcode sind in englischer Sprache.
Neu eingebaut in der Software ist eine Selbsttest-Funktion, in der die Funktion des Testers gemessen wird. In diesen Selbsttest ist auch ein Kalibrationsteil integriert.

== Hardware ==

Im Prinzip ist die neue Software so zu konfigurieren, daß sie auf der bereits von Markus F. vorgestellten Hardware ohne Änderungen läuft.

Sinnvoll sind dennoch einige Änderungen:

* Der Prozessor sollte auf einen 8 MHz Taktfrequenz umgestellt werden, am besten mit einem externen Quarz. Dazu müssen die fuses des ATmega geändert werden.
* Ein "pull up" Widerstand von etwa 27 kOhm sollte von Pin 13 (PD7) des ATmega nach VCC nachgerüstet werden.
* Der 100 nF Kondensator am Pin 21 (AREF) kann entweder ganz entfernt werden oder besser durch einen 1 nF Kondensator ersetzt werden.
* Wenn die elektronische Einschaltung des Testers Probleme macht, sollte wenigstens der C2 Kondensator an der Basis von Transistor T1 auf 10 nF reduziert werden und ggf. auch der Widerstand R7 auf 3,3 kOhm reduziert werden. Das komplette Schaltbild und Einzelheiten dazu findet man in der PDF Dokumentation.

Die Gründe und die Einzelheiten für diese Änderungen sowie weitere Hinweise für einen Neuaufbau sind im Hardware-Kapitel meiner pdf-Dokumentation beschrieben. Empfohlen wird ein ATmega168 Prozessor oder auch ein ATmega328 Prozessor, weil der ADC mit der Autoscale Funktion im Bedarfsfall von der 5V Referenz (VCC) auf die interne Referenz-Spannung umgeschaltet wird. Die interne Referenz hat für der ATmega8 eine Spannung von 2,56V, für die anderen Prozessoren aber 1,1 Volt. Mit 1,1 V kann eine bessere Auflösung des ADC für gemessene Spannungen unter 1 Volt erreicht werden.
Man kann den ATmega8 ohne Hardwareänderung gegen einen ATmega168 oder ATmega328 austauschen!
Hier ist der Teil der Schaltung, der für die Messung erforderlich ist.
Die Elektronik für die Batterieversorgung und die automatische Abschaltung fehlt in diesem Schaltbild.[[Datei:TransistorTesterVC1.png|miniatur|Schaltbild ohne Stromversorgung]]

Die rot markierten Bauteile sind nicht unbedingt erforderlich, können aber zu einer Verbesserung der Messgenauigkeit beitragen. Die grün markierten Bauteile sind gegenüber dem ersten Entwurf von Markus F. geändert.
Die Eagle Dateien von Asko B. für drei Varianten sind im Thread zu finden bei der Adresse: http://www.mikrocontroller.net/topic/248078?page=4#2891344

Hier ist der Artikel der 1. Transistortester Version von Markus F. zu finden: [[AVR-Transistortester]]

== Diskussionen zur neuen Version ==
Der Thread mit meinen älteren Software-Versionen und einigen Problemfällen sowie Hardware-Vorschlägen ist unter [https://www.mikrocontroller.net/topic/248078#new https://www.mikrocontroller.net/topic/248078#new] zu finden.

== Downloads (deutsch) ==
Alle Versionen von der Software und der Doku sind im SVN gespeichert.

[[Media:ttinfo_ger111k.pdf|Kurzbeschreibung (deutsch) Version 1.11k (2015-01-30)]]

[[Media:ttester_ger111k.pdf|Anleitung (deutsch) Version 1.11k (2015-02-08)]]

Die Benutzer können über den svnbrowser [https://www.mikrocontroller.net/svnbrowser/transistortester/ https://www.mikrocontroller.net/svnbrowser/transistortester/] das gewählte Verzeichnis als "GNU tarball" runterladen.
Beim Aufruf des svnbrowsers steht dazu unter der Datei/Verzeichnis Liste der Eintrag "Download GNU tarball".

Zum Auspacken der heruntergeladenen transistortester*.tar.gz Datei benötigen Windows Benutzer eine geeignete Software wie das Freeware Paket [http://www.7-zip.org/ 7-Zip].
Nach dem Auspacken hat man den vorher mit dem svnbrowser ausgewählten Verzeichnisbaum auf seinem eigenen Rechner.
Ein direkter Zugriff auf die Dateien mit dem svnbrowser ist nicht möglich!

Eine andere Methode auf den Inhalt des svn Archivs zuzugreifen besteht mit der Installation des TortoiseSVN Plugins für den Windows Explorer.
Damit ist dann der Zugriff über [svn://mikrocontroller.net/transistortester svn://mikrocontroller.net/transistortester] direkt auf das Archiv mit dem Browser möglich.

Linux Benutzer können auch direkt über svn auf das Archiv zugreifen.

== Downloads (russisch) - Загрузки (русский) ==
Для загрузок доступны все версии программного обеспечения и документации, хранящиеся в SVN

[[Media:ttinfo_rus111k.pdf|краткое описание (русский) Версия 1.11k (2015-01-11)]]

[[Media:ttester_rus111k.pdf|инструкции (русский) Версия 1.11k (2015-02-07)]]

Пользователь может загрузить выбранный каталог в качестве "GNU архива" через svnbrowser [https://www.mikrocontroller.net/svnbrowser/transistortester/ https://www.mikrocontroller.net/svnbrowser/transistortester/].

При вызове svnbrowsers, смотрите в список файлов / каталогов, запись "Скачать GNU архив".

Для распаковки загруженного файла * .tar.gz пользователи Windows могут воспользоваться любым подходящим программным обеспечением, таким как бесплатная программа [http://www.7-zip.org/ 7-Zip].

После распаковки архива у вас на компьютере будет архив с заранее выбранным через svnbrowser содержимым в дереве каталогов.

Прямой доступ к файлам через svnbrowser не возможен!

Еще один способ получить доступ к содержимому хранилища SVN состоит в установке TortoiseSVN плагина для Windows Explorer. Это затем кнопкой [svn://mikrocontroller.net/transistortester svn://mikrocontroller.net/transistortester] прямо в вашем архиве, используя браузер.

Пользователи Linux могут получить доступ непосредственно из SVN к архиву.

== Downloads (english) ==
All versions of the software and documentation are saved in the SVN archive.

[[Media:ttinfo_eng111k.pdf|Short description (english) Version 1.11k (2015-01-05)]]

[[Media:ttester_eng111k.pdf|Manual (english) Version 1.11k (2015-02-08)]]

Users can download a "GNU tarball" of the previous selected directory with the svnbrowser [https://www.mikrocontroller.net/svnbrowser/transistortester/ https://www.mikrocontroller.net/svnbrowser/transistortester/].

Windows users need a additional tool like the freeware [http://www.7-zip.org/ 7-Zip] to unpack the downloaded transistortester*.tar.gz file.
After unpacking you have a copy of the selected directory at your own computer.
The direct access is not possible with the svnbrowser!

Another way to get access to the SVN data is to install the TortoiseSVN plugin for the windows explorer. After installing you can access the data with [svn://mikrocontroller.net/transistortester svn://mikrocontroller.net/transistortester].

Linux users can also access the data with svn directly.

== Downloads (Português - Brasil) ==

Todas as versões de software e documentação estão salvas no arquivador SVN.

Usuários podem descarregar um pacote "GNU" de todos os diretórios anteriores com o svnbrowser [https://www.mikrocontroller.net/svnbrowser/transistortester/ https://www.mikrocontroller.net/svnbrowser/transistortester/].

Usuários de Windows precisam de uma ferramenta adicional como o freeware [http://www.7-zip.org/ 7-Zip] para descompactar o arquivo transistortester*.tar.gz. Depois de descompactado você terá uma cópia do diretório selecionado no seu computador. O acesso direto não é possível com o svnbrowser!

Outra forma de acessar os dados no SVN é instalar o TortoiseSVN plugin para Windows Exporer. Depois de instalar você pode acessar soa dados com o endereçco [svn://mikrocontroller.net/transistortester svn://mikrocontroller.net/transistortester].

Usuários Linux podem acessar os dados com svn diretamente.

== Downloads (Español) ==
Todas la versiones del software y la documentación están en SVN.

Los usuarios pueden descargar un "GNU tarball" del directorio seleccionado utlizando svnbrowser [https://www.mikrocontroller.net/svnbrowser/transistortester/ https://www.mikrocontroller.net/svnbrowser/transistortester/]

Los usuarios de Windows requieren de una herramienta adicional como el freeware [http://www.7-zip.org/ 7-Zip] (gratis) para desempacar el archivo descargado, transistortester*.tar.gz.

Luego de desempacar el archivo, tendrá en su computador una copia completa del directorio seleccionado.
Acceso directo no es posible con svnbrowser.

La otra manera de accesar el respositorio SVN es instalando el plugin TortoiseSVN; éste le permitirá acceso a la información con el URI: [svn://mikrocontroller.net/transistortester svn://mikrocontroller.net/transistortester]

Los usuarios de Linux pueden, por supuesto, accesar SVN directamente.

== Downloads (Slovak) ==

Všetky verzie softvéru a dokumentácie sú uložené v SVN archíve.

Prostredníctvom ''svnbrowsera'', ktorý sa nachádza na adrese [https://www.mikrocontroller.net/svnbrowser/transistortester/ https://www.mikrocontroller.net/svnbrowser/transistortester/] je možné kliknutím na odkaz ''"Download GNU tarball"'' stiahnuť kompletný obsah aktuálne zobrazeného adresára.

Na rozbalenie stiahnutého súboru ''transistortester*.tar.gz'' pod systémom Windows je možné použiť bezplatný software ''[http://www.7-zip.org/ 7-Zip]''. Po extrahovaní je na lokálnom PC k dispozícii kópia vybraného adresára. Priamy prístup k jednotlivým súborom SVN archívu cez ''svnbrowser'' nie je možný!

Alternatívnym spôsobom prístupu k SVN archívu je inštalácia a použitie pluginu ''TortoiseSVN'' pre Windows Explorer. Potom je možné pristupovať k dátam prostredníctvom odkazu [svn://mikrocontroller.net/transistortester svn://mikrocontroller.net/transistortester].

Užívatelia systému Linux môžu k SVN dátam pristupovať priamo.

== Downloads (your-language) ==
You can put a translation ''here'', but only if its done by yourself, not Google Translate.
You can also put a translation of the whole article here, if its done by yourself.

Only little understanding of the Wiki-Syntax is needed therefore.

== Verzeichnisstruktur des SVN ==
{| border="1" cellspacing="0" style="border-collapse:collapse"
|+ '''Ordnerstruktur und Beschreibung der ''Pfade'' im SVN'''
|- style="background-color:#B3B7FF"
| style="text-align:center" colspan="2" | '''Ordner/directory''' || '''Dateien/files''' || '''Beschreibung/description'''
|- style="background-color:#B9FFC5"
| '''Doku''' || || || Enthält die Dokumentation als PDF und als pdflatex-Quelltext
|-
| || '''trunk''' || || Letzter Entwicklungsstand der Dokumentation inclusive Bilder und Diagrammen
|-
| || '''trunk/pdftex/german''' || || enthält die deutschen Texte, Makefile und PDF-Dokumentation der Entwicklerversion
|-
| || '''trunk/pdftex/english''' || || contains the English text, Makefile and PDF documentation of the developer version
|-
| || '''trunk/pdftex/russian''' || || contains the Russian text, Makefile and PDF documentation of the developer version
|-
| || '''tags''' ||''changelog.txt'' || ''Hier sollte jede Änderung mit Versionsnummer eingetragen werden''
|-
| || '''tags/german''' || || ''Aktuelle PDF Dokumentation in deutsch''
|-
| || '''tags/english''' || || ''Current PDF documentation in English''
|-
| || '''tags/russian''' || || ''Current PDF documentation in Russian language''
|-
| || '''tags/old/german''' || || ''PDF Dokumentationen zu früheren Softwareversionen''
|-
| || '''tags/old/english''' || || ''PDF documentation for earlier software versions''

|- style="background-color:#B9FFC5"
| '''Hardware''' || || || Hardware Beschreibung
|-
| || '''strip_grid''' || || Verzeichnis für eine Streifenleiterplatine
|-
| || '''strip_grid/ttester_strip_grid.diy''' || || Beispiel einer Streifenleiterplatine, DIYLC-Datei
|-
| || '''strip_grid/TTester_strip.pdf''' || || Ergebnis der Streifenleiterplatine im PDF Format
|-
| || '''strip_grid/LiesMich.txt''' || || Kurzdokumentation für Streifenleiter-Platine
|-
| || '''strip_grid/ReadMe.txt''' || || Short documentation for the strip grid board
|-
| || '''Markus''' || || Entwurf von Markus R. mit LED-Dimmer im Eagle 6.4.0 Format

|- style="background-color:#B9FFC5"
| '''Software''' || || || Software für AVR-GCC 4.8.2
|-
| || '''trunk''' || || Aktueller Software-Entwicklungszweig
|-
| || '''trunk/default''' || || Makefile und Programmierdaten für ATmega168 mit Standard-Layout
|-
| || '''trunk/mega168_1.9V''' || || Makefile und Daten für ATmega168 mit Knopfzellenbetrieb (FiFi)
|-
| || '''trunk/mega168_3.3V''' || || Makefile und Daten für ATmega168 mit LiPo-Akkubetrieb (FiFi)
|-
| || '''trunk/mega168_strip_grid''' || || Makefile und Daten für ATmega168 für Streifenleiter-Platine
|-
| || '''trunk/mega328''' || || Makefile und Daten für ATmega328 mit Standard-Layout (ab Version 1.08k)
|-
| || '''trunk/mega328_1.9V''' || || Makefile und Daten für ATmega328 mit Knopfzellenbetrieb (Funkamateur)
|-
| || '''trunk/mega328_3.3V''' || || Makefile und Daten für ATmega328 mit LiPo-Akkubetrieb (Funkamateur)
|-
| || '''trunk/mega328_2X16_menu''' || || Makefile und Daten für ATmega328, 2x16 Zeichen Textdisplay, Impulsdrehgeber + Spannungsmessung
|-
| || '''trunk/mega328_dogm''' || || Makefile und Daten für ATmega328 mit Standard-Layout, 2x16 Zeichen DOG-M LCD
|-
| || '''trunk/mega328_strip_grid''' || || Makefile und Daten für ATmega328 für Streifenleiter-Platine (ab Version 1.08k)
|-
| || '''trunk/mega328_strip_grid_dogm''' || || Makefile und Daten für ATmega328 für Streifenleiter-Platine mit DOG-M Display
|-
| || '''trunk/mega328_st7565''' || || Makefile und Daten für ATmega328 mit Standard-Layout, 126x64 Pixel LCD, ST7565 Controller
|-
| || '''trunk/mega328_st7108''' || || Makefile und Daten für ATmega328 mit Standard-Layout, 126x64 Pixel LCD, ST7108 Controller
|-
| || '''trunk/mega328_st7920''' || || Makefile und Daten für ATmega328 mit Standard-Layout, 126x64 Pixel LCD, ST7920 Controller
|-
| || '''trunk/mega328_fish8840''' || || Makefile und Daten für chinesische Fish8840 Version, ATmega328, 126x64 Pixel LCD, ST7565 Controller
|-
| || '''trunk/mega328_wei_st7565''' || || Makefile und Daten für chinesische WEI_M8_LGTST Version, 126x64 Pixel LCD, ST7565 Controller, LiIon Accu
|-
| || '''trunk/mega328_GM328''' || || Makefile und Daten für chinesische GM328 Version, ATmega328, 126x64 Pixel LCD, ST7565 Controller
|-
| || '''trunk/mega328_T3_T4_st7565''' || || Makefile und Daten für chinesische T3 oder T4 Version, ATmega328, 126x64 Pixel LCD, ST7565 Controller
|-
| || '''trunk/mega328_T5_st7565''' || || Makefile und Daten für chinesische T5 Version, ATmega328, 126x64 Pixel LCD, ST7565 Controller, LiIon Accu
|-
| || '''trunk/mega328_ssd1306I2C''' || || Makefile und Daten für ATmega328 mit Standard-Layout, 126x64 Pixel OLED, SSD1306 Controller, I2C Schnittstelle
|-
| || '''trunk/mega328_ssd1306SPI''' || || Makefile und Daten für ATmega328 mit Standard-Layout, 126x64 Pixel OLED, SSD1306 Controller, SPI Schnittstelle
|-
| || '''trunk/mega644_LCD2004''' || || Makefile und Daten für ATmega644/1284 mit 4x20 Zeichen LCD
|-
| || '''trunk/arduino_m2560''' || || Makefile und Daten für Arduino Mega (ATmega2560) mit 2x16 Zeichen LCD
|-
| || '''trunk/mega8''' || || Makefile und Daten für ATmega8. Ab Version 1.00k ist der Selbsttest für den ATmega8 nicht mehr konfigurierbar.
|-
| || '''tags''' || || Fertige Software Versionen als ZIP gepackt
|-
| || || ''changelog.txt'' || ''Hier sollte jede Änderung mit Versionsnummer eingetragen werden''
|-
| || '''Markus''' || || Alternative Software von Markus R., bitte README beachten! Die Software wurde aufgeräumt und ist viel besser strukturiert, läuft aber nur auf einem ATmega168 oder ATmega328. Die Software läuft nur auf dem Standard-Layout.
|-
|}

[[Kategorie:AVR-Projekte]]

AVR Transistortester

2015-08-12T05:11:47Z

Maybee: Änderung 89503 von 95.244.122.48 (Diskussion) rückgängig gemacht.

Kühlkörper

2015-07-29T07:27:57Z

Maybee: Änderung 89416 von 217.234.142.25 (Diskussion) rückgängig gemacht.

Dieser Artikel versteht sich als Unterpunkt zum Artikel [[Leistungselektronik]].

== Einleitung ==

Ein Kühlkörper (engl. ''heat sink'') wird benötigt, wenn die Verlustleistung von elektronischen Bauteilen einen bestimmten Wert übersteigt. Der Kühlkörper hat dabei die Aufgabe, die entstehende Wärme möglichst gut auf eine große Fläche zu verteilen, um sie dann an die Umgebung abzugeben.

[[bild: Rippenkuehlkoerper.png | thumb | 300px| Rippenkühlkörper, Schnittdarstellung]]

Das grundlegende Prinzip sieht man an jedem Rippenkühlkörper. An der Stelle, wo das Kühlobjekt angeschraubt/gepresst ist (rotes Viereck), ist ein dicker "Klumpen" Material, der erstmal die Wärme auf eine etwas größere Fläche verteilen soll. Bei CPU-Lüftern ist dort teilweise Kupfer eingepresst, weil das noch besser als Aluminium Wärme leitet (engl. heat spreader, Wärmespreizer). Danach folgen viele, nach aussen dünner werdende Rippen. In der Mitte noch dick, dort muss die Wärme ja verlustarm durchgeleitet werden, aussen dünn, dort ist fast alle Wärme schon abgegeben. Ein guter Kühlkörper hat eine möglichst große Oberfläche bei möglichst kleiner Masse. Viele Kühlkörper werden aus preiswerten [http://de.wikipedia.org/wiki/Strangpressen Strangpressprofilen] hergestellt.

== Wärmewiderstand ==

Die wichtigste Kennzahl eines Kühlkörpers ist der Wärmewiderstand. Er gibt an, um wie viel Kelvin sich die Temperatur zwischen Wärmequelle und Umgebung unterscheidet, wenn eine bestimmte Wärmeleistung abgeführt werden muss. Die Einheit ist K/W, Kelvin pro Watt. (Hinweis: Oft wird die Einheit °C/W angegeben, das ist allerdings nicht ganz korrekt. Temperaturdifferenzen werden in Kelvin angegeben). Je niedriger der Wärmewiderstand, umso besser der Kühlkörper, weil er die gleiche Wärmeleistung mit einem kleineren Temperaturunterschied abführen kann. Dadurch bleibt das Bauteil kühler, was der Lebensdauer und Funktionssicherheit zu Gute kommt.

Allgemein gilt die Formel

<math>\Delta T = P_{\theta} \cdot R_{\theta}</math>

*<math>\Delta T</math> - Temperaturdifferenz zwischen Wärmequelle und Umgebung in K
*<math>P_{\theta}</math> - Wärmeleistung in W
*<math>R_{\theta}</math> - Wärmewiderstand in K/W

Der griechische Buchstabe Theta wird als Symbol für Wärmekenngrößen verwendet, denn es geht bei diesen Rechnungen um Wärmewiderstände und Wärmeleistungen, keine elektrischen Widerstände und elektrische Leistungen.

== Berechnung des Wärmewiderstands ==

Für einen Kühlkörper ist der Wärmewiderstand im Datenblatt angegeben. Diesen rein aus dem Aufbau zu berechnen ist sehr schwierig, auch das Messen ist nicht so einfach. Was man jedoch berechnen kann und muss ist der Wärmewiderstand eines Gesamtaufbaus, d.h. Bauteil + Kühlkörper. Dazu muss man im Wesentlichen zwei Fälle unterscheiden.

=== Bauteil ohne Kühlkörper ===

Ohne Kühlkörper kann ein Bauteil seine Wärme über zwei Wege abgeben. Über das Gehäuse direkt an die Luft (Abstrahlung oder Konvektion) oder über die Anschlüsse auf die Platine (Wärmeleitung). Dies alles findet parallel statt, aber je nach Gehäusetyp und Platinengestaltung ist die Verteilung auf die Kühlwege verschieden. Transistoren im Metallgehäuse (z. B. TO-3) oder mit Metallfahne (z. B. TO220) können recht viel Wärme über das Gehäuse abgeben. Leistungsdioden im Plastikgehäuse hingegen können den Großteil der Wärme nur über die Anschlüsse abgeben. Deshalb sollten diese möglichst kurz sein, und auf der Platine an dicke Leiterbahnen oder gar Kupferflächen angeschlossen werden. Ähnliches gilt für leistungsverstärkte DIL- oder SOIC-[[IC-Gehäuseformen | Gehäuse]], welche oft für [[H-Brücken_Übersicht | Leistungstreiber]] oder [[FET | MOSFETs]] verwendet werden. In diesen Fällen sollten die Pins direkt an Kupferflächen '''ohne''' Wärmefallen (Thermals) angeschlossen werden, auch wenn dadurch das [[Löten]] erschwert wird.

Für die meisten Bauteile ist im Datenblatt der Wärmewiderstand zwischen dem eigentlichen Chip (engl. "'''j'''unction") und der Umgebung (engl. "'''a'''mbient") angegeben.

*<math>R_{\theta JA}</math> - Wärmewiderstand zwischen Sperrschicht und Umgebung ohne zusätzlichen Kühlkörper in K

Damit kann man direkt in die oben genannte Formel gehen und die Temperaturdifferenz ausrechnen. Die Temperatur der Sperrschicht errechnet sich einfach aus der maximalen Umgebungstemperatur (meist Luft) und dem errechneten Temperaturunterschied.

<math>T_J = T_A + \Delta T </math>

*<math>T_J</math> - Temperatur der Sperrschicht in °C (engl. "'''j'''unction")
*<math>T_A</math> - Temperatur der Umgebung in °C (engl. "'''a'''mbient")
*<math>\Delta T</math> - Temperaturdifferenz zwischen Wärmequelle und Umgebung in K

=== Bauteil mit Kühlkörper ===

Will man mit einem IC größere Verlustleistungen umsetzen (Linearer Spannungsregler, [[Transistor]], etc.] muss meist ein Kühlkörper her. Die jeweiligen Gehäuse besitzen dazu meist eine Kühlfahne, an die man den Kühlkörper anschrauben kann. Bei anderen gibt es Klemmen, die den Kühlkörper fest klemmen. Hier gibt es einiges zu beachten. Der Kühlkörper darf nicht zu schwach angeschraubt werden, sonst ist der Wärmewiderstand zwischen Gehäuse und Kühlkörper zu gross. Er darf aber auch nicht zu stark angeschraubt/angepresst werden, um das Gehäuse nicht zu deformieren. Wichtig ist der Übergang zwischen IC und Kühlkörper. Hier muss bei größeren Leistungen (>5W) Wärmeleitpaste verwendet werden. Ihre Aufgabe ist es, die Luft zwischen den Oberflächen zu verdrängen, welche sich in den mikroskopischen Unebenheiten befindet und den Wärmewiderstand '''deutlich''' erhöht. Dabei sollte die Schicht sehr dünn sein, denn die Wärmeleitpaste ist im Vergleich zu Aluminium oder Kupfer ein schlechter Wärmeleiter, allerdings deutlich besser als Luft.

{| class="wikitable" style="text-align:center"
|-
! Material || Wärmeleitfähigkeit [W/(m*K)]
|-
| Luft || 0,026
|-
| Wärmeleitpaste || 4 - 10
|-
| Aluminium || 221*
|-
| ALMg3 || 140 - 160
|-
| ALMg4,5Mn || 120 - 140
|-
| ALMgSi1 || 170 - 220
|-
| ALCuMg1 || 160 - 200
|-
| ALCu6,5Mn0,3 || 95 - 130
|-
| Kupfer || 370*
|-
| Messing MS60 || 90 - 113
|-
| Cu Be 2 || 92 - 125
|-
| Cu Co 2 Be || 192 - 239
|-
| Cu Cr 1 Zr || 167 - 320
|-
| Cu Ni 2 Si || 67 - 120
|-
| Stahl 0,2%C || 50
|-
| Stahl 8%Cr || 21
|-
| Zinn || 65
|-
| Blei || 35
|-
|}

*Werte DIN V 4108-4, Achtung: bei den verfügbaren Legierungen sind weit geringere Wärmeleitfähigkeiten zu erwarten!

'''Beispiel'''

Das oft verwendete TO220 Gehäuse hat ca. 1cm^2 Kühlfläche. Wird ein Kühlkörper ohne Wärmeleitpaste aufgeschraubt und entsteht dabei ein angenommener Luftspalt von 10µm, hat dieser einen Wärmewiderstand von ca. 4K/W! Mit Wärmeleitpaste sind es rein rechnerisch nur 1/150tel, also etwa 0,026 K/W. Real muss man jedoch eher mit 0,5-1K/W rechnen.

Für die Berechnung des gesamten Wärmewiderstandes müssen hier drei Widerstände in Reihe betrachtet werden. Der Erste ist im Datenblatt zwischen Chip und Gehäuse angeben (engl. junction to case). Danach kommt der Übergang Gehäuse-Kühlkörper. Dieser ist von der Oberflächengüte und der Wärmeleitpaste abhängig und kann nur abgeschätzt werden. Ein TO220 Gehäuse mit dünner Schicht Wärmeleitpaste hat hier ca. 0,5-1K/W. Zum Schluss muss noch der Wärmewiderstand des Kühlkörpers addiert werden, dieser ist im Datenblatt angegeben. Vorsicht, bei größeren Kühlkörpern mit großen Rippen ist die Einbaulage wichtig, damit der Luftstrom frei strömen und gut kühlen kann (freie Konvektion, warme Luft strömt nach oben und kalte strömt unten nach). Die drei Wärmewiderstände werden addiert und über die oben angegebene Formel der Gesamtwärmewiderstand und damit die Temperaturerhöhung der Sperrschicht berechnet.
Dabei muss man aufpassen, dass man nicht aus Versehen den Wärmewiderstand ohne Kühlkörper (<math>R_{\theta JA}</math>) in die Formel einsetzt!

<math>R_{\theta} = R_{\theta JC} + R_{\theta CS} + R_{\theta S}</math>

*<math>R_{\theta}</math> - Gesamtwärmewiderstand in K/W
*<math>R_{\theta JC}</math> - Wärmewiderstand zwischen Sperrschicht und Gehäuse (engl. '''j'''unction - '''c'''ase)
*<math>R_{\theta CS}</math> - Wärmewiderstand zwischen Gehäuse und Kühlkörper (engl. '''c'''ase - heat '''s'''ink)
*<math>R_{\theta S}</math> - Wärmewiderstand des Kühlkörpers (engl. heat '''s'''ink)

Wird eine Schaltung in einem Gehäuse eingesetzt, muss man dafür sorgen dass die warme Luft abgeführt wird, vor allem in Kunststoffgehäusen. Ansonsten gibt es einen Wärmestau und die Temperatur steigt deutlich!

=== Zwangskühlung ===

Natürlich muss der Kühlkörper die Wärme auch abführen können. Was aber, wenn der für den Wärmeabtransport benötigte Kühlkörper mechanisch nicht ins Gehäuse paßt?
Hier kommen die Lüfter zum Einsatz, das Ganze nennt sich dann Zwangskühlung.

Durch den Einsatz eines Lüfters lässt sich die der Wärmewiderstand des Kühlkörpers etwa um den Faktor 4 verbessern, bzw. der Kühlkörper lässt sich in der Größe ungefähr um den Faktor 7..8 reduzieren. Dies sind jedoch nur Richtwerte für den ersten Entwurf, eine Prüfung durch Messung ist unbedingt erforderlich. Der Effekt beruht darauf, daß mittels eines Lüfters wesentlich mehr Luft wesentlich schneller am Kühlkörper vorbeiströmen kann, und dabei mehr Wärme bei gleicher Temperaturerhöhung aufnehmen kann.

Beim Einsatz eines Lüfters ist auch daran zu denken, daß sowohl die Ansaugöffnung als auch der Kühlkörper verschmutzen und regelmäßig gereinigt werden müssen. Weiterhin erzeugt ein Lüfter natürlich auch Lärm. Je kleiner der Lüfter und je größer die benötigte Luftlieferleistung, umso lauter wird der Lüfter. Umgekehrt kann man aber mit einem großen, eher langsam laufenden Lüfter den Geräuschpegel stark absenken. Und letztendlich kann ein Lüfter auch kaputt gehen, womit die Kühlung deutlich verschlechtert wird und das Bauteil überhitzt. Hier empfiehlt sich bei wertvolleren Objekten eine Lüfterüberwachung, wie sie seit längerem bei PCs eingesetzt wird.

==== Physikalischer Hintergrund der Zwangskühlung mit Luft ====

Luft hat eine Wärmekapazität von ungefähr 1kJ/kg/K was bedeutet, daß für die Erwärmung von 1kg Luft um 1K eine Energiemenge von 1kJ = 1000Ws erforderlich ist. D.h. für den kontinuierlichen Abtransport von 100W Wärme werden mindestens 100g Luft pro Sekunde benötigt, wenn man diese nur um 1K erwärmen will.
Um also 100W von einem Kühlkörper abzuführen, der sich hier im Beispiel um 8K erwärmen darf, sind 100W / 8K = 12,5g Luft pro Sekunde erforderlich. Ein Gramm Luft hat ein Volumen von etwa 0,77l, d.h. bei 12,5 g muss der Lüfter 9,6 l/s bzw. 34,5 m³/h liefern, die dann auch durch den gesamten Kühlkörper geblasen werden müssen.

== Die Platine als Kühlkörper ==

Bei kleineren Leistungen (< 5W) kann man auch die Platine als Kühlkörper benutzten. Dabei muss jedoch die Wärme vom Bauteil möglichst schnell auf eine größere Fläche verteilt werden. Dazu nutzt man große Kupferflächen direkt am Bauteil. Diese werden teilweise beidseitig angebracht. Die Wärme muss man dann jedoch mit vielen Vias von der einen Seite, auf der das Bauteil sitzt, auf die andere geleitet werden. Diese Vias heißen thermische Vias, da sie nicht als elektrische Verbindung sondern als Wärmeleiter dienen. Das funktioniert deshalb so gut, weil die Vias innen mit Kupfer beschichtet sind, welches die Wärme wesentlich besser leitet als das Material der Leiterplatte (FR2, FR4).
Verfügt ein SMD-Bauteil über eine sogenannte "heat slug" oder thermal pad auf der Unterseite, muss dieses zur Wärmeableitung unbedingt angelötet werden. Dies ist mit einem normalen Lötkolben möglich, wenn die Platine an dieser Stelle mehrere Durchkontaktierungen mit einem Durchmesser von ca. 1,5mm aufweist. Durch diese Durchkontaktierungen kann genug Lötzinn auf die andere Seite fließen um diese Fläche mit der Platine zu verlöten.

Mit modernen Technologien ist es auch möglich, deutlich größere Wärmeleistungen von der Platine abzuführen. Dazu werden z. B. Platinen mit Aluminium- oder Kupferkern oder auf einen Metallträger laminierte PCBs benutzt (IMS = '''I'''nsulated '''M'''etal '''S'''ubstrat). Diese kommen z. B. bei Hochleistungs-[[LED]]s zum Einsatz. Für Hobbyzwecke sind sie aber noch wesentlich zu teuer, vor allem bei Einzelstücken.

== Peltierelement ==

Ein [http://de.wikipedia.org/wiki/Peltier-Element Peltierelement] arbeitet nach dem [http://de.wikipedia.org/wiki/Thermoelektrizit%C3%A4t#Peltier-Effekt Peltier-Effekt]. Dabei wird in einem Halbleiter durch Stromfluss eine Seite des Elements kalt, die andere heiß. Damit kann man ein kleines Objekt beliebig kühlen oder heizen. Allerdings sind Peltierelemente nur in eher kleinen Abmessungen und Leistung verfügbar (bis einige Dutzend Watt) und deren Effizienz ist auch nicht sonderlich hoch. Die allgemeine Auffassung, die könnten Wärme einfach verschwinden lassen ist falsch. Denn die heiße Seite muss klassisch gekühlt werden, je nach Temperaturunterschied mit mehr als der doppelten Kühlleistung als auf der kalten Seite an Wärme abgeführt wird.

== Heat pipe ==

Eine [http://de.wikipedia.org/wiki/Heatpipe Heat pipe],auf deutsch Wärmerohr genannt, ist ein Rohr, welches mit einer leicht verdampfenden Flüssigkeit gefüllt ist. Wird ein Ende erhitzt, verdampft die Flüssigkeit und nimmt dabei sehr viel Wärme auf. Der Dampf steigt im Rohr ans andere Ende, kondensiert dort und gibt dabei seine Wärme wieder ab.

Heat pipes werden auch als Wärmesuperleiter bezeichnet, weil sie Wärme 100-10.000 mal besser leiten als ein massiver Kupferstab mit gleichen Abmessungen.

Auch hier muss gesagt werden, dass eine Heat pipe allein '''kein''' Kühlsystem ist, denn die Seite, auf der das Wärmetransportmedium wieder kondensiert, muss auch wieder klassisch gekühlt werden. Der grosse Vorteil ist die Abführung großer Wärmemengen auf engstem Raum, wie z. B. bei CPUs in Laptops.

== Flüssigkühlung ==

Im PC-Bereich ist es unter einigen Enthusiasten verbreitet, den Rechner entweder zu übertakten, um eine höhere Leistung zu erzielen oder super leise zu machen, um angenehmer arbeiten oder spielen zu können. In beiden Fällen muss eine große Wärmemenge abgeführt werden. Dabei wird die sehr hohe Wärmekapazität von Wasser genutzt, um auf kleinem Raum die Wärme von CPU, GPU, Festplatten etc. abzuführen. Aber auch hier ist zu beachten, dass am Ende einer Flüssigkühlung praktisch immer ein klassischer Wärmetauscher steht, welcher die Wärme an die Umgebungsluft abgibt. Dieser kann sich aber deutlich weiter entfernt vom zu kühlenden Objekt befinden als ein einfacher, direkt montierter Kühlkörper.

Bei der Verwendung von Wasser statt Luft als Kühlmedium reduziert sich die Durchflußmasse in etwa um den Faktor 4,2, da die Wärmekapazität von Wasser bei ca. 4,182 kJ/kg/K liegt. Da Wasser aber auch eine deutlich höhere Dichte als Luft besitzt (Wasser = 1g/cm³; Luft = 1,3mg/cm³) kommt noch der Faktor von ~770 dazu, woraus sich ein Gesamtfaktor für das Durchflußvolumen von ~3230 ergibt.

D.h. die Durchflußmenge in unserem oben genannten Beispiel (100W) sinkt auf ca. 2,9 ml/s bzw. 10,7 l/h.

Vorteile
*Abtransport großer Wärmemengen auf kleinstem Raum
*nahezu lautlos

Nachteile
*höherer Aufwand und Kosten
*Gefahr durch auslaufendes Kühlmittel

Im Bereich der Leistungselektronik wird Flüssigkühlung eingesetzt, im Hobbybereich nahezu nicht.

== Bauteilmontage auf dem Kühlkörper ==

Die Montage der klassischen Halbleitergehäuse nach TO220 und ähnlichen gestaltet sich augenscheinlich simpel: Die Kühlfahne hat ein Loch. Da ist es doch sehr verlockend, das Bauteil mit einer Schraube durch ebendieses Loch auf dem Kühlkörper zu befestigen...

Bei fachgerechter Ausführung spricht auch wenig gegen diese Montageweise. Dazu gehört dann auch das richtige Anzugsmoment für die Schraube. Zu lose angezogen und zwischen Bauteilgehäuse und wärmeabführender Oberfläche entsteht ein Luftspalt. Ein Wärmeleitpad oder Wärmeleitpaste schaffen zwar Abhilfe, aber die Wärmeleitfähigkeit dieser Stoffe liegt um Größenordnungen unter der von Aluminium (Kühlkörper) und Kupfer (Kühlfahne). Ein vorhandenes Wärmeleitpad wird mitunter auch nicht weit genug zusammengedrückt, sodass auch noch Optimierung möglich wäre. Nämlich durch festeres Anziehen der Schraube.
Zu fest angezogen und die Kühlfahne wölbt sich minimal. Dabei hebt der Bauteilkörper von der Oberfläche des Kühlkörpers ab und es entsteht wieder ein Spalt. Ungünstigerweise liegt aber genau dort der Usprung des Wärmeflusses (Silizium-Chip). Bei Conrad gibt es [http://www.conrad.de/ce/de/overview/0205045/Transistor-Halteklammern-Haltefedern Klammern] zur Befestigung von Transistoren von [http://www.fischerelektronik.de/web_fischer/de_DE/K%C3%BChlk%C3%B6rper/A06/Transistorhaltefedern/$search_result_naviActualPage/1/$search_result_naviLinesPerPage/100/search.xhtml;jsessionid=2C868850DA0202334B26912FF6948496#search_result_naviPoint Fischer].

[[Datei: kuehlkoerper-montage.jpeg | thumb | 300px | Montagebeispiel]] Weitaus einfacher zu handhaben ist folgende Montageweise: Die Bauteile werden, ungeachtet der Montagebohrung, lose auf den Kühlkörper gelegt. Falls notwending natürlich mit Isolierstoff dazwischen und in jedem Fall hauchdünn mit einem Wärmeleitmittel bestrichen. Über die Bauteile wird dann ein Aluminiumprofil gelegt und erst dieses wird, weiterhin mit einer Schraube pro Bauteil, auf den Kühlkörper gespannt. Abgesehen davon, dass so auch SMD-Bauteile (IPAK!) auf einem Kühlkörper Platz finden, entsteht Druck genau über dem Hot Spot.

{{clear}}

== Weitere Hinweise ==

*Große Hochlastwiderstände mit Keramikgehäuse werden im Normalbetrieb recht heiß (200-350°C). Diese Temperaturen sollten nicht auf die Platine kommen, denn das macht das Material nicht lange mit. Hier muss genau das Gegenteil von dem gemacht werden, was weiter oben für Bauteile ohne Kühlkörper empfohlen wurde. Die Anschlüsse müssen möglichst lang sein, damit wenig Wärme über sie abgegeben werden kann. Die Kühlung erfolgt nahezu nur über den Keramikkörper durch Wärmestrahlung und Konvektion.
* Ein TO220 Gehäuse kann ca. 1W ohne Kühlkörper abgeben.
* Bei der Dimensionierung des Kühlkörpers sollte man sich nicht an der maximal zulässigen Sperrschichttemperatur orientieren, sondern möglichst um 10..50K kühler bleiben. Das verbessert die Funktionssicherheit und vor allem die Lebensdauer erheblich!
* Merksatz über den dicken Daumen: Pro 10 Grad Temperaturerhöhung halbiert sich die Lebenserwartung eines Bauteils. (Arrheniusgesetz, RGT-Regel, 10-Grad-Gesetz)
* Temperaturzyklen verkürzen die Lebensdauer von Schaltungen erheblich
* Meist sind mehrere kleine Kühlkkörper deutlich kleiner und billiger als ein Großer.

== Links ==

* [[Leistungselektronik]]
*[http://www.mikrocontroller.net/topic/308826?goto=3325027#3325027 Forumsbeitrag]: Wärmewiderstand und Sperrschichttemperatur messen
* [http://www.mikrocontroller.net/topic/351187#3905083 Forumsbeitrag]: Dicker MOSFET, dünnes Anschlusspin?

== Weblinks ==

* [http://sound.westhost.com/heatsinks.htm The Design of Heat sinks]. Eine ausführliche Seite zum Thema Kühlkörper, englisch
* [http://ludens.cl/Electron/Thermal.html Noch eine gute Seite, englisch]
* [http://wiki.oliverbetz.de/owiki.php/FormelSammlung Universelle Formelsammlung mit kurzen Erklärungen]
* [http://www.thermoconsult.de/01_TechInfo/Physik.pdf Grundlagen zur Kühlung, inhaltlich gut, Formatierung eher mies]
* [http://tangentsoft.net/elec/diy-hs.html DIY Heat Sinks]
* [http://www.fischerelektronik.de/ Kühlkörper bei Fischer Elektronik]
* [http://www.leiton.de/leiterplatten_teaser_alu.html Leiterplatten mit Alukern bei Leiton]
*[http://www.mikrocontroller.net/topic/84303 Guter Beitrag im Forum mit einer Beispielrechnung]
*[http://www.shop.display3000.com/mikrocontrollerloesungen/uc-mit-21-tft/d074-mikrocontroller-atmega-tft-farbdisplay-212.html Berechnung in der Praxis: Unter Downloads das Handbuch laden, dann Seite 14]

[[Kategorie:Bauteile]]
[[Kategorie:Leistungselektronik]]
[[Category:Grundlagen]]

Konstantstromquelle

2015-06-03T06:03:49Z

Maybee:

Eine '''Konstantstromquelle''' ist eine Schaltung, deren Zweck es ist, den Strom durch eine Last (z. B. eine [[LED]]) möglichst konstant zu halten, das heißt Änderungen des Stroms durch Variationen der Betriebsspannung und/oder des Lastwiderstands entgegen zu wirken.

Es gibt viele verschiedene Schaltungen, die zu diesem Zweck eingesetzt werden. Sie unterscheiden sich in ihrer Präzision, der minimalen und maximalen Betriebsspannung, und dem Bauteilaufwand. Es sollen hier nur einige besonders einfache Schaltungen vorgestellt werden.
<div class="toclimit-2">
__TOC__
</div>

== Konstantstromquelle mit J-FET ==

=== Beschreibung ===

Eine sehr einfache Konstantstromquelle lässt sich mit einem [[FET|JFET]] realisieren. Der resultierende Strom ist durch den verwendeten FET bestimmt, dabei wird die Eigenschaft genutzt, dass der JFET selbstleitend ist, also bei einer Gate-Source-Spannung von 0V seinen maximal möglichen Strom leitet und bei ansteigender negativer Gate-Source-Spannung U_GS den Drain-Source-Kanal zunehmend abschnürt. Es werden Bauteile angeboten, bei denen die Verbindung zwischen Gate und Source des FET schon intern vorgenommen wurde (Konstantstromdiode, engl. current regulator diode). Diese werden mit engeren Toleranzen gefertigt und erlauben daher eine genauere Definition des Stroms. Außerdem benötigen diese keinen Widerstand in der Sourceleitung und haben damit weniger Spannungsabfall im Betrieb.

=== Vorteile ===

* Großer Betriebsspannungsbereich, nach oben nur durch die maximale Drain-Source-Spannung (V_DS) des FETs und seine maximale Verlustleistung begrenzt.
* Einfachster Aufbau

=== Nachteile ===

* Beeinflussung durch Toleranzen der Fertigungsparameter des FET, typ. +/- 10%
* hohe Sättigungsspannung über dem FET, typ. 1-3V
* nur mäßig temperaturstabil
* selbstleitende FETs für Ströme größer als 30mA sind selten und entsprechend teuer<ref>Es gibt aber einige Depletion-Mode Mosfets mit sehr hohen Sperrspannungen und z.T. auch grösseren Strömen.</ref>

=== Schaltung ===

[[Bild:Konstantstrom.gif]]

=== Weblinks ===
* [http://www.vishay.com/docs/70596/70596.pdf Vishay AN103 - The FET Constant-Current Source/Limiter]
* [http://www.elektronik-kompendium.de/sites/slt/0207011.htm ELKO: FET als Konstantstromquelle]
* [http://www.elektronik-kompendium.de/public/schaerer/curr2pol.htm ELKO: Der Transistor-LED-und der FET-Konstantstromzweipol]
* [[Mosfet-Übersicht#N-Kanal J-FET | Liste von J-FETs]]
* [http://search.datasheetcatalog.net/key/LM334 LM334] betagter, aber guter IC, programmierbare Konstantstromquelle mit 1µA-10mA, 0,8-1V Spannungsabfall, kann per Transistor auf deutlich größere Ströme erweitert werden.

== Konstantstromquelle mit bipolaren Transistoren ==

[[Datei:Ksq.png|thumb|right|231px|UBE-Konstantstromquelle]]
Die auch als UBE-Konstantstromquelle bekannte Stromquelle funktioniert folgendermaßen:

Über R2 wird ein Strom in die Basis von T1 eingespeist, dadurch fließt in T1 ein Kollektorstrom, welcher gleichzeitig der Laststrom ist, welcher konstant gehalten werden soll. Die Summe aus Kollektor- und Basisstrom von T1 fließt durch R1 und erzeugt über ihm einen Spannungsabfall. Wenn die Spannung über R1 die Basis-Emitter-Flußspannung von T2 überschreitet (ca. 0,7V), beginnt ein Kollektorstrom durch T2 zu fließen. Dadurch fließt ein Teil des Basisstroms von T1 in den Kollektor von T2 ab. Da der Basisstrom von T1 nun nicht weiter ansteigen kann, weil jeder Zuwachs als Kollektorstrom von T2 abfließt, bleibt der Strom durch R1 und damit auch die Last konstant. So stellt sich diese Schaltung auf eine konstante BE-Spannung von ca. 0,7V über R1 ein, je nach verwendetem Transistor. R1 berechnet sich daher wie folgt:

:<math>
\begin{align}
R1 & = \frac{U_{BE,T2}}{I_{\text{soll}}} = \frac{0.7\text{V}}{I_{\text{soll}}}
\end{align}
</math>

R2 wird so ausgelegt, dass T1 grundsätzlich sättigen kann. Siehe dazu [[Basiswiderstand]]. Ein guter Richtwert bei 5V Vcc ist 4,7kΩ. Anstatt '''T2''' kann auch eine Leuchtdiode verwendet werden, dazu den Basisanschluss weglassen. Die LED leuchtet auf, wenn die Stromquelle regelt, und verlischt bei Leerlauf. So lassen sich einfache Konstantstrom-Ladegeräte mit Kontrollanzeige aufbauen. Eine temperaturstabile Präzisions-Stromquelle entsteht durch Ersetzen von '''T2''' durch einen TL431[http://www.mikrocontroller.net/part/TL431].

=== Vorteile ===
* Gut bei niedriger Betriebsspannung, da Schaltung bereits mit kleiner Restspannung am Transistor T1 läuft und die Regelung auch dann erfolgt, wenn nur noch wenige hundert mV zwischen Kollektor und Emitter des Transistors T1 anliegen.
:: <math>U_{BE,T2}+U_{CE,T1} \approx 0{,}65\,\text{V}+0{,}15\,\text{V}</math>
* Einfachster Aufbau mit Standardbauteilen, d.h. kann aus Resten aus der Bastelkiste aufgebaut werden

=== Nachteile ===
* Nicht temperaturkompensiert, der Strom schwankt um ca. 0,26%/K
:: <math>\frac{\Delta U_{BE}}{R1} \quad\text{ mit }\quad \Delta U_{BE} \left(\Delta\vartheta\right) \approx -1{,}7 \,\frac{\text{mV}}{\text{K}} \cdot \Delta\vartheta</math>

[[Datei:Ksq_2T_sim.svg|thumb|right|300px|Analyse bei steigender Versorgungsspannung]]

=== Weblinks ===
* [http://www.elektronik-kompendium.de/sites/slt/0210253.htm ELKO: Transistor als Konstantstromquelle]
* [http://www.elektronik-kompendium.de/public/schaerer/currled.htm ELKO: Die Transistor-LED-Konstantstromquelle mit ein oder zwei Transistoren und Konstantstromquelle mit Bandgap und Opamp]
* [http://www.elektronik-kompendium.de/public/schaerer/curr2pol.htm ELKO: Der Transistor-LED-und der FET-Konstantstromzweipol]
* [http://www.ferromel.de/tronic_6.htm Verschiedene Konstantstromquellen mit Beschreibung]
* [http://www.elexs.de/kap5_9.htm Konstantstromquelle bei ELEXS]
{{Absatz}}

== Konstantstromquelle mit Operationsverstärker und Transistor ==

[[Datei:Ksq_opv.png|thumb|right|231px|Konstantstromquelle mit OPV und Bipolartransistor]]

Der Strom, welcher konstant gehalten werden soll, wird durch R2 gemessen (Shunt). Der OPV arbeitet als Spannungsfolger und versucht, die Spannung am - Eingang so groß wie am + Eingang zu halten. Ist z.B. die Spanunng am - Eingang etwas kleiner als am + Eingang (Bruchteile von mV!), dann steigt die Ausgangsspannung des OPV um einige mV und erhöht damit die Basis-Emitter-Spannung von T1 und damit den Basisstrom. Dadurch fließt ein höherer Kollerktorstom, welcher wiederum einen höheren Spannungsabfall über R2 verursacht, bis die Spannungen am - und + Eingang des OPV wieder absolut gleich sind (die Offsetspannung wird hier zunächst vernachlässigt). Die Beispielschaltung hier ist bei ausreichender [[Kühlkörper|Kühlung]] für T1 für ca. 1A brauchbar. Der Strom wird mit 0-100mV eingestellt. Der [[Basiswiderstand]] R4 wird nicht klassisch berechnet, da er hier eine etwas andere Funktion hat. Er dient mehreren Zwecken:
* Strombegrenzung des OPV im Extremfall, wenn die Last am Kollektor nicht angeschlossen ist. Dann versucht der OPV mit maximaler Ausgangsspannung den Strom durch R2 zu treiben, schafft das aber nicht.
* Verringerung der Verstärkung des Regelkreises. Damit kann man je nach Schaltung und OPV den Regelkreis stabil bekommen, falls er schwingt. Das ist auch von der internen Kompensation des OPVs abhängig und kann sehr verschieden sein.
* Schutz des OPV-Ausgangs im Fall der Überlastung von T1. Sollte dieser wegen Überlastung, Überspannung etc. kaputt gehen, so kann die Kollektorspannung an den OPV-Ausgang gelangen und diesen zerstören. Durch R4 wird der Strom begrenzt und damit eine Zerstörung verhindert.
Die Dimensionierung ist ein Kompromiss dieser drei Aufgaben, wobei man entscheiden muss, welche wichtiger ist. Um den den optimalen Wert zu finden, muss man meist auch einige Versuche durchführen.

Nachteilig ist, dass der Basisstrom von T1 nicht durch die Last fließt, aber durch R2 und somit die Konstantstromregelung verfälscht. Als Gegenmaßnahme nutzt man einen Darlingtontransistor mit sehr hoher Stromverstärkung von 1000 und mehr, was bedeutet, dass der verfälschende Basisstrom nur noch 1 Promille Fehler verursacht. Alternativ kann man mit gerade mal zwei clever platzierten Widerständen den Fehler des Basisstroms nahezu vollständig kompensieren, wie es in diesem [http://www.edn.com/design/power-management/4318484/Error-compensation-improves-bipolar-current-sinks Artikel] in [http://m.eet.com/media/1128969/12734-figure_3.pdf Figure 3] dargestellt ist. Das hat den Vorteil, dass man einfache Bipolartransistoren nutzen kann, welche deutlich höhere Grenzfrequenzen als Darlingtons aufweisen.
Eine weitere Möglichkeit ist die Verwendung eines MOSFET, dieser hat Gateströme (Leckströme) im Bereich von unter einem Mikroampere. Dieser Fehler fällt bei 99,9% der Anwendungen nicht ins Gewicht. Prüfen sollte man dabei, dass der MOSFET für [[FET#Linearbetrieb_von_MOSFETs | Linearbetrieb]] geeignet ist, denn das sind viele Hochleistungs-MOSFETs nicht! Hier wird noch ein zusätzlicher Widerstand vor dem Gate des MOSFETs geschaltet, um die hohe Kapazität des Gates vom OPV-Ausgang zu entkoppeln, welche viele OPVs wieder instabil machen würde.

[[Datei:Ksq_opv_mosfet.png|thumb|right|231px|Konstantstromquelle mit OPV und N-Kanal-MOSFET]]

Wichtig sind R1 und C1. In vielen Schaltungen im Internet fehlen sie, die Spannung über R2 geht direkt an den - Eingang des OPV. Das ist aber falsch und funktioniert oft nur durch Zufall. Denn R1 und C1 sind wichtig für die Frequenzgangkompensation des OPV. Die Schaltung ist ein [http://de.wikipedia.org/wiki/Regelkreis Regelkreis] und diese sind für notorische Instabilitäten bekannt, d.h. sie schwingen. Durch Rechnung oder Probieren muss der richtige Wert für R1 und C1 gefunden werden, bei denen die Stromquelle ausreichend schnell reagiert ohne zu schwingen. Testen kann man das u.a. dadurch, dass man einen Sprung auf den Eingang gibt, z.B. mit einem Funktionsgenerator oder einfach einem NE555 als Taktgeber. Dabei beobachtet man die Spannung über R2 mit dem Oszilloskop, ggf. auch am Ausgang des OPV. Hier sieht man wie schnell die Stromquelle reagiert und ob sie schwingt.

=== Vorteile ===
* Große Ströme können sehr genau und schnell geregelt werden, nur durch T1 und dessen Kühlung begrenzt
* einfacher Aufbau mit Standardkomponenten
* wird oft als Stromregler in elektronischen Lasten benutzt

=== Nachteile ===
* bei sehr hohen Stömen muss man eine Vierdrahtmessung an R2 vornehmen
* hohe Verlustleistung bei kleinen Lastwiderständen und hoher Betriebsspannung (lineare Stromquelle)
* nur Einquadrantenbetrieb möglich

=== Weblinks ===
*Analog by Design Show - Hosted by Bob Pease
** [http://www.youtube.com/watch?v=411f0DvXu18 Konstantstromquellen]
** [http://www.youtube.com/watch?v=2N6cjGS7lUE Präzise 1A Konstantstromquelle ]

== Stromspiegel als Konstantstromquelle ==

[[Datei:Stromspiegel als Konstantstromquelle.svg|miniatur|Stromspiegel mit Widerstand]]
Bei stabiler Versorgungsspannung eignet sich ein Stromspiegel mit Widerstand als Spannungs-Stromwandler und findet sich beispielsweise in älteren Operationsverstärkern wie dem LM741. Das Konzept des Stromspiegels wird an dieser Stelle nicht weiter erläutert.

Die Widerstände R2 und R3 reduzieren die Auswirkungen von Bauteiltoleranzen und den Temperaturdrift. Als grober Richtwert sollte deren Spannungsabfall 0,2 V oder mehr betragen. T1 und T2 sind identische Transistortypen (z.B. BC557B), die idealerweise von einer Bauteilrolle stammen.

Bei geeigneter Wahl von R2 und R3 oder Parallelschaltung von Transistoren wird aus dem Stromspiegel ein Stromvervielfacher. Bei gleichen Transistoren und gleichen Widerständen entsteht ein 1:1 Stromspiegel.

Berechnung:

Die Versorgungsspannung UB und der gewünschte Strom I sind bekannt

:<math>I_{ref} = \frac{U_B - 0{,}65 V}{R1+R2}</math> (Ausgangsformel)
:<math>R3 = R2</math> (1:1 Stromspiegel)
:<math>I = I_{ref}</math>
:<math>R1 + R2 = R_g = \frac{U_B - 0{,}65 V}{I}</math>
:<math>U_{R2} \approx 0{,}2 V</math>
:<math>R2 = \frac{U_{R2}}{I}=\frac{0{,}2 V}{I}</math>
:<math>R1 = R_g - R2</math>

=== Vorteile ===

* wenige, günstige Bauteile
* sehr einfache Konstruktion
* mäßiger Spannungsabfall (ca. 1V)
* schnell, da keine ausgeprägte Rückkopplung vorhanden
* zur Stromsenke umformbar (Überkopf stellen und npn-Typen verwenden)

=== Nachteile ===

* geringer Wirkungsgrad, doppelt wegen Referenzstrom
* mäßig hoher Quellenwiderstand (einfacher Stromspiegel)

== PTAT-Konstantstromquelle ==

:→ siehe [[PTAT-Stromquelle]]

== Konstantstromquelle mit Linearreglern ==

=== Grundschaltung mit LM317 ===

[[Bild:LM317_constant_current.png|thumb|right|280px|Konstantstromquelle mit LM317]]

Eine sehr einfache, günstige und doch genaue Konstantstromquelle kann mittels LM317 aufgebaut werden. Für einen LED-Strom von 20mA ist ein R1 von 62,5 Ω erforderlich, praktisch wird man 68Ω wählen. Dabei ist zu beachten, daß die Eingangsspannung ''V''in mindestens 3,5V + ''U''f,LED (Flußspannung der LED) betragen muss.
{{Absatz}}

==== Vorteile ====

* temperaturstabil
* sehr wenige, billige Bauteile

==== Nachteile ====

* Überschwinger beim Einschalten können vorkommen, so dass sensible Lasten zerstört werden können.
* Hoher Spannungsabfall über der Schaltung von mind. 3,5V
* Verlustleistung
:: <math>PV_\text{LM317} = I_\text{out}\cdot (V_\text{in}- U_\text{f,LED} -1,25\,\mathrm V)</math>
* Abhängig vom Gehäuse ist bei höheren Eingangsspannungen ein [[Kühlkörper]] am LM317 nötig:
** TO220: 1W
** TO92: 500mW
** SO-8: 600mW
* Bei niedrigen Strömen unter 3.5 mA ungenau (min. Load Current 3.5 mA laut Datenblatt)

==== Schrittweise einstellbare Variante ====

Eine schrittweise voreinstellbare Variante der Grundschaltung wurde 2008 von einem Mitarbeiter von National Semiconductor (Hersteller des LM317) im EDN-Magazin vorgestellt: [http://m.eet.com/media/1132369/14758-figure_1.pdf Programmable current source requires no power supply]. Dabei ist hier mit ''programmable'' manuell voreinstellbar gemeint, nicht Mikrocontroller-gesteuert. Auch der Teil des Titles ''requires no power supply'' ist irreführend. Die Konstantstromquelle benötigt sehr wohl eine externe Stromversorgung. Die Schaltung benötigt lediglich keine zusätzlichen Hilfsspannungen, entspricht sie doch der oben genannten Grundschaltung.

Mittels dreier 0−9 BCD-Schalter werden geschickt gewählte Widerstände zwischen ADJ und OUT parallel geschaltet. Die Widerstände sind so gewählt, dass der erste Schalter mit seinen zehn Stellungen und Widerständen zwischen 0 mA und 9 mA in 1 mA Schritten zum Gesamtstrom beiträgt, der zweite 0 mA bis 90 mA in 10 mA Schritten und der dritte 0 mA bis 900 mA in 100 mA Schritten.

In dieser Kombination ergibt das eine einstellbare Konstantstromquelle bis 999 mA in 1mA-Schritten bei rund 2% Genauigkeit.

Insgesamt werden

* 45 Widerstände, alle 1%, 1/4 W
** 15 × 1,24 kΩ
** 15 × 124 Ω
** 15 × 12,4 Ω
* ein LM317
* drei 0−9 BCD-Schalter und
* Gehäusematerial (Gehäuse, Kühlkörper für den LM317, Polklemmen, ...)
benötigt.

Der LM317 wird bei dieser einstellbaren Stromquelle gerade noch innerhalb seiner Spezifikation betrieben - wenn man den Spannungsabfall über ihn gering hält. Im Stromquellen-Beispiel im Datenblatt wird ein maximaler Widerstand von 120 Ω genannt, wohingegen die einstellbare Stromquelle bis zu 1,24 kΩ (nominell 1 mA Ausgangsstrom) und ∞ Ω (offen, nominell 0 mA Ausgangsstrom) verwendet. Mit etwas Geduld kann man aus dem Datenblatt herauslesen, dass 1,24 kΩ gerade noch ausreichen, damit die Regelung des LM317 nicht aussetzt. Dies findet man im Datenblatt in der Grafik ''Minimum Operating Current'' und im Beispiel ''1.2V-20V Regulator with Minimum Program Current''. Mit ∞ Ω ist man definitiv außerhalb des Arbeitsbereiches.

Der Strom bei der Einstellung 000 mA (Widerstand → ∞ Ω, d.h. offen) entspricht nicht 0,0 mA, sondern dem Strom aus dem ADJ-Anschluss für den nicht spezifizierten Fall, dass der LM317 außerhalb seines Arbeitsbereiches betrieben wird. Die im Datenblatt angegebenen 50 µA (typ.), 100 µA (max.) für den Arbeitsbereich können dabei je nach Exemplar überschnitten werden und sind nicht konstant.

Die Messung an neueren Chargen (gefertigt nach 2006) des LM317 diverser Hersteller zeigt, dass auch 1mA nicht sicher erreichbar sind. Es ist vielmehr so, das diese KSQ erst korrekt ab 003 mA bis hoch zu den 999 mA funktioniert. Das heißt konkret, die Einstellungen 000 mA, 001 mA und 002 mA sind nicht mehr stromstabilsiert. Das sollte man beachten, sofern man unbedingt den LM317 bei sehr kleinen Strömen einsetzen möchte.

In der Praxis lohnt es sich besonders bei kleinen Strömen ein Strommessgerät in Reihe zu schalten. Dabei ist Vorsicht bei billigen Multimetern geboten<ref>Bei billigen Multimetern ist auch aus anderen Gründen immer Vorsicht geboten. Siehe [http://gps.sozialnetz.de/global/show_document.asp?id=aaaaaaaaaaaajxn Schwerpunktaktion „Handmultimeter“ der hessischen Marktüberwachung ...]</ref>. Deren niedrige Strommessbereiche sind häufig mit einer 200 mA oder 250 mA Schmelzsicherung abgesichert. Schaltet man die Stromquelle versehentlich über 200 mA, beziehungsweise 250 mA, ist ein Sicherungswechsel fällig.

==== Weblinks ====

* National Semiconductor Datenblatt [http://www.national.com/ds/LM/LM117.pdf LM117/LM317A/LM317 3-Terminal Adjustable Regulator]
* [http://www.roboternetz.de/phpBB2/konstantstrom.php Passenden Widerstand für Konstantstromschaltung mit LM317 berechnen]
* [http://www.lumitronixforum.de/viewtopic.php?t=2611&highlight=lm317 Einfachste Konstantstromquelle mit dem LM317]
* [http://www.umnicom.de/Elektronik/Schaltungssammlung/Strom/Quelle/Stromquelle.html Konstantstromquelle bis 3A mit LM2576]
*[http://www.edn.com/contents/images/6566536.pdf Programmable current source requires no power supply]

==== Preise ====

; LM317:
* TO3: 1,90 €
* TO-220: < 0,25 €
* TO-92: < 0,15 €
* SO-8: < 0,20 €

=== Andere Linearregler ===

Der zuvor beschriebene LM317 eignet sich besonders gut als Stromquelle, da er seine Regelspannung auf der 'high-side' erwartet (1,25 V zwischen Vout und ADJ) und man den Regelpfad als Konstantstrompfad missbrauchen kann (ADJ als Ausgang nach GND, wobei der Strom über den Widerstand und nicht von ADJ geliefert wird)).

==== Mittels Shunt und Messverstärker ====

Die meisten anderen Linearregler messen ihre Regelspannung im Bezug auf GND. Um einen solchen Regler als Konstantstromquelle zu benutzen, kann man einen Stromsensor und einen Messverstärker verwenden. Letzterer steuert dann die Regelung des Linearreglers. Maxim hat in [http://www.maxim-ic.com/app-notes/index.mvp/id/921] ein Beispiel veröffentlicht, das so oder so ähnlich auch mit anderen Linearreglern funktioniert. Maxim misst den Strom auf der Eingangsseite. Vorteil: der Innenwiderstand des Ausgangs des Linearreglers wird durch den Messwiderstand nicht erhöht. Nachteil: Der Eigenverbrauch des Linearreglers wird mitgemessen.

Man kann den Strom auch auf der Ausgangsseite messen.

Das gleiche Prinzip funktioniert für Schaltregler, siehe zum Beispiel [[#LM2576_Step_Down| LM2576 Step Down]] auf dieser Seite.

==== Im Regelpfad - High-Side ====

.-----------.
VCC IN | | OUT
------------o o------>----.
| | I | |
| | | |
| | .-. |
| | | | |
| | | | Rload, R1 |
| | '-' |
| | | |
| | FB | |
| o------<----o |Vout
| | Iref | | |
| | | | |
| | .-. | |
| | | | | Vref |
| | | | R2 | |
'-----o-----' '-' | |
| GND | | |
| | | |
=== === v v
GND GND

Iref <1, R2) zwischen Ausgangsspannung (Vout) und Masse (GND) eingestellt. Der Spannungsteiler wird dabei so dimensioniert, dass eine vorgegebene Spannung Vref (meist 1,25 V) gegen GND an der Anzapfung des Spannungsteilers abfällt, die dann zum Regeleingang des Linearreglers geführt wird. Dabei wird üblicherweise angenommen, dass der Strom Iref in den Regler hinein vernachlässigbar ist.

Dann gilt für den Strom I im Spannungsteiler:

:<math>I = I_{R_1} = I_{R_2} = \frac{V_\text{out}}{R_1 + R_2}</math>

und

:<math>I_{R_2} = \frac{V_\text{ref}}{R_2}</math>

Der Strom I im Spannungsteiler ist somit alleine durch Wahl von R2 bestimmt und unabhängig von R1 bei vorgegebenem R2.

Ersetzt man daher R1 durch die Last, so erzeugt der Linearregler durch Steuerung von Vout einen konstanten Strom

:{|cellpadding="2" style="border:2px solid #ccccff"
|<math>I = \frac{V_\text{ref}}{R_2}</math>
|}

durch die Last.

Dabei muss man die Grenzen des Linearreglers beachten:

Der maximale Strom ''I''max des Reglers darf nicht überschritten werden. Damit die Annahme gilt, dass der Reglerstrom ''I''ref gegenüber dem Strom ''I'' im Spannungsteiler vernachlässigbar ist muss R2 klein gegenüber dem Innenwiderstand des Regeleingangs sein. Dass bedeutet, dass R2 so zu wählen ist, dass immer gilt:

:{|cellpadding="2" style="border:2px solid #ccccff"
|<math>\frac{V_\text{ref}}{I_\text{max}} \leqq R_2 \ll R_\text{in,ref} = \frac{V_\text{ref}}{I_\text{ref}}</math>
|}

Es muss ein Minimalstrom ''I''min durch den Spannungsteiler fließen, damit die Regelung nicht aussetzt. Für diesen Strom gilt gegenüber dem Regelstrom ''I''ref:

:<math>I_\text{min} = \frac{V_\text{out,min}}{R_1 + R_2} \gg I_\text{ref}</math>

Mit

:<math>V_\text{out,min} = V_\text{ref}\,</math>

folgt

:<math>R_1 \ll \frac{V_\text{ref}}{I_\text{ref}} - R_2 = R_\text{in,ref} - R_2</math>

Angenähert:

:{|cellpadding="2" style="border:2px solid #ccccff"
|<math>R_\text{load} \approx R_1 \ll \frac{V_\text{ref}}{I_\text{ref}}</math>
|}

Neben diesen Einschränkungen ist auch zu beachten, dass Die Last R1 auf der High-Side hängt und nicht gegen GND.

== Konstantstromquelle mit Schaltregler ==
Am günstigsten erscheinen Tiefsetzsteller (StepDown-Schaltregler), die mit einer großen Drossel im nichtlückenden Bereich arbeiten. Dann ist der Strom-Ripple (Wechselspannungsanteil) durch die Induktivität und Schaltfrequenz vorgegeben. Ein weiteres Glätten des Stromes ist dann gar nicht mehr erforderlich. Es sind nahezu beliebig große Gleichströme bereitstellbar.
=== MC34063, Step Up ===
==== Beschreibung ====
Der Ausgangsstrom beträgt 1,25V/Rx. Die Stromquelle ist '''nicht''' kurzschlussfest. Der Widerstand Rsc dient der Strombegrenzung der einzelnen Strompulse (Schaltregler), was u.a. einen gewissen Überlastschutz für den MC34063 darstellt. Rsc = 0.3/I_max, wobei I_max der maximale Pulsstrom ist und dieser kleiner 1.5A sein muss, weil der IC nicht mehr hergibt. In den meisten Anwendungen nimmt man hier 0,22Ω oder mehr.
Das Ganze kann man z. B. für mehrere LEDs in Reihe verwenden um diese mit
5V oder mit 4x 1,5V Batterien zu betreiben. Weiterhin ist zu beachten,
dass die Schaltung nicht leerlauffest ist: Im Leerlauf läuft die
Spannung auf >40V, und dann geht der MC34063 kaputt. Daher sollte man
zur Sicherheit eine Z-Diode parallel zum Ausgang legen, deren Z-Spannung 2..3V über der maximal zu erwartenden Ausgangsspannung liegt, wenn es
passieren kann, dass die Last abgeklemmt wird.
Aufgrund des Elkos am Ausgang ist die Stromquelle recht träge. R1 dient dazu den MC34063 vor dem Stromstoß zu schützen, wenn sich der Elko in eine zu kleine Last entlädt und der Strom kurzzeitig höher als der eingestellte Wert wird.
Die Bauteilwerte sind alle relativ unkritisch. Je nach Betriebsspannung sind die Bauteilwerte etwas anzupassen um den optimalen Wirkungsgrad und die beste Performance zu erzielen. Die eingezeichneten Bauteilwerte sind für geringe Ströme (<100mA) und Eingangsspannungen zwischen 5 und 15V ausgelegt. R2 sollte bei hohen Spannungen vergrößert werden. Wie man die Werte genau berechnet, steht in der Application Note AN920/D.
http://www.onsemi.com/pub/Collateral/AN920-D.PDF

Stromquellen sollten grundsätzlich ''keinen'' Ausgangselko aufweisen! Wie die Schaltregler-Schaltung dann stabil arbeitet muss gesondert herausgefunden werden.

==== Schaltung ====

[[Bild:mc34063_constant_current.gif]]

==== Vorteile ====
* überschüssige Spannung wird nicht verheizt

==== Nachteile ====
* nicht kurzschlussfest
* ohne Z-Diode D2 nicht leerlauffest
* träge beim Einschalten

=== MC34063, Step Down ===
==== Beschreibung ====

Die Step-Down Version funktioniert im Prinzip genauso wie die normale, lineare Konstantstromquelle, nur dass die ungenutzte Spannung nicht sinnlos verheizt wird. Der Ausgangsstrom beträgt 1,25V/Rx. Die Eingangsspannung muss mindestens 2V größer sein als die Ausgangsspannung.

Diese Version ist auch ohne die Z-Diode leerlauffest. Kurzschlussfest wird sie durch Rsc. Allerdings entlädt sich der Elko erstmal in die Last, wenn man diese im Betrieb anklemmt. Dadurch kann die Last und der MC34063 beschädigt werden, der Widerstand R1 verhindert aber letzteres.

Bei der Step-Down Version kann man die Elkos etwas kleiner machen, als bei der Step-Up Version, da der Stromfluss durch die Spule in die Last nahezu konstant ist. Wenn man die Spule vergrößert, wird der Strom gleichmäßiger und man kann die Elkos verkleinern. Allerdings wird der Wirkungsgrad aufgrund des höheren Gleichstromwiderstands der Spule schlechter und die Schaltung reagiert langsamer auf Laständerungen. Wie immer ist es also ein Kompromiss zwischen Wirkungsgrad, Kosten und Bauteilgröße.

Konstantstromregler sollten grundsätzlich ''keinen'' Ausgangskondensator haben, weil dieser den gewünschten Regeleffekt zunichte macht. Wie die Rückführung zum Regelverstärker im Schaltregler regelschwingungsfrei gemacht wird muss dann gesondert herausgefunden werden.

==== Schaltung ====

[[Bild:mc34063_constant_current_2.gif]]

==== Vorteile ====
* überschüssige Spannung wird nicht verheizt
* leerlauf
* kurzschlussfest

==== Nachteile ====
* träge beim Ausschalten

Besser ist hier eine [[Konstantstromquelle fuer Power LED]].

=== LM2576 Step Down ===
In einem [http://www.mikrocontroller.net/topic/97838#new Beitrag] im Forum wird folgende [http://www.mikrocontroller.net/attachment/34179/current_source.pdf Schaltung] genannt. Der vollständige Artikel ist [http://www.ednindia.com/article-621-switchingregularformsconstantcurrentsource-Asia.html hier] verfügbar.

== Konstantstromquelle mit Komparatoren ==
=== Einfache Abwärtswandlung (Vout < Vin)===

==== Beschreibung ====

Diese Schaltung wurde eigentlich für 1W LEDs entworfen, kann aber sicherlich auch anderweitig verwendet werden. Sie ähnelt sehr der eines vollintegrierten Schaltreglers wie MC34063 oder LM2576, ohne jedoch einen solchen zu verwenden.
Der Komparator vergleicht den Spannungsabfall über einem Shunt mit dem einer Referenzspannungsquelle. Ist die Spannung über dem Shunt zu groß, so schaltet er ab und der P-Kanal MOSFET sperrt. Umgekehrt, ist die Spannung über dem Shunt kleiner als die Referenzspannung, leitet der P-FET. Q4 arbeitet als [[Konstantstromquelle]] und sorgt dafür, dass die Gateansteuerung auch bei unterschiedlichen Versorgungsspannungen immer gleich bleibt. Die Referenzspannung von 100mV wird hier einfach durch eine Z-Diode und einen Spannungsteiler eingestellt. Für D4 muss eine schnelle Diode eingesetzt werden, entweder eine Schottkydiode oder schnelle Siliziumdiode! Q2 und Q3 dienen als sehr einfacher [[FET|MOSFET]]-[[Treiber]]. D3 ist nur aus Sicherheitsgründen vorhanden, um die Gate-Source Spannung des MOSFETs zu begrenzen, sie kann ggf. auch weggelassen werden. Über den Anschluß PWM kann ein invertiertes [[PWM]]-Signal zur Dimmung eingespeist werden. Hierbei muss das PWM-Signal im HIGH-Zustand größer als ca. 1V sein, ein einfaches 3,3V oder 5V Logiksignal ist also voll OK.

Der Ausgangsstrom kann durch Veränderung von R1 eingestellt werden. Der Wert kann einfach über die Formel

<math>I_{aus}=\frac{V_{Ref}}{R1} = \frac{100mV}{R1}</math>

bestimmt werden.

==== Schaltung ====

Platinendatei im Eagle-Format gibt es [http://www.mikrocontroller.net/wikifiles/3/38/LED_Stromregler.sch hier].

[[Bild:LED_Stromregler.png|thumb|left|600px| Einfacher Stromregler aus Standardbauteilen]]

[[Bild:LED_Stromregler_brd.png|thumb|left|600px| Beispiel eines Platinenlayouts]]

{{clear}}

==== Vorteile ====

* Kurzschlussfest
* guter Wirkungsgrad bei hohen Eingangsspannungen, Energie wird nicht wie bei einem Linearregler in Wärme umgesetzt
* einfachste Komponenten
* sehr preiswert, max. 2 EUR
* Dimmung per [[PWM]] möglich
* Eingangsspannungsbereich sehr groß, ca. 6-30V
* sehr einfach auch auf anderen Strom einstellbar



== Threads im Forum ==
* [http://www.mikrocontroller.net/topic/75355#new Philosophiestunde Konstantstromquelle]
* [http://www.mikrocontroller.net/topic/71573#new Suche regelbare Konstantstromquelle für ACULED]
* [http://www.mikrocontroller.net/topic/67593#new Konstantstrom für Windmessung]
* [http://www.mikrocontroller.net/topic/66825#new Konstantstromdiode]
* [http://www.mikrocontroller.net/topic/66033#new Konstantstromquelle als IC und einstellbar]
* [http://www.mikrocontroller.net/topic/59467#new Konstantstromquelle für einen Haufen LEDs]
* [http://www.mikrocontroller.net/topic/58036#new Konstantstromquelle]
* [http://www.mikrocontroller.net/topic/61778#new temperaturunabhängige Konstantstromquelle]
* [http://www.mikrocontroller.net/topic/45039#new Konstanter Strom für LED bei 2,5V bis 5,5V]

== Weblinks ==
* [http://de.wikipedia.org/wiki/Konstantstromquelle Konstantstromquelle bei Wikipedia]
* [http://www.dcdcselector.com/de/dc-dc-led-driver DC/DC LED Treiber IC parametrische Suche]
* [http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm DSE FAQ]
* [http://www.led-treiber.de Seite zu LED Treibern]
* [http://www.christiankoch.de/archiv/led-ksq/ Diskrete LED-Konstantstromquelle auf Schaltregler-Basis]
* [http://www.national.com/an/AN/AN-1392.pdf NATIONAL Application Note 1392: LM3485 LED Demo Board]
* [http://www.circuit-fantasia.com/circuit_stories/understanding_circuits/current_source/howland_current_source/howland_current_source.htm Howland Current Source]
* [http://www.national.com/an/AN/AN-1515.pdf "A Comprehensive Study of the Howland Current Pump", Application Note von National Semiconductior, engl.]
* [http://www.nomad.ee/micros/mc34063a/index.shtml MC34063A Design Tool (engl.)]
* [http://www.onsemi.com/pub_link/Collateral/MC34063A-D.PDF Datenblatt des MC34063 bei ON Semi]
* [http://www.stromflo.de/dokuwiki/doku.php?id=led-tutorial LED_Tutorial]
* [[Konstantstromquelle fuer Power LED]]
* [http://www.joretronik.de/Web_NT_Buch/Kap3/Kapitel3_2.html weitere Beispiele von Konstantstromquellen]
* [http://www.edn.com/design/power-management/4318484/Error-compensation-improves-bipolar-current-sinks Error compensation improves bipolar current sinks, EDN, engl.]
*[http://www.nxp.com/documents/application_note/AN10739.pdf] Diskreter LED Treiber, Konstantstromquellen

== Fußnoten ==

<references />

[[Kategorie:Spannungsversorgung und Energiequellen]]
[[Kategorie:Grundlagen]]

AVR Transistortester

2015-04-25T06:44:13Z

Maybee: /* Downloads (your-language) */

== Einleitung ==

Original Entwurf: http://www.mikrocontroller.net/articles/AVR-Transistortester

Weiterentwickelt von Karl-Heinz Kübbeler

Ich habe das Transistortester Projekt von Markus Frejek weitergeführt und speziell die Software weiterentwickelt.
Aufgrund der verbesserten Eigenschaften wurde schon der Name Komponententester vorgeschlagen. Ich selbst sehe aber immer noch die herausragende Eigenschaft in der automatischen Bestimmung von Transistortyp und Eigenschaft, wie sie von
Markus Frejek entwickelt wurde.

Hier möchte ich die wichtigsten '''Eigenschaften''' aufführen

* Arbeitet mit ATmega8, ATmega168 und ATmega328 Prozessoren.
* Anzeige der Meßergebnisse auf ein 2x16 Zeichen LCD.
* Statt dem 2x16 Zeichen LCD kann auch ein graphisches Display mit ST7565 Controller benutzt werden. Auch ein Anschluß eines OLED Display mit SSD1306 Controller ist mit SPI oder I2C Schnittstelle möglich.
* Ein-Tastenbedienung mit automatischer Abschaltung.
* Das Gerät besitzt drei universelle Meßports (Test Pin).
* Automatische Erkennung von NPN, PNP, N- und P-Kanal MOSFET, JFET, Dioden und Kleinsignal Thyristor und TRIAC.
* Automatische Erkennung der Pin-Belegung der Bauteile, die Bauelemente können beliebig angeschlossen werden.
* Messung des Stromverstärkungsfaktors und der Basis-Emitter Spannung für bipolare Transistoren, auch für Darlingtontransistoren.
* Automatische Erkennung eine Schutzdiode für bipolare Transistoren und MOSFETs.
* Bei bipolaren Transistoren mit Schutzdiode wird ein parasitärer Transistor erkannt (NPNp = NPN + parasitär PNP).
* Bis zu zwei Widerstände werden in einer Messung mit einer Auflösung von bis zu 0,1 Ohm gemessen, wobei der Meßbereich bis über 50 MOhm reicht. Widerstandswerte unter 10 Ohm werden für den ATmega168/328 mit der ESR-Meßmethode mit einer Auflösung von 0.01 Ohm angezeigt.
* Ein angeschlossener Kondensator kann gemessen werden im Bereich 35pF bis 100mF mit einer Auflösung von bis zu 1 pF.
* Widerstände und Kondensatoren werden mit ihren Symbolen dargestellt, umgeben von den gefundenen Anschlußpin Nummern.
* Die Widerstands und Kondensator-Werte werden mit bis zu vier Dezimalstellen in der richtigen Dimension angezeigt.
* Bis zu zwei Dioden werden ebenfalls mit ihrer Symboldarstellung flußrichtungsrichtig angezeigt, umgeben von den Anschlußpin Nummern und der zusätzlichen Angabe der Flußspannung.
* Bei einzelnen Dioden wird zusätzlich der Kapazitätswert und ab Version 1.08k auch der Strom in Sperr-Richtung gemessen.
* Für ATmega168/328 ist eine Kalibration der Nullkapazität, des Nullwiderstandes und weiterer Parameter im Selbsttest-Zweig möglich.
* Für ATmega168/328 können auch Induktivitäten von etwa 0.01mH bis über 20H erkannt und gemessen werden.
* Für ATmega168/328 ist eine ESR-Messung (Equivalent Series Resistance) für Kondensatoren über 90 nF mit einer Auflösung von 0.01 Ohm integriert.
* für ATmega168/328 wird für Kondensatoren über 5 nF der Spannungsverlust Vloss nach einem Ladepuls untersucht. Damit läßt sich die Güte der Kondensatoren abschätzen.
* für ATmega328 sind mit einer Menüfunktion, die mit einem längeren Tastendruck (> 0.5 s) aufgerufen werden kann, weitere Funktionen aus einer Liste möglich. Ein kurzer Tastendruck zeigt die nächste Funktion. Ein längerer Tastendruck startet die angezeigte Funktion. Nachfolgend die Liste der bisher eingebauten Zusatzfunktionen:
** Frequenzmessung an dem PD4 Pin, der aber auch für den LCD-Anschluß benutzt wird. Der Pin wird für die Messung auf Eingang umgeschaltet. Die anliegende Frequenz wird zunächst für 1 Sekunde ausgezählt. Wenn die Frequenz unter 25 kHz liegt, wird auch eine mittlere Periode gemessen und daraus eine Frequenz berechnet mit einer Auflösung von bis zu 0.001 mHz.
** Spannungsmessung am PC3 Pin, wenn dieser nicht für die serielle Ausgabe benutzt wird. Bei ATmega328 mit 32 Pins (PLCC) kann aber auch der ADC6 oder ADC7 Pin benutzt werden. Da ein 10:1 Teiler am Eingang benutzt wird, können Spannungen bis zu 50V gemessen werden. Mit einer Erweiterung der Schaltung (DC-DC Konverter) können auch Zenerdioden gemessen werden.
** Frequenzerzeugung am TP2 Port. Über den am PB2 Pin angeschlossenen 680 Ohm Widerstand kann ein Signal mit einer aus einer Liste einstellbaren Frequenz von 1 Hz bis 2 MHz am TP2 Port ausgegeben werden. Der TP1 Port ist dabei auf Masse geschaltet.
** Pulsweitenmodulation mit fester Frequenz und einstellbarer Pulsweite auf dem TP2 Port. Der Zähler 1 wird für diese Funktion als 10-Bit Zähler benutzt. Der TP1 Port ist auf Masse geschaltet. Die Pulsweite kann durch kurzen Tastendruck um 1% und durch längeren Tastendruck um 10% erhöht werden.
** Mit einer separaten Kapazitäts- und ESR-Messung können an TP1 und TP3 angeschlossene Kondensatoren mit einer Kapazität von etwa 2µF bis 50mF meist auch in der Schaltung gemessen werden. Hierbei sollte aber immer sichergestellt sein, daß die Kondensatoren keine Restladung mehr haben.

Die zusätzlichen Funktionen sind zeitbegrenzt wie die Dialogfunktion selbst auch, wenn die POWER_OFF Option in der Konfigurationsdatei (Makefile) eingeschaltet ist.
Ausführlichere Informationen mit Meßbeispielen kann man in den pdf-Dokumentationen in deutscher und englischer Sprache nachlesen. Auch russische Übersetzung der Dokumentationen sind verfügbar.

== Software ==

Die Software wurde basierend auf der Arbeit von Markus F. weiterentwickelt.
Der Teil für die Kondensatormessung wurde komplett neu geschrieben und auch die Widerstandsmessung wurde erheblich überarbeitet. Bei Schwierigkeiten und Problemen sollte man mich über E-mail oder über den Diskussionsteil (thread) benachrichtigen. Nur wenn ich von Problemen weiß, kann ich hoffentlich Abhilfe schaffen.

Weitere Einzelheiten sowie Beschreibung der einzelnen Meßverfahren und Beispiel-Ergebnisse habe ich in der pdf-Dokumentation (deutsche und englische Version) beschrieben. Hier findet man auch Hinweise zum Konfigurieren der Software mit Makefile Parametern und Optionen.
Die Kommentare im Quellcode sind in englischer Sprache.
Neu eingebaut in der Software ist eine Selbsttest-Funktion, in der die Funktion des Testers gemessen wird. In diesen Selbsttest ist auch ein Kalibrationsteil integriert.

== Hardware ==

Im Prinzip ist die neue Software so zu konfigurieren, daß sie auf der bereits von Markus F. vorgestellten Hardware ohne Änderungen läuft.

Sinnvoll sind dennoch einige Änderungen:

* Der Prozessor sollte auf einen 8 MHz Taktfrequenz umgestellt werden, am besten mit einem externen Quarz. Dazu müssen die fuses des ATmega geändert werden.
* Ein "pull up" Widerstand von etwa 27 kOhm sollte von Pin 13 (PD7) des ATmega nach VCC nachgerüstet werden.
* Der 100 nF Kondensator am Pin 21 (AREF) kann entweder ganz entfernt werden oder besser durch einen 1 nF Kondensator ersetzt werden.
* Wenn die elektronische Einschaltung des Testers Probleme macht, sollte wenigstens der C2 Kondensator an der Basis von Transistor T1 auf 10 nF reduziert werden und ggf. auch der Widerstand R7 auf 3,3 kOhm reduziert werden. Das komplette Schaltbild und Einzelheiten dazu findet man in der PDF Dokumentation.

Die Gründe und die Einzelheiten für diese Änderungen sowie weitere Hinweise für einen Neuaufbau sind im Hardware-Kapitel meiner pdf-Dokumentation beschrieben. Empfohlen wird ein ATmega168 Prozessor oder auch ein ATmega328 Prozessor, weil der ADC mit der Autoscale Funktion im Bedarfsfall von der 5V Referenz (VCC) auf die interne Referenz-Spannung umgeschaltet wird. Die interne Referenz hat für der ATmega8 eine Spannung von 2,56V, für die anderen Prozessoren aber 1,1 Volt. Mit 1,1 V kann eine bessere Auflösung des ADC für gemessene Spannungen unter 1 Volt erreicht werden.
Man kann den ATmega8 ohne Hardwareänderung gegen einen ATmega168 oder ATmega328 austauschen!
Hier ist der Teil der Schaltung, der für die Messung erforderlich ist.
Die Elektronik für die Batterieversorgung und die automatische Abschaltung fehlt in diesem Schaltbild.[[Datei:TransistorTesterVC1.png|miniatur|Schaltbild ohne Stromversorgung]]

Die rot markierten Bauteile sind nicht unbedingt erforderlich, können aber zu einer Verbesserung der Messgenauigkeit beitragen. Die grün markierten Bauteile sind gegenüber dem ersten Entwurf von Markus F. geändert.
Die Eagle Dateien von Asko B. für drei Varianten sind im Thread zu finden bei der Adresse: http://www.mikrocontroller.net/topic/248078?page=4#2891344

Hier ist der Artikel der 1. Transistortester Version von Markus F. zu finden: [[AVR-Transistortester]]

== Diskussionen zur neuen Version ==
Der Thread mit meinen älteren Software-Versionen und einigen Problemfällen sowie Hardware-Vorschlägen ist unter [https://www.mikrocontroller.net/topic/248078#new https://www.mikrocontroller.net/topic/248078#new] zu finden.

== Downloads (deutsch) ==
Alle Versionen von der Software und der Doku sind im SVN gespeichert.

Die Benutzer können über den svnbrowser [https://www.mikrocontroller.net/svnbrowser/transistortester/ https://www.mikrocontroller.net/svnbrowser/transistortester/] das gewählte Verzeichnis als "GNU tarball" runterladen.
Beim Aufruf des svnbrowsers steht dazu unter der Datei/Verzeichnis Liste der Eintrag "Download GNU tarball".

Zum Auspacken der heruntergeladenen transistortester*.tar.gz Datei benötigen Windows Benutzer eine geeignete Software wie das Freeware Paket [http://www.7-zip.org/ 7-Zip].
Nach dem Auspacken hat man den vorher mit dem svnbrowser ausgewählten Verzeichnisbaum auf seinem eigenen Rechner.
Ein direkter Zugriff auf die Dateien mit dem svnbrowser ist nicht möglich!

Eine andere Methode auf den Inhalt des svn Archivs zuzugreifen besteht mit der Installation des TortoiseSVN Plugins für den Windows Explorer.
Damit ist dann der Zugriff über [svn://mikrocontroller.net/transistortester svn://mikrocontroller.net/transistortester] direkt auf das Archiv mit dem Browser möglich.

Linux Benutzer können auch direkt über svn auf das Archiv zugreifen.

== Downloads (russisch) - Загрузки (русский) ==
Для загрузок доступны все версии программного обеспечения и документации, хранящиеся в SVN

Пользователь может загрузить выбранный каталог в качестве "GNU архива" через svnbrowser [https://www.mikrocontroller.net/svnbrowser/transistortester/ https://www.mikrocontroller.net/svnbrowser/transistortester/].

При вызове svnbrowsers, смотрите в список файлов / каталогов, запись "Скачать GNU архив".

Для распаковки загруженного файла * .tar.gz пользователи Windows могут воспользоваться любым подходящим программным обеспечением, таким как бесплатная программа [http://www.7-zip.org/ 7-Zip].

После распаковки архива у вас на компьютере будет архив с заранее выбранным через svnbrowser содержимым в дереве каталогов.

Прямой доступ к файлам через svnbrowser не возможен!

Еще один способ получить доступ к содержимому хранилища SVN состоит в установке TortoiseSVN плагина для Windows Explorer. Это затем кнопкой [svn://mikrocontroller.net/transistortester svn://mikrocontroller.net/transistortester] прямо в вашем архиве, используя браузер.

Пользователи Linux могут получить доступ непосредственно из SVN к архиву.

== Downloads (english) ==
All versions of the software and documentation are saved in the SVN archive.

Users can download a "GNU tarball" of the previous selected directory with the svnbrowser [https://www.mikrocontroller.net/svnbrowser/transistortester/ https://www.mikrocontroller.net/svnbrowser/transistortester/].

Windows users need a additional tool like the freeware [http://www.7-zip.org/ 7-Zip] to unpack the downloaded transistortester*.tar.gz file.
After unpacking you have a copy of the selected directory at your own computer.
The direct access is not possible with the svnbrowser!

Another way to get access to the SVN data is to install the TortoiseSVN plugin for the windows explorer. After installing you can access the data with [svn://mikrocontroller.net/transistortester svn://mikrocontroller.net/transistortester].

Linux users can also access the data with svn directly.

== Downloads (Português - Brasil) ==

Todas as versões de software e documentação estão salvas no arquivador SVN.

Usuários podem descarregar um pacote "GNU" de todos os diretórios anteriores com o svnbrowser [https://www.mikrocontroller.net/svnbrowser/transistortester/ https://www.mikrocontroller.net/svnbrowser/transistortester/].

Usuários de Windows precisam de uma ferramenta adicional como o freeware [http://www.7-zip.org/ 7-Zip] para descompactar o arquivo transistortester*.tar.gz. Depois de descompactado você terá uma cópia do diretório selecionado no seu computador. O acesso direto não é possível com o svnbrowser!

Outra forma de acessar os dados no SVN é instalar o TortoiseSVN plugin para Windows Exporer. Depois de instalar você pode acessar soa dados com o endereçco [svn://mikrocontroller.net/transistortester svn://mikrocontroller.net/transistortester].

Usuários Linux podem acessar os dados com svn diretamente.

== Downloads (Español) ==
Todas la versiones del software y la documentación están en SVN.

Los usuarios pueden descargar un "GNU tarball" del directorio seleccionado utlizando svnbrowser https://www.mikrocontroller.net/svnbrowser/transistortester/

Los usuarios de Windows requieren de una herramienta adicional como el freeware 7-Zip (gratis) para desempacar el archivo descargado, transistortester*.tar.gz.

Luego de desempacar el archivo, tendrá en su computador una copia completa del directorio seleccionado.
Acceso directo no es posible con svnbrowser.

La otra manera de accesar el respositorio SVN es instalando el plugin TortoiseSVN; éste le permitirá acceso a la información con el URI: svn://mikrocontroller.net/transistortester

Los usuarios de Linux pueden, por supuesto, accesar SVN directamente.

== Downloads (your-language) ==

You can put a translation ''here'', but only if its done by yourself, not Google Translate.

You can also put a translation of the whole article here, if its done by yourself.

Only little understanding of the Wiki-Syntax is needed therefore.

== Verzeichnisstruktur des SVN ==
{| border="1" cellspacing="0" style="border-collapse:collapse"
|+ '''Ordnerstruktur und Beschreibung der ''Pfade'' im SVN'''
|- style="background-color:#B3B7FF"
| style="text-align:center" colspan="2" | '''Ordner/directory''' || '''Dateien/files''' || '''Beschreibung/description'''
|- style="background-color:#B9FFC5"
| '''Doku''' || || || Enthält die Dokumentation als PDF und als pdflatex-Quelltext
|-
| || '''trunk''' || || Letzter Entwicklungsstand der Dokumentation inclusive Bilder und Diagrammen
|-
| || '''trunk/pdftex/german''' || || enthält die deutschen Texte, Makefile und PDF-Dokumentation der Entwicklerversion
|-
| || '''trunk/pdftex/english''' || || contains the English text, Makefile and PDF documentation of the developer version
|-
| || '''trunk/pdftex/russian''' || || contains the Russian text, Makefile and PDF documentation of the developer version
|-
| || '''tags''' ||''changelog.txt'' || ''Hier sollte jede Änderung mit Versionsnummer eingetragen werden''
|-
| || '''tags/german''' || || ''Aktuelle PDF Dokumentation in deutsch''
|-
| || '''tags/english''' || || ''Current PDF documentation in English''
|-
| || '''tags/russian''' || || ''Current PDF documentation in Russian language''
|-
| || '''tags/old/german''' || || ''PDF Dokumentationen zu früheren Softwareversionen''
|-
| || '''tags/old/english''' || || ''PDF documentation for earlier software versions''

|- style="background-color:#B9FFC5"
| '''Hardware''' || || || Hardware Beschreibung
|-
| || '''strip_grid''' || || Verzeichnis für eine Streifenleiterplatine
|-
| || '''strip_grid/ttester_strip_grid.diy''' || || Beispiel einer Streifenleiterplatine, DIYLC-Datei
|-
| || '''strip_grid/TTester_strip.pdf''' || || Ergebnis der Streifenleiterplatine im PDF Format
|-
| || '''strip_grid/LiesMich.txt''' || || Kurzdokumentation für Streifenleiter-Platine
|-
| || '''strip_grid/ReadMe.txt''' || || Short documentation for the strip grid board
|-
| || '''Markus''' || || Entwurf von Markus R. mit LED-Dimmer im Eagle 6.4.0 Format

|- style="background-color:#B9FFC5"
| '''Software''' || || || Software für AVR-GCC 4.5.3
|-
| || '''trunk''' || || Aktueller Software-Entwicklungszweig
|-
| || '''trunk/default''' || || Makefile und Programmierdaten für ATmega168 mit Standard-Layout
|-
| || '''trunk/mega168_1.9V''' || || Makefile und Daten für ATmega168 mit Knopfzellenbetrieb (FiFi)
|-
| || '''trunk/mega168_3.3V''' || || Makefile und Daten für ATmega168 mit LiPo-Akkubetrieb (FiFi)
|-
| || '''trunk/mega328''' || || Makefile und Daten für ATmega328 mit Standard-Layout (ab Version 1.08k)
|-
| || '''trunk/mega328_1.9V''' || || Makefile und Daten für ATmega328 mit Knopfzellenbetrieb (Funkamateur)
|-
| || '''trunk/mega328_3.3V''' || || Makefile und Daten für ATmega328 mit LiPo-Akkubetrieb (Funkamateur)
|-
| || '''trunk/mega168_strip_grid''' || || Makefile und Daten für ATmega168 für Streifenleiter-Platine
|-
| || '''trunk/mega328_strip_grid''' || || Makefile und Daten für ATmega328 für Streifenleiter-Platine (ab Version 1.08k)
|-
| || '''trunk/mega328_strip_grid_dogm''' || || Makefile und Daten für ATmega328 für Streifenleiter-Platine mit DOG-M Display
|-
| || '''trunk/mega8''' || || Makefile und Daten für ATmega8. Ab Version 1.00k ist der Selbsttest für den ATmega8 nicht mehr konfigurierbar.

|-
| || '''tags''' || || Fertige Software Versionen als ZIP gepackt
|-
| || || ''changelog.txt'' || ''Hier sollte jede Änderung mit Versionsnummer eingetragen werden''
|-
| || '''Markus''' || || Alternative Software von Markus R., bitte README beachten! Die Software wurde aufgeräumt und ist viel besser strukturiert, läuft aber nur auf einem ATmega168 oder ATmega328. Die Software läuft nur auf dem Standard-Layout.
|-
|}

[[Kategorie:AVR-Projekte]]

AVR Transistortester

2015-03-19T20:54:06Z

Maybee: Änderung 87999 von 36.84.125.217 (Diskussion) rückgängig gemacht.

== Einleitung ==

Original Entwurf: http://www.mikrocontroller.net/articles/AVR-Transistortester

Weiterentwickelt von Karl-Heinz Kübbeler

Ich habe das Transistortester Projekt von Markus Frejek weitergeführt und speziell die Software weiterentwickelt.
Aufgrund der verbesserten Eigenschaften wurde schon der Name Komponententester vorgeschlagen. Ich selbst sehe aber immer noch die herausragende Eigenschaft in der automatischen Bestimmung von Transistortyp und Eigenschaft, wie sie von
Markus Frejek entwickelt wurde.

Hier möchte ich die wichtigsten '''Eigenschaften''' aufführen

* Arbeitet mit ATmega8, ATmega168 und ATmega328 Prozessoren.
* Anzeige der Meßergebnisse auf ein 2x16 Zeichen LCD.
* Statt dem 2x16 Zeichen LCD kann auch ein graphisches Display mit ST7565 Controller benutzt werden. Auch ein Anschluß eines OLED Display mit SSD1306 Controller ist mit SPI oder I2C Schnittstelle möglich.
* Ein-Tastenbedienung mit automatischer Abschaltung.
* Das Gerät besitzt drei universelle Meßports (Test Pin).
* Automatische Erkennung von NPN, PNP, N- und P-Kanal MOSFET, JFET, Dioden und Kleinsignal Thyristor und TRIAC.
* Automatische Erkennung der Pin-Belegung der Bauteile, die Bauelemente können beliebig angeschlossen werden.
* Messung des Stromverstärkungsfaktors und der Basis-Emitter Spannung für bipolare Transistoren, auch für Darlingtontransistoren.
* Automatische Erkennung eine Schutzdiode für bipolare Transistoren und MOSFETs.
* Bei bipolaren Transistoren mit Schutzdiode wird ein parasitärer Transistor erkannt (NPNp = NPN + parasitär PNP).
* Bis zu zwei Widerstände werden in einer Messung mit einer Auflösung von bis zu 0,1 Ohm gemessen, wobei der Meßbereich bis über 50 MOhm reicht. Widerstandswerte unter 10 Ohm werden für den ATmega168/328 mit der ESR-Meßmethode mit einer Auflösung von 0.01 Ohm angezeigt.
* Ein angeschlossener Kondensator kann gemessen werden im Bereich 35pF bis 100mF mit einer Auflösung von bis zu 1 pF.
* Widerstände und Kondensatoren werden mit ihren Symbolen dargestellt, umgeben von den gefundenen Anschlußpin Nummern.
* Die Widerstands und Kondensator-Werte werden mit bis zu vier Dezimalstellen in der richtigen Dimension angezeigt.
* Bis zu zwei Dioden werden ebenfalls mit ihrer Symboldarstellung flußrichtungsrichtig angezeigt, umgeben von den Anschlußpin Nummern und der zusätzlichen Angabe der Flußspannung.
* Bei einzelnen Dioden wird zusätzlich der Kapazitätswert und ab Version 1.08k auch der Strom in Sperr-Richtung gemessen.
* Für ATmega168/328 ist eine Kalibration der Nullkapazität, des Nullwiderstandes und weiterer Parameter im Selbsttest-Zweig möglich.
* Für ATmega168/328 können auch Induktivitäten von etwa 0.01mH bis über 20H erkannt und gemessen werden.
* Für ATmega168/328 ist eine ESR-Messung (Equivalent Series Resistance) für Kondensatoren über 90 nF mit einer Auflösung von 0.01 Ohm integriert.
* für ATmega168/328 wird für Kondensatoren über 5 nF der Spannungsverlust Vloss nach einem Ladepuls untersucht. Damit läßt sich die Güte der Kondensatoren abschätzen.
* für ATmega328 sind mit einer Menüfunktion, die mit einem längeren Tastendruck (> 0.5 s) aufgerufen werden kann, weitere Funktionen aus einer Liste möglich. Ein kurzer Tastendruck zeigt die nächste Funktion. Ein längerer Tastendruck startet die angezeigte Funktion. Nachfolgend die Liste der bisher eingebauten Zusatzfunktionen:
** Frequenzmessung an dem PD4 Pin, der aber auch für den LCD-Anschluß benutzt wird. Der Pin wird für die Messung auf Eingang umgeschaltet. Die anliegende Frequenz wird zunächst für 1 Sekunde ausgezählt. Wenn die Frequenz unter 25 kHz liegt, wird auch eine mittlere Periode gemessen und daraus eine Frequenz berechnet mit einer Auflösung von bis zu 0.001 mHz.
** Spannungsmessung am PC3 Pin, wenn dieser nicht für die serielle Ausgabe benutzt wird. Bei ATmega328 mit 32 Pins (PLCC) kann aber auch der ADC6 oder ADC7 Pin benutzt werden. Da ein 10:1 Teiler am Eingang benutzt wird, können Spannungen bis zu 50V gemessen werden. Mit einer Erweiterung der Schaltung (DC-DC Konverter) können auch Zenerdioden gemessen werden.
** Frequenzerzeugung am TP2 Port. Über den am PB2 Pin angeschlossenen 680 Ohm Widerstand kann ein Signal mit einer aus einer Liste einstellbaren Frequenz von 1 Hz bis 2 MHz am TP2 Port ausgegeben werden. Der TP1 Port ist dabei auf Masse geschaltet.
** Pulsweitenmodulation mit fester Frequenz und einstellbarer Pulsweite auf dem TP2 Port. Der Zähler 1 wird für diese Funktion als 10-Bit Zähler benutzt. Der TP1 Port ist auf Masse geschaltet. Die Pulsweite kann durch kurzen Tastendruck um 1% und durch längeren Tastendruck um 10% erhöht werden.
** Mit einer separaten Kapazitäts- und ESR-Messung können an TP1 und TP3 angeschlossene Kondensatoren mit einer Kapazität von etwa 2µF bis 50mF meist auch in der Schaltung gemessen werden. Hierbei sollte aber immer sichergestellt sein, daß die Kondensatoren keine Restladung mehr haben.

Die zusätzlichen Funktionen sind zeitbegrenzt wie die Dialogfunktion selbst auch, wenn die POWER_OFF Option in der Konfigurationsdatei (Makefile) eingeschaltet ist.
Ausführlichere Informationen mit Meßbeispielen kann man in den pdf-Dokumentationen in deutscher und englischer Sprache nachlesen. Auch russische Übersetzung der Dokumentationen sind verfügbar.

== Software ==

Die Software wurde basierend auf der Arbeit von Markus F. weiterentwickelt.
Der Teil für die Kondensatormessung wurde komplett neu geschrieben und auch die Widerstandsmessung wurde erheblich überarbeitet. Bei Schwierigkeiten und Problemen sollte man mich über E-mail oder über den Diskussionsteil (thread) benachrichtigen. Nur wenn ich von Problemen weiß, kann ich hoffentlich Abhilfe schaffen.

Weitere Einzelheiten sowie Beschreibung der einzelnen Meßverfahren und Beispiel-Ergebnisse habe ich in der pdf-Dokumentation (deutsche und englische Version) beschrieben. Hier findet man auch Hinweise zum Konfigurieren der Software mit Makefile Parametern und Optionen.
Die Kommentare im Quellcode sind in englischer Sprache.
Neu eingebaut in der Software ist eine Selbsttest-Funktion, in der die Funktion des Testers gemessen wird. In diesen Selbsttest ist auch ein Kalibrationsteil integriert.

== Hardware ==

Im Prinzip ist die neue Software so zu konfigurieren, daß sie auf der bereits von Markus F. vorgestellten Hardware ohne Änderungen läuft.

Sinnvoll sind dennoch einige Änderungen:

* Der Prozessor sollte auf einen 8 MHz Taktfrequenz umgestellt werden, am besten mit einem externen Quarz. Dazu müssen die fuses des ATmega geändert werden.
* Ein "pull up" Widerstand von etwa 27 kOhm sollte von Pin 13 (PD7) des ATmega nach VCC nachgerüstet werden.
* Der 100 nF Kondensator am Pin 21 (AREF) kann entweder ganz entfernt werden oder besser durch einen 1 nF Kondensator ersetzt werden.
* Wenn die elektronische Einschaltung des Testers Probleme macht, sollte wenigstens der C2 Kondensator an der Basis von Transistor T1 auf 10 nF reduziert werden und ggf. auch der Widerstand R7 auf 3,3 kOhm reduziert werden. Das komplette Schaltbild und Einzelheiten dazu findet man in der PDF Dokumentation.

Die Gründe und die Einzelheiten für diese Änderungen sowie weitere Hinweise für einen Neuaufbau sind im Hardware-Kapitel meiner pdf-Dokumentation beschrieben. Empfohlen wird ein ATmega168 Prozessor oder auch ein ATmega328 Prozessor, weil der ADC mit der Autoscale Funktion im Bedarfsfall von der 5V Referenz (VCC) auf die interne Referenz-Spannung umgeschaltet wird. Die interne Referenz hat für der ATmega8 eine Spannung von 2,56V, für die anderen Prozessoren aber 1,1 Volt. Mit 1,1 V kann eine bessere Auflösung des ADC für gemessene Spannungen unter 1 Volt erreicht werden.
Man kann den ATmega8 ohne Hardwareänderung gegen einen ATmega168 oder ATmega328 austauschen!
Hier ist der Teil der Schaltung, der für die Messung erforderlich ist.
Die Elektronik für die Batterieversorgung und die automatische Abschaltung fehlt in diesem Schaltbild.[[Datei:TransistorTesterVC1.png|miniatur|Schaltbild ohne Stromversorgung]]

Die rot markierten Bauteile sind nicht unbedingt erforderlich, können aber zu einer Verbesserung der Messgenauigkeit beitragen. Die grün markierten Bauteile sind gegenüber dem ersten Entwurf von Markus F. geändert.
Die Eagle Dateien von Asko B. für drei Varianten sind im Thread zu finden bei der Adresse: http://www.mikrocontroller.net/topic/248078?page=4#2891344

Hier ist der Artikel der 1. Transistortester Version von Markus F. zu finden: [[AVR-Transistortester]]

== Diskussionen zur neuen Version ==
Der Thread mit meinen älteren Software-Versionen und einigen Problemfällen sowie Hardware-Vorschlägen ist unter [http://www.mikrocontroller.net/topic/248078#new http://www.mikrocontroller.net/topic/248078#new] zu finden.

== Downloads ==
Alle Versionen von der Software und der Doku sind im SVN gespeichert.
Die Benutzer können über den svnbrowser [http://www.mikrocontroller.net/svnbrowser/transistortester/ http://www.mikrocontroller.net/svnbrowser/transistortester/] das gewählte Verzeichnis als "GNU tarball" runterladen.
Beim Aufruf des svnbrowsers steht dazu unter der Datei/Verzeichnis Liste der Eintrag "Download GNU tarball".
Zum Auspacken der heruntergeladenen transistortester*.tar.gz Datei benötigen Windows Benutzer eine geeignete Software wie das Freeware Paket [http://www.7-zip.org/ 7-Zip].
Nach dem Auspacken hat man den vorher mit dem svnbrowser ausgewählten Verzeichnisbaum auf seinem eigenen Rechner.
Ein direkter Zugriff auf die Dateien mit dem svnbrowser ist nicht möglich!
Eine andere Methode auf den Inhalt des svn Archivs zuzugreifen besteht mit der Installation des TortoiseSVN Plugins für den Windows Explorer.
Damit ist dann der Zugriff über [svn://mikrocontroller.net/transistortester svn://mikrocontroller.net/transistortester] direkt auf das Archiv mit dem Browser möglich.
Linux Benutzer können auch direkt über svn auf das Archiv zugreifen.

== Downloads (russisch) ==
 == Загрузок == Все версии программного обеспечения и документации, хранятся в SVN. 
 Пользователь может загрузить выбранный каталог в качестве "GNU архива" за svnbrowser [http://www.mikrocontroller.net/svnbrowser/transistortester/ http://www.mikrocontroller.net/svnbrowser/transistortester/]. 
 При вызове svnbrowsers, смотрите в список файлов / каталогов, запись "Скачать GNU архив". 
 Для распаковки загруженного транзистор тестер файл * .tar.gz вам нужно пользователи Windows подходящий программного обеспечения, таких как бесплатный пакет [http://www.7-zip.org/ 7-Zip]. 
 После распаковки у нас есть собственный заранее с svnbrowser выбран в дереве каталогов на своем компьютере. 
 Прямой доступ к файлам с svnbrowser не возможно! 
 Еще один способ получить доступ к содержимому хранилища SVN состоит из установки TortoiseSVN плагин для Windows Explorer. 
 Это затем кнопкой [SVN://mikrocontroller.net/transistortester SVN://mikrocontroller.net/transistortester] прямо в вашем архиве, используя браузер. 
 Пользователи Linux могут получить доступ непосредственно из SVN в архив.

== Downloads (english) ==
All versions of the software and documentation are saved in the SVN archive.
Users can download a "GNU tarball" of the previous selected directory with the svnbrowser [http://www.mikrocontroller.net/svnbrowser/transistortester/ http://www.mikrocontroller.net/svnbrowser/transistortester/].
Windows users need a additional tool like the freeware 7-Zip to unpack the downloaded transistortester*.tar.gz file.
After unpacking you have a copy of the selected directory at your own computer.
The direct access is not possible with the svnbrowser!

Another way to get access to the SVN data is to install the TortoiseSVN plugin for the windows explorer. After installing you
can access the data with [svn://mikrocontroller.net/transistortester svn://mikrocontroller.net/transistortester] .

Linux users can also access the data with svn directly.

{| class="wikitable"
|+ '''Ordnerstruktur und Beschreibung der ''Pfade'' im SVN'''
|- style="background-color:#B3B7FF"
| style="text-align:center" colspan="2" | '''Ordner/directory''' || '''Dateien/files''' || '''Beschreibung/description'''
|- style="background-color:#B9FFC5"
| '''Doku''' || || || Enthält die Dokumentation als PDF und als pdflatex-Quelltext
|-
| || '''trunk''' || || Letzter Entwicklungsstand der Dokumentation inclusive Bilder und Diagrammen
|-
| || '''trunk/pdftex/german''' || || enthält die deutschen Texte, Makefile und PDF-Dokumentation der Entwicklerversion
|-
| || '''trunk/pdftex/english''' || || contains the English text, Makefile and PDF documentation of the developer version
|-
| || '''trunk/pdftex/russian''' || || contains the Russian text, Makefile and PDF documentation of the developer version
|-
| || '''tags''' ||''changelog.txt'' || ''Hier sollte jede Änderung mit Versionsnummer eingetragen werden''
|-
| || '''tags/german''' || || ''Aktuelle PDF Dokumentation in deutsch''
|-
| || '''tags/english''' || || ''Current PDF documentation in English''
|-
| || '''tags/russian''' || || ''Current PDF documentation in Russian language''
|-
| || '''tags/old/german''' || || ''PDF Dokumentationen zu früheren Softwareversionen''
|-
| || '''tags/old/english''' || || ''PDF documentation for earlier software versions''

|- style="background-color:#B9FFC5"
| '''Hardware''' || || || Hardware Beschreibung
|-
| || '''strip_grid''' || || Verzeichnis für eine Streifenleiterplatine
|-
| || '''strip_grid/ttester_strip_grid.diy''' || || Beispiel einer Streifenleiterplatine, DIYLC-Datei
|-
| || '''strip_grid/TTester_strip.pdf''' || || Ergebnis der Streifenleiterplatine im PDF Format
|-
| || '''strip_grid/LiesMich.txt''' || || Kurzdokumentation für Streifenleiter-Platine
|-
| || '''strip_grid/ReadMe.txt''' || || Short documentation for the strip grid board
|-
| || '''Markus''' || || Entwurf von Markus R. mit LED-Dimmer im Eagle 6.4.0 Format

|- style="background-color:#B9FFC5"
| '''Software''' || || || Software für AVR-GCC 4.5.3
|-
| || '''trunk''' || || Aktueller Software-Entwicklungszweig
|-
| || '''trunk/default''' || || Makefile und Programmierdaten für ATmega168 mit Standard-Layout
|-
| || '''trunk/mega168_1.9V''' || || Makefile und Daten für ATmega168 mit Knopfzellenbetrieb (FiFi)
|-
| || '''trunk/mega168_3.3V''' || || Makefile und Daten für ATmega168 mit LiPo-Akkubetrieb (FiFi)
|-
| || '''trunk/mega328''' || || Makefile und Daten für ATmega328 mit Standard-Layout (ab Version 1.08k)
|-
| || '''trunk/mega328_1.9V''' || || Makefile und Daten für ATmega328 mit Knopfzellenbetrieb (Funkamateur)
|-
| || '''trunk/mega328_3.3V''' || || Makefile und Daten für ATmega328 mit LiPo-Akkubetrieb (Funkamateur)
|-
| || '''trunk/mega168_strip_grid''' || || Makefile und Daten für ATmega168 für Streifenleiter-Platine
|-
| || '''trunk/mega328_strip_grid''' || || Makefile und Daten für ATmega328 für Streifenleiter-Platine (ab Version 1.08k)
|-
| || '''trunk/mega328_strip_grid_dogm''' || || Makefile und Daten für ATmega328 für Streifenleiter-Platine mit DOG-M Display
|-
| || '''trunk/mega8''' || || Makefile und Daten für ATmega8. Ab Version 1.00k ist der Selbsttest für den ATmega8 nicht mehr konfigurierbar.
|-
| || '''tags''' || || Fertige Software Versionen als ZIP gepackt
|-

| || || ''changelog.txt'' || ''Hier sollte jede Änderung mit Versionsnummer eingetragen werden''
|-
| || '''Markus''' || || Alternative Software von Markus R., bitte README beachten! Die Software wurde aufgeräumt und ist viel besser strukturiert, läuft aber nur auf einem ATmega168 oder ATmega328. Die Software läuft nur auf dem Standard-Layout.
|-
|}

[[Kategorie:AVR-Projekte]]

RFM69

2015-03-08T09:04:57Z

Maybee: /* Funtionsweise */

[[Datei:rf69cw.png|thumb|300px|RFM69CW, Pinkompatibel zum RFM12]]
Das RFM69 von HopeRF ist ein universelles Funkmodul für die ISM-Frequenzbänder 315, 433, 868 und 915 MHz. Eine [[SPI]]-Schnitttstelle ermöglicht die einfache Integration in Mikrocontrollerprojekte.

== Ausführungen ==
* RFM69HCW, mit zusätzlicher PA, 20 dBm, als Ersatz für den RFM22B gedacht
* RFM69HW, mit zusätzlicher PA, 20 dBm
* RFM69CW, Pinkompatibel zum RFM12B
* RFM69W

Die CW-Variante hat 2 Pins weniger (es fehlt der Pin DIO4), und ist Pinkompatibel zum Vorgänger RFM12B.
Es kann ohne Änderung am Layout oder der Schaltung ausgetauscht werden. Lediglich die Software muss angepasst werden.

== Ausstattung ==
* Betriebsspannung 1,8 - 3,6 V
* SPI-Schnittstelle
* FSK- und OOK-Modulation (Frequency Shift Keying = Frequenzumtastung, On-Off-Keying = Amplitudentastung)
* Eingebauter Manchesterde- und -encoder
* Frequenzbereiche 315, 433, 868, 915 MHz
* Max. Datenrate 300 kbit/s
* Ausgangsleistung +13 dBm (rund 20 mW)
* Stromaufnahme 45 mA senden (13 dBm), 16 mA empfangen, 0,1 µA Standby
* Integrierte Packetengine für Synchronwort, CRC, Scrambling und AES-Verschlüsselung
* 66 Byte FIFO
* Modul basiert auf dem SX1231 von Semtech

== Vergleich zum RFM12B ==

{| class="wikitable"
|-
! !! RFM12B !! RFM69(C)W
|-
| Versorgungsspannung || 2,2 - 3,8 V || 1,8 - 3,6 V
|-
| Max. Datenrate || 115,2 kbit/s || 300 kbit/s
|-
| Sendeleistung || 5 dBm || 13 dBm
|-
| Empfindlichkeit || -105 dB || -120 dB
|-
| Stromaufnahme || 22 mA/11 mA/0,3 µA || 45 mA/16 mA/0,1 µA
|-
| FIFO Größe || 16 Bit || 66 Bytes
|-
| Syncmustererkennung || Fest 0x2DD4 oder 0xD4 || Frei bis zu 8 Bytes
|}

== Ansteuerung ==
Das Funkmodul kommuniziert über die SPI Schnittstelle mit dem µC. Im einfachsten Fall werden SCK, MISO, MOSI und NSS benötigt. Am besten führt man auch noch DIO0 zum Prozessor. Dieser Pin kann softwareseitig so konfiguriert werden, dass er anzeigt, wenn ein Paket vollständig gesendet oder ein neues Paket empfangen wurde. Ist das Modul in Minimalkonfiguration angeschlossen, müssen dazu die Statusregister RegIrqFlags1 (0x27) oder RegIrqFlags2 (0x28) ausgelesen werden.

Die SPI-Ansteuerung erfolgt im Modus CPOL=0, CPHA=0, wobei jeweils 16 Bits vom µC zum Modul geschickt werden:
Das erste Bit teilt dem Modul mit, ob es sich um einen Lese- (Bitwert 0) oder Schreibvorgang (Bitwert 1) handelt, die restlichen sieben Bit des ersten Bytes geben die Registeradresse an. Mit den zweiten acht Bit wird im Schreibmodus der zu übertragende Befehl an das Modul übermittelt, im Lesemodus kann eine beliebige Bitfolge gesendet werden. Während das zweite Bit gesendet wird, empfängt der µC sowohl im Lese- als auch im Schreibmodus den Inhalt des angesprochenen Registers vor dem aktuellen Zugriff.

Werden nach dem Adressbyte mehrere Bytes empfangen oder gelesen, wird der Adresszeiger im RFM69 automatisch inkrementiert, so dass in einem einzigen Burst mehrere Register gelesen werden können. Zu beachten ist dabei, dass in Registern die mehr als 8 Bit breit sind (Frequenz, Bitrate, ...), das höchstwertige Byte zu erst geschrieben/gelesen wird (big endian). Wird das FIFO Register gelesen/geschrieben, wird der Adresszeiger nicht inkrementiert, so dass auf das FIFO in einem Burst zugegriffen werden kann.

== Funktionsweise ==
Es gibt zwei grundsätzliche Funktionsmodi, die im Register "RegDataModule" gewählt werden:
=== Continuous Mode ===
Für die Datenübertragung vom/zum Modul werden die beiden Pins "DIO1/DCLK" und "DIO2/DATA" verwendet. An DCLK gibt das Modul den Takt vor mit dem die Datenbits an DATA geschrieben oder gelesen werden müssen.
=== Packet Mode ===
Die Packetengine des RFM69 kümmert sich um die Erzeugung und Auswertung der Preamble, des Synchronwortes, des Scramblings, der CRC und der Verschlüsselung. Im Sendebetrieb bearbeitet die eingebaute Packet Engine ein Nutzdatenpaket folgendermaßen:
==== Fixed Length Format ====
===== Senden =====
* Einstellbare Anzahl (0-65535) von Preamblebytes (0xAA) an den Anfang setzen
* Synchronwort hinzufügen (Länge zwischen 0-8 Bytes einstellbar, Synchronwort selbst ebenfalls einstellbar)
* Nutzdaten hinzufügen (Länge wird in einem Register angegeben)
* CRC hinzufügen (abschaltbar)

== Interrupts ==
{| class="wikitable"
|-
! Bezeichnung !! Beschreibung !! Verfügbar an
|-
| ModeReady || Beispiel || DIO5
|-
| RxReady || Beispiel || Beispiel
|-
| TxReady || Beispiel || DIO3, DIO0
|-
| PllLock || Beispiel || DIO3, DIO1, DIO0
|-
| Rssi || Beispiel || DIO3, DIO0
|-
| Timeout || Beispiel || DIO1
|-
| AutoMode || Beispiel || DIO2
|-
| SyncAddressMatch|| Beispiel || DIO3, DIO0
|-
| FifoFull || Beispiel || DIO3, DIO1
|-
| FifoNotEmpty || || DIO2, DIO1
|-
| FifoLevel || || DIO1
|-
| FifoOverrun || ||
|-
| PacketSent || || DIO0
|-
| PayloadReady || || DIO0
|-
| CrcOk || || DIO0
|}

== Pinbelegung RFM69(H)CW ==
{| class="wikitable"
|-
! Pinnummer !! Name !! Richtung !! Beschreibung !! Pin am RFM12
|-
| 1 || ANA || || Antennenanschluss || ANT
|-
| 2 || 3.3V || || Versorgungsspannung || VDD
|-
| 3 || GND || || || GND
|-
| 4 || DIO3 || || FifoFull PllLock Rssi SyncAdress TXReady || nINT/VDI
|-
| 5 || MOSI || || SPI Daten Eingang || SDI
|-
| 6 || SCK || || SPI Takt || SCK
|-
| 7 || NSS || || Chip select || nSEL
|-
| 8 || MISO || || SPI Daten Ausgang || SDO
|-
| 9 || DIO0 || || PllLock (FS, TX) CrcOK (RX) PayloadReady (RX) SyncAddress (RX) Rssi (RX) PacketSent (TX) TxReady (TX) || nIRQ
|-
| 10 || DIO2 || || FifoNotEmpty (Sleep, Stdby, FS, RX, TX) AutoMode(Sleep, Stdby, FS, RX, TX) Data (RX, TX) || FSK/DATA/nFFS
|-
| 11 || DIO1 || || FifoLevel (Sleep, Stdby, FS, RX, TX) FifoFull (Sleep, Stdby, FS, RX, TX) FifoNotEmpty (Sleep, Stdby, FS, RX, TX) PllLock (FS, TX) Timeout (RX) || DCLK/CFIL/FFIT
|-
| 12 || DIO5 || || ModeReady ClkOut (Stdby, FS, RX, TX) Data (RX, TX) || CLK
|-
| 13 || RESET || || || nRES
|-
| 14 || GND || || || GND
|}

== Register ==
{| class="wikitable"
|-
! Adresse !! Registername !! Beschreibung !! Beispiel
|-
| 0x00 || RegFifo || Zugriff auf das FIFO Register
|-
| 0x01 || RegOpMode || Betriebsart (senden, empfangen, ...) || 0x04 = Empfangen
|-
| 0x02 || RegDataModule || Modulationsart &-shaping, Packetengine || 0x00 = FSK, Packetengine aktiv
|-
| 0x03 - 0x04|| RegBitrate || = FXOSC/Bitrate || 0x1A0B = 6667 -> 4,8 kbit/s
|-
| 0x05 - 0x06 || RegFdev || Frequenzabweichung (Hub * 2) || 0x52 = 82 -> 5 kHz
|-
| 0x07 - 0x09 || RegFrf || Mittenfrequenz || 0xD91333 = 14226227 -> 868,300 MHz
|-
| 0x11|| RegPaLevel || Sendeleistung || 0x12 = 18 -> 0 dBm
|-
| 0x19|| RegRxBw || Filterbandbreite || 0b01001 -> 200 kHz
|-
| 0x25|| RegDioMapping1 || DIO Funktionen ||
|-
| 0x27|| RegIrqFlags1 || Statusflags (ModeReady, RxReady, TxReady, PllLock, RSSI, Timeout, AutoMode, SyncAddressMatch) || 0xD0 -> Empfänger bereit zum Datenempfang
|-
| 0x28|| RegIrqFlags2 || Statusflags (FifoFull, FifoNotEmpty, FifoLevel, FifoOverrun, PacketSent, PayloadReady, CrcOk, LowBat) || 0x06 -> Daten mit erfolgreichem CRC empfangen
|-
| 0x2C - 0x2D|| RegPreamble || Preamblelänge ||
|-
| 0x2E || RegSyncConfig || Synchronworteinstellungen ||
|-
| 0x2F - 0x36 || RegSyncValue || Synchronwort || 0x2DD4
|-
| 0x37 || RegPacketConfig1 || Einstellungen Packetengine ||
|-
| 0x38 || RegPayloadLength || Datenpacketgröße ||
|}

== Projekte ==
=== FS20 Funksteckdosen schalten ===
Da das RFM69 OOK modulieren kann, können damit die FS20 Funksteckdosen geschaltet werden. FS20 verwendet allerdings eine Art Pulsdauermodulation; eine 1 wird mit 600 µs Träger an gefolgt von 600 µs Träger aus, und eine 0 mit 400 µs an gefolgt von 400 µs aus übertragen. Man teilt einfach das Signal in 200 µs Schlitze ein (OOK-Datenrate 5 kbit/s), und sendet für eine 1 die Folge 111000 und für eine 0 die Folge 1100. Im FS20 Protokoll wird ein 13 Bit langer Header (0000000000001) übertragen, diesen kann man umrechnen und im RFM69 als Syncword einstellen. So wird der Header vom RFM69 bei jeder Übertragung automatisch vorweg ausgesendet.

=== Conrad Energy Count 3000 ===
Unter http://forum.jeelabs.net/node/3412679.html?page=1 wurde schon das Protokoll der Conrad Energy Count 3000 (baugleich mit Technoline Cost Control RC) Funk-Energiekostenmessgeräte beschrieben. Mit dem RFM69 lässt sich ein Frame des Messgerätes mit dem konfigurierbarem Synchronwortfinder bequem empfangen.

=== LaCrosse Temperatursensoren empfangen ===
=== Open Energy Monitor empfangen ===

== Bezugsquellen ==
* [http://shop.seegel-systeme.de/Bauelemente/Funkmodul-RFM69CW-REV-V1-0-868-MHz-SMD.html Seegel Systeme]
* Pollin: [http://www.pollin.de/shop/dt/Nzk2OTgxOTk-/Bausaetze_Module/Module/Funkmodul_HOPERF_RFM69CW_433_MHz_TX_RX.html 433 MHz] / [http://www.pollin.de/shop/dt/Njk2OTgxOTk-/Bausaetze_Module/Module/Funkmodul_HOPERF_RFM69CW_868_MHz_TX_RX.html 868 MHz]
* [http://www.aliexpress.com/item/RFM69CW-13dBm-transceiver-module-pin-to-pin-compatible-to-RFM12B-433-868-915mhz-can-be-selected/2010762457.html AliExpress]

== Links ==
* [http://www.hoperf.com/upload/rf/RFM69CW-V1.1.pdf Datenblatt RFM69CW]
* [http://www.hoperf.com/upload/rf/RFM69W-V1.3.pdf Datenblatt RFM69W]
* [http://www.semtech.com/images/datasheet/sx1231.pdf Datenblatt Semtech SX1231]
* [http://www.semtech.com/images/datasheet/AN1200.18_STD.pdf Application Note zur Softwareimplementierung von Data-Whitening und CRC]
* [http://www.mikrocontroller.net/topic/332579 Thread im Forum: Wer verwendet RFM69]

[[Kategorie:RFM12]]
[[Kategorie:Funk]]

LED

2015-03-05T18:14:08Z

Maybee: Änderung 87703 von 2A02:1205:C694:59C0:FC76:B0D0:853B:7FBC (Diskussion) rückgängig gemacht.

== Beschreibung ==

[[Bild:Ledrgb.jpg|thumb|right|246px|Detailfoto einer RGB-LED [http://www.mikrocontroller.net/topic/109784#990685]]]

Eine LED (engl. Light Emitting Diode, ''Leuchtdiode'') besteht aus einem [[Halbleiter]]-PN-Übergang, der durch seine Zusammensetzung Licht eines stark begrenzten Wellenbereiches emittiert, wenn er in Durchlassrichtung von Strom durchflossen wird. Die Helligkeit einer LED ist in erster Näherung proportional zum Strom.

Die Farbe des emittierten Lichts hängt vom verwendeten Halbleitermaterial ab. Es existieren [[Halbleiter | Halbleitermaterialien]] für den gesamten sichtbaren Bereich als auch für den Infrarotbereich und den nahen Ultraviolettbereich. Für kurze Wellenlängen (Blau bis Ultraviolett) ist ein Halbleitermaterial wie z. B. InGaN oder GaN erforderlich. Für die ersten blauen LEDs wurde SiC verwendet, welche aber eine schlechte Effizienz hat (Quelle:Wikipedia).

Weißes Licht oder andere Farbmischungen können erzeugt werden, indem man eine Blau- oder Ultraviolett-LED mit einem Phosphormaterial beschichtet, welches durch das Licht der LED zur Emission angeregt wird. Die entstehende Farbe wird dabei von der Beschichtung bestimmt.

{{Absatz}}
== Durchlassspannung ==

LEDs haben im Vergleich zu gewöhnlichen [[Diode|Dioden]] eine vergleichsweise hohe, vom Halbleitermaterial abhängige [[Durchlass-Spannung]]. Bevor diese erreicht wird, fließt nur sehr wenig Strom und die LED leuchtet praktisch nicht. Oberhalb der Durchlassspannung (Flussspannung) steigt der Strom schnell an (Diodenkennlinie). Die Flussspannung reicht von ca. 1,2 V bei Infrarot-LEDs bis zu etwa 4 V bei Ultraviolett-LEDs. Auffällig ist die Korrelation zwischen Spannung und der Farbe, die damit zusammenhängt, dass die Emission höherenergetischer Photonen einen größeren Bandabstand im Halbleitermaterial erfordert, welcher von den Elektronen überwunden werden muss, wenn sie ihre Energie abgegeben. Da anfänglich nur Halbleiter mit geringem Bandabstand produziert wurden und aufgrund von mangelnder Reinheit oft Zwischenniveaurekombination stattfand, waren lange Zeit keine blauen oder gar echtvioletten LEDs herstellbar. Die ersten verfügbaren LEDs waren naturgemäß auch rot.

{| class="wikitable" style="text-align:centre"
|-
! Farbe || typische Flussspannung [V]
|-
| Infrarot || 1,2
|-
| Rot || 1,8
|-
| Gelb || 2,0
|-
| Grün || 2,2
|-
| Grün (Ultrahell) || 3,3
|-
| Blau || 3,6
|-
| Weiß || 3,6
|-
| Ultraviolett || 4
|}

== Durchlassstrom ==

Da LEDs durch einen zu hohen Strom zerstört werden, muss der Strom begrenzt werden. Der Maximalstrom einer LED ist bei allen Typen sehr ähnlich und liegt bei 25 -30 mA. Eine standard LED wird üblicherweise mit 20 mA betrieben. Moderne LEDs kommen häufig mit sehr viel weniger Strom aus. So benötigt eine Low-Current LED nur 2 mA um sehr hell zu leuchten. Da der Maximalwert auch für eine Low-Current LED gilt, schadet es nicht, wenn man sie mit 20 mA betreibt. Sinnvoll ist es aber nur beim Multiplexen. Genaue Angaben dazu finden sich in entsprechenden Datenblättern.

=== Vorwiderstand ===

Im einfachsten Fall und bei relativ geringfügig variierender Betriebsspannung kann man dazu einen Widerstand einsetzen.

[[bild:led_rv.png|right]]

:<math>R_V=\frac{Vcc-U_\text{LED}}{I_\text{LED}}</math>

* <math>R_V</math>: Vorwiderstand in Ohm
* Vcc: Betriebsspannung in Volt
* <math>U_{LED}</math>: Durchlassspannung der LED in Volt
* <math>I_{LED}</math>: Strom durch die LED in Ampere

Bei 6 V Betriebsspannung, einer Durchlassspannung der LED von 2,4 V und einem gewünschten Strom von 20 mA braucht man nach dem ohmschen Gesetz einen Widerstand von 180Ω, bei 12 V Betriebsspannung sind es 480Ω. In der Praxis wird jeweils der nächstgrößere Standardwert gewählt (E-Reihen).

Was passiert nun, wenn die Flußspannung der LED etwas anders ist als angenommen, z.B. durch Fertigungstoleranzen, höheren Strom oder stark veränderte Temperatur? Bleiben wir bei dem Beispiel mit 6V Versorgungsspannung, 2,4V Flußspannung, 20mA und 180 Ohm Vorwiderstand. Es fallen rechnerisch 3,6V am Vorwiderstand ab. Wenn nun die Flußspannung um 0,2V schwankt (realistischer Wert), ändert sich die Spannung über dem Vorwiderstand um diese 0,2V. Bezogen auf 3,6V Spannungsabfall sind das 5,5%. Bei 12V Betriebsspannung und damit 9,6V Spannungsabfall über dem Vorwiderstand sind es nur noch 2%. Daraus erkennt man, dass der Vorwiderstand umso besser als [[Konstantstromquelle]] wirkt, je höher der Spannungsabfall über diesem ist. Eine echte Konstantstromquelle mit aktiven Elementen (Transistoren) erreicht den gleichen Effekt mit deutlich weniger Spannungsabfall.

Mit einem 480-Ohm-Widerstand, welcher für 12 V Betriebsspannung passend ist, würden bei 6 Volt statt 20 mA nur noch 7,5 mA fließen. Mit einem 180-Ohm-Widerstand, welcher für 6 V Betriebsspannung passend ist, würden bei 12 V statt der gewünschten 20 mA allerdings schon 53 mA fließen.

Beachten muss man auch die als Wärme abgegebene '''Verlustleistung''' über dem Vorwiderstand, vor allem wenn man LEDs an eine recht hohe Betriebsspannung von 12 V oder gar 24 V anschließt. Die Verlustleistung berechnet sich einfach aus

:<math>P_\text{RV} = (V_\text{cc}-U_\text{LED}) \cdot I_\text{LED} = I_\text{LED}^2 \cdot R_\text{V}</math>

In diesem Beispiel mit der 2,4-V-LED und einem Strom von 20 mA heißt das, dass an dem 480-Ohm-Widerstand eine Verlustleistung von 192 mW abfällt. Ein kleiner SMD-Widerstand der Größe 0805 hält das nicht mehr aus (1/8 W = 125 mW maximal).

Wie man aus dem Beispiel erkennt, ist bei stark variierender Betriebsspannung ein Vorwiderstand weniger geeignet. Es sei denn, man nimmt sehr unterschiedliche LED-Ströme und damit LED-Helligkeiten oder möglicherweise die Zerstörung der LED in Kauf.

Bei Batteriebetrieb werden LEDs häufig ohne Vorwiderstand betrieben. So z.B. bei billigen Taschenlampen und Fahrradlampen. Dabei werden oft sogar zwei 1,5V Batterien in Reihe geschaltet und die LED direkt angeschlossen. Der Grund ist, dass das alles nichts kosten darf und man sich auf den Innenwiderstand der Batterie und der LEDs verlässt, um den Strom halbwegs zu begrenzen.

=== Konstantstromquelle ===

Bei stark schwankender Versorgungsspannung oder Umgebungstemperatur heißt der Ausweg [[Konstantstromquelle]]. Kriterien für die Auswahl einer Schaltung für die Konstantstromquelle sind hierbei z. B. Betriebsspannungsbereich, erforderliche Genauigkeit und Kosten. Auch hier ist zu beachten, daß die Verlustleistung der Konstantstromquelle von den Bauteilen abgeführt werden muss, mit einer gewissen Ausnahme der Lösungen mit Schaltregler.

=== Betriebsstrom ===

In der Praxis werden LEDs oft mit einem weit geringeren als dem maximal zulässigen Durchlassstrom betrieben. Insbesondere im Entwicklungs- und Experimentierumfeld kann eine für maximal 20 mA ausgelegte LED auch mit lediglich 3-5 mA betrieben werden. Der subjektiv wahrgenommene Helligkeitsverlust ist deutlich geringer, als der prozentuale Unterschied der Stromstärke vermuten lässt, siehe Artikel [[LED-Fading]].

== Mehrere LEDs zusammenschalten ==

Diese Frage bewegt immer wieder die Gemüter. Wie schaltet man mehrere LEDs '''richtig''' zusammen?

=== Reihenschaltung ===

In einer Reihenschaltung ist der Strom durch alle Verbraucher gleich. Ideal für LEDs. Hat man eine ausreichend hohe Versorgungsspannung, kann man mehrere LEDs in Reihe schalten. Dann reicht ein einziger Widerstand bzw. eine [[Konstantstromquelle]]. Allerdings sollte man das nicht übertreiben. 100-150 LEDs direkt an die Netzspannung zu hängen ist nicht möglich, da die LEDs zu viel Sperrspannung abbekommen würden. Auch bei gleichgerichteter Spannung besteht ein Sicherheitsproblem. Als Hobbybastler sollte man sich auch hier auf Spannungen kleiner als 40V beschränken.

=== Parallelschaltung ===

Das direkte Parallelschalten von LEDs ist sehr kritisch und muss vermieden werden. Grund ist die exponentielle Diodekennlinie, welche bewirkt, dass eine kleine Spannungsänderung eine grosse Stromänderung hervorruft. Schaltet man nun zwei LEDs mit verschiedenen Durchlassspannung parallel, bekommt die mit der niedrigeren Durchlassspannung DEUTLICH mehr Strom ab, dadurch wird sie nicht nur deutlich heller sondern auch wärmer. Das führt zum 2. Problem, denn mit steigender Temperatur sinkt die Durchlassspannung zusätzlich, wodurch sich der Effekt weiter verstärkt! LEDs verschiedender Farben haben sehr unterschiedliche Durchlassspannungen, hier ist ein direktes Parallelschalten vollkommen unmöglich. Aber selbst LEDs mit gleicher Farbe und aus einem Produktionsdurchlauf (Lot) weisen herstellungsbedingt bisweilen erhebliche Streuungen der Durchlassspannung auf!

Richtig Parallelschalten kann man LEDs aber durch

* Vorwiderstand/Konstantstromquelle für jede einzelne LED
* Auswählen von ausgemessenen LEDs mit sehr ähnlicher Flußspannung

Letztere Methode wird von professionellen Herstellern verwendet, um bei grösseren Anzeigen LEDs direkt parallel schalten zu können. Die Unterschiede in der Flußspannung bei Nennstrom sollten dabei kleiner als 10mV(?) sein. Das gilt natürlich auch für das Parallelschalten von LED-Strängen, also Reihenschaltungen von LEDs.

=== Reihen- plus Parallelschaltung ===

Eine Kombination aus Serien- und Parallelschaltung ist weniger kritisch, da sich die unterschiedlichen Kennlinien statistisch mitteln. Z.B. kann man 20 LEDs in Reihe und mehrere solcher Stränge parallel schalten. Eine einzelne Diode mit geringerer Durchlaßspannung wird im Strom durch 9 andere begrenzt. Der Stromanstieg infolge der Unterschiede der einzelnen Stränge erzeugt an allen Bahnwiderständen der Dioden einen Spannungsabfall, der die ungleiche Stromverteilung begrenzt.

Da LEDs mit bis zu 20% in ihrer effektiven Leuchtkraft bei gleicher scheinbarer Spannung streuen, sollte man wenigstens 10 LEDs in Reihe schalten und diese auch nur zu 70% auslasten, um optische Schwankungen auf ein Maß der Nichtsichtbarkeit zu senken und Mitkopplungseffekte infolge von Erwärmung zu begrenzen. Statistisch streuen die Helligkeiten dann nur noch im Bereich einiger Prozente. Die Variation der Stromaufnahme einzelner Stränge sollte demgemäß ebenfalls auf 5% begrenzt werden, d.h. der regelnde Widerstand muss im Bereich von >10% Spannungsänderungen aufnehmen können.

Eine brauchbare Dimensionierung für 1,7V-LEDs @ 20mA wäre: 10 LEDs mit R=150Ohm an 20Volt. Der Widerstand sollte mit 1W belastbar sein. Noch besser ist ein gegengeregelter FET, der als Kaltleiter eine doppelte Gegenregelung bringt.

Für eine gleichmäßige Lichtversorgung eines Array, sollten die LEDs nicht strangweise parallel, sondern in Schleifen verlegt werden. Man kann z.B. zwei Stränge alternierend verdrahten.

== Direktbetrieb an 230V ==
Eine Methode, LEDs an 230V direkt zu betreiben, ist die Strombegrenzung mit einem spannungsfesten Kondensator, der in Reihe zur eigentlichen LED-Schaltung liegt, die aus einem 4-Wege-Gleichrichter, einem ELKO und einer Anzahl als Array verschalteter LEDs besteht. Die LEDs können wie im obigen Beispiel auf 20V oder 24V ausgelegt werden und sollten mit zwei antiparallel geschalteten Z-Dioden auf 24/28V limitiert werden, um Spannungsspitzen abzufangen. Die vorgeschaltete Kapazität wird mit einer Reihenschaltung von 4 keramischen Kondensatoren aufgebaut, von denen jeder ca 60V abfangen muss. Die Kapazität richtet sich nach der Stromaufnahme der Summe der LED-Stränge.

Eine andere Möglichkeit befindet sich im Artikel [[LED-Glühbirne]].

== Siehe auch ==

* [[AVR-Tutorial: IO-Grundlagen#Hardware]]
* [[LED-"Birnen"]]
* [[LED-Matrix]]
* [[LED-Fading]]
* [[Lichtsensor / Helligkeitssensor#LED]]
* [[Ambilight in Hardware]]
* [[Konstantstromquelle]]
* [[Konstantstromquelle fuer Power LED]]
* [http://www.mikrocontroller.net/topic/158836?goto=2759782#2759782 Forumsbeitrag]: LEDs an 230V Netzspannung mit Konstantstromquelle
* [http://www.mikrocontroller.net/topic/219681#2197034 Forumsbeitrag]: Darstellung der Toleranzen von LEDs und deren Wirkung, oder "Warum man einen Vorwiderstand braucht"
* [http://www.mikrocontroller.net/topic/74169#618682 Forumsbeitrag]: 16-Segment Ganganzeige ohne Mikrocontroller
* [http://www.mikrocontroller.net/topic/267113#2788848 Forumsbeitrag]: Unbekannte LEDs ausmessen.
* [http://www.mikrocontroller.net/topic/280991?goto=2966997#2966820 Forumsbeitrag]: Konstantstromquelle für LED an 40-420VDC
* [http://www.mikrocontroller.net/topic/290710?goto=3106790#3106790 Forumsbeitrag]: Graphische Ermittlung des LED-Stroms und der Toleranzen
* [http://www.mikrocontroller.net/topic/311454#new Forumsbeitrag]: Glühbirnen ungepulst betreiben?
* [http://www.mikrocontroller.net/topic/289238#3073788 Forumsbeitrag]: 2 LEDs mit einem Portpin steuern
* [http://www.mikrocontroller.net/topic/261525?goto=new#new Forumsbeitrag]: Samsung Hochvolt AC LED Erfahrungen?

== Weblinks ==
* [http://de.wikibooks.org/wiki/Arbeiten_mit_LEDs/_Grundlagen Wikibooks Arbeiten mit LEDs: Grundlagen] - Sehr gute Erklärung, auch für Anfänger
* [http://www.theledlight.com/technical.html www.theledlight.com] - LED Information and Technical Data (englisch)
* [http://forum.electronicwerkstatt.de/phpBB/faq/led/ LED FAQ für Anfänger]
* [http://members.misty.com/don/ledx.html Don Klipstein's LED Main Page (engl.)]
* [http://www.robotroom.com/LEDTester.html Selecting a LED] - LED Tester von David Cook (Beginnerprojekt)
* [http://www.evilmadscientist.com/article.php/throw Some thoughts on throwies] von Windell H. Oskay von www.evilmadscientist.com
*[http://www.led-rechner.de www.led-rechner.de]
*[http://catalog.osram-os.com/catalogue/catalogue.do?act=downloadFile&favOid=02000002000040ac000100b6 Vergleich von LED-Schaltungen ] - Applikationsschrift von OSRAM, engl.
* [http://catalog.osram-os.com/catalogue/catalogue.do;jsessionid=CBC285EE73F7A4DA3956223C87D46516?act=downloadFile&favOid=0200000200004264000100b6 Ansteuerung von Power TOPLEDs] - Applikationsschrift von OSRAM, engl.
*[http://catalog.osram-os.com/catalogue/catalogue.do;jsessionid=CBC285EE73F7A4DA3956223C87D46516?act=downloadFile&favOid=0200000200001b48000200b6 Verhalten von InGaN LEDs in Parallelschaltungen] - Applikationsschrift von OSRAM, engl.

[[Category:Bauteile]]
[[Category:Grundlagen]]
[[Category:Displays und Anzeigen| ]]

AVR-Tutorial: Stack

2015-03-04T11:48:09Z

Maybee:

"[[Stack]]" bedeutet übersetzt soviel wie Stapel. Damit ist ein Speicher nach dem LIFO-Prinzip ("last in first out") gemeint. Das bedeutet, dass das zuletzt auf den Stapel gelegte Element auch zuerst wieder heruntergenommen wird. Es ist nicht möglich, Elemente irgendwo in der Mitte des Stapels herauszuziehen oder hineinzuschieben.

Bei allen aktuellen AVR-Controllern wird der Stack im [[Speicher#RAM|RAM]] angelegt. Der Stack wächst dabei von oben nach unten: Am Anfang wird der Stackpointer (Adresse der aktuellen Stapelposition) auf das Ende des RAMs gesetzt. Wird nun ein Element hinzugefügt, wird dieses an der momentanen Stackpointerposition abgespeichert und der Stackpointer um 1 erniedrigt. Soll ein Element vom Stack heruntergenommen werden, wird zuerst der Stackpointer um 1 erhöht und dann das Byte von der vom Stackpointer angezeigten Position gelesen.

== Aufruf von Unterprogrammen ==
Dem Prozessor dient der Stack hauptsächlich dazu, Rücksprungadressen beim Aufruf von Unterprogrammen zu speichern, damit er später noch weiß, an welche Stelle zurückgekehrt werden muss, wenn das Unterprogramm mit '''ret''' oder die Interruptroutine mit '''reti''' beendet wird.

Das folgende Beispielprogramm (AT90S4433) zeigt, wie der Stack dabei beeinflusst wird:

[http://www.mikrocontroller.net/sourcecode/tutorial/stack.asm Download stack.asm]

<syntaxhighlight lang="avrasm">
.include "4433def.inc" ; bzw. 2333def.inc

.def temp = r16

ldi temp, RAMEND ; Stackpointer initialisieren
out SP, temp

rcall sub1 ; sub1 aufrufen

loop: rjmp loop

sub1:
; hier könnten ein paar Befehle stehen
rcall sub2 ; sub2 aufrufen
; hier könnten auch ein paar Befehle stehen
ret ; wieder zurück

sub2:
; hier stehen normalerweise die Befehle,
; die in sub2 ausgeführt werden sollen
ret ; wieder zurück
</syntaxhighlight>

'''.def temp = r16''' ist eine Assemblerdirektive. Diese sagt dem Assembler, dass er überall, wo er "temp" findet, stattdessen "r16" einsetzen soll. Das ist oft praktisch, damit man nicht mit den Registernamen durcheinander kommt. Eine Übersicht über die Assemblerdirektiven findet man [http://www.avr-asm-tutorial.net/avr_de/beginner/diraus.html hier].

Bei Controllern, die mehr als 256 Byte RAM besitzen (z. B. ATmega8), passt die Adresse nicht mehr in ein Byte. Deswegen gibt es bei diesen Controllern das Stack-Pointer-Register aufgeteilt in '''SPL''' (Low) und '''SPH''' (High), in denen das Low- und das High-Byte der Adresse gespeichert wird. Damit es funktioniert, muss das Programm dann folgendermaßen geändert werden:

[http://www.mikrocontroller.net/sourcecode/tutorial/stack-bigmem.asm Download stack-bigmem.asm]

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

.def temp = r16

ldi temp, HIGH(RAMEND) ; HIGH-Byte der obersten RAM-Adresse
out SPH, temp
ldi temp, LOW(RAMEND) ; LOW-Byte der obersten RAM-Adresse
out SPL, temp

rcall sub1 ; sub1 aufrufen

loop: rjmp loop

sub1:
; hier könnten ein paar Befehle stehen
rcall sub2 ; sub2 aufrufen
; hier könnten auch Befehle stehen
ret ; wieder zurück

sub2:
; hier stehen normalerweise die Befehle,
; die in sub2 ausgeführt werden sollen
ret ; wieder zurück
</syntaxhighlight>

Natürlich ist es unsinnig, dieses Programm in einen Controller zu programmieren. Stattdessen sollte man es mal mit dem AVR-Studio simulieren, um die Funktion des Stacks zu verstehen.

Als erstes wird mit '''Project/New''' ein neues Projekt erstellt, zu dem man dann mit '''Project/Add File''' eine Datei mit dem oben gezeigten Programm (stack.asm) hinzufügt. Nachdem man unter '''Project/Project Settings''' das '''Object Format for AVR-Studio''' ausgewählt hat, kann man das Programm mit Strg+F7 assemblieren und den Debug-Modus starten.

Danach sollte man im Menu '''View''' die Fenster '''Processor''' und '''Memory''' öffnen und im Memory-Fenster '''Data''' auswählen.

Das Fenster '''Processor'''
* ''Program Counter'': Adresse im Programmspeicher (FLASH), die gerade abgearbeitet wird
* ''Stack Pointer'': Adresse im Datenspeicher (RAM), auf die der Stackpointer gerade zeigt
* ''Cycle Counter'': Anzahl der Taktzyklen seit Beginn der Simulation
* ''Time Elapsed'': Zeit, die seit dem Beginn der Simulation vergangen ist

Im Fenster '''Memory''' wird der Inhalt des RAMs angezeigt.

Sind alle 3 Fenster gut auf einmal sichtbar, kann man anfangen, das Programm (in diesem Fall "stack.asm") mit der Taste F11 langsam Befehl für Befehl zu simulieren.

Wenn der gelbe Pfeil in der Zeile '''out SPL, temp''' vorbeikommt, kann man im Prozessor-Fenster sehen, wie der Stackpointer auf 0xDF (''ATmega8'': 0x45F) gesetzt wird. Wie man im Memory-Fenster sieht, ist das die letzte RAM-Adresse.

Wenn der Pfeil auf dem Befehl '''rcall sub1''' steht, sollte man sich den Program Counter anschauen: Er steht auf 0x02 (''ATmega8'': 0x04).

Drückt man jetzt nochmal auf F11, springt der Pfeil zum Unterprogramm sub1. Im RAM erscheint an der Stelle, auf die der Stackpointer vorher zeigte, die Zahl 0x03 (''ATmega8'': 0x05). Das ist die Adresse im ROM, an der das Hauptprogramm nach dem Abarbeiten des Unterprogramms fortgesetzt wird. Doch warum wurde der Stackpointer um 2 verkleinert? Das liegt daran, dass eine Programmspeicheradresse bis zu 2 Byte breit sein kann, und somit auch 2 Byte auf dem Stack benötigt werden, um die Adresse zu speichern.

Das gleiche passiert beim Aufruf von sub2.

Zur Rückkehr aus dem mit rcall aufgerufenen Unterprogramm gibt es den Befehl '''ret'''. Dieser Befehl sorgt dafür, dass der Stackpointer wieder um 2 erhöht wird und die dabei eingelesene Adresse in den "Program Counter" kopiert wird, so dass das Programm dort fortgesetzt wird.

Apropos Program Counter: Wer sehen will, wie so ein Programm aussieht, wenn es assembliert ist, sollte mal die Datei mit der Endung ".lst" im Projektverzeichnis öffnen. Die Datei sollte ungefähr so aussehen:

http://www.mikrocontroller.net/images/listfile.gif

Im blau umrahmten Bereich steht die Adresse des Befehls im Programmspeicher. Das ist auch die Zahl, die im Program Counter angezeigt wird, und die beim Aufruf eines Unterprogramms auf den Stack gelegt wird. Der grüne Bereich rechts daneben ist der OP-Code des Befehls, so wie er in den Programmspeicher des Controllers programmiert wird, und im roten Kasten stehen die "mnemonics": Das sind die Befehle, die man im Assembler eingibt.
Der nicht eingerahmte Rest besteht aus Assemblerdirektiven, Labels (Sprungmarkierungen) und Kommentaren, die nicht direkt in OP-Code umgewandelt werden.
Der grün eingerahmte Bereich ist das eigentliche Programm, so wie es der µC versteht. Die jeweils erste Zahl im grünen Bereich steht für einen Befehl, den sog. OP-Code (OP = Operation). Die zweite Zahl codiert Argumente für diesen Befehl.

== Sichern von Registern ==
Eine weitere Anwendung des Stacks ist das "Sichern" von Registern. Wenn man z. B. im Hauptprogramm die Register R16, R17 und R18 verwendet, dann ist es i.d.R. erwünscht, dass diese Register durch aufgerufene Unterprogramme nicht beeinflusst werden. Man muss also nun entweder auf die Verwendung dieser Register innerhalb von Unterprogrammen verzichten, oder man sorgt dafür, dass am Ende jedes Unterprogramms der ursprüngliche Zustand der Register wiederhergestellt wird. Wie man sich leicht vorstellen kann ist ein "Stapelspeicher" dafür ideal: Zu Beginn des Unterprogramms legt man die Daten aus den zu sichernden Registern oben auf den Stapel, und am Ende holt man sie wieder (in der umgekehrten Reihenfolge) in die entsprechenden Register zurück. Das Hauptprogramm bekommt also wenn es fortgesetzt wird überhaupt nichts davon mit, dass die Register inzwischen anderweitig verwendet wurden.

[http://www.mikrocontroller.net/sourcecode/tutorial/stack-saveregs.asm Download stack-saveregs.asm]
<syntaxhighlight lang="avrasm">
.include "4433def.inc" ; bzw. 2333def.inc

.def temp = R16

ldi temp, RAMEND ; Stackpointer initialisieren
out SP, temp

ldi temp, 0xFF
out DDRB, temp ; Port B = Ausgang

ldi R17, 0b10101010 ; einen Wert ins Register R17 laden

rcall sub1 ; Unterprogramm "sub1" aufrufen

out PORTB, R17 ; Wert von R17 an den Port B ausgeben

loop: rjmp loop ; Endlosschleife

sub1:
push R17 ; Inhalt von R17 auf dem Stack speichern

; hier kann nach belieben mit R17 gearbeitet werden,
; als Beispiel wird es hier auf 0 gesetzt

ldi R17, 0

pop R17 ; R17 zurückholen
ret ; wieder zurück zum Hauptprogramm
</syntaxhighlight>
Wenn man dieses Programm assembliert und in den Controller lädt, dann wird man feststellen, dass jede zweite LED an Port B leuchtet. Der ursprüngliche Wert von R17 blieb also erhalten, obwohl dazwischen ein Unterprogramm aufgerufen wurde, das R17 geändert hat.

Auch in diesem Fall kann man bei der Simulation des Programms im AVR-Studio die Beeinflussung des Stacks durch die Befehle '''push''' und '''pop''' genau nachvollziehen.

== Sprung zu beliebiger Adresse ==
''Dieser Abschnitt ist veraltet, da nahezu alle ATmega/ATtiny Typen IJMP/ICALL unterstützen.''

Kleinere AVR besitzen keinen Befehl, um direkt zu einer Adresse zu springen, die in einem Registerpaar gespeichert ist. Man kann dies aber mit etwas Stack-Akrobatik erreichen. Dazu einfach zuerst den niederen Teil der Adresse, dann den höheren Teil der Adresse mit '''push''' auf den Stack legen und ein '''ret''' ausführen:
<syntaxhighlight lang="avrasm">
ldi ZH, high(testRoutine)
ldi ZL, low(testRoutine)

push ZL
push ZH
ret

...
testRoutine:
rjmp testRoutine
</syntaxhighlight>
Auf diese Art und Weise kann man auch Unterprogrammaufrufe durchführen:
<syntaxhighlight lang="avrasm">
ldi ZH, high(testRoutine)
ldi ZL, low(testRoutine)
rcall indirectZCall
...

indirectZCall:
push ZL
push ZH
ret

testRoutine:
...
ret
</syntaxhighlight>

Größere AVR haben dafür die Befehle <code>ijmp</code> und <code>icall</code>.
Bei diesen Befehlen muss das Sprungziel in ZH:ZL stehen.

== Weitere Informationen (von Lothar Müller): ==
* [http://www.mikrocontroller.net/attachment/301/Der-Stack-1.pdf Der Stack - Funktion und Nutzen (pdf)]
* [http://www.mikrocontroller.net/attachment/299/Der-Stack-2.pdf Der Stack - Parameterübergabe an Unterprogramme (pdf)]
* [http://www.mikrocontroller.net/attachment.php/676/Der-Stack-3.pdf Der Stack - Unterprogramme mit variabler Parameteranzahl (pdf) ]

(Der in dieser Abhandlung angegebene Befehl ''MOV ZLow, SPL'' muss ''IN ZL, SPL'' heißen, da SPL und SPH I/O-Register sind. Ggf ist auch SPH zu berücksichtigen --> 2byte Stack-Pointer)

----

{{Navigation_zurückhochvor|
zurücktext=logische Operatoren|
zurücklink=AVR-Tutorial: Logik|
hochtext=Inhaltsverzeichnis|
hochlink=AVR-Tutorial|
vortext=LCD|
vorlink=AVR-Tutorial: LCD}}

[[Category:AVR-Tutorial|Stack]]

Transistor

2015-02-11T09:16:02Z

Maybee: Änderung 87248 von 84.136.7.7 (Diskussion) rückgängig gemacht.

Kunstwort aus "transfer resistor", was etwa so viel bedeutet wie "übertragener [[Widerstand]]".

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

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

== Schaltzeichen ==
http://electronicsclub.info/images/transbce.gif

* E: Emitter
* B: Basis
* C: Collector

In ASCII Schaltplänen sehen Transistoren so aus:
<pre>
|> |/
NPN |> oder -| oder -|
|\ |>

|< |/
PNP: |< oder -| oder -|
|\ |<
</pre>

Um zu erkennen, ob ein NPN oder PNP Transistor im Schaltplan verwendet wird, gibt es Eselsbrücken:
*Für Dichter: '''Tut der Pfeil der Basis weh, handelt's sich um PNP.'''
*Für Praktiker: '''PNP heisst "Pfeil Nach Platte"'''.
*Mit Dialekt: '''NPN "'naus, Pfeil, 'naus"'''.
*..und für Gleichberechtigungsverfechter: '''NPN means "Not Pointing iN"'''.

JFET: [[Bild:Transistor_JFET.png]]

MOSFET: [[Bild:Transistor_MOSFET.png]]

* S: Source
* G: Gate
* D: Drain

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.

'''Achtung:''' Die NPN/PNP Eselsbrücken funktionieren bei FETs nicht, denn bei einem P-Kanal FET zeigt der Pfeil weg vom FET!
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.

Bipolare Leistungstransistoren sind für das Schalten und Verstärken von Signalen höherer Stromstärken und Spannungen ausgelegt.

== Typbezeichnungen ==

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.

== Kenndaten/Parameter ==

Im [http://www.mikrocontroller.net/topic/197676#1938546 Beitrag: Transistorparameter Erklärung] sind Links zu Erläuterungen spezieller Kürzel.

== Transistor Grundschaltungen ==

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.

'''Weitere Links:'''
* Artikel [[Basiswiderstand]]
* [http://www.elektronik-kompendium.de/sites/slt/0203111.htm Transistor Grundschaltungen im ElKo]
* [http://www.roboternetz.de/wissen/index.php/Transistor Transistor bei RoboterNetz.de]

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.

=== Kollektorschaltung (Emitterfolger)===

'''Anwendung:'''
* Impedanzwandler
* Darlington-Schaltung
* Schalter

'''Eigenschaften:'''
* Keine Phasendrehung
* Hohe Stromverstärkung
* Keine Spannungsverstärkung

'''Beispiel: Transistor als Schalter'''

* NPN: Kollektor mit Vcc verbinden, Last an Emitter
* PNP: Kollektor mit GND verbinden, Last an Emitter

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.

[[Bild:NPN_Collector.gif | framed | center | NPN Transistor in Kollektorschaltung]]

Wird <math>R_{Poti}</math> (Spannungsteiler) erhöht, steigt die Spannung <math>U_{Last}</math> letztlich bis auf Vcc-0,6V (Basis-Emitter-Übergang).

[[Bild:PNP_Collector.gif | framed | center | PNP Transistor in Kollektorschaltung]]

Wird <math>R_{Poti}</math> (Spannungsteiler) erhöht, sinkt Spannung an <math>U_{Last}</math> letztlich bis auf 0,6V (Basis-Emitter-Übergang).

'''Weitere Links:'''
* [http://www.elektronik-kompendium.de/sites/slt/0204133.htm Kollektorschaltung im ElKo]

=== Emitterschaltung ===

Die Emitterschaltung bietet hohe Spannungs- und Stromverstärkung.

'''Anwendung:'''
* NF- und HF-Verstärker
* Leistungsverstärker
* Transistor als Schalter

'''Eigenschaften:'''
* Phasendrehung 180°
* Hohe Spannungsverstärkung
* Hohe Stromverstärkung

'''Beispiel: Transistor als Schalter'''

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.

[[Bild:NPN_Schalter.gif | framed | center | NPN Transistor als Schalter]]
<pre>
___ ___
Vcc/+ o-----------------------+ Vcc/+ o-----------------------+
| |
___ |< U_schalt (-) ___ |< PNP
+------|___|---| PNP o------------|___|----|
| R_Basis |\ R_Basis |\
Schalter \ | |
| ___ | ___ |
GND/- o------+------|___|-----+ GND/- o-------------|___|-----+
R_Last R_Last

</pre>

'''Weitere Links:'''
* [http://www.elektronik-kompendium.de/sites/slt/0204302.htm Emitterschaltung im ElKo]

=== Basisschaltung ===

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.

'''Eigenschaften:'''
* Geringe Eingangsimpedanz
* Keine Phasenverschiebung
* Hohe Bandbreite

'''Weitere Links:'''
* [http://www.elektronik-kompendium.de/sites/slt/0205081.htm Basisschaltung im ElKo

== FAQ aus dem Forum ==

=== PNP/NPN als Schalter, wohin mit der Last? ===
Für viele einfache Anwendungen kann man sich merken: '''Bei Schaltanwendungen darf der Basisstrom nicht durch die Last fließen'''. Normalerweise kommt dabei die Emitterschaltung zum Einsatz, die Last kommt also an den Kollektor.

<pre>
Vcc o-------------+ Vcc o-----------+
| |
.-. An: GND ___ |<
| | R_Last o---|___|--| PNP
'-' Aus: Vcc |\
| |
An: Vcc ___ |/ .-.
o---|___|----| NPN 3> | | R_Last
Aus: GND |> '-'
| |
GND o-------------+ GND o-----------+
</pre>

Siehe [[Basiswiderstand]] zur Berechnung des notwendigen Basiswiderstandes bei gegebener Last R_Last für einen Transistor als Schalter.

Siehe auch Threads im Forum:
* http://www.mikrocontroller.net/topic/58567
* http://www.mikrocontroller.net/topic/119841
* oder im [http://www.elektronik-kompendium.de/sites/slt/0208031.htm Elektronik-Kompendium-Forum]

=== Wie kann ich mit 5V vom Mikrocontroller 12V und mehr schalten? ===
Schau mal hier:
* Wikiartikel [[Pegelwandler]]
* [http://www.elektronik-kompendium.de/sites/praxis/bausatz_pegelwandler-mit-transistoren.htm Pegelwandler im ElKo]
* [http://dl6gl.de/grundlagen/schalten-mit-transistoren schalten-mit-transistoren]

oder in diesen Threads:
*[http://www.mikrocontroller.net/topic/17899 Transistor als Schalter]
*[http://www.mikrocontroller.net/topic/14437 Vcc schalten mit MOSFET]
*[http://www.mikrocontroller.net/topic/29830 Schalten mit PNP-Transistor]
*[http://www.mikrocontroller.net/topic/104027 Transistorschalter für Versorgungsspannung]
*[http://www.mikrocontroller.net/topic/104951#921417 7-50V strombegrenzt schalten]
*[http://www.mikrocontroller.net/topic/103116#900247 P-Kanal MOSFET ansteuern]

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.

Schalten gegen GND

<pre>
+12V o------------------------+
|
.-.
( X )
'-'
|
___ |/ T1,NPN
uC PIN o---|___|-----| BC547
R2,4K7 |>
|
GND o---------o--------------+
</pre>

Schalten gegen +12V

<pre>
+12V o--------------+----------------------+
| |
| ____ |< T2, PNP
+--|____|----+--------| BC557
R1,4K7 | |\
|/T1,NPN |
Vcc/+5V o--------------| BC547 |
|> |
___ | .-.
uC PIN o-----|___|------+ ( X )
R2,4K7 '-'
|
GND o----------o--------------------------+
</pre>

=== Transistor an µC ohne Vorwiderstand ===

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.

Deshalb kann man den IO-Pin des AVRs einfach als Tristate Eingang einstellen (Portpin als Eingang und Pullup deaktivieren), damit kein Basisstrom fließt.

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

Nur sollte man bei kleinen Transistoren aufpassen, dass man den Portpin in der Software nie als aktiven Ausgang schaltet.

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

Eine Anwendung wären z. B. Nixie-Röhren-Kathodentreiber (geringe Stromverstärkung nötig).

=== Wann bipolare (NPN/PNP) und wann FETs (insbesonders, wenn LEDs im Spiel sind)?===
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...).

Ein Grenzfall: 500mA/5V schalten, siehe http://www.mikrocontroller.net/topic/62327.

=== Wieso gehen bei einer Multiplex-Anzeige mit Schieberegister 74HC595 und (Darlington-)Transistor als Zeilentreiber die LED nicht ganz aus? ===
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]

=== Wie steuert man ein Relais? ===
Normalerweise verwendet man zur Ansteuerung von Relais NPN-Transistoren in Emitterschaltung. Freilaufdiode nicht vergessen!

Siehe auch:
* [[Relais mit Logik ansteuern]]
* [http://www.mikrocontroller.net/attachment/22023/Relaisanteuerung.png Schaltbilder aus dem Forum]

=== Was ist die Spannung <math>U_{BE\_sat}</math> (lt. Datenblatt max. 1,2V)? ===
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.

=== Was bewirkt ein Kondensator (100µF-1nF) parallel zur Basis-Emitter-Strecke nach Masse? ===
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.

=== Gibt es einen IC, der wie mehrere Transistoren funktioniert? ===

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. B. ein Leistungstreiber zur Ansteuerung von Schrittmotoren, Relais und anderen induktiven Lasten aufbauen.

=== Gibt es ein Transistor-Array wie ULN28xx, das gegen Vcc schaltet? ===

Such mal nach UDN29xx, z. B. UDN2981, UDN2987 ...

=== Wann setzt man einen MOSFET, Bipolartransistor, IGBT oder Thyristor ein ? ===
siehe [[Leistungselektronik]]

Die Summe allen Übels ist konstant. Man muss wissen, welches Bauteil sich wofür besonders eignet.

====[[FET | MOSFET]]====

Vorteile
* Bei niedrigen Spannungen <100V sehr gut geeignet, <200V gut geeignet, sehr geringe R_DS-ON Widerstände möglich (einstelliger mOhm-Bereich)
* Hohe Schaltgeschwindigkeiten möglich
* Geringe An- und Ausschaltverluste
* Statisch praktisch leistungslos steuerbar
* Bodydiode kann als Freilaufdiode in H-Brücken verwendet werden
* 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]])

Nachteile
*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)
* Bei Sperrspannungen >100V deutlich steigende Einschaltwiderstände (R_DS-ON)
* Schnelles Umschalten erfordert hohe Lade-und Entladeströme ([[MOSFET-Übersicht#Mosfet-Treiber|MOSFET-Treiber]])
* Leitverluste quadratisch proportional zum Strom, Pv = I²*R_DS-ON

====[[Transistor | Bipolartransistor]]====

Vorteile
* Hohe Spannungsfestigkeiten möglich, bis zu 2000V
* Sehr hohe Schaltgeschwindigkeiten möglich
* Leitverluste linear proportional zum Strom und Kollektor-Emitter-Sättigungsspannung, Pv = I * Uce-sat, U_CEC-sat typ 0,1..1V

Nachteile
* Stromgesteuert, damit wird immer eine gewisse Ansteuerleistung benötigt
* Bei grossen Kollektorströmen nimmt die Stromverstärkung deutlich ab, dann wird ein großer Basisstrom benötigt
* 2. Durchbruch bei Überschreiten der max. Kollektor-Emitter Sperrspannung zerstört das Bauteil

====[[IGBT]]====

Vorteile
* Hohe Spannungsfestigkeiten möglich, bis zu 6600V, in üblichen Bauformen bis ca 1700V gut verfügbar
* Statisch praktisch leistungslos steuerbar
* Mit oder ohne antiparallele Diode zur Kollektor-Emitter-Strecke verfügbar
* Leitverluste linear proportional zum Strom und Kollektor-Emitter-Sättigungsspannung, Pv = I * Uce-sat, U_CE-sat typ. 2V

Nachteile
* Nur mäßige Schaltfrequenzen möglich (typ. <30..50kHz)
* Schnelles Umschalten erfordert hohe Lade-und Entladeströme ([[MOSFET-Übersicht#Mosfet-Treiber|MOSFET-Treiber]])
* 2. Durchbruch bei Überschreiten der max. Kollektor-Emitter Sperrspannung zerstört das Bauteil

====[[TRIAC]]/Thyristor====

Vorteile:
* Sehr hohe Spannungsfestigkeiten möglich (800V...mehrere kV, Thyristoren bis 12kV)
* Mit kurzen Pulsen einschaltbar, danach Selbsthaltung des Stromflusses
* Leitverluste linear proportional zum Strom, Pv = I * Uak, Uak typ. 0,8..1V

Nachteile
* Auf niedrige Schaltfrequenzen beschränkt (kHz-Bereich, Schaltzeit im Bereich von µs)
* Anstiegsgeschwindigkeit des Stromes muss begrenzt werden, sonst kommt es zu Bauteilschäden
* Anstiegsgeschwindigkeit der Spannung muss begrenzt werden, sonst kommt es zum ungewollten Zünden
* Stromfluss kann nicht ausgeschaltet werden, damit meist nur Einsatz an Wechselspannung

{| class="wikitable"
|-
! Bauteil || optimales Einsatzgebiet || Kommentar
|-
| MOSFET || 0..200V, 0..500A || im Kleinspannungsbereich meist die beste Wahl als Schalter
|-
| Bipolartransistor || 0..1000V, 0..10A || wird mehr und mehr von MOSFETs verdrängt
|-
| IGBT || 200..1700V, 0..500A || optimal für hohe Spannungen und hohe Ströme
|-
| Triac/Thyristor || 230V, 400V, 680V, bis mehrere kV, 0..100A || meist für Wechselspannung, im Pulsbetrieb einige kA. Thyristoren bis 1000A im Dauerbetrieb (Scheibenzelle)
|}

=== Wie finde ich den richtigen Transistor für eine LED-Ansteuerung? ===

Quelle: Beiträge [http://www.mikrocontroller.net/topic/157763#1493623] und [http://www.mikrocontroller.net/topic/157763#1494972] von yalu

Um am Anfang wenigstens ein bisschen den Durchblick im Transistordschungel zu behalten, kannst du folgendermaßen vorgehen:

'''Nomenklatur'''

Nach der amerikanischen Nomenklatur beginnen die Transistornamen meist mit 2N (z. B. 2N2222 oder 2N3055) und nach der japanischen mit 2S (z. 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:

Der erste Buchstabe bezeichnet das Halbleitermaterial (A=Germanium, B=Silizium). Germaniumtransistoren werden heute nur noch selten verwendet.

Der zweite Buchstabe steht für den Einsatzzweck (C=Universal, D=hohe Leistung, F=Hochfrequenz, U=hohe Spannung).

So ist also ein ACxxx ein Germaniumuniversaltransistor und ein BDxxx ein Siliziumleistungstransistor.

'''Auswahl'''

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
Suchreihenfolge. Als erstes Auswahlkriterium nimmst du den Preis, denn:

* Zuviel Geld hast wahrscheinlich nicht einmal du.
* 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.
* 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.

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.

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]])

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:

<pre>
BC547C 45V 0,1A 0,5W
</pre>

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.

Deine LED wird typisch mit 20mA (max. 30mA) betrieben. Der BC547C kann 100mA, also ist auch hier noch Luft.

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.

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.

Da in deiner Anwendung HF- und Rauschverhalten keine Rolle spielen, bist du schon am Ziel angelangt.

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
zu einfach, wenn immer nur A, B und C verwendet würde ;-)

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. B. BD647). Ein Transistortyp, der sich sehr gut zum Schalten höherer Ströme eignet, ist der [[FET | MOSFET]].

Wie schon oben angedeutet: Wenn die 30-80V die die meisten BC- und BD-Transistoren abkönnen, nicht ausreichen, suchst du weiter bei BU.

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 ;-)

'''Und wie geht's weiter?'''

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.

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.

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

=== Wo ist die Antwort auf meine Frage? ===

Vielleicht im Forum? Falls du sie da findest, dann pack das ganze doch hier rein.

[http://www.mikrocontroller.net/topic/165580 Gegen Vcc oder GND schalten]

== Siehe auch ==
* [[Basiswiderstand]]
* [[Transistor-Übersicht]]
* [[AVR-Transistortester]]
* [[Leistungselektronik]]

== Gehäusebauformen von Transistoren ==

=== TO-92 ===
Ein kleiner Aufsatz über TO-92 Transistorgehäuse und Footprints findet sich unter: [[Media:TO-92-Gehaeuse_RevB2.pdf]].

== Weblinks ==
* [http://de.wikipedia.org/wiki/transistor "Transistor" bei Wikipedia]
* [http://www.elektronik-kompendium.de www.elektronik-kompendium.de]
** [http://www.elektronik-kompendium.de/sites/bau/0201291.htm Elko/Transistor]
* http://www.elektronikinfo.de/strom/bipolartransistoren.htm
* http://www.ferromel.de/tronic_1870.htm
* [http://www.DieElektronikerseite.de Die Elektronikerseite] Lehrgang: Der Transistor - Ein Tausendsassa

[[Category:Bauteile]]
[[Category:Grundlagen]]

Arduino

2015-01-29T09:03:37Z

Maybee: Schrott

Das Arduino-Projekt ist ein 2006 gestartetes Projekt aus Italien. Arduino ist eine Zusammenstellung aus verschiedenen Boards und einer IDE. Die Boards basieren auf der Atmel-AVR Serie. Die einzige Ausnahme bildet der Arduino Due, dieser basiert auf einem ARM-Chip von Atmel. Das Gesamt Projekt ist quelloffen, also Open-Source. Was nicht nur die Entwicklungsumgebung betrifft, sondern auch die Projektdateien für die Platinen. Die Unterschiede zu anderen Atmel-Boards sind der Bootloader und die IDE. Der Bootloader wird durch das Arduino-Projekt entwickelt und ist für die einzelnen Boards spezifisch.

== Zielgruppe ==
Arduinos richten sich an Mikrocontroller-Einsteiger und kleinere bis mittlere Projekte. Es sind fertig aufgebaute Boards mit zahlreichen Anschlüssen und aufgelöteten Buchsenleisten. Die Programmierung ist zuverlässig und die Kompatibilität mit Shields und die Portabilität zwischen den einzelnen Boards wird weitestgehend gewährleistet. Eine obere Grenze für die verfügbare Rechenleistung sind Ausgaben auf große Anzeigen wie XVGA-Monitore. Ein PAL-Signal für Fernseher ist möglich. Die meisten Boards verfügen über relativ wenig Speicher, womit sie schon mit Bibliotheken für Ein-/ Ausgabe auf SD-Karten (16kByte) ausgereizt sind. Eine LED blinken zu lassen wird im u.a. Tutorial gezeigt.

Projekte aus den Startpaketen benutzen bspw. 3 lichtempfindliche Widerstände um eine 3-farbige LED anzusteuern. Eine Lichtschranke oder ein Mikrofon regeln die Stellung eines Servomotor. Dem offiziellen Arduino Starterkit liegen sogar Optokoppler bei, um die Tasten anderer Geräte zu ''hacken'' und per Arduino fernzusteuern. Der sog. ''Playground'' <ref name="playground">[http://playground.arduino.cc/] Arduino Playground Wiki</ref> ist ein Wiki, in dem eine Vielzahl von Ideen mit Schaltungsbeispielen die Möglichkeiten eines Mikrocontrollers aufzeigen.

Wer dem Arduino dann entwachsen ist, muss ihn nicht zum alten Eisen legen. Einige Boards haben einen ISP-Port (In System Programming=Programmierung in der Schaltung) vorgesehen und sogar mit einem 6pol. Steckverbinder bestückt. Damit sind diese Arduinos über einen passenden Programmieradapter gemäß Chip-Datenblatt vollständig programmierbar – auch was für Profis, die das teure Atmel-Board scheuen.

==Die IDE und Schaltpläne==
[[Datei:Arduino ide.png|miniatur|links|Bildschirmfoto Arduino-IDE]] Die Arduino-IDE ist eine in JAVA programmierte grafische Oberfläche. Dadurch ist sie plattfomunabhägig, folglich mit gleichem Erscheinungsbild auf Windows, Linux, MacOS X und Solaris verfügbar. Der Funktionsumfang ist deutlich geringer als etwa das [[Atmel Studio]] oder [[AVR Eclipse|Eclipse]]-basierte Entwicklungsumgebungen. So gibt es keine gesonderte Verwaltung von Bibliotheken (libraries/ Header-Dateien). Jedes Projekt ist abgeschlossen und enthält alle notwendigen Abhängigkeiten, statt sie aus einer gemeinsamen Ablage zu beziehen. Diese Arbeitsweise entspricht eher dem ad-hoc-Charakter des Arduino. Es sollen schnell Ergebnisse sichtbar sein, ohne allzu tief in die Materie eintauchen zu müssen.

Die Grafische Oberfläche compiliert die Sketche (engl. für Skizze, so heißt ein Arduino-Programm offiziel) nicht, sondern ruft verschiedene Programme auf. Dies sind in der Regel der Compiler avr-g++ (und zugehörige Programme, z.B. ein Linker) und avrdude, ein Programm zum übertragen des compilierten Sketch als *.hex File auf den Flashspeicher des Arduino. Die IDE basiert auf der Processing IDE und Wiring.

Für die Einsteiger-freundliche virtuelle Verkabelung kann [[Schaltplaneditoren#Fritzing|Fritzing]] benutzt werden. Wie für die Arduino IDE zählt auch hier nicht die technische Genauigkeit. Wer aber sein Arduino-Projekt schnell zeichnen möchte, so dass andere es schnell nachbauen können, ist damit bestens beraten.

==Die Boards==
Die Arduino-Boards sind Atmel AVR/ARM Chips basierende Mikrocontrollerplatinen,
welche zur Steuerung von I/O-Pins gedacht sind. Im Gegensatz zu anderen Boards sind die Arduino-Boards nicht gedacht um als "Computer" mit Betriebssystem zu dienen, wie etwa der Raspberry Pi, sondern um die I/O Pins zu steuern. Es gibt mehr als 10 echte Arduino Boards mit 13 - 70 I/O Pins. Die Platinen besitzen meistens einen USB-Aschluß (USB-B bzw. USB-Mini) oder eine Schnittstelle für einen USB-Serial-Konverterchip. Die Platinen mit USB-Anschluß haben einen solchen Chip integriert. Ältere Boards nutzen dafür einen FTDI-Chip, oder einen 8U2/16U2 bei neueren Boards. Eine Ausnahme bildet hier der Arduino Leonardo: Dieser besitzt einen Atmel-AVR 32U4 Mikrocontroller, welcher auch die Funktionen eines FTDI-Chips besitzt. Es ist also kein weiterer Konverter nötig.
Neben den von Arduino selbst hergestellten Boards gibt es eine Vielzahl von Sprösslingen, die von anderen Firmen auf der Arduino-Architektur aufgesetzt werden. Dieser Artikel beschäftigt sich der Einfachheit wegen nur mit den echten Arduinos. Es lohnt sich aber auch die anderen Boards zu studieren, um noch kleinere, noch sparsamere oder noch leistungsfähigere zu finden.

Wer wenig Erfahrung mit Elektronik hat muss darauf achten, einen Arduino mit einem austauschbaren Chip zu kaufen. Dazu gehört der Uno (mittlerweile R3). Alle anderen Boards haben fest verlötete Prozessoren und ein Fehler im eigenen Projekt mit anschließendem Kurzschluss, Spannungs- oder Stromspitzen entwertet so die gesamte Platine. Da die anderen Varianten zudem oft in Oberflächenmontage und mit vielen Beinchen gelötet werden, ist ein Austausch für den Anfänger ausgeschlossen. Einen neuen ATMega328P (PDIP/ Plastikinsekt mit 32 Beinen) gibt es im Elektronikhandel für ca. 3 Euro im Gegensatz zu 25 Euro für ein komplettes Board. (Den blanken Chip kann man aus der IDE mit dem Bootloader ''flashen''.)

Es ist generell ratsam mit einem kleinen Arduino einzusteigen. Wer noch keine Bastelkiste mit Elektronikteilen hat, dem seien die Startpakete ans Herz gelegt. Neben den wichtigsten Bauteilen enthalten sie ein kleines Steckbrett, ein paar Drahtbrücken und ein Buch mit ca. 10 Projekten. Wenn man dann dem Speicher des Uno entwachsen ist und die Anschlüsse nicht mehr reichen, lohnt sich der Umstieg auf die größeren Varianten. Wer es dann elektronischer haben möchte, der schaut sich die gesamte Atmel-Palette an, in die Kataloge der anderen Hersteller oder rüstet gleich auf einen vollwertigen Mini-PC um.

===Arduino Uno===
Der Arduino Uno R3 ist der Standard-Arduino. In den meisten Anfänger-Bücher und Tutorials wird dieser Arduino verwendet. Auch sind die meisten Libaries für ihn geschrieben. Er ist der neuste der am längsten weiterentwickleten Arduino-Reihe.
So ist eine frühere Version des Arduino Uno (Arduino USB) das Board gewesen, welches als erstes ''Arduino'' gennant wurde. In der aktuellen Revision (Version) 3 besitzt der Uno 14 Digitale I/O Pins sowie 6 analoge Eingänge. Er besitzt eine Spannungsregelung und darf mit 12V über einen Hohlstecker versorgt werden, kann aber auch an bereits geregelte 5V angeschlossen werden und besitzt folgende Speicherkapazitäten:
* 32K Flash(0,5 werden vom Bootloader verwendet.)
* 2K SRAM
* 1K EEPROM
* 16 MHz (Prozessortakt)
Neben dem USB-B Anschluß verfügt der Uno noch über folgende Anschlüsse:
* Hohlstecker-Buchse (2.1mm , 6-20 V möglich)
* SPI
* I²C
* ICSP

==== Arduino Mega ====
Hinsichtlich der Ein- und Ausgänge sowie dem verfügbaren Speicher ist der Mega der große Bruder von allen AVR-basierten Arduinos. Die aktuellen Versionen sind der Mega 2560 und der Mega ADK. Neben 16 analogen Eingängen gibt es 54 digitale Kanäle von denen 15 mit PWM steuern können. Zur seriellen Kommunikation, sog. UARTs, können 4 Kanäle genutzt werden. Der Flash-Speicher ist mit 256kByte 8mal größer als der des Uno. So passen eine Menge Bibliotheken in eigene Programme.

==== Arduino Due ====
Im Gegensatz zu den übrigen Boards wird für den Due ein ARM Cortex-M3-Chip (Atmel SAM3X8E) verbaut. Das bringt den größten Flash-Speicher mit 512kByte und zum Mega vergleichbare Ein- und Ausgänge. Die drei wichtigsten Unterscheidungsmerkmale sind die deutlich höhere Taktfrequenz von 84MHz (statt 16MHz), 32bit-Verarbeitung (statt 8bit) und 2 analoge Ausgänge. Zudem darf der Due nur mit 3.3V betrieben und angesteuert werden, d.h. alle I/O-Pins müssen an 5V-Logik angepasst werden, sollen sie mit 5V genutzt werden.

==== Andere Boards ====
Der Arduino Duemilanove ist der Vorgänger des Arduino Uno. Er besitzt den
ATmega168 (seit 2009 328p) statt dem 328 wie beim Uno. Als Konverter verwendet der Duemilianove eine FTDI-Chip anstelle eines 16U2. Sonst ist von der Pin anzahlen und den Maßen des Boards identisch mit denen des Uno. Das Board des ''Ethernet'' verfügt über einen RJ45-Anschluss sowie einen microSD-Karten-Slot. Wenn man einen Arduino als USB-Gerät benutzen möchte, dann bietet sich der ''Leonardo'' an. Der verbaute Mikrocontroller (ATmega32u4) besitzt eine in Hardware implementierte USB-Schnittstelle. Den übrigen Boards fehlt dafür der Programmieranschluss für den separaten USB-Controller oder es muss ein Programmieradapter statt des USB-Kabels benutzt werden, die Firmware entsprechend zu aktualisieren.

Alle o.a. Boards sind groß und so gibt es etwa die ''Lilipads'', deren runde Platine und niedrige Bauhöhe den Einsatz in Textilien erleichtert. Sie sind nicht mehr kompatibel zu den Shields. Wer es dennoch niedrig und Shield-kompatibel wünscht, der kann die ''Pro''-Modelle nutzen. Sie haben eine feste Spannungsreglung und müssen mit 3.3V oder 5V betrieben werden. Die Buchsenleisten sind nicht vorgelötet. Die kleinsten Boards sind die ''Pro Mini''-Varianten. Sie haben nur noch die Größe eines Kaugummistreifens. Diese Miniaturisierung fordert auch ihren Tribut und die höchstzulässige Verlustleistung des verbauten Chips ist geringer als bei den großen Boards.

==Tutorial==
===Ein erster Sketch: Blinkende LED===
Die meisten aktuellen Arduino-Boards habe einen fest verlötete
SMD-LED, welche an Pin 13 angeschloßen ist. Diese LED kann von jedem
Sketch angesteuert werden. Da diese LED meistens vorhanden ist und immer an Pin 13 ageschloßen ist, ist dieses Programm auf den meisten Boards gleich.
<syntaxhighlight lang="c">
//Blinkende LED
void setup() {
pinMode(13,OUTPUT);
}

void loop() {
delay(1000);
digitalWrite(13,HIGH);
delay(1000);
digitalWrite(13,LOW);
}
</syntaxhighlight>

==Shields(Erweiterungsplatinen)==
Sogennante Shields sind Erweiterungsplatinen, die die Funktionen eines Arduino-Boards um neue Funktionen erweitern. So gibt es z.B. Shields die den Arduino um eine Ethernet-Schnittstelle erweitern, einen VGA-Aschluß besitzen oder einfach leere Platinen sind, auf die eine Chip eingesetzt werden kann, ohne zu Löten. Für das letztere Bsp. wäre eine solche Platine die XBEE-Antenne. Es gibt eine eigene Datenbank <ref name="shieldlist">[http://shieldlist.org/] Shieldlist für Arduino</ref> nur für Shields.

===8-bit LCD-Shield mit Touch-Controller ohne IRQ-Pin===

Seit ca. Herbst 2012 werden einige LCD-Shields mit Touch-Controller angeboten, die den IRQ-Pin nicht mehr durchschleifen.

Damit läuft auch die U-Touch Bibliothek von Henning Carlsen nicht mehr. Alle Sample-Codes im Web funktionieren auch nicht. Das Problem besteht darin herauszufinden, mit welchem Arduino-Pin das CS-Signal verbunden ist. Hier hilft nur: Sheets studieren.

Beim Austesten des Touch-Shields ergab sich bei mir zusätzlich ein y-Basiswert des Touchcontrollers von 4095 ('kein Touch') und eine Differenz der Widerstandswerte zwischen 'Touch' und 'keine Touch' von 180 (x) bzw. 240 (y), siehe Code-Kommentare.

Bei mir lief schließlich folgender Code (das CS-Signal lag auf Pin 10):
<syntaxhighlight lang="c">
#define LCD_RS 19
#define LCD_WR 18
#define LCD_CS 17
#define LCD_REST 16

#define DCLK 15
#define DIN 14
#define CS 10
#define DOUT 8

//#define IRQ 7

unsigned int TP_X,TP_Y,x0,y0;
unsigned int l3=0;
int lx,ly, l2, ry,rx,x3=65,y3=318;
int k=3, vh2=0x84,vl2=0xFF;

void spistar() //SPI Start
{
digitalWrite(CS,LOW);
digitalWrite(DCLK,HIGH);
digitalWrite(DIN,HIGH);
digitalWrite(DCLK,HIGH);

}
//**********************************************************
void WriteCharTo7843(unsigned char num) //SPI Write Data
{
unsigned char count=0;
unsigned char temp;
unsigned nop;
temp=num;
digitalWrite(DCLK,LOW);
for(count=0;count<8;count++)
{
if(temp&0x80)
digitalWrite(DIN,HIGH);
else
digitalWrite(DIN,LOW);

temp=temp<<1;

digitalWrite(DCLK,LOW);
nop++;
nop++;
digitalWrite(DCLK,HIGH);
nop++;
nop++;
}
}

//**********************************************************
unsigned int ReadFromCharFrom7843() //SPI Read Data
{
unsigned nop;
unsigned char count=0;
unsigned int Num=0;
for(count=0;count<12;count++)
{
Num<<=1;
digitalWrite(DCLK,HIGH);//DCLK=1; _nop_();_nop_();_nop_();
nop++;
digitalWrite(DCLK,LOW);//DCLK=0; _nop_();_nop_();_nop_();
nop++;
if(digitalRead(DOUT)) Num++;
}
return(Num);
}

void LCD_Writ_Bus(char VH,char VL)
{
PORTD = VH;
digitalWrite(LCD_WR,LOW);
digitalWrite(LCD_WR,HIGH);
PORTD = VL;
digitalWrite(LCD_WR,LOW);
digitalWrite(LCD_WR,HIGH);
}

void LCD_Write_COM(char VH,char VL)
{
digitalWrite(LCD_RS,LOW);
LCD_Writ_Bus(VH,VL);
}

void LCD_Write_DATA(char VH,char VL)
{
digitalWrite(LCD_RS,HIGH);
LCD_Writ_Bus(VH,VL);
}

void Lcd_Write_Com_Data(int com,int val)
{
LCD_Write_COM(com>>8,com);
LCD_Write_DATA(val>>8,val);
}

void Address_set(unsigned int x1,unsigned int y1,unsigned int x2,unsigned int y2)
{
LCD_Write_COM(0x00,0x46);LCD_Write_DATA(x2,x1);
LCD_Write_COM(0x00,0x47);LCD_Write_DATA(y2>>8,y2);
LCD_Write_COM(0x00,0x48);LCD_Write_DATA(y1>>8,y1);
LCD_Write_COM(0x00,0x20);LCD_Write_DATA(x1>>8,x1);
LCD_Write_COM(0x00,0x21);LCD_Write_DATA(y1>>8,y1);
LCD_Write_COM(0x00,0x22);
}

void LCD_Init(void)
{

digitalWrite(LCD_REST,HIGH);
delay(5);
digitalWrite(LCD_REST,LOW);
delay(5);
digitalWrite(LCD_REST,HIGH);
delay(5);

digitalWrite(LCD_CS,LOW);
Lcd_Write_Com_Data(0x11,0x2004);
Lcd_Write_Com_Data(0x13,0xCC00);
Lcd_Write_Com_Data(0x15,0x2600);
Lcd_Write_Com_Data(0x14,0x252A);
Lcd_Write_Com_Data(0x12,0x0033);
Lcd_Write_Com_Data(0x13,0xCC04);
delay(1);
Lcd_Write_Com_Data(0x13,0xCC06);
delay(1);
Lcd_Write_Com_Data(0x13,0xCC4F);
delay(1);
Lcd_Write_Com_Data(0x13,0x674F);
Lcd_Write_Com_Data(0x11,0x2003);
delay(1);
Lcd_Write_Com_Data(0x30,0x2609);
Lcd_Write_Com_Data(0x31,0x242C);
Lcd_Write_Com_Data(0x32,0x1F23);
Lcd_Write_Com_Data(0x33,0x2425);
Lcd_Write_Com_Data(0x34,0x2226);
Lcd_Write_Com_Data(0x35,0x2523);
Lcd_Write_Com_Data(0x36,0x1C1A);
Lcd_Write_Com_Data(0x37,0x131D);
Lcd_Write_Com_Data(0x38,0x0B11);
Lcd_Write_Com_Data(0x39,0x1210);
Lcd_Write_Com_Data(0x3A,0x1315);
Lcd_Write_Com_Data(0x3B,0x3619);
Lcd_Write_Com_Data(0x3C,0x0D00);
Lcd_Write_Com_Data(0x3D,0x000D);
Lcd_Write_Com_Data(0x16,0x0007);
Lcd_Write_Com_Data(0x02,0x0013);
Lcd_Write_Com_Data(0x03,0x0003);
Lcd_Write_Com_Data(0x01,0x0127);
delay(1);
Lcd_Write_Com_Data(0x08,0x0303);
Lcd_Write_Com_Data(0x0A,0x000B);
Lcd_Write_Com_Data(0x0B,0x0003);
Lcd_Write_Com_Data(0x0C,0x0000);
Lcd_Write_Com_Data(0x41,0x0000);
Lcd_Write_Com_Data(0x50,0x0000);
Lcd_Write_Com_Data(0x60,0x0005);
Lcd_Write_Com_Data(0x70,0x000B);
Lcd_Write_Com_Data(0x71,0x0000);
Lcd_Write_Com_Data(0x78,0x0000);
Lcd_Write_Com_Data(0x7A,0x0000);
Lcd_Write_Com_Data(0x79,0x0007);
Lcd_Write_Com_Data(0x07,0x0051);
delay(1);
Lcd_Write_Com_Data(0x07,0x0053);
Lcd_Write_Com_Data(0x79,0x0000);

LCD_Write_COM(0x00,0x22);
digitalWrite(LCD_CS,HIGH);

}

void Pant(char VH,char VL)
{
int i,j;
Address_set(0,0,240,320);
for(i=0;i<=320;i++)
{
for (j=0;j<=240;j++)
{
LCD_Write_DATA(VH,VL);
}
}
}

void digi(int z3)
{
unsigned char p;
int x2, y2, z2, i,h2=1000;
digitalWrite(LCD_CS,LOW);
for(i=0;i<3;i++)
{
y2=y3;
x2=x3+(10*i);
Address_set(x2+6,y2-15,x2+7,y2);
for(p=0; p<32; p++) LCD_Write_DATA(0xFF,0xFF);
Address_set(x2,y2-15,x2+7,y2-14);
for(p=0; p<16; p++) LCD_Write_DATA(0xFF,0xFF);
Address_set(x2,y2-1,x2+7,y2);
for(p=0; p<16; p++) LCD_Write_DATA(0xFF,0xFF);
Address_set(x2,y2-8,x2+7,y2-7);
for(p=0; p<16; p++) LCD_Write_DATA(0xFF,0xFF);
Address_set(x2,y2-15,x2+1,y2);
for(p=0; p<32; p++) LCD_Write_DATA(0xFF,0xFF);

h2=h2/10;
z2=z3/h2;
z3=z3-z2*h2;
if (z2==0) {
Address_set(x2+2,y2-8,x2+5,y2-7);
for(p=0; p<8; p++) LCD_Write_DATA(0x00,0x00);
}
if (z2==1) {
Address_set(x2,y2-15,x2+5,y2);
for(p=0; p<96; p++) LCD_Write_DATA(0x00,0x00);
}
if (z2==2) {
Address_set(x2,y2-13,x2+1,y2-9);
for(p=0; p<10; p++) LCD_Write_DATA(0x00,0x00);
Address_set(x2+6,y2-6,x2+7,y2-2);
for(p=0; p<10; p++) LCD_Write_DATA(0x00,0x00);
}
if (z2==3) {
Address_set(x2,y2-13,x2+1,y2-9);
for(p=0; p<10; p++) LCD_Write_DATA(0x00,0x00);
Address_set(x2,y2-6,x2+1,y2-2);
for(p=0; p<10; p++) LCD_Write_DATA(0x00,0x00);
}
if (z2==4) {
Address_set(x2,y2-6,x2+5,y2);
for(p=0; p<42; p++) LCD_Write_DATA(0x00,0x00);
Address_set(x2+2,y2-15,x2+5,y2-14);
for(p=0; p<8; p++) LCD_Write_DATA(0x00,0x00);
}
if (z2==5) {
Address_set(x2+6,y2-13,x2+7,y2-9);
for(p=0; p<10; p++) LCD_Write_DATA(0x00,0x00);
Address_set(x2,y2-6,x2+1,y2-2);
for(p=0; p<10; p++) LCD_Write_DATA(0x00,0x00);
}
if (z2==6) {
Address_set(x2+6,y2-13,x2+7,y2-9);
for(p=0; p<10; p++) LCD_Write_DATA(0x00,0x00);
}
if (z2==7) {
Address_set(x2,y2-13,x2+5,y2);
for(p=0; p<84; p++) LCD_Write_DATA(0x00,0x00);
}
if (z2==9) {
Address_set(x2,y2-6,x2+1,y2-2);
for(p=0; p<10; p++) LCD_Write_DATA(0x00,0x00);
}
}

digitalWrite(LCD_CS,HIGH);
}

void newpa(void)
{
unsigned char p;
digitalWrite(LCD_CS,LOW);
Pant(0x00,0x00);

Address_set(0,319,240,319);
for(p=0; p<240; p++) LCD_Write_DATA(0xF8,0x00);
Address_set(0,0,240,0);
for(p=0; p<240; p++) LCD_Write_DATA(0xFF,0xFF);
Address_set(0,300,240,300);
for(p=0; p<240; p++) LCD_Write_DATA(0xFF,0xFF);
Address_set(0,0,0,255);
for(p=0; p<255; p++) LCD_Write_DATA(0xF8,0x00);
Address_set(0,255,0,300);
for(p=0; p<45; p++) LCD_Write_DATA(0xF8,0x00);
Address_set(239,0,239,255);
for(p=0; p<255; p++) LCD_Write_DATA(0xF8,0x00);
Address_set(239,255,239,300);
for(p=0; p<45; p++) LCD_Write_DATA(0xF8,0x00);
Address_set(50,308,59,311);
for(p=0; p<40; p++) LCD_Write_DATA(0x07,0xE0);
Address_set(53,305,56,314);
for(p=0; p<40; p++) LCD_Write_DATA(0x07,0xE0);
Address_set(215,305,239,314);
for(p=0; p<250; p++) LCD_Write_DATA(0xF8,0x00);
digitalWrite(LCD_CS,HIGH);

}

void recan(void)
{
int i,j;
// unsigned int m;
digitalWrite(LCD_CS,LOW);
for(i=0;i<7;i++)
{
// m=i*3;
Address_set(i*5,305,i*5+3,314);
for(j=0; j<40; j++)
{
if (1+i*2<= k) LCD_Write_DATA(0xFF,0xE0); else LCD_Write_DATA(0x00,0x00);
}
}
Address_set(100,305,124,314);
for(i=0; i<250; i++) LCD_Write_DATA(vh2,vl2);
Address_set(125,305,149,314);
for(i=0; i<250; i++) LCD_Write_DATA(vh2,vl2);
digitalWrite(LCD_CS,HIGH);
}

void AD7843(void)
{
digitalWrite(CS,LOW);
WriteCharTo7843(0x90);
digitalWrite(DCLK,HIGH);
digitalWrite(DCLK,LOW);
TP_Y=ReadFromCharFrom7843();
WriteCharTo7843(0xD0);
digitalWrite(DCLK,HIGH);
digitalWrite(DCLK,LOW);
TP_X=ReadFromCharFrom7843();
digitalWrite(CS,HIGH);

}

void setup()
{

unsigned char p;

for(p=0;p<20;p++)
{
pinMode(p,OUTPUT);
}
pinMode(DOUT,INPUT);
x0=1;
y0=1;

LCD_Init();
newpa();
recan();
digi(vh2);
x3=x3+90;
digi(vl2);
spistar();
}

void loop()
{
rx=0;
ry=0;

for(l3=0;l3<8;l3++)
{
AD7843();

lx=0;
ly=-1*TP_Y;
ly=4095+ly; //4095=Basiswert y-Signal
if(ly > 0) lx=1*TP_X; else {lx=0;ly=0;rx=0;ry=0;l3=9; }
rx=rx+lx;
ry=ry+ly;
}
lx=(rx/8-180)/15; //180=Minimaler x-Wert bei 'Touch'
ly=(ry/8-240)/11; //240=Minimaler (über 4095) y-Wert bei 'Touch'
if(ly < 1) {lx=0;ly=0; }
if(lx < 1) lx=0;

if(ly > 309-k)
{
ly=0;
if(lx > 200) k=k-2; else if (lx > 160) k=k+2;else
if (lx > 100) vh2++; else if (lx > 40) vl2++; else newpa();
lx=0;
if (k<1) k=1;
if (k>13) k=13;
if (vh2>255) vh2=0;
if (vl2>255) vl2=0;
x3=65;
digi(vh2);
x3=x3+90;
digi(vl2);
recan();
}

if(ly > 299-k) ly=299-k;
if(ly > 0)
{
x0=240-lx;
if(x0 > 240-k) x0=240-k;
y0=ly;
l2=(k+1)*(k+1);
digitalWrite(LCD_CS,LOW);
Address_set(x0,y0,x0+k,y0+k);
for (l3=0; l3<l2; l3++) LCD_Write_DATA(vh2,vl2);
digitalWrite(LCD_CS,HIGH);
}
delay (50);
}
</syntaxhighlight>

== Downloads ==
* [http://www.arduino.cc/en/Main/Software Download der IDE]
* [http://www.mikrocontroller.net/articles/AVR Artikel zur AVR Prozessor-Serie]
* [http://sourceforge.net/projects/arduinosources/ Quelltexte zu Arduino - Hard- und Software Open Source Plattform (ISBN 978-3-907857-16-8)]
* [http://sourceforge.net/projects/arduinoynsnippets/ Programmbeispiele zu beiden Prozessoren des Arduino Yún: Atheros AR9331 mit Linino (openWRT) & ATmega32u4]

==Literatur==
* Günter Spanner: ''Arduino: Schaltungsprojekte für Profis'', Elektor Verlag, 2012, ISBN 978-3-89576-257-4
* Erik Bartmann: ''Die elektronische Welt mit Arduino entdecken'', O'Reilly Verlag, 2011, ISBN 978-3-89721-319-7
* Thomas Brühlmann: ''Arduino: Praxiseinstieg'', mitp Verlag, 2010, ISBN 978-3-8266-5605-7
* Claus Kühnel: ''Arduino Yún - Arduino für die Cloud'', Skript Verlag Kühnel 2014, ISBN 978-3-907857-20-5
* Claus Kühnel: ''Arduino für die Cloud - Arduino Yún & Dragino Yún Shield'', 2. Aufl., Skript Verlag Kühnel 2014, ISBN 978-3-907857-25-0

==Bezugsquellen(Auswahl)==

===Offiziele Boards===
* [http://www.watterott.com/de/Boards-Kits/Arduino Watterott.com]
* [http://www.reichelt.de/ Reichelt.de]
* [http://www.conrad.de/ Conrad.de]
* [http://www.tigal.com/ TIGAL.com]

===Lernpakete===
* [http://www.franzis.de/ Franzis Verlag(Lernpakete)]

== Siehe auch ==
* [http://www.arduino.cc/ Website des Arduino-Projekt]
* [http://arduino.cc/forum/index.php/board,31.0.html Deutsches Arduino-Forum(offiziel)]

<references />
[[Kategorie:AVR-Boards]]

AVR In System Programmer

2015-01-21T22:50:17Z

Maybee:

== Einführung ==

In-System-Programming (ISP) bedeutet, einen Mikrocontroller oder anderen programmierbaren Baustein im eingebauten Zustand zu programmieren. Dazu muss der Mikrocontroller entsprechend beschaltet sein. Das bedeutet, die benötigten Anschlüsse am Mikrocontroller müssen zugänglich und nicht ohne weitere Vorkehrungen anderweitig benutzt sein - siehe [http://www.atmel.com/images/atmel-2521-avr-hardware-design-considerations_application-note_avr042.pdf Atmel Application Note AVR042].

Atmel verwendet für ihre 8-Bit RISC Mikrocontroller zum Teil unterschiedliche ISP-Protokolle. Das bekannteste davon wird einfach als ISP bezeichnet. Insgesamt findet man:

;ISP:Der Normalfall. Bei vielen, aber nicht allen AVRs teilen sich [[SPI]]- und ISP-Schnittstelle die Pins. Je nach AVR gibt es leichte Unterschiede im Protokoll. Das Protokoll für einen Typ ist im Datenblatt unter ''Memory Programming -> Serial Downloading'' beschrieben.
;TPI:Tiny Programming Interface. Einige AVRs der Tiny-Serie, besonders die 6-Pin Tinys.
;PDI:Programming and Debugging Interface. Die XMEGAs.
;JTAG:AVRs mit [[JTAG]] Debugging-Schnittstelle lassen sich auch über JTAG in-system-programmieren.
;Bootloader:Einige wenige AVRs kommen bereits mit einem einprogrammierten [[Bootloader]]. Bei diesen kann man ein zum Bootloader passendes Programm nutzen um den AVR über eine im Bootloader definierte Schnittstelle programmieren. Auf Bootloadern basierende Systeme haben ansonsten ein Henne-Ei Problem. Irgendwie muss der Bootloader einmal konventionell in den AVR programmiert werden, zum Beispiel mit ISP.

Atmels [[debugWire]] ist keine Programmierschnittstelle, sondern eine reines Debugging-Interface. Zum Programmieren verwendet man bei AVRs mit debugWire daher normalerweise ISP.

Atmel hat für die AVR 8-Bit RISC Mikrocontroller mehrere Application Notes herausgegeben, auf deren Basis eine Vielzahl von Programmiergeräten (''programmer'') entwickelt wurden.

Natürlich liefert Atmel auch eigene, fertige Programmiergeräte (AVRISP (mk I), AVRISP mk II, [[AVR-Dragon]], ...), Programmiersoftware (AVRProg, AVR Studio) und Entwicklungsboards mit integriertem Programmiergerät (z. B. [[STK500]]).

<big>FAQ/Tipp: '''"Welchen ISP-Adapter sollte man sich zulegen oder bauen?"'''</big>

Man sollte sich einen fertigen, original Atmel (keinen Clone) ISP-Adapter kaufen. Zum Beispiel für ISP (und PDI) Programmierung '''Atmels original [[AVR_In_System_Programmer#Atmel_AVRISP_MKII|AVRISP mkII]] für rund 36,- Euro'''.

Das ist eine Investition, die viel Zeit und Ärger spart, denn es geht nichts über zuverlässiges Werkzeug. Beim Umgang mit µCs ist es sehr frustrierend an drei Fronten gleichzeitig zu kämpfen:
# Bugs in der Software,
# Bugs in der Schaltung und
# Bugs/Probleme beim ISP-Adapter-/PC-Gespann.

Wenigstens Probleme mit dem ISP-Adapter lassen sich durch den Kauf eines zuverlässigen ISP-Adapters eliminieren. Siehe auch diverse Forenbeiträge u.a. [http://www.mikrocontroller.net/topic/91042#778908] und [http://www.mikrocontroller.net/topic/153841#1447882].

Sehr unzuverlässig sind häufig billige oder selbstgebaute Programmierkabel mit nichts außer ein paar Widerständen. Unzuverlässig sind häufig auch billige oder selbstgebaute Programmierkabel mit einem einfachen Bustreiber. Nur weil sie bei manchen funktionieren heißt das nicht, dass sie überall problemlos funktionieren.

Parallelport- (Druckerport-) ISP-Adapter funktionieren gar nicht, wenn man sie mit einem USB <-> Druckerport Adapter an einen USB-Port am PC anschließt. Einfach (unintelligente) ISP-Adapter für die serielle Schnittstelle funktionieren gar nicht oder extrem langsam, wenn man sie mit einem USB <-> Seriell Adapter am PC anschließt. Gute intelligente serielle Programmieradapter, wie der in Atmels STK500 eingebaute, funktionieren normalerweise mit einem USB-Adapter.

Bei allen Programmieradaptern mit eigener Firmware, einschließlich der Original-Adapter von Atmel, ist man darauf angewiesen, dass der Hersteller wenn nötig Firmware-Updates bereitstellt. Bei Clones ist die Versorgung mit Firmware manchmal fraglich.

Oftmals funktionieren auch die Treiber der Clones unter 64-Bit Betriebssystem nicht richtig oder nur mit Tricks, die leider wichtige Sicherheitsfunktionen des Betriebssystem abschalten. Der [[AVR_In_System_Programmer#Atmel_AVRISP_MKII|AVRISP mkII]] funktioniert dagegen auch unter Windows 7 (64-Bit).

== Application Notes ==
* [http://www.atmel.com/dyn/resources/prod_documents/DOC0943.PDF AVR910] (PDF) "''Low-cost''" ''In-system programming'' ('''AVRISP''') beschreibt einen einfachen, kostengünstigen Programmieradapter zur Übertragung von Programmen in den Mikrocontroller. Auf dem Programmer befindet sich ein Mikrocontroller (natürlich von Atmel ;-), der serielle Steuerkommandos und Daten vom PC in Programmiersignale für den Mikrocontroller umsetzt.

* [http://www.atmel.com/dyn/resources/prod_documents/doc2568.pdf AVR911] (PDF) ''Open source serial programmer'' ('''AVROSP''') beschreibt eine ''open source'' Programmiersoftware zur Übertragung von Programmen in den Mikrocontroller.

* [http://www.atmel.com/dyn/resources/prod_documents/doc1644.pdf AVR109] (PDF) ''Self-Programming'' mit Hilfe eines [[Bootloader|Bootloaders]]. Hier wird im Mikrocontroller zunächst ein mikrocontroller-spezifisches Bootloader-Programm abgelegt. Dieses Programm empfängt das eigentliche Benutzerprogramm oder Daten z. B. über einen seriellen Anschluss ([[UART]]), legt es ggf. im Speicher (Flash-ROM, EEPROM) ab und führt ggf. anschliessend das Benutzerprogramm aus.

== Pinbelegung ==
===ISP===
Die Standard-Pinbelegung des ISP-Steckers zum Anschluss des Mikrocontrollers sieht nach obigen Application Notes und der [http://www.atmel.com/images/atmel-2521-avr-hardware-design-considerations_application-note_avr042.pdf AVR042] (PDF) folgendermaßen aus (Anschluss auf der Platine, Ansicht von oben). Atmel bevorzugt dabei bereits seit Jahren den 6-poligen Anschluss.

[[Bild:avr-isp-pinout.png|right]]

10-poliger 6-poliger
Anschluss Anschluss

1 MOSI 1 MISO
2 VCC 2 VCC
3 - (*) 3 SCK
4,6,8,10 GND 4 MOSI
5 RESET 5 RESET
7 SCK 6 GND
9 MISO

Pin 1 ist am Pfostenstecker mit einem kleinen Pfeil gekennzeichnet.

Um Verwechslungen zu vermeiden, empfiehlt es sich, für die einzelnen Leitungen unterschiedliche Farben zu verwenden. Atmel hat dafür keine Festlegung getroffen, so dass es keinen festen Standard gibt. Üblich ist jedoch eine Farbzuordnung wie beim [https://guloshop.de/shop/Mikrocontroller-Programmierung/guloboard-G6::5.html guloboard]:

1 MISO weiß
2 VCC rot
3 SCK blau
4 MOSI grün
5 RESET gelb
6 GND schwarz

(*) Einige Programmieradapter (Ponyprog-Adapter nach Lancos-Schaltplan) unterstützen an Pin 3 des 10-poligen Steckers eine LED (Kathode an Pin), die "Programmierzugriff" signalisieren soll. Dies ist aber kaum nützlich, daher wird der Pin auch von Atmel als N/C (not connected) definiert und beim original Atmel AVRISP mit GND verbunden.

Der 10-polige Anschluss wurde von der Firma Kanda beim STK200 verwendet und ist deshalb auch als "Kanda-Standard" bekannt und war zur Zeit der STK200 Programmieradapter relativ weit verbreitet. Die Anschlussbelegung über einen 6-poligen Stecker stammt von Atmel selbst und ist platzsparender auf der Platine.

Am besten kauft oder fertigt man sich einen Adapter 6 <-> 10 (siehe [http://www.shop.robotikhardware.de/shop/catalog/product_info.php?products_id=190], [http://www.watterott.com/de/AVR-ISP-Programmieradapter], [http://www.watterott.com/de/AVR-Programmier-Kabel], [https://guloshop.de/shop/Adapterkabel/Programmieradapterkabel-6-polig-10-polig-lang::9.html]), dann lassen sich praktisch alle Boards mit jedem Programmer programmieren.

[[Datei:Kabeloben.jpg]]
[[Datei:Kabelunten.jpg]]
[[Datei:isp_kab.jpg]]

Zehnpolige Messerleisten (Wannenstecker) zur Montage auf einer µC Platine zum verpolungssicheren Anschluss des Programmieradapters sind fast "überall" verfügbar, nach den sechspoligen muss man häufig etwas suchen. Mittlerweile sind sie endlich bei Reichelt erhältlich (WSL 6G). 
Alternativ bleibt nur der Griff zu den nicht verpolungssicheren 2xN Stiftleisten (z. B. 2x40), wobei man eine Stiftleiste auf 2x3 Pole kürzt.

Sechspolige Federleisten (Pfostenbuchsen) zum Anquetschen an ein Programmierkabel sind dagegen zumindest bei den großen Versendern und Distributoren erhältlich (z. B. von Bürklin Art.53F3500; Conrad Art.701980-62; Farnell Art.1097021; Reichelt PFL 6). Kleine lokale Elektronikläden führen diese jedoch häufig nicht. Zu den sechpoligen Pfostenbuchsen gibt es keine Alternative, wenn man ein sechpoliges Programmierkabel bauen möchte. Zehnpolige Pfostenbuchsen lassen sich nicht auf sechs Pole kürzen. Korrektur: Man kann die äußeren pins ( 2 rechts, 2 links) einfach rausdrücken, dann passt der 6pol in die Buchse. Verpolungsschutz besteht weiterhin.

Je nach Programmieradapter hat der VCC-Anschluss unterschiedliche Funktionen:

1. Versorgung des Programmieradapters mit Strom aus der Schaltung, wie es bei vielen Parallelport-Adaptern der Fall ist.

2. Versorgung der Schaltung mit Strom aus dem Programmieradapter. Dies ist insbesondere beim STK500 möglich und dank dessen programmierbarer Versorgungsspannung manchmal ganz praktisch.

3. Messung der Betriebsspannung der Schaltung, so dass der Programmieradapter sich auf diese Spannung einstellen kann und so ein 3,3 V Board mit 3,3 V und ein 5 V Board mit 5 V programmiert. So wie zum Beispiel beim AVRISP mkII. Daher wird VCC auf neueren Schaltbildern auch als Vtg oder VTref bezeichnet (Atmel kann sich da nicht auf eine Bezeichnung einigen).

'''Je nach verwendetem Programmer muss man daher sorgfältig auf die Beschaltung von VCC/Vtg/VTref und auf die Stromversorgung von Board und Programmer achten.'''

*[http://www.mikrocontroller.net/topic/301971#3234822 Forumsbeitrag]: Extrem kleiner ISP Header, wie?
*[http://www.mikrocontroller.net/topic/145711#1352516 Forumsbeitrag]: Kleinserie: ISP Programmierung mögl. ohne Stecker

===TPI===

Die TPI-Programmierung setzt sich aus mehreren Schichten zusammen: Hardware (Ansteuerung der IO-Pins), Speicher-Management (stellt Funktionen zum Flashen bereit) und der Speicher selbst.

Data 1 2 VCC
Clock 3 4 N.C.
Reset 5 6 GND

Standard TPI connector used on e.g. STK600 and AVRISP mkII.

===PDI===
====Atmel Board-Schnittstelle & AVRISP MkII ====
Für Mikrocontroller-Boards schlägt Atmel einen 6-Pin Header, 2,54 mm Raster, mit folgender Pinbelegung vor (Ansicht von Oben):

DATA 1 2 VCC
N.C. 3 4 N.C.
CLK 5 6 GND

(N.C.: Not Connected, nicht verbunden). Diese Belegung wird auch von Atmels AVRISP MkII im PDI-Modus verwendet.

Bei Atmels eigenem XPlain Eval-Kit und anderen Programmieradaptern geht es zur Zeit jedoch noch fröhlich durcheinander. Folgenden Pinbelegungen lassen sich finden.

====Atmel XPlain Eval-Board====

Hier hat Atmel die Xmega PDI- und JTAG-Schnittstelle gemeinsam auf den Header J100 gelegt. Die PDI-Belegung ist wie folgt:

1 2 GND
3 4 VCC
5 6 CLK
VCC 7 '''8 DATA'''
9 10 GND

Nur jeweils ein VCC- und ein GND-Anschluss muss verwendet werden. Es bieten sich die Pins 2 und 4 an.

Man beachte die Position von DATA auf Pin 8 bei dieser Belegung von PDI auf dem XPlain JTAG-Header.

====Atmel JTAGICE MkII====

Einige sehr alte JTAGICE MkII unterstützen kein PDI. Alle neueren, in den letzten Jahren hergestellte tun es. Eventuell ist ein Firmware-Upgrade über AVR-Studio nötig.

Laut [http://support.atmel.no/knowledgebase/avrstudiohelp/mergedProjects/JTAGICEmkII/mkII/Html/Connecting_to_target_through_the_PDI_interface.htm] und der eingebauten Hilfe von [[AVR Studio]] 4.18 SP 1 verwendet ein JTAGICE MkII im PDI-Modus folgende Pinbelegung:

1 2 GND
3 4 VTref
5 6 CLK
7 8
'''DATA 9''' 10 GND

Man beachte, dass DATA hier angeblich auf Pin 9 liegt. (VTref dürfte VCC entsprechen). In der Hilfe zu AVR Studio 4.18 SP 1 ist der Pin CLK mit PDI_CLK, und der Pin DATA mit PDI_DATA bezeichnet.

====Atmel AVR Dragon====

Erst mit der Dragon-Firmware im SP 1 für AVR Studio 4.18 soll der PDI-Support des [[AVR Dragon]] funktionieren. Angekündigt war PDI-Support bereits für AVR Studio 4.18.

Leider hat Atmel es versäumt in der Dragon-Dokumentation die Pinbelegung für PDI auf der Seite des Dragon anzugeben. In der Studio-Dokumentation ist von einem ominösen Dragon PDI Adapter die Rede, der Teil des "Dragon Kit" sein soll. Allerdings wird der Dragon 'nackt' ausgeliefert und bisher gibt es keine Berichte darüber, dass jemand diesen ominösen Adapter gesehen hat. Von neueren Versionen des JTAGICE mkII ist hingegen bekannt, dass sie mit einem ''XMEGA PDI adapter kit'' geliefert werden.

Angeblich ist es nötig, beim Dragon jeweils einen 330Ω Widerstand in die CLK und DATA Leitung zu legen, um Probleme mit dem Überschwingen der Signale zu vermeiden.

== Programmer-Varianten ==

Mittlerweile existiert eine fast unüberschaubare Zahl von Programmer-Varianten und Untervarianten. Hier sollen nur die wichtigsten Varianten mit Bauanleitungen aufgelistet werden, geordnet nach der Art des Anschlusses an den PC.

Zur Zeit (März 2012) gibt es vermehrt Probleme, mit den neuen Varianten 5.x des AVR Studios, kompatible Programmer, die nicht von Atmel selbst hergestellt wurden, anzusteuern. Es sollte beim Erwerb/Nachbau auf die Zusicherung der Komptibilität zum gewünschen AVR Studio geachtet werden.

=== Parallelport ===

==== STK200-kompatibel ====

Fast alle erhältlichen Parallelport-Programmieradapter, u.a. auch der hier im [http://shop.mikrocontroller.net/ Shop] angebotene, sind kompatibel zum Programmer des [[STK200]] / STK300.

* [http://www.mikrocontroller.net/articles/STK200 Schaltbilder für STK200 und kompatible]
* Bauanleitung für einen [http://rumil.de/hardware/avrisp.html STK200-kompatiblen Programmieradapter] von Rolf Milde
* Universelles Programmiergerät mit 74HC244 und Schutzwiderständen http://www.aplomb.nl/TechStuff/PPPD/PPPD%20English.html

==== Paralleles Interface für AVR und PonyProg ====

Schaltplan und Erläuterungen bei [http://s-huehn.de/elektronik/avr-prog/avr-prog-alt.htm Scott-Falk Hühn]

==== SP12 Programmer ====

Schaltplan, Erläuterungen und Software für mehrere Plattformen, darunter auch MSDOS, gibt es bei [http://www.xs4all.nl/~sbolt/e-spider_prog.html#programmer Steven Bolt]. [http://www.xs4all.nl/~sbolt/e-spider_prog.html#programmer Ken's Dongle] ist ein spezieller Kabeladapter für SP12 zur Verbesserung der Signalqualität. Anpassung an neue Typen erfolgt durch leicht selbst erstellbare Beschreibungsdateien.

=== Serieller Port ([[RS-232]]) ===

==== Atmel AVRISP, STK500, AVR910 ====

Der original AVRISP von Atmel, das [[STK500]] und der Programmer aus der Application Note AVR910 enthalten einen Mikrocontroller, der die Umsetzung der seriellen Daten auf das ISP- und TPI-Programmierinterface vornimmt. Sie lassen sich direkt mit dem AVR-Studio programmieren und sind auch problemlos mit einem USB-seriell-Adapter verwendbar.

Ein Layout mit Schaltplan und erweitertem Sourcecode findet sich in diesem Thread in der Codesammlung [http://www.mikrocontroller.net/topic/88295#749553 AVR910 Programmer, Schaltplan, Layout, Firmware].

Das AVR910 Design ist u.a. auf der Seite von [http://www.serasidis.gr/circuits/avr_isp/avr_isp.htm Serasidis Vasilis] im Detail beschrieben.

Eine weitere, auführliche Anleitung zum AVR910 gibt es in deutsch auf der Seite von [http://www.klaus-leidinger.de/mp/Mikrocontroller/AVR-Prog/AVR-Programmer.html Klaus Leidinger].
* [https://www.ssl-id.de/b-redemann.de AVR910-USB-Prog: Bausatz incl. USB-seriell Wandler]
* [http://www.avr-projekte.de/isp.htm AVR910-USB: Bauanleitung incl. USB-seriell Wandler]

==== SI-Prog ====

Daneben gibt es noch weitere Programmieradapter für den seriellen Port, die auf den eigenen Mikrocontroller im Programmieradapter verzichten und das ISP-Programmierprotokoll über die Steuerleitungen des RS-232-Port nachbilden. Das Programmierprogramm auf dem PC sendet jetzt keine Steuerkommandos und Daten mehr, sondern gibt direkt die Programmiersignale an der seriellen Schnittstelle aus ("Pinwackeln an den Statuspins"). Der Nachteil dieser Adapter ist, dass sie meistens relativ langsam sind und nur unter wenigen Betriebssystemen funktionieren. Ein Beispiel dafür ist SI-Prog.

* [http://www.lancos.com/siprogsch.html SI-Prog Originalversion]
* [http://s-huehn.de/elektronik/avr-prog/avr-prog.htm Schaltplan und Erläuterungen]

==== Sercon2 ====

Mit einer etwas anderen Steckerbelegung als der SI-Prog arbeitet die Sercon Familie an Adaptern. Nähere Unterlagen dazu finden sich
[http://www.speedy-bl.com/adapter.htm hier]

==== Selbstbau-Programmer, basierend auf dem FTDI chip (via avrdude) ====
http://irq5.wordpress.com/2010/07/15/programming-the-attiny10/

=== USB ===

Die meisten USB-Programmieradapter verwenden einen USB-seriell-Wandler und ein STK500/AVRPROG-kompatibles Protokoll und können damit direkt aus dem AVR-Studio programmiert werden.

Eine Quick-and-Dirty Programmierlösung bietet der [[#USB-Hub-ISP]], der außer einem USB-Hub nur Standard-Bauteile voraussetzt.

==== Atmel AVRISP MKII ====

Nachfolger des Atmel AVRISP "MKI". Mit USB-Schnittstelle, leistungsfähigerem Programmiercontroller und erweitertem Hardwareschutz. Programmiersoftware: [[AVR-Studio]] und [[AVRDUDE]]. Herstellerinformation bei [http://www.atmel.com/dyn/products/tools_card.asp?family_id=607&family_name=AVR+8%2DBit+RISC+&tool_id=3808 atmel.com]

Der AVRISP MKII führt ca. 1s nach dem Einschalten der Versorgungsspannung einen Reset aus. Lässt man den Programmer beim Testen der Schaltung gesteckt und startet diese durch Einschalten von Vcc, kann dies zu unangenehmen Nebeneffekten führen. Z.B. wird eine gerade angelaufene Datenübertragung nach 1s abrupt abgebrochen, startet neu und läuft danach fehlerfrei.

Dave Jones hat im EEVblog #158 ein [http://www.eevblog.com/2011/03/25/eevblog-158-avr-isp-mk2-lm317-regulator-tutorial/ Videotutorial] erstellt, wie man beim Atmel AVRISP "MKI" mit dem LM317 Spannungsregler 3.3V oder 5V Versorgungsspannungen für das Targetboard nachrüstet. Im Video schlägt Dave als bessere Lösung die Verwendung eines Low-Drop-Spannungsreglers vor. Dafür eignet sich z.B. der [http://www.mikrocontroller.net/part/LM1117 LM1117]

Weiter unten auf dieser Seite wird auch ein einfacher, kompatibler Nachbau namens [http://www.mikrocontroller.net/articles/AVR_In_System_Programmer#usbprog usbprog] vorgestellt.

==== Atmel AT90USBKEY ====
Mit hilfe des [http://www.fourwalledcubicle.com/AVRISP.php AVRISP-MKII Clone] Projekts aus dem [http://www.fourwalledcubicle.com/LUFA.php LUFA] Paket wird aus dem [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3879 AT90USBKEY] recht einfach ein Programmer, der mit [[AVR-Studio]] und [[AVRDUDE]] genutzt werden kann.

==== AVRISP mkII Klon mit dem Teensy-Board und der Lufa-Bibliothek ====
Mit der [http://www.fourwalledcubicle.com/LUFA.php LUFA-Bibliothek] und dem [http://www.pjrc.com/teensy TEENSY 2.0 Board] kann schnell ein AVRISP mk2 Klon gebaut werden, der auch mit [[AVR-Studio]] in Windows einwandfrei zusammenarbeitet. Weitere Infos auf [http://www.weigu.lu/b/avrispmk2 weigu.lu].

==== AVRISP mkII Klon mit dem Atmega32U2-Breakout-Board und der Lufa-Bibliothek ====
Mit der [http://www.fourwalledcubicle.com/LUFA.php LUFA-Bibliothek] ([http://dokuwiki.ehajo.de/artikel:atmega_u-howto:avrisp-mkii Eine Anleitung gibt es hier]) und dem [http://www.ehajo.de/Bausaetze/Atmega32u2-Breakout-Board Atmega32U2-Breakout-Board] kann problemlos ein AVRISP mkII-Klon programmiert werden. Um praktisch auf die Programmierpins zugreifen zu können gibt es [http://www.ehajo.de/Bausaetze/ISP-Addon-Atmega%2AU2-Breakout dieses Addon-Board] für das Breakout-Board. Der Programmer läuft problemlos mit [[AVR-Studio]] unter Windows.

==== Bascom USB ISP ====
Beliebter USB programmer der speziell für den Bascom Compiler entwickelt wurde.
Unterstützt Bascom einen neuen AVR-Controller, so kann dies automatisch auch dieser USB Programmer, eine neue Firmware ist nicht erforderlich. Ein weiterer Vorteil ist, dass er speziell für Bascom entwickelt wurde und in der IDE unterstützt wird. Er unterstützt alle Features von Bascom, auch die automatische Fusebit-Einstellung per Direktive im Quellcode.

Angenehm ist auch, dass er keine 5V benötigt. Im Gegenteil, er kann sogar Boards über das übliche ISP-Programmierkabel mit 5V versorgen, so dass viele Boards auch ohne weitere Spannungsquelle programmiert werden können.
Ein wirklich empfehlenswerter Qualitätsprogrammer für alle Programmierer, die ausschließlich mit Bascom arbeiten wollen
* [http://www.shop.robotikhardware.de/shop/catalog/product_info.php?cPath=73&products_id=161 Vertrieb in Deutschland bei robotikhardware.de]

Im Online- / Auktionshandel werden auch Alternativen angeboten, teils recht schick im Plexiglasgehäuse für ca. 20 Euro. Angeboten z. B. als "USB 2.0 Full Speed low cost Programmer für ATMEGA Chips" oder "AVR USB ISP Programmer ATMEL ATMEGA STK500". Die Adapter funktionieren auch mit BasCom (aber auch mit AVR Studio), z. B. mit der Einstellung "STK500 native driver".

Man kann die Targetspannungsversorgung per USB zwischen 3,3 und 5V umschalten oder ganz abschalten (per DIP-Schalter). Sie sind per USB an den PC angeschlossen und arbeiten über einen virtuellen COM-Port. Achtung: In BasCom funktioniert das nur bis COM9. Wenn sich das Gerät z. B. auf COM15 installiert, wird es im BasCom evtl. nicht gefunden. Dann in der Systemsteuerung entsprechend umstellen.

==== Atmel AVR Dragon ====

''Hauptartikel [[AVR-Dragon]]''

Der [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] ist ein preiswerter ISP (und ICE) von Atmel, der aufgrund Preis/Leistungs-Verhältnisses schnell populär wurde. Atmel wurde von dieser Popularität überrascht, da der Dragon wohl ursprünglich nur als ein "Gimmick" zur Verbreitung von AVRs in Asien gedacht war.

Die großen Vorteile des Dragons sind, dass er alle Programmiermodi beherrscht, inklusive High-Voltage Parallel Programming ("verfuste" AVRs retten), dass er ein natives USB-Interface hat, von AVR-Studio unterstützt wird, und sogar [[JTAG]] und [[debugWIRE]] ICE / Debugging unterstützt (bei den AVRs die dies können).

Zu den größten bekannten Nachteilen gehören, dass der Dragon völlig "nackt" kommt. Kein USB-Kabel, kein Gehäuse, nicht einmal Abstandsbolzen unter der Platine, keine Patchkabel und nicht einmal die Fassungen zum Einstecken von AVRs sind bestückt. Eine gedruckte Anleitung gibt es auch nicht. Daneben wird aufgrund des Stromverbrauchs des Dragon ein USB-Hub mit Netzteil benötigt.

Weiter ist der Dragon dafür bekannt, empfindlich auf statische Aufladungen zu reagieren. Ein Spannungsregler und ein Ausgangstreiber gehen dabei besonders gerne kaputt. Ein gerne von Anfängern gemachter Fehler ist es, den Dragon im Betrieb auf dem mitgelieferten "Schaumstoff" aus der Verpackung liegen zu lassen. Das ist jedoch kein Schaumstoff, sondern leitendes Moosgummi.

Weitere Schutzmaßnahmen für gefährdete AVR Dragons findet man auf der Dragonlair-Seite von [http://www.aplomb.nl/TechStuff/Dragon/Dragon.html Nard Awater].

Der Dragon wird unter Linux z. B. von der avrdude-Programmiersoftware unterstützt. Unerklärlicherweise stellt Atmel die Dokumentation und Beschreibung des Dragon nur als Teil der Online-Hilfe der AVR-Studio Software unter Windows zur Verfügung. Weiterhin lassen sich Firmware-Updates auch nur mittels eine proprietären Atmel-Software unter Windows einspielen. Daher ist der Dragon für Linux-Benutzer nur dann zu empfehlen, wenn man zusätzlich noch Zugriff auf eine Windows-Installation hat.

==== USBisp ====

AVR Programmierdongle mit USB Anschluss und kompatibel zum STK500-Protokoll. Unter anderem programmierbar mit [[AVR-Studio]], [[AVRDUDE]] und [[uisp]]. Schaltplan (PDF), Layout (PDF), Erläuterungen und Firmware gibt es vom Entwickler [http://www.matwei.de Matthias Weißer].

==== USB avrisp ====

USB AVR Programmer auf Basis des AVR 910 Designs. Den Schaltplan, Layout und Erläuterungen (englisch) gibt es von [http://www.e.kth.se/~joakimar/hardware.html Joakim Arfvidsson].

==== Evertool ====

Mit USB-seriell-Wandler. Getestet mit Adapterkabeln/ICs von FTDI, SiLabs und Prolific (Adapterkabel z. B. für ca. 10EUR bei Reichelt).

* [http://www.siwawi.arubi.uni-kl.de/avr_projects/evertool/ Evertool-"Homepage"]

==== USBasp ====

Thomas Fischls [http://www.fischl.de/usbasp/ USBasp] ist ein
Openhardware-/Openfirmware-USB-ISP-Adapter. Er basiert auf einem
ATmega8, ATmega8L, ATmega88 oder ATtiny85, der mittels einer rein auf Firmware
basierenden USB-Implementierung von
[http://www.obdev.at/products/avrusb/index.html Objective Development]
arbeitet.

Bezugsquellen:
* Ein [http://www.FundF.net/usbasp/ offizieller USBasp Bausatz] ist erhältlich.
* Alternative Bausätze inkl. Dokumentation gibt es bei [http://www.b-redemann.de/produkte-programmer.shtml www.b-redemann.de], [http://shop.ulrichradig.de/Bausaetze/USB-ASP-Bausatz.html shop.ulrichradig.de] und [https://guloshop.de/shop/index.php guloshop.de].
* Eine MacOS X Anpassung stammt von [http://www.macsven.de/usbasp.html Sven Schwiecker]. Man kann aber auch das Komplettpaket Crosspack-AVR, in dem AVRDUDE für Mac OS X bereits enthalten ist, von [http://www.obdev.at/products/crosspack/index-de.html obdev.at] benutzen
* Chinesische Clones von [http://www.ebay.de/sch/i.html?_from=R40&_sacat=0&_nkw=usbasp&rt=nc&LH_BIN=1 Ebay].

Zum Ansteuern des USBasp wird [[AVRDUDE]] in einem speziellen Modus benötigt, der ab Version 5.2 standardmäßig vorhanden ist (vorher waren
Patches nötig).

Zum Programmieren von neuen ATtinys muss der Jumper Slow SCK gesetzt werden.
Alternativ ist es möglich mit der zusätzlichen Option von avrdude "-B100" die Periodendauer von SCK auf etwa 100 µs oder noch länger zu vergrößern (funktioniert nur, wenn die Firmware des USBasp vom Mai 2011 oder neuer ist).

Der originale USBasp hat den Nachteil, dass er nicht die Targetspannung zum Programmieren benutzt, sondern immer seine 5V. Deshalb kann es Probleme geben, wenn das Target mit einer niedrigen Spannung versorgt wird, da der USBasp die Target-Highpegel eventuell nicht mehr als High erkennt. Abhilfe kann ein kleiner Hack schaffen, mit dem der µC wahlweise mit 5V oder mit ~3.6V betrieben wird:
http://www.mikrocontroller.net/topic/109648?goto=2031524#2031524

Der [http://diy.elektroda.eu/usbasp-z-optoizolacja-do-25kv-18v-6v/?lang=en Optoisolated USBASP 1.8V to 6V] ist eine Hardwareänderung ebenfalls mit breitem Targetspannungsbereich und zusätzlich galvanischer Isolation über die [[Optokoppler]] 6N317 (schnelle Datenleitungen) und PC817 (langsame Resetleitung).

Manche USBasp sind umschaltbar zwischen 5 V und 3,3 V. Falls man später darüber eine Schaltung mit 3,3 Volt betreiben will – etwa zum direkten Ansprechen einer SD-Karte – lohnt gezieltes Nachfragen vor dem Kauf.

==== AvrUsb500 ====

* [http://www.tuxgraphics.org/electronics/200510/article05101.shtml AvrUsb500] - an open source Atmel AVR Programmer, stk500 V2 compatible, with USB interface
* [http://www.mechaos.de/avr_progusb.php meCHAOS] - Nachbau mit neuem Platinenlayout und weiteren Funktionen.

==== usbprog ====

[http://www.usbprog.org/ usbprog] von Benedikt Sauter ist ein USB Programmieradapter, der fast alle Atmel-Mikrocontroller unterstützt (ATiny, ATMega, AT89, AT90, ...) und daneben auch für ARM7/9 und MSP universell einsetzbar ist. Unterstützung für Xmega gibt es nicht.

Der Programmer wurde so entwickelt, dass man die Firmware auf dem Adapter über die USB-Verbindung austauschen kann. Dadurch sollte der Adapter lange attraktiv bleiben, da alles rund um das Projekt als open Source veröffentlicht ist und daher neue Controller einfach in die usbprog-Firmware integriert werden können.
Es ensteht gerade eine Firmware für einen einfachen JTAG-Adapter. Damit kann man dann ganz einfach debuggen (voraussichtlich auch aus dem AVR Studio aus).

Man kann den Adapter auch als 1:1 AVRISP-mkII-kompatibles Gerät betreiben. Dafür muss man eine andere Firmware einspielen, die ebenfalls Teil des Projektes ist. Der Vorteil ist der, dass man so auf jede bestehende Programmiersoftware zurückgreifen kann, die das originale AVRISP mkII unterstützt. Getestet wurde usbprog bis jetzt mit avrdude (Linux und Windows) und dem AVR Studio 4 (Windows).

'''Hinweis:''' Damit der Programmer mit AVR Studio 5.x zusammen arbeitet, muss die Firmware aktualisiert werden: http://www.usbprog.org/index.php/Firmwares (siehe Update-Hinweis)

Derzeit kann man bei der embedded projects GmbH die Versionen 3.3 und 4.0 bestellen. Näheres im [http://www.usbprog.org/index.php/Hardware Projekt-Wiki].

==== AVR-Doper ====

[http://www.obdev.at/products/avrusb/avrdoper.html AVR-Doper] kann neben ISP auch im High-Voltage Serial Mode als [[AVR HV-Programmer]] programmieren. Rein auf Firmware basierende USB-Implementierung. BUS-Powered. Einseitige Platine und damit auch für Selbstbauer geeignet. Verwendet einen Mega8 zur Steuerung des Programmers. Ist kompatibel zu AVR-Studio durch STK500-Protokoll.

==== USB AVR-Lab ====

[http://www.ullihome.de/index.php/Hauptseite#USB_AVR-Lab USB AVR-Lab] besteht aus einer sehr einfachen Hardware, usb wird in Software gemacht. Mit einem Bootloader nebst Applikation kann die Funktion des Lab´s zwischen

*AVRISPmkII kompatiblem Programmer (AVR Studio, Linux, MacOS)
*JTAGICEmkII kompatibler AVR Programmer (AVR Studio, Linux, MacOS) (keine AVR32, kein Xmega)
*OpenOCD Interface (sehr viel ARM Controller, PLD´s, FPGA´s)
*STK500v2 kompatiblem Programmer (AVR Studio)
*USBasp kompatiblem Programmer (Linux, MacOS)
*JTAG Boundary Scan Interface + Software
*RS232/RS485 Wandler
*I2C Logger
*I2C Interface (zur benutzung aus eigenen Programmen)
*Oszi
*6-Kanal Logik Analyzer (in Entwicklung)
*Labornetzteil (in Entwicklung)

getauscht werden. Mit der STK500v2 kompatiblen Firmware kann der Programmer direkt aus dem AVR Studio heraus voll kompatibel zum AVR-ISP mkII arbeiten.
Zusätzlich bietet der Programmer den virtuellen Com Port als Debug Port an solange nicht geflasht wird. Man kann also direkt mit dem Terminalprogramm auf seinen AVR zugreifen über den ISP Adapter.
Dieser Modus wird von jeder ISP Firmware unterstützt.
Statusanzeige des Targets (angeschlossen, falsch angeschlossen, nicht angeschlossen), max. 3 Mhz ISP Freq. Das Ganze ist sehr günstig in der Beschaffung (10 Eur Bauteile bei Reichelt + 3,5 Eur Platine von ullihome.de, oder 15 Eur bestückt von ullihome.de)

==== USBtinyISP ====

[http://www.ladyada.net/make/usbtinyisp/ USBtinyISP] ist ein preiswerter (ca. 16$ für die Bauteile) AVR ISP Programmer und SPI Interface auf open-source Basis. Als Software kann z.B. AVRDUDE oder AVRStudio verwendet werden. Der Programmer wurde auf Windows, MacOS X und Ubuntu (ab 9.04) getestet. Bei Adafruit sind auch Selbstbaukits erhältlich.
Eine miniaturisierte Version findet sich hier [http://www.mikrocontroller.net/articles/AVR-ISP-Stick www.mikrocontroller.net/articles/AVR-ISP-Stick]. Diese ist ab 6,90€ als Bausatz bei [http://www.ehajo.de/Bausaetze/AVR-ISP-Stick eHaJo.de] erhältlich.

==== UCOM-IR ====
Der [http://www.nibo-roboter.de/wiki/UCOM-IR UCOM-IR] Programmieradapter ist ein kommerzieller Bausatz (ca. 25 €), der auf einem AT90USB162 basiert. Durch die Verwendung des STK500v2 Protokolls kann zur Programmierung sowohl das [[AVR-Studio]] wie auch [[AVRDUDE]] verwendet werden. Zusätzlich hat der Adapter einen IR-Empfänger und zwei Sendedioden, die zur Kommunikation und zur Fernsteuerung verwendet werden können.

==== Selbstbau-Programmer, basierend auf dem vUSB stack ====
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=90498

==== USB-Hub-ISP ====
HUB ISP - Solving the USB-Only "Chicken or Egg" Problem: 
HUB ISP can write an AVR chip using only a USB hub, one cheap/common logic chip, and a few resistors. 
http://www.pjrc.com/hub_isp/

==== Launchprog ====
Der [[Launchprog]] ist ein AVR-ISP-Programmer nach der Atmel AVR910-Appnote, der auf einem [http://processors.wiki.ti.com/index.php?title=MSP430_LaunchPad_%28MSP-EXP430G2%29 TI Launchpad 1.4] mit dem beiliegenden [http://www.ti.com/product/msp430g2211 MSP430G2211] und dem beiliegenden Uhrenquarz läuft. Nach außen hin ist der [[Launchprog]] wie ein AVR910 zu verwenden. Allerdings muss die Geschwindigkeit der seriellen Schnittstelle auf 9600 Baud eingestelllt werden. 
Beispiel der avrdude-Kommandozeile: 
''avrdude -c avr910 -b 9600 -P <PORT> -p <PART> -U <KOMMANDO>''

==== mySmartUSB ====
Der mySmartUSB Programmer von myAVR ist ein kompakter ISP Programmer mit USB Anschluss (der Preis liegt bei 28€). Lt. Hersteller kann er auch für die Kommunikation via UART, TWI, SPI verwendet werden (hab ich noch nicht probiert).

ich aber: Beim Schreiben der Fuse Bits musste ich das Tool myAVR_ProgTool.exe verwenden

Mit avrdude ist das Schreiben der Fuse-Bits mit dem AVR910-Modus möglich.

avrdude-Kommandozeile :
''avrdude -c avr910 -P PORT -p PART -U lfuse:w:0xFF:m -U hfuse:w:0xD9:m''

'''Achtung:''' Die neuere Version (mySmartUSB MK3) scheint mit der aktuellen Firmwareversion noch große Probleme mit ISP zu haben (siehe Postings im Supportforum: http://myavr.info/myForum/viewforum.php?f=8). Solange diese Probleme nicht ausgemerzt sind, sollte man auf die ältere Version (mySmartUSB MK2) oder ein anderes Produkt ausweichen.

==== mySmartUSB light ====

Preiswerter (ca. 15 €) Programmer im USB-Stick Design von myAVR. Der mySmartUSB light verfügt über eine Auto-Speed Funktion die die Frequenz des Programmers automatisch an die Taktfrequenz des Controllers anpasst.
Der Programmer kann 5V und 3.3V Systeme programmieren, Treiber gibt es für Windows, Linux und MacOS X und unterstützt wird je nach Firmware-Version das STK500v2 oder AVR910/911 Protokoll.

==== Amadeus-USB ====

[http://home.arcor.de/bernhard.michelis Amadeus-USB] ist ein ISP-Programmer zum Selberbauen. Er unterstützt eine Vielzahl von AVRs und verfügt über ein eigenes User-Interface. Der Programmer enthält einen einfach zu bedienenden Fuse-Editor. Sollte man einmal die falschen Clock-Einstellungen vorgenommen haben, ist das kein Problem, da der Programmer über eine Takterzeugung verfügt, mit der man den AVR wiederbeleben kann.
Auch wer mit niedrigen Taktraten arbeitet (z. B. 32kHz), kann einen ATmega64 in ca. 4,8 Sekunden programmieren und vergleichen. Darüber hinaus kann mit geeigneten Makros die Programmausführung getracet werden. Die maximale Programmierdauer beträgt bei einem ATmega64 mit 16MHz Quarz 3,1 Sekunden, wenn der gesamte Speicher geschrieben und verglichen werden muss. Ist das Programm kleiner, geht es natürlich schneller ;-) Für einen ATTiny2313 oder ATTiny24 braucht er weniger als eine Sekunde.

==== AVR-ISP-Stick ====

Der [http://www.ehajo.de/Bausaetze/AVR-ISP-Stick AVR-ISP-Stick] ist ein OpenSource/CC-Projekt und eine sehr günstige (6,90€!) Alternative zu den restlichen Programmieradaptern auf dem Markt. Er ist als Bausatz erhältlich und bereits über 100 mal im produktiven Einsatz.

==== µISP-Stick ====

Der [http://www.ehajo.de/Bausaetze/µISP-Stick µISP-Stick] ist die Weiterentwicklung des AVR-ISP-Sticks. Für 9,90€ bekommt man hier einen vorbestückten Bausatz an dem nur noch die bedrahteten Stecker angelötet werden müssen.

==== Arduino ISP Shield ====

Ein Arduino-Board kann mit dem entsprechenden Sketch und einfachen Jumperwires oder einem komfortablen Shield benutzt werden, um AVRs ohne [[Bootloader]] zu flashen. Eine Anleitung dazu wird bei [http://www.open-electronics.org/arduino-isp-in-system-programming-and-stand-alone-circuits/ www.open-electronics.org] und [http://hlt.media.mit.edu/?p=1229 hlt.media.mit.edu] (via [http://www.mikrocontroller.net/topic/252620#2598960]) gegeben.

==== aTeVaL-Board ====

Das [http://www.ehajo.de/Bausaetze/aTeVaL aTeVaL-Board] ist die Weiterentwicklung des Atmel Evalboards von Pollin. Damit lassen sich problemlos alle bedrahteten AVR-Controller programmieren. Der Programmer ist ein AVR-ISP-mkii-Clon und somit 100% kompatibel mit dem Atmelstudio. Für eigene Platinen ist ein 6- und 10-poliger ISP-Stecker vorhanden.

==== USP-Stick ====

Der [http://www.ehajo.de/Bausaetze/USP-Stick USP-Stick] ist ein sehr kleiner Programmieradapter, der in ein USB-A-Gehäuse passt. Er beruht auf der bewährten Hardware des AVR-ISP-Sticks (attiny2313 + quarz) und ist für 4,90€ erhältlich.

==== guloprog USB-Programmer und Signalwandler ====

Unter dem Namen [https://guloshop.de/shop/Mikrocontroller-Programmierung/guloprog-der-Programmer-von-guloshop-de::70.html guloprog] wird eine kleine Platine angeboten, die einen USB-Programmer und einen [https://guloshop.de/shop/USB-TTL-ADC-PWM-Signalwandler:::10.html Signalwandler] vereint. Der Programmer wird per USB angeschlossen und meldet sich als Fischl-kompatibler usbasp.

Die Signalwandlerfunktion bietet voneinander unabhängige einfache Schalt- und Abfragemöglichkeiten für die vier sonst zum Programmieren verwendeten Anschlüsse. Jede Leitung kann per Tastatur-Kommando einen Ausgang auf 0 Volt oder auf 5 Volt setzen oder "dimmen" (PWM in Schritten von 0 bis 100%). Alle Anschlüsse können als Digital-Eingang verwendet werden, drei davon wahlweise als Analog-Eingang. Die gemessenen Werte lassen sich ebenfalls per Kommandozeile abfragen und auf diese Weise leicht in andere PC-Programme einbinden (Linux, Mac, Windows).

Herzstück ist ein ATtiny85, der im Gegensatz zu allen ATmegas und fast allen ATtinys auch über den internen RC-Oszillator mit 16 MHz betrieben werden kann. Ein Quarz ist daher nicht erforderlich. Die für V-USB erforderliche Genauigkeit erreicht der Programmer über einen Synchronisationsschritt, der bei jedem Start automatischen durchlaufen wird. Die Firmware steht unter einer freien Lizenz, es werden nur sehr wenige Bauteile benötigt, so dass sich dieser Programmer auch recht gut für den Nachbau eignet. Schaltungs- und softwaretechnisch besteht praktisch Baugleichheit zum [[Bierdeckel-Programmer]].

=== Standalone ===

Die folgenden Geräte verfügen über interne Speicher, auf denen der zu programmierende Maschinencode abgelegt werden kann. Zum "flashen" selbst ist keine Verbindung zwischen Arbeitsplatzrechner bzw. Notebook und Programmiergerät erforderlich.

==== roloFlash (kommerziell) ====
[http://www.halec.de/roloFlash/?ref=wiki_isp.mikrocontroller.net roloFlash] wird mit einer microSD-Karte bestückt, die die zu flashenden Daten enthält. Dadurch können unabhängig von einem PC an jedem beliebigen Ort AVR-Controller geflasht werden.

In einem ersten Schritt wird die microSD-Karte vorbereitet. Durch die auf dem roloFlash eingebaute Scriptsprache roloBasic lässt sich der gewünschte Ablauf sehr flexibel festlegen.

Nun kann roloFlash irgendwo anders ohne PC AVR-Controller flashen. Dabei geben 5 zweifarbigen LEDs Auskunft über den Fortschritt bzw. das Ergebnis des Flash-Prozesses. Fehlbedienungen sind unmöglich, da es keine Bedienelemente gibt.

Einsatzgebiete:
* Produktion
* Fehlbedienungssichere Updates beim Kunden

==== TheCableAVR-SD (kommerziell) ====
[http://www.priio.com/productcart/pc/viewPrd.asp?idcategory=6&idproduct=88 TheCableAVR-SD] works by saving the "ISP", "HEX" and "EEP" files required for part programming from the PC application onto an SD-Card and inserting it into TheCableAVR-SD. This programmer is stand alone, making it very handy for field software updates and production programming.

Wird 4/2012 scheinbar nicht mehr verkauft ([http://www.mikrocontroller.net/topic/257278#2657606 Forumsbeitrag Priio AVR Programmer?]).

==== ButtLoad ====
[http://www.fourwalledcubicle.com/ButtLoad.php ButtLoad] is based on the Atmel [[AVR Butterfly]] development board. ButtLoad is specially written firmware which converts a low-cost official Atmel Butterfly evaluation board into a smart ISP programmer for other members of the Atmel AVR family. It supports the entire AVR range, and allows for a complete program (including EEP, HEX, Fuse and Lock Bytes) to be stored and later programmed into a device from the Butterfly's on board non-volatile memory.

[http://www.fourwalledcubicle.com/ButtLoad.php ButtLoad] basiert auf dem Atmel-[[AVR Butterfly]]-development board und ist eine spezielle Firmware, die ein (billiges) Atmel-Butterfly-Board in einen vollwertigen ISP-Programmierer für andere Controller der Atmel-AVR-Familie verwandelt. Es unterstützt den gesamten AVR-Bereich und erlaubt, ein Programm komplett mit EEP, HEX, Sicherungs- und Lock-Bytes im nichtflüchtigen on-board-Speicher des Butterflys abzulegen und dann von dort heraus die Controller zu programmieren.

==== PalmAVR ====
* siehe [http://www.mikrocontroller.net/topic/77870#648376 Forenbeitrag]

==== ISPnub (Open Source) ====
[http://www.fischl.de/ispnub/ ISPnub - Stand-alone AVR In-System-Programmer Module] besteht aus einem AVR in dessen Flash ein Programmierskript geladen wird. Der eigentliche Programmiervorgang wird über einen Tastendruck ausgelöst. Die Zahl der Programmierzyklen kann beschränkt werden (z.B. auf ein Fertigungslos beschränkt).

==== AVR-ISP500, AVR-ISP500 tiny ====
von Olimex, siehe
* [http://www.olimex.com/dev/avr-isp500-iso.html Herstellerseite zum ISP500]
* [http://www.olimex.com/dev/avr-isp500-tiny.html Herstellerseite zum ISP500-TINY]

=== Geschwindigkeitsvergleich ===

Im Rahmen einer Forendiskussion entstand die folgende Messung, die
einige der möglichen Programmer in ihrer Geschwindigkeit vergleicht.
Mit einbezogen in den Vergleich wurde neben originalen
Atmel-ISP-Werkzeugen noch Werkzeuge für [[JTAG#AVR_JTAG|JTAG]].

Die Testdatei war 29704 Bytes groß. Target ist ein ATmega6490, der
mit 8 MHz vom RC-Oszillator getaktet wird. Das alles wurde mit einem
AVRDUDE 5.5 getestet.

<pre>
Programmer Parameter Zeit fürs
Schreiben Lesen
-----------------------------------------------
JTAG ICE mkII default 2,58 s 3,27 s
JTAG (4 MHz)
-----------------------------------------------
JTAG ICE mkII 1 MHz 8,34 s 8,51 s (**)
ISP
-----------------------------------------------
AVRISP mkII 250 kHz 5,37 s 5,46 s
1 MHz 2,45 s 2,45 s
2 MHz 1,89 s 1,99 s
-----------------------------------------------
STK500 900 kHz 5,84 s 3,49 s
(schnellstes)
-----------------------------------------------
AVR Dragon default 2,81 s 3,49 s
JTAG (4 MHz)
-----------------------------------------------
AVR Dragon 1 MHz 8,34 s 8,64 s
ISP 2 MHz - - (*)
-----------------------------------------------
Parallelport- keine Delay 13,20 s 12,45 s (**)
Dongle "alf" CPU 900 MHz
-----------------------------------------------
</pre>

(*) Benutzung unmöglich, weder Fuses noch Signature zuverlässig
lesbar.

(**) Fuses und Signature OK, aber das programmierte Ergebnis ist
fehlerhaft (verify errors)

== Software ==

* [http://www.myplace.nu/avr/yaap/ yaap] (Windows, diverse Parallelport-Programmer, GUI)
* [[Pony-Prog Tutorial|PonyProg]] (Linux, Windows, diverse Programmer für den parallelen und seriellen Port, GUI, am seriellen Port nur "Statuspinwackler" nach dem Schaltplan auf der lancos-Seite)
* [http://www.soft-land.de/index.php?page=avrburner AVRBurner] Ponyprog ähnliche Oberfläche für AVRDUDE.
* [http://www.nongnu.org/avrdude AVRDUDE] (Unix, Linux, Windows, praktisch alle Programmer, leicht erweiterbar auf andere Parallelportadapter-Anschlussbelegungen, Kommandozeile, auch für AVR Butterfly über dessen vorinstallierten Bootloader/Firmware-Uploader) siehe im Wiki [[AVRDUDE]]
* [http://savannah.nongnu.org/projects/uisp uisp] (Unix, Linux, Windows, praktisch alle Programmer, Kommandozeile, nicht mehr gepflegt).
* AVR-Studio (nur Programmieradapter mit integriertem Controller für den seriellen Port, z. B. AVR910, ATMEL AVRISP und STK500)
* [http://www.mcselec.com Eingebauter Programmer im Bascom-Basic Compiler]
* [http://esnips.com/web/AtmelAVR AvrOspII] - GUI Open Source programmer based on Atmels Application note AVR911.
* [http://www.mikrocontroller.net/topic/60817 Forumsbeitrag] - Wie man Ponyprog aus dem AVR-Studio heraus nutzt
* [http://www.cadmaniac.org/projectMain.php?projectName=kontrollerlab Kontrollerlab] - (Linux), Grafische Oberfläche zu avr-gcc, uisp, avrdude und kate mit built-in debugger und serial terminal. Einfach verständlich und aufgeräumt (im KDE-Stil)
* [http://shop.myavr.de/index.php?sp=download.sp.php&suchwort=dl112 myAVRProgTool] - Freies Programmiertool und zusätzlich auch als DUDE-GUI geeignet, einfach zu bedienen
* [http://dybkowski.net/isp ISP Programmer] von Adam Dybkowski (Opensource, Windows 95, 98, Me, NT 4.0, 2000, XP, 2003, Vista and Windows 7 (32-bit and 64-bit versions))
* [http://andreas-weschenfelder.de.vu/Homepage/Version_3/index.php?section=PC_Delphi_FT2232_AtmelISP.html FT2232 ISP Flasher] von Andreas Weschenfelder (Windows 95, 98, Me, NT 4.0, 2000, XP, 2003, Vista and Windows 7 (32-bit and 64-bit versions)), verwendet das MPSSE Protokoll der FTDI Chips zur ISP Programmierung
* [http://andreas-weschenfelder.de.vu/Homepage/Version_3/index.php?section=Android_FTDI_AVR_Programmer.html Atmel ISP Flasher for Android] von Andreas Weschenfelder (Android 4.1.1), verwendet das MPSSE Protokoll der FTDI Chips zur ISP Programmierung, KEINE root-Rechte erforderlich

== ISP-Pins am AVR auch für andere Zwecke nutzen ==

Bei einem Programmer mit eingebautem [[Ausgangsstufen_Logik-ICs#Tristate|Tristate]]-Treiber (z. B. 74HC(T)244) werden die Leitungen MISO, MOSI und SCK hochohmig geschaltet wenn die Programmierung beendet ist, d.h. sie beeinflussen die Schaltung nicht. Man kann die betreffenden Pins am AVR also relativ problemlos als Ausgänge verwenden, wenn man darauf achtet, dass die daran angeschlossene Peripherie durch die Programmierimpulse keinen Schaden nehmen kann. Als Eingänge sollte man die Pins allerdings nicht verwenden, da ein angeschlossener Taster zum Beispiel die Programmierimpulse kurzschließen würde, wenn er gedrückt ist.

Atmel empfiehlt in der Application Note [http://www.atmel.com/images/atmel-2521-avr-hardware-design-considerations_applicationnote_avr042.pdf AVR042: AVR Hardware Design Considerations (PDF)] Peripherie an der SPI-Schnittstelle, bei gleichzeitiger Verwendung der Schnittstelle als In-System-Programmieranschluss, über Widerstände anzuschliessen.

Ein Widerstand in SCK ist in diesem Zusammenhang aber nur dann sinnvoll, wenn am AVR ein externer SPI-Master hängt, denn nur dann kann ein Konflikt zwischen diesem SCK treibenden Master und dem ebenfalls SCK treibenden ISP auftreten. Ist der AVR hingegen wie üblich selbst der Master, dann ist ein Konflikt ausgeschlossen. Das gleiche gilt für MOSI.

Bei MISO kann ein Konflikt nur auftreten, wenn diese Leitung vom Slave in der ISP-Phase aktiv treibend sein kann. Das ist beispielsweise bei Porterweiterungen (Inputs) mit Schieberegistern der Fall, wenn der
Datenausgang des Schieberegisters nicht passivierbar ist (tristate, Z-state). Dann ist ein Serienwiderstand in MISO sinnvoll.

Normale SPI-Slaves mit CS-Leitung, wie ADCs, passivieren jedoch ihren Datenausgang wenn CS inaktiv ist. In diesem Fall ist ein Serienwiderstand in MISO unnötig, es muss nur über schwache Pullup-Widerstände an allen relevanten CS Leitungen sichergestellt sein, dass sie während Reset hochgezogen werden. Manche SPI-Slaves haben die bereits an Bord. Die internen Pullups im AVR sind keine Hilfe, da sie während Reset abgeschaltet sind.

siehe auch [http://www.mikrocontroller.net/articles/AVR_HV-Programmer AVR HV-Programmer]

[[Kategorie:AVR-Programmer und -Bootloader| ]]

AVR-GCC-Tutorial/LCD-Ansteuerung

2015-01-03T10:36:54Z

Maybee:

==Das LCD und sein Controller==

Die meisten Text-LCDs verwenden den Controller [[HD44780]] oder einen kompatiblen (z. B. KS0070) und haben 14 oder 16 Pins. Hier ist die häufigste Anschluss-Belegung angegeben.

;Achtung: Es gibt Displays mit abweichender Anschluss-Belegung, z.B. TC1602E (Pollin 120420). Falscher Anschluss kann zur Zerstörung führen! Daher immer das zugehörige Datenblatt zu Rate ziehen. Einzelheiten unter Artikel zum Controller [[HD44780]].

{| class="wikitable"
! Pin # || Bezeichnung || Funktion
|-
! 1
| Vss || GND (beim TC1602E Vdd=Vcc)
|-
! 2
| Vdd/Vcc || 5V (beim TC1602E Vss=Gnd)
|-
! 3
| Vee || Kontrastspannung (0V bis 5V)
|-
! 4
| RS || Register Select (Befehle/Daten)
|-
! 5
| RW || Read/Write
|-
! 6
| E
| Enable
|-
! 7
| DB0 ||rowspan="8"| Datenbits 0−7
|-
! 8
| DB1
|-
! 9
| DB2
|-
! 10
| DB3
|-
! 11
| DB4
|-
! 12
| DB5
|-
! 13
| DB6
|-
! 14
| DB7
|-
! 15
| A || LED-Beleuchtung, Anode
|-
! 16
| K || LED-Beleuchtung, Kathode
|}

{{Warnung|
;Achtung: Unbedingt von der richtigen Seite zu zählen anfangen! Meistens ist neben Pin 1 eine kleine 1 auf der LCD-Platine. Ansonsten im Datenblatt nachschauen! Oft ist Pin 1 auch durch ein rechteckiges statt rundes Pad gekennzeichnet.

:Bei LCDs mit 16-poligem Anschluss sind die beiden letzten Pins für die Hintergrundbeleuchtung reserviert. Hier unbedingt das Datenblatt zu Rate ziehen, die beiden Anschlüsse sind je nach Hersteller oft anders beschaltet. Falls kein Datenblatt vorliegt, kann man mit einem Durchgangsprüfer feststellen, welcher Anschluss mit Masse (GND) verbunden ist.
}}

Vss wird ganz einfach an GND angeschlossen und Vcc an 5V. Vee kann man testweise auch an GND legen. Wenn das LCD dann zu dunkel sein sollte muss man ein 10k-Potentiometer zwischen GND und 5V schalten, mit dem Schleifer an Vee:

[[Bild:LCD_Vee.gif]]

Es gibt zwei verschiedene Möglichkeiten zur Ansteuerung eines solchen Displays: den '''8-bit-''' und den '''4-bit-'''Modus.
* Für den '''8-bit-Modus''' werden (wie der Name schon sagt) alle acht Datenleitungen zur Ansteuerung verwendet, somit kann durch einen Zugriff immer ein ganzes Byte übertragen werden.
* Der '''4-bit-Modus''' verwendet nur die oberen vier Datenleitungen ('''DB4-DB7'''). Um ein Byte zu übertragen braucht man somit zwei Zugriffe, wobei zuerst das höherwertige '''"Nibble"''' (= 4 Bits), also Bit 4 bis Bit 7 übertragen wird und dann das niederwertige, also Bit 0 bis Bit 3. Die unteren Datenleitungen des LCDs, die beim Lesezyklus Ausgänge sind, lässt man offen (siehe Datasheets, z. B. vom KS0070).

Der 4-bit-Modus hat den Vorteil, dass man 4 IO-Pins weniger benötigt als beim 8-bit-Modus, weshalb ich mich hier für eine Ansteuerung mit 4bit entschieden habe.

Neben den vier Datenleitungen (DB4, DB5, DB6 und DB7) werden noch die Anschlüsse '''RS''', '''RW''' und '''E''' (ist in manchen Unterlagen auch '''EN''' für ''Enable'' abgekürzt) benötigt.

* Über '''RS''' wird ausgewählt, ob man einen Befehl oder ein Datenbyte an das LCD schicken möchte. Ist RS Low, dann wird das ankommende Byte als Befehl interpretiert, ist RS high, dann wird das Byte auf dem LCD angezeigt.
* '''RW''' legt fest, ob geschrieben oder gelesen werden soll. High bedeutet lesen, low bedeutet schreiben. Wenn man RW auf lesen einstellt und RS auf Befehl, dann kann man das '''Busy-Flag''' an DB7 lesen, das anzeigt, ob das LCD den vorhergehenden Befehl fertig verarbeitetet hat (diese Methode u.a. in der LCD-Library von Peter Fleury verwendet). Ist RS auf Daten eingestellt, dann kann man z. B. den Inhalt des Displays lesen - was jedoch nur in den wenigsten Fällen Sinn macht. Deshalb kann man RW dauerhaft auf low lassen (= an GND anschließen), so dass man noch ein IO-Pin am Controller einspart. Der Nachteil ist, dass man dann das Busy-Flag nicht lesen kann, weswegen man nach jedem Befehl vorsichtshalber ein paar Mikrosekunden warten sollte, um dem LCD Zeit zum Ausführen des Befehls zu geben. Dummerweise schwankt die Ausführungszeit von Display zu Display und ist auch von der Betriebsspannung abhängig. Für professionellere Sachen also lieber den IO-Pin opfern und Busy abfragen.
* Der '''E''' Anschluss schließlich signalisiert dem LCD, dass die übrigen Datenleitungen jetzt korrekte Pegel angenommen haben und es die gewünschten Daten von den Datenleitungen bzw. Kommandos von den Datenleitungen übernehmen kann.

== Anschluss an den Controller ==

Jetzt da wir wissen, welche Anschlüsse das LCDs benötigt, können wir das LCD mit dem Mikrocontroller verbinden:

ACHTUNG: Es gibt Displays mit abweichender Anschluss-Belegung, falscher Anschluss kann zur Zerstörung führen! Daher immer das zugehörige Datenblatt zu Rate ziehen.

Einzelheiten unter [http://www.mikrocontroller.net/articles/HD44780 Artikel zum Controller HD44780]

{| class="wikitable"
!Pin #-LCD || Bezeichnung-LCD || Pin-µC
|-
!1
| Vss || GND
|-
!2
| Vcc || 5V
|-
!3
| Vee || GND oder Poti (siehe oben)
|-
!4
| RS || PD4 am AVR
|-
!5
| RW || GND
|-
!6
| E || PD5 am AVR
|-
!7
| DB0 ||rowspan="4"| offen (unbenutzt)
|-
!8
| DB1
|-
!9
| DB2
|-
!10
| DB3
|-
!11
| DB4 || PD0 am AVR
|-
!12
| DB5 || PD1 am AVR
|-
!13
| DB6 || PD2 am AVR
|-
!14
| DB7 || PD3 am AVR
|}

Wenn man die Steuerleitungen EN und RS auf Pins an einem anderen Port legen möchte, kann man so wie in diesem [http://www.mikrocontroller.net/topic/88543#751982 Forumsbeitrag] oder wie im Artikel [[Erweiterte LCD-Ansteuerung]] vorgehen.

Ok, alles ist verbunden, wenn man jetzt den Strom einschaltet sollten ein oder zwei schwarze Balken auf dem Display angezeigt werden. Erscheint trotz korrektem Anschluss nichts auf dem Display, so kann das auch am Kontrast des LCDs liegen. Die Balken werden dann zwar theoretisch angezeigt, sind aber nicht sichtbar, weil die Kontrastspannung zu hoch ist. Abhilfe schafft es hier, wenn man die Spannung am Schleifer des Potis nachmisst und in Richtung 0V verstellt. Zwischen 1V und 0V treten die Balken dann meist hervor.
Doch wie bekommt man jetzt die Befehle und Daten in das Display?

== Programmierung ==

=== Die LCD Routinen ===

Der folgende Satz von Ansteuerroutinen für ein Text-LCD ist in der Datei '''lcd-routines.c''' zusammengefasst. Diese Datei muss man beim Einrichten zusätzlich zum eigenen Hauptprogramm in sein Projekt aufnehmen. Dies geschieht beim AVR Studio unter Source Files im Fenster AVR GCC oder bei WinAVR im Makefile (z. B. durch SRC += lcd-routines.c).

Wichtig ist außerdem, dass die Optimierung bei der Compilierung eingeschaltet ist, sonst stimmen die Zeiten der Funktionen _delay_us() und _delay_ms() nicht und der Code wird wesentlich länger (Siehe Dokumentation der libc im WinAVR).

Als weitere Datei ist die Includedatei '''lcd-routines.h''' notwendig, die im Hauptprogramm und in '''lcd-routines.c''' eingebunden wird. Die Anpassung der Pinbelegung etc. macht man in dieser Datei.

==== Datei '''lcd-routines.h''' ====
<syntaxhighlight lang="c">
// Ansteuerung eines HD44780 kompatiblen LCD im 4-Bit-Interfacemodus
// http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung
//

#ifndef LCD_ROUTINES_H
#define LCD_ROUTINES_H

////////////////////////////////////////////////////////////////////////////////
// Hier die verwendete Taktfrequenz in Hz eintragen, wichtig!

#ifndef F_CPU
#define F_CPU 8000000
#endif

////////////////////////////////////////////////////////////////////////////////
// Pinbelegung für das LCD, an verwendete Pins anpassen
// Alle LCD Pins müssen an einem Port angeschlossen sein und die 4
// Datenleitungen müssen auf aufeinanderfolgenden Pins liegen

// LCD DB4-DB7 <--> PORTD Bit PD0-PD3
#define LCD_PORT PORTD
#define LCD_DDR DDRD
#define LCD_DB PD0

// LCD RS <--> PORTD Bit PD4 (RS: 1=Data, 0=Command)
#define LCD_RS PD4

// LCD EN <--> PORTD Bit PD5 (EN: 1-Impuls für Daten)
#define LCD_EN PD5

////////////////////////////////////////////////////////////////////////////////
// LCD Ausführungszeiten (MS=Millisekunden, US=Mikrosekunden)

#define LCD_BOOTUP_MS 15
#define LCD_ENABLE_US 20
#define LCD_WRITEDATA_US 46
#define LCD_COMMAND_US 42

#define LCD_SOFT_RESET_MS1 5
#define LCD_SOFT_RESET_MS2 1
#define LCD_SOFT_RESET_MS3 1
#define LCD_SET_4BITMODE_MS 5

#define LCD_CLEAR_DISPLAY_MS 2
#define LCD_CURSOR_HOME_MS 2

////////////////////////////////////////////////////////////////////////////////
// Zeilendefinitionen des verwendeten LCD
// Die Einträge hier sollten für ein LCD mit einer Zeilenlänge von 16 Zeichen passen
// Bei anderen Zeilenlängen müssen diese Einträge angepasst werden

#define LCD_DDADR_LINE1 0x00
#define LCD_DDADR_LINE2 0x40
#define LCD_DDADR_LINE3 0x10
#define LCD_DDADR_LINE4 0x50

////////////////////////////////////////////////////////////////////////////////
// Initialisierung: muss ganz am Anfang des Programms aufgerufen werden.
void lcd_init( void );

////////////////////////////////////////////////////////////////////////////////
// LCD löschen
void lcd_clear( void );

////////////////////////////////////////////////////////////////////////////////
// Cursor in die 1. Zeile, 0-te Spalte
void lcd_home( void );

////////////////////////////////////////////////////////////////////////////////
// Cursor an eine beliebige Position
void lcd_setcursor( uint8_t spalte, uint8_t zeile );

////////////////////////////////////////////////////////////////////////////////
// Ausgabe eines einzelnen Zeichens an der aktuellen Cursorposition
void lcd_data( uint8_t data );

////////////////////////////////////////////////////////////////////////////////
// Ausgabe eines Strings an der aktuellen Cursorposition
void lcd_string( const char *data );

////////////////////////////////////////////////////////////////////////////////
// Definition eines benutzerdefinierten Sonderzeichens.
// data muss auf ein Array[8] mit den Zeilencodes des zu definierenden Zeichens
// zeigen
void lcd_generatechar( uint8_t code, const uint8_t *data );

////////////////////////////////////////////////////////////////////////////////
// Ausgabe eines Kommandos an das LCD.
void lcd_command( uint8_t data );

////////////////////////////////////////////////////////////////////////////////
// LCD Befehle und Argumente.
// Zur Verwendung in lcd_command

// Clear Display -------------- 0b00000001
#define LCD_CLEAR_DISPLAY 0x01

// Cursor Home ---------------- 0b0000001x
#define LCD_CURSOR_HOME 0x02

// Set Entry Mode ------------- 0b000001xx
#define LCD_SET_ENTRY 0x04

#define LCD_ENTRY_DECREASE 0x00
#define LCD_ENTRY_INCREASE 0x02
#define LCD_ENTRY_NOSHIFT 0x00
#define LCD_ENTRY_SHIFT 0x01

// Set Display ---------------- 0b00001xxx
#define LCD_SET_DISPLAY 0x08

#define LCD_DISPLAY_OFF 0x00
#define LCD_DISPLAY_ON 0x04
#define LCD_CURSOR_OFF 0x00
#define LCD_CURSOR_ON 0x02
#define LCD_BLINKING_OFF 0x00
#define LCD_BLINKING_ON 0x01

// Set Shift ------------------ 0b0001xxxx
#define LCD_SET_SHIFT 0x10

#define LCD_CURSOR_MOVE 0x00
#define LCD_DISPLAY_SHIFT 0x08
#define LCD_SHIFT_LEFT 0x00
#define LCD_SHIFT_RIGHT 0x04

// Set Function --------------- 0b001xxxxx
#define LCD_SET_FUNCTION 0x20

#define LCD_FUNCTION_4BIT 0x00
#define LCD_FUNCTION_8BIT 0x10
#define LCD_FUNCTION_1LINE 0x00
#define LCD_FUNCTION_2LINE 0x08
#define LCD_FUNCTION_5X7 0x00
#define LCD_FUNCTION_5X10 0x04

#define LCD_SOFT_RESET 0x30

// Set CG RAM Address --------- 0b01xxxxxx (Character Generator RAM)
#define LCD_SET_CGADR 0x40

#define LCD_GC_CHAR0 0
#define LCD_GC_CHAR1 1
#define LCD_GC_CHAR2 2
#define LCD_GC_CHAR3 3
#define LCD_GC_CHAR4 4
#define LCD_GC_CHAR5 5
#define LCD_GC_CHAR6 6
#define LCD_GC_CHAR7 7

// Set DD RAM Address --------- 0b1xxxxxxx (Display Data RAM)
#define LCD_SET_DDADR 0x80

#endif
</syntaxhighlight>

==== Datei '''lcd-routines.c''': ====
<syntaxhighlight lang="c">
// Ansteuerung eines HD44780 kompatiblen LCD im 4-Bit-Interfacemodus
// http://www.mikrocontroller.net/articles/HD44780
// http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung
//
// Die Pinbelegung ist über defines in lcd-routines.h einstellbar

#include <avr/io.h>
#include "lcd-routines.h"
#include <util/delay.h>

////////////////////////////////////////////////////////////////////////////////
// Erzeugt einen Enable-Puls
static void lcd_enable( void )
{
LCD_PORT |= (1<<LCD_EN); // Enable auf 1 setzen
_delay_us( LCD_ENABLE_US ); // kurze Pause
LCD_PORT &= ~(1<<LCD_EN); // Enable auf 0 setzen
}

////////////////////////////////////////////////////////////////////////////////
// Sendet eine 4-bit Ausgabeoperation an das LCD
static void lcd_out( uint8_t data )
{
data &= 0xF0; // obere 4 Bit maskieren

LCD_PORT &= ~(0xF0>>(4-LCD_DB)); // Maske löschen
LCD_PORT |= (data>>(4-LCD_DB)); // Bits setzen
lcd_enable();
}

////////////////////////////////////////////////////////////////////////////////
// Initialisierung: muss ganz am Anfang des Programms aufgerufen werden.
void lcd_init( void )
{
// verwendete Pins auf Ausgang schalten
uint8_t pins = (0x0F << LCD_DB) | // 4 Datenleitungen
(1<<LCD_RS) | // R/S Leitung
(1<<LCD_EN); // Enable Leitung
LCD_DDR |= pins;

// initial alle Ausgänge auf Null
LCD_PORT &= ~pins;

// warten auf die Bereitschaft des LCD
_delay_ms( LCD_BOOTUP_MS );

// Soft-Reset muss 3mal hintereinander gesendet werden zur Initialisierung
lcd_out( LCD_SOFT_RESET );
_delay_ms( LCD_SOFT_RESET_MS1 );

lcd_enable();
_delay_ms( LCD_SOFT_RESET_MS2 );

lcd_enable();
_delay_ms( LCD_SOFT_RESET_MS3 );

// 4-bit Modus aktivieren
lcd_out( LCD_SET_FUNCTION |
LCD_FUNCTION_4BIT );
_delay_ms( LCD_SET_4BITMODE_MS );

// 4-bit Modus / 2 Zeilen / 5x7
lcd_command( LCD_SET_FUNCTION |
LCD_FUNCTION_4BIT |
LCD_FUNCTION_2LINE |
LCD_FUNCTION_5X7 );

// Display ein / Cursor aus / Blinken aus
lcd_command( LCD_SET_DISPLAY |
LCD_DISPLAY_ON |
LCD_CURSOR_OFF |
LCD_BLINKING_OFF);

// Cursor inkrement / kein Scrollen
lcd_command( LCD_SET_ENTRY |
LCD_ENTRY_INCREASE |
LCD_ENTRY_NOSHIFT );

lcd_clear();
}

////////////////////////////////////////////////////////////////////////////////
// Sendet ein Datenbyte an das LCD
void lcd_data( uint8_t data )
{
LCD_PORT |= (1<<LCD_RS); // RS auf 1 setzen

lcd_out( data ); // zuerst die oberen,
lcd_out( data<<4 ); // dann die unteren 4 Bit senden

_delay_us( LCD_WRITEDATA_US );
}

////////////////////////////////////////////////////////////////////////////////
// Sendet einen Befehl an das LCD
void lcd_command( uint8_t data )
{
LCD_PORT &= ~(1<<LCD_RS); // RS auf 0 setzen

lcd_out( data ); // zuerst die oberen,
lcd_out( data<<4 ); // dann die unteren 4 Bit senden

_delay_us( LCD_COMMAND_US );
}

////////////////////////////////////////////////////////////////////////////////
// Sendet den Befehl zur Löschung des Displays
void lcd_clear( void )
{
lcd_command( LCD_CLEAR_DISPLAY );
_delay_ms( LCD_CLEAR_DISPLAY_MS );
}

////////////////////////////////////////////////////////////////////////////////
// Sendet den Befehl: Cursor Home
void lcd_home( void )
{
lcd_command( LCD_CURSOR_HOME );
_delay_ms( LCD_CURSOR_HOME_MS );
}

////////////////////////////////////////////////////////////////////////////////
// Setzt den Cursor in Spalte x (0..15) Zeile y (1..4)

void lcd_setcursor( uint8_t x, uint8_t y )
{
uint8_t data;

switch (y)
{
case 1: // 1. Zeile
data = LCD_SET_DDADR + LCD_DDADR_LINE1 + x;
break;

case 2: // 2. Zeile
data = LCD_SET_DDADR + LCD_DDADR_LINE2 + x;
break;

case 3: // 3. Zeile
data = LCD_SET_DDADR + LCD_DDADR_LINE3 + x;
break;

case 4: // 4. Zeile
data = LCD_SET_DDADR + LCD_DDADR_LINE4 + x;
break;

default:
return; // für den Fall einer falschen Zeile
}

lcd_command( data );
}

////////////////////////////////////////////////////////////////////////////////
// Schreibt einen String auf das LCD

void lcd_string( const char *data )
{
while( *data != '\0' )
lcd_data( *data++ );
}

////////////////////////////////////////////////////////////////////////////////
// Schreibt ein Zeichen in den Character Generator RAM

void lcd_generatechar( uint8_t code, const uint8_t *data )
{
// Startposition des Zeichens einstellen
lcd_command( LCD_SET_CGADR | (code<<3) );

// Bitmuster übertragen
for ( uint8_t i=0; i<8; i++ )
{
lcd_data( data[i] );
}
}
</syntaxhighlight>

=== LCD Beispiel 1 ===
Ein Hauptprogramm, welches die LCD Funktionen benutzt, sieht zb. so aus:

<syntaxhighlight lang="c">
//
// Anpassungen im makefile:
// ATMega8 => MCU=atmega8 im makefile einstellen
// lcd-routines.c in SRC = ... Zeile anhängen
//
#include <avr/io.h>
#include "lcd-routines.h"

int main(void)
{
// Initialisierung des LCD
// Nach der Initialisierung müssen auf dem LCD vorhandene schwarze Balken
// verschwunden sein
lcd_init();

// Text in einzelnen Zeichen ausgeben
lcd_data( 'T' );
lcd_data( 'e' );
lcd_data( 's' );
lcd_data( 't' );

// Die Ausgabemarke in die 2te Zeile setzen
lcd_setcursor( 0, 2 );

// erneut Text ausgeben, aber diesmal komfortabler als String
lcd_string("Hello World!");

while(1)
{
}

return 0;
}
</syntaxhighlight>

=== LCD Beispiel 2 ===
Ein Hauptprogramm, welches eine Variable ausgibt, sieht zb. so aus.
Mittels der itoa() Funktion (itoa = Integer To Ascii ) wird von einem Zahlenwert eine textuelle Repräsentierung ermittelt (sprich: ein String erzeugt) und dieser String mit der bereits vorhandenen Funktion lcd_string ausgegeben. Das Einrichten des Projekts ist wie in Beispiel 1.

<syntaxhighlight lang="c">
//
// Anpassungen im makefile:
// ATMega8 => MCU=atmega8 im makefile einstellen
// lcd-routines.c in SRC = ... Zeile anhängen
//
#include <avr/io.h>
#include <stdlib.h>
#include "lcd-routines.h"

// Beispiel
int variable = 42;

int main(void)
{
lcd_init();

// Ausgabe des Zeichens dessen ASCII-Code gleich dem Variablenwert ist
// (Im Beispiel entspricht der ASCII-Code 42 dem Zeichen *)
// http://www.code-knacker.de/ascii.htm
lcd_data( variable );

lcd_setcursor( 0, 2 );

// Ausgabe der Variable als Text in dezimaler Schreibweise
{
// ... umwandeln siehe FAQ Artikel bei http://www.mikrocontroller.net/articles/FAQ
// WinAVR hat eine itoa()-Funktion, das erfordert obiges #include <stdlib.h>
char Buffer[20]; // in diesem {} lokal
itoa( variable, Buffer, 10 );

// ... ausgeben
lcd_string( Buffer );
}

while(1)
{
}

return 0;
}
</syntaxhighlight>

== Siehe auch ==

* [[Erweiterte LCD-Ansteuerung]]
* [[Pseudo-Graphische LCD-Ansteuerung]]
* [http://www.mikrocontroller.net/topic/316826#3431235 Ermittlung der Startadresse der einzelnen Zeilen]
* [http://www.mikrocontroller.net/topic/350554#3899961 LCD-Ansteuerung mit freier Wahl von Pins und Portregistern am Controller]

== Weblinks ==

* [http://homepage.hispeed.ch/peterfleury/avr-software.html#libs Lib zur HD44780 Ansteuerung (AVR)]
* [http://pic-projekte.de/wordpress/?p=908 Lib zur HD44780 Ansteuerung (PIC)]
* [http://www.nongnu.org/avr-libc/user-manual/group__stdiodemo.html Using the standard IO facilities] - Demoprojekt zur Text-LCD Ansteuerung (HD44780 komp.) in der avr-libc

[[Kategorie:Avr-gcc Tutorial]]
[[Kategorie:LCD]]

Remote IRMP

2014-12-20T09:55:10Z

Maybee: Konsistenz

Von '''Frank M. ([http://www.mikrocontroller.net/user/show/ukw ukw])'''

[[Datei:Remote-IRMP-Screenshot1.png|thumb|Frei gestaltbare Tasten zum Senden von IR-Befehlen]]

Dieser Artikel ist eine konkrete Anwendung des [[IRMP]]-Projekts (IRMP-Dekoder = Infrarot-Multiprotokoll-Dekoder). Wir verschaffen unserem Mikrocontroller nicht nur einen IR-Sender und Empfänger, sondern auch noch einen Netzwerkanschluss. Damit wird es möglich, mit einer Android-App eine anlernbare IR-Fernbedienung zu realisieren. Der Anwender kann dann mehrere Geräte, die irgendwo im Haushalt verteilt sind, über das Handy steuern. Dabei sendet die App über WLAN zuvor gespeicherte [[IRMP]]-Codes an den gewünschten µC. Dieser strahlt dann die Signale über den IR-Sender aus, um damit unsere Geräte aus der Unterhaltungsindustrie zu schalten.

Außerdem ist eine Erweiterung von [[IRMP]] um Funksender geplant, damit zukünftig auch Funksteckdosen bequem vom Handy aus geschaltet werden können.

== Merkmale ==

Folgende Funktionalitäten sind bereits umgesetzt:

* Anbindung des µC an einen Wiznet W5100 Ethernet-Controller
* Protokollschnittstelle über TCP/IP und UDP
* Testprogramme der Kommunikation für Unix, Linux und Windows
* Android-App mit frei konfigurierbaren Bedienertasten/Bildschirmseiten
* Anlernen von IR-Codes mit Speicherung unter Android
* Senden der IR-Codes über WLAN an den Remote-IRMP Controller

== Hardware ==

[[Datei:Remote-irmp-schaltung-arduino.png|thumb|Schaltbild des Prototyps als Shield für Arduino Ethernet]]

Der stabil laufende Prototyp wurde mit dem Arduino Ethernet Board (erhältlich z.B. bei [http://www.pollin.de/shop/dt/MTA4OTgxOTk-/Bausaetze_Module/Entwicklerboards/ARDUINO_Ethernet.html Pollin]) realisiert - jedoch ohne die Verwendung der Arduino-Bibliotheken bzw. Arduino-Software. Die Verwendung des fertigen Boards hatte den Vorteil, dass der Lötaufwand sich auf ein Minimum reduziert: Es muss lediglich je ein IR-Sender- und ein Empfänger-Modul angeschlossen werden. Diese Module bestehen lediglich aus ein paar Bauteilen, welche hier auf eine Lochraster-Platine gelötet werden. Die Lochraster-Platine wird dann einfach als Shield auf das Arduino-Board aufgesteckt. Das Schaltbild dazu ist rechts zu sehen.

Dabei ist:

* 0C0A = PD6 oder in der Arduino-Nomenklatur: Digital Pin 6
* PC0 in der Arduino-Schreibweise: Analog Input 0.

Die für den Prototyp entwickelte Software funktioniert aber auch mit einem WIZnet WIZ812MJ-Modul, welches man zum Beispiel bei [http://www.watterott.com/de/WIZnet-WIZ812MJ-Ethernet-Modul Watterott] erstehen kann. Dieses Modul wird dann auf eine eigens zu entwickelnde Platine aufgesteckt.

Die dafür notwendige Hauptplatine als endgültige Version mit ATmega, Infrarot-Sender/Empfänger und Funksteckdosen-Sendermodul ist noch nicht ganz fertig - dazu später mehr. Der Prototyp mit dem Arduino Ethernet Board ist aber durchaus jetzt schon einsatzfähig.

== Protokoll ==

[[Datei:Remote-IRMP-Screenshot3.png|thumb|Beispiel für einen DVD-Player]]

Das Kommunikationsprotokoll für die Remote-IRMP-Satelliten wurde bewusst einfach gehalten. Dabei kann sowohl TCP/IP als auch UDP verwendet werden.

=== Senden eines IRMP-Codes ===

In diesem Fall sind 7 Bytes zu übertragen:

* Byte 1: 'S' als Kommmando "Send"
* Byte 2: [[IRMP]]-Protokollnummer
* Byte 3: Upper Byte der [[IRMP]]-Adresse
* Byte 4: Lower Byte der [[IRMP]]-Adresse
* Byte 5: Upper Byte des [[IRMP]]-Kommandos
* Byte 6: Lower Byte des [[IRMP]]-Kommandos
* Byte 7: [[IRMP]]-Flag

Antwort:

* Byte 1: 'S'
* Byte 2: '+' im Erfolgsfall

oder:

* Byte 1: 'S'
* Byte 2: '-' als Fehlercode, wenn das Protokoll unbekannt ist.

=== Empfangen eines IRMP-Codes (Anlernen) ===

Es wird lediglich 1 Byte gesandt:

* Byte 1: 'R' als Kommmando "Receive"

Wenn man als Anwender innerhalb von 5 Sekunden nun eine Fernbedienung betätigt, wird der angelernte Code als Antwort zurückgeschickt, nämlich:

* Byte 1: 'R' als Bestätigung
* Byte 2: '+' als Erfolgscode
* Byte 3: [[IRMP]]-Protokollnummer
* Byte 4: Upper Byte der [[IRMP]]-Adresse
* Byte 5: Lower Byte der [[IRMP]]-Adresse
* Byte 6: Upper Byte des [[IRMP]]-Kommandos
* Byte 7: Lower Byte des [[IRMP]]-Kommandos
* Byte 8: [[IRMP]]-Flag

Sollte keine Fernbedienungstaste betätigt oder das verwendete IR-Protokoll von [[IRMP]] nicht verstanden werden, werden als Antwort auch 8 Bytes zurückgesandt, aber:

* Byte 1: 'R' als Bestätigung
* Byte 2: '-' als Fehlercode
* Byte 3-8: 0x00

=== Weitere Netzwerkbefehle ===

[[Datei:Remote-IRMP-Screenshot4.png|thumb|Bis zu 8 Remote-IRMP Server sind ansprechbar]]

Außerdem wurde noch ein Kommando eingebaut, um die Kommunikation über IP selbst zu testen:

* Byte 1: 'P' als "Ping"-Kommando

Antwort:

* Byte 1: 'P' als Bestätigung
* Byte 2: '+' als Erfolgscode

Es gibt noch ein weiteres Kommando - dieses jedoch nur für TCP/IP, nicht für UDP:

* Byte 1: 'B' als Bootloader-Sprungkommando

Es kommt keine Antwort zurück, sondern der ATmega328 springt dann direkt in den Ethernet-Bootloader, damit man ein Update flashen kann, ohne extra die RESET-Taste drücken zu müssen. Siehe dazu auch das Kapitel [http://www.mikrocontroller.net/articles/Remote_IRMP#Bootloader_-_Flashen_.C3.BCbers_Netzwerk Bootloader - Flashen übers Netzwerk].

== IRMP-Software mit LAN-Anbindung ==

Der Source-Code lässt sich einfach für AVR-µCs übersetzen, indem man unter Windows die Projekt-Datei ipserver.aps in das AVR Studio 4 lädt. Jedoch sollte der avr-gcc schon ein neuerer sein, als ursprünglich mal 2010 mit dem AVR Studio 4 ausgeliefert wurde. Ich persönlich nutze avr-gcc 4.7.2.

Bei neueren Entwicklungsumgebungen bzw. Linux ist es auch kein Problem, ein eigenes Projekt bzw. Makefile zu erstellen. Folgende Sources müssen dafür ins Projekt übernommen werden:

* ipserver.c - das main-Modul
* [http://www.mikrocontroller.net/svnbrowser/irmp/irmp.c?view=markup irmp.c] - der IR-Multiprotokoll-Decoder
* [http://www.mikrocontroller.net/svnbrowser/irmp/irsnd.c?view=markup irsnd.c] - der IR-Encoder
* w5100.c - der Wiznet W5100 Treiber

Zum Projekt gehören dann noch folgende Includes:

* [http://www.mikrocontroller.net/svnbrowser/irmp/irmp.h?view=markup irmp.h]
* [http://www.mikrocontroller.net/svnbrowser/irmp/irmpconfig.h?view=markup irmpconfig.h]
* [http://www.mikrocontroller.net/svnbrowser/irmp/irmpextlog.h?view=markup irmpextlog.h]
* [http://www.mikrocontroller.net/svnbrowser/irmp/irmpprotocols.h?view=markup irmpprotocols.h]
* [http://www.mikrocontroller.net/svnbrowser/irmp/irmpsystem.h?view=markup irmpsystem.h]
* [http://www.mikrocontroller.net/svnbrowser/irmp/irsnd.h?view=markup irsnd.h]
* [http://www.mikrocontroller.net/svnbrowser/irmp/irsndconfig.h?view=markup irsndconfig.h]
* w5100.h
* w5100config.h

'''Bitte KEINE weiteren C-Module (wie z.B. ipbootloader.c) im Projekt angeben!'''

Zusatzlich zu den Standard-Compiler-Optionen (Prozessor-Typ etc.) sollten dem Projekt für alle C-Dateien folgende Optionen hinzugefügt werden:

-DF_CPU=16000000UL
-Os
-flto
-ffunction-sections
-fdata-sections

Als Linker-Optionen:

-Os
-flto
-ffunction-sections
-fdata-sections
-Wl,--gc-sections

=== Fuses ===
Wichtig sind auch die Fuses. Wenn das Arduino Ethernet Board verwendet wird, muss auf jeden Fall der standardmäßig installierte Bootloader deaktiviert werden. Aber auch für eine eigene Platine müssen die Fuses angepasst werden, nämlich auf:

* lfuse: 0xFF
* hfuse: 0xD1
* efuse: 0xFD

Nur wenn der eigene IP-Bootloader auch verwendet werden soll, ist die hfuse nochmals zu ändern. Das ist dann im [http://www.mikrocontroller.net/articles/Remote_IRMP#Bootloader_-_Flashen_.C3.BCbers_Netzwerk Bootloader-Kapitel] weiter unten nachzulesen.

=== Konfiguration ===

[[Datei:Remote-IRMP-Screenshot5.png|thumb|Konfiguration und Test eines Remote-IRMP Servers]]

Es können etliche Parameter angepasst werden. Hier die wichtigsten Einstellungen:

'''ipserver.c'''

<syntaxhighlight lang="c">
#define DEBUG 1

#define MAC_ADDRESS {0x90,0xA2,0xDA,0x00,0xF4,0x65} // mac address
#define IP_ADDRESS {192,168,10,233} // ip address
#define IP_NETMASK {255,255,255,0} // netmask
#define IP_GATEWAY {192,168,10,1} // gateway address

#define DBG_PORT 10000 // debug tcp listen port
#define TCP_PORT 10001 // normal tcp listen port
#define UDP_PORT 10001 // udp port

#define LED_DDR DDRB
#define LED_PORT PORTB
#define LED_BIT PB1
</syntaxhighlight>

Als MAC-Adresse (MAC_ADDRESS) wählt man beim Arduino Ethernet Board am besten die aufgeklebte MAC-Adresse. Dann kann es nicht zu Konflikten kommen. Die IP-Adresse (IP_ADDRESS) sollte an das lokale Netzwerk angepasst werden. Ebenso die Netzwerkmaske (IP_NETMASK), wenn sie im lokalen Netz abweicht. Die Angabe eines Gateways (IP_GATEWAY) ist nicht unbedingt notwendig, wenn die [[IRMP]]-Server nur im lokalen Netz erreichbar sein sollen. In diesem Fall kann {0,0,0,0} angegeben werden.

Normalerweise horchen die [[IRMP]]-Server auf dem TCP- und UDP-Port 10001. Wenn gewünscht, können die Ports sowohl für TCP (TCP_PORT) als auch für UDP (UDP_PORT) geändert werden. Sie können auch verschieden sein. Normalerweise ist aber eine Änderung nicht notwendig.

Bleibt noch der Debug-Port (DBG_PORT). Nur wenn die Präprozessor-Konstante DEBUG auf 1 steht, spielt dieser eine Rolle. Dann protokolliert der [[IRMP]]-Server nämlich alle eingehenden [[IRMP]]-Befehle, wenn man eine telnet-Session für die konfigurierte IP-Adresse und den Debug-Port öffnet. Unter Windows eignet sich dafür hervorragend PuTTY, welches man aus dem Internet herunterladen kann. Bei unixoiden Systemen ist telnet sowieso verfügbar - meist schon standardmäßig installiert.

Wird Debugging nicht gewünscht, kann man DEBUG auf 0 setzen und der Wert des DBG_PORTs wird irrelevant.

Außerdem gibt es noch die Definitionen für eine am ATmega angeschlossene LED (Konstanten LED_xxx). Hier werden dann ausgesandte IR-Signale parallel auf der LED visualisiert. Außerdem leuchtet diese LED, solange man einen IR-Code anlernt.

Die obigen Werte dafür entsprechen der bereits vorhandenen LED auf dem Arduino-Board. Sie können natürlich für andere Hardware (z.B. eigene Platine mit WIZ812MJ-Modul) angepasst werden. Besser: Man wählt beim Entwurf einer eigenen Hauptplatine einfach denselben Port.

'''w5100config.h'''

<syntaxhighlight lang="c">
#define CHIP_SELECT_AVAILABLE 0 // set to 1 if CS will be controlled by other pin than SS of the µC
#define CHIP_RESET_AVAILABLE 0 // set to 1 if RESET can be controlled by µC

#if CHIP_SELECT_AVAILABLE == 1 // if CS can be controlled , enter port/pin of µC
# define CS_DDR DDRD
# define CS_PORT PORTD
# define CS_BIT 4
#endif

#if CHIP_RESET_AVAILABLE == 1 // if RESET can be controlled by µC, enter port/pin of µC
# define RESET_DDR DDRD
# define RESET_PORT PORTD
# define RESET_BIT 5
#endif
</syntaxhighlight>

Die obigen Konstanten beschreiben, wie der W5100-Controller an den ATmega angebunden ist.

Ist CS (Chip-Select) des W5100 '''nicht''' an SS des ATmegas angeschlossen, muss CHIP_SELECT_AVAILABE auf 1 gesetzt werden und mittels CS_xxx-Konstanten der für CS verwendete Port-Pin des ATmegas angegeben werden, damit der ATmega softwaremäßig den Ethernet-Controller aktivieren kann. Beim Arduino Ethernet Board ist CS mit SS fest verbunden, so dass CHIP_SELECT_AVAILABLE auf 0 stehen bleibt und die CS_xxx-Konstanten nicht weiter beachtet werden.

Muss der W5100-Controller explizit über den RESET-Pin softwaremäßig zurückgesetzt werden, dann sollte dies über den ATmega geschehen. In diesem Fall setzt man CHIP_RESET_AVAILABLE auf 1 und definiert weiter unten den Portpin (RESET_xxx), an welchem ATmega-Portpin der RESET-Pin des W51000 angeschlossen ist. Beim Arduino Ethernet Board hängt der W5100 an einer eigenen Hardware-Reset-Schaltung, so dass CHIP_SELECT_AVAILABLE auf 0 stehenbleiben kann und damit die RESET_xxx-Konstanten irrelevant werden.

'''irmpconfig.h''' und '''irsndconfig.h'''

Die Konstanten in den [[IRMP]]-Konfigurationsdateien sind ausführlich im [[IRMP]]-Artikel erklärt. Daher wird hier auf weitere Erläuterungen verzichtet. Im wesentlichen wird hier definiert, welche Pins am ATmega für den IR-Empfänger und für den IR-Sender verwendet werden. Die Port-Einstellungen sind hier vorgewählt auf das oben bereits erwähnte Lochraster-Arduino-Ethernet-Shield - siehe Schaltbild. Ausserdem kann man hier die IR-Protokolle auswählen, die [[IRMP]]/IRSND mit einbinden soll. Insgsamt sind 36 Protokolle wählbar. Die häufigsten 6 Protokolle sind bereits aktiviert.

'''Erster Start'''

Der erste Start mit dem Arduino Ethernet Board kann durchaus auch ohne selbstgebautes "Shield" auf Lochrasterplatine gewagt werden. Hierzu wird die vom Compiler erzeugte Hex-Datei über den 6-poligen ISP-Stecker des Boards eingespielt. [http://www.mikrocontroller.net/articles/Remote_IRMP#Fuses Fuses] nicht vergessen! Anschließend sollte man vom PC aus das Modul per ping-Befehl ansprechen können. Wenn das funktioniert, ist man schon fast am Ziel. Nun sollte man das Board von der Stromversorgung trennen und die Platine mit IR-Empfänger und Sender als Shield aufstecken. Nach Neustart kann man nun entweder direkt die Funktionen mit der [http://www.mikrocontroller.net/articles/Remote_IRMP#Android-Software Android-App] testen oder erstmal mit einem [http://www.mikrocontroller.net/articles/Remote_IRMP#Andere_Betriebssysteme_als_Clients PC-Testprogramm], siehe weiter unten.

Ganz Mutige lassen das aber mit dem Programmieren der Remote-IRMP-Software über den ISP, sondern installieren direkt den [http://www.mikrocontroller.net/articles/Remote_IRMP#Bootloader_-_Flashen_.C3.BCbers_Netzwerk Bootloader], siehe weiter [http://www.mikrocontroller.net/articles/Remote_IRMP#Bootloader_-_Flashen_.C3.BCbers_Netzwerk unten]. Anschließend kann man beliebig oft die IRMP-Software oder Updates davon direkt übers Netzwerk installieren.

== Bootloader - Flashen übers Netzwerk ==

Wenn man schon einen netzwerkfähigen ATmega hat, dann möchte man Updates auch über das angesteckte Netzwerkkabel einspielen. Dafür wurde ein Bootloader entwickelt, welcher mit 1,6 KB Größe leicht in den oberen Flash-Bereich des ATmega328 passt. Das eigentliche Flash-Programm sendet dann per TCP/IP die Daten an den Bootloader. Das Flash-Programm ist für Unix, Linux und Windows verfügbar.

=== Bootloader-Kommunikationsprotokoll ===

* Bootloader (BL) horcht auf TCP/Port 22222 und wartet für 3 Sekunden auf das Zeichen '$' (1 Byte)
* Falls dieses eintrifft, antwortet BL ebenfalls mit dem '$'-Zeichen (1 Byte), anderenfalls hier Ende
* BL sendet die µC-spezifische "Page-Size" des Flashs zum Programmieren an den PC (1 Byte)
* PC sendet erste Page-Nummer des zu schreibenden Programms (2 Bytes, LSB, i.d.R. 0x00 0x00)
* PC sendet die Anzahl der zu übertragenden Pages (2 Bytes, LSB)
* PC sendet die Daten für eine Page - gefolgt von einem Prüfsummen-Byte
* BL antwortet mit '1', wenn das Prüfsummen-Byte passt, anderenfalls mit '0' und bricht ab
* Weiter gehts mit der nächsten Page, also 2 Schritte höher...

=== Bootloader-Software ===

Der Source-Code lässt sich einfach für AVR-µCs übersetzen, indem man unter Windows die Projekt-Datei ipbootloader.aps in das AVR Studio 4 lädt. Der avr-gcc muss jedoch neuer sein als der, welcher ursprünglich im Jahre 2010 mit dem AVR Studio 4 ausgeliefert wurde. Empfehlung: avr-gcc 4.7.2 oder neuer.

Bei neueren AVR-Entwicklungsumgebungen bzw. Linux ist es auch kein Problem, ein eigenes Projekt bzw. Makefile zu erstellen. Folgende Sources müssen dafür ins Projekt übernommen werden:

* ipbootloader.c - der Bootloader
* w5100.c - der Wiznet W5100 Treiber

Zum IP-Bootloader-Projekt gehören dann noch folgende Includes:

* w5100.h
* w5100config.h

'''Bitte KEINE weiteren C-Module (wie z.B. ipserver.c o.ä.) im Projekt angeben!'''

Zusatzlich zu den Standard-Compiler-Optionen (Prozessor-Typ etc.) müssen dem Projekt für alle C-Dateien folgende Optionen hinzugefügt werden:

-DF_CPU=16000000UL
-Os
-flto
-ffunction-sections
-fdata-sections

Als Linker-Optionen:

-Os
-flto
-ffunction-sections
-fdata-sections
-Wl,--gc-sections
-Wl,--section-start=.text=0x7800

Mit der letzten Linker-Option wird das Programm derart übersetzt, dass es ab Adresse 0x7800 lauffähig ist. Damit liegt es in den letzten 2KB des ATmega328-Flash-Speichers. Beim Übersetzen ist dringendst darauf zu achten, dass das Compilat eine "Program Size" von ca. 1,6KB hat. Wird es größer als 2KB, dann sind offensichtlich die obigen Compiler- und Linker-Optionen nicht korrekt eingetragen und das Programm ist als Bootloader unbrauchbar.

=== Konfiguration des Bootloaders ===

Hier gelten im wesentlichen dieselben Konfigurationsparameter für w5100config.h wie [http://www.mikrocontroller.net/articles/Remote_IRMP#Konfiguration oben]. Wichtig ist die Anpassung der IP-Adresse, siehe dafür ipbootloader.c:

<syntaxhighlight lang="c">
#define MAC_ADDRESS {0x90,0xA2,0xDA,0x00,0xF4,0x65} // mac address
#define IP_ADDRESS {192,168,10,233} // ip address
#define IP_NETMASK {255,255,255,0} // netmask
#define IP_GATEWAY {192,168,10,1} // gateway address

#define TCP_PORT 22222 // listen port
</syntaxhighlight>

=== Fuses für den Bootloader ===

Die Fuses sind in diesem Fall auf folgende Werte zu ändern:

* lfuse: 0xFF
* hfuse: 0xD2
* efuse: 0xFD

Damit werden die letzten 2KB im Flash für den Bootloader reserviert. Dieser kann dann über den ISP-Stecker installiert werden. Updates der Remote-IRMP-Software können anschließend bequem über das Netzwerk eingespielt werden. Der Anschluss eines ISP-Programmers ist dann nicht mehr notwendig.

=== Flashprogramm ===

Das Flashprogramm ist unter Unix, Linux und Windows verfügbar. Als Executable für Windows benutzt man einfach ipflash.exe, unter unixoiden System kompiliert man sich das Programm selbst mit:

cc -O win32/ipflash/ipflash.c -o ipflash

Der Aufruf ist dann allgemein:

ipflash [-b ipserver-tcp-port] ip-address tcp-port hex-file

oder konkret für die Windows-Eingabeaufforderung:

ipflash.exe 192.168.10.233 22222 ipserver.hex

bzw. linux:

./ipflash 192.168.10.233 22222 ipserver.hex

Wichtig ist dabei, kurz vorher den RESET-Button auf dem Board zu drücken und dann innerhalb von 3 Sekunden das Flash-Programm zu starten.

Ist einmal das ipserver-Programm installiert, kann man sich das Drücken des RESET-Buttons zukünftig auch sparen. Dann kann das Flash-Programm den ATmega auch über das Netzwerk resetten. Hierbei ist zusätzlich der TCP-Port des ipserver-Programms anzugeben, also:

ipflash.exe -b 10001 192.168.10.233 22222 ipserver.hex

bzw.

./ipflash -b 10001 192.168.10.233 22222 ipserver.hex

In diesem Fall schickt das Flash-Programm zunächst den Boot-Befehl auf Port 10001, wartet dann ein paar Sekunden und führt dann erst den eigentlichen Flash-Prozess aus. So kann man dann bequem vom Arbeitsplatz aus alle [[IRMP]]-Netzwerkserver im Haushalt aktualisieren, ohne direkt "vor Ort" zu sein.

== Android-Software ==

[[Datei:Remote-IRMP-Screenshot2.png|thumb|Anlernen eines IR-Befehls]]

=== Merkmale ===

* Ansteuerung von mehreren im Haushalt verteilten IRMP-Satelliten
* Erstellung von mehreren Bildschirmseiten
* Frei definierbares Tastenfeld pro Bildschirmseite
* Anlernen von IR-Codes
* Senden von IR-Codes

=== Konfiguration ===

Nach dem ersten Start der App sollte zunächst mindestens ein Remote-IRMP-Satellit konfiguriert werden. Dazu wählt man unter dem Menü den Punkt "Server" an und wählt den ersten Server aus. Hier kann man einen Namen wählen, z.B. "Wohnzimmer". Nach Eingabe der IP-Adresse und des UDP-Ports (i.d.R. 10001) kann man zunächst die Verbindung testen. War diese erfolgreich, speichert man die Serverkonfiguration mit "OK" ab.

=== Bearbeiten ===

In der App sind bereits einige Geräte und ein paar Tasten als Beispiel gespeichert. Die verschiedenen Bildschirmseiten kann man durch Wischen nach links oder rechts anwählen.

Mit der Anwahl des Menüpunktes "Bearbeiten" kann man nun eine (oder direkt mehrere) Seiten ändern. Oben erscheint dann eine zusätzliche Schaltfläche zum Speichern. Unmittelbar darunter kann die Bezeichnung der Seite geändert werden.

Die bisherigen Tasten werden nun etwas nach unten hin "gestreckt" gezeigt. Das ist Absicht: Die Leerzeilen repräsentieren nämlich später jeweils einen kleinen Abstand zwischen Tastenzeilen. Tippt man nun auf eine leere Fläche, erscheint dort eine neue Taste. Durch erneutes Antippen wird die Konfiguration der Taste geöffnet. Nach Eingabe einer Bezeichnung (Bitte keine Smilies o.ä. eingeben, das kann beim Speichern im Moment noch die Konfiguration zerschiessen!) kann man nun die Taste anlernen. Dafür tippt man die Anlernen-Schaltfläche an. Nun hat man 5 Sekunden Zeit, die gewünschte Taste anzulernen, indem man sie auf der Fernbedienung drückt und dabei auf den IR-Empfänger zielt. Nun sollte das Protokoll, die Adresse und das Kommando erscheinen. Man kann diese Parameter zwar auch manuell eingeben, jedoch ist die Übernahme durch Anlernen doch um einiges einfacher.

Nach dem Speichern sollte ein kurzes Antippen der konfigurierten Tasten den Remote-IRMP-Sender dazu bewegen, den vorher angelernten IR-Code wieder auszusenden.

Eine Taste kann durch langes Drücken im Bearbeitungsmodus gelöscht werden.

(Beschreibung wird fortgesetzt)

=== Weitere Planung ===

* Erweiterung um Graphiksymbole für die Tasten
* Makros, um mehrere nachfolgende Befehle über eine Taste zu senden
* Anlernen von Funksteckdosen-Fernbedienungen

== Andere Betriebssysteme als Clients ==

Es ist auch möglich, für andere Betriebssysteme einen Remote-IRMP-Client zu entwickeln. Ein entsprechendes C-Programm inkl. Quelltext, welches [[IRMP]]-Codes an einen [[IRMP]]-Satelliten schickt bzw. die angelernten Codes empfängt, habe ich beigefügt. Der C-Quelltext ist unter Unix, Linux und Windows compilierbar. Dieses Testprogramm ist als Vorlage für ambitionierte Anwender gedacht, die selbst ein eigenes PC-Projekt für Remote-IRMP realisieren möchten.

Als Executable für Windows kann man auch einfach ipclient.exe benutzen, unter Unix bzw. Linux kompiliert man das Programm selbst mit:

cc -O win32/ipclient/ipclient.c -o ipclient

=== Aufruf des Testprogramms ===

Allgemeiner Aufruf:

IR-Code senden über UDP:

ipclient udpsend ipaddress udp-port ir-protocol ir-addr-in-hex ir-command-in-hex flag-in-hex

IR-Code senden über TCP:

ipclient send ipaddress tcp-port ir-protocol ir-addr-in-hex ir-command-in-hex flag-in-hex

IR-Code empfangen über UDP:

ipclient udprec ipaddress udp-port

IR-Code empfangen über TCP:

ipclient rec ipaddress tcp-port

=== Beispiel: Senden eines IRMP-Codes ===

IR-Code senden über UDP, z.B. NEC-Protokoll (Nr. 2), Adresse 0xFF00, Kommando: 0x0020, Flag: 0x00

Der Aufruf ist dann in der Windows-Eingabeaufforderung:

ipclient.exe udpsend 192.168.10.233 10001 2 FF00 0020 0

bzw. unter Linux:

./ipclient udpsend 192.168.10.233 10001 2 FF00 0020 0

Wichtig ist dabei, dass die Protokollnummer in dezimal, alle anderen IR-Parameter in hexadezimal angegeben werden. Eine Liste der IR-Protokollnummern findet man hier: [http://www.mikrocontroller.net/svnbrowser/irmp/irmpprotocols.h?view=markup irmpprotocols.h]

=== Beispiel: Empfangen eines IRMP-Codes ===

Man kann natürlich auch IR-Telegramme empfangen, z.B. über TCP mit dem folgenden Befehl:

Windows-Eingabeaufforderung:

ipclient.exe rec 192.168.10.233 10001

Linux:

./ipclient rec 192.168.10.233 10001

Sendet man nun innerhalb von 5 Sekunden mit irgendeiner Fernbedienung ein Signal an den IR-Empfänger, wird dieses dann als [[IRMP]]-Code (Protokoll, Adresse, Kommando, Flag) auf dem PC ausgegeben.

== Downloads ==

==== Remote-IRMP für AVR, Unix, Linux, Windows ====

Version 1.0: [[Datei:Remote-irmp.zip]]

==== Remote-Butler als Client für Android ====

Version 1.0: [[Datei:RemoteButler.apk]]

Das einfachste, um die App unter Android zu installieren, ist es, den obigen Download-Link direkt auf dem Handy anzuklicken.

Java-Sources für Interessierte: [[Datei:Remotebutler.zip]]

==== Dateiliste ====

{| class="wikitable"
! Dateiname || Erläuterung
|-
| ipbootloader.aps || AVR Studio4 Projektdatei des Bootloaders
|-
| ipbootloader.c || main-Modul des Bootloaders
|-
|
|-
| ipserver.aps || AVR Studio4 Projektdatei des IP-Servers
|-
| ipserver.c || main-Modul des IP-Servers
|-
| [http://www.mikrocontroller.net/svnbrowser/irmp/irmp.c?view=markup irmp.c] || Der eigentliche IR-Decoder
|-
| [http://www.mikrocontroller.net/svnbrowser/irmp/irmp.h?view=markup irmp.h] || Include-Datei für IRMP-Projekte
|-
| [http://www.mikrocontroller.net/svnbrowser/irmp/irmpconfig.h?view=markup irmpconfig.h] || Konfiguration für IRMP
|-
| [http://www.mikrocontroller.net/svnbrowser/irmp/irmpextlog.c?view=markup irmpextlog.c] || IRMP-Logging für Nicht-AVR-µCs
|-
| irmpextlog.h || IRMP-Interne Include-Datei
|-
| [http://www.mikrocontroller.net/svnbrowser/irmp/irmpprotocols.h?view=markup irmpprotocols.h] || Sämtliche Definitionen zu den IR-Protokollen
|-
| [http://www.mikrocontroller.net/svnbrowser/irmp/irmpsystem.h?view=markup irmpsystem.h] || Vom Zielsystem abhängige Definitionen für AVR/PIC/STM32
|-
| [http://www.mikrocontroller.net/svnbrowser/irmp/irsnd.c?view=markup irsnd.c] || Der eigentliche IR-Encoder
|-
| [http://www.mikrocontroller.net/svnbrowser/irmp/irsnd.h?view=markup irsnd.h] || Include-Datei für die Applikation
|-
| [http://www.mikrocontroller.net/svnbrowser/irmp/irsndconfig.h?view=markup irsndconfig.h] || Anzupassende Konfigurationsdatei
|-
|
|-
| w5100.c || Treiber-Modul für WIZnet W5100 Netzwerk-Controller
|-
| w5100.h || Include-Datei für W5100-Treiber
|-
| w5100config.h|| Konfigurationsdatei für W5100-Treiber
|-
|
|-
| ipclient.exe || ipclient-Executable für Windows
|-
| ipflash.exe || ipflash-Executable für Windows
|-
|
|-
| win32/ipclient/ipclient.c || Beispiel Client in C - übersetzbar unter Unix, Linux und Windows
|-
| win32/ipclient/ipclient.sln || gehört zu ipclient - für Microsoft Visual C++ 2010 Express
|-
| win32/ipclient/ipclient.suo || gehört zu ipclient - für Microsoft Visual C++ 2010 Express
|-
| win32/ipclient/ipclient.vcxproj || Projekt-Datei für Microsoft Visual C++ 2010 Express
|-
|
|-
| win32/ipflash/ipflash.c || Flash-Programm in C - übersetzbar unter Unix, Linux und Windows
|-
| win32/ipflash/ipflash.sln || gehört zu ipflash - für Microsoft Visual C++ 2010 Express
|-
| win32/ipflash/ipflash.suo || gehört zu ipflash - für Microsoft Visual C++ 2010 Express
|-
| win32/ipflash/ipflash.vcxproj || Projekt-Datei für Microsoft Visual C++ 2010 Express
|}

== Siehe auch ==

* [http://www.mikrocontroller.net/topic/329407 Thread im Forum zu diesem Projekt]
* [[IRMP]]
* [http://ethersex.de/index.php/IRMP Portierung nach Ethersex]

Viel Spaß mit Remote IRMP!

[[Kategorie:Infrarot]]
[[Kategorie:AVR-Projekte]]

Remote IRMP

2014-12-20T09:51:32Z

Maybee: Typo

Von '''Frank M. ([http://www.mikrocontroller.net/user/show/ukw ukw])'''

[[Datei:Remote-IRMP-Screenshot1.png|thumb|Frei gestaltbare Tasten zum Senden von IR-Befehlen]]

Dieser Artikel ist eine konkrete Anwendung des [[IRMP]]-Projekts (IRMP-Dekoder = Infrarot-Multiprotokoll-Dekoder). Wir verschaffen unserem Mikrocontroller nicht nur einen IR-Sender und Empfänger, sondern auch noch einen Netzwerkanschluss. Damit wird es möglich, mit einer Android-App eine anlernbare IR-Fernbedienung zu realisieren. Der Anwender kann dann mehrere Geräte, die irgendwo im Haushalt verteilt sind, über das Handy steuern. Dabei sendet die App über WLAN zuvor gespeicherte [[IRMP]]-Codes an den gewünschten µC. Dieser strahlt dann die Signale über den IR-Sender aus, um damit unsere Geräte aus der Unterhaltungsindustrie zu schalten.

Außerdem ist eine Erweiterung von [[IRMP]] um Funksender geplant, damit zukünftig auch Funksteckdosen bequem vom Handy aus geschaltet werden können.

== Merkmale ==

Folgende Funktionalitäten sind bereits umgesetzt:

* Anbindung des µC an einen Wiznet W5100 Ethernet-Controller
* Protokollschnittstelle über TCP/IP und UDP
* Testprogramme der Kommunikation für Unix, Linux und Windows
* Android-App mit frei konfigurierbaren Bedienertasten/Bildschirmseiten
* Anlernen von IR-Codes mit Speicherung unter Android
* Senden der IR-Codes über WLAN an den Remote-IRMP Controller

== Hardware ==

[[Datei:Remote-irmp-schaltung-arduino.png|thumb|Schaltbild des Prototyps als Shield für Arduino Ethernet]]

Der stabil laufende Prototyp wurde mit dem Arduino Ethernet Board (erhältlich z.B. bei [http://www.pollin.de/shop/dt/MTA4OTgxOTk-/Bausaetze_Module/Entwicklerboards/ARDUINO_Ethernet.html Pollin]) realisiert - jedoch ohne die Verwendung der Arduino-Bibliotheken bzw. Arduino-Software. Die Verwendung des fertigen Boards hatte den Vorteil, dass der Lötaufwand sich auf ein Minimum reduziert: Es muss lediglich je ein IR-Sender- und ein Empfänger-Modul angeschlossen werden. Diese Module bestehen lediglich aus ein paar Bauteilen, welche hier auf eine Lochraster-Platine gelötet werden. Die Lochraster-Platine wird dann einfach als Shield auf das Arduino-Board aufgesteckt. Das Schaltbild dazu ist rechts zu sehen.

Dabei ist:

* 0C0A = PD6 oder in der Arduino-Nomenklatur: Digital Pin 6
* PC0 in der Arduino-Schreibweise: Analog Input 0.

Die für den Prototyp entwickelte Software funktioniert aber auch mit einem WIZnet WIZ812MJ-Modul, welches man zum Beispiel bei [http://www.watterott.com/de/WIZnet-WIZ812MJ-Ethernet-Modul Watterott] erstehen kann. Dieses Modul wird dann auf eine eigens zu entwickelnde Platine aufgesteckt.

Die dafür notwendige Hauptplatine als endgültige Version mit ATmega, Infrarot-Sender/Empfänger und Funksteckdosen-Sendermodul ist noch nicht ganz fertig - dazu später mehr. Der Prototyp mit dem Arduino Ethernet Board ist aber durchaus jetzt schon einsatzfähig.

== Protokoll ==

[[Datei:Remote-IRMP-Screenshot3.png|thumb|Beispiel für einen DVD-Player]]

Das Kommunikationsprotokoll für die Remote-IRMP-Satelliten wurde bewusst einfach gehalten. Dabei kann sowohl TCP/IP als auch UDP verwendet werden.

=== Senden eines IRMP-Codes ===

In diesem Fall sind 7 Bytes zu übertragen:

* Byte 1: 'S' als Kommmando "Send"
* Byte 2: [[IRMP]]-Protokollnummer
* Byte 3: Upper Byte der [[IRMP]]-Adresse
* Byte 4: Lower Byte der [[IRMP]]-Adresse
* Byte 5: Upper Byte des [[IRMP]]-Kommandos
* Byte 6: Lower Byte des [[IRMP]]-Kommandos
* Byte 7: [[IRMP]]-Flag

Antwort:

* Byte 1: 'S'
* Byte 2: '+' im Erfolgsfall

oder:

* Byte 1: 'S'
* Byte 2: '-' als Fehlercode, wenn das Protokoll unbekannt ist.

=== Empfangen eines IRMP-Codes (Anlernen) ===

Es wird lediglich 1 Byte gesandt:

* Byte 1: 'R' als Kommmando "Receive"

Wenn man als Anwender innerhalb von 5 Sekunden nun eine Fernbedienung betätigt, wird der angelernte Code als Antwort zurückgeschickt, nämlich:

* Byte 1: 'R' als Bestätigung
* Byte 2: '+' als Erfolgscode
* Byte 3: [[IRMP]]-Protokollnummer
* Byte 4: Upper Byte der [[IRMP]]-Adresse
* Byte 5: Lower Byte der [[IRMP]]-Adresse
* Byte 6: Upper Byte des [[IRMP]]-Kommandos
* Byte 7: Lower Byte des [[IRMP]]-Kommandos
* Byte 8: [[IRMP]]-Flag

Sollte keine Fernbedienungstaste betätigt oder das verwendete IR-Protokoll von [[IRMP]] nicht verstanden werden, werden als Antwort auch 8 Bytes zurückgesandt, aber:

* Byte 1: 'R' als Bestätigung
* Byte 2: '-' als Fehlercode
* Byte 3-8: 0x00

=== Weitere Netzwerkbefehle ===

[[Datei:Remote-IRMP-Screenshot4.png|thumb|Bis zu 8 Remote-IRMP Server sind ansprechbar]]

Außerdem wurde noch ein Kommando eingebaut, um die Kommunikation über IP selbst zu testen:

* Byte 1: 'P' als "Ping"-Kommando

Antwort:

* Byte 1: 'P' als Bestätigung
* Byte 2: '+' als Erfolgscode

Es gibt noch ein weiteres Kommando - dieses jedoch nur für TCP/IP, nicht für UDP:

* Byte 1: 'B' als Bootloader-Sprungkommando

Es kommt keine Antwort zurück, sondern der ATmega328 springt dann direkt in den Ethernet-Bootloader, damit man ein Update flashen kann, ohne extra die RESET-Taste drücken zu müssen. Siehe dazu auch das Kapitel [http://www.mikrocontroller.net/articles/Remote_IRMP#Bootloader_-_Flashen_.C3.BCbers_Netzwerk Bootloader - Flashen übers Netzwerk].

== IRMP-Software mit LAN-Anbindung ==

Der Source-Code lässt sich einfach für AVR-µCs übersetzen, indem man unter Windows die Projekt-Datei ipserver.aps in das AVR Studio 4 lädt. Jedoch sollte der avr-gcc schon ein neuerer sein, als ursprünglich mal 2010 mit dem AVR Studio 4 ausgeliefert wurde. Ich persönlich nutze avr-gcc 4.7.2.

Bei neueren Entwicklungsumgebungen bzw. Linux ist es auch kein Problem, ein eigenes Projekt bzw. Makefile zu erstellen. Folgende Sources müssen dafür ins Projekt übernommen werden:

* ipserver.c - das main-Modul
* [http://www.mikrocontroller.net/svnbrowser/irmp/irmp.c?view=markup irmp.c] - der IR-Multiprotokoll-Decoder
* [http://www.mikrocontroller.net/svnbrowser/irmp/irsnd.c?view=markup irsnd.c] - der IR-Encoder
* w5100.c - der Wiznet W5100 Treiber

Zum Projekt gehören dann noch folgende Includes:

* [http://www.mikrocontroller.net/svnbrowser/irmp/irmp.h?view=markup irmp.h]
* [http://www.mikrocontroller.net/svnbrowser/irmp/irmpconfig.h?view=markup irmpconfig.h]
* [http://www.mikrocontroller.net/svnbrowser/irmp/irmpextlog.h?view=markup irmpextlog.h]
* [http://www.mikrocontroller.net/svnbrowser/irmp/irmpprotocols.h?view=markup irmpprotocols.h]
* [http://www.mikrocontroller.net/svnbrowser/irmp/irmpsystem.h?view=markup irmpsystem.h]
* [http://www.mikrocontroller.net/svnbrowser/irmp/irsnd.h?view=markup irsnd.h]
* [http://www.mikrocontroller.net/svnbrowser/irmp/irsndconfig.h?view=markup irsndconfig.h]
* w5100.h
* w5100config.h

'''Bitte KEINE weiteren C-Module (wie z.B. ipbootloader.c) im Projekt angeben!'''

Zusatzlich zu den Standard-Compiler-Optionen (Prozessor-Typ etc.) sollten dem Projekt für alle C-Dateien folgende Optionen hinzugefügt werden:

-DF_CPU=16000000UL
-Os
-flto
-ffunction-sections
-fdata-sections

Als Linker-Optionen:

-Os
-flto
-ffunction-sections
-fdata-sections
-Wl,--gc-sections

=== Fuses ===
Wichtig sind auch die Fuses. Wenn das Arduino Ethernet Board verwendet wird, muss auf jeden Fall der standardmäßig installierte Bootloader deaktiviert werden. Aber auch für eine eigene Platine müssen die Fuses angepasst werden, nämlich auf:

* lfuse: 0xFF
* hfuse: 0xD1
* efuse: 0xFD

Nur wenn der eigene IP-Bootloader auch verwendet werden soll, ist die hfuse nochmals zu ändern. Das ist dann im [http://www.mikrocontroller.net/articles/Remote_IRMP#Bootloader_-_Flashen_.C3.BCbers_Netzwerk Bootloader-Kapitel] weiter unten nachzulesen.

=== Konfiguration ===

[[Datei:Remote-IRMP-Screenshot5.png|thumb|Konfiguration und Test eines Remote-IRMP Servers]]

Es können etliche Parameter angepasst werden. Hier die wichtigsten Einstellungen:

'''ipserver.c'''

<syntaxhighlight lang="c">
#define DEBUG 1

#define MAC_ADDRESS {0x90,0xA2,0xDA,0x00,0xF4,0x65} // mac address
#define IP_ADDRESS {192,168,10,233} // ip address
#define IP_NETMASK {255,255,255,0} // netmask
#define IP_GATEWAY {192,168,10,1} // gateway address

#define DBG_PORT 10000 // debug tcp listen port
#define TCP_PORT 10001 // normal tcp listen port
#define UDP_PORT 10001 // udp port

#define LED_DDR DDRB
#define LED_PORT PORTB
#define LED_BIT PB1
</syntaxhighlight>

Als MAC-Adresse (MAC_ADDRESS) wählt man beim Arduino Ethernet Board am besten die aufgeklebte MAC-Adresse. Dann kann es nicht zu Konflikten kommen. Die IP-Adresse (IP_ADDRESS) sollte an das lokale Netzwerk angepasst werden. Ebenso die Netzwerkmaske (IP_NETMASK), wenn sie im lokalen Netz abweicht. Die Angabe eines Gateways (IP_GATEWAY) ist nicht unbedingt notwendig, wenn die [[IRMP]]-Server nur im lokalen Netz erreichbar sein sollen. In diesem Fall kann {0,0,0,0} angegeben werden.

Normalerweise horchen die [[IRMP]]-Server auf dem TCP- und UDP-Port 10001. Wenn gewünscht, können die Ports sowohl für TCP (TCP_PORT) als auch für UDP (UDP_PORT) geändert werden. Sie können auch verschieden sein. Normalerweise ist aber eine Änderung nicht notwendig.

Bleibt noch der Debug-Port (DBG_PORT). Nur wenn die Präprozessor-Konstante DEBUG auf 1 steht, spielt dieser eine Rolle. Dann protokolliert der [[IRMP]]-Server nämlich alle eingehenden [[IRMP]]-Befehle, wenn man eine telnet-Session für die konfigurierte IP-Adresse und den Debug-Port öffnet. Unter Windows eignet sich dafür hervorragend PuTTY, welches man aus dem Internet herunterladen kann. Bei unixoiden Systemen ist telnet sowieso verfügbar - meist schon standardmäßig installiert.

Wird Debugging nicht gewünscht, kann man DEBUG auf 0 setzen und der Wert des DBG_PORTs wird irrelevant.

Außerdem gibt es noch die Definitionen für eine am ATmega angeschlossene LED (Konstanten LED_xxx). Hier werden dann ausgesandte IR-Signale parallel auf der LED visualisiert. Außerdem leuchtet diese LED, solange man einen IR-Code anlernt.

Die obigen Werte dafür entsprechen der bereits vorhandenen LED auf dem Arduino-Board. Sie können natürlich für andere Hardware (z.B. eigene Platine mit WIZ812MJ-Modul) angepasst werden. Besser: Man wählt beim Entwurf einer eigenen Hauptplatine einfach denselben Port.

'''w5100config.h'''

<syntaxhighlight lang="c">
#define CHIP_SELECT_AVAILABLE 0 // set to 1 if CS will be controlled by other pin than SS of the µC
#define CHIP_RESET_AVAILABLE 0 // set to 1 if RESET can be controlled by µC

#if CHIP_SELECT_AVAILABLE == 1 // if CS can be controlled , enter port/pin of µC
# define CS_DDR DDRD
# define CS_PORT PORTD
# define CS_BIT 4
#endif

#if CHIP_RESET_AVAILABLE == 1 // if RESET can be controlled by µC, enter port/pin of µC
# define RESET_DDR DDRD
# define RESET_PORT PORTD
# define RESET_BIT 5
#endif
</syntaxhighlight>

Die obigen Konstanten beschreiben, wie der W5100-Controller an den ATmega angebunden ist.

Ist CS (Chip-Select) des W5100 '''nicht''' an SS des ATmegas angeschlossen, muss CHIP_SELECT_AVAILABE auf 1 gesetzt werden und mittels CS_xxx-Konstanten der für CS verwendete Port-Pin des ATmegas angegeben werden, damit der ATmega softwaremäßig den Ethernet-Controller aktivieren kann. Beim Arduino Ethernet Board ist CS mit SS fest verbunden, so dass CHIP_SELECT_AVAILABLE auf 0 stehen bleibt und die CS_xxx-Konstanten nicht weiter beachtet werden.

Muss der W5100-Controller explizit über den RESET-Pin softwaremäßig zurückgesetzt werden, dann sollte dies über den ATmega geschehen. In diesem Fall setzt man CHIP_RESET_AVAILABLE auf 1 und definiert weiter unten den Portpin (RESET_xxx), an welchem ATmega-Portpin der RESET-Pin des W51000 angeschlossen ist. Beim Arduino Ethernet Board hängt der W5100 an einer eigenen Hardware-Reset-Schaltung, so dass CHIP_SELECT_AVAILABLE auf 0 stehenbleiben kann und damit die RESET_xxx-Konstanten irrelevant werden.

'''irmpconfig.h''' und '''irsndconfig.h'''

Die Konstanten in den [[IRMP]]-Konfigurationsdateien sind ausführlich im [[IRMP]]-Artikel erklärt. Daher wird hier auf weitere Erläuterungen verzichtet. Im wesentlichen wird hier definiert, welche Pins am ATmega für den IR-Empfänger und für den IR-Sender verwendet werden. Die Port-Einstellungen sind hier vorgewählt auf das oben bereits erwähnte Lochraster-Arduino-Ethernet-Shield - siehe Schaltbild. Ausserdem kann man hier die IR-Protokolle auswählen, die [[IRMP]]/IRSND mit einbinden soll. Insgsamt sind 36 Protokolle wählbar. Die häufigsten 6 Protokolle sind bereits aktiviert.

'''Erster Start'''

Der erste Start mit dem Arduino Ethernet Board kann durchaus auch ohne selbstgebautes "Shield" auf Lochrasterplatine gewagt werden. Hierzu wird die vom Compiler erzeugte Hex-Datei über den 6-poligen ISP-Stecker des Boards eingespielt. [http://www.mikrocontroller.net/articles/Remote_IRMP#Fuses Fuses] nicht vergessen! Anschließend sollte man vom PC aus das Modul per ping-Befehl ansprechen können. Wenn das funktioniert, ist man schon fast am Ziel. Nun sollte man das Board von der Stromversorgung trennen und die Platine mit IR-Empfänger und Sender als Shield aufstecken. Nach Neustart kann man nun entweder direkt die Funktionen mit der [http://www.mikrocontroller.net/articles/Remote_IRMP#Android-Software Android-App] testen oder erstmal mit einem [http://www.mikrocontroller.net/articles/Remote_IRMP#Andere_Betriebssysteme_als_Clients PC-Testprogramm], siehe weiter unten.

Ganz Mutige lassen das aber mit dem Programmieren der Remote-IRMP-Software über den ISP, sondern installieren direkt den [http://www.mikrocontroller.net/articles/Remote_IRMP#Bootloader_-_Flashen_.C3.BCbers_Netzwerk Bootloader], siehe weiter [http://www.mikrocontroller.net/articles/Remote_IRMP#Bootloader_-_Flashen_.C3.BCbers_Netzwerk unten]. Anschließend kann man beliebig oft die IRMP-Software oder Updates davon direkt übers Netzwerk installieren.

== Bootloader - Flashen übers Netzwerk ==

Wenn man schon einen netzwerkfähigen ATmega hat, dann möchte man Updates auch über das angesteckte Netzwerkkabel einspielen. Dafür wurde ein Bootloader entwickelt, welcher mit 1,6 KB Größe leicht in den oberen Flash-Bereich des ATmega328 passt. Das eigentliche Flash-Programm sendet dann per TCP/IP die Daten an den Bootloader. Das Flash-Programm ist für Unix, Linux und Windows verfügbar.

=== Bootloader-Kommunikationsprotokoll ===

* Bootloader (BL) horcht auf TCP/Port 22222 und wartet für 3 Sekunden auf das Zeichen '$' (1 Byte)
* Falls dieses eintrifft, antwortet BL ebenfalls mit dem '$'-Zeichen (1 Byte), anderenfalls hier Ende
* BL sendet die µC-spezifische "Page-Size" des Flashs zum Programmieren an den PC (1 Byte)
* PC sendet erste Page-Nummer des zu schreibenden Programms (2 Bytes, LSB, i.d.R. 0x00 0x00)
* PC sendet die Anzahl der zu übertragenden Pages (2 Bytes, LSB)
* PC sendet die Daten für eine Page - gefolgt von einem Prüfsummen-Byte
* BL antwortet mit '1', wenn das Prüfsummen-Byte passt, anderenfalls mit '0' und bricht ab
* Weiter gehts mit der nächsten Page, also 2 Schritte höher...

=== Bootloader-Software ===

Der Source-Code lässt sich einfach für AVR-µCs übersetzen, indem man unter Windows die Projekt-Datei ipbootloader.aps in das AVR Studio 4 lädt. Der avr-gcc muss jedoch neuer sein als der, welcher ursprünglich im Jahre 2010 mit dem AVR Studio 4 ausgeliefert wurde. Empfehlung: avr-gcc 4.7.2 oder neuer.

Bei neueren AVR-Entwicklungsumgebungen bzw. Linux ist es auch kein Problem, ein eigenes Projekt bzw. Makefile zu erstellen. Folgende Sources müssen dafür ins Projekt übernommen werden:

* ipbootloader.c - der Bootloader
* w5100.c - der Wiznet W5100 Treiber

Zum IP-Bootloader-Projekt gehören dann noch folgende Includes:

* w5100.h
* w5100config.h

'''Bitte KEINE weiteren C-Module (wie z.B. ipserver.c o.ä.) im Projekt angeben!'''

Zusatzlich zu den Standard-Compiler-Optionen (Prozessor-Typ etc.) müssen dem Projekt für alle C-Dateien folgende Optionen hinzugefügt werden:

-DF_CPU=16000000UL
-Os
-flto
-ffunction-sections
-fdata-sections

Als Linker-Optionen:

-Os
-flto
-ffunction-sections
-fdata-sections
-Wl,--gc-sections
-Wl,--section-start=.text=0x7800

Mit der letzten Linker-Option wird das Programm derart übersetzt, dass es ab Adresse 0x7800 lauffähig ist. Damit liegt es in den letzten 2KB des ATmega328-Flash-Speichers. Beim Übersetzen ist dringendst darauf zu achten, dass das Compilat eine "Program Size" von ca. 1,6KB hat. Wird es größer als 2KB, dann sind offensichtlich die obigen Compiler- und Linker-Optionen nicht korrekt eingetragen und das Programm ist als Bootloader unbrauchbar.

=== Konfiguration des Bootloaders ===

Hier gelten im wesentlichen dieselben Konfigurationsparameter für w5100config.h wie [http://www.mikrocontroller.net/articles/Remote_IRMP#Konfiguration oben]. Wichtig ist die Anpassung der IP-Adresse, siehe dafür ipbootloader.c:

<syntaxhighlight lang="c">
#define MAC_ADDRESS {0x90,0xA2,0xDA,0x00,0xF4,0x65} // mac address
#define IP_ADDRESS {192,168,10,233} // ip address
#define IP_NETMASK {255,255,255,0} // netmask
#define IP_GATEWAY {192,168,10,1} // gateway address

#define TCP_PORT 22222 // listen port
</syntaxhighlight>

=== Fuses für den Bootloader ===

Die Fuses sind in diesem Fall auf folgende Werte zu ändern:

* lfuse: 0xFF
* hfuse: 0xD2
* efuse: 0xFD

Damit werden die letzten 2KB im Flash für den Bootloader reserviert. Dieser kann dann über den ISP-Stecker installiert werden. Updates der Remote-IRMP-Software können anschließend bequem über das Netzwerk eingespielt werden. Der Anschluss eines ISP-Programmers ist dann nicht mehr notwendig.

=== Flashprogramm ===

Das Flashprogramm ist unter Unix, Linux und Windows verfügbar. Als Executable für Windows benutzt man einfach ipflash.exe, unter unixoiden System kompiliert man sich das Programm selbst mit:

cc -O win32/ipflash/ipflash.c -o ipflash

Der Aufruf ist dann allgemein:

ipflash [-b ipserver-tcp-port] ip-address tcp-port hex-file

oder konkret für die Windows-Eingabeaufforderung:

ipflash.exe 192.168.10.233 22222 ipserver.hex

bzw. linux:

./ipflash 192.168.10.233 22222 ipserver.hex

Wichtig ist dabei, kurz vorher den RESET-Button auf dem Board zu drücken und dann innerhalb von 3 Sekunden das Flash-Programm zu starten.

Ist einmal das ipserver-Programm installiert, kann man sich das Drücken des RESET-Buttons zukünftig auch sparen. Dann kann das Flash-Programm den ATmega auch über das Netzwerk resetten. Hierbei ist zusätzlich der TCP-Port des ipserver-Programms anzugeben, also:

ipflash.exe -b 10001 192.168.10.233 22222 ipserver.hex

bzw.

./ipflash -b 10001 192.168.10.233 22222 ipserver.hex

In diesem Fall schickt das Flash-Programm zunächst den Boot-Befehl auf Port 10001, wartet dann ein paar Sekunden und führt dann erst den eigentlichen Flash-Prozess aus. So kann man dann bequem vom Arbeitsplatz aus alle [[IRMP]]-Netzwerkserver im Haushalt aktualisieren, ohne direkt "vor Ort" zu sein.

== Android-Software ==

[[Datei:Remote-IRMP-Screenshot2.png|thumb|Anlernen eines IR-Befehls]]

=== Merkmale ===

* Ansteuerung von mehreren im Haushalt verteilten IRMP-Satelliten
* Erstellung von mehreren Bildschirmseiten
* Frei definierbares Tastenfeld pro Bildschirmseite
* Anlernen von IR-Codes
* Senden von IR-Codes

=== Konfiguration ===

Nach dem ersten Start der App sollte zunächst mindestens ein Remote-IRMP-Satellit konfiguriert werden. Dazu wählt man unter dem Menü den Punkt "Server" an und wählt den ersten Server aus. Hier kann man einen Namen wählen, z.B. "Wohnzimmer". Nach Eingabe der IP-Adresse und des UDP-Ports (i.d.R. 10001) kann man zunächst die Verbindung testen. War diese erfolgreich, speichert man die Serverkonfiguration mit "OK" ab.

=== Bearbeiten ===

In der App sind bereits einige Geräte und ein paar Tasten als Beispiel gespeichert. Die verschiedenen Bildschirmseiten kann man durch Wischen nach links oder rechts anwählen.

Mit der Anwahl des Menüpunktes "Bearbeiten" kann man nun eine (oder direkt mehrere) Seiten ändern. Oben erscheint dann eine zusätzliche Schaltfläche zum Speichern. Unmittelbar darunter kann die Bezeichnung der Seite geändert werden.

Die bisherigen Tasten werden nun etwas nach unten hin "gestreckt" gezeigt. Das ist Absicht: Die Leerzeilen repräsentieren nämlich später jeweils einen kleinen Abstand zwischen Tastenzeilen. Tippt man nun auf eine leere Fläche, erscheint dort eine neue Taste. Durch erneutes Antippen wird die Konfiguration der Taste geöffnet. Nach Eingabe einer Bezeichnung (Bitte keine Smilies o.ä. eingeben, das kann beim Speichern im Moment noch die Konfiguration zerschiessen!) kann man nun die Taste anlernen. Dafür tippt man die Anlernen-Schaltfläche an. Nun hat man 5 Sekunden Zeit, die gewünschte Taste anzulernen, indem man sie auf der Fernbedienung drückt und dabei auf den IR-Empfänger zielt. Nun sollte das Protokoll, die Adresse und das Kommando erscheinen. Man kann diese Parameter zwar auch manuell eingeben, jedoch ist die Übernahme durch Anlernen doch um einiges einfacher.

Nach dem Speichern sollte ein kurzes Antippen der konfigurierten Tasten den Remote-IRMP-Sender dazu bewegen, den vorher angelernten IR-Code wieder auszusenden.

Eine Taste kann durch langes Drücken im Bearbeitungsmodus gelöscht werden.

(Beschreibung wird fortgesetzt)

=== Weitere Planung ===

* Erweiterung um Graphiksymbole für die Tasten
* Makros, um mehrere nachfolgende Befehle über eine Taste zu senden
* Anlernen von Funksteckdosen-Fernbedienungen

== Andere Betriebssysteme als Clients ==

Es ist auch möglich, für andere Betriebssysteme einen Remote-IRMP-Client zu entwickeln. Ein entsprechendes C-Programm inkl. Quelltext, welches [[IRMP]]-Codes an einen [[IRMP]]-Satelliten schickt bzw. die angelernten Codes empfängt, habe ich beigefügt. Der C-Quelltext ist unter Unix, Linux und Windows compilierbar. Dieses Testprogramm ist als Vorlage für ambitionierte Anwender gedacht, die selbst ein eigenes PC-Projekt für Remote-IRMP realisieren möchten.

Als Executable für Windows kann man auch einfach ipclient.exe benutzen, unter Unix bzw. Linux kompiliert man das Programm selbst mit:

cc -O win32/ipclient/ipclient.c -o ipclient

=== Aufruf des Testprogramms ===

Allgemeiner Aufruf:

IR-Code senden über UDP:

ipclient udpsend ipaddress tcp-port ir-protocol ir-addr-in-hex ir-command-in-hex flag-in-hex

IR-Code senden über TCP:

ipclient send ipaddress tcp-port ir-protocol ir-addr-in-hex ir-command-in-hex flag-in-hex

IR-Code empfangen über UDP:

ipclient udprec ipaddress tcp-port

IR-Code empfangen über TCP:

ipclient rec ipaddress tcp-port

=== Beispiel: Senden eines IRMP-Codes ===

IR-Code senden über UDP, z.B. NEC-Protokoll (Nr. 2), Adresse 0xFF00, Kommando: 0x0020, Flag: 0x00

Der Aufruf ist dann in der Windows-Eingabeaufforderung:

ipclient.exe udpsend 192.168.10.233 10001 2 FF00 0020 0

bzw. unter Linux:

./ipclient udpsend 192.168.10.233 10001 2 FF00 0020 0

Wichtig ist dabei, dass die Protokollnummer in dezimal, alle anderen IR-Parameter in hexadezimal angegeben werden. Eine Liste der IR-Protokollnummern findet man hier: [http://www.mikrocontroller.net/svnbrowser/irmp/irmpprotocols.h?view=markup irmpprotocols.h]

=== Beispiel: Empfangen eines IRMP-Codes ===

Man kann natürlich auch IR-Telegramme empfangen, z.B. über TCP mit dem folgenden Befehl:

Windows-Eingabeaufforderung:

ipclient.exe rec 192.168.10.233 10001

Linux:

./ipclient rec 192.168.10.233 10001

Sendet man nun innerhalb von 5 Sekunden mit irgendeiner Fernbedienung ein Signal an den IR-Empfänger, wird dieses dann als [[IRMP]]-Code (Protokoll, Adresse, Kommando, Flag) auf dem PC ausgegeben.

== Downloads ==

==== Remote-IRMP für AVR, Unix, Linux, Windows ====

Version 1.0: [[Datei:Remote-irmp.zip]]

==== Remote-Butler als Client für Android ====

Version 1.0: [[Datei:RemoteButler.apk]]

Das einfachste, um die App unter Android zu installieren, ist es, den obigen Download-Link direkt auf dem Handy anzuklicken.

Java-Sources für Interessierte: [[Datei:Remotebutler.zip]]

==== Dateiliste ====

{| class="wikitable"
! Dateiname || Erläuterung
|-
| ipbootloader.aps || AVR Studio4 Projektdatei des Bootloaders
|-
| ipbootloader.c || main-Modul des Bootloaders
|-
|
|-
| ipserver.aps || AVR Studio4 Projektdatei des IP-Servers
|-
| ipserver.c || main-Modul des IP-Servers
|-
| [http://www.mikrocontroller.net/svnbrowser/irmp/irmp.c?view=markup irmp.c] || Der eigentliche IR-Decoder
|-
| [http://www.mikrocontroller.net/svnbrowser/irmp/irmp.h?view=markup irmp.h] || Include-Datei für IRMP-Projekte
|-
| [http://www.mikrocontroller.net/svnbrowser/irmp/irmpconfig.h?view=markup irmpconfig.h] || Konfiguration für IRMP
|-
| [http://www.mikrocontroller.net/svnbrowser/irmp/irmpextlog.c?view=markup irmpextlog.c] || IRMP-Logging für Nicht-AVR-µCs
|-
| irmpextlog.h || IRMP-Interne Include-Datei
|-
| [http://www.mikrocontroller.net/svnbrowser/irmp/irmpprotocols.h?view=markup irmpprotocols.h] || Sämtliche Definitionen zu den IR-Protokollen
|-
| [http://www.mikrocontroller.net/svnbrowser/irmp/irmpsystem.h?view=markup irmpsystem.h] || Vom Zielsystem abhängige Definitionen für AVR/PIC/STM32
|-
| [http://www.mikrocontroller.net/svnbrowser/irmp/irsnd.c?view=markup irsnd.c] || Der eigentliche IR-Encoder
|-
| [http://www.mikrocontroller.net/svnbrowser/irmp/irsnd.h?view=markup irsnd.h] || Include-Datei für die Applikation
|-
| [http://www.mikrocontroller.net/svnbrowser/irmp/irsndconfig.h?view=markup irsndconfig.h] || Anzupassende Konfigurationsdatei
|-
|
|-
| w5100.c || Treiber-Modul für WIZnet W5100 Netzwerk-Controller
|-
| w5100.h || Include-Datei für W5100-Treiber
|-
| w5100config.h|| Konfigurationsdatei für W5100-Treiber
|-
|
|-
| ipclient.exe || ipclient-Executable für Windows
|-
| ipflash.exe || ipflash-Executable für Windows
|-
|
|-
| win32/ipclient/ipclient.c || Beispiel Client in C - übersetzbar unter Unix, Linux und Windows
|-
| win32/ipclient/ipclient.sln || gehört zu ipclient - für Microsoft Visual C++ 2010 Express
|-
| win32/ipclient/ipclient.suo || gehört zu ipclient - für Microsoft Visual C++ 2010 Express
|-
| win32/ipclient/ipclient.vcxproj || Projekt-Datei für Microsoft Visual C++ 2010 Express
|-
|
|-
| win32/ipflash/ipflash.c || Flash-Programm in C - übersetzbar unter Unix, Linux und Windows
|-
| win32/ipflash/ipflash.sln || gehört zu ipflash - für Microsoft Visual C++ 2010 Express
|-
| win32/ipflash/ipflash.suo || gehört zu ipflash - für Microsoft Visual C++ 2010 Express
|-
| win32/ipflash/ipflash.vcxproj || Projekt-Datei für Microsoft Visual C++ 2010 Express
|}

== Siehe auch ==

* [http://www.mikrocontroller.net/topic/329407 Thread im Forum zu diesem Projekt]
* [[IRMP]]
* [http://ethersex.de/index.php/IRMP Portierung nach Ethersex]

Viel Spaß mit Remote IRMP!

[[Kategorie:Infrarot]]
[[Kategorie:AVR-Projekte]]

Multitasking

2014-11-02T09:18:24Z

Maybee: Wiki-Syntax

Multitasking bedeutet ein quasi paralleles Ausführen von mehreren Prozessen auf einem Prozessor.

== Einleitung ==

Da eine echte parallele Ausführung von mehreren Prozessen (Programmen, Funktionen) auf einer einzelnen CPU (genauer: einem CPU-Kern) nicht möglich ist, wird ein "Trick" angewendet. Er besteht darin, einzelne Prozesse jeweils nur für kurze Zeit (ungefähr 1...50 ms) zu bearbeiten und danach auf einen anderen Prozess umzuschalten. Man spricht auch von einer verschachtelten Bearbeitung (engl. interleaving).

Das Herz jedes Multitasking-Systems ist der Scheduler. Dies ist ein Programm, das nach bestimmten Algorithmen überprüft, welcher Prozess als nächstes die CPU (also Rechenzeit) zugeteilt bekommt. Es gibt verschiedene Schedulingstrategien:

* "First come first served": Prozesse bekommen Rechenzeit zugeteilt in der Reihenfolge, in der sie rechenbereit werden.
* "Shortest job first": Der Prozess mit der kürzesten Rechenzeit wird als erstes bearbeitet. Dazu muss die Rechenzeit natürlich im Voraus bekannt sein.
* "Shortest remaining time next": Der Prozess mit der kürzesten ''verbleibenden'' Rechenzeit wird jeweils als nächstes bearbeitet. Auch hier muss diese Zeit bekannt sein.
* Round robin: Alle Prozesse bekommen gleich viel Zeit zugeteilt. Der Scheduler lässt jeden Prozess für dieselbe Dauer rechnen und übergibt die CPU dann an den nächsten Prozess.
* Priority Scheduling: Die Prozesse sind nicht gleichwertig (wie beim Round-Robin-Verfahren), sondern haben Prioritäten. Der Scheduler sorgt dafür, dass höher priorisierte Prozesse bevorzugt behandelt werden.

Soweit die "reine Lehre". Scheduler in freier Wildbahn implementieren oftmals komplizierte Hybriden der genannten Techniken. Jene der "echten" Betriebsysteme (Windows, Linux, MacOS, *BSD) sind im Prinzip prioritäten-basierte Round-Robin-Scheduler. Generell hat ein Betriebssystem zwei Möglichkeiten, Multitasking zu realisieren: kooperativ oder präemptiv.

== Kooperatives Multitasking ==

Beim kooperativen Multitasking gibt der Scheduler die Kontrolle komplett an den Prozess ab. Als Konsequenz davon ist das Betriebssystem darauf angewiesen, dass der Prozess seinerseits die Kontrolle "freiwillig" wieder zurückgibt. Geschieht das nicht, wird der Scheduler nicht wieder aufgerufen und damit auch kein anderer Prozess mehr ausgeführt - das System "hängt". Das Betriebssystem ist also auf die [http://de.wikipedia.org/wiki/Kooperation Kooperation] der Prozesse angewiesen. Bekannte Beispiele für Betriebssysteme mit kooperativem Multitasking sind Windows 3.x und MacOS vor Version 10.

Dennoch ist kooperatives Multitasking keineswegs überholt oder schlecht. Gerade im Bereich der Mikrocontroller und Echtzeitanwendungen gibt es viele gute Argumente dafür: Kooperatives Multitasking ist deterministischer, also besser zeitlich und logisch vorhersagbar. Es ist besser simulierbar, d. h. für ein gegebenes System ist leichter nachweisbar, dass es funktioniert. Da es sich um geschlossene Systeme handelt, tritt das Problem, dass "irgendein" Prozess das System anhält, nicht auf. Es laufen ja im Gegensatz zum PC nicht "irgendwelche" Prozesse, sondern nur die, deren Korrektheit (im Idealfall) verifiziert und validiert wurde.

=== Ein einfaches Beispiel für den AVR ===

Hier soll ein einfaches Beispiel den Weg in die Programmierung von parallel bearbeiteten Aufgaben zeigen.

Wichtigster Grundsatz ist die Herangehensweise! Viele Programmieranfänger haben damit Schwierigkeiten, was unter anderem an den schlecht vermittelten Grundlagen liegt. Oft sieht man Funktionen zum Warten in Form von

<syntaxhighlight lang="c">
while(1) {
PORTD ^= (1<<PD0);
_delay_ms(500);
}
</syntaxhighlight>

um beispielsweise eine [[LED]] blinken zu lassen. Will man dann noch andere Dinge erledigen, wundert sich der Programmierer, warum der Mikrocontroller so langsam reagiert, trotz 16 MHz Taktfrequenz.

==== Einfacher Ansatz ====

Stellen wir uns vor, wir wollen drei Dinge gleichzeitig tun.

* Eine Taste abfragen
* Eine LED blinken lassen, in Abhängigkeit der gedrückten Taste
* Daten vom UART empfangen und zum PC zurücksenden

Ein einfacher Ansatz für die drei Dinge sieht etwa so aus. Die Beispiele wurden mit [[WinAVR]] Version 20081006 in der Optimierungsstufe -Os kompiliert.

<syntaxhighlight lang="c">
/*

Multitasking Demo, erster Versuch

ATmega32 @ 3,6864 MHz

LED + 1KOhm Vorwiderstand an PB0
Taster nach GND an PA0
UART an RXD und TXD

*/

#define F_CPU 3686400
// Baudrate, das L am Ende ist wichtig, NICHT UL verwenden!
#define BAUD 9600L

#include "avr/io.h"
#include "util/delay.h"

// Berechnungen
// clever runden
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1)
// Reale Baudrate
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))
// Fehler in Promille
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD-1000)

#if ((BAUD_ERROR>10) || (BAUD_ERROR<-10))
#error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch!
#endif

uint8_t taste_lesen(void) {
if (PINA & (1<<PA0))
return 1;
else
return 0;
}

void led_blinken(uint8_t taste) {

PORTB ^= (1<<PB0);
if (taste)
_delay_ms(1000); // 1 s warten
else
_delay_ms(100); // 0,1 s warten
}

void uart_lesen(void) {
uint8_t tmp;
while (!(UCSRA & (1<<RXC))); // Warte auf empfangenes Zeichen vom UART
tmp = UDR;
while (!(UCSRA & (1<<UDRE))); // Warte auf freien Sendepuffer vom UART
UDR = tmp;
}

int main(void) {
int8_t taste;

// IOs initialisieren

PORTA = 1; // Pull Up für PA0
DDRB = 1; // PC0 ist Ausgang

// UART initialisieren

UBRRH = UBRR_VAL >> 8;
UBRRL = UBRR_VAL & 0xFF;
UCSRB = (1<<RXEN) | (1<<TXEN);

// Endlose Hauptschleife

while (1) {
taste = taste_lesen();
led_blinken(taste);
uart_lesen();
}
}
</syntaxhighlight>

Wenn man das Programm nun laufen lässt, wird man feststellen dass

* das Hyperterminal sehr langsam reagiert und bisweilen Zeichen verschluckt
* die LED auf Tastendrücke nur dann reagiert, wenn man per Hyperterminal Zeichen eingibt

Dieser Ansatz ist also untauglich. Egal wie schnell unser AVR auch ist, er reagiert sehr langsam.

==== Verbesserter Ansatz ====

Will man mehrere Dinge gleichzeitig bearbeiten, muss man die Aufgaben in kleinste Häppchen zerteilen. Diese kleinsten Häppchen werden dann verschachtelt abgearbeitet, also ein Häppchen von Aufgabe A, ein Häppchen von Aufgabe B, ein Häppchen von Aufgabe C.

Das Auslesen der Taste geht immer sehr schnell, kein Ansatz zum optimieren. Das Blinken der LED dauer entweder 1s oder 100ms, eine Ewigkeit für einen Mikrocontroller! Hier muss man was ändern. Am schlimmsten ist die UART-Nutzung. Der AVR wartet solange, bis ein Zeichen empfangen wurde! Das kann ewig dauern! Unser Programm steht! Das darf nicht sein!

<syntaxhighlight lang="c">
/*

Multitasking Demo, zweiter Versuch

ATmega32 @ 3,6468 MHz

LED + 1KOhm Vorwiderstand an PB0
Taster nach GND an PA0
UART an RXD und TXD

*/

#define F_CPU 3686400
// Baudrate, das L am Ende ist wichtig, NICHT UL verwenden!
#define BAUD 9600L

#include "avr/io.h"
#include "util/delay.h"

// Berechnungen
// clever runden
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1)
// Reale Baudrate
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))
// Fehler in Promille
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD-1000)

#if ((BAUD_ERROR>10) || (BAUD_ERROR<-10))
#error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch!
#endif

uint8_t taste_lesen(void) {
if (PINA & (1<<PA0))
return 1;
else
return 0;
}

void led_blinken(uint8_t taste) {
static uint16_t zaehler=0;

if (taste) {
if (zaehler>=999) {
PORTB ^= (1<<PB0);
zaehler=0;
}
}
else {
if (zaehler>=99) {
PORTB ^= (1<<PB0);
zaehler=0;
}
}

zaehler++;
}

void uart_lesen(void) {
uint8_t tmp;
if((UCSRA & (1<<RXC))) { // empfangenes Zeichen abholbereit im UART ?
tmp = UDR;
while (!(UCSRA & (1<<UDRE))); // Warte auf freien Sendepuffer vom UART
UDR = tmp;
}
}

int main(void) {
int8_t taste;

// IOs initialisieren

PORTA = 1; // Pull Up für PA0
DDRB = 1; // PB0 ist Ausgang

// UART initialisieren

UBRRH = UBRR_VAL >> 8;
UBRRL = UBRR_VAL & 0xFF;
UCSRB = (1<<RXEN) | (1<<TXEN);

// Endlose Hauptschleife

while (1) {
taste = taste_lesen();
led_blinken(taste);
uart_lesen();
_delay_ms(1); // 1 ms warten
}
}
</syntaxhighlight>

Dieses Programm reagiert '''ganz''' anders! Schnell wie der Wind und vollkommen unabhängig von anderen, parallel laufenden Prozessen. Warum ist das so?

Die einzelnen kleinen Häppchen sind verdaulicher als die großen. Die maximale Durchlaufzeit der einzelnen Funktionen ist drastisch reduziert. Anstatt in der LED-Ausgabe einmal 1000 ms zu warten wird nun 1000 mal 1 ms gewartet. Zwischendurch werden aber 1000 mal die anderen Prozesse bearbeitet. Echte Demokratie sozusagen. Noch viel besser ist die Handhabung des UARTs. Anstatt eine Ewigkeit auf ein ankommendes Zeichen zu warten, wird nur dann etwas bearbeitet, wenn auch wirklich etwas zur Bearbeitung vorliegt. Klingt eigentlich logisch. Also nur dann, wenn schon ein Zeichen empfangen wurde wird es auch bearbeitet, ansonsten geht es zurück zur Hauptschleife. Das ist praktisch der ganze "Trick" eines kooperativen Multitaskings. Auch wenn die Verwendung von _delay_ms(1) noch ein kleiner Schönheitsfehler ist, den die Profis lieber mit einem [[Timer]] erledigen, so wird das Prinzip klar.

*Prozesse eines kooperativen Multitaskingsystems warten nicht (lies: niemals) auf das Eintreten von Ereignissen, sondern bearbeiten nur bereits eingetretene Ereignisse.
*Größere Aufgaben werden in kleine Teilaufgaben zerlegt, welche nur durch mehrfaches Aufrufen der Funktion abgearbeitet werden. Das erreicht man meist am besten mit einer [[statemachine |State machine]].
*Prozesse eines kooperativen Multitaskings haben eine garantierte, maximale Durchlaufzeit, welche möglichst klein ist.

Damit ähneln die Prozesse einem [[Interrupt]], auch wenn sie als ganz normale Funktionen außerhalb eines Interrupts ausgeführt werden. An diesem Beispiel erkennt man die Vor- und Nachteile des kooperativen Multitaskings:

Vorteile
* einfacher Scheduler mit geringster CPU Belastung
* Deterministische Arbeitsweise, damit einfach prüfbar und strenges Timing möglich

Nachteile
* eine andere Programmierweise zur Zerlegung größerer Aufgaben in kleine Teilaufgaben muss manuell vorgenommen werden

==== Verbesserter Ansatz mit Timer ====

Zum Abschluss die noch bessere Version mit Timer. Diese hat mehrere Vorteile.

* Das Zeitraster der Hauptschleife ist exakt, unabhängig von der Laufzeit der Aufgaben, weil der Timer unabhängig eine feste Interruptfrequenz generiert. Im vorherigen Beispiel war das Zeitraster die Summe aus Laufzeit aller Funktionen/Tasks und dem _delay_ms(1).
* CPU-Rechenleistung wird zu 100% in der Abarbeitung der Task verwendet und nicht für nutzlose Warteschleifen verschwendet.
* Es kann leicht im realen System geprüft werden, ob die Laufzeit der Tasks klein genug ist, um den Anforderungen des Timers zu genügen.

Diese Überprüfung kann an zwei Stellen durchgeführt werden.

* Am Ende der Hauptschleife nach Abarbeitung aller Ausgaben. Wenn hier die Variable flag_1ms schon wieder aktiv ist, dauerte die Abarbeitung länger als 1ms. Wenn man ein sehr strenges Timing sicherstellen möchte, ist das ein Fehler, der erkannt und signalisiert werden kann.
* In der ISR. Wenn hier die Variable immer noch aktiv ist, wurde sie von der Hauptschleife noch nicht erkannt und zurück gesetzt. Das ist definitiv ein Fehler, denn jetzt würde ohne Fehlererkennung ein Timerdurchlauf von der Hauptschleife verschluckt werden. Diese Prüfung ist etwas nachgiebiger, weil zwischenzeitlich ein Durchlauf der Hauptschleife mehr als 1ms, jedoch nicht länger als 2ms dauern darf. Siehe auch den Abschnitt [[Interrupt#Zeitverhalten_eines_Timerinterrupts]]. Sinnvollerweise nutzt man nur eine der beiden Prüfungen, nicht beide zusammen.

<syntaxhighlight lang="c">
/*

Multitasking Demo, dritter Versuch

ATmega32 @ 3,6468 MHz

LED + 1KOhm Vorwiderstand an PB0 und PB1
Taster nach GND an PA0
UART an RXD und TXD

*/

#define F_CPU 3686400
// Baudrate, das L am Ende ist wichtig, NICHT UL verwenden!
#define BAUD 9600L

#include "avr/io.h"
#include "util/delay.h"
#include "avr/interrupt.h"

// Berechnungen
// clever runden
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1)
// Reale Baudrate
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))
// Fehler in Promille
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD-1000)

#if ((BAUD_ERROR>10) || (BAUD_ERROR<-10))
#error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch!
#endif

uint8_t taste_lesen(void) {
if (PINA & (1<<PA0))
return 1;
else
return 0;
}

void led_blinken(uint8_t taste) {
static uint16_t zaehler=0;

if (taste) {
if (zaehler>=999) {
PORTB ^= (1<<PB0);
zaehler=0;
}
}
else {
if (zaehler>=99) {
PORTB ^= (1<<PB0);
zaehler=0;
}
}

zaehler++;
}

void uart_lesen(void) {
uint8_t tmp;
if((UCSRA & (1<<RXC))) { // empfangenes Zeichen abholbereit im UART ?
tmp = UDR;
while (!(UCSRA & (1<<UDRE))); // Warte auf freien Sendepuffer vom UART
UDR = tmp;
}
}

volatile uint8_t flag_1ms;

int main(void) {
int8_t taste;

// IOs initialisieren

PORTA = 1; // Pull Up für PA0
DDRB = 3; // PB0/1 sind Ausgang

// UART initialisieren

UBRRH = UBRR_VAL >> 8;
UBRRL = UBRR_VAL & 0xFF;
UCSRB = (1<<RXEN) | (1<<TXEN);

// Timer 0 initialisieren, CTC, Presacler 64

TCCR0 = (1<<WGM01) | (1<<CS01) | (1<<CS00);
OCR0 = 56; // 1ms
TIMSK |= (1<<OCIE0);

// Interrupts global freigeben

sei();

// Endlose Hauptschleife

while (1) {
if (flag_1ms) {
flag_1ms=0;
taste = taste_lesen();
led_blinken(taste);
uart_lesen();
if (flag_1ms) {
// Laufzeit der Tasks >1ms, Fehlersignalisierung
// PB1 auf HIGH, Programm stoppen
PORTB |= (1<<PB1);
while(1);
}
}

}
}

// Interruptserviceroutine für Timer 0
// hier 1ms

ISR(TIMER0_COMP_vect) {
if (flag_1ms) {
// Laufzeit der Tasks >2ms, Fehlersignalisierung
// PB1 auf HIGH, Programm stoppen
PORTB |= (1<<PB1);
while(1);
}
flag_1ms = 1;
}

</syntaxhighlight>

==== Message passing Framework ====

Im vorangegangenen Abschnitt wird erklärt, wie man die einzelnen Tasks in kleine "Häppchen" zerlegen kann und diese alle innerhalb der Main Loop aufruft.
Dieses kooperative System hat aber noch einige Nachteile:

* Alle Häppchen werden gleich oft aufgerufen und nicht nur bei Bedarf
* Für die Timeouts gibt es noch keine befriedigende Lösung

Wenn man diese beiden Nachteile auch noch beseitigen möchte, wird das ganze noch ein klein wenig komplizierter. Da man das Grundprinzip aber für viele Mikrocontroller-Projekte immer wieder verwenden kann, lohnt es sich und man kann die Entwicklung für diese Art des Multitasking in einem Framework zusammenfassen.

Ein Framework, das sind einige Dateien, die den Rahmen (Frame=Rahmen) für ein Programm bilden und den Teil enthalten, den man immer wieder braucht.

===== Message =====

Die Basis des Frameworks bildet die "Message". Immer wenn wir für einen unserer "Tasks" etwas zu tun haben, schicken wir eine "Message". Die "Messages" werden in eine Warteschlange einsortiert und der Reihe nach abgearbeitet. Dadurch kommt ein Task der viel zu tun hat (viele Messages bekommt) öfter dran, als ein "Task" der nicht so viel zu tun hat. Außerdem kann eine Message noch Daten enthalten (z. B. ein empfangenes Zeichen). So können die einzelnen Tasks sogar Daten austauschen.

===== Message Receiver =====

Unsere "Tasks" werden immer dann aufgerufen, wenn Arbeit für sie da ist. Das wissen wir, weil sie eine Message empfangen sollen. Deshalb heißen die "Tasks" ab jetzt "Message Receiver"

===== Timeout =====

In diesem System wird jeder Message Receiver aufgerufen, wenn jemand Arbeit für ihn hat und er deshalb eine Message bekommt. Was aber, wenn keine Message kommt, oder ein Message Receiver selbst aktiv werden soll?

Aus diesem Grund braucht es die Timeouts. Mit Hilfe eines Hardware Timers wird eine "Systemzeit" programmiert. Jeder Message Receiver kann die Zeit angeben, wann er wieder aufgerufen werden muss. Das Framework verwaltet alle Timer und sendet den Message Receivern eine "Timeout" message, wenn ihre Zeit gekommen ist.

===== Beispiel =====
Hier der Sourcecode eines solchen Framework [[Datei:ACF.zip]]
Das Framework implementiert die Message Warteschlange und die Timer Warteschlange. Die Prozessor spezifischen Dinge sind in der Datei "ACF_Hal.c" zusammengefasst und für Linux Desktop und atMega128 implementiert.
In dieser Datei kann man das ganze auch auf andere Prozessoren anpassen.

Ein "main" sieht dann z.B. so aus:

<syntaxhighlight lang="c">
#include "ACF.h"

int main(int argc, char** argv)
{
ACF_init();
ACF_loop();
return 0; // we will never arrive here
}
</syntaxhighlight>

===== Tracing =====
Es gibt noch einen weiteren Grund, sich ein "Framework" zu erarbeiten, oder ein fertiges Framework zu verwenden. Da der Ablauf der Software und der Aufruf aller Teile vom Framework bestimmt wird, kann das Framework auch einen sehr detaillierten Trace über das Verhalten des Codes anfertigen. Das Framework aus vorstehendem Beispiel enthält bereits entsprechenden Code.

Solche Traces von laufendem Code können gerade dann sehr hilfreich sein, wenn viele Dinge gleichzeitig ablaufen (und das war schließlich der Sinn des ganzen).

Nachstehendes Bild zeigt den Trace eines Reglers, der mit dem Framework realisiert wurde.
[http://www.mikrocontroller.net/attachment/74409/ablauf.png Sequenzdiagramm]

== Präemptives Multitasking ==

Beim präemptiven Multitasking gibt das OS die Kontrolle zu keinem Zeitpunkt auf. Ein Prozess, der gerade die CPU nutzt, kann jederzeit wieder vom Betriebssystem unterbrochen werden. Daher muss bei der Entwicklung für ein präemptives System immer damit gerechnet werden, dass ein Prozess '''jederzeit''' unterbrochen werden kann. Das kann z. B. zu Problemen beim Zugriff auf limitierte Betriebsmittel führen. Beispiel:

* Prozess A sucht freien Speicher und findet einen freien Block
* Prozess B wird vom Scheduler gestartet und sucht ebenfalls einen Speicherblock. Der gefundene Block wird von Prozess B reserviert und benutzt
* Der Scheduler teilt wieder Prozess A die CPU zu. Prozess A wird fortgeführt, d.h. er reserviert jetzt den im letzten Systemcall gefundenen Speicherblock
Jetzt haben also beide Prozesse den gleichen Speicherblock reserviert. Entweder arbeiten jetzt beide Prozesse mit dem gleichen Speicher, und überschreiben daher gegenseitig die Daten, oder das Betriebsystem hat etwas gemerkt und zieht die Notbremse. In jedem Fall passieren schreckliche Dinge. Sowas nennt man eine Race-Condition.

Die Lösung nennt sich Semaphore: Dieser Mechanismus wird vom Betriebsystem bereitgestellt und erlaubt es einem Prozess eine bestimmte Ressource zu sperren. Wenn also Prozess A aus obigem Beispiel Speicher haben möchte, setzt er vor Beginn der sogenannten "Kritischen Sektion" einen Semaphor für "Speicher reservieren". Dieser Semaphor wird erst wieder aufgehoben, sobald Prozess A den Speicher für sich reserviert hat. Wenn der Prozess B zwischendurch gestartet wird und ebenfalls versucht den Semaphor zu setzen, wird er solange warten müssen, bis Prozess A den Semaphor wieder freigibt. Speziell für derartige Locking Mechanismen bieten die meisten Prozessoren sogenannte TAS-Befehle (Test And Set), die in einem Prozessorbefehl eine Variable testen und je nach Ergebnis setzen können. Das ist nötig um das Setzen von Semaphoren unteilbar (atomar) zu machen. Könnte der Scheduler das Setzen eines Semaphors unterbrechen, wäre ja der ganze Aufwand umsonst.

Präemptive Multitasking Systeme sind sehr flexibel und kommen mit einer Vielzahl an Tasks klar. Amok laufende Prozesse können das System bei korrekter Implementierung nicht blockieren. Damit aber das System crash-sicher ist, muss es Systemresourcen geben, die nur der Scheduler verteilen kann (z. B. kein anderer Prozess darf in den Speicherbereich des Schedulers schreiben; kein anderer Prozess darf den Timerinterrupt des Schedulers ändern). Diese Möglichkeiten sind in Mikrocontrollern normalerweise gar nicht vorhanden, wodurch dieser Vorteil des Präemptiven MT weniger ins Gewicht fällt. Beispiele für Systeme mit präemptivem Multitasking sind Linux, *BSD und Windows XP.

Vorteile
* sehr flexibel in der Verwaltung von dynamisch ausgeführten Prozessen
* einzelne Prozesse können einfach linear programmiert werden, ohne die Aufgabe in kleine Teile zerlegen zu müssen

Nachteile
* Der Scheduler ist aufwändiger und benötigt mehr CPU-Zeit
* Höherer Resourcenbedarf zu Verwaltung des Systems und Bereitstellung der Semaphore etc.
* nicht streng deterministisch, somit kann kein festes Timing garantiert werden
* nicht explizit debug- und prüfbar, da die Prozesse nicht fest gekoppelt sind

== Multithreading ==

Multithreading ist eine meist softwarebasierende Möglichkeit moderner Betriebssysteme, innerhalb eines Prozesses mehrere Tasks (threads) parallel auszuführen. Der Vorteil dieser weiteren Unterteilung ist, dass sich die Threads eines Tasks den Speicherbereich teilen können und eine Aufteilung in logische nebeneinander laufende Teile möglich ist. Je nach Betriebssystem kann der Übergang von Multithreading zu Multiprocessing fliessend bis starr sein.

Das Hyperthreading eines Intel Pentium 4 folgt dem Konzept des Multithreadings auf Hardwarebasis und teilt den CPU-Kern zeitlich in zwei logische Prozessoren ein.

== Umsetzung auf Prozessoren ==
Unabhängig davon, ob Multitasking oder -threading auf einem Prozessor konkret unterstützt wird, lässt es sich immer in Form von Software realisieren. Dies wird in modernen Systemen durch das OS geleistet, das standardisierte Funktionen und Strukturen zur Verfügung stellt. Besonders C++ bietet ein stark abstrahiertes Programmiermodell und Methoden-Set an, um effektiv untereinander kompatible Programmmodule erstellen zu können. Nutzt man diese nicht, wie z.B. bei der Programmierung in C, müssen Strukturen manuell erzeugt und gehandhabt werden, was aufwändiger ist, aber auch geringeren overhead bewirkt. Das Programm ist dann fast immer erheblich kleiner, in den meisten Fällen strukturell einfacher, bezüglich komplizierter Änderungen jedoch auch unflexibler und träger.

Bei Mikrocontrollern findet man je nach Komplexität und Struktur der Appliation praktisch alle denkbaren Kombinationen:

=== System mit real-time OS und Entwicklung in C++ ===
* Programmentwicklung stark an abstrakte Interfaces und Standards gebunden
* Starke Abängigkeit an das OS im Bezug auf RT-Funktionalität
* Innerhalb gleicher OS-Landschaft gut portierbar
* Sehr geringe Abhängigkeit vom Prozessortyp
* Multitasking muss über OS-Schicht ausprogrammiert werden
* Multithreading muss/kann durch Programmierleistung optimiert werden
* Laufzeiteffizienz ist niedrig durch relativ hohen Anteil des OS-Bedarfs
* Datendurchsatz regelt sich selbst und ist gleichmässig am relativen Maximum
* Programmiereffizienz ist niedrig durch sehr viel Arbeit an Formalismen
* Planungsaufwand ist noch überschaubar
* Planungseffizienz ist relaiv hoch durch viele Standards
* Erweiterung um komplexe Module einfach möglich, Timing regelt sich selber

=== System mit real-time OS und Entwicklung in C ===
* Programmentwicklung stark an Interfaces und weniger an Standards
* Starke Abängigkeit an das OS im Bezug auf RT-Funktionalität
* Innerhalb aber auch ausserhalb gleicher OS-Landschaft gut portierbar
* Geringe Abhängig von dem Prozessortyp
* Multitasking muss über OS-Schicht und eigene Strukturen programmiert werden
* Multithreading muss/kann durch Programmierleistung optimiert werden
* Laufzeiteffizienz ist höher durch geringeren Anteil des OS-Bedarfs
* Datendurchsatz regelt sich selbst und ist gleichmässig am relativen Maximum
* Programmiereffizienz ist höher durch weniger Arbeit mit Formalien
* Planungsaufwand ist etwas höher, je nach Applikation
* Planungseffizienz ist relaiv niedriger durch weniger Standards
* Erweiterung mit akzeptablem Aufwand möglich, Timing muss beachtet werden

=== System ohne real-time OS und Entwicklung in C ===
* Programmentwicklung stark an Interfaces und kaum an Standards gebunden
* Ausprägung und Gestaltung der RT-Funktionalität absolut frei
* nur ausserhalb von OS-Landschaft portierbar, dafür prinziepiell sehr gut
* Stärkere Abhängig von dem Prozessortyp, kann die Portierbarkeit einschränken
* Multitasking muss auschlieslich durch eigene Strukturen programmiert werden
* Multithreading muss durch umständliche Programmierung ermöglicht werden werden
* Laufzeiteffizienz kann sehr hoch sein, ist aber stark von der Progr. abhängig
* Datendurchsatz muss selbst ins Maximum gesteuert werden, das aber höher liegt
* Programmiereffizienz ist hoch, dank Wegfall von Konventionen
* Planungsaufwand ist stark Applikations abhängig, gfs sehr viel grösser
* Planungseffizienz ist gering, da RT Konzept selber optmiert werden muss
* Erweiterung nur möglich, wenn Timing weitestgehend überarbeitet wird

=== System ohne real-time OS und Entwicklung in ASM ===
* Programmentw. nur an physische Interfaces gebunden und frei von Standards
* Ausprägung und Gestaltung der RT-Funktionalität absolut frei
* nur innerhalb der Prozessorlandschaft gut portierbar
* Volle Abhängig vom Prozessortyp, Portierbarkeit auf andere aufwändig
* Multitasking muss auschlieslich durch eigene Strukturen programmiert werden
* Multithreading muss durch umständliche Programmierung ermöglicht werden werden
* Laufzeiteffizienz sehr hoch, jedoch stark von Programmierung abhängig
* Datendurchsatz muss selbst ins Maximum gesteuert werden, das aber höher liegt
* Programmiereffizienz ist hoch, dank Wegfall von Konventionen
* Planungsaufwand ist stark applikationsabhängig, ggfs. sehr viel grösser
* Planungseffizienz sehr gering, RT Konzept nur für einfache System machbar
* Erweiterung nur möglich, wenn Timing komplett überarbeitet wird

== Weblinks ==

* [http://de.wikipedia.org/wiki/Pr%E4emptives_Multitasking Präemptives Multitasking] bei [http://de.wikipedia.org Wikipedia]
* [http://www.femtoos.org/ Femto OS], ein ultrakompaktes Mulitaskingbetriebssystem für kleine Mikrocontroller
*[http://www.freertos.org/ FreeRTOS], ein freies Echtzeitbetriebssystem für Mikrocontroller
* [http://w3.ualg.pt/~rmarcel/Get%20by%20Without%20an%20RTOS.pdf Get by Without an RTOS] Ein schönes Beispiel wie man ohne ein RTOS auch Multitasking hinbekommt.
* [[TNKernel]], freier Multitasking-Kernel.
* [http://embeddedgurus.com/state-space/2010/04/i-hate-rtoses/ i-hate-rtoses] Blog zum Thema RTOS

[[Kategorie:Betriebssysteme]]

Stromversorgung für FPGAs

2014-10-04T16:51:55Z

Maybee: /* Der klassische Ansatz */

In diesem Artikel soll eine kurze Erklärung zum Entwurfsproblem von Stromversorgungen für Hochleistungs-[[FPGA]]s gegeben werden. Ein neuer Ansatz zur Messung des Frequenzgangs wird dargestellt und praktische Messergebnisse werden gezeigt.

FPGAs werden immer mehr Bestandteil moderner Elektronik. Die Bausteine werden größer, schneller und leistungsstärker mit jedem Tag. Und so steigt auch die Leistungsaufnahme. Obwohl die Leistung pro Gatter sich durch bessere Technologie und kleinere Geometrien verringert, steigt die Taktfrequenz und die Anzahl der Gatter pro Bauteil. Mit steigender Schaltgeschwindigkeit wird die Stromversorgung zu einem kritischen Teil im Systementwurf. Das Stromversorgungsnetz muss eine Quelle mit niedriger Impedanz über einen sehr weiten Frequenzbereich sein. Anderenfalls könnnen Überschwinger, Spannungsabfall oder Störpulse auf VCC/GND die Funktion des FPGAs stören, welche durch den schnell wechselnden Leistungsbedarf des FPGAs verursacht wird.

== Breitbandentkopplung ist Teamwork ==

Der Spannungsregler muss die Gleichstromkomponente für das Stromversorgungsnetzwerk liefern. Bei maximaler Leistung und Umgebungstemperatur muss er immer noch sauber funktionieren ohne zu überhitzen, Spannungseinbrüche etc. Seine Aufgabe ist es, auf niederfrequente Lastsprünge zu reagieren (ca. 0..30kHz).

Im mittleren Frequenzbereich kann der Spannungsregler nicht mehr reagieren, er ist zu langsam. Der Strom muss dann von großen Elektrolytkondensatoren geliefert werden. Diese Kondensatoren können bis einige MHz Strom liefern, danach begrenzen der parasitäre Widerstand (ESR, engl. effective series resistance) bzw. die parasitäre Induktivität (ESL, engl. effective series inductance) die Stromlieferfähigkeit des Kondensators und machen ihn irgendwann bei höheren Frequenzen nutzlos.

Jetzt kommt die Zeit der kleinen Keramikkondensatoren, typisch 10 oder 100nF. Sie gibt es in kleinen [[SMD]]-Gehäusen wie 0603 und kleiner mit sehr wenig parasitärer Induktivität. Sie können Strom bis einige hundert MHz liefern und sind damit eine niederohmige Quelle für Hochfrequenzströme.

Aber für die '''wirklich''' schnell schaltenden ICs sind auch diese Keramikkondensatoren nicht ausreichend, um das Stromversorgungsnetzwerk ausreichend zu entkoppeln. Hier braucht man die Kapazität der Stromversorgungsflächen, welche duch VCC- und Masseflächen in mehrlagigen Platinen gebildet wird. Um ein Maximum an Kapazität zu erreichen sollte ein dünnes Dielektrikum mit einer hohen Dielektrizitätskonstante und niedrigen Verlusten benutzen. Außerdem sollte man ein VIA für jedes VCC/GND Pin benutzen, um die parasitären Induktivitäten zu minimieren, nicht ein VIA für mehrere Pins! [[IC-Gehäuseformen#BGA | BGA-Gehäuse]] bieten zusätzlich kürzere Verbindungen vom eigentlichen IC zur Platine, sie sind aber schwieriger zu handhaben (Layout und [[SMD Löten | Löten]]).

== Der klassische Ansatz ==

Es gibt viele Theorien und Application Notes zum Thema Entkopplung von Stromversorgungen. Einige nehmen einfach die Brechstange und bauen einen Friedhof für unzählige Kondensatoren, andere sind schlauer. Es gibt auch sehr viele Simulationen zu dem Thema. Aber am Ende sind die Eigenschaften des Stromversorgungsnetzes definiert duch das Zusammenspiel von

* dem FPGA und dessen Leistungsaufnahme, welche von der Schaltfrequenz abhängt
* dem Layout der Platine mit der Platzierung der verschiedenen Kondensatoren

Eine Möglichkeit zur Messung der Qualität des Stromversorgungsnetzwerkes ist die Nutzung eines Netzwerkanalysators. Dafür benötigt man eine Platine, welche nur mit den passiven Komponenten bestückt ist. Dabei wird ein Testsignal in das Netzwerk eingespeist (meist an Stelle des Spannungsreglers) und an einer anderen Stelle gemessen (meist an Stelle der ICs). Der Netzwerkanalysator variiert dann die Frequenz und zeichnet eine Kurve des Widerstands über die Frequenz auf. Diese Methode hat einige Nachteile.

*Man braucht einen teuren Netzwerkanalysator
*Man benötigt eine zusätzliches Board, welches nur mit den Kondensatoren bestückt ist, welches nicht immer verfügbar ist
*Die Messung spiegelt nicht die wahren Bedingungen wieder, weil alle ICs und aktiven Teile fehlen. Ausserdem sind nur Punkt zu Punkt Messungen möglich, welche das reale Verhalten nicht korrekt wiedergeben.

Die Methode in diesem Artikel versucht, die meisten Nachteile zu vermeiden.

== Ein direkter Ansatz ==

Da wir hier über FPGAs reden, haben wir die Möglichkeit, '''jede''' beliebige digitale Funktion hineinzuprogrammieren. Also sollten wir eine digitale Funktion entwerfen, welche dem schlimmstmöglichen Fall der Belastung der Stromversorgung entspricht. Aus der Theorie der linearen Netzwerke wissen wir, dass der Frequenzgang eines linearen Systems aus der Sprungantwort am Eingang und der Reaktion am Ausgang gemessen werden kann. Für das Stromversorgungsnetzwerk funktioniert das sogar wenn es nicht vollständig linear ist, da wir ja die reale Reaktion auf konstante Last und Lastsprünge messen wollen. Was ist nun der schlimmste Belastungsfall für die Stromversorgung? Da fast alle ICs auf CMOS-Technologie beruhen, wird die meiste Leistung umgesetzt, wenn Signalnetze ihren Pegel wechseln. Bei einem FPGA heißt das, dass alle [[FlipFlop]]s ihren Pegel gleichzeitig wechseln und dabei große Signalnetze treiben (parasitäre Kapazität). Also entwerfen wir die folgende Schaltung.

[[bild:Schematic.gif|thumb|left|600px|Logik für Lasttest]]
{{clear}}

Der Kern besteht aus einer Matrix aus 30x50 FlipFlops, wobei jeweils 50 FlipFlops aus einem Puffer-FlipFlop gespeist werden, um die Ausgangslast relativ niedrig zu halten und damit eine hohe Taktfrequenz zu erreichen. Um etwas kombinatorische Logik zu erzeugen und um die HDL Compiler davon abzuhalten, die FlipFlops wegzuoptimieren, verbinden wir alle FlipFlops über ein gigantisches ODER-Gatter und leiten den Ausgang auf ein IO-Pad. Dieser Ausgang wird aber nicht weiter genutzt. Dann haben wir noch einen 16-Bit Zähler und etwas Steuerlogik, welche das Toggle-FlipFlop gemäß folgender Tabelle steuert.

{| class="wikitable"
|+ '''Steuerung der Testlogik'''
|-
! sel<1> || sel<0> || Modus
|-
| 0 || 0 || inaktiv
|-
| 0 || 1 || konstante Umschaltung
|-
| 1 || 0 || Burstbetrieb
|}

== VHDL Code ==

Wenn der Code synthetisiert wird, muss die Option "remove duplicate registers" in der Synthesesoftware ausgeschaltet werden. Es sollten zwei Dateien angelegt werden, top.vhd und row.vhd.

Datei top.vhd

<syntaxhighlight lang="vhdl">
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity power is
Port ( clk_in : in std_logic; -- clock input
sel : in std_logic_vector(1 downto 0); -- select modulation ON/OFF
gnd : out std_logic_vector(5 downto 0); -- artificial gnd
mod_out : out std_logic; -- modulation signal
reset : in std_logic; -- reset for DLL
dummy : out std_logic); -- dummy out, to fool the synthesizer

end power;

architecture Behavioral of power is

COMPONENT row
PORT(
clk : IN std_logic;
data : IN std_logic;
dout : OUT std_logic
);
END COMPONENT;

-- DLL (Delay Locked Loop), a Virtex primitive

component CLKDLL
port (
CLKIN : in std_logic;
CLKFB : in std_logic;
RST : in std_logic;
CLK0 : out std_logic;
CLK90 : out std_logic;
CLK180 : out std_logic;
CLK270 : out std_logic;
CLK2X : out std_logic;
CLKDV : out std_logic;
LOCKED : out std_logic);
end component;

-- BUFG (Global Clock buffer), a Virtex primitive

component BUFG
port ( I : in std_logic;
O : out std_logic);
end component;

-- IBUFG (Global Clock input buffer ), aa Virtex primitive

component IBUFG
port ( I : in std_logic;
O : out std_logic);
end component;

component SRL16 -- virtex primitive
port (
D : in std_logic;
CLK : in std_logic;
A0 : in std_logic;
A1 : in std_logic;
A2 : in std_logic;
A3 : in std_logic;
Q : out std_logic
);
end component;

constant rows: integer:=30;

type flop_array is array (rows-1 downto 0) of std_logic_vector(49 downto 0);

signal toggle : std_logic; -- a toggle flipflop
signal ff_ar : flop_array;
signal drive_ar : std_logic_vector (rows-1 downto 0); -- driver array for toggeling rows
signal dout_ar : std_logic_vector (rows-1 downto 0); -- driver array for toggeling rows
signal or_ar : std_logic_vector (rows-1 downto 0); -- driver array for toggeling rows
signal cnt : std_logic_vector (15 downto 0); -- modulation divider

signal CLKIN_w, RESET_w, CLK2X_dll, CLK2X_g, CLK4X_dll, CLK4X_g, CLK8X_dll, CLK8X_g: std_logic;
signal LOCKED2X, LOCKED2X_delay, RESET4X, RESET8X, LOCKED4X, LOCKED4X_delay, LOCKED8X : std_logic;

signal logic1,clk : std_logic;

signal clk2x,clk4x,clk8x, clkmux: std_logic;

begin

-- use two DLL to get 147 MHz

logic1<='1';

clkpad : IBUFG port map (I=>CLK_IN, O=>CLKIN_w);

dll2x : CLKDLL port map (CLKIN=>CLKIN_w, CLKFB=>CLK2X_g, RST=>RESET,
CLK0=>open, CLK90=>open, CLK180=>open, CLK270=>open,
CLK2X=>CLK2X_dll, CLKDV=>open, LOCKED=>LOCKED2X);

clk2xg : BUFG port map (I=>CLK2X_dll, O=>CLK2X_g);

rstsrl : SRL16 port map (D=>LOCKED2X, CLK=>CLK2X_g, Q=>LOCKED2X_delay,
A3=>logic1, A2=>logic1, A1=>logic1, A0=>logic1);

RESET4X <= not LOCKED2X_delay;

dll4x : CLKDLL port map (CLKIN=>CLK2X_g, CLKFB=>CLK4X_g, RST=>RESET4X,
CLK0=>open, CLK90=>open, CLK180=>open, CLK270=>open,
CLK2X=>CLK4X_dll, CLKDV=>open, LOCKED=>LOCKED4X);

clk4xg : BUFG port map (I=>CLK4X_dll, O=>CLK4X_g);

clk<=clk4x_g;

-- the toggeling array

l_rows: for i in 0 to rows-1 generate
Inst_row: row PORT MAP(
clk => clk,
data => drive_ar(i),
dout => dout_ar(i)
);
end generate;

-- combine all douts via a BIG or-gate

process(dout_ar)
variable tmp: std_logic;
begin
tmp:='0';
l_or: for i in 0 to rows-1 loop
tmp:=tmp or dout_ar(i);
end loop;
dummy<=tmp;
end process;

-- prescaler

process(clk)
begin
if clk='1' and clk'event then
cnt<=cnt+1;
end if;
end process;

-- toggle fliplop and distribution

process(clk)
begin
if clk='1' and clk'event then
case sel is
when "00" => toggle <= '0';
when "01" => toggle <= not toggle;
when "10" => if cnt(15)='1' then toggle <= not toggle; else toggle<='0'; end if;
when others => null;
end case;
drive_ar<=(others=>toggle);
end if;
end process;

gnd<=(others=>'0');
mod_out<=cnt(15);

end Behavioral;
</syntaxhighlight>

Datei row.vhd

<syntaxhighlight lang="vhdl">
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity row is
Port ( clk : in std_logic;
data : in std_logic;
dout : out std_logic);
end row;

architecture Behavioral of row is

signal my_array: std_logic_vector (49 downto 0);

begin

-- generate 50 FFs with clock enable

process (clk)
begin
if clk='1' and clK'event then
my_array<=(others=>data);
end if;
end process;

-- combine all into a BIG OR

process(my_array)
variable tmp: std_logic;
begin
tmp:='0';
l: for i in 0 to 49 loop
tmp:=tmp or my_array(i);
end loop;
dout<=tmp;
end process;

end Behavioral;
</syntaxhighlight>

== Messungen ==

[[bild:Term1.gif|thumb|right|220px|Terminierung 1: 50Ω vor dem Koppelkondensator, fg = 10 Hz]]
[[bild:Term2.gif|thumb|right|220px|Terminierung 2: 50Ω nach dem Koppelkondensator, fg = 200 kHz]]

Die nachfolgenden Messungen wurden mit einem Spartan-II Demoboard von Insight Electronics durchgeführt. Es ist mit einem XC2S100-5 im PQ208 Gehäuse bestückt. Es nutzt eine Kernspannung von 2,5V und eine IO-Spannung von 3,3V. Beide Spannungen werden durch Linearregler geliefert. Ein 36.864 MHz Oszillator wurde hinzugefügt. Für die Messung wurde der Takt mittels DLL vervierfacht auf 147 MHz. Diese hohe Frequenz wurde gewählt, um die Effekte gut demonstrieren zu können. In einer praktischen Anwendung wird man diesen Test nur mit der normalen Frequenz betreiben, welche auch in der realen Anwendung genutzt wird. Das Board wird durch ein starkes Netzteil versorgt.

Die Kernspannung wird mit einem Stück Koaxialkabel vom Typ RG 174 gemessen, welches direkt an ein VCC/GND-Pin des FPGAs angelötet ist. Das [[Oszilloskop]] ist auf 50Ω Eingangsimpedanz mit AC-Kopplung geschaltet. Wir sind nicht an der absoluten Größe der Versorgungsspannung interessiert sind, nur an Wechselanteilen, welche hoffentlich deutlich kleiner sind. Mit AC-Kopplung kann man einen deutlich kleineren Messbereich für die vertikale Auflösung verwenden. Dieser Aufbau hat eine gute Abschirmung gegen Störungen und eine sehr hohe Bandbreite zur Messung der hochfrequenten Störungen.

Während der Messung wurde festgestellt, dass es zwei verschiedene [[Wellenwiderstand | Terminierungsmethoden]] in Oszilloskopen gibt. Das alte Tektronix CSA 404 mit einem 11A34 Verstärker nutzt Terminierung 1 am 50Ω Eingang. Daraus ergibt sich eine untere Grenzfrequenz des Hochpasses von ~10 Hz. Das zweite Oszilloskop, ein Tektronix TDS 3034, mit welchem die Screenshots gemacht wurden, nutz Terminierung 2, welche in einer unteren Grenzfrequenz von ~200 kHz resultiert. Das ist nicht akzeptabel für die Messung der Sprungantwort, weswegen die 1 MΩ Eingangsterminierung benutzt wurde. Das ist OK für die Messung niedriger Frequenzen (<10 MHz). Zur Messung der Hochfrequenzstörungen (Messung 4) ist die Grenzfrequenz von 200 kHz kein Problem.
{{Absatz}}

== Messung 1 - FPGA unkonfiguriert ==

Bei diesem Schritt können wir die Leistungsaufnahme in Ruhezustand messen, welche größtenteils durch Leckströme verursacht wird. Zu beachten ist auch, dass unser Oszilloskop mit Eingangsschaltung 1 viel Strom zieht (50Ω @ 2,5V = 50mA). Wir können mittles Multimeter messen, ob unsere Spannungsregler die korrekte Spannung liefern. Wir schreiben den aktuellen Stromverbrauch und Kernspannung auf. Dabei ist der Stromverbrauch der Eingangstermninierung nicht enthalten, weil für alle Messungen das zweite Oszilloskop mit Schaltung 2 verwendet wurde.

== Messung 2 - FPGA mit leerer Logik ==

Ein Design mit einer einfachen Schleife von einem Eingang auf einen Ausgang ist jetzt in das FPGA geladen. Nach der Konfiguration '''sinkt''' der Stromverbrauch, weil die Konfigurationslogik im FPGA abgeschaltet wurde, welche permanant den Konfigurationsspeicher löscht. Die Leistungsaufnahme dieser Minimalschaltung wird als Kalibrierungspunkt für alle nachfolgenden Messungen verwendet.

== Messung 3 - FPGA konfiguriert ohne schaltende Logik ==

Jetzt steigt die Leistungsaufnahme deutlich. Auf den ersten Blick ist das unerwartet, denn im FPGA werden keinerlei Signale geschaltet , die FlipFlips laden immer den gleichen Wert. Aber das ist nicht ganz korrekt. Das Taktnetzwerk läuft auf voller Leistung. Daran erkennt man, dass die Taktverteilung signifikant Leistung benötigt. Darum nutzen [[Ultra low power | stromsparende ICs]] eine saubere Methode zur [[Taktung FPGA/CPLD | Taktabschaltung (clock gating)]], um die Leitungsaufnahme zu verringern. Aber das muss auf sichere Weise erfolgen.

== Messung 4 - FPGA mit dauerhaft schaltenden Signalen ==

Jetzt starten wir ein Feurwerk! Die Stromversorgung erfährt jetzt ihren schlimmsten Albtraum. 1500 FlipFlops die gleichzeitig mit 147 MHz umschalten (togglen)
ist kein Kindergeburtstag! Schau auf den Strommesser! Das FPGA wird schnell sehr heiß. Aber was sehen wir auf dem Oszilloskop? Da die Stromaufnahme konstant ist, können wir nur Hochfrequenzstörungen durch die schaltende Logik sehen, welche durch unzureichende Entkopplung der Keramikkondensatoren verursacht werden könnte. Mit einem schnellen Oszilloskop (1GHz++) und schlechten Versorgungslagen und Keramikkondensatoren, könnte man die '''wirklich''' hochfrequenten Störungen sehen. Mit dem 1 GHz-Oszilloskop sieht man in diesem Fall aber nichts, eben weil die Kondensatoren und Stromversorgungslagen gut funktionieren. Mit langsameren Oszilloskopen (300MHz oder weniger) sieht man nur den Effekt der Kondensatoren. Hier können wir auch die Kernspannung unter Volllast messen. Aber man muss sicherstellen, die Spannung zu messen, welche wirklich am FPGA ankommt, d.h. man muss '''direkt''' an den Pins des FPGA messen, nicht irgendwo auf dem Board! Denn das Stromversorgungsnetz hat einen endlichen Widerstand, welcher einen Spannungsabfall vom Spannungsregler bis zum FPGA verursacht. In einem guten Entwurf sollte der Spannungsabfall kleiner als 1% der Nennspannung sein.

== Messung 5 - Burstbetrieb ==

Zum Schluß erreichen wir den interessantesten Punkt. Mit dem 16-Bit Zähler wird das Umschalten des FlipFlop-Arrays mit einer niedrigen Frequenz moduliert, die Modulationsfrequenz ist 1/65356 der Taktfrequenz, hier ~2,2 kHz. Das ist die Sprungfunktion, welche in den Abschnitten weiter oben genannt wurde. Und wir sehen die Reaktion des Stromversorgungsnetzes. Wenn es ideal wäre, würden wir nur eine gerade Linie auf dem Oszilloskop sehen. Aber da es numal keine Idealfälle gibt, sehen wir Überschwinger und einen verbleibenden Offset. Das nachfolgende Bild zeigt das deutlich. Der blaue Kanal ist das Modulationssignal des 16-Bit Zählers (MSB), der gelbe Kanal die Kernspannung.

<gallery widths="140">
bild:01.gif| Sprungantwort mit 10µF
bild:02.gif| Sprungantwort mit 110µF
bild:03.gif| Abschaltflanke 10µF
bild:04.gif| Abschaltflanke 110µF
bild:05.gif| Zoom, Abschaltflanke 110µF
bild:06.gif| Anschaltflanke 10µF
bild:07.gif| Anschaltflanke 110µF
bild:08.gif| Zoom, Anschaltflanke 110µF
</gallery>

== Erklärung ==

Der Unterschwinger beim Einschalten wird verursacht durch unzureichende Entkopplung im mittleren Frequenzbereich. Der sprunghaft steigende Stromverbrauch kann nicht von den Mittelfrequenzkondensatoren geliefert werden (zu wenig Kapazität), auch nicht vom Spannungsregler (er ist zu langsam dafür). Das originale Demoboard ist nur mit einem 10µF Tantalkondensator hinter dem Spannungsregler bestückt, welcher für so eine große Last viel zu klein ist. Durch Ergänzung eines 100µF Kondensatores kann der Unterschwinger deutlich verkleinert werden.

Der Überschwinger beim Abschalten ist ähnlich, aber hier ist der Spannungsregler ist zu langsam, den Ausgangsstrom herunterzuregeln. Der überschüssige Strom (Ladung) wird in den Mittelfrequenzkondensatoren gespeichert, aber da dieser nur 10µF hat, steigt die Spannung schnell an. Ein einfacher Vergleich. Es ist genauso wie wenn man mit einem kleinen Fass das Regenwasser von einem großen Dach auffangen will, das Faß füllt sich schnell.

Was verursacht den verbliebenden Offset? Nun, das ist der Gleichstromwiderstand des Stromversorgungsnetzwerks vom Spannungsregler (wo dieser die Ausgangsspanung misst und regelt) bis zum VCC-Pin des FPGAs. Die Stromaufnahme des FPGAs schwankt zwischen Messung 3 (kein Umschalten) und Messung 4 (konstantes Umschalten). Auf dem Oszilloskop sehen wir eine Spannungsdifferenz von ~70mV bei einer Stromdifferenz von 912 mA, woraus ca. 76mΩ Widerstand resultieren. Die Schlußfolgerung daraus ist, dass die Verbindung zwischen dem Punkt der Spannungsmessung durch den Spannungsregler und den VCC-Pins einen möglichst niedrigen Widerstand haben muss. Das beste sind komplette Lagen für die Stromversorgung (Power Planes), aber kurze, dicke Leitungen sind meist auch OK. Es gibt auch Spannungsregler mit extra Messeingängen, welche den Spannungsabfall über der Zuleitung kompensieren können, weil sie direkt am Verbraucher die Spannung messen. Als weitere Möglichkeit werden heutzutage meist sog. Point of Load Module eingesetzt. Das sind Spannungsregler (Schaltregler), welche direkt am zu versorgenden FPGA sitzen und mit einer hohen Spannung von 5..48V über das Board versorgt werden.

{| class="wikitable"
|+ '''Messergebnisse'''
|-
! Messung || FPGA-Inhalt || Icc [mA] || Vcc [V] || P [mW]
|-
| 1 || keine Konfiguration || 80 || 2.501 || 200
|-
| 2 || Minimallogik || 40 || 2.502 || 100
|-
| 3 || Testlogik, inaktiv || 235 || 2.487 || 584
|-
| 4 || Testlogik, konstantes Umschalten || 1147 || 2.433 || 2790
|-
| 5 || Testlogik, Burstbetrieb || 690 || 2.464 || 1700
|}

== Zusammenfassung ==

In diesem Artikel wurde eine einfache aber leistungsfähige Methode zur Messung des Frequenzgangs des Stromversorgungsnetzwerks für FPGAs gezeigt. Die Messung kann deutlich einfacher und mit leicht verfügbaren Messgeräten unter realistischeren Bedingungen durchgeführt werden als eine klassische Messung mit einem Netzwerkanalysator. Es läßt viel Raum für Experimente mit der Entkopplung der Stromversorgung in Bezug auf die Platzierung und Werte der Kondensatoren.

== Weblinks ==

*[http://processors.wiki.ti.com/index.php/General_hardware_design/BGA_PCB_design/BGA_decoupling General hardware design/BGA PCB design/BGA decoupling, Texas Instruments (engl.)]
*[http://www.signalintegrity.com/Pubs/pubsKeyword.htm#power%20system Signal integrity of power systems] by Howard Johnson (engl.)

[[Kategorie:Spannungsversorgung und Energiequellen]]
[[Kategorie:FPGA und Co]]
[[Kategorie:VHDL]]

Bitmanipulation

2014-09-29T10:12:43Z

Maybee: Änderung 85050 von 2.244.37.200 (Diskussion) rückgängig gemacht.

== Bitoperatoren ==

Bitoperatoren stammen ursprünglich aus dem Bereich des Maschinen-Codes und Assembler, existieren aber auch in den meisten Hochsprachen, wie C.

* >> = Rechts schieben
* << = Links schieben (Bsp: ''a<<b'' ist das gleiche wie ''a * 2^b''; bzw. bei 1<<3 wird die 1 um drei Stellen nach links geschoben)
* | = binäres ODER
* & = binäres UND
* usw.

Bitoperatoren in dieser Schreibweise können in Assemblercode für
konstante Ausdrücke benutzt werden.

Beispiel:

<syntaxhighlight lang="avrasm">
ldi temp, (1<<3) | (1<<1) | (1<<2) | (1<<0)
</syntaxhighlight>

wird zu:

<syntaxhighlight lang="avrasm">
ldi temp, 8 | 2 | 4 | 1
</syntaxhighlight>

wird zu:

<syntaxhighlight lang="avrasm">
ldi temp, 15
</syntaxhighlight>

== Bitmaske ==

Im Folgenden ist häufiger von dem Begriff ''Bitmaske'' die Rede. Damit wird eine Folge von einzelnen Bit bezeichnet, die den Zustand Null ('0') oder Eins ('1') darstellen können.

Bitmasken werden im allgemeinen dazu verwendet, um unter Anwendung eines Operators (z. B. UND, ODER, XOR), eine Eingabe zu manipulieren. Das Ergebnis ist dann die Anwendung des Operators auf die Eingabe und der Bitmaske.

Wenn ein Operator eine Funktion mit zwei Argumenten ist, dann lässt sich dessen Anwendung wie folgt schreiben:

<syntaxhighlight lang="c">
Ergebnis = Operator( Eingabe, Bitmaske )
</syntaxhighlight>

Die Bitmaske ist häufig eine Konstante, da diese z. B. die Information über die Position einer Information in einem Register darstellt. Das kann z. B. ein Überlaufflag in einem Timer Statusregister sein.

== Bits setzen ==

Wenn in einem Byte mehrere [[Digitaltechnik|Bits]] auf Eins gesetzt werden sollen, wird dies durch eine [[AVR-Tutorial:_Logik#ODER | ODER]]-Verknüpfung erreicht. Alle Bits, welche in der Bitmaske '1' sind, werden auf '1' gesetzt. Alle Bits, die in der Maske auf '0' gesetzt sind, bleiben unverändert.

=== AVR-Assembler ===

<syntaxhighlight lang="avrasm">
sbr r16, 0b11110000 ; setzt Bits 4-7 in r16, ist ein Pseudobefehl
; funktioniert nur für die Arbeitsregister r16-r31

ori r16, 0b11110000 ; setzt Bits 4-7 in r16, ori ist identisch mit sbr
; funktioniert nur für die Arbeitsregister r16-r31

sbi PORTB, 5 ; setzt Bit 5 in PortB
sbi PORTB, PB5 ; identisch, besser lesbar
; funktioniert nur für die IO-Register 0..0x1F

; für I/O Register mit I/O Adresse 0x20..0x3F muss
; in/out verwendet werden
in r16, TIMSK ; setzt Bit TOIE1 in TIMSK
sbr r16, (1<<TOIE1)
out TIMSK, r16

; für I/O Register oberhalb der I/O Adresse 0x3F muss
; lds/sts verwednet werden
; setzt Bit RXCIE0 in UCSR0B
lds r16, UCSR0B
sbr r16, (1<<RXCIE0)
sts UCSR0B, r16
</syntaxhighlight>

Man beachte den Unterschied! Eine "5" würde von sbr als "setze Bit 2 und 0" gedeutet (=0b00000101), während sbi sie als "setze Bit 5" versteht. Der Befehl '''sbr''' erwartet ein Bit'''muster''' für eine ODER-Verknüpfung, während der Befehlt '''sbi''' die Bit'''nummer''' benötigt. Darauf sind auch die Includefiles von Atmel im AVR-Studio (Assembler) als auch [[WinAVR]] (C) ausgelegt. Die Namen der Bits sind als Bit'''nummer''' definiert. Das ist wichtig, wenn man Register von grossen AVRs manipuliert, z. B. ATmega48. Hier muss aus der Bitnummer über eine Schiebeoperation erst das Bit'''muster''' gemacht werden.

=== Standard C ===

<syntaxhighlight lang="c">
PORTB |= 0xF0; // Kurzschreibweise, entspricht PORTB = PORTB | 0xF0; bitweises ODER

/* übersichtlicher mittels Bit-Definitionen */
#define MEINBIT0 0
#define MEINBIT1 1
#define MEINBIT2 2

PORTB |= ((1 << MEINBIT0) | (1 << MEINBIT2)); // setzt Bit 0 und 2 in PORTB auf "1"
</syntaxhighlight>

Die letzte Zeile "entschlüsselt":

# '''(1 << n)''' : Zuerst wird durch die '<<'-Ausdrücke eine "1" n-mal nach links geschoben. Dies ergibt somit (in Binärschreibweise) 0b00000001 für (1 << MEINBIT0) und 0b00000100 für (1 << MEINBIT2).
# '''|''' : Das Ergebnis wird bitweise ODER-verknüpft, also 0b00000001 ''or'' 0b00000100 wird zu 0b00000101.
# '''|=''' : Diese Maske wird mit dem aktuellen Inhalt von PORTB bitweise ODER-verknüpft und das Ergebnis PORTB wieder zugewiesen.

<syntaxhighlight lang="c">
PORTB |= variable; // Kurzschreibweise
PORTB = PORTB | variable; // lange Schreibweise
</syntaxhighlight>

: Ist PORTB vorher z. B. 0b01111010, dann ist der Inhalt nach der Operation 0b01111010 ''or'' 0b00000101 = 0b01111111, die gewünschten Bits sind somit gesetzt!

Anmerkung: Will man das gezeigte Beispiel der Bitmanipulation auf größere Datentypen anwenden, ist zu beachten, dass der Compiler in der Operation (1 << MEINBIT1) stillschweigend gemäss, den C-Regeln, die 1 als Integer Typ ansieht. Beim AVR-GCC bedeutet das 16-Bit/signed und die folgende Operation bringt ggf. nicht das gewünschte Ergebnis. (Stichwort: "Integer Promotion").

Angenommen Bit 15 soll in einer 32-Bit weiten Variable gesetzt werden.

<syntaxhighlight lang="c">
#define MEINBIT15 15
#define MEINBIT42 42

uint32_t reg_32; /* uint32_t definiert per typedef z. B. in stdint.h */
uint64_t reg_64; /* uint64_t definiert per typedef z. B. in stdint.h */

reg_32 |= (1 << MEINBIT15); /* FEHLER: Setzt die Bits 31 - 15, da ((int)1 << 15) == 0xFFFF8000 */

reg_32 |= ((uint32_t)1 << MEINBIT15); /* Hier wird nur Bit 15 gesetzt. */
reg_32 |= (1U << MEINBIT15); /* */
reg_32 |= (1L << MEINBIT15); /* andere Schreibweise. */
reg_64 |= (1LL << MEINBIT42); /* Hier wird nur Bit 42 gesetzt,
andere Schreibweise für 64 Bit (long long). */
</syntaxhighlight>

Bei Compilern für 32bit Controller (z. B. ARM7TDMI) sind Integers per default 32-bit und Konstanten sind somit implizit ebenfalls 32-bit. Man sollte aber dennoch die oben gezeigte Vorgehenweise verwenden, um Probleme zu vermeiden die entstehen könnten, wenn Code unter verschiedenen Plattformen/Compilern verwendet werden soll.

== Bits löschen ==

Wenn in einem Byte mehrere [[Digitaltechnik|Bits]] auf Null gesetzt werden sollen, wird dies durch eine [[AVR-Tutorial:_Logik#UND | UND]]-Verknüpfung erreicht. Alle Bits, welche in der Bitmaske '0' sind, werden auf '0' gesetzt. Alle Bits, die in der Maske auf '1' gesetzt sind, bleiben unverändert.

=== AVR-Assembler ===

<syntaxhighlight lang="avrasm">
cbr r16, 0b00001111 ; löscht Bits 0-3 in r16, ist ein Pseudobefehl
; funktioniert nur für die Arbeitsregister r16-r31

andi r16, 0b11110000 ; löscht Bits 0-3 in r16, andi ist identisch mit cbr
; funktioniert nur für die Arbeitsregister r16-r31

andi r16, ~0b00001111 ; andere Schreibweise, hier wird die Bitmaske durch ~ invertiert
; dadurch kann man einfach alle zu löschenden Bit als '1' angeben
; so wie bei den Bitmasken für das setzen von Bits (positive Logik)

cbi PORTB, 5 ; löscht Bit 5 in PortB
cbi PORTB, PB5 ; identisch, besser lesbar
; funktioniert nur für die IO-Register 0..31

; für I/O Register mit I/O Adresse 0x20..0x3F muss
; in/out verwendet werden weil dieser Bereich nicht
; bitadressierbar ist
in r16, TIMSK ; löscht Bit TOIE1 in TIMSK
cbr r16, 1<<TOIE1
out TIMSK, r16

; für I/O Register oberhalb der I/O Adresse 0x3F muss
; lds/sts verwednet werden
; löscht Bit RXCIE0 in UCSR0B
lds r16, UCSR0B
cbr r16, 1<<RXCIE0
sts UCSR0B, r16
</syntaxhighlight>

Auch hier gilt: Man beachte den Unterschied! Eine "5" würde von cbr als "lösche Bit 2 und 0" gedeutet, während cbi sie als "lösche Bit 5" versteht. Der Befehl '''cbr''' erwartet ein Bit'''muster''' für eine UND-NOT-Verknüpfung (nicht zu verwechseln mit NAND), während der Befehl '''cbi''' die Bit'''nummer''' benötigt. Darauf sind auch die Includefiles von Atmel im AVR-Studio (Assembler) als auch [[WinAVR]] ausgelegt. Die Namen der Bits sind als Bit'''nummer''' definiert. Das ist wichtig, wenn man Register von grossen AVRs manipuliert, z. B. ATmega48. Hier muss aus der Bitnummer über eine Schiebeoperation << erst das Bit'''muster''' gemacht werden.

=== Standard C ===

<syntaxhighlight lang="c">
PORTB &= 0xF0; // entspricht PORTB = PORTB & 0xF0; bitweises UND
// Bits 0-3 (das "niederwertige" Nibble) werden geloescht

/* übersichtlicher mittels Bit-Definitionen */
#define MEINBIT0 0
#define MEINBIT1 1
#define MEINBIT2 2

PORTB &= ~((1 << MEINBIT0) | (1 << MEINBIT2)); // löscht Bit 0 und 2 in PORTB
</syntaxhighlight>

Die letzte Zeile entschlüsselt:

# '''(1 << n)''' : Zuerst wird durch die '<<'-Ausdrücke eine "1" n-mal nach links geschoben. Dies ergibt somit (in Binärschreibweise) 0b00000001 für (1 << MEINBIT0) und 0b00000100 für (1 << MEINBIT2).
# '''|''' : Das Ergebnis wird bitweise ODER-verknüpft also 0b00000001 ''or'' 0b00000100 wird zu 0b00000101.
# '''~''' : Der Wert in der Klammer wird bitweise invertiert, aus 0b00000101 wird 0b11111010.
# '''&=''' : PORTB wird mit der berechneten Maske UND-verknüpft und das Ergebnis wieder PORTB zugewiesen.

<syntaxhighlight lang="c">
PORTB &= variable; // Kurzschreibweise
PORTB = PORTB & variable; // lange Schreibweise
</syntaxhighlight>

: Ist PORTB vorher z. B. 0b01111111, dann ist der Inhalt nach der Operation 0b011111111 ''and'' 0b11111010 = 0b01111010, die gewünschten Bits 0 und 2 sind somit gelöscht.

Die C-Ausdrücke mittels Definitionen von Bitnummern und Schieboperator (<<) sehen auf den ersten Blick etwas "erschreckend" aus und sind mehr "Tipparbeit", funktionieren aber universell und sind deutlicher und nachvollziehbarer als "handoptimierte" Konstanten. Bei eingeschalteter Optimierung löst der Compiler die Ausdücke mit konstanten Werten bereits zur Compilierungszeit auf und es entsteht kein zusätzlicher Maschinencode. Bei AVR sind die Definitionen meist Teil der Entwicklungsumgebungen (bei avr-libc z. B. implizit durch #include <avr/io.h>). Sie entsprechen den Angaben und Beispielen in den Datenblättern und sind damit de-facto ein Standard beim Zugriff auf Bits in Hardware-Registern.

'''Wichtiger Hinweis''': Die ODER-Verknüpfung und die anschliessende Invertierung kann man nicht vertauschen! (Theorem von DeMorgan) Folgendes Beispiel soll die Richtigkeit der Aussage zeigen:

<syntaxhighlight lang="c">
~(0b0001 | 0b0010) == 0b1100
~0b0001 | ~0b0010 == 0b1111
</syntaxhighlight>

'''Noch ein wichtiger Hinweis''': Der operator ~ mit einem Operanden vom Typ int negiert nur so viele bits, wie der Typ int hat.
Will man ein bit in einer breiteren Variablen löschen, dann sollte die nach links zu shiftende 1 den Typ dieser Variablen haben.

Ein Programm, welches das verdeutlicht:
<syntaxhighlight lang="c">
#include <stdio.h>
#include <stdint.h>

int main(int argc, const char* argv[])
{
int bit = 60;
uint64_t ui64;
printf("sizeof(int)=%d\n", (int)sizeof(int));

ui64 = 0xFFFFFFFFFFFFFFFF;
ui64 &= ~(1<<60); /* Keine Wirkung bei sizeof(int) < 8 */
/* gcc warnt sogar:
* gcc -Wall bit_clear.c -o bit_clear
* bit_clear.c: In function ‘main’:
* bit_clear.c:11:5: warning: left shift count >= width of type [enabled by default]
*/
printf("%d\n", ui64!=0xFFFFFFFFFFFFFFFF);

ui64 = 0xFFFFFFFFFFFFFFFF;
ui64 &= ~((uint64_t)1<<60); /* ok */
printf("%d\n", ui64!=0xFFFFFFFFFFFFFFFF);

ui64 = 0xFFFFFFFFFFFFFFFF;
ui64 &= ~(1LL<<60); /* auch ok, und kürzer. */
printf("%d\n", ui64!=0xFFFFFFFFFFFFFFFF);

ui64 = 0xFFFFFFFFFFFFFFFF;
ui64 &= ~(1<<bit); /* Ohne Warnung, und funktioniert manchmal, je nach Optimierung */
printf("%d\n", ui64!=0xFFFFFFFFFFFFFFFF);

return 0;
}
/* Ausgabe auf meinem PC ohne Optimierung:
* sizeof(int)=4
* 0
* 1
* 1
* 1
* Ausgabe auf meinem PC mit -O2
* 0
* 1
* 1
* 0
*/
</syntaxhighlight>

=== Niederwertigstes gesetztes Bit löschen (Standard C) ===

Folgender Code löscht von allen 1-Bits in einer Integer-Variable das niederwertigste, unabhängig von der Position desselben.

Beispiel: 01101000 -> 01100000

<syntaxhighlight lang="c">
uint8_t byte;

byte = irgendwas();

byte = byte & (byte - 1); /* Diese seltsame Operation löscht das
niederwertigste 1-Bit */
</syntaxhighlight>
Beispiel:
<syntaxhighlight lang="c">
Byte : 01101000
Byte-1: 01100111
Ergebnis:01100000

</syntaxhighlight>
Das funktioniert also mit jeder beliebigen Zahl.

Dies kann bspw. zur schnellen Paritätsgenerierung eingesetzt werden:

<syntaxhighlight lang="c">
uint8_t pareven(uint8_t byte) {
uint8_t par = 0;

while(byte) {
byte = byte & (byte - 1);
par = ~par;
}
return par;
}
</syntaxhighlight>

Das genannte gilt natürlich nicht nur für 8-Bit-Integers, sondern für beliebige, vom Compiler unterstützte Wortlängen.

== Bits invertieren ==

Im allgemeinen Sprachgebrauch oft Toggeln genannt (aus dem Englischen). Wenn in einem Byte mehrere [[Digitaltechnik|Bits]] invertiert (getoggelt) werden sollen, wird dies durch eine [[AVR-Tutorial:_Logik#XOR_.28Exlusives_Oder.29 | XOR]]-Verknüpfung erreicht. Alle Bits, welche in der Bitmaske '1' sind, werden invertiert. Alle Bits, die in der Maske auf '0' gesetzt sind, bleiben unverändert.

=== AVR Assembler ===

Bei [[AVR]]s erlaubt dies folgender Assemblercode. Hier wird ein Ausgangspin invertiert.

<syntaxhighlight lang="avrasm">
sbic PortB, 0 ; Überspringe den nächsten Befehl, wenn das Bit 0 im Port gelöscht ist
rjmp ClrBitNow ; Springe zu ClrBitNow
sbi PortB, 0 ; Setze Bit 0 in PortB
rjmp BitReady ; Springe BitReady
ClrBitNow:
cbi PortB, 0 ; Lösche Bit 0 in PortB
BitReady:
</syntaxhighlight>

Noch kürzer gehts so: 
Die zweite Zeile mit dem Befehl '''ldi''' lädt die Bitmaske, in welcher die zu toggelnden Bits auf '1' gesetzt sind. In diesem Beispiel wird das dritte Bit invertiert. Der Vorteil dieser Methode ist neben der Kürze und Übersichtlichkeit auch die Möglichkeit, bis zu 8 Bit gleichzeitig zu toggeln. Diese Methode ist natürlich auch auf normale Daten anwendbar, nicht nur auf IO-Ports.

<syntaxhighlight lang="avrasm">
in R24, PORTE ; Daten lesen
ldi R25, 0x04 ; Bitmaske laden, hier Bit #2
eor R24, R25 ; Exklusiv ODER
out PORTE, R24 ; Daten zurückschreiben
</syntaxhighlight>

Eine andere Möglichkeit gibt es, wenn man nur das 8. Bit kippen will:

<syntaxhighlight lang="avrasm">
in r16, PORTB
subi r16, 0x80
out PORTB, r16
</syntaxhighlight>

=== Standard C ===

<syntaxhighlight lang="c">
PORTB ^= (1<<PB0); /* XOR, Kurzschreibweise, PORTB = PORTB ^ (1<<PB0) */
</syntaxhighlight>

=== Neuere ATmegas ===

Bei den neueren ATmegas (z. B. ATmega48) kann man IO-Pins direkt ohne den Umweg über Register togglen, indem man das entsprechende Bit im PINx-Register '''setzt''':

<syntaxhighlight lang="avrasm">
sbi PIND, 2 ; Bit 2 von Port D togglen
</syntaxhighlight>

=== 8051er ===

<syntaxhighlight lang="avrasm">
cpl bitadresse
</syntaxhighlight>

== Bits prüfen ==

Will man prüfen ob ein oder mehrere Bits in einer Variable gesetzt oder gelöscht sind, muss man sie mit einer Bitmaske UND verknüpfen. Die Bitmaske muss an den Stellen der zu prüfenden Bits eine '1' haben, an allen anderen eine '0'.

* Ist das Ergebnis gleich Null, sind alle geprüften Bits gelöscht.
* Ist das Ergebnis ungleich Null, ist mindestens ein geprüftes Bit gesetzt.
* Ist das Ergebnis gleich der Bitmaske, sind alle geprüften Bits gesetzt.

=== AVR Assembler ===

Der AVR hat spezielle Befehle um direkt einzelne Bits in den CPU-Registern r0..r31 sowie den IO-Registern 0..0x1F zu prüfen.

<syntaxhighlight lang="avrasm">
; Befehle zur Prüfung von einzelnen Bits

sbrs r16,3 ; überspringe den nächsten Befehl, wenn in r16 Bit #3 gesetzt ist
rjmp bit_ist_nicht_gesetzt

sbrc r16,5 ; überspringe den nächsten Befehl, wenn in r16 Bit #5 gelöscht ist
rjmp bit_ist_nicht_geloescht

sbis timsk,3 ; überspringe den nächsten Befehl, wenn in timsk Bit #3 gesetzt ist
rjmp bit_ist_nicht_gesetzt

sbic timsk,5 ; überspringe den nächsten Befehl, wenn in timsk Bit #5 gelöscht ist
rjmp bit_ist_nicht_geloescht

; Befehle zur Prüfung von mehreren Bits

andi r16,0b1010 ; prüfe Bit #1 und #3 in r16
breq alle_bits_sind_geloescht

andi r16,0b1010 ; prüfe Bit #1 und #3 in r16
brne mind_ein_bit_ist_gesetzt

andi r16,0b1010 ; prüfe Bit #1 und #3 in r16
cpi r16,0b1010
breq alle_bits_sind_gesetzt
</syntaxhighlight>

=== Standard C ===

<syntaxhighlight lang="c">
// prüfe ob Bit 4 in der Variable tmp gelöscht ist
// die Klammer ist wichtig
if (!(tmp & 0x10)) {
// hier die Anweisungen, wenn das Bit gelöscht ist
}

// prüfe ob Bit 0 und Bit 4 in der Variable tmp gelöscht sind
// die Klammer ist wichtig!
if ((tmp & 0x11) == 0) {
// hier die Anweisungen, wenn beide Bits gelöscht sind
}

// prüfe ob Bit 0 oder Bit 4 in der Variable tmp gesetzt ist
if (tmp & 0x11) {
// hier die Anweisungen, wenn mindestens ein Bit gesetzt ist
}

// prüfe ob Bit 0 oder Bit 4 in der Variable tmp gelöscht sind
if (~tmp & 0x11) {
// hier die Anweisungen, wenn mindestens ein Bit gelöscht ist
}

// prüfe ob Bit 4 in der Variable tmp gesetzt ist
if (tmp & 0x10) {
// hier die Anweisungen, wenn das Bit gesetzt ist
}

// prüfe ob Bit 0 und Bit 4 in der Variable tmp gesetzt sind
// die Klammer ist wichtig!
if ((tmp & 0x11) == 0x11) {
// hier die Anweisungen, wenn beide Bits gesetzt sind
}
</syntaxhighlight>

== Hilfsfunktionen zur Bitmanipulation in C/C++ ==
Um "einfacher" elementare Bitmanipulationen durchzuführen bietet es sich an einige Hilfsfunktionen zu definieren. Dabei gibt es zwei verschiedene Möglichkeiten diese zu realiseren:
* Als C-Makro [[C_Makros]]
* Als Inline-Funktion
In beiden Fällen wird bei eingeschalteter Optimierung letztendlich vom Compiler ein sehr kompakter (und identischer!) Code erzeugt, jedoch ist dringend von der Verwendung von Makros abzuraten (siehe [[Makro]] )!
Im Fehlerfall zeigt der Compiler bei der Verwendung vom Makros keine eindeutigen Fehlermeldungen an, da es sich um simple Ersetzungen handelt - bei der Verwendung von Inline-Funktionen hingegen gibt es eine "brauchbare" Fehlermeldung!

=== Beispiele - Inline Variante ===
<syntaxhighlight lang="c">
// Achtung: Zugriffe erfolgen über Pointer
// PORTA, PB2 setzen
BIT_SET(&PORTA, PB2);

// PORTC, PB0 löschen
BIT_CLEAR(&PORTC, PB0);

// PORTA, PB2 direkt setzen
// HIGH
BIT_BOOL_SET(&PORTA, PB2, 1);

// LOW
BIT_BOOL_SET(&PORTA, PB2, 0);
</syntaxhighlight>

=== Beispiele - MakroVariante ===
<syntaxhighlight lang="c">
// Achtung: Zugriffe erfolgen direkt über die Variablen/Portnamen
// PORTA, PB2 setzen
BIT_SET(PORTA, PB2);

// PORTC, PB0 löschen
BIT_CLEAR(PORTC, PB0);
</syntaxhighlight>

Um die Hilfsfunktionen verwenden zu können einfach folgenden Code in eine neue Header-Datei (z.B. BitIO.h) kopieren:

=== Hilfsfunktionen als Inline-Methoden ===
Achtung: Wenn nur ein C Compiler verwendet wird, kennt dieser den Typ "bool" nicht, dieser muss dann vorher definiert werden!
<syntaxhighlight lang="c">
/**
* BitIO.h
* @author Andi Dittrich <http://andidittrich.de>
* @version 1.0
* @license MIT Style X11 License
*/

#include <inttypes.h>

#ifndef BITIO_H_
#define BITIO_H_

// set bit
static inline void BIT_SET(volatile uint8_t *target, uint8_t bit) __attribute__((always_inline));
static inline void BIT_SET(volatile uint8_t *target, uint8_t bit){
*target |= (1<<bit);
};

// set clear
static inline void BIT_CLEAR(volatile uint8_t *target, uint8_t bit) __attribute__((always_inline));
static inline void BIT_CLEAR(volatile uint8_t *target, uint8_t bit){
*target &= ~(1<<bit);
};

// bit toogle
static inline void BIT_TOGGLE(volatile uint8_t *target, uint8_t bit) __attribute__((always_inline));
static inline void BIT_TOGGLE(volatile uint8_t *target, uint8_t bit){
*target ^= (1<<bit);
};

// set bit by boolean
static inline void BIT_BOOL_SET(volatile uint8_t *target, uint8_t bit, bool enable) __attribute__((always_inline));
static inline void BIT_BOOL_SET(volatile uint8_t *target, uint8_t bit, bool enable){
if (enable){
BIT_SET(target, bit);
}else{
BIT_CLEAR(target, bit);
}
};

#endif /* BITIO_H_ */

</syntaxhighlight>

=== Hilfsfunktionen als C-Makro (nicht empfohlen) ===
<syntaxhighlight lang="c">
/* Bit setzen */
#define set_bit(var, bit) ((var) |= (1 << (bit)))

/* Bit löschen */
#define clear_bit(var, bit) ((var) &= (unsigned)~(1 << (bit)))

/* Bit togglen */
#define toggle_bit(var,bit) ((var) ^= (1 << (bit)))
</syntaxhighlight>

== Bitmanipulation beim MSP430 ==

Beim MSP430 und dessen Compilern sind die Bitnamen meist anders definiert. Und zwar nicht als Bitnummer, sondern als Bitmuster. Darum schreibt man dort die Bitzugriffe in C anders. Das kann auch bei anderen Mikrocontrollern bzw. C-Compilern so sein. Wichtig ist, dass man seine eignen Definitionen in der gleichen Weise wie der Compiler anlegt, um Verwirrung zu vermeiden, siehe [[Strukturierte Programmierung auf Mikrocontrollern]]

<syntaxhighlight lang="c">
// Definition von Bitnamen in den Headerfiles des Compilers

#define PD4 4 // Definition im AVR GCC als Bitnummer
#define PD5 5

#define P14 (1<<4) // Definition im MSP430 GCC als Bitmuster
#define P15 (1<<5)

// Bitmanipulation im Programm

DDRD = (1<<PD5) | (1<<PD4); // AVR GCC
P1DIR = P15 | P14; // MSP430 GCC
</syntaxhighlight>

==Siehe auch==

* [http://www.mikrocontroller.net/topic/179566#1729219 Forumsbeitrag:] Bits aus einem Array extrahieren
* [http://www.mikrocontroller.net/topic/169509#1631439 Forumsbeitrag:] Bits für ein Schieberegister zusammenstellen, TLC5941
* [http://www.mikrocontroller.net/topic/15466?goto=107726#107720 Forumsbeitrag:] Bitreihenfolge ändern
* [http://www.mikrocontroller.net/topic/23866?goto=new#177674 Forumsbeitrag:] Wie drehe ich eine Bitreihenfolge um?
* [http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/AVR-Built_002din-Functions.html AVR Build-in Functions], spezielle Funktion im avr-gcc zur schnellen Bitvertauschung, engl.

[[Category:8051]]
[[Category:AVR-Arithmetik]]

GPIB-RS232-Schnittstelle

2014-07-13T22:22:58Z

Maybee: Änderung 83589 von 84.21.100.54 (Diskussion) rückgängig gemacht.

Achtung, Baustelle.

''von Sven Pauli''

Einfacher GPIB-Controller mit serieller Schnittstelle (RS232).

== Einleitung ==
[[Datei:gpib-rs232.jpeg|miniatur|GPIB-RS232-Schnittstelle]]
Viele Messgeräte sind (auch heute immer noch) mit einer GPIB-Schnittstelle ausgerüstet. Zwar handelt es sich hierbei zwar um einen eher antiquierten, parallelen Datenbus, den Hewlett-Packard vor nunmehr vierzig Jahren in die Welt gesetzt hat, dennoch sind es vor allem die [http://www.ni.com/white-paper/3509/en/#vergleichsweise geringen Übertragungslatenzen], welche die GPIB-Schnittstelle auch weiterhin für zeitkritesche Aufgaben prädestinieren.
Mittlerweile wurde die GPIB-Schnittstelle vielfach genormt - unter anderem unter der Bezeichnung IEEE488 und IEC-625, daher auch die gängige Bezeichnung als ''IEC-BUS''.

Der Bus ist acht Bit breit und beinhaltet neben einer Reihe von Steuerleitungen ein Drei-Leitungs-Handshake. Dieses ist in Wired-And-Methodik ausgeführt, d.h. der Bus wird terminiert und mit Pull-up versehen, welchen die Busteilnehmer dann aktiv nach Masse ziehen können. Das Handshake gewährleistet, dass der Bus nur so schnell betrieben wird, wie das langsamste Gerät am Bus Daten aufnehmen kann. Der genaue Ablauf des Bustransfers ist in [http://www.interfacebus.com/Design_Connector_GPIB.html#d dieser Grafik] recht anschaulich beschrieben.

Funktionen:
* GPIB-Controller, also SH, AH, C,
* HP Universal Language Interface auf der seriellen,
* Zustandsanzeige über Blinkmuster...,
* Vernünftige Pegelwandler und keine Spannungsteiler,
* umfangreiche End-of-string-Behandlung.

== Terminologie ==
Sämtliche Signale auf dem Bus sind Low-aktiv.

Der Bus besteht aus den acht Datenleitungen des ''Datenbus'', die das Datenbyte aufnehmen (invertiert, da Low-aktiv). Ein Byte kann ''auf den Bus gelegt'' werden, indem die Treiber eingeschaltet werden und die Datenleitungen entsprechend gesetzt werden. Um das Byte wieder ''vom Bus zu '''nehmen''''', werden die Treiber wieder abgeschaltet. Das ist etwas anderes, als ein Byte ''vom Bus zu '''lesen'''''!

Dazu kommt der ''Übergabebus'' mit den drei Handshakeleitungen DAV (data available), NDAC (no data accepted) und NRFD (not ready for data). Schließlich bilden ein paar Steuerleitungen den ''Steuerbus''; die wichtigsten wären
* ATN (attention),
* REN (remote enable) und
* EOI (end or identify).

Man spricht beim GPIB eigentlich immer von irgendwelchen ''Botschaften'', die abgesetzt oder zurückgezogen werden. Es kann sich dabei um Bytes handeln, die über den Bus gehen, oder auch schlicht um eine der Steuer- oder Handshakeleitungen, die einen bestimmten Pegel annimmt. Da der Bus Low-aktiv arbeitet, sind insbesondere die Steuerleitungen ''aktiv'', wenn sie einen niedrigen Spannungspegel annehmen. Die entsprechende Botschaft ist dann ''gesendet'' (oder ''abgesetzt''). Wegen Wired-and können auch mehrere Busteilnehmer eine Botschaft zugleich absetzen. Sie bleibt dann solange abgesetzt, bis sämtliche Teilnehmer sie wieder ''zurückgezogen'' haben.

Mit der DAV-Botschaft (data valid) wird signalisiert, dass der Datenbus gültige Daten enthält, die nun gelesen werden können. Wird die EOI-Botschaft (end or identify) zusammen mit einem Byte übertragen, so handelt es sich um das letzte Byte einer längeren Nachricht. Die ATN-Botschaft (attention) fordert alle Busteilnehmer auf, sämtliche Bustätigkeit zu unterbrechen und den Datenbus freizugeben (etwaige Talker nehmen ihr Byte vom Bus).

== Hardware ==
Die Schnittstelle wurde vollständig in bedrahteter Technologie auf einer einseitigen Platine aufgebaut. Für die serielle Schnittstelle kommt der MAX232 zum Einsatz, die Busankopplung nehmen die klassichen SN75160 (Daten) und SN75162 (Steuerleitungen). Zusammengehalten wird beides von einem ATmega16 oder pinkompatiblen. Die Bustreiber sind eigentlich typisch; den -160 bekommt man bei Reichelt. Den zweiten gibt es dort noch als -161; dem fehlen allerdings zwei wichtige Signale, es muss also der -162 sein.

Notfalls lassen sich die Treiber auch aus alten GPIB-Karten ausschlachten...

Zuletzt habe ich noch ein geregeltes Netzteil (7805) spendiert, um die Karte über Hohlstecker zu versorgen. Man halte sich dabei die vergleichsweise große Verlustleistung der Bustreiber vor Augen, wenn man mit dem Gedanken spielt, die Karte über USB zu versorgen: Im Leerlauf insgesamt etwa 150mA.

Zum Bus hin habe ich den typischen Centronics-Stecker (''micro ribbon connector'') verbaut. Da ist etwas Vorsicht geboten, denn die gibt es auch in gespiegelter Bauform. Der Stecker ist trapezförmig; die normale Bauform hat das schmale Ende unten (Richtung Platine), die gespiegelte Version nach oben. Ich habe die normale Version gewählt.

Es gibt auf der Platine keine diskrete Logik für die ATN-Leitung. Das mag mancheinem vielleicht schon aufgefallen sein, der alte GPIB-PCI-Steckkarten gesehen hat -- die glichen anfangs einem TTL-Grab. Hintergrund ist, dass in der Spezifikation ein recht zeitkritisches Verhalten als Antwort auf die ATN-Botschaft vereinbart ist. Nämlich haben alle Busteilnehmer bei Empfang der ATN-Botschaft ihren Busbetrieb binnen 200ns einzustellen und die Treiber zu deaktivieren.

Das Zeitfenster von 200ns ist recht sportlich, um es mit einem Interrupt aufzufangen, gerade bei den alten Mikroprozessors, die auf den Steckkarten verbaut wurden, und auch für den AVR. Daher hat man diese Spezifikation (und noch ein paar weitere) mit diskreter Logik erschlagen. Diese hat sich dann schnell um die Bustreiber gekümmert und einfach ein Flipflop gesetzt. Dieses hat der Mikroprozessor dann bei nächster Gelegenheit abgeholt und hatte damit wieder genug Zeit, zu reagieren.

== Software ==
Die Software ist in C für avr-gcc geschrieben.

=== Controller-Betrieb ===
Die fehlende diskrete Logik hat zur Konsequenz, dass die Schnittstelle eigentlich nur als Controller standardkonform funktioniert. Denn nur dann kümmert sie sich selbst um die ATN-Botschaft und muss demnach nicht auf fremde ATN-Botschaften reagieren, was sie ja aus Zeitgründen nicht innerhalb des spezifizierten Zeitfensters kann. Würde man die Schnittstelle ''nur'' als ''Sprecher'' (Talker) betreiben, könnte der momentane Controller die ATN-Botschaft versenden und gleich darauf ein paar Daten auf den Bus legen. Tut er das so schnell wie möglich, also nach 200ns, hätte die Schnittstelle keine Chance, etwaige Daten vom Bus zu nehmen, denn mit zwei Prozessorzyklen des AVR (bei 8MHz) wären die 200ns schon beim Sprung in den Interrupt verstrichen (rjmp mit zwei Zyklen = 250ns). Und da sind noch nicht die vier Takte drin, die bis zum Interruptvektor vergehen, denn es muss ja noch der Programmzähler auf den Stack gelegt werden.

Praktisch ist der Bus in Wired-and ausgeführt, d.h. es entstehen zumindest keine Kurzschlüsse, wenn zwei gleichzeitig reden, weil die Treiber nicht schnell genug abgeschaltet werden. Es können aber Daten kaputt gehen, wenn andere Teilnehmer die Daten früher vom Bus lesen, als jemand anderes seine Treiber abschaltet. Und zwar nach folgendem Szenario:
* Wir legen ein Byte auf den Bus und
* signalisieren das mit der DAV-Botschaft.
* Ein paar Hörer lesen das Byte vom Bus.
* Der Controller setzt die ATN-Botschaft ab,
* er wartet die 200ns und
* legt seinerseits ein Byte auf den Bus (dieses kollidiert mit unserem) und
* signalisiert das mit der DAV-Botschaft. Die DAV-Botschaft bleibt also bestehen (Wired-and).
* Ein paar andere Hörer lesen das ('''kaputte''') Byte vom Bus.
* Wir bemerken die ATN-Botschaft und ziehen Byte und ATN-Botschaft zurück.
* Wegen Wired-and ist die DAV-Botschaft noch immer aktiv.
* ...

Der Betrieb als Hörer leidet am gleichen Problem, hier ist allerdings das Lesen vom Bus kritisch. Ein Sprecher könnte ein Datenbyte auf den Bus legen und dies mit der DAV-Botschaft signalisieren. Das bemerken wir und beginnen mit dem Lesevorgang (Interrupt betreten und so weiter). Indes unterbricht ein Controller die Übertragung mit der ATN-Botschaft der Bus enthält dann ungültige Daten. Und wir fahren munter mit dem begonnenen Lesevorgang fort...

Unterm Strich: Meistens funktioniert es.

=== Protokoll ===
Für das Protokoll über die serielle Schnittstelle habe ich mich vom ''Universal Language Interface'' (ULI) von Hewlett-Packard inspirieren lassen. Das Heftchen von 1993 fiel mir zufällig in die Hände und ich fand das ganz passend.

Das Prinzip dahinter ist recht einfach. Früher hat man eine GPIB-Karte in den Computer gesteckt und bekam einen Treiber für ein recht bekanntes Betriebssystem seiner Zeit. Dazu kamen ein paar Bibliotheken für BASIC, C, Pascal und so weiter, die entsprechende Funktionen boten. Dazu gehörten Lese- und Schreibbefehle ''ibrd()'' und ''ibwr()'', Funktionen zur Adressiereung und allerlei Zubehör. Je nach Hersteller waren diese Funktionen dann mehr oder weniger ähnlich und/oder inkompatibel.

Beim ULI dagegen erzeugte der Treiber quasi eine Gerätedatei, die man in der jeweiligen Programmiersprache dann mit Standard-E/A öffnen konnte. Das entspricht in etwa dem, was sich unter *nix schon länger bewährt hat. Eine Bibliothek gibt es nicht mehr, stattdessen werden Befehle zeilenweise in dieses Gerät geschrieben und Antworten kommen zeilenweise wieder heraus.

''Zeilenweise'' ist in diesem Zusammenhang schwierig. Einerseits könnten Zeilenendzeichen (Wagenrücklauf CR, Zeilenvorschub LF) auch im Nutzdatenstrom vorkommen, andererseits konstruierte sich anfangs jeder Hersteller von GPIB-Messgeräten ein eigenes Bild vom Zeilenende. Manche wollten nur ein CR oder LF, manche CRLF, ein Semikolon oder die EOI-Botschaft (die EOI-Steuerleitung kann zusammen mit dem letzten übertragenen Byte gesetzt werden und signalisiert dann das Zeilenende). Glücklicherweise waren und sind die meisten Geräte recht tolerant und akzeptieren eine Vielzahl dieser Möglichkeiten, wenn man mit ihnen spricht. Tragischerweise antworten sie aber auch mit einer Vielzahl dieser Möglichkeiten, wenn sie umgekehrt mit uns sprechen...

=== Architektur ===
Die Firmware ist mehrschichtig konstruiert. Ganz unten liegen zwei Ringpuffer, einer für die serielle Schnittstelle und einer für den GPIB. Diese Puffer kümmern sich um die Handshakes (Dreileitung für GPIB und RTS/CTS für die serielle).

Darüber liegt eine Strom-Schicht (Strom von Datenstrom), die aus den eingehenden Datenströmen der Ringpuffer die Zeilenenden herausfischt und die Zeilenenden in den ausgehenden Strömen erzeugt. Von da an sind beide Schnittstellen an die C-Laufzeitbibliothek angeschlossen, sodass die Kommunikation in weiten Teilen wie gewohnt mit puts()/printf()/... abläuft. Die Zeilenenden in den Eingangsströmen werden dabei als End-of-file (EOF) dargestellt. Da man allerdings kein EOF in den Ausgangsströmen erzeugen kann (könnte man schon, mit fclose(); diese Funktion ist aber schon anderweitig vergeben), werden die Zeilenenden mit einem ''flush'' ausgelöst. Blöderweise ist auch fflush() schon vergeben, daher zwei spezifische Routinen.

Obenauf liegt ein Terminal und verbindet die beiden Schnittstellen über das ULI.

=== Beispiel ===
Eine Sitzung mit dem Universalzähler ''PM6652'' und dem Generator ''PM5192'' könnte etwa so aussehen:

Die Baudrate wird automatisch am ersten empfangenen Zeilenvorschub ermittelt:
$ echo > ttyUSB1
Schnittstelle einschalten und den Zähler (Adresse 14) parametrisieren:
$ echo "ONLINE" > ttyUSB1
$ echo "REMOTE 14" > ttyUSB1
$ echo "OUTPUT 14;D" > ttyUSB1
$ echo "OUTPUT;F1TE1G0SM5" > ttyUSB1
Zähler auf 1337Hz einstellen:
$ echo "REMOTE 15" > ttyUSB1
$ echo "OUTPUT 15;OUT 15;WSLA4F1337" > ttyUSB1
Messung durchführen und Ergebnis abholen:
$ echo "TRIGGER 14" > ttyUSB1
$ echo "ENTER 14" > ttyUSB1
$ line < ttyUSB1
FA 001.3370011E+3

Die Anführungszeichen sind nötig, damit die Shell das Semikolon nicht als Befehlsende interpretiert.

== Schaltung ==
[[Datei:gpib-rs232-sch.png|miniatur|Schaltplan]]
[[Datei:gpib-rs232-brd.png|miniatur|Board]]
Die Schaltung ist in EAGLE realisiert; Maßstab des Board ist 1:2, also nicht wundern... Das ganze hat mit drei Drahtbrücken einseitig funktioniert. Die Drahtbrücke oben links verbindet die Schirmung mit Masse.

Schaltplan und Board stelle ich vorerst unter der aktuellen [http://creativecommons.org/licenses/by-nc-sa/3.0/de/ CC-BY-NC-SA] zur Verfügung.

== Downloads ==
Die jeweils aktuelle Version hängt am jüngsten Beitrag im Thread.

== Siehe auch ==
* [http://www.mikrocontroller.net/topic/256475 Thread zum Artikel]
* http://www.interfacebus.com/Design_Connector_GPIB.html GPIB Bus Ja ich weiß, GPIB Bus ist wie LCD-Display, aber die Seite heißt nunmal so...
* http://linux-gpib.sourceforge.net/doc_html/index.html Typischer Satz von Bibliotheksfunktionen
* http://www.ni.com/pdf/manuals/370915a.pdf Universal Language Interface

[[Kategorie:AVR-Projekte]]
[[Kategorie:UART und RS232]]

RGB Touch Matrix

2014-06-29T22:35:47Z

Maybee: Links nach Relevanz angeordnet

''von Conny G.''

Es soll eine RGB Touch Matrix entwickelt werden, die z.B. für RGB-Touch-Tische eingesetzt werden kann.
Beispiel für einen Touch-Tisch: http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html
Dieser ist jedoch vom Hardware-Konzept sehr aufwändig gelöst, deshalb ist das Ziel des Projekts als Kern der Lösung zwei Dinge möglichst effizient zu lösen:
* die einzelnen RGB & Touch Pixel
* die Verbindung der Pixel auf Basis eines Busses
Effizient heisst: geringe Bauteilkosten, einfache Herstellung der Pixel und einfach Verkabelung, idealerweise nur ein Bus von 1-2 Leitungen (zzgl. GND).

== Einleitung ==

Eine RGB-Touch-Matrix besteht aus folgenden Komponenten:

* Steuereinheit (Master), die die Touch-Werte auswertet und entsprechend RGB-Werte an die Pixel (Slave) zurücksendet
* eine größere Zahl (10x10 = 100 oder 10x20 = 200) RGB & Touch-Pixel, die jede Zelle beleuchten und für jede Zelle ein Touch-Sensing durchführen
* einem Bus zwischen diesen Komponenten

== Bus ==

Die RGB-Touch-Pixel sollen über einen Bus verbunden werden. Das könnte entweder ein sternförmiger Bus sein oder eine Daisy-Chain wie die WS2811-Chips ihn bilden.

=== Ein Szenario mit Daisy Chain ===

Es sei eine CLK-Leitung vorausgesetzt, diese könnte jedoch auch implizit durch festes Timing gelöst werden (wie WS2811).

Ablauf:

Zunächst in Richtung MOSI, also Master sendet eine Chain von Daten an den ersten Slave.

* durch eine vorhergehende Pause ist der "LATCH & RESET"-Zustand eingetreten, d.h. alle Slaves wissen: wenn jetzt was kommt, dann ist das der Anfang
* Der Master sendet Bit für Bit an den ersten Slave
* der erste Slave nimmt sich die ersten 8x3=24 Bits und schreibt sie in seinen Zwischenspeicher für den RGB-Wert
* der erste Slave schreibt jedes weitere Bit direkt an den Ausgang ohne es weiter anzusehen
* dasselbe tut jeder weitere Node
* Pause: LATCH & RESET

Das ist die Richtung "RGB an Slaves", von den WS2811 bekannt.

Die Rückrichtung:
es müsste also jetzt beim Master an MISO nach und nach, Bit für Bit die Chain an Daten aus den Slaves ankommen, also muss sich hier das ganze Spektakel umgekehrt abspielen.
Während also die Bits in der "hin"-Richtung durchschieben, müssten ebenfalls die Bits in der Rück-Richtung durchshiften.

* Pause = LATCH & RESET setzt alle Slaves in Startzustand.
* wenn jetzt der erste Slave seine Daten bekommt, dann müsste er einfach gleichzeitig am Ausgang entweder seine oder die Daten des nächsten Node setzen
* er erhält also das erste Bit vom Master. Jetzt setzt er das erste Bit seiner Sensordaten
* nach den ersten 24 Bits (= seine RGB-Daten) sind seine Sensordaten durch (24 Bit Sensor-Daten)
* ab dann lauscht er auf seinem Eingang für Sensordaten vom nächsten Node und er reicht jedes Bit, das dort ankommt direkt an den Master weiter
* spannenderweise passiert es genau zum selben Zeitpunkt, dass er seine 24 Bit RGB-Daten durchhat und dann die weiteren Bits weiterreicht wenn er die Daten des nächsten Node für Rück weiterreichen soll, das läuft also 100% parallel
* der 2. Slave tut genau dasselbe

Nun kommen beim Hinsenden der RGBs genau der Strom an Sensordaten wieder zurück.

Vorteile:
* Die Datenübertragung dauert genauso lange wie es dauert die Daten seriell auf einen Bus zu schicken, da ist keine Zeitverzögerung
* es müssen vom Master keine Nodes addressiert und abgefragt werden, also maximal effizient
* für die bidirektionale Übertragung brauche ich keine Extrazeit, die Rückdaten kommen gleichzeitig
* es ist völlig egal, wieviele Slaves ich habe, solange die Gesamtübertragungrate noch die gewünschte Framerate hergibt. Danach kann man den Bus splitten und z.B. die ganze Kette in 2 Teile trennen und einfach 2x einspeisen, dann kann man mit selber Framerate doppelt soviele Slaves abdecken
* die Übertragung ist maximal Stör-un-anfällig, weil die Distanz zwischen den Clients kurz ist und das Signal jedesmal neu gesendet wird
* man braucht keine Tranceiver, die Attiny sind gleichzeitig die Tranceiver
* man braucht nur 2 Leitungen mit GND, wenn es mit implizitem Takt läuft

Idealerweise hängen alle Slaves einfach an einem Strang als einfachstmögliche Konstellation - einfache Verkabelung, keine mehrfach-Einspeisung in der Software.
Für einen 10x10 RGB-Touch-Tisch sind das 100 Slaves. Jeder hat 24 Bits zu bekommen, ergibt 2400 Bits.
Mal Framerate von 25 ergibt 25 x 2.400 Bits = 60.000 Bits pro Sekunde.
Vorsichtshalber betreiben wir den Bus mit 100 kBit, dann sind wir nicht in einem technisch kritischen Bereich und brauchen nur einen Strang. (Die WS2811 machen 800 kBit, also das 8-fache).
250 kbit sollten noch ebenso einfach machbar sein, dann kann auch ein 10x20 Tisch in einem Strang betrieben werden

Das Protokoll wäre auch mit nur einer Leitung denkbar, wenn noch einbaut, dass man den Slaves mitteilt: jetzt gehört die Leitung Euch!
Zum Beispiel: man sendet eine Chain von 0xffffff an alle (d.h. der RGB-Wert 0xffffff steht nicht zur Verfügung) und weiss: jetzt kommen als nächstes solange Bits zurück (Mode: MISO), bis mindestens eine Pause von xx Millisekunden da ist, dann ist der Mode wieder MOSI.
Man müsste gezielt RGB-Frames dafür ausfallen lassen, d.h. es reduziert die Framerate ein wenig und die Abtastrate der Touches ist auf 5-10/Sekunde begrenzt (das ist ausreichend).
Zum Beispiel: grundsätzliche Framerate 35 FPS, jeder 5. fällt aus für Touch-Sensing, dann habe ich 7x Touch pro Sekunde und 28 RGB-Frames.
Ein Problem mit unregelmässiger Refreshrate gibt es hier nicht, da alle Slaves beim letzten RGB-Wert bleiben und weiterleuchten, nur die Aktualisierung "stockt" für eine 35stel Sekunde, das ist nicht wahrnehmbar.

== RGB & Touch Pixel ==
Ein Pixel soll die Abmaße von 45x45mm bis maximal 50x50mm haben. Um Trennwände zwischen den Pixeln verwenden zu können, sollte auf die Maximalgröße verzichtet werden.

Für die Beleuchtung ist eine RGB vorgesehen, welche über drei verschiedene PWM-Kanäle angesteuert wird. Hierbei sollten mindestens 8bit oder besser 10bit Auflösungen angestrebt werden, um flüssige Übergänge zu erhalten.

Die Idee zur Erkennung ist eine Infrarot-LED zu verwenden, welche eine Wellenlänge von ca. 940-950nm bedient, um einen IR-Strahl auszusenden. Wenn sich ein Objekt über dem Pixel befindet, wird dieser Strahl reflektiert und eine Fotodiode (inkl. Arbeitsbereich 940-950nm) im Pixel erkennt diese Infrarotstrahlen. Dabei muss darauf geachtet werden, dass die IR-LED möglichst nach "oben" strahlt, um nicht direkt die Fotodiode zu beeinflussen. Somit kann die Fotodiode nur eine Reflektion erkennen.
Diese Reflektion kann an der Diode mittels Spannungsabfall über einen ADC ausgewertet werden.

Um die Touch-Erkennung etwas zu "tunen" können Filter verwendet werden. Als Beispiel sei das Umgebungslicht kurz erwähnt. Denn je nach Helligkeit der Umgebung verändert sich die Charakteristik des Touch. Wenn also dies nicht berücksichtigt wird, könnte im zweifelsfall eine Erkennung bei Sonnenschein schwer werden. Ebenso kann die RGB im eigenen Pixel die Helligkeit entschieden verändert, sodass die Fotodiode andere Verhaltensweise vorweist. Um für die Filterung keine zusätzlichen Hardwarekomponenten und Kosten zu erhalten bietet sich eine Softwarelösung an. Beispielsweise könnte die Fotodiode (RGB aus) einen Wert messen und abspeichern. Nun hat man einen Parameter für die Umgebungshelligkeit. Anschließend kann eine Messung (RGB an) einen Parameter liefern wenn auch der Pixel von innen beleuchtet wird.

== Bauteil-Kandidaten ==

* [http://de.aliexpress.com/item/1000PCS-LOT-5050-highlighted-red-green-and-blue-LED-light-emitting-diode-RGB-LED/1759436080.html RGB-LED] 21USD/1000

* [http://de.aliexpress.com/item/free-shipping-10000pcs-lot-5mm-LED-IR-water-clear-led-diode-850nm-940nm-LED-Light-Emitting/1665949654.html IR-LED] 21USD/1000

* [http://de.aliexpress.com/item/2-X-1000-pcs-Lot-3MM-940NM-Photodiode-Infrared-Emission-Controls-FZ0444-Free-Shipping/1508783472.html IR-Photodiode] 50USD/2000

* [http://www.digikey.de/product-detail/de/ATTINY841-SSU/ATTINY841-SSU-ND/4437435 ATtiny841] 1€@500

== Siehe auch ==

* Forumsthread [http://www.mikrocontroller.net/topic/337623 Projektidee RGB Pixel mit Touch] (aktueller Thread für "ein Pixel pro Platine")
* Forumsthread [http://www.mikrocontroller.net/topic/326662 LED Tisch mit Berührungs-/Gegenstandserkennung] (ursprünglicher Thread)
* Forumsthread [http://www.mikrocontroller.net/topic/329090 Schwierigkeiten passenden Bus zu finden]

[[Category:Projekte| ]]

Diskussion:RGB Touch Matrix

2014-06-26T17:11:55Z

Maybee:

== Daisy-Chain / Kommunikation ==

=== SPI ===

Bei der Daisy-Chain könnte man auch einfach MISO vom letzten Slave als Ausgang für die Daten nehmen, dann werden alle x Bits durchgeschoben. Der Master tauscht immer 1 Byte RGB gegen ein Byte Touchdaten. Gelatcht wird dann nicht wenn ein slave 24 bit drinnen hat, sondern wenn clock länger als x µS still war. Damit können die slaves einfache Schieberegister imitieren und man hat die Clock synchron an allen Slaves, damit spart man sich den Delay von jedem Slave in der Chain. --93.188.26.218 26.06.2014 12:53

: Möglichkeiten gibt es viele. Der Charme einer Daisy-Chain mit UART liegt in der einzelnen Kommunikationsleitung: geringstmöglicher Verdrahtungsaufwand. --[[Benutzer:Maybee|Maybee]] ([[Benutzer Diskussion:Maybee|Diskussion]]) 19:11, 26. Jun. 2014 (CEST)

RGB Touch Matrix

2014-06-24T18:44:18Z

Maybee: /* Bauteil-Kandidaten */

''von Conny G.''

Es soll eine RGB Touch Matrix entwickelt werden, die z.B. für RGB-Touch-Tische eingesetzt werden kann.
Beispiel für einen Touch-Tisch: http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html
Dieser ist jedoch vom Hardware-Konzept sehr aufwändig gelöst, deshalb ist das Ziel des Projekts als Kern der Lösung zwei Dinge möglichst effizient zu lösen:
* die einzelnen RGB & Touch Pixel
* die Verbindung der Pixel auf Basis eines Busses
Effizient heisst: geringe Bauteilkosten, einfache Herstellung der Pixel und einfach Verkabelung, idealerweise nur ein Bus von 1-2 Leitungen (zzgl. GND).

== Einleitung ==

Eine RGB-Touch-Matrix besteht aus folgenden Komponenten:

* Steuereinheit, die die Touch-Werte auswertet und entsprechend RGB-Werte an die Pixel zurücksendet
* eine größere Zahl (10x10 = 100 oder 10x20 = 200) RGB & Touch-Pixel, die jede Zelle beleuchten und für jede Zelle ein Touch-Sensing durchführen
* einem Bus zwischen diesen Komponenten

== Bus ==

Die RGB-Touch-Pixel sollen über einen Bus verbunden werden. Das könnte entweder ein sternförmiger Bus sein oder eine Daisy-Chain wie die WS2811-Chips ihn bilden.

=== Ein Szenario mit Daisy Chain ===

Es sei eine CLK-Leitung vorausgesetzt, diese könnte jedoch auch implizit durch festes Timing gelöst werden (wie WS2811).

Ablauf:

Zunächst in Richtung MOSI, also Master sendet eine Chain von Daten an den ersten Slave.

* durch eine vorhergehende Pause ist der "LATCH & RESET"-Zustand eingetreten, d.h. alle Slaves wissen: wenn jetzt was kommt, dann ist das der Anfang
* Der Master sendet Bit für Bit an den ersten Slave
* der erste Slave nimmt sich die ersten 8x3=24 Bits und schreibt sie in seinen Zwischenspeicher für den RGB-Wert
* der erste Slave schreibt jedes weitere Bit direkt an den Ausgang ohne es weiter anzusehen
* dasselbe tut jeder weitere Node
* Pause: LATCH & RESET

Das ist die Richtung "RGB an Slaves", von den WS2811 bekannt.

Die Rückrichtung:
es müsste also jetzt beim Master an MISO nach und nach, Bit für Bit die Chain an Daten aus den Slaves ankommen, also muss sich hier das ganze Spektakel umgekehrt abspielen.
Während also die Bits in der "hin"-Richtung durchschieben, müssten ebenfalls die Bits in der Rück-Richtung durchshiften.

* Pause = LATCH & RESET setzt alle Slaves in Startzustand.
* wenn jetzt der erste Slave seine Daten bekommt, dann müsste er einfach gleichzeitig am Ausgang entweder seine oder die Daten des nächsten Node setzen
* er erhält also das erste Bit vom Master. Jetzt setzt er das erste Bit seiner Sensordaten
* nach den ersten 24 Bits (= seine RGB-Daten) sind seine Sensordaten durch (24 Bit Sensor-Daten)
* ab dann lauscht er auf seinem Eingang für Sensordaten vom nächsten Node und er reicht jedes Bit, das dort ankommt direkt an den Master weiter
* spannenderweise passiert es genau zum selben Zeitpunkt, dass er seine 24 Bit RGB-Daten durchhat und dann die weiteren Bits weiterreicht wenn er die Daten des nächsten Node für Rück weiterreichen soll, das läuft also 100% parallel
* der 2. Slave tut genau dasselbe

Nun kommen beim Hinsenden der RGBs genau der Strom an Sensordaten wieder zurück.

Vorteile:
* Die Datenübertragung dauert genauso lange wie es dauert die Daten seriell auf einen Bus zu schicken, da ist keine Zeitverzögerung
* es müssen vom Master keine Nodes addressiert und abgefragt werden, also maximal effizient
* für die bidirektionale Übertragung brauche ich keine Extrazeit, die Rückdaten kommen gleichzeitig
* es ist völlig egal, wieviele Slaves ich habe, solange die Gesamtübertragungrate noch die gewünschte Framerate hergibt. Danach kann man den Bus splitten und z.B. die ganze Kette in 2 Teile trennen und einfach 2x einspeisen, dann kann man mit selber Framerate doppelt soviele Slaves abdecken
* die Übertragung ist maximal Stör-un-anfällig, weil die Distanz zwischen den Clients kurz ist und das Signal jedesmal neu gesendet wird
* man braucht keine Tranceiver, die Attiny sind gleichzeitig die Tranceiver
* man braucht nur 2 Leitungen mit GND, wenn es mit implizitem Takt läuft

Idealerweise hängen alle Slaves einfach an einem Strang als einfachstmögliche Konstellation - einfache Verkabelung, keine mehrfach-Einspeisung in der Software.
Für einen 10x10 RGB-Touch-Tisch sind das 100 Slaves. Jeder hat 24 Bits zu bekommen, ergibt 2400 Bits.
Mal Framerate von 25 ergibt 25 x 2.400 Bits = 60.000 Bits pro Sekunde.
Vorsichtshalber betreiben wir den Bus mit 100 kBit, dann sind wir nicht in einem technisch kritischen Bereich und brauchen nur einen Strang. (Die WS2811 machen 800 kBit, also das 8-fache).
250 kbit sollten noch ebenso einfach machbar sein, dann kann auch ein 10x20 Tisch in einem Strang betrieben werden

Das Protokoll wäre auch mit nur einer Leitung denkbar, wenn noch einbaut, dass man den Slaves mitteilt: jetzt gehört die Leitung Euch!
Zum Beispiel: man sendet eine Chain von 0xffffff an alle (d.h. der RGB-Wert 0xffffff steht nicht zur Verfügung) und weiss: jetzt kommen als nächstes solange Bits zurück (Mode: MISO), bis mindestens eine Pause von xx Millisekunden da ist, dann ist der Mode wieder MOSI.
Man müsste gezielt RGB-Frames dafür ausfallen lassen, d.h. es reduziert die Framerate ein wenig und die Abtastrate der Touches ist auf 5-10/Sekunde begrenzt (das ist ausreichend).
Zum Beispiel: grundsätzliche Framerate 35 FPS, jeder 5. fällt aus für Touch-Sensing, dann habe ich 7x Touch pro Sekunde und 28 RGB-Frames.
Ein Problem mit unregelmässiger Refreshrate gibt es hier nicht, da alle Slaves beim letzten RGB-Wert bleiben und weiterleuchten, nur die Aktualisierung "stockt" für eine 35stel Sekunde, das ist nicht wahrnehmbar.

== RGB & Touch Pixel ==

== Bauteil-Kandidaten ==

* [http://de.aliexpress.com/item/1000PCS-LOT-5050-highlighted-red-green-and-blue-LED-light-emitting-diode-RGB-LED/1759436080.html RGB-LED] 21USD/1000

* [http://de.aliexpress.com/item/free-shipping-10000pcs-lot-5mm-LED-IR-water-clear-led-diode-850nm-940nm-LED-Light-Emitting/1665949654.html IR-LED] 21USD/1000

* [http://de.aliexpress.com/item/2-X-1000-pcs-Lot-3MM-940NM-Photodiode-Infrared-Emission-Controls-FZ0444-Free-Shipping/1508783472.html IR-Photodiode] 50USD/2000

* [http://www.digikey.de/product-detail/de/ATTINY841-SSU/ATTINY841-SSU-ND/4437435 ATtiny841] 1€@500

== Siehe auch ==

* Forumsthread [http://www.mikrocontroller.net/topic/326662 LED Tisch mit Berührungs-/Gegenstandserkennung]
* Forumsthread [http://www.mikrocontroller.net/topic/329090 Schwierigkeiten passenden Bus zu finden]
* [[Audio-Projekt|Link zu anderem Projekt]]

[[Category:Projekte| ]]

AVR Typen

2014-06-20T22:27:17Z

Maybee: aktualisierter Link

== AT90S ==
Die "Basic Line" der Atmel [[AVR]]-Reihe. Sie beinhaltet die ersten [[AVR|AVRs]] die produziert wurden und deren Bezeichnung mit "AT90S" beginnt. Alle Typen wurden mit der Zeit von den beiden Nachfolgereihen ersetzt: ATmega bzw. ATtiny.

Einige neue AVR-Controller tragen eine mit AT90-''ohne S'' beginnende Bezeichnung, haben aber einen "moderneren" Kern. Z.B. sind die Typen AT90PWM2/3 und AT90CAN128 vom Funktionsumfang (interner RC, USART etc.) den ATmegas zuzuordnen.

== ATmega ==
Die ATmega-[[Mikrocontroller]] sind ein Teil der AVR-Controllerfamilie. Zusammen mit den ATtiny lösen die ATmega die AT90S-Serie schrittweise ab, wobei es in den meisten Fällen weitgehend pin- und funktionskompatiblen Ersatz für abgekündigte Controller gibt (ATmega8 bzw. ATmega8A statt AT90S4433, ATmega8515 statt AT90S8515 usw.).

Atmel ATmega AVRs werden mit aktiviertem internem Taktgeber ausgeliefert. Schließt man eine andere externe Taktquelle an (Quarz, Quarzoszillator o.ä), wird diese nicht automatisch genutzt. Zum Aktivieren müssen die Fuse-Bits des Controllers entsprechend eingestellt werden (siehe Datenblatt).

ATmegas mit integriertem [[JTAG]]-Interface (z.Zt. solche ab 16kB Flash-Speicher und mehr als 28 Pins) werden ab Werk mit aktiviertem JTAG-Interface ausgeliefert. Dieses Interface belegt vier Port-Pins (z. B. am PORTC bei ATmega16/32), die nicht für eigene Anwendungen genutzt werden können, solange das JTAG-Interface aktiviert ist. Das Interface lässt sich über ein Fuse-Bit (JTAGEN) dauerhaft und über ein Bit (JTD) in dem (oder einem der) MC-Kontroll-Register (Datenblatt nach JTD durchsuchen) per Software zur Laufzeit an- und abschalten. Weiteres im Datenblatt des jeweiligen Controllers in den Abschnitten Memory-Programming (Fuse) und JTAG/ICE (JTD).

Beim ATmega128 ist ab Werk die Mega103-Kompatibilitäts-fuse gesetzt. Um alle Erweiterungen des Mega128 gegenüber dem Mega103 zu nutzen muss diese deaktivert werden. Diese Fuse sorgt außerdem dafür, dass das SRAM in einem anderen Adressbereich liegt. Dadurch funktionieren C-Programme nur bis zum ersten Funktionsaufruf. Siehe auch [[AVR_Checkliste#Besonderheiten_bei_ATmega128_und_seinen_Derivaten_im_64-Pin-Gehäuse | AVR Checkliste: Besonderheiten bei ATmega64 / ATmega128]]

== ATtiny ==

Die ATtiny stellen das untere Ende der neuen AVR Linie von Atmel dar und waren zunächst durch das Fehlen von internem [[RAM#SRAM|SRAM]] gekennzeichnet. Mittlerweile gibt es aber so bemerkenswerte Controller wie den ATtiny4313, deren Möglichkeiten und Funktionen den ATmegas in nichts nachstehen.

Ein weiterer Unterschied zu den ATmegas ist der fehlende Hardwaremultiplizierer. Jede Multiplikation muss also in Software ausgeführt werden. Eine Übersicht über die Verfügbarkeit verschiedener Befehle bietet die [[AVR_Assembler_-_Vergleichstabelle|AVR-Assembler Befehlsvergleichstabelle]].

== ATxmega ==
Neueste Generation von AVR-Controllern mit neuem internen Aufbau, hoher Taktrate (32 MHz), niedriger Spannung (1,6 - 3,6V), vielen Schnittstellen, in 44 - 100 poligen SMD-Gehäusen. Besonderheiten: ADC mit 2 Megasample/12 Bit, vierpoliges Programm- und Debug- Interface PDI (VTref, CLK, DATA, GND) erfordert z.B. einen AVR_JTAGICE-mkII Programmer. PDI (Flash und Debug) funktioniert mit C-Code z.B. mit AVR Studio 4.19.

Leider ist die Xmega-Reihe zu den AVR-Prozessoren der Mega- oder Tiny-Serien nicht kompatibel (viel komplizierter, anderer Aufbau der IO-Baugruppen, der Interrupts, der C-Funktionen etc.). Prozessor-Manuals zeigen weder Assembler noch C-Beispiele für Ansteuerung der IO-Baugruppen. C-Programmbeispiele (geeignet für AVR-Studio) findet man erst in Xmega Application Notes. Einen Überblick gibt es von [http://www.stromflo.de/dokuwiki/doku.php?id=xmega-c-tutorial Florian Grotz] oder in dem [http://www.jtronics.de/avr-projekte/xmega-tutorial.html jtronics Xmega Tutorial] .

== Sonstiges ==

Die AT89-Familie gehört nicht zu den AVR-Typen mit dem AVR-RISC-Befehlssatz, sondern ist eine [[8051|Intel-8051]]-kompatible 8-Bit µC-Serie.

=== Tiny vs Mega ===
Die modernen Typen sind die Tiny (=winzig) und die Mega (=riesig). Die ATTiny haben kleinere Gehäuse als die ATMega, mit weniger Pins. Dies führt bei ähnlicher Funktionalität wie die Megas zu extremen Mehrfachbelegungen der Pins und auch eher zu Überschneidungen der Pinfunktionalität. Die Tiny sind daher eher für sehr hohe Stückzahlen geeignet, wo die Einsparung über die Stückzahl kommt. Anfänger und Bastler sind mit den ATMega besser bedient, da es weniger Limitierungen gibt.

Tinys haben keinen Hardware-Multiplizierer.

==Nomenklatur==
===ATmega===
Auch wenn die Namensgebung auf den ersten Blick bedingt durch die vielen verfügbaren Modelle kompliziert aussieht, so folgt sie doch immer (von wenigen Ausnahmen abgesehen) einem einfachen Schema.

Nehmen wir einen aktuellen Baustein als Beispiel: *ATmega48PA-AU*. Der Name besteht aus 5 Teilen:
# Der Baureihe (hier: "ATmega")
# Einer Nummer, immer eine Zweierpotenz (hier: 4). Diese Zahl gibt die Größe des Flashspeichers in [https://de.wikipedia.org/wiki/Kibibyte Kibibyte] an.
# Bis zu zwei weiteren Ziffern (hier: 8). Sie definieren die Zusatzfunktionen sowie Zahl der I/O-Ports.
# Bis zu zwei Buchstaben (hier: PA), die für die Revision sowie spezielle stromsparende Architekturen stehen.
# Einem Bindestrich und zwei weiteren Buchstaben, die die Bauform angeben (hier: AU).

====Baureihe====

Hier gibt es nur zwei Reihen: Den kleinen ATtiny mit reduziertem Funktionsumfang und den großen ATmega.

====Speichergröße====

Während die Größe des Flashspeichers (Programmspeicher) direkt im Namen angegeben ist, ergibt sich die Größe von RAM und EEPROM nur indirekt aus dieser Nummer, wobei natürlich die Bausteine mit großem Flash auch mehr RAM und EEPROM haben als kleinere. Grob gilt diese Zuordnung:

{| class="wikitable"
|-
! Flash (kB) !! EEPROM (B) !! RAM (B)
|-
| 2 || tiny: 128 || tiny: 128
|-
| 4 || tiny: var., mega: 256 || tiny: 256, mega: 512
|-
| 8 || tiny: var., mega: 512 || tiny: 512, mega: 1024
|-
| 16 || 512 || 1024
|-
| 32 || 1024 || 2048
|-
| 64 || 2048*) || 4096*)
|-
| 128 - 256 || 4096 || 4K - 16K
|}
*)Atmega640 verfügt über den doppelten Speicher

====Zusatzfunktionen / Größe====
Die Ziffer(n) nach der Flashgröße geben die Ausstattungsmerkmale des Bausteins an. Die folgende Tabelle gilt für die Atmega-Reihe:
{| class="wikitable"
|-
! Ziffer !! Beschreibung
|-
| - || Keine Ziffer markiert die Bausteine der ersten Generation. Sie verfügen in der Regel über eine niedrigere maximale Taktrate (8/16 MHz anstatt 10/20 MHz), eine höhere Minimal-Spannung (2,7 anstatt 1,8 Volt), weniger Interrupt-Quellen und PWM-Kanäle
|-
| 0 || Reihe von 32 - 256 kB in einem größeren Gehäuse mit höherer Anzahl an I/O-Pins. Etwas älter als die aktuellen Reihen 4 und 8.
|-
| 1 || Kennzeichnet eine verbesserte Version des Atmega128 / 256, aber älter als aktuelle 4er Reihe
|-
| 4 || Reihe von 16 bis 128 kB Flash, alle pinkompatibel in 40-44 poligem Gehäuse. Neueste Baureihe, alle in pico-power-Technologie mit vielen verbesserten Funktionen wie externen Interrupts, Timern, USART...
|-
| 5 || Reihe von 16 bis 64 kB
|-
| 8 || Reihe von 4 bis 32 kB, alle pinkompatibel in 28-32 poligem Gehäuse. Neueste Baureihe, alle in pico-power-Technologie mit vielen verbesserten Funktionen wie externen Interrupts, Timern, USART.... (auch in der Attiny-Reihe vorhanden)
|-
| 9 || Reihe von 16 bis 64 kB mit integriertem Controller für LC-Displays, folglich in großen Gehäusen (64-/100-polig)
|}
Aus dieser Liste stechen einige Bausteine als Außenseiter hervor:
* Atmega8515 / Atmega8535
* Atmega640: Im Prinzip ein Atmega64 mit deutlich mehr Hardware-Ressourcen (4 UARTs, 16 ADC-Kanäle...) und doppelt soviel EEPROM / SRAM.

====Revision / Architektur====
Die (optionalen) Buchstaben vor dem Bindestrich geben Auskunft über den Stromverbrauch und Spannungsbereich
{| class="wikitable"
|-
! Buchstabe !! Beschreibung
|-
| A || Zweite Revision - meist nur eine Umstellung der internen Strukturen ohne Auswirkung für den Benutzer
|-
| L / V || "Low-Voltage": Speziell für niedrigere Taktraten (8 bzw. 10 MHz) sowie niedrigere Eingangsspannungen (1,8 bzw. 2,7V) selektierte Bausteine
|-
| P/PA || "Pico-Power": Reduzierter Stromaufnahme, besonders in tiefen Sleep-Modes (< 1uA); Manche Bausteine (z.B. Mega48) gibt es als P und PA
|}

==== Bauform====
Die beiden Buchstaben nach dem Bindestrich geben Auskunft über die Bauform. Die Zahl der Pins des jeweiligen Gehäusetyps hängt vom Baustein ab.
{| class="wikitable"
|-
! Buchstaben !! Beschreibung
|-
| A || TQFP-Gehäuse
|-
| C || BGA-Gehäuse
|-
| I || Bleihaltig - nicht mehr erhältlich
|-
| J || PLCC-Gehäuse
|-
| M || (V)QFN- / MLF- Gehäuse
|-
| P || DIP-Gehäuse (bastlerfreundlich!)
|-
| S || SOIC-Gehäuse
|-
| U || Bleifrei, RoHS-kompatibel
|-
| X || TSSOP-Gehäuse
|}

===ATtiny===
Bei den ATtiny-Bausteinen ist die Nummerierung deutlich unübersichtlicher als in der ATmega-Reihe. Die erste Ziffer gibt wie auch bei ATmega die Größe des Flash-Speichers an. Die obenstehenden Tabellen für Baureihe, Bauform, Revision und Speichergröße gelten ebenfalls (Ausnahmen: ATtiny5 mit 0,5 Kilobytes Flash sowie ATtiny4 und ATtiny9 mit 0,5 bzw. 1 kB Flash). Die Zusatzfunktionen und Baugröße sind aber nicht deutlich

== Vergleichstabelle(n) / Ausstattung ==
=== AT90S - Reihe ===
{| class="wikitable sortable" style="font-size:10px;" id="AVR_Features_AT90S"
|-
!Typ||Flash (Kbytes)||EEPROM (Bytes)||SRAM (Bytes)||Max I/O Pins||F.max (MHz)||Vcc (V)||Analog Comparator||16-bit Timer||8-bit Timer||Brown Out Detector||On Chip Oscillator||PWM Channels||RTC||Self Program Memory||Boot Code||SPI||TWI (I2C)||UART||Watchdog||Bauform
|- 
|[http://www.atmel.com/dyn/resources/prod_documents/doc0839.pdf AT90S2313]<ref>veraltet → ATtiny2313</ref>
|2
|128
|128
|15
|10
|2.7-6.0
|Ja
|1
|1
|Nein
|Nein
|1
|Nein
|Nein
|Nein
|Ja
|Nein
|Ja
|Ja
|PDIP20 SOIC20
|- 
|[http://www.atmel.com/atmel/acrobat/doc1004.pdf AT90S2323]<ref>veraltet → ATtiny25/45/85</ref>
|2
|128
|128
|3
|10
|2.7-6.0
|Nein
|0
|1
|Nein
|Nein
|0
|Nein
|Nein
|Nein
|Ja
|Nein
|Nein
|Ja
|PDIP8 SOIC8
|- 
|[http://www.atmel.com/atmel/acrobat/doc1004.pdf AT90S2343]<ref>veraltet → ATtiny25/45/85</ref>
|2
|128
|128
|5
|10
|2.7-6.0
|Nein
|0
|1
|Nein
|Ja
|0
|Nein
|Nein
|Nein
|Ja
|Nein
|Nein
|Ja
|PDIP8 SOIC8
|- 
|[http://www.atmel.com/atmel/acrobat/doc0841.pdf AT90S8515]<ref>veraltet → ATmega16/162/32/644</ref>
|8
|512
|512
|32
|8
|2.7-6.0
|Ja
|1
|1
|Nein
|Nein
|1 (16-Bit)
|Nein
|Nein
|Nein
|Ja
|Nein
|Ja
|Ja
|PDIP40 PLCC44 TQFP44


|}

=== ATtiny - Reihe ===
{| class="wikitable sortable" style="font-size:10px;" id="AVR_Features_ATtiny"
|-
!Typ||Flash (Kbytes)||EEPROM (Bytes)||SRAM (Bytes)||Max I/O Pins||F.max (MHz)||Vcc (V)||A/D Channels||Analog Comparator||16-bit Timer||8-bit Timer||Brown Out Detector||On Chip Oscillator||PWM Channels||RTC||Self Program Memory||Boot Code||SPI||TWI (I2C)||UART||Watchdog||Bauform(en)||Preis
|-
|[http://www.atmel.com/Images/doc8127.pdf ATtiny10]
|1
| --
|32
|4
|12
|1.8-5.5
|4 8-bit
|Ja
|1
| --
|Nein
|Ja
|2
|Nein
|Nein
|Nein
|Ja
|Nein
|Nein
|Ja
|SOT23
| 0.83-0.99
|-
|[http://www.atmel.com/dyn/resources/prod_documents/doc1006.pdf ATtiny11]
|1
| --
| --
|6
|6
|2.7-5.5
| --
|Ja
| --
|1
|Nein
|Nein
| --
|Nein
|Nein
|Nein
|Nein
|Nein
|Nein
|Ja
|PDIP8 SOIC8
| 0.58-0.87
|-
|[http://www.atmel.com/dyn/resources/prod_documents/doc1006.pdf ATtiny12]
|1
|64
| --
|6
|8
|1.8-5.5
| --
|Ja
| --
|1
|Ja
|Ja
| --
|Nein
|Nein
|Nein
|Ja
|Nein
|Nein
|Ja
|PDIP8 SOIC8
| 1.00-1.20
|-
|[http://www.atmel.com/Images/doc8126.pdf ATtiny13A]
|1
|64
|64
|6
|20
|1.8-5.5
|4 10bit
|Ja
| --
|1
|Ja
|Ja
|1<ref>Timer-PWM</ref>
|Nein
|Ja
|Ja
|Ja
|Nein
|Nein
|Ja
|PDIP8 SOIC8
| 0.60-1.20
|-
|[http://www.atmel.com/dyn/resources/prod_documents/doc1187.pdf ATtiny15]
|1
|64
| --
|6
|1.6
|2.7-5.5
|4 10bit
|Ja
| --
|2
|Ja
|ONLY
|1<ref>150kHz 8bit</ref>
|Nein
|Nein
|Nein
|Ja
|Nein
|Nein
|Ja
|PDIP8 SOIC8
| 1.15
|-
|[http://www.atmel.com/Images/Atmel-2586-AVR-8-bit-Microcontroller-ATtiny25-ATtiny45-ATtiny85_Datasheet.pdf ATtiny45]
|4
|256
|256
|6
|20
|2.7-5.5
|4
|Ja
| --
|2
|Ja
|Ja
|2
|Nein
|Ja
|Nein
|Ja
|Nein
|Nein
|Ja
|PDIP8 SOIC8
| 0.90-2.00
|-
|[http://www.atmel.com/dyn/resources/prod_documents/doc2586.pdf ATtiny85]
|8
|512
|512
|6
|20
|1.8-5.5
|4
|Ja
| --
|2
|Ja
|Ja
|2
|Nein
|Ja
|Nein
|Ja
|Nein
|Nein
|Ja
|PDIP8 SOIC8
| 0.90-2.00
|-
|[http://www.atmel.com/dyn/resources/prod_documents/doc2543.pdf ATtiny2313]
|2
|128
|128
|18
|20
|2.7-5.5
| --
|Ja
|1
|1
|Ja
|Ja
|4
|Nein
|Ja
|Ja
|Ja<ref name="usip">+USI</ref>
|Ja<ref name="usi">USI</ref>
|Ja<ref name="usart">USART</ref>
|Ja
|PDIP20 SOIC20 QFN20 MLF20
| 1.30
|-
|[http://www.atmel.com/Images/doc8246.pdf ATtiny4313]
|4
|256
|256
|18
|20
|1.8-5.5
| --
|Ja
|1
|1
|Ja
|Ja
|4
|Nein
|Ja
|Ja
|Ja<ref name="usip">+USI</ref>
|Ja<ref name="usi">USI</ref>
|Ja<ref name="usart">USART</ref>
|Ja
|PDIP20 SOIC20 QFN20 MLF20
| 1.00-2.00
|-
|[http://atmel.com/dyn/resources/prod_documents/doc8006.pdf ATtiny24]
|2
|128
|128
|12
|20
|2.7-5.5
|8 10bit
|Ja
|Ja
|Ja
|Ja
|Ja
|4
|Nein
|Ja
|Ja
|Ja<ref name="usip">+USI</ref>
|Ja<ref name="usi">USI</ref>
|Nein
|Ja
|PDIP14 SOIC14 QFN20/MLF20
|0.85
|-
|[http://www.atmel.com/Images/doc8183.pdf ATtiny84A]
|8
|512
|512
|12
|20
|1.8-5.5
|8 10bit
|Ja
|Ja
|Ja
|Ja
|Ja
|4
|Nein
|Ja
|Ja
|Ja<ref name="usip">+USI</ref>
|Ja<ref name="usi">USI</ref>
|Nein
|Ja
|PDIP14 SOIC14 QFN20/MLF20
|1,00-4,00
|-
|[http://atmel.com/dyn/resources/prod_documents/doc2588.pdf ATtiny261]
|2
|128
|128
|16
|20
|1,8-5,5
|11
|1
|1
|1
|Ja
|Ja
|2
|Nein
|Ja
|Ja
|Ja<ref name="usip">+USI</ref>
|Ja<ref name="usi">USI</ref>
|Nein
|Ja
|PDIP20 SOIC20 MLF20 (TSSOP20 bei Tiny261A)
|1,15
|}

=== ATmega - Reihe ===
{| class="wikitable sortable" style="font-size:10px;" id="AVR_Features_ATMega"
|-
!Typ||Flash (Kbytes)||EEPROM (Bytes)||SRAM (Bytes)||Max I/O Pins||F.max (MHz)||Vcc (V)||A/D Channels||Analog Comparator||16-bit Timer||8-bit Timer||Brown Out Detector||On Chip Oscillator||PWM Channels||RTC||Self Program Memory||Boot Code||SPI||TWI (I2C)||UART||Watchdog||Bauform||Preis
|-
|[http://www.atmel.com/dyn/resources/prod_documents/2486S.pdf ATmega8] [http://www.atmel.com/Images/Atmel-8159-8-bit-AVR-microcontroller-ATmega8A_datasheet.pdf ATmega8A]
|8
|512
|1K
|23
|16
|2.7-5.5
|6 10bit PDIP 8 10bit TQFP QFN/MLF
|Ja
|1
|2
|Ja
|Ja
|3
|Ja
|Ja
|Ja
|Ja
|Ja
|Ja USART
|Ja
|PDIP28 TQFP32 QFN/MLF32
| 1.50-4.00
|-
|[http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf ATmega16]
|16
|512
|1K
|32
|16
|2.7-5.5
|8 10bit
|Ja
|1
|2
|Ja
|Ja
|4
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Ja
|1<ref name="usart">USART</ref>
|Ja
|PDIP40 TQFP44 QFN/MLF44
| 2.60-2.85
|-
|[http://www.atmel.com/dyn/resources/prod_documents/doc2513.pdf ATmega162]
|16
|512
|1K
|35
|16
|2.7-5.5
|Keine
|Ja
|2
|2
|Ja
|Ja
|6
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Nein
|2<ref name="usart">USART</ref>
|Ja
|PDIP40 TQFP44 QFN/MLF44
| 2.70-3.80
|-
|[http://www.atmel.com/dyn/resources/prod_documents/doc2503.pdf ATmega32]
|32
|1K
|2K
|32
|16
|2.7-5.5
|8 10bit
|Ja
|1
|2
|Ja
|Ja
|4
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Ja
|1<ref name="usart">USART</ref>
|Ja
|PDIP40 TQFP44 QFN/MLF44
| 3.20-4.60
|-
|[http://www.atmel.com/Images/doc8271.pdf ATmega48A]
|4
|256
|512
|23
|20
|1.8-5.5
|6 10bit PDIP 8 10bit TQFP QFN/MLF
|Ja
|1
|2
|Ja
|Ja
|6
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Ja
|1<ref name="usart">USART</ref>
|Ja
|PDIP28 TQFP32 QFN/MLF32
| 2.00-4.50
|-
|[http://www.atmel.com/Images/doc8271.pdf ATmega88A]
|8
|512
|1K
|23
|20
|1.8-5.5
|6 10bit PDIP 8 10bit TQFP QFN/MLF
|Ja
|1
|2
|Ja
|Ja
|6
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Ja
|1<ref name="usart">USART</ref>
|Ja
|PDIP28 TQFP32 QFN/MLF32
| 2.00-4.50
|-

|[http://www.atmel.com/Images/doc8011.pdf ATmega164]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|PDIP40 TQFP44 QFN/MLF44
| 2.00-4.50
|-

|[http://www.atmel.com/Images/doc8271.pdf ATmega168A]
|16
|512
|1K
|23
|20
|1.8-5.5
|6 10bit PDIP 8 10bit TQFP QFN/MLF
|Ja
|1
|2
|Ja
|Ja
|6
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Ja
|1<ref name="usart">USART</ref>
|Ja
|PDIP28 TQFP32 QFN/MLF32
| 2.00-4.50
|-

|[http://www.atmel.com/Images/doc8271.pdf ATmega328]
|32
|1K
|2K
|23
|20
|1.8-5.5
|6 10bit PDIP 8 10bit TQFP QFN/MLF
|Ja
|1
|2
|Ja
|Ja
|6
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Ja
|1<ref name="usart">USART</ref>
|Ja
|PDIP28 TQFP32 QFN/MLF32
| 2.00-4.50
|-
|[http://www.atmel.com/Images/doc8272.pdf ATmega324A]
|32
|1K
|2K
|32
|20
|1.8-5.5
|8 10bit
|Ja
|1
|2
|Ja
|Ja
|6
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Ja
|2
|Ja
|PDIP40 TQFP44 VQFN44 QFN/MLF44 DRQFN44 VFBGA49
| 3.50-4.50
|-
|[http://www.atmel.com/atmel/acrobat/doc2490.pdf ATmega64]<ref>Geliefert im ATmega103-Modus. Fuse ändern!</ref>
|64
|2K
|4K
|53
|16
|2.7-5.5
|8 10bit
|Ja
|2
|2
|Ja
|Ja
|2 8bit, 6 2-16bit
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Ja
|1<ref name="usart">USART</ref>
|Ja
| TQFP64 QFN/MLF64
| 7.50-9.50
|-
|[http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf ATmega644]
|64
|2K
|4K
|32
|20
|1.8-5.5
|8 10bit
|Ja
|1
|2
|Ja
|Ja
|6
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Ja
|1<ref name="usart">USART</ref> 2<ref>beim 644P</ref>
|Ja
|PDIP40 TQFP44 QFN/MLF44
| 6.80-7.50
|-
|[http://www.atmel.com/dyn/resources/prod_documents/doc2467.pdf ATmega128]
|128
|4K
|4K
|53
|16
|2.7-5.5
|8 10bit
|Ja
|2
|2
|Ja
|Ja
|2 8bit 6 2-16bit
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Ja
|2<ref name="usart">USART</ref>
|Ja
|TQFP64 QFN/MLF64
|8.05-8.40
|-
|[http://www.atmel.com/dyn/products/product_card.asp?part_id=4331 ATmega1284P]
|128
|4K
|16K
|32
|20
|1.8-5.5
|8 10bit
|Ja
|2
|2
|Ja
|Ja
|6
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Ja
|2<ref name="usart">USART</ref>
|Ja
|PDIP40 TQFP44 QFN/MLF44
|5.00-7.00
|-
|[http://www.atmel.com/dyn/resources/prod_documents/doc2549.pdf ATmega2560]
|256
|4K
|8K
|86
|16
|2.7-5.5
|16 10bit
|Ja
|4
|2
|Ja
|Ja
|16
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Ja
|4<ref name="usart">USART</ref>
|Ja
|TQFP100
|8.00-15.00
|-
|[http://www.atmel.com/atmel/acrobat/doc2512.pdf ATmega8515]
|8
|512
|512
|35
|16
|2.7-5.5
|Keine
|Ja
|1
|1
|Ja
|Ja
|1 8-bit, 1 16-bit
|Nein
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Nein
|1<ref name="usart">USART</ref>
|Ja
|PDIP40 TQFP44 PLCC44 QFN/MLF44
|3.20-3.90
|-
|[http://www.atmel.com/atmel/acrobat/doc2502.pdf ATmega8535]
|8
|512
|512
|32
|16
|2.7-5.5
|8 10bit
|Ja
|1
|2
|Ja
|Ja
|2 8-bit, 2 16-bit
|Ja
|Ja
|Ja
|Ja<ref name="ms">Master/Slave</ref>
|Ja
|1<ref name="usart">USART</ref>
|Ja
|PDIP44 PLCC44 QFN/MLF44
|3.15-3.75



|}

Hinweis: Die angegebenen Preise sind Richtwerte. Es empfiehlt sich die Verwendung einer Preissuchmaschine, z.B. [http://www.google.de/shopping google.de/shopping].

=== ATXMega - Reihe ===
{| class="wikitable sortable" style="font-size:10px;" id="AVR_Features_ATXMega"
|-
!Typ||Flash (Kbytes)||EEPROM (KBytes)||SRAM (KBytes)||Boot (Kbytes)||Max I/O Pins||F.max (MHz)||Vcc (V)||ADC||DAC||PWM Channels||16-Bit Timer||SPI||TWI (I2C)||UART||Bauformen
|-
|ATxmega16a4
|16
|1
|2
|4
|34
|32
|1,6 - 3,6
|12-CH @ 12-Bit
|2-CH @ 12-Bit
|16
|5
|2
|2
|5
|TQFP44
|-
|ATxmega32a4
|32
|1
|4
|4
|34
|32
|1,6 - 3,6
|12-CH @ 12-Bit
|2-CH @ 12-Bit
|16
|5
|2
|2
|5
|TQFP44
|-
|ATxmega64a4
|64
|2
|4
|4
|34
|32
|1,6 - 3,6
|12-CH @ 12-Bit
|2-CH @ 12-Bit
|16
|5
|2
|2
|5
|TQFP44
|-
|ATxmega128a4
|128
|2
|8
|8
|34
|32
|1,6 - 3,6
|12-CH @ 12-Bit
|2-CH @ 12-Bit
|16
|5
|2
|2
|5
|TQFP44
|-
|ATxmega64a3
|64
|2
|4
|4
|50
|32
|1,6 - 3,6
|2x 8-CH @ 12-Bit
|2-CH @ 12-Bit
|22
|7
|3
|2
|7
|TQFP64
|-
|ATxmega128a3
|128
|2
|8
|8
|50
|32
|1,6 - 3,6
|2x 8-CH @ 12-Bit
|2-CH @ 12-Bit
|22
|7
|3
|2
|7
|TQFP64
|-
|ATxmega192a3
|192
|2
|16
|8
|50
|32
|1,6 - 3,6
|2x 8-CH @ 12-Bit
|2-CH @ 12-Bit
|22
|7
|3
|2
|7
|TQFP64
|-
|ATxmega256a3
|256
|4
|16
|8
|50
|32
|1,6 - 3,6
|2x 8-CH @ 12-Bit
|2-CH @ 12-Bit
|22
|7
|3
|2
|7
|TQFP64
|-
|ATxmega64a1
|64
|2
|4
|4
|78
|32
|1,6 - 3,6
|2x 8-CH @ 12-Bit
|2x 2-CH @ 12-Bit
|24
|8
|4
|4
|8
|TQFP100
|-
|ATxmega128a1
|128
|2
|8
|8
|78
|32
|1,6 - 3,6
|2x 8-CH @ 12-Bit
|2x 2-CH @ 12-Bit
|24
|8
|4
|4
|8
|TQFP100
|-
|ATxmega192a1
|192
|2
|16
|8
|78
|32
|1,6 - 3,6
|2x 8-CH @ 12-Bit
|2x 2-CH @ 12-Bit
|24
|8
|4
|4
|8
|TQFP100
|-
|ATxmega256a1
|256
|4
|16
|8
|78
|32
|1,6 - 3,6
|2x 8-CH @ 12-Bit
|2x 2-CH @ 12-Bit
|24
|8
|4
|4
|8
|TQFP100
|-
|ATxmega384a1
|384
|4
|32
|8
|78
|32
|1,6 - 3,6
|2x 8-CH @ 12-Bit
|2x 2-CH @ 12-Bit
|24
|8
|4
|4
|8
|TQFP100
|-
|ATxmega16d4
|16
|1
|2
|4
|34
|32
|1,6 - 3,6
|12-CH @ 12-Bit
|0
|16
|4
|2
|2
|2
|TQFP44
|-
|ATxmega32d4
|32
|1
|4
|4
|34
|32
|1,6 - 3,6
|12-CH @ 12-Bit
|0
|16
|4
|2
|2
|2
|TQFP44
|-
|ATxmega64d4
|64
|2
|4
|4
|34
|32
|1,6 - 3,6
|12-CH @ 12-Bit
|0
|16
|4
|2
|2
|2
|TQFP44
|-
|ATxmega128d4
|128
|2
|8
|8
|34
|32
|1,6 - 3,6
|12-CH @ 12-Bit
|0
|16
|4
|2
|2
|2
|TQFP44
|-
|ATxmega64d3
|64
|2
|4
|4
|50
|32
|1,6 - 3,6
|16-CH @ 12-Bit
|0
|18
|5
|2
|2
|3
|TQFP64
|-
|ATxmega128d3
|128
|2
|8
|8
|50
|32
|1,6 - 3,6
|16-CH @ 12-Bit
|0
|18
|5
|2
|2
|3
|TQFP64
|-
|ATxmega192d3
|192
|2
|16
|8
|50
|32
|1,6 - 3,6
|16-CH @ 12-Bit
|0
|18
|5
|2
|2
|3
|TQFP64
|-
|ATxmega256d3
|256
|4
|16
|8
|50
|32
|1,6 - 3,6
|16-CH @ 12-Bit
|0
|18
|5
|2
|2
|3
|TQFP64
|}

== Weitere Vergleichstabellen ==
Vergleichstabellen zum Downloaden gibt es unter Anderem
* [http://www.mikrocontroller.net/topic/242328 von Andreas], Stand 19.12.2011; vollständig,
* [http://www.mikrocontroller.net/topic/232939 von Sven], Stand 22.09.2011; weiter eingedampft.

=== ATtiny ===

{| class="wikitable sortable" style="font-size:10px;" id="AVR_Features_ATtiny"
|+ Device-specific Features  
|- valign="top"
! Device
! Flash [KiB]
! Pin Anzahl
! Max. &fnof;CPU [MHz]
! of Touch Kanäle
! Hardware Qtouch
! Max I/O Pins
! Ext Interrupts
! SPI
! TWI
! UART
! LIN
! ADC Kanäle
! ADC Auflösung [bits]
! ADC Speed [ksps]
! Temp. Sensor
! SRAM [KiB]
! EEPROM [Bytes]
! Self Program Memory
! picoPower
! Temp. Bereich [°C]
! I/O Supply Class [V]
! Operating Voltage [VCC]
! Timers
! Output Compare Kanäle
! Input Capture Kanäle
! PWM Kanäle
! 32kHz RTC
! Device
|-
| ATtiny28L || 2 || 28 || 4 || — || — || 11 || 10 || 0 || 0 || 0 || 0 || 0 || 0 || 0 || — || 0.03 || 0 || — || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 1 || 0 || 0 || 0 || — || ATtiny28L
|-
| ATtiny26 || 2 || 20 || 16 || — || — || 16 || 11 || 1 || 1 || 0 || 0 || 11 || 10 || 15 || — || 0.12 || 128 || — || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 2 || 3 || 0 || 4 || — || ATtiny26
|-
| ATtiny13 || 1 || 8 || 20 || — || — || 6 || 6 || 0 || 0 || 0 || 0 || 4 || 10 || 15 || — || 0.06 || 64 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 1 || 2 || 0 || 2 || — || ATtiny13
|-
| ATtiny2313 || 2 || 20 || 20 || 4 || — || 18 || 18 || 2 || 1 || 1 || 0 || 0 || 0 || 15 || — || 0.12 || 128 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 4 || — || ATtiny2313
|-
| ATtiny25 || 2 || 8 || 20 || 4 || — || 6 || 6 || 1 || 1 || 0 || 0 || 4 || 10 || 15 || √ || 0.12 || 128 || √ || — || −40 – 105 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 5 || 0 || 6 || — || ATtiny25
|-
| ATtiny85 || 8 || 8 || 20 || 3 || — || 6 || 6 || 1 || 1 || 0 || 0 || 4 || 10 || 15 || √ || 0.5 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 5 || 0 || 6 || — || ATtiny85
|-
| ATtiny45 || 4 || 8 || 20 || 3 || — || 6 || 6 || 1 || 1 || 0 || 0 || 4 || 10 || 15 || √ || 0.25 || 256 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 5 || 0 || 6 || — || ATtiny45
|-
| ATtiny24 || 2 || 14 || 20 || 4 || — || 12 || 12 || 1 || 1 || 0 || 0 || 8 || 10 || 15 || √ || 0.12 || 128 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 4 || — || ATtiny24
|-
| ATtiny44 || 4 || 14 || 20 || 6 || — || 12 || 12 || 1 || 1 || 0 || 0 || 8 || 10 || 15 || √ || 0.25 || 256 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 4 || — || ATtiny44
|-
| ATtiny84 || 8 || 14 || 20 || 6 || — || 12 || 12 || 1 || 1 || 0 || 0 || 8 || 10 || 15 || √ || 0.5 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 4 || — || ATtiny84
|-
| ATtiny261 || 2 || 20 || 20 || 4 || — || 16 || 16 || 1 || 1 || 0 || 0 || 11 || 10 || 15 || √ || 0.12 || 128 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 6 || 1 || 6 || — || ATtiny261
|-
| ATtiny461 || 4 || 20 || 20 || 8 || — || 16 || 16 || 1 || 1 || 0 || 0 || 11 || 10 || 15 || √ || 0.25 || 256 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 6 || 1 || 6 || — || ATtiny461
|-
| ATtiny861 || 8 || 20 || 20 || 8 || — || 16 || 16 || 1 || 1 || 0 || 0 || 11 || 10 || 15 || √ || 0.5 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 6 || 1 || 6 || — || ATtiny861
|-
| ATtiny13A || 1 || 8 || 20 || — || — || 6 || 6 || 0 || 0 || 0 || 0 || 4 || 10 || 15 || — || 0.06 || 64 || √ || √ || −40 – 125 || 1.8 – 5.5 || 1.8 – 5.5 || 1 || 2 || 0 || 2 || — || ATtiny13A
|-
| ATtiny48 || 4 || 32 || 12 || 12 || — || 28 || 28 || 1 || 1 || 0 || 0 || 8 || 10 || 15 || √ || 0.25 || 64 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 2 || — || ATtiny48
|-
| ATtiny88 || 8 || 32 || 12 || 12 || — || 28 || 28 || 1 || 1 || 0 || 0 || 8 || 10 || 15 || √ || 0.5 || 64 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 2 || — || ATtiny88
|-
| ATtiny24A || 2 || 14 || 20 || 4 || — || 12 || 12 || 1 || 1 || 0 || 0 || 8 || 10 || 15 || √ || 0.12 || 128 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 4 || — || ATtiny24A
|-
| ATtiny44A || 4 || 14 || 20 || 6 || — || 12 || 12 || 1 || 1 || 0 || 0 || 8 || 10 || 15 || √ || 0.25 || 256 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 4 || — || ATtiny44A
|-
| ATtiny43U || 4 || 20 || 8 || 8 || — || 16 || 16 || 1 || 1 || 0 || 0 || 4 || 10 || 15 || √ || 0.25 || 64 || √ || √ || −40 – 85 || 0.7 – 5.5 || 0.7 – 5.5 || 2 || 4 || 0 || 4 || — || ATtiny43U
|-
| ATtiny10 || 1 || 6 || 12 || 1 || — || 4 || 4 || 0 || 0 || 0 || 0 || 4 || 8 || 15 || — || 0.03 || 0 || — || — || −40 – 125 || 1.8 – 5.5 || 1.8 – 5.5 || 1 || 2 || 1 || 2 || — || ATtiny10
|-
| ATtiny4 || 0.5 || 6 || 12 || 1 || — || 4 || 4 || 0 || 0 || 0 || 0 || 0 || 0 || 0 || — || 0.03 || 0 || — || — || −40 – 125 || 1.8 – 5.5 || 1.8 – 5.5 || 1 || 2 || 1 || 2 || — || ATtiny4
|-
| ATtiny5 || 0.5 || 6 || 12 || 1 || — || 4 || 4 || 0 || 0 || 0 || 0 || 4 || 8 || 15 || — || 0.03 || 0 || — || — || −40 – 125 || 1.8 – 5.5 || 1.8 – 5.5 || 1 || 2 || 1 || 2 || — || ATtiny5
|-
| ATtiny9 || 1 || 6 || 12 || 1 || — || 4 || 4 || 0 || 0 || 0 || 0 || 0 || 0 || 0 || — || 0.03 || 0 || — || — || −40 – 125 || 1.8 – 5.5 || 1.8 – 5.5 || 1 || 2 || 1 || 2 || — || ATtiny9
|-
| ATtiny261A || 2 || 20 || 20 || 4 || — || 16 || 16 || 1 || 1 || 0 || 0 || 11 || 10 || 15 || √ || 0.12 || 128 || √ || √ || −40 – 105 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 6 || 1 || 6 || — || ATtiny261A
|-
| ATtiny461A || 4 || 20 || 20 || 8 || — || 16 || 16 || 1 || 1 || 0 || 0 || 11 || 10 || 15 || √ || 0.25 || 256 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 6 || 1 || 6 || — || ATtiny461A
|-
| ATtiny861A || 8 || 20 || 20 || 8 || — || 16 || 16 || 1 || 1 || 0 || 0 || 11 || 10 || 15 || √ || 0.5 || 512 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 6 || 1 || 6 || — || ATtiny861A
|-
| ATtiny2313A || 2 || 20 || 20 || — || — || 18 || 18 || 2 || 1 || 1 || 0 || 0 || 0 || 15 || — || 0.12 || 128 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 4 || — || ATtiny2313A
|-
| ATtiny4313 || 4 || 20 || 20 || — || — || 18 || 18 || 2 || 1 || 1 || 0 || 0 || 0 || 15 || — || 0.25 || 256 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 4 || — || ATtiny4313
|-
| ATtiny167 || 16 || 20 || 16 || 8 || — || 16 || 16 || 2 || 1 || 1 || 1 || 11 || 10 || 15 || √ || 0.5 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 3 || 1 || 9 || √ || ATtiny167
|-
| ATtiny87 || 8 || 20 || 16 || — || — || 16 || 16 || 2 || 1 || 1 || 1 || 11 || 10 || 15 || √ || 0.5 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 3 || 1 || 9 || √ || ATtiny87
|-
| ATtiny20 || 2 || 14 || 12 || 5 || √ || 12 || 12 || 1 || 1 || 0 || 0 || 8 || 10 || 15 || √ || 0.12 || 0 || — || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 3 || — || ATtiny20
|-
| ATtiny40 || 4 || 20 || 12 || 12 || √ || 18 || 18 || 1 || 1 || 0 || 0 || 12 || 10 || 15 || √ || 0.25 || 0 || — || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 2 || — || ATtiny40
|-
| ATtiny84A || 8 || 14 || 20 || 6 || — || 12 || 12 || 1 || 1 || 0 || 0 || 8 || 10 || 15 || √ || 0.5 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 2 || 4 || 1 || 4 || — || ATtiny84A
|}

{| class="wikitable"
|+ '''General Features'''  
|-
| '''CPU''' || 8-bit AVR
|-
| '''Quadrature Decoder Kanäle''' || 0
|-
| '''USB Transceiver''' || 0
|-
| '''USB Speed''' || nein
|-
| '''USB Interface''' || nein
|-
| '''CAN''' || 0
|-
| '''SSC''' || 0
|-
| '''Ethernet''' || 0
|-
| '''SD / eMMC''' || 0
|-
| '''Segment LCD''' || 0
|-
| '''Grafik LCD''' || nein
|-
| '''Video Decoder''' || nein
|-
| '''Kamera Interface''' || nein
|-
| '''Analog Comparators''' || 1
|-
| '''Resistive Touch Screen''' || nein
|-
| '''DAC Kanäle''' || 0
|-
| '''DAC Auflösung [bits]''' || 0
|-
| '''External Bus Interface''' || 0
|-
| '''DRAM Memory''' || nein
|-
| '''NAND Interface''' || nein
|-
| '''FPU''' || nein
|-
| '''MPU / MMU''' || nein / nein
|-
| '''Crypto Engine''' || nein
|-
| '''Calibrated RC Oscillator''' || ja
|}

=== ATmega ===

{| class="wikitable sortable" style="font-size:10px;" id="AVR_Features_ATmega"
|+ Device-specific Features  
|- valign="top"
! Device
! Flash [KiB]
! Pin Anzahl
! Max. &fnof;CPU [MHz]
! of Touch Kanäle
! Max I/O Pins
! Ext Interrupts
! USB Transceiver
! USB Speed
! USB Interface
! SPI
! TWI
! UART
! CAN
! LIN
! Segment LCD
! ADC Kanäle
! ADC Auflösung [bits]
! ADC Speed [ksps]
! Analog Comparators
! DAC Kanäle
! DAC Auflösung [bits]
! Temp. Sensor
! SRAM [KiB]
! EEPROM [Bytes]
! Self Program Memory
! picoPower
! Temp. Bereich [°C]
! I/O Supply Class [V]
! Operating Voltage [VCC]
! Timers
! Output Compare Kanäle
! Input Capture Kanäle
! PWM Kanäle
! 32kHz RTC
! Device
|-
| ATmega8 || 8 || 32 || 16 || 12 || 23 || 2 || 0 || — || — || 1 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 3 || 3 || 1 || 3 || √ || ATmega8
|-
| ATmega8515 || 8 || 44 || 16 || 16 || 35 || 3 || 0 || — || — || 1 || 0 || 1 || 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0 || — || 0.5 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 2 || 3 || 1 || 3 || — || ATmega8515
|-
| ATmega8535 || 8 || 44 || 16 || 16 || 32 || 3 || 0 || — || — || 1 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 0.5 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega8535
|-
| ATmega16 || 16 || 44 || 16 || 16 || 32 || 3 || 0 || — || — || 1 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega16
|-
| ATmega32 || 32 || 44 || 16 || 16 || 32 || 3 || 0 || — || — || 1 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega32
|-
| ATmega64 || 64 || 64 || 16 || 16 || 53 || 8 || 0 || — || — || 1 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 8 || 2 || 7 || √ || ATmega64
|-
| ATmega128 || 128 || 64 || 16 || 16 || 53 || 8 || 0 || — || — || 1 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 4096 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 8 || 2 || 7 || √ || ATmega128
|-
| ATmega162 || 16 || 44 || 16 || 16 || 35 || 3 || 0 || — || — || 1 || 0 || 2 || 0 || 0 || 0 || 0 || 0 || 0 || 1 || 0 || 0 || — || 1 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 4 || 6 || 2 || 6 || √ || ATmega162
|-
| ATmega48 || 4 || 32 || 20 || 12 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 0.5 || 256 || — || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega48
|-
| ATmega88 || 8 || 32 || 20 || 12 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega88
|-
| ATmega168 || 16 || 32 || 20 || 16 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega168
|-
| AT90CAN128 || 128 || 64 || 16 || 16 || 53 || 8 || 0 || — || — || 1 || 1 || 2 || 1 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 4096 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 8 || 2 || 7 || √ || AT90CAN128
|-
| ATmega325 || 32 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega325
|-
| ATmega3250 || 32 || 100 || 16 || 16 || 69 || 25 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega3250
|-
| ATmega6450 || 64 || 100 || 16 || — || 69 || 25 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega6450
|-
| ATmega645 || 64 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega645
|-
| ATmega329 || 32 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 100 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega329
|-
| ATmega3290 || 32 || 100 || 16 || 16 || 69 || 32 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 160 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega3290
|-
| ATmega649 || 64 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 100 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega649
|-
| ATmega6490 || 64 || 100 || 16 || 16 || 69 || 32 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 160 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega6490
|-
| ATmega640 || 64 || 100 || 16 || 16 || 86 || 32 || 0 || — || — || 5 || 1 || 4 || 0 || 0 || 0 || 16 || 10 || 15 || 1 || 0 || 0 || — || 8 || 4096 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 6 || 16 || 4 || 15 || √ || ATmega640
|-
| ATmega1281 || 128 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 8 || 4096 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 6 || 16 || 2 || 8 || √ || ATmega1281
|-
| ATmega2561 || 256 || 64 || 16 || — || 54 || 17 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 8 || 4096 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 6 || 16 || 2 || 8 || √ || ATmega2561
|-
| ATmega2560 || 256 || 100 || 16 || — || 86 || 32 || 0 || — || — || 5 || 1 || 4 || 0 || 0 || 0 || 16 || 10 || 15 || 1 || 0 || 0 || — || 8 || 4096 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 6 || 16 || 4 || 15 || √ || ATmega2560
|-
| ATmega1280 || 128 || 100 || 16 || 16 || 86 || 32 || 0 || — || — || 5 || 1 || 4 || 0 || 0 || 0 || 16 || 10 || 15 || 1 || 0 || 0 || — || 8 || 4096 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 6 || 16 || 4 || 15 || √ || ATmega1280
|-
| ATmega644 || 64 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega644
|-
| AT90CAN32 || 32 || 64 || 16 || 16 || 53 || 8 || 0 || — || — || 1 || 1 || 2 || 1 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 8 || 2 || 7 || √ || AT90CAN32
|-
| AT90CAN64 || 64 || 64 || 16 || 16 || 53 || 8 || 0 || — || — || 1 || 1 || 2 || 1 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 8 || 2 || 7 || √ || AT90CAN64
|-
| AT90USB1286 || 128 || 64 || 16 || 16 || 48 || 16 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 8 || 4096 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 10 || 1 || 9 || √ || AT90USB1286
|-
| AT90USB1287 || 128 || 64 || 16 || 16 || 48 || 16 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbo">Device + OTG</ref> || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 8 || 4096 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 10 || 1 || 9 || √ || AT90USB1287
|-
| AT90USB647 || 64 || 64 || 16 || 16 || 48 || 16 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbo">Device + OTG</ref> || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 10 || 1 || 9 || √ || AT90USB647
|-
| AT90USB646 || 64 || 64 || 16 || 16 || 48 || 16 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 10 || 1 || 9 || √ || AT90USB646
|-
| ATmega164P || 16 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega164P
|-
| ATmega324P || 32 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega324P
|-
| ATmega165P || 16 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega165P
|-
| ATmega169P || 16 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 100 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega169P
|-
| ATmega644P || 64 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega644P
|-
| AT90PWM1 || 8 || 24 || 16 || 8 || 19 || 4 || 0 || — || — || 1 || 0 || 0 || 0 || 0 || 0 || 8 || 10 || 125 || 2 || 0 || 0 || — || 0.5 || 512 || √ || — || −40 – 105 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 12 || 1 || 7 || — || AT90PWM1
|-
| ATmega329P || 32 || 64 || 20 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 100 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega329P
|-
| ATmega3290P || 32 || 100 || 20 || 16 || 69 || 32 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 160 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega3290P
|-
| ATmega325P || 32 || 64 || 20 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega325P
|-
| ATmega3250P || 32 || 100 || 20 || 16 || 69 || 25 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega3250P
|-
| AT90USB82 || 8 || 32 || 16 || 12 || 22 || 21 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 2 || 0 || 1 || 0 || 0 || 0 || 0 || 0 || 0 || 1 || 0 || 0 || — || 0.5 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 2 || 5 || 1 || 4 || — || AT90USB82
|-
| AT90USB162 || 16 || 32 || 16 || — || 22 || 21 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 2 || 0 || 1 || 0 || 0 || 0 || 0 || 0 || 0 || 1 || 0 || 0 || — || 0.5 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 2 || 5 || 1 || 4 || — || AT90USB162
|-
| AT90PWM216 || 16 || 24 || 16 || 12 || 19 || 4 || 0 || — || — || 1 || 0 || 1 || 0 || 0 || 0 || 8 || 10 || 125 || 2 || 1 || 10 || — || 1 || 512 || √ || — || −40 – 105 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 12 || 1 || 7 || — || AT90PWM216
|-
| AT90PWM316 || 16 || 32 || 16 || 12 || 27 || 4 || 0 || — || — || 1 || 0 || 1 || 0 || 0 || 0 || 11 || 10 || 125 || 3 || 1 || 10 || — || 1 || 512 || √ || — || −40 – 105 || 2.7 – 5.5 || 2.7 – 5.5 || 5 || 16 || 1 || 12 || — || AT90PWM316
|-
| ATmega48P || 4 || 32 || 20 || 12 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || √ || 0.5 || 256 || — || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega48P
|-
| ATmega88P || 8 || 32 || 20 || 12 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || √ || 1 || 512 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega88P
|-
| ATmega168P || 16 || 32 || 20 || 16 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || √ || 1 || 512 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega168P
|-
| ATmega328P || 32 || 32 || 20 || 16 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || √ || 2 || 1024 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega328P
|-
| AT90PWM3B || 8 || 32 || 16 || 8 || 27 || 4 || 0 || — || — || 1 || 0 || 1 || 0 || 0 || 0 || 11 || 10 || 125 || 3 || 1 || 10 || — || 0.5 || 512 || √ || — || −40 – 105 || 2.7 – 5.5 || 2.7 – 5.5 || 5 || 16 || 1 || 12 || — || AT90PWM3B
|-
| AT90PWM2B || 8 || 24 || 16 || 8 || 19 || 4 || 0 || — || — || 1 || 0 || 1 || 0 || 0 || 0 || 8 || 10 || 125 || 2 || 1 || 10 || — || 0.5 || 512 || √ || — || −40 – 105 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 12 || 1 || 7 || — || AT90PWM2B
|-
| ATmega32U4 || 32 || 44 || 16 || 14 || 26 || 13 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 2 || 1 || 1 || 0 || 0 || 0 || 12 || 10 || 15 || 1 || 0 || 0 || √ || 2.5 || 1024 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 12 || 2 || 8 || — || ATmega32U4
|-
| ATmega1284P || 128 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 16 || 4096 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega1284P
|-
| ATmega16U4 || 16 || 44 || 16 || 14 || 26 || 13 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 2 || 1 || 1 || 0 || 0 || 0 || 12 || 10 || 15 || 1 || 0 || 0 || √ || 1.25 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 12 || 2 || 8 || — || ATmega16U4
|-
| ATmega16A || 16 || 44 || 16 || 16 || 32 || 3 || 0 || — || — || 1 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega16A
|-
| ATmega32A || 32 || 44 || 16 || 16 || 32 || 3 || 0 || — || — || 1 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega32A
|-
| ATmega88PA || 8 || 32 || 20 || 12 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || √ || 1 || 512 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega88PA
|-
| ATmega324PA || 32 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega324PA
|-
| ATmega48PA || 4 || 32 || 20 || 12 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || √ || 0.5 || 256 || — || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega48PA
|-
| ATmega164PA || 16 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega164PA
|-
| ATmega64A || 64 || 64 || 16 || 16 || 53 || 8 || 0 || — || — || 1 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 8 || 2 || 7 || √ || ATmega64A
|-
| ATmega128A || 128 || 64 || 16 || 16 || 53 || 8 || 0 || — || — || 1 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 4096 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 4 || 8 || 2 || 7 || √ || ATmega128A
|-
| ATmega8A || 8 || 32 || 16 || 12 || 23 || 2 || 0 || — || — || 1 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 3 || — || — || 3 || √ || ATmega8A
|-
| ATmega168PA || 16 || 32 || 20 || 16 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || √ || 1 || 512 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega168PA
|-
| ATmega8U2 || 8 || 32 || 16 || — || 22 || 20 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 2 || 0 || 1 || 0 || 0 || 0 || 0 || 0 || 0 || 1 || 0 || 0 || — || 0.5 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 2 || 5 || 1 || 4 || — || ATmega8U2
|-
| ATmega16U2 || 16 || 32 || 16 || 12 || 22 || 21 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 2 || 0 || 1 || 0 || 0 || 0 || 0 || 0 || 0 || 1 || 0 || 0 || — || 0.5 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 2 || 5 || 1 || 4 || — || ATmega16U2
|-
| ATmega32U2 || 32 || 32 || 16 || 12 || 22 || 20 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 2 || 0 || 1 || 0 || 0 || 0 || 0 || 0 || 0 || 1 || 0 || 0 || — || 1 || 1024 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 2 || 5 || 1 || 4 || — || ATmega32U2
|-
| ATmega644PA || 64 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega644PA
|-
| ATmega16M1 || 16 || 32 || 16 || 12 || 27 || 27 || 0 || — || — || 1 || 0 || 1 || 1 || 1 || 0 || 11 || 10 || 125 || 4 || 1 || 10 || √ || 1 || 512 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 2 || 14 || 1 || 10 || — || ATmega16M1
|-
| ATmega32M1 || 32 || 32 || 16 || 12 || 27 || 27 || 0 || — || — || 1 || 0 || 1 || 1 || 1 || 0 || 11 || 10 || 125 || 4 || 1 || 10 || √ || 2 || 1024 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 2 || 14 || 1 || 10 || — || ATmega32M1
|-
| ATmega64M1 || 64 || 32 || 16 || 12 || 27 || 27 || 0 || — || — || 1 || 0 || 1 || 1 || 1 || 0 || 11 || 10 || 125 || 4 || 1 || 10 || √ || 4 || 2048 || √ || — || −40 – 85 || 2.7 – 5.5 || 2.7 – 5.5 || 2 || 14 || 1 || 10 || — || ATmega64M1
|-
| ATmega169PA || 16 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 100 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega169PA
|-
| ATmega48A || 4 || 32 || 20 || 12 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || √ || 0.5 || 256 || — || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega48A
|-
| ATmega88A || 8 || 32 || 20 || 12 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || √ || 1 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega88A
|-
| ATmega168A || 16 || 32 || 20 || 16 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || √ || 1 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega168A
|-
| ATmega328 || 32 || 32 || 20 || 16 || 23 || 24 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || √ || 2 || 1024 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega328
|-
| ATmega164A || 16 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega164A
|-
| ATmega324A || 32 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega324A
|-
| ATmega644A || 64 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega644A
|-
| ATmega1284 || 128 || 44 || 20 || 16 || 32 || 32 || 0 || — || — || 3 || 1 || 2 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 16 || 4096 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 6 || 1 || 6 || √ || ATmega1284
|-
| AT90PWM81 || 8 || 20 || 16 || — || 20 || 3 || 0 || — || — || 1 || 0 || 0 || 0 || 0 || 0 || 11 || 10 || 125 || 3 || 1 || 10 || √ || 0.25 || 512 || √ || — || −40 – 125 || 2.7 – 5.5 || 2.7 – 5.5 || 1 || 8 || 1 || 6 || — || AT90PWM81
|-
| ATmega165PA || 16 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega165PA
|-
| ATmega325A || 32 || 64 || 20 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega325A
|-
| ATmega3250A || 32 || 100 || 20 || 16 || 69 || 25 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega3250A
|-
| ATmega645A || 64 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega645A
|-
| ATmega645P || 64 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega645P
|-
| ATmega6450P || 64 || 100 || 20 || — || 69 || 25 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega6450P
|-
| ATmega6450A || 64 || 100 || 20 || — || 69 || 25 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 0 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega6450A
|-
| ATmega169A || 16 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 100 || 8 || 10 || 15 || 1 || 0 || 0 || — || 1 || 512 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega169A
|-
| ATmega329A || 32 || 64 || 20 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 100 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega329A
|-
| ATmega649A || 64 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 100 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega649A
|-
| ATmega3290A || 32 || 100 || 20 || 16 || 69 || 32 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 160 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega3290A
|-
| ATmega649P || 64 || 64 || 16 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 100 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega649P
|-
| ATmega6490A || 64 || 100 || 20 || 16 || 69 || 32 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 160 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || — || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega6490A
|-
| ATmega6490P || 64 || 100 || 20 || 16 || 69 || 32 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 160 || 8 || 10 || 15 || 1 || 0 || 0 || — || 4 || 2048 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega6490P
|-
| ATmega329PA || 32 || 64 || 20 || 16 || 54 || 17 || 0 || — || — || 2 || 1 || 1 || 0 || 0 || 100 || 8 || 10 || 15 || 1 || 0 || 0 || — || 2 || 1024 || √ || √ || −40 – 85 || 1.8 – 5.5 || 1.8 – 5.5 || 3 || 4 || 1 || 4 || √ || ATmega329PA
|}

{| class="wikitable"
|+ '''General Features'''  
|-
| '''CPU''' || 8-bit AVR
|-
| '''Hardware Qtouch''' || nein
|-
| '''Quadrature Decoder Kanäle''' || 0
|-
| '''SSC''' || 0
|-
| '''Ethernet''' || 0
|-
| '''SD / eMMC''' || 0
|-
| '''Grafik LCD''' || nein
|-
| '''Video Decoder''' || nein
|-
| '''Kamera Interface''' || nein
|-
| '''Resistive Touch Screen''' || nein
|-
| '''External Bus Interface''' || 0
|-
| '''DRAM Memory''' || nein
|-
| '''NAND Interface''' || nein
|-
| '''FPU''' || nein
|-
| '''MPU / MMU''' || nein / nein
|-
| '''Crypto Engine''' || nein
|-
| '''Calibrated RC Oscillator''' || ja
|}

=== ATxmega ===

{| class="wikitable sortable" style="font-size:10px;" id="AVR_Features_ATxmega"
|+ Device-specific Features  
|- valign="top"
! Device
! Flash [KiB]
! Pin Anzahl
! Anzahl Touch Kanäle
! Max I/O Pins
! Ext Interrupts
! USB Transceiver
! USB Speed
! USB Interface
! SPI
! TWI
! UART
! Segment LCD
! ADC Kanäle
! ADC Speed [ksps]
! Analog Comparators
! DAC Kanäle
! DAC Auflösung [bits]
! SRAM [KiB]
! EEPROM [Bytes]
! External Bus Interface
! DRAM Memory
! Crypto Engine
! Timers
! Output Compare Kanäle
! Input Capture Kanäle
! PWM Kanäle
! Device
|-
| ATxmega64A1 || 64 || 100 || 16 || 78 || 78 || 0 || — || — || 12 || 4 || 8 || 0 || 16 || 2000 || 4 || 4 || 12 || 4 || 2048 || 1 || ja<ref name="sdram">SDRAM</ref> || ja<ref name="cry">AES/DES</ref> || 8 || 24 || 24 || 24 || ATxmega64A1
|-
| ATxmega128A1 || 128 || 100 || 16 || 78 || 78 || 0 || — || — || 12 || 4 || 8 || 0 || 16 || 2000 || 4 || 4 || 12 || 8 || 2048 || 1 || ja<ref name="sdram">SDRAM</ref> || ja<ref name="cry">AES/DES</ref> || 8 || 24 || 24 || 24 || ATxmega128A1
|-
| ATxmega64A3 || 64 || 64 || 16 || 50 || 50 || 0 || — || — || 10 || 2 || 7 || 0 || 16 || 2000 || 4 || 2 || 12 || 4 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 7 || 22 || 22 || 22 || ATxmega64A3
|-
| ATxmega128A3 || 128 || 64 || 16 || 50 || 50 || 0 || — || — || 10 || 2 || 7 || 0 || 16 || 2000 || 4 || 2 || 12 || 8 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 7 || 22 || 22 || 22 || ATxmega128A3
|-
| ATxmega192A3 || 192 || 64 || 16 || 50 || 50 || 0 || — || — || 10 || 2 || 7 || 0 || 16 || 2000 || 4 || 2 || 12 || 16 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 7 || 22 || 22 || 22 || ATxmega192A3
|-
| ATxmega256A3 || 256 || 64 || 16 || 50 || 50 || 0 || — || — || 10 || 2 || 7 || 0 || 16 || 2000 || 4 || 2 || 12 || 16 || 4096 || 0 || — || ja<ref name="cry">AES/DES</ref> || 7 || 22 || 22 || 22 || ATxmega256A3
|-
| ATxmega16A4 || 16 || 44 || 16 || 34 || 34 || 0 || — || — || 7 || 2 || 5 || 0 || 12 || 2000 || 2 || 2 || 12 || 3.3 || 1024 || 0 || — || ja<ref name="cry">AES/DES</ref> || 5 || 16 || 16 || 16 || ATxmega16A4
|-
| ATxmega32A4 || 32 || 44 || 16 || 34 || 34 || 0 || — || — || 7 || 2 || 5 || 0 || 12 || 2000 || 2 || 2 || 12 || 4 || 1024 || 0 || — || ja<ref name="cry">AES/DES</ref> || 5 || 16 || 16 || 16 || ATxmega32A4
|-
| ATxmega64A4 || 64 || 44 || — || 34 || 34 || 0 || — || — || 7 || 2 || 5 || 0 || 12 || 2000 || 2 || 2 || 12 || 4 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 5 || 16 || 16 || 16 || ATxmega64A4
|-
| ATxmega128A4 || 128 || 44 || — || 34 || 34 || 0 || — || — || 7 || 2 || 5 || 0 || 12 || 2000 || 2 || 2 || 12 || 8 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 5 || 16 || 16 || 16 || ATxmega128A4
|-
| ATxmega256A3B || 256 || 64 || 16 || 47 || 49 || 0 || — || — || 8 || 2 || 6 || 0 || 16 || 2000 || 4 || 2 || 12 || 16 || 4096 || 0 || — || ja<ref name="cry">AES/DES</ref> || 7 || 22 || 22 || 22 || ATxmega256A3B
|-
| ATxmega256D3 || 256 || 64 || 16 || 50 || 50 || 0 || — || — || 5 || 2 || 3 || 0 || 16 || 200 || 2 || 0 || 0 || 16 || 4096 || 0 || — || — || 5 || 18 || 18 || 18 || ATxmega256D3
|-
| ATxmega192D3 || 192 || 64 || 16 || 50 || 50 || 0 || — || — || 5 || 2 || 3 || 0 || 16 || 200 || 2 || 0 || 0 || 16 || 2048 || 0 || — || — || 5 || 18 || 18 || 18 || ATxmega192D3
|-
| ATxmega128D3 || 128 || 64 || 16 || 50 || 50 || 0 || — || — || 5 || 2 || 3 || 0 || 16 || 200 || 2 || 0 || 0 || 8 || 2048 || 0 || — || — || 5 || 18 || 18 || 18 || ATxmega128D3
|-
| ATxmega64D3 || 64 || 64 || 16 || 50 || 50 || 0 || — || — || 5 || 2 || 3 || 0 || 16 || 200 || 2 || 0 || 0 || 4 || 2048 || 0 || — || — || 5 || 18 || 18 || 18 || ATxmega64D3
|-
| ATxmega128D4 || 128 || 44 || — || 34 || 34 || 0 || — || — || 4 || 2 || 2 || 0 || 12 || 200 || 2 || 0 || 0 || 8 || 2048 || 0 || — || — || 4 || 14 || 14 || 14 || ATxmega128D4
|-
| ATxmega64D4 || 64 || 44 || — || 34 || 34 || 0 || — || — || 4 || 2 || 2 || 0 || 12 || 200 || 2 || 0 || 0 || 4 || 2048 || 0 || — || — || 4 || 14 || 14 || 14 || ATxmega64D4
|-
| ATxmega32D4 || 32 || 44 || 16 || 34 || 34 || 0 || — || — || 4 || 2 || 2 || 0 || 12 || 200 || 2 || 0 || 0 || 4 || 1024 || 0 || — || — || 4 || 14 || 14 || 14 || ATxmega32D4
|-
| ATxmega16D4 || 16 || 44 || 16 || 34 || 34 || 0 || — || — || 4 || 2 || 2 || 0 || 12 || 200 || 2 || 0 || 0 || 2 || 1024 || 0 || — || — || 4 || 14 || 14 || 14 || ATxmega16D4
|-
| ATxmega16A4U || 16 || 44 || 16 || 34 || 34 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 7 || 2 || 5 || 0 || 12 || 2000 || 2 || 2 || 12 || 3.3 || 1024 || 0 || — || ja<ref name="cry">AES/DES</ref> || 5 || 16 || 16 || 16 || ATxmega16A4U
|-
| ATxmega32A4U || 32 || 44 || 16 || 34 || 34 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 7 || 2 || 5 || 0 || 12 || 2000 || 2 || 2 || 12 || 4 || 1024 || 0 || — || ja<ref name="cry">AES/DES</ref> || 5 || 16 || 16 || 16 || ATxmega32A4U
|-
| ATxmega64A3U || 64 || 64 || 16 || 50 || 50 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 10 || 2 || 7 || 0 || 16 || 2000 || 4 || 2 || 12 || 4 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 7 || 22 || 22 || 22 || ATxmega64A3U
|-
| ATxmega128A3U || 128 || 64 || 16 || 50 || 50 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 10 || 2 || 7 || 0 || 16 || 2000 || 4 || 2 || 12 || 8 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 7 || 22 || 22 || 22 || ATxmega128A3U
|-
| ATxmega192A3U || 192 || 64 || 16 || 50 || 50 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 10 || 2 || 7 || 0 || 16 || 2000 || 4 || 2 || 12 || 16 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 7 || 22 || 22 || 22 || ATxmega192A3U
|-
| ATxmega256A3U || 256 || 64 || 16 || 50 || 50 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 10 || 2 || 7 || 0 || 16 || 2000 || 4 || 2 || 12 || 16 || 4096 || 0 || — || ja<ref name="cry">AES/DES</ref> || 7 || 22 || 22 || 22 || ATxmega256A3U
|-
| ATxmega256A3BU || 256 || 64 || 16 || 47 || 49 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 8 || 2 || 6 || 0 || 16 || 2000 || 4 || 2 || 12 || 16 || 4096 || 0 || — || ja<ref name="cry">AES/DES</ref> || 7 || 22 || 22 || 22 || ATxmega256A3BU
|-
| ATxmega64B3 || 64 || 64 || 16 || 36 || 36 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 2 || 1 || 1 || 100 || 8 || 2000 || 2 || 0 || 0 || 4 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 2 || 6 || 6 || 6 || ATxmega64B3
|-
| ATxmega128B3 || 128 || 64 || 16 || 36 || 36 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 2 || 1 || 1 || 100 || 8 || 2000 || 2 || 0 || 0 || 4 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 2 || 6 || 6 || 6 || ATxmega128B3
|-
| ATxmega128B1 || 128 || 100 || 16 || 53 || 53 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 3 || 1 || 2 || 160 || 16 || 2000 || 4 || 0 || 0 || 8 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 3 || 10 || 10 || 10 || ATxmega128B1
|-
| ATxmega64B1 || 64 || 100 || 16 || 53 || 53 || 1 || ja<ref name="usbs">Full Speed</ref> || ja<ref name="usbd">Device</ref> || 3 || 1 || 2 || 160 || 16 || 2000 || 4 || 0 || 0 || 8 || 2048 || 0 || — || ja<ref name="cry">AES/DES</ref> || 3 || 10 || 10 || 10 || ATxmega64B1
|}

{| class="wikitable"
|+ '''General Features'''  
|-
| '''Max. &fnof;CPU [MHz]''' || 32
|-
| '''CPU''' || 8-bit AVR
|-
| '''Hardware Qtouch''' || nein
|-
| '''Quadrature Decoder Kanäle''' || 0
|-
| '''CAN''' || 0
|-
| '''LIN''' || 0
|-
| '''SSC''' || 0
|-
| '''Ethernet''' || 0
|-
| '''SD / eMMC''' || 0
|-
| '''Grafik LCD''' || nein
|-
| '''Video Decoder''' || nein
|-
| '''Kamera Interface''' || nein
|-
| '''ADC Auflösung [bits]''' || 12
|-
| '''Resistive Touch Screen''' || nein
|-
| '''Temp. Sensor''' || ja
|-
| '''Self Program Memory''' || ja
|-
| '''NAND Interface''' || nein
|-
| '''picoPower''' || ja
|-
| '''Temp. Bereich [°C]''' || −40 – 85
|-
| '''I/O Supply Class [V]''' || 1.6 – 3.6
|-
| '''Operating Voltage [VCC]''' || 1.6 – 3.6
|-
| '''FPU''' || nein
|-
| '''MPU / MMU''' || nein / nein
|-
| '''32kHz RTC''' || ja
|-
| '''Calibrated RC Oscillator''' || ja
|}

== Referenzen ==
<references/>

== Weblinks ==

* [http://www.avrfreaks.net/index.php?module=Freaks%20Devices&func=devCompare Vergleichstabelle] von AVRFreaks
* [http://www.atmel.com/products/selector_overview.aspx Parametrische Suche bei Atmel]

[[Kategorie:AVR]]
[[Kategorie:Liste mit Bauteilen]]

AVR Net-IO Bausatz von Pollin

2014-06-17T19:21:09Z

Maybee:

Hier steht eine Beschreibung des Pollin Bausatzes [http://www.pollin.de/shop/shop.php?cf=detail.php&pg=NQ==&a=MTQ5OTgxOTk= AVR-NET-IO. Best.Nr. 810 058], oder als aufgebautes Fertigmodul, Best.Nr. 810 073.

Einige Features: Ethernet-Platine mit ATmega32 und Netzwerkcontroller ENC28J60. Die Platine verfügt über 8 digitale Ausgänge, 4 digitale und 4 ADC-Eingänge, welche alle über einen Netzwerkanschluss (TCP/IP) abgerufen bzw. geschaltet werden können.

[[Datei:AVR-NET-IO ADD-ON.JPG|thumb|right|400px|AVR-NET-IO (links) mit zusätzlicher SUB-D Anschlussplatine (rechts, nicht im Lieferumfang)und Add-On-Board (oben, mit aufgelötetem RFM12-433-Modul, beides nicht im Lieferumfang). Ebenso ist zusätzlich ein nicht im Lieferumfang enthaltener kleiner Kühlkörper auf einem der Spannungsregler montiert und die Schraubklemmen zur Stromversorgung wurden durch Buchsen ersetzt.]]

== Technische Daten ==

* Betriebsspannung 9 V AC/DC
* Stromaufnahme ca. 190 mA
* bzw. 5V DC, 1A (Steckernetzteil) an J6
* 8 digitale Ausgänge (0/5 V) [PC0-PC7 an J3]
* 4 digitale Eingänge (0/5 V) [PA0-PA3 an J3]
* 4 ADC-Eingänge (10 Bit) [PA4-PA7 an Schraubklemmen]
* LCD-Anschluss (HD44780 komp. Controller nötig) [PD2-7,PB0,PB3 an EXT]
* [[ENC28J60]]
* [http://www.atmel.com/dyn/Products/Product_card.asp?part_id=2014 ATmega32] Mikrocontroller

Maße (L×B×H): 108×76×22 mm.

== Hardware ==
=== AVR-NET-IO ===

Die Schaltung des AVR-NET-IO ist recht einfach:
* Ein ATmega32 Mikrocontroller enthält die gesamte Software
* Ein ENC28J60 Ethernet-Controller für das Senden und Empfangen von Ethernet Frames (MAC und PHY Ethernet Layer) ist über [[SPI]] mit dem ATmega32 verbunden
* Ein Ethernet RJ-45 MagJack TRJ 0011 BA NL von [http://www.trxcom.com/ Trxcom] mit eingebautem Übertrager und Anzeige-LEDs am ENC28J60.
* Ein MAX232 für die serielle Schnittstelle
* Zwei Spannungsregler, 5 V und 3,3 V
* "Hühnerfutter"

Fast alle I/O Pins des ATmega32 sind irgendwo auf Anschlüssen herausgeführt. Entweder auf dem SUB-D Stecker, dem EXT oder ISP Wannensteckern oder den blauen Anschlussklemmen. Eine Schutzbeschaltung gibt es nicht.

Die blauen Anschlussklemmen haben eine Nut und eine Feder mit denen man
sie zusammenstecken kann, dadurch ist das Anlöten wesentlich leichter
und sie stehen auch sauber in der Reihe.

=== Erweiterungsplatine ===

Seit Januar 2010 gibt es auch eine Erweiterungsplatine

[http://www.pollin.de/shop/dt/Nzg4OTgxOTk-/Bausaetze/Diverse/Bausatz_Add_on_fuer_AVR_NET_IO.html Add-on für AVR-NET-IO-Board Best.Nr. 810 112]

Diese Platine erweitert das NET-IO um:

* SD-Karten-Slot über SPI
* Display über PCF 8574
* Infrarot-Empfang
* [[RFM12]] Funkmodul (nicht im Lieferumfang enthalten)

Eine Aufstellung bekannter Fehler findet sich weiter unten [[#Bekannte Fehler|Bekannte Fehler - Erweiterungplatine]]

Erste Erfahrungsberichte im Forum http://www.mikrocontroller.net/topic/161354

=== Hardware-Umbauten & -Verbesserungen ===

* Kühlkörper auf dem 7805 - (Vorsicht: Der LM317T ist rückseitig spannungsführend. Den Kühlkörper also keinesfalls an beide Spannungsregler anschließen!)
* MAX232 nach anfänglicher Konfiguration nicht bestücken um Strom zu sparen oder um zwei weitere I/O-Pins zu gewinnen
* 10µF-Elkos für MAX232N (C14-C17) durch 1µF ersetzen. Eine 10µF-Version für den MAX232 gibt es nicht. Die 10µF-Elkos können auch Ursache einer nicht funktionierenden RS232 sein.
** Laut Spezifikation sind auch mehr als 1µF erlaubt. Selbst Atmel verwendet beim STK500 10µF. Dies führt keinesfalls dazu, dass die RS232 nicht mehr funktioniert.
* Die IC-Fassungen aus "Pollins Resterampe" durch Fassungen mit gedrehten Kontakten ersetzen.
* ''Netz'' LED nicht bestücken oder größere Widerstände einlöten um Strom zu sparen (R3)
* Vorwiderstände der Ethernet-LEDs größer machen (z. B. verdoppeln) um Strom zu sparen (R6,R7)
* Linear-Spannungsregler ersetzen
* Kondensator an AREF-Pin des ATmega32 (ATmega32 Datenblatt) (100nF gegen Masse)
* Kondensator an den RESET-Pin des ATmega32 ([http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf Atmel Application Note AVR042: AVR Hardware Design Considerations]) Wenn man diese Quelle genauer liest, ist das aber eher unnötig. - Kondensator bei selbstbau-ISP empfehlenswert.
* Umbau auf 3,3 V:
** Ersatz der Spannungsregler durch einen einzigen 3,3 V Regler
** Anpassen (verkleinern) des LED-Vorwiderstands R3 für 3,3 Volt Betrieb
** Reduktion der Taktfrequenz (Austausch von Q2) auf den bei 3,3V erlaubten Bereich des ATmega32 ( ATmega32(L) 3.3V /8.0 Mhz Takt )
** Ersatz des MAX232 durch einen MAX3232
[[Bild:POWER.JPG|thumb|400px|5V Stromversorgung über USB Kabel, ohne 5 V Spannungsregler und Gleichrichterdioden, Vorsicht: kein Verpolungsschutz! ]]
* ATmega32 vom ENC28J60 takten (OSC2)
* Betrieb mit Gleichspannung:
** Dioden D2 und D5 durch Drahtbrücken ersetzen, D1 und D4 nicht bestücken (komplette Entfernung des Brückengleichrichters, beinhaltet Verlust des Verpolungsschutzes)
** Diode D2 bestücken, D5 durch Drahtbrücke ersetzen, D1 und D4 nicht bestücken (Brückengleichrichter durch Verpolungsschutze ersetzen)
*** ??? Ist dies nicht kontraproduktiv? Bei mir wurde durch D2-Bestückung die Eingangsspannung von ca. 5,2 V am LM317T auf ca. 4,6 V gedrückt, so dass am ENC28J60 nur ca. 2,6 V ankamen (außerhalb der lt. Datenblatt "Operating voltage range of 3.14V to 3.45V"). Man müsste also ein geregeltes Netzteil mit ca. 5,5 V anschließen um 5 und 3,3 V zu erzielen. Dann lieber den Verpolungsschutz durch andere Maßnahmen sicherstellen.
** Beim Betrieb von USB beachten, dass USB-Spezifikation keinesfalls 5V garantiert, sondern Spannung bis runter 4.4V erlaubt und dann u.U. durch den LM317 nicht mehr genügend Spannung am ENC anliegt. Das äußert sich so, dass zwar der Atmega einwandfrei funktioniert, die Ethernet-Kommunikation aber nicht oder nur sehr sporadisch.
* Betrieb mit Steckernetzteil
** Wenn man ein energieeffizientes Stecker-Schaltnetzteil mit 5V, 1A direkt an J6 kontaktiert, kann man sich die o.g. Um- und Ausbauten sparen. Kein Spannungsregler wird mehr heiß, kein Kühlkörper wird benötigt, das Board arbeitet absolut stabil.
* Ersatz des ATmega32 durch einen ATmega644 oder ATmega1284p mit mehr FLASH-Speicher.
** Der ATmega644 und auch der ATMega1284p sind nicht mit der Pollin-Firmware kompatibel
* 100nF über alle drei IC Störunterdrückung zusätzlich bestücken

== Inbetriebnahme der Originalsoftware ==
=== Einleitung ===

Die bei Auslieferung (Stand September 2008) in den ATmega32 gebrannte Firmware stellt sich manchmal recht zickig an. Es scheint dann die Netzwerk-Schnittstelle, ggf. auch die serielle Schnittstelle, nicht zu funktionieren. Falls es Probleme geben sollte, sollte man erst einmal ein Firmwareupdate versuchen. Dies geschieht über die serielle Schnittstelle mittels des Programmes NetServer (aktuelle Version 1.03, Februar 2010), die dem Bausatz beiliegt.

Falls die serielle Schnittstelle ebenfalls nicht zugänglich ist, kann mit den im folgenden beschriebenen Schritten die Inbetriebnahme der Software möglich sein. Dazu benötigt man:

* Einen Windows-PC mit Ethernet-Schnittstelle und RS232-Schnittstelle (ein Prolific RS232-USB Konverter funktioniert)
* Entweder
**zwei normale (''straight through'') Ethernet-Kabel und einen Ethernet Switch/Hub, oder
**ein gekreuztes(''cross over'') Ethernet-Kabel
* Einen AVR Programmer (Hardware und Software). Zum Beispiel einen [[AVR Dragon]] oder [[STK500]] mit [[AVR Studio]] oder das [[Pollin ATMEL Evaluations-Board]] und [[avrdude]].
* Die [http://www.pollin.de/shop/ds/MTQ5OTgxOTk-.html Pollin NetServer Software], Version 1.03 (oder neuer)

=== Gelieferten ATmega32 richtig einstellen ===
[[image:fuse_bits_avr_studio.jpg|thumb|right|250px|Einstellungen der Fuse-Bits mittels AVR Studio 4]]
Die Fuses der gelieferten ATmega32s scheinen nicht immer mit den im Handbuch auf Seite 12 als erforderlich angegebenen Fuse-Einstellungen übereinzustimmen.

Dies kann man mittels eines Programmers ändern. LFuse = 0xBF, HFuse = 0xD2. Das genaue Vorgehen hängt dabei vom verwendeten Programmer ab. Bei der Gelegenheit kann man ebenfalls eine Sicherheitskopie des ursprünglichen Flash-Inhalts und des EEPROMs anfertigen. Das EEPROM scheint die MAC-Adresse des Ethernet-Ports zu enthalten.

Entgegen der Spezifikation im Handbuch von Pollin sollten die '''HFuses auf 0xC2''' gesetzt werden, d. h. CKOPT-Fuse programmiert (dies ist in der Software Version 1.03 bereits vollzogen). Das sorgt für einen stabilen Betrieb des AVR-Oszillators im "full rail-to-rail swing"-Mode bei 16 MHz. Atmel garantiert ansonsten nur stabilen Betrieb bis 8 MHz. Siehe ATmega32-Datenblatt, Kapitel 8.4, Crystal Oscillator.
{{Absatz}}

==== Funktionsfähige Konfiguration - AVR-Prog ====

[[Bild:Avrprog.png|thumb|right|250px]]
Benutzer von AVR-Prog können die nachfolgenden Einstellungen für die Lock- und Fuse-Bits verwenden. Hierbei handelt es sich um die ausgelesenen Einstellungen eines funktionsfähigen Controllers. Allerdings sollte, laut Handbuch des AVR-NET-IO-Boards, das Fuse-Bit EESAVE eigentlich gesetzt sein.

Alternativ kann auch per avrdude die Einstellung getroffen werden:
avrdude -c stk500v2 -pm32 -U lfuse:w:0xBF:m
und
avrdude -c stk500v2 -pm32 -U hfuse:w:0xC2:m

Anschließend muß noch der Bootloader und die Firmware aktualisiert werden (siehe Handbuch AVR-NET-IO-Board Seite 12 Punkt 3).

=== PC Konfiguration ===

==== PC normalerweise nicht im 192.168.0.0/24 Subnetz ====

Betreibt man den PC nicht im 192.168.0.0/24 Subnetz, muss er wie folgt umkonfiguriert werden, oder die IP Adresse des Boards wird entsprechend angepasst. ( Siehe Handbuch Seite 14ff. Das ist meist sinnvoller und auch einfacher. )

Den PC vom normalen Netzwerk abstecken[1]. Zur Umkonfiguration dazu bei Windows XP in der Systemsteuerung ''Netzwerkverbindungen'' aufrufen und die lokale ''LAN-Verbindung'' markieren. Dann in der rechten Leiste ''Einstellungen dieser Verbindung ändern'' aufrufen.

Es erscheint der Dialog ''Eigenschaften von <Verbindungsname>''. In der Liste im Dialog zu ''Internetprotokoll (TCP/IP)'' gehen. Ein Doppelklick auf den Eintrag öffnet den ''Eigenschaften von Internetprotokoll (TCP/IP)'' Dialog.

In diesem Dialog ''Folgende IP-Adresse verwenden:'' auswählen und zum Beispiel

IP-Adresse: '''192.168.0.100''' 
Subnetzmaske: '''255.255.255.0''' 
Standardgateway: '''192.168.0.1'''

eingeben.

Anmerkung von bitman:
[1] Dies ist spätestens ab Windows XP nicht mehr notwendig, wenn das Netz 192.168.0.0/24 noch frei ist. Dann kann man einfach den Client ''zusätzlich'' in diesem Netzwerk zusätzlich einbinden über Einstellungen/Netzwerkverbindungen/Lanverbindung/Eigenschaften/TCP-IP/Eigenschaften/Erweitert/IP-Adresse hinzufügen. Es werden dann eben mehrere IP-Adressen an den NIC gebunden.

Alle geöffneten Dialoge nacheinander mit OK schließen.

Alternativ bietet sich das Umprogrammieren des Boards über die serielle Schnittstelle an. Die Werte für IP-Adresse, Netzmaske und Standard-Gateway werden mit den dokumentierten SETxx-Befehlen geändert, das Board neu gestartet und ans vorhandene Netzwerk gesteckt.

Im EEPROM sind folgende Werte vorprogrammiert: 
3EE - 3F3 MAC-ADRESSE 
3F4 - 3F7 GATEWAY 
3F8 - 3FB NETMASK 
3FC - 3FF IP-ADRESSE 

==== PC bereits im 192.168.0.0/24 Subnetz ====

In diesem Fall muss man prüfen, ob die IP-Adresse 192.168.0.90 bereits im Subnetz verwendet wird. Ist dies der Fall, muss das verwendete Gerät mit dieser IP vorübergehend aus dem Subnetz entfernt werden. Es sei denn, dabei handelt es sich um den PC. In diesem Fall muss er wie zuvor umkonfiguriert werden. Ansonsten kann der unverändert im Netz verbleiben.

Dem AVR-NET-IO gibt man eine neue, zuvor unbenutzte Adresse (siehe unten). Dann kann das abgekoppelte Gerät wieder angeschlossen werden, beziehungsweise der PC zurückkonfiguriert werden.

=== AVR-NET-IO anschließen ===

Musste man den PC umkonfigurieren, so werden jetzt nur der PC und der AVR-NET-IO über Ethernet miteinander verbunden. Je nach Ethernet-Kabel benötigt man dazu einen Switch/Hub oder nicht.

Musste man den PC nicht umkonfigurieren, so kann man den AVR-NET-IO wie einen normalen Rechner an das vorhandenen Netz anschließen.

Zusätzlich schließt man die serielle Schnittstelle des AVR-NET-IO an den PC an.

=== Firmware 1.03 einspielen ===

Laut Handbuch sollte der AVR-NET-IO jetzt über Ethernet funktionieren. Ebenso sollte er über die serielle Schnittstelle und ein Terminalprogramm konfigurierbar sein. Beides ist offensichtlich im Auslieferungszustand selten der Fall.

Auch wenn sich Pollins NetServer Software nicht mit dem AVR-NET-IO verbinden lässt, so ist sie jedoch in der Lage eine neue Firmware 1.03 einzuspielen. Das Vorgehen ist im Handbuch auf Seite 12 beschrieben. NetServer präsentiert dabei ein paar einfache Anweisungen denen man folgen sollte.

Wenn sich nach dem scheinbar erfolgreichem Einspielen der Firmware, später nichts tut, so sollte die Firmware mit gesetztem "FailSafe" in der mitgelieferten NetServer-Software nochmals Eingespielt werden.

=== Abschluss ===

Jetzt sollte sich die NetServer Software mit dem AVR-NET-IO über Ethernet verbinden lassen. Dies macht es wiederum möglich, den AVR-NET-IO mit einer anderen IP-Adresse zu versehen. Will man den AVR-NET-IO in einem anderen Subnetz betreiben kann man dies jetzt einstellen.

Nachdem man die IP-Adresse neu eingestellt hat, muss man den PC zurückkonfigurieren und kann dann sowohl den AVR-NET-IO und den PC zusammen betreiben.

== Funktionsumfang der Originalsoftware ==
Die Originalsoftware ist sehr einfach gestrickt. Im AVR Net-IO läuft ein Programm, welches am Port 50290 ein Textschnittstelle bereit stellt. Diese Schnittstelle kann sowohl über die RS232 als auch über Ethernet angesprochen werden kann. Mit diesem Programm ist es möglich, alle Eingänge sowie alle Ausgänge anzusprechen, als auch die Konfiguration der Netzwerkeinstellungen zu verändern. Die Karte versteht dann folgende Befehle:
* SETPORT
Einen digitalen Ausgang auf 0 oder 1 schalten
* GETPORT
Den Status eines digital Ausgangs/Eingangs abfragen
* GETSTATUS
Den Status aller digital Ausgänge abfragen
* GETADC
Den Messwert eines analogen Eingangs ermitteln
* SETIP
Die IP-Adresse des Boards ändern
* GETIP
Die eingestellte IP-Adresse abfragen
* SETMASK
Die Netzwerkmaske verändern
* GETMASK
Die eingestelle Netzwerkmaske abfragen
* SETGW
Das Netzwerk-Gateway verändern
* GETGW
Das eingestellte Netzwerk-Gateway abfragen
* INITLCD
Ein angeschlossenes LCD initialisieren
* WRITELCD
Einen Text am LCD ausgeben
* CLEARLCD
Ein angeschlossenes LCD löschen
* VERSION
Die Versionsnummer des Programms ausgeben

Dazu gibt es ein auf Java basierendes Programm, welches alternativ zu einem Terminalprogramm benutzt werden kann. Es zeigt den Status der Portpins an und diese lassen sich auch mit der Maus verändern. Die Messwerte der 4 analogen Eingänge werden ständig angezeigt, wobei es möglich ist, durch einstellbare Faktoren die internen Werte gleich in sinnvolle Einheiten umrechnen zu lassen. Diese Messwerte können auch in eine Datei geloggt werden.
Neben der Möglichkeit, alle Kommandos auch händisch einzugeben, wird das Java-Programm auch benötigt, um einen Firmware-Update der Net-IO Platine durchzuführen.
Alles in allem ist dieses Frontend aber mehr als Testumgebung anzusehen, um damit die Hardware in Betrieb zu nehmen. Für einen sinnvollen Dauereinsatz ist das Programm deutlich zu einfach und unflexibel gestrickt. Auch kann die grafische Aufbereitung der Anzeige- und Kontrollelemente nicht befriedigen.

== Bekannte Fehler ==
=== AVR-NET-IO ===

Siehe auch [[#Hardware-Umbauten_.26_-Verbesserungen|Hardware-Umbauten und Verbesserungen]] 
Käufer berichten von fehlenden Bauteilen im Bausatz (Wannenstecker, Widerstände, Kondensatoren, Induktivitäten). Für Reklamationen: [https://www.pollin.de/shop/kontakt_service/reklamation.html]

* Die Stückliste auf Seite 4 in den Anleitung mit den Versionsangaben
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)
:ist falsch. Pollin legt dem Bausatz irgendwann ab September 2008 einen gedruckten Korrekturzettel bei. Die Online-Version der Anleitung ist korrigiert.
* Im Schaltplan auf Seite 7 in den Anleitungen mit den Versionen
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)
** ''Stand 03.09.2008, online, #all, wpe'' (Online)
:ist eine 25-polige SUB-D Buchse gezeichnet. Geliefert wird und in der Stückliste verzeichnet ist ein Stecker.

* Die September 2008 ausgelieferte Firmware im ATmega32 funktioniert bei vielen nicht und muss erst upgedatet werden (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])

* Im Flash der gelieferten AVR ist anders als beschrieben nur der Bootloader enthalten, die eigentliche Firmware muss erst mit Hilfe der Updatefunktion geladen werden. Wenn zusätzlich auch die Fuses falsch gebrannt sind, dann funktioniert das Update nicht, auch wenn das PC Programm was anderes behauptet.

* Die Fuse-Einstellungen des ausgelieferten ATmega32 entspricht nicht der Anleitung (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])

* Bausatz, gekauft am 27.10.08, Anleitungsversion 19.09.08, ohne Probleme oder erkennbare Fehler zusammengebaut und in Betrieb genommen.

* Bausatz gekauft 29.09.2008, Pinbelegung des 25 poligen D-Sub "Anschlusses" stimmt nicht mit der Anleitung überein. Der Aufdruck auf der Platine ist falsch. Pin1 <-> Pin13, Pin2 <-> Pin12 usw. Setzt man den D-Sub Stecker ein, so sind dessen Pinnummern korrekt. Bei einem Bausatz gekauft 05/2013 ist dies ebenfalls noch der Fall.

* 3 Bausätze Anf. Oktober 2008 gekauft, bei einem waren 2 LM317 dabei, dafür fehlte der 7805 - aus der Bastelkiste ersetzt. Alle haben jedoch auf Anhieb funktioniert

* Bausatz gekauft Ende Januar 2009. Die Lock-Bits (u.a. für PonyProg2000) werden falsch beschrieben. Die in Klammern aufgeführten Werte stimmen bei einem Bit nicht. Die Texte "Programmiert/Unprogrammiert" hingegen schon. Bei den Bauteilen gab es 4 Kondensatoren mit der Aufschrift "220", ich habe diese durch welche mit 22p ersetzt, da ich nicht sicher war ob wirklich 22p geliefert wurden. Dafür wurden statt einem zwei 7805 und statt einem mindestens vier LM317 mitgeliefert.

* Bausatz geliefert 22.4.2009. Alles vollständig, zusammengebaut, läuft. Software-Version 1.03. Für den oben schon genannten Steckverbinder wurde eine Buchse geliefert. Allerdings stimmen die PIN-Nummern im Schaltplan nicht mit den PIN-Nummern auf der Buchse überein (sie sind gespiegelt), daher liefen die Test-LEDs zunächst nicht.

* Bausatz geliefert 11.7.2009. Spannungsregler LM317T fehlt, grüne statt roter LED. Ein Kondensator 22pF zu viel. LM317T wurde auf Anfrage kostenlos nachgeliefert (27.7.). Inbetriebnahme problemlos.

* Bausatz geliefert 24.7.2009. Ein Quarz 16MHz zu viel, ebenfalls grüne statt rote LED.

* Bausatz geliefert 20.08.2009. Ein Kondensator 22pF zuviel und grüne statt rote LED.

* Bausatz Juli '09 gekauft, grüne statt rote LED

* Bausatz 25.09.09 geliefert, grüne Betriebs-LED, ein ELKO zuviel, Fehler 1µF am MAX232 statt 100nF behoben, richtiger C wird mitgeliefert, Aufbau komplett nach Pollin Anleitung durchgeführt, auf Anhieb fehlerfrei!

* Bausatz 17.10.09 geliefert, grüne Betriebs-LED, zwei 100nF Kondensatoren zu wenig. Aufbau und Inbetriebnahme problemlos.

* Bausatz 21.10.09 gekauft, grüne Betriebs-LED. Aufbau problemlos, RS232 läuft nicht. LAN läuft

* Bausatz Nov. 09 gekauft, grüne LED, alles o.k.

* Bausatz Nov. 09 gekauft, grüne LED, ENC28J60, MAX232 und ATmega32 fehlen, Nachlieferung nach einer Woche

* Bausatz Nov. 09 gekauft,Bauteile komplett.Verbindungsaufbau Seriell klappt erst nach mehreren Versuchen.Problem gelöst:Spannung an MAX und Mega zu niedrig

* Bausatz Dez. 09 gekauft, grüne LED, 100µF Kondensator fehlt, alles o.k.

* Bausatz August 09 gekauft, alle teile da nach Einstellen der fusebits lief alles perfekt

* Bausatz Okt. 09 gekauft, ein 100nF Kondensator und 25MHz Quarz fehlten ... hab beim lokalen Elektronikhändler keinen 25Mhz Grundton Quarz sondern nur im 3. Oberton bekommen aber mit R2.2k parallel zum Quarz schwingt er in der Schaltung schön bei 25Mhz. Mit 1µF am MAX232 funktioniert jetzt auch die RS232.

* 2x Bausatz Feb. 10 gekauft, bei beiden fehlten 7805, L1+L2 je 100µH sowie 4x falscher Wert Kondensator an Max232 vorhanden. Fehlende Bauteile nachgelötet und Funktion getestet. Hat alles einwandfrei funktioniert!!!

* Bausatz März. 10 gekauft, RS232 Printbuchse fehlt, dafür 1x 10pol Wannenstecker zuviel. Grüne LED statt Rot. Funktioniert ansonsten einwandfrei.

* Bausatz Jan. 10 gekauft, gelbe LED statt rot, C14...C17: 10µF, weder seriell noch via Ethernet Konnektivität. Nach Austausch von C14-C17 gegen 1µF, wenigstens serielle Kontaktaufnahme möglich, kein Ethernet auch nach Flash von 1.03 mit NetServer.

* Bausatz Feb. 10 gekauft, Spannungsregler LM317T fehlte

* Bausatz März 10 gekauft, gelbe statt rote LED geliefert, aber Aufbau und inbetriebnahme lt. Handbuch ohne Probleme

* Bausatz März 10 gekauft und gelbe statt rote LED geliefert, funzt wunderbar gemäß Anleitung

* Fertig gelötete Platine gekauft. µC war falsch im Sockel.

* Bausatz April 10 gekauft und gelbe statt rote LED geliefert, ADM232LJN statt MAX232 - Funktion erst nach Ersetzung des ADM durch nen MAX

* Bausatz April 10 gekauft und gelbe statt rote LED geliefert, ADM232LJN statt MAX232 - funktionierte sofort auch mit dem ADM232LJN.

* Bausatz April 10 gekauft wurde mit grüner statt roter LED Ausgeliefert

* Bausatz Juni 10 gekauft: wurde mit grüner statt roter Netz-LED ausgeliefert, 2x 22pF Kerko zuviel

* Bausatz August 10 gekauft: komplett und sofort funktioniert

* Bausatz Juli 10 gekauft: 2 Quarze mit 16 MHz geliefert, statt 1x 16MHz und 1x25MHz.

* Bausatz September 10 gekauft: hat sofort funktioniert. 1x 3,3k und 1x 10k Widerstand zuviel. Statt 100nF Kondensatoren wurden 1µF geliefert -> Platzprobleme auf der Platine durch grössere Bauform. LED grün.

* Bausatz Oktober 6 gekauft: alles funktioniert. LED grün statt rot.

* Fertigmodul Oktober 10 gekauft: Auf Anhieb alles funktioniert!

* Bausatz Oktober 10 gekauft: komplett und sofort funktioniert

* Bausatz November 10 gekauft: komplett und sofort funktioniert (sogar mit der neusten Pollin Firmware 1.03 schon drauf) LED grün statt rot.

* Bausatz November 10 gekauft. Nach Bezug neuer Feinst-Lötspitzen konnte ich ihn dann auch zusammenlöten. Es hat sofort alles funktioniert, obwohl ich nur 12V bzw. 9V Gleichspannung zur Verfügung hatte, und nicht sicher war, wieviel die Komponenten wirklich benötigen. Der Regler wird auch bei 9V Gleichspannungsversorgung noch sehr warm. Da muss auf jeden Fall ein Kühlkörper dran! Ich habe auch eine grüne LED bekommen, ist mir aber wurscht :-)

* Bausatz Dezember 10 gekauft: komplett und funktionierte sofort. Firmware 1.03, grüne LED (Ein Quarz und ein IC-Sockel zu viel)

* Bausatz Januar 2011 gekauft: nur genau die richtige Anzahl Teile dabei, Firmware 1.03, grüne LED, ging auf Anhieb

* 2x Bausatz Januar 2011 gekauft: beide grüne LED, und 1x doppelter Satz Jumper/Stiftleiste, 22PF und Anschlussklemmen. Rest vollständig und beide haben sofort nach zusammenbau funktioniert.

* Februar 2011: AVR-NET-IO: die Diode D5 fehlt, 10 µF gegen 1 µF für MAX232 getauscht, Flash im ATmega32 war programmiert, passende IP-Adr über serielle Schnittstelle eingestellt; ADD-ON: für R1 war 22Ω statt 0,2Ω beigelegt, durch richtigen ersetzt, Beschreibung der LED Bestückung mangelhaft / oe1smc

* Februar 2011: AVR-NET-IO: 1 Diode zuviel, 2 Spulen fehlen, LED grün. Die fehlenden Spulen wurden durch welche aus der Bastelkiste ersetzt - funktioniert. Der 7805 bekam einen kleinen Kühlkörper spendiert.

* Februar 2011: AVR-NET-IO: 2x 10k Widerstände fehlen. Dafür eine Diode zu viel.

* Ende Februar 2011: Zwei Bausaetze an jeweils zwei Adressen, alles in Ordnung.

* Ende März 2011: 2x 25 Mhz Quarz statt 1x16 u. 1x25 Mhz. LED fehlt. Bausatz funktioniert nach Tausch des Quarz den mir mein Freund oe9rsv aus seinem Fundus spendiert hat. Danke auch für die Hilfe beim Fehler suchen.

* Mitte 2010 gekauft: 1x 100nF fehlt

* Mitte Juni 2011: Beide Quarze fehlen und beide Spannungsregler fehlen, Pollin wollte, dass ich das ganze Paket zurückschicke für einen Austausch. Ein 51Ω zu viel. 16Mhz im Handel und 25Mhz vom alten Mobo ausgelötet. Läuft wunderbar.

* Anfang Juni 2011: Beide Quarze fehlen und beide Spannungsregler fehlen, nach kurzer Mail an Pollin (leider ohne Antwort) wurden diese nach ca. 1 Woche in einem Brief nachgeliefert.

* August 2011: alles 1a...

* August 2011: Platine fehlte -> in Nachlieferung

* 30 August 2011: alles 1a...

* 06 Sep. 2011: alles 1a...

* August 2011: 6 Stück bestellt, bei einem haben die 100nF Kondensatoren gefehlt, bei einem zwei LM317 statt 7805 und LM317. Angerufen, 3 Tage später Nachlieferung erhalten.

* Nov. 2011: '''Net_IO''' vollständig. Einspielen der Firmware 1.03 war erforderlich. Bei '''Add-On''' immer noch falscher Q1 BC548 (NPN) in Stückliste und Lieferung. BC327-40 oder BC328-40 (PNP) nachgefordert. R11 und R24 mitgeliefert, entsprechend Beschreibung V1.1 von Pollin's Download. Beiliegende Beschreibung war älter, ohne diese Widerstände.

* Ende Nov.2011, alle Teile dabei, Firmware war drauf, sofort funktioniert.

* Anfang Dez.2011, komplett bestückte Platine gekauft. Auf 7805 Kühlkörper gebaut, da er nach 1 Minute schon ausgestiegen ist (LED hat das Pumpen angefangen). Firmware 1.03 musste noch aufgespielt werden danach funktioniert alles einwandfrei. In Betrieb mit 10V DC

* Ende Dez.2011 2xNET-IO und 2xADD bestellt, 4 verschieden volle Kisten bekommen... WSL16 ist mit Verriegelung, geht nicht aufs Board, Jumper fehlen, Spannungsregler doppelt, Poti Löcher zu klein, lsb3 fehlt, SD-Slot hab ich jetzt 3, 100nF hab ich jetzt 4 übrig ... also immer noch lustig. HW-Stand immer noch 1.0 ( gab es überhaupt eine 1.1?)

* Mitte Jan. 2012, 10pol. beide Wannenstecker nicht dabei, Firmware war drauf, sofort funktioniert. 1 LED zuviel. Unproblematische Nachlieferung bei Reklamation (wegen der beiden Wannenstecker kam ein PAKET!).

* Ende Feb. 2012, Um die PHP-Scripte über öffentlichen Webserver zu betreiben muss mit SETGW die Gateway-Adresse des lokalen Routers eingetragen werden. Bei der NAT im Router sollte z.B. Port 8080 auf den internen Port 50290 umgeleitet werden, da manche Provider diesen Port für die Socket-Kommunikation nicht zulassen.

* Juli 2012, Bausatz vollständig, Nach Aufbau sofort den 7805 mit einem kleinen Kühlkörper versehen, da er sonst thermisch überlastet wird! hat weder auf LAN noch RS232 reagiert, musste erst Update einspielen (Download Pollin), danach funktionierte alles einwandfrei!

* Januar 2013, Bausatz vollständig, 7805 mit Kühlkörper versehen, nach Aufbau ohne Probleme funktioniert

* Februar 2013, Bausatz komplett, Aufbau ohne Probleme, 7805 nur leicht warm, LAN funktioniert, RS232 noch ohne Funktion.

* Oktober 2013, Bausatz komplett laut Stückliste, problemloser Aufbau, 7805 leicht warm am 10V DC. RS232 und LAN funktionierten auf Anhieb.

* Januar 2014, Bausatz komplett, Aufbau ohne Probleme, Betrieb mit 9V DC, LAN funktioniert auf Anhieb, RS232 noch nicht getestet.

* März 2014, Komplettgerät, von ca. 100 Versuchen gerade mal 2 erfolgreiche Zugänge. Weder LAN noch RS232 mit Putty funktionierten.

=== Erweiterungsplatine ===

Die nachfolgend genannten Änderungen sind in der Bauanleitung V1.1 mit Stand 07.12.2011 (Wichtig! Es gibt mehr als eine V1.1 ...) bereits berücksichtigt, R3 wird allerdings mit 3,6kΩ angegeben.

Um bei einem Neuaufbau parallele Widerstände zu vermeiden, sollten folgende Änderungen auf dem Addon-Board gemacht werden:
*R2 1,5kΩ ersetzen mit 2kΩ
*R3 1,8K ersetzen mit 3,3kΩ
*R19 470kΩ ersetzen zu 470Ω
*Q1 BC548 ersetzen durch BC327 oder BC328 (Hauptsache PNP! und mehr als 100mA)

'''ACHTUNG''' beim Anschluß eines LC-Displays an J5 (über I2C, PCF 8574): Vcc/5V liegt an Pin 1, GND an Pin 2 von J5. Es gibt etliche Displays mit abweichender Belegung Pin 1 GND und Pin 2 Vcc!

Auch beim Add-On gibt es fehlende oder falsche Bauteile im Bausatz und Fehler im Schaltplan und auf der Platine:

*Stand Feb. 2011: R2 wird mit 2,2kΩ und R3 wird mit 3,6kΩ ausgeliefert. Somit werden die 3,3 V richtig erzeugt. R19 hat 470Ω. Der ISP-Anschluß ist nicht vollständig durchgeschleift, es besteht keine Verbindung der RESET-Leitung zwischen ISP und ISP1 (Abhilfe: Drahtbrücke einlöten, [http://www.mikrocontroller.net/topic/161354#1600385 Quelle]).

*Stand Nov. 2011: bei mir ist die RESET-Leitung korrekt zw. ISP und ISP1 verbunden. Es gibt jetzt auch einen R24 (470Ohm) und R11 (1KOhm), der in der bei mir mitgelieferten Bauanleitung fehlt, in der zum Download (V1.1) angebotenen aber drin steht. Es wird immer noch der falsche Q1 BC548C (NPN) mitgeliefert. Das Schaltsymbol für einen PNP ist richtig im Schaltplan gezeichnet.

*Stand Dez. 2011: R24 (470Ω) kann mit 0Ω ersetzt und R11 (1kΩ) völlig weggelassen werden. Diese Widerstände bilden einen (eigentlich überflüssigen) Spannungsteiler in der MISO Leitung. Der Spannungsteiler hat allerdings auch eine Schutzfunktion, falls weitere Slaves am SPI-Bus hängen, die 5V-Pegel nutzen, z. B. ISP-Programmierer. (siehe [http://son.ffdf-clan.de/include.php?path=forumsthread&threadid=1167&postid=9203 1284p: Board, ich oder beide verwirrt?])

*Sept'12: Bausatz mit Stecker anstelle einer Buchse ausgeliefert, 5mm anstelle von 3mm LED's dafür aber 3 Poti zuviel.

*Sept'12: Ebenfalls Bausatz mit Sub-D-Stecker statt Buchse ausgeliefert, 5mm anstelle von 3mm LED's und 3 Potis zuviel.

*Stand März 2013: Die Belegung der 25 pol. Sub-D-Buchse im Schaltplan der Anleitung V1.1 (und früher) ist falsch dargestellt. SCL und SDA des I2C-Busses liegen wie beim AVR-NET-IO Board auf Pin 2 bzw. 3 und nicht auf Pin 11 bzw. 12 der Buchse. Ein 1:1 verdrahtetes Kabel funktioniert.

== Andere Software für den Client-PC ==
=== NetIOLib ===

In C# geschriebene Bibliothek zur Ansteuerung der Platine im Orginalzustand. Inkl. Beispielsoftware und Quellcode (GNU GPL)

Links gehen nicht:
DLL: [http://www.tware.org/downloads/NetIOLib_dll.zip Download-Link]
Source: [http://www.tware.org/downloads/NetIOLib_src.zip Download-Link]

=== E2000-NET-IO-Multi-Control ===
Mti dem E2000-NET-IO-Multi-Control ist es möglich, die vom dem E2000-NET-IO-Designer erstellten Projekte zu öffnen und die AVR-NET-IO's zu steuern.

Die Anwendung liegt dem [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#E2000-NET-IO-Designer_.28Windows.5BXP.2F7.5D_.2F_Android.29 E2000-NET-IO-Designer] bei.

=== ControlIO ===
Einfache Bibliothek zur Ansteuerung mit Originalfirmware.
http://www.mikrocontroller.net/topic/149695

=== JAVA Lib ===
Einfache Java-Bibliothek zur Ansteuerung mit Originalfirmware.
http://son.ffdf-clan.de/?path=forumsthread&threadid=611

=== PHP ===
PHP Klasse zur Ansteuerung mit der Originalfirmware. (Opensource Lizenz)
http://blog.coldtobi.de/1_coldtobis_blog/archive/298_pollin_net-io_php_library.html

PHP Funktionen zum Ansteuern der Originalfirmware. (Free for All Lizenz)
http://defcon-cc.dyndns.org/wiki/index.php/Pollin_AVR-NetIO_PHP_Wrapper

== Clients für Smartphones ==

=== AVR NET IO Control (Windows Phone 7.5,7.8,8.0) ===

Freie App zur steuerung des AVR NET IO.

'''App im Market: [http://www.windowsphone.com/de-de/store/app/avr-net-io-controll/030d107f-9a27-4a62-ac8f-cb74e79c0500 AVR NET IO Control]'''
=== App NetIO (Windows Mobile 6.5) ===
Frei verfügbare App für Windows Mobile zur Ansteuerung mit der Orginalsoftware. Das HTC HD2 wird damit zur Fernsteuerung für das AVR Net-IO Board.
http://www.heesch.net/netio.aspx

=== NET-IO Control (Android) ===
Eine Application für das Android Betriebssystem zur Steuerung des AVR Net-IO Boards. Es ist möglich, alle Ausgänge zu steuern und alle Eingänge anzuzeigen. Die Analogen Eingänge können mit einem Berechnungsfaktor versehen werden. ''Geplant ist noch ein Offsetwert.'' Außerdem kann jedem analogen Wert eine Einheit zugeordnet werden. Die Ausgänge können in der neusten Version in einen Tastermodus gesetzt werden.

[[Datei:NET-IO-Control.png|200px]] [[Datei:NET-IO-Control2.png|200px]] [[Datei:NET-IO-Control3.png|200px]]

'''Trial-Version: [https://play.google.com/store/apps/details?id=de.android.AVR.NETIOControlTRAIL Google-Play]'''

(In dieser Probe Version können nur 1 Output und 2 Inputs gesteuert werden)

'''Vollversion: [https://play.google.com/store/apps/details?id=de.android.AVR.NETIOControl Google-Play]'''

(Kostet im Google-Play 3,00 €)

Weitere Informationen sind auf der Entwickler-Seite zu finden: [http://elektronik2000.de/ Elektronik2000.de]

=== E2000-NET-IO-Designer (Windows[XP/7] / Android) ===
[[Datei:E2000-NET-IO-Designer.png|400px|right]]
Mit dem E2000-NET-IO-Designer ist es möglich, eine grafische Oberfläche für die NET-IOs von Pollin zu erstellen. Dafür werden Knöpfe, Texte und Anzeigebilder zur Verfügung gestellt. Jedes dieser Element kann "Aufgaben" übernehmen um die NET-IOs zu steuern oder einen Status des NET-IO anzuzeigen. Weitere Icons können von dem Benutzer selbst in den entsprechenden Ordner gelegt werden und in die Oberfläche eingebunden werden. Es können mehrere Seiten designt werden die durch einen selbst positionierten Knopf erreichbar sind. Die Android Application arbeitet somit im Fullscreen-Modus. Des weiteren ist es möglich, mehrere NET-IO's in einem Projekt zu benutzen. Nach dem erstellen der grafischen Oberfläche mit dem E2000-NET-IO-Designer, kann mit der Android APP das Projekt einfach gedownloaded werden. Dafür baut die APP eine Verbindung zum E2000-NET-IO-Designer auf und läd alle benötigten Dateien herunter (Achtung: Firewall-Einstellungen beachten). Die designten Oberflächen können außerdem noch mit der E2000-NET-IO-Multi-Control.exe auf dem Computer ausgeführt werden. Dadurch ist es Möglich, seine NET-IOs vom PC aus zu steuern über eine selbst designte Oberfläche.

Zum Ausführen des E2000-NET-IO-Designer muss .NET Framework 4.0 installiert sein und es muss eine Internetverbindung exisitieren.

'''Features:'''<ul>
<li>Grafische Oberfläche am PC erstellen</li>
<li>Verwendung von eigenen Button- und Hintergrundbildern</li>
<li>Designbare Anzeige von Digital- und Analogwerten</li>
<li>Steuern von mehreren AVR-NET-IO Boards</li>
<li>Unterstützung der E2000-NET-IO Firmware (mehere Boards gleichzeitig)</li>
<li>Designte Steuerungen können auf dem PC oder dem Handy ausgeführt werden (Android)</li>
<li>Schnelle Verbindung</li>
<li>Einfache übertragung auf das Handy durch Projekt Download</li>
</ul>

[http://www.elektronik2000.de/downloads.php?id=44 Download E2000-NET-IO-Designer]

[http://www.elektronik2000.de/hilfe/E2000Netdesigneruebersicht.html Online Hilfe]

Weitere Informationen sind auf der Entwickler-Seite zu finden: [http://elektronik2000.de/ Elektronik2000.de]

=== NetIO ( iPhone & Android ) ===
<div style="float: left; margin-right: 20px">[[Datei:Netio_logo.png|70px]]</div>

Schöne universelle Fernbedienung für das Board (iOS / Android). Konfigurierbar über einen Browserbasierten Editor. 
Unterstützt TCP socket Verbindungen, kann http request absetzen und kann auch Webseiten einbinden (z.B. IP-Kameras). Kann mehrere
Boards gleichzeitig steuern! Einfach super schnell ins Projekt eingebaut... Es gibt Buttons (die auch als Taster konfiguriert werden können), Slider, Switches und einfache Labels. Dinge können geschaltet oder Daten ausgelesen und mit regex dargstellt werden.

<div style='float: right'>
[[Datei:Netio_TV.png|190px]]
[[Datei:Netio_iphone5.png|190px]]
[[Datei:NetIO_appflow.jpg|190px]]
</div>

 
AppStore Link: http://itunes.apple.com/app/netio/id464924297?mt=8 
Google Play Link: https://play.google.com/store/apps/details?id=com.luvago.netio 
Die gleiche Konfiguration kann auch mit einem [https://github.com/davideickhoff/NetIO-OSX-Dashboard-Widget OSX Widget] benutzt werden. 
Webseite: http://netio.davideickhoff.de

Hinweis: Man findet es unter "NetIO" im Store, im Icon selbst und in iTunes wird es als "Controller" angezeigt. 
Die eigene Konfiguration kann man mit dem [http://netio.davideickhoff.de/editor Online Editor] vorher am PC erstellen.
Eine fertige [http://netio.davideickhoff.de/editor/?config=pollin AVR-NET-IO Konfiguration] gibt es als funktionierendes Beispiel schon als Preset.

 
<div style='clear: both'></div>

=== AVR Net IO (iPhone) ===
[[Datei:AVRNetIO-Screenshot1.png|160px|rechts]]
Update 15.12.2011: Die Neue Version 1.3 ist seit gestern im AppStore. Fehlerkorrekturen und ein robusteres Handling machen die App nun zur universellen AVR-Net-IO-Steuerung.

Mit der [http://itunes.apple.com/de/app/avr-net-io/id460991760?mt=8 iPhone App AVR-Net-IO] kann das Board ferngesteuert werden. Die Fernsteuerung umfasst in der Version 1.1 folgende Funktionen: <ul>
<li>ADC-Werte zyklisch auslesen und darstellen</li>
<li>Digital-Inputs zyklisch darstellen</li>
<li>Digital-Outputs können über Buttons geschaltet werden. Die Werte der Digital-Outputs werden zuerst ausgelesen und zeigen den zuletzt gesetzten Wert an.</li>
<li>Terminal-Modus: Hier können beliebige AVR-Net-IO-Befehle eingegeben werden. Das Ergebnis wird 1:1 angezeigt, wie es vom Board kommt. Hilfreich für Tests bei Eigenentwicklungen und Konfigurationen.</li>
</ul>
 
Mehr Infos gibt's dazu direkt von den Entwicklern auf [http://www.facebook.com/pages/AVR-Net-IO/187799687958255?ref=nf AVR-net-IO Facebook-Page] oder direkt auf deren Homepage [http://www.ondics.de/apps/1001/ Homepage].
 
Hinweis: MIt der aktuellen Version 1.1 gibt es noch bei manchen Boards Probleme beim auslesen und anzeigen der ADC- und Digital-Werte. Das Terminal funzt problemlos. Die Entwickler kümmern sich gerade drum und haben einen baldigen Update versprochen.
 

== Andere Software statt der Originalsoftware von Pollin ==

Die Umrüstung auf einen Webserver durch Austausch der Software (und ev. des ATmega32) bietet sich an. Kleiner Hinweis dabei: wenn zum Flashen ein ISP-Adapter verwendet wird, diesen unbedingt vor dem Start der neuen Software abziehen! Der ISP arbeitet nämlich über dieselbe SPI-Schnittstelle über die auch der ENC28J60 angesteuert wird. Ein eventuell noch angeschlossener, wenn auch passiver ISP-Adapter stört diese Kommunikation, d.h. das Programm an sich scheint zu laufen, aber die Ethernet-Schnittstelle funktioniert nicht.

=== E2000 - Logik ===

[[Datei:E2000-Logik-Bedienoberflaeche.jpg|500px|rechts]]

Anwenderfreundliche Logik-Software von Elektronik2000.de zur Steuerung des AVR-NET-IO. Der ATMEGA32 wird durch einen ATMEGA644 ersetzt und mit der E2000-Firmware beschrieben. Nun ist es möglich in der E2000-Logik Software eine Logikschaltung zu erstellen und diese auf das NET-IO-Board zu übertragen. Dort wird diese Schaltung simuliert. Dies funktioniert komplett ohne einen Computer.

Durch ein Erweiterungsboard von Elektronik2000.de ist es auch möglich, das Board ohne Internet laufen zu lassen eine RTC (RealTimeClock) übernimmt dabei die Uhrzeitgesteuerten Funktionen. Auf dieser Erweiterung ist auch ein EEPROM integriert, um Firmware-Updates über Netzwerk einzuspielen (in Zukunft). Diese Erweiterung bietet außerdem die Anbindung an das E2000-Bus-System, durch das es möglich ist das AVR-NET-IO-Board durch weitere Ein- und Ausgänge zu erweitern.

Das Designen von Schaltaufgaben wird in diesem Programm grafisch dargestellt, durch das ein einfaches Anpassen seiner Logikschaltungen möglich ist.

Eine Steuerung des E2000-NET-IO ist möglich durch den Intregrieten Webserver, die PC-Software (E2000-NET-IO Control) oder der Androidsoftware. All diese Können gleichzeitig auf das E2000-NET-IO zugreifen und Funktionen ausführen.

Weitere Informationen gibt es auf der Entwicklerseite: [http://www.elektronik2000.de Elektronik2000.de]

=== Bascom Version von Hütti ===

(Quelle: http://bascom-forum.de/index.php/topic,1781.45.html )
dort am Ende der Seite.

=== Ben's Bascom Quellcode ===

(Quelle: http://members.home.nl/bzijlstra/software/examples/enc28j60.htm )

Muss aber für Bascom 1.11.9.3 angepasst werden, siehe Code von Hütti !

=== U. Radigs Webserver ===

Angepasster Sourcecode von U.Radig: http://www.mikrocontroller.net/attachment/40027/Webserver_MEGA32.hex
oder selbst anpassen:
Ändere in der Datei ENC28J60.H:
#define ENC28J60_PIN_CS 4
(Quelle: http://www.mikrocontroller.net/topic/109988#988386)

Temporären Dateien (*.d, *,lst,*.o) vorher im Verzeichnis löschen ''make clean'', damit neu compiliert wird.

IP: 192.168.0.99 
User: admin 
Pass: uli1 

Den orginal SourceCode gibt's übrigens hier:http://www.ulrichradig.de/home/index.php/avr/eth_m32_ex

Bei den Fuses BOOTRST ausschalten, da die Software keinen Bootloader enthält.

IP: 192.168.1.90 
User: admin 
Pass: tim 
Test: http://beitz-online.dyndns.org 
Test: http://pieper-online.dyndns.org 

Weiterentwicklung des Radig-Codes von RoBue: 
- 1-Wire-Unterstützung (Anschlus an PORTA7) 
- PORTA0-3 digitaler Eingang (ein/aus) 
- PORTA4-6 analoger Eingang (0 - 1023) 
- LCD an PORTC 
- Schalten in Abhängigkeit von Temperatur und analogem Wert 
- (Teilweise) Administration über Weboberfläche 
- Erweiterung des cmd-Befehlsatzes für telnet/rs232 
Gedacht ist der Einsatz des AVR-NET-IO-Bausatzes für Heizungs- oder Haussteuerung) 

Test: http://avrboard.eluhost.de/ 

(Quelle: 
http://www.mikrocontroller.net/attachment/43307/AVR-NET-IO_RoBue_V1.3.zip 
http://www.mikrocontroller.net/attachment/44569/AVR-NET-IO_RoBue_V1.4.zip 
http://www.mikrocontroller.net/attachment/46720/AVR-NET-IO_RoBue_1.5-final_hoffentlich_.zip)

Bei der Ver 1.5 sind die Ports PD2+3 fürs 4bit LCD (Ext.) vertauscht ! Gruß B.P

=== Simon Ks Webserver (uip-Stack) ===
Angepasster Sourcecode von Simon K: http://www.mikrocontroller.net/attachment/39939/uWebSrv.zip
IP: 192.168.0.93:8080 
Um diesen Code mit einem Atmega1284P verwenden zu können, muss in der main.c in Zeile 38, "TIMSK" durch "TIMSK1" ersetzt werden.
Die Fusebits für den Atmega1284p ohne Bootloader sind:
lfuse=0xFF, hfuse=0xD9, efuse=0xFF

=== Ethersex Server ===

http://www.ethersex.de - Einfach für atmega32 compilieren und funktioniert.

=== Etherrape Server ===

http://www.lochraster.org/etherrape/

ist in jedem Fall hier auch zu erwähnen zumal es sich beim etherrape um das Ursprungsprojekt von ethersex handelt.
Es scheint aber bei der Weiterentwicklung wenig zu passieren.
Ausführliche Dokumentation findet sich unter http://wiki.lochraster.org/wiki/Etherrape

=== Mini SRCP Server (kommerziell, Closed-Source)===

Damit wird die Platine zu einer Modellbahnsteuerung, die
über das Netzwerkprotokoll SRCP mit verschiedenen Programmen
gesteuert werden kann.

[http://www.7soft.de/de/mini_srcp_server/index.html Infoseite] zur Hardware
und das zugrundeliegende [http://www.der-moba.de/index.php/Digitalprojekt Digitalprojekt].

=== Avr ArtNET-Node ===

Hiermit kann die Platine zu einem Art-Net Node werden, mit dem sich ein DMX-Universe über Ethernet übertragen lässt. Basiert auf den Quellen von Ulrich Radig.

Dokumentation: [http://www.dmxcontrol.de/wiki/Art-Net-Node_f%C3%BCr_25_Euro Art-Net-Node für 25 Euro]

=== Webserver von G. Menke ===

Ein Webserver (basierend auf den Sourcen von U. Radig), der so angepasst ist, dass alle Ein- und Ausgänge wie bei der originalen Pollin-Software genutzt werden können (8xDIGOUT, 4xDIGIN, 4xADIN). Der Webserver kann daher direkt auf das Net-IO geladen werden. Im ZIP-File sind ein ReadMe und alle C-Sourcen enthalten. Download:
[http://gm.stream-center.de/webserver/ Webserver mit passender IO]

=== OpenMCP ===
'''(Projekt scheint erloschen - Links all down - Jan. 2014)'''

Tolles Projekt, welches viele Features bietet und stabil läuft. Hervorzuheben ist die Übersichtlichkeit der Programmteile/Module und die vielleicht nicht ganz komplette Dokumentation. Man merkt, dass viel Arbeit und Liebe in diesem Projekt steckt. Herausgekommen ist dabei eine einfach zu handhabende Entwicklungsumgebung. Anfänger können, dank des gut durchdachten CGI-Systems, welches sich um alle wichtigen Sachen kümmert, leicht eigene CGI implementieren. Alle Ausgaben erfolgen nur mit printf über die Standardausgabe und werden automatisch richtig per Netzwerk übertragen, dadurch ist es auch für den Anfänger recht gut geeignet, da man sich nicht mit der Netzwerkprogrammierung auseinander setzen muss.

Die Software belegt im Moment (Stand Juli 2010) ca. 55 Kb im Flash, so dass man das Board mit einem grösseren µC (z.B. ATMega644) aufrüsten muss.

[http://wiki.neo-guerillaz.de Projekt und Doku]

Der Autor stellt zwei über das Internet erreichbare Testboards bereit unter http://www.neo-guerillaz.de:81 und http://www.neo-guerillaz.de:82 die beide unter OpenMCP laufen, je auf einen AVR-NETIO mit einem ATmega644 und dem eigentlichen Board mit einem ATmega2561. Zusätzlich ist gerade eine Version für das myAVR in Arbeit die schon ordentlich Fortschritte macht.

=== OpenMLP ===
Auf openMCP basierender Port nach [http://avr.myluna.de LunaAVR] (GPL). Umfangreiche Funktionalität und direkte Anpassung an die Sprache. Abgespeckte Version auch auf Atmega32 lauffähig. Die Original-Dokumentation kann zum Großteil hergenommen werden. Einige Zusatzfeatures. Leichte Konfiguration und guter Einstieg für Anfänger und zum Verständnis der Serverfunktionalität.

[http://avr.myluna.de/doku.php?id=de:openmlp Artikelseite]
[http://forum.myluna.de/viewtopic.php?f=8&t=13 Forum]

=== ENC28J60 I/O-Webserver von Thomas Heldt ===

Ein Modul-Webserver (Softwarekompatibel zum Pollin Webserver), der durch div. Module erweitert werden kann, Software in Bascom basierend auf dem Code von Ben Zijlsta wurde erweitert und angepasst:

[http://mikrocontroller.heldt.eu/index.php?page=enc28j60-io-webserver Projekt und Software]

=== AVR-Netino ===
[http://code.google.com/p/avr-netino/ Projekt und Software]

Arduino fürs Net-IO

== Siehe auch ==
* Diskussion zu diesem Projekt: http://www.mikrocontroller.net/topic/109988
* [http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en022889 ENC28J60 Produktseite]
* [http://ww1.microchip.com/downloads/en/DeviceDoc/39662c.pdf ENC28J60 Datenblatt(pdf)]
* [http://son.ffdf-clan.de Forum für AVR-Net-IO]
* [http://avr.myluna.de/doku.php?id=de:openmlp LunaAVR openMLP ]
* [http://bascom-forum.de/index.php/topic,1781.0.html Bascom Forum ]
* [http://hobbyelektronik.org/w/index.php/AVR-NET-IO-Shield Shield für den NET-IO]

[[Category:AVR-Boards]]
[[Category:Ethernet|P]]

RGB Touch Matrix

2014-06-12T01:18:36Z

Maybee: /* Siehe auch */

''von Conny G.''

Es soll eine RGB Touch Matrix entwickelt werden, die z.B. für RGB-Touch-Tische eingesetzt werden kann.
Beispiel für einen Touch-Tisch: http://www.it-gecko.de/100pixel-rgb-led-tisch-interaktiv-touch.html
Dieser ist jedoch vom Hardware-Konzept sehr aufwändig gelöst, deshalb ist das Ziel des Projekts als Kern der Lösung zwei Dinge möglichst effizient zu lösen:
* die einzelnen RGB & Touch Pixel
* die Verbindung der Pixel auf Basis eines Busses
Effizient heisst: geringe Bauteilkosten, einfache Herstellung der Pixel und einfach Verkabelung, idealerweise nur ein Bus von 1-2 Leitungen (zzgl. GND).

== Einleitung ==

Eine RGB-Touch-Matrix besteht aus folgenden Komponenten:

* Steuereinheit, die die Touch-Werte auswertet und entsprechend RGB-Werte an die Pixel zurücksendet
* eine größere Zahl (10x10 = 100 oder 10x20 = 200) RGB & Touch-Pixel, die jede Zelle beleuchten und für jede Zelle ein Touch-Sensing durchführen
* einem Bus zwischen diesen Komponenten

== Bus ==

Die RGB-Touch-Pixel sollen über einen Bus verbunden werden. Das könnte entweder ein sternförmiger Bus sein oder eine Daisy-Chain wie die WS2811-Chips ihn bilden.

=== Ein Szenario mit Daisy Chain ===

Es sei eine CLK-Leitung vorausgesetzt, diese könnte jedoch auch implizit durch festes Timing gelöst werden (wie WS2811).

Ablauf:

Zunächst in Richtung MOSI, also Master sendet eine Chain von Daten an den ersten Slave.

* durch eine vorhergehende Pause ist der "LATCH & RESET"-Zustand eingetreten, d.h. alle Slaves wissen: wenn jetzt was kommt, dann ist das der Anfang
* Der Master sendet Bit für Bit an den ersten Slave
* der erste Slave nimmt sich die ersten 8x3=24 Bits und schreibt sie in seinen Zwischenspeicher für den RGB-Wert
* der erste Slave schreibt jedes weitere Bit direkt an den Ausgang ohne es weiter anzusehen
* dasselbe tut jeder weitere Node
* Pause: LATCH & RESET

Das ist die Richtung "RGB an Slaves", von den WS2811 bekannt.

Die Rückrichtung:
es müsste also jetzt beim Master an MISO nach und nach, Bit für Bit die Chain an Daten aus den Slaves ankommen, also muss sich hier das ganze Spektakel umgekehrt abspielen.
Während also die Bits in der "hin"-Richtung durchschieben, müssten ebenfalls die Bits in der Rück-Richtung durchshiften.

* Pause = LATCH & RESET setzt alle Slaves in Startzustand.
* wenn jetzt der erste Slave seine Daten bekommt, dann müsste er einfach gleichzeitig am Ausgang entweder seine oder die Daten des nächsten Node setzen
* er erhält also das erste Bit vom Master. Jetzt setzt er das erste Bit seiner Sensordaten
* nach den ersten 24 Bits (= seine RGB-Daten) sind seine Sensordaten durch (24 Bit Sensor-Daten)
* ab dann lauscht er auf seinem Eingang für Sensordaten vom nächsten Node und er reicht jedes Bit, das dort ankommt direkt an den Master weiter
* spannenderweise passiert es genau zum selben Zeitpunkt, dass er seine 24 Bit RGB-Daten durchhat und dann die weiteren Bits weiterreicht wenn er die Daten des nächsten Node für Rück weiterreichen soll, das läuft also 100% parallel
* der 2. Slave tut genau dasselbe

Nun kommen beim Hinsenden der RGBs genau der Strom an Sensordaten wieder zurück.

Vorteile:
* Die Datenübertragung dauert genauso lange wie es dauert die Daten seriell auf einen Bus zu schicken, da ist keine Zeitverzögerung
* es müssen vom Master keine Nodes addressiert und abgefragt werden, also maximal effizient
* für die bidirektionale Übertragung brauche ich keine Extrazeit, die Rückdaten kommen gleichzeitig
* es ist völlig egal, wieviele Slaves ich habe, solange die Gesamtübertragungrate noch die gewünschte Framerate hergibt. Danach kann man den Bus splitten und z.B. die ganze Kette in 2 Teile trennen und einfach 2x einspeisen, dann kann man mit selber Framerate doppelt soviele Slaves abdecken
* die Übertragung ist maximal Stör-un-anfällig, weil die Distanz zwischen den Clients kurz ist und das Signal jedesmal neu gesendet wird
* man braucht keine Tranceiver, die Attiny sind gleichzeitig die Tranceiver
* man braucht nur 2 Leitungen mit GND, wenn es mit implizitem Takt läuft

Idealerweise hängen alle Slaves einfach an einem Strang als einfachstmögliche Konstellation - einfache Verkabelung, keine mehrfach-Einspeisung in der Software.
Für einen 10x10 RGB-Touch-Tisch sind das 100 Slaves. Jeder hat 24 Bits zu bekommen, ergibt 2400 Bits.
Mal Framerate von 25 ergibt 25 x 2.400 Bits = 60.000 Bits pro Sekunde.
Vorsichtshalber betreiben wir den Bus mit 100 kBit, dann sind wir nicht in einem technisch kritischen Bereich und brauchen nur einen Strang. (Die WS2811 machen 800 kBit, also das 8-fache).
250 kbit sollten noch ebenso einfach machbar sein, dann kann auch ein 10x20 Tisch in einem Strang betrieben werden

Das Protokoll wäre auch mit nur einer Leitung denkbar, wenn noch einbaut, dass man den Slaves mitteilt: jetzt gehört die Leitung Euch!
Zum Beispiel: man sendet eine Chain von 0xffffff an alle (d.h. der RGB-Wert 0xffffff steht nicht zur Verfügung) und weiss: jetzt kommen als nächstes solange Bits zurück (Mode: MISO), bis mindestens eine Pause von xx Millisekunden da ist, dann ist der Mode wieder MOSI.
Man müsste gezielt RGB-Frames dafür ausfallen lassen, d.h. es reduziert die Framerate ein wenig und die Abtastrate der Touches ist auf 5-10/Sekunde begrenzt (das ist ausreichend).
Zum Beispiel: grundsätzliche Framerate 35 FPS, jeder 5. fällt aus für Touch-Sensing, dann habe ich 7x Touch pro Sekunde und 28 RGB-Frames.
Ein Problem mit unregelmässiger Refreshrate gibt es hier nicht, da alle Slaves beim letzten RGB-Wert bleiben und weiterleuchten, nur die Aktualisierung "stockt" für eine 35stel Sekunde, das ist nicht wahrnehmbar.

== RGB & Touch Pixel ==

== Siehe auch ==

* Forumsthread [http://www.mikrocontroller.net/topic/326662 LED Tisch mit Berührungs-/Gegenstandserkennung]
* Forumsthread [http://www.mikrocontroller.net/topic/329090 Schwierigkeiten passenden Bus zu finden]
* [[Audio-Projekt|Link zu anderem Projekt]]

[[Category:Projekte| ]]

AVR

2014-06-08T19:05:37Z

Maybee:

Die AVR-[[Mikrocontroller]] von [http://www.atmel.com Atmel] sind wegen ihrer übersichtlichen internen Struktur, der [[ISP | In-System-Programmierbarkeit]], und der Vielzahl von kostenlosen Programmen zur Softwareentwicklung (Assembler, Compiler) beliebt. Diese Eigenschaften und der Umstand, dass viele Typen in einfach handhabbaren DIL-Gehäusen (DIP) verfügbar sind, machen den AVR zum idealen Mikrocontroller für Anfänger.

Über die Bedeutung des Namens "AVR" gibt es verschiedene Ansichten; manche meinen er sei eine Abkürzung für '''A'''dvanced '''V'''irtual [[RISC|'''R'''ISC]], andere vermuten dass der Name aus den Anfangsbuchstaben der Namen der Entwickler ('''A'''lf Egin Bogen und '''V'''egard Wollan '''R'''ISC) zusammengesetzt wurde. Laut Atmel ist der Name bedeutungslos.

==Architektur==

Die Architektur ist eine 8-Bit-[[Harvard-Architektur]], das heißt, es gibt getrennte Busse zum Programmspeicher ([[Speicher#Flash-ROM |Flash-ROM]], dieser ist 16 bit breit) und Schreib-Lese-Speicher ([[Speicher#RAM |RAM]]). Programmcode kann ausschließlich aus dem Programmspeicher ausgeführt werden. Weiterhin sind die Adressräume getrennt (d.h. die erste Speicherstelle im Flash-Speicher hat die gleiche Adresse (0) wie die erste Speicherstelle im RAM). Bei der Programmierung in Assembler und einigen C-Compilern bedeutet dies, dass sich Konstanten aus dem ROM nicht mit dem gleichen Code laden lassen wie Daten aus dem RAM. Abgesehen davon ist der Aufbau des Controllers recht übersichtlich und birgt wenige Fallstricke.

* 32 größtenteils gleichwertige Register
* davon 1-3 16-bit-Zeigerregister (paarweise)
* ca. 110 Befehle, die meist 1-2 Taktzyklen dauern
* Taktfrequenz bis 32MHz
* Betriebsspannung von 1,8 - 5,5 V
* Speicher
**1-256 kB [[Speicher#Flash-ROM | Flash-ROM]]
**0-4 kB [[Speicher#EEPROM | EEPROM]]
**0-16 kB [[speicher#RAM | RAM]]
* Peripherie: [[AD-Wandler]] 10 bit, 8- und 16-Bit-[[Timer]] mit [[PWM]], [[SPI]], [[I²C]] (TWI), [[UART]], Analog-[[Komparator]], [[Watchdog]]
* [[Speicher#Mit_XMEM-Interface | 64kB Externer SRAM]] (ATmega128, ATmega64, ATmega8515/162); (Bei den XMEGAs bis zu 16 MB (128 Mbit) externer SDRAM)
* [[JTAG]] bei den größeren ATmegas
* [[debugWire]] bei den neueren AVRs

== Software ==
* [http://www.mikroe.com/mikropascal/avr]: Mikropascal, mit einer eingeschränkten kostenlosen Testversion
* [[AVR-Studio]]: Kostenlose Enwicklungsumgebung mit Simulator
* [http://www.atmel.com/tools/atmelstudio.aspx Atmel Studio 6]: Kostenlose Enwicklungsumgebung mit Simulator
* [http://sourceforge.net/projects/kontrollerlab/ KontrollerLab]: Kostenlose Entwicklungsumgebung für KDE
* [http://corpsman.de/index.php?doc=projekte/klab Klab]: Kostenlose Entwicklungsumgebung für KDE/GTK2/Win32 (als FPC/Lazarus Quellcode verfügbar, Nachbau von KontrollerLab)
* [http://www.microsoft.com/germany/Express/product/visualcplusplusexpress.aspx Microsoft Visual C++ Express]: Kostenlose Enwicklungsumgebung (Win),über makefile
* [http://netbeans.org Netbeans]: Plugin-basierte, kostenlose Entwicklungsumgebung (Windows, Mac, Linux, und Solaris). [http://mattzz.dyndns.org/wiki/bin/view/Projects/ArduinoAndNetbeans Hier] findet sich ein Howto für das Setup von AVR (z.B. für Arduino)
* [[AVR Eclipse]]: Plugin-basierte kostenlose Entwicklungsumgebung (Win, Linux, Mac)
* [[Code::Blocks]]: Freie Entwicklungsumgebung (Win, Linux, Mac), die auch für AVR-Projekte Unterstützung anbietet
* [[AVR-GCC]]: Kostenloser C-Compiler
* [[LunaAVR]]: Kostenlose, objektbasierte Basic/Pascal-ähnliche Programmiersprache und Entwicklungsumgebung mit Compiler/Assembler und Disassembler (Win, Linux, Mac). http://avr.myluna.de
* [http://sourceforge.net/projects/avra/ AVRA]: freier AVR-Assembler
* [http://www.mcselec.com/bascom-avr.htm Bascom AVR] beliebter Basic-Compiler
* [http://www.e-lab.de AVRCo Pascal Compiler]
* [http://amforth.sourceforge.net/ amforth]: interaktiver und erweiterbarer Kommandointerpreter für AVR unter GNU Lizenz (Open Source)
* [[SJC]]: Experimenteller Java-Compiler unter GPL mit AVR-Unterstützung
* [http://www.atnel.pl/mkAVRCalculator_build_57en.rar mkAvrCalculator]: User friendly fuse bits calculator and GUI for avrdude

== Boards & Starterkits ==

Siehe dazu auch die Artikel in der [[:Kategorie:AVR-Boards|Kategorie AVR-Boards]] und den Artikel zur [[AVR_In_System_Programmer|AVR Programmierung]].

* [[STK200]]
* [[STK500]]
* [[STK600]]
* [[AVR Dragon]]
* [[AVR Butterfly]]
* [[AVR Raven]]
* AVR-ISP / AVR-ISP mkII
* [http://www.ehajo.de/Bausaetze/AVR-ISP-Stick AVR-ISP-Stick]
* [http://www.ehajo.de/Bausaetze/µISP-Stick µISP-Stick]
* [http://www.ehajo.de/Bausaetze/USP-Stick USP-Stick]
* AVR JTAG-ICE
* [http://www.robotikhardware.de RN-Control]
* [http://www.conrad.de C-Control PRO]
* [http://www.myavr.de myAVR Board]
* [http://www.rowalt.de AVR Lehrbuch und -bausatz]
* [http://www.pollin.de Pollin] - preiswerte Starterkits sowie Lösungen für RFID-125kHz und EtherNet
* [http://www.lochraster.org/rumpus Rumpus von lochraster.org] ist ein günstiges und gut dokumentiertes Starterkit mit Atmega 168
* [http://www.das-labor.org/wiki/Laborboard Laborboard von das-labor.org] - Bauplan Lochrasterplatine mit Atmega32
* [http://nibo.nicai-systems.de Roboterbausatz NIBO 2] - autonomer Roboter mit einem ATmega128 und einem ATmega88 / [http://nibobee.nicai-systems.de Roboterbausatz NIBObee] - Roboter für Einsteiger mit ATmega16 und integriertem USB-Programmer
* [http://www.nerdkits.com Nerdkit - Starterkit inkl. Doku] - ideal für Anfänger
* [http://arduino.cc/ Arduino] - Ein modulares System mit verschiedenen Entwicklungsboards (insbesondere auch eins mit ATmega1280, dem mit den vielen dünnen Beinchen), das aufgrund der Nutzung einer JAVA-IDE und "Wiring" besonders einfach zu nutzen ist. Es gibt verschiedene Clones unter Namen wie Freeduino, Seeeduino etc., auch den Lilypad zum Einnähen in Kleidung und Verschaltung mittels leitender Fäden. Die neueren Versionen können über einen standardmäßig mit ausgelieferten Bootloader ohne sonstige Hardware direkt über USB bespielt werden.
* [http://www.aevum-mechatronik.de Modularis] - AVR Mikrocontroller-Boards (z.T. mit Zusatz-Speicher und USB) die über Flachbandkabel erweitert werden können. Es gibt bis jetzt Zubehör-Module mit Taster, Motor H-Brücke, XBee und Winkelsensor.
* [http://www.b-redemann.de AVR Mikrocontroller Lehrbuch (R. Walter, 3. Auflage 2009) und Bauteilesatz incl. Leiterplatte; www.b-redemann.de]
* [http://weigu.lu/b/mices2 mices2] - Entwicklungsboard zum [http://www.weigu.lu/a Gratis Assembler Kurs]. Integriertes Programmiergerät (USB, avrisp mk2 kompatibel). Spannungsvrsorgung über USB. Platine einseitig, leicht zu bestücken. Viele Schnittstellen (1-Wire, I2C, EIA232 ...), D/A-Wandler, Mikrofonschaltung., Audioverstärker ...
* [https://guloshop.de/shop/Mikrocontroller-Programmierung/::45.html gulostart] – [[Steckbrett|Steckplatinen]]-basiertes Lernpaket / Einsteiger-Set mit ausführlicher Anleitung. Verwendet ausschließlich [http://de.wikipedia.org/wiki/Open_source Open-Source-Software], kann fast alle DIP-ATtiny/ATmega programmieren. Für USB-Schnittstelle.
* [http://corpsman.de/index.php?doc=avrnetio/atmegaboard Atmegaboard] Eagle Daten für ein Testboard zur Nutzung 2er Atmegas gleichzeitig. Weitere Adapterplatinen sowie Source Code sind ebenfalls verfügbar.
* [http://matrixstorm.com/avr/tinyusbboard/ tinyUSBboard] - Ein sehr sehr preiswertes, Arduino und BASCOM kompatibles Board mit onboard USB Interface und [http://matrixstorm.com/avr/tinyusbboard/#firmwaresotherbootloader auswechelbarem Bootloader].
* [http://www.ehajo.de/Bausaetze/aTeVaL aTeVaL-Board] - Nachfolger des bekannten Pollin Evalboards. ISP-mkii-Klon & Seriell/USB-Wandler via USB. Testhardware auf der Platine: Taster, LED, Summer, Potis, ...
* [https://www.olimex.com/Products/AVR/ verschiedene Boards von Olimex]

== Projekte ==
Siehe dazu auch die Artikel in der [[:Kategorie:AVR-Projekte|Kategorie AVR-Projekte]].

* [[PWM_foxlight]] - LED Lampe mit PWM
* [[Digitaler Funktionsgenerator]]
* [[Midi Rekorder mit MMC/SD-Karte]]
* [[Schrittmotor-Controller (Stepper)]]
* [[Pulsuhrempfänger mit AVR Butterfly]]
* [[DCF77-Funkwecker mit AVR]]
* [[Fahrradcomputer]]
* [[Einfacher und billiger Webserver mit AtMega32]]
* [[AVR RFM12]]
* [[RF SOAP]] USB / AtMega88 / RFM12, optional LiPo Akku mit Lader
* [http://www.andreadrian.de/schach/#Selbstbau_Schachcomputer_SHAH Selbstbau Schachcomputer SHAH mit ATMega88V]
* [[Giess-o-mat]] - vollautomatische Blumengießanlage
* [http://www.zipfelmaus.com/led-flitzer/ POV-LED mit ATmega8, USB und Beschleunigungssensor]
* [http://g-heinrichs.de/attiny/ ATtiny-Mikrokontroller für Schulbedarf]
* [http://www.weigu.lu/b Kleine USB-Bibliothek (C, BASCOM und Assembler) für ATMEL-USB-AVRs]
* [http://volkszaehler.org/ Ein tolles Smartmeter mit kompletter Middleware!]

== Tutorials ==

* [[AVR-Tutorial]]
* [[AVR-GCC-Tutorial]]
* http://www.avr-asm-tutorial.net
* [http://www.weigu.lu/a weigu.lu/a]: Gratis Assembler Kurs (pdf). Mehrere hundert Seiten mit vielen neuen Grafiken. Besonders zum Selbststudium geeignet. Es existiert auch ein [http://www.weigu.lu/b/mices2 Entwicklungsboard] zum Kurs.

== Literatur ==

* C.Kühnel Programmieren der AVR RISC Mikrocontroller mit BASCOM-AVR ISBN 3898119378 (2000) ISBN 3907857046 (2.Aufl.2004) ISBN 978-3-907857-14-4 (3. überarbeitete und erweiterte Auflage 2010)
* R.Mittermayr AVR-RISC: Embedded Software selbst entwickeln Franzis 2008 ISBN 3772341071
* F.Schäffer AVR: Hardware und C-Programmierung in der Praxis Elektor 2008 ISBN 3895762008 [http://www.blafusel.de/books/avr.html Webseite des Autors, Codebeispiele und Leseprobe]
* G.Schmitt Mikrocomputertechnik mit Controllern der Atmel AVR-RISC-Familie...Oldenbourg 4.Aufl.2008 ISBN 3486587900 ISBN 3486580167 (2006) ISBN 3486577174 (2005) [http://www.oldenbourg-wissenschaftsverlag.de/olb/de/1.c.1495224.de Verlags-Webseite mit Buchauszügen]
* M.Schwabl-Schmidt Programmiertechniken für AVR-Mikrocontroller Elektor 2008 ISBN 3895761761 [http://www.schwabl-schmidt.de/index.php/buecher Webseite des Autors]
* M.Schwabl-Schmidt Systemprogrammierung für AVR-Mikrocontroller Elektor 2009 ISBN 3895762180
* W.Trampert Messen,Steuern und Regeln mit AVR Mikrocontrollern Franzis 2004 ISBN 3772342981
* W.Trampert AVR-RISC Mikrocontroller Franzis ISBN 3772354769 (2003) ISBN 3772354742 (2002) ISBN 3772354750 (2000)
* P.Urbanek Embedded Systems: Ein umfassendes Grundlagenwerk ... (2007) ISBN 3981123018 [http://www.ulb.tu-darmstadt.de/tocs/188146911.pdf Inhaltsverzeichnis]
* S./F.Volpe AVR-Mikrocontroller-Praxis Elektor 2001 ISBN 3895760633
* R.Walter AVR-Mikrocontroller-Lehrbuch 3. Auflage Denkholz 2009 ISBN 9783981189445 [http://www.rowalt.de/mc/avr/avrbuch/index.htm Webseite des Autors, Buch-Download in geringer Auflösung]

== Tipps & Hinweise ==

* [[AVR Typen]] - Die verschiedenen Typen (AT90S, ATmega, ATtiny)
* [[AVR Checkliste]] - Liste mit Hinweisen zur Lösung üblicher Probleme
* [http://blog.coldtobi.de/1_coldtobis_blog/archive/87_little_endianess_guide_for_atmel_avr.html (Little) Endianess Guide for Atmel AVR] Übersicht über die Endianess der AVR und AVR32
* [[AVR Fuses|Fuse-Bits]] - Das Setzen der Fuse-Bits ist ein berüchtigter Fallstrick bei den AVRs; vor dem Rumspielen damit unbedingt diese Hinweise lesen!
* [[AVR In System Programmer]] - Programmierhardware
* [[Pony-Prog Tutorial]] - Hinweise zur Programmiersoftware PonyProg
* [[AVRDUDE]] - Programmiersoftware für die Kommandozeile
* [[AVR-GCC-Codeoptimierung]] - Wie man mehr aus dem Controller herausholen kann, ohne ein Assembler-Guru sein zu muessen.
* [[AVR Softwarepool]] - Verschiedene Softwaremodule und Codeschnippsel aus der Codesammlung

== Weblinks ==

* [http://revision3.com/systm/avr101 AVR101] - systm Videocast von Revision3 Internet Television (engl.).

Weitere Verweise (Links) auf externe Informationen und Projekte finden sich in der '''[[Linksammlung#AVR|Linksammlung]]'''.

=== Anmerkungen ===

Es gibt nur wenige Typen mit D/A-Wandler (z.B. AT90PWM2); hierfür benutze man PWM oder externe Bausteine.

Die Takterzeugung ist bei AVRs recht einfach gehalten. So gibt es bei den meisten Modellen keine internen PLLs um „krumme“ Prozessor- oder Peripherietaktfrequenzen zu erzeugen, noch ist der Peripherie-Takt vom Prozessortakt abkoppelbar. Einige AVR verfügen über eine PLL, um damit z.B. einen Timer mit Frequenzen über der Systemfrequenz zu takten oder höhere Systemfrequenz aus niederfrequenteren Taktquellen zu erzeugen (vgl. u.a. Datenblatt ATtiny861). Die Baudrate serieller Schnittstellen lässt sich nicht gebrochen einstellen, so dass gegebenenfalls ein zur Baudrate passender Quarz oder Resonator zu verwenden ist.

Für die serielle Programmierung des Flash-Speichers sind 4 Datenleitungen erforderlich und die Taktversorgung muss sicher gestellt sein. Es ist darauf zu achten, dass bei Einstellung der Taktquelle (Fuses) auch die vorhandene Taktquelle ausgewählt wird. Für die Hochvolt-Programmierung (so genannt wegen 12 V am RESET-Anschluss) werden je nach Chip sehr viele Leitungen benötigt. Einige Modelle verfügen über eine Debugwire-Schnittstelle, für die im Betrieb zwei Leitungen ausreichen.

Nicht zu verwechseln ist die 8-bit-AVR-Serie mit AVR32. Letztere ist eine 32-bit-Architektur mit recht viel Ähnlichkeit zu Controllern auf Basis eines ARM-Cores. Controller der ATxmega-Serie verfügen über mehr Funktionen als die "traditionellen" AVR (z.B. DMA- und Eventsystem, 12Bit A-D-Wandler). ATxmega sind jedoch für 3,3V-Betrieb ausgelegt und ausschließlich in SMD-Bauform erhältlich.

[[Category:Mikrocontroller]]
[[Category:AVR| ]]
__NOTOC__

IRMP

2014-06-07T06:23:21Z

Maybee: Typo

Von '''Frank M. ([http://www.mikrocontroller.net/user/show/ukw ukw])'''

[[Datei:irmp-title.png| |Scan eines NEC-kompatiblen Fernbedienungssignals]]

Da RC5 nicht nur veraltet, sondern mittlerweile obsolet ist und immer mehr die elektronischen Geräte der fernöstlichen Unterhaltungsindustrie in unseren Haushalten Einzug finden, ist es an der Zeit, einen IR-Decoder zu entwickeln, der ca. 90% aller bei uns im täglichen Leben zu findenden IR-Fernbedienungen "versteht".

Im folgenden wird IRMP als "Infrarot-Multiprotokoll-Decoder" in allen Einzelheiten vorgestellt. Auch das Gegenstück, nämlich IRSND als IR-Encoder, wird in diesem Artikel behandelt.

= IRMP - Infrarot-Multiprotokoll-Decoder =

[[Datei:IRMP-TSOP1736.png|miniatur|Anschluß eines IR-Empfängers an µC]]

=== Unterstützte µCs ===

[[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] ist u.a. lauffähig auf folgenden AVR µCs:

* ATtiny87, ATtiny167
* ATtiny45, ATtiny85
* ATtiny44, ATtiny84
* ATmega8, ATmega16, ATmega32
* ATmega162
* ATmega164, ATmega324, ATmega644, ATmega644P, ATmega1284
* ATmega88, ATmega88P, ATmega168, ATmega168P, ATmega328P

Es gibt aber auch Portierungen auf diverse PIC µCs - für den CCS- und C18-Compiler. Auch ist [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] mittlerweile auf ARM STM32 und Stellaris LM4F120 Launchpad von TI (ARM Cortex M4) lauffähig.

=== Unterstützte IR-Protokolle ===

[[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] - der Infrarot-Fernbedienungsdecoder, der mehrere Protokolle auf einmal decodieren kann, beherrscht folgende Protokolle (in alphabetischer Reihenfolge):

{| class="wikitable"
! Protokoll || Hersteller
|-
| [[IRMP#A1TVBOX|A1TVBOX]] || ADB (Advanced Digital Broadcast), z.B. A1 TV Box
|-
| [[IRMP#APPLE|APPLE]] || Apple
|-
| [[IRMP#B&O|B&O]] || Bang & Olufsen
|-
| [[IRMP#BOSE|BOSE]] || Bose
|-
| [[IRMP#DENON|DENON]] || Denon, Sharp
|-
| [[IRMP#FDC|FDC]] || FDC Keyboard
|-
| [[IRMP#GRUNDIG_+_NOKIA|GRUNDIG]] || Grundig
|-
| [[IRMP#GRUNDIG_+_NOKIA|NOKIA]] || Nokia, z.B. D-Box
|-
| [[IRMP#IR60 (SDA2008)|IR60 (SDA2008)]] || Diverse europäische Hersteller
|-
| [[IRMP#JVC|JVC]] || JVC
|-
| [[IRMP#KASEIKYO|KASEIKYO]] || Panasonic, Technics, Denon und andere japanische Hersteller, welche Mitglied der "Japan's Association for Electric Home Application" sind.
|-
| [[IRMP#KATHREIN|KATHREIN]] || KATHREIN
|-
| [[IRMP#LEGO|LEGO]] || Lego
|-
| [[IRMP#LGAIR|LGAIR]] || LG Air Conditioner '''(NEU, nur im SVN)'''
|-
| [[IRMP#MATSUSHITA|MATSUSHITA]] || Matsushita
|-
| [[IRMP#NEC16|NEC16]] || JVC, Daewoo
|-
| [[IRMP#NEC42|NEC42]] || JVC
|-
| [[IRMP#NEC_+_extended_NEC|NEC]] || NEC, Yamaha, Canon, Tevion, Harman/Kardon, Hitachi, JVC, Pioneer, Toshiba, Xoro, Orion, NoName und viele weitere japanische Hersteller.
|-
| [[IRMP#NETBOX|NETBOX]] || Netbox
|-
| [[IRMP#NIKON|NIKON]] || NIKON
|-
| [[IRMP#NUBERT|NUBERT]] || Nubert, z.B. Subwoofer System
|-
| [[IRMP#ORTEK|ORTEK]] || Ortek, Hama (z. Zt. nur im SVN!)
|-
| [[IRMP#RC5_+_RC5X|RC5]] || Philips und andere europäische Hersteller
|-
| [[IRMP#RC6_+_RC6A|RC6A]] || Philips, Kathrein und andere Hersteller, z.B. XBOX
|-
| [[IRMP#RC6_+_RC6A|RC6]] || Philips und andere europäische Hersteller
|-
| [[IRMP#RCCAR|RCCAR]] || RC Car: IR Fernbedienung für Modellfahrzeuge
|-
| [[IRMP#RECS80|RECS80]] || Philips, Nokia, Thomson, Nordmende, Telefunken, Saba
|-
| [[IRMP#RECS80EXT|RECS80EXT]] || Philips, Technisat, Thomson, Nordmende, Telefunken, Saba
|-
| [[IRMP#RCMM|RCMM]] || Fujitsu-Siemens z.B. Activy keyboard '''(NEU!)'''
|-
| [[IRMP#ROOMBA|ROOMBA]] || iRobot Roomba Staubsauger
|-
| [[IRMP#SAMSUNG32|SAMSUNG32]] || Samsung
|-
| [[IRMP#SAMSUNG|SAMSUNG]] || Samsung
|-
| [[IRMP#SIEMENS_+_RUWIDO|RUWIDO]] || RUWIDO (z.B. T-Home-Mediareceiver, MERLIN-Tastatur (Pollin))
|-
| [[IRMP#SIEMENS_+_RUWIDO|SIEMENS]] || Siemens, z.B. Gigaset M740AV
|-
| [[IRMP#SIRCS|SIRCS]] || Sony
|-
| [[IRMP#SPEAKER|SPEAKER]] || Lautsprecher Systeme wie z.B. X-Tensions '''(NEU, nur im SVN!)'''
|-
| [[IRMP#TELEFUNKEN|TELEFUNKEN]] || Telefunken
|-
| [[IRMP#THOMSON|THOMSON]] || Thomson
|}

Jedes dieser Protokolle ist einzeln aktivierbar. Wer möchte, kann alle Protokolle aktivieren. Wer nur ein Protokoll braucht, kann alle anderen deaktivieren. Es wird nur das vom Compiler übersetzt, was auch benötigt wird.

=== Entstehung ===

Der auf AVR- und PIC-µCs einsetzbare Source zu [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] entstand im Rahmen des [[Word Clock]] Projektes.

=== Thread im Forum ===

'''Anlass für einen eigenen [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]]-Artikel ist folgender Thread in der Codesammlung: [http://www.mikrocontroller.net/topic/162119 Beitrag: IRMP - Infrared Multi Protocol Decoder]'''

== IR-Protokolle ==

[[Datei:nec-protocol.png|miniatur|NEC-Protokoll, Reichelt RGB-LED-Fernbedienung, T->A: 9,14ms, A->B: 4,42ms, B->C: 660us]]

Einige Hersteller verwenden ihr eigenes hausinterne Protokoll, dazu gehören u.a. Sony, Samsung und Matsushita. Philips hat [[IRMP#RC5 + RC5X|RC5]] entwickelt und natürlich auch selbst benutzt. [[IRMP#RC5 + RC5X|RC5]] galt damals in Europa als ''das'' Standard-IR-Protokoll, welches von vielen europäischen Herstellern übernommen wurde. Mittlerweile ist [[IRMP#RC5 + RC5X|RC5]] fast gar nicht mehr anzutreffen - man kann es eigentlich als "ausgestorben" abhaken. Der Nachfolger RC6 wird zwar noch in einigen aktuellen europäischen Geräten eingesetzt, ist aber auch nur vereinzelt vorzufinden.

Auch die japanischen Hersteller haben versucht, einen eigenen Standard zu etablieren, nämlich das sog. [[IRMP#KASEIKYO|Kaseikyo]]- (oder auch "Japan-") Protokoll. Dieses ist mit einer Bitlänge von 48 sehr universell und allgemein verwendbar. Richtig durchgesetzt hat es sich aber bis heute nicht - auch wenn man es hier und da im heimischen Haushalt vorfindet.

Heutzutage wird (auch vornehmlich bei japanischen Geräten) das [[IRMP#NEC_+_extended_NEC|NEC]]-Protokoll verwendet - und zwar von den unterschiedlichsten (Marken- und auch Noname-)Herstellern. Ich schätze den "Marktanteil" auf ca. 80% beim [[IRMP#NEC_+_extended_NEC|NEC]]-Protokoll. Fast alle Fernbedienungen im alltäglichen Einsatz verwenden bei mir den [[IRMP#NEC_+_extended_NEC|NEC]]-IR-Code. Das fängt beim Fernseher an, geht über vom DVD-Player zur Notebook-Fernbedienung und reicht bis zur Noname-MultiMedia-Festplatte - um nur einige Beispiele zu nennen.

== Kodierungen ==

[[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] unterstützt folgende IR-Codings:

* [[IRMP#Pulse Distance|Pulse Distance]], typ. Beispiel: [[IRMP#NEC_+_extended_NEC|NEC]]
* [[IRMP#Pulse Width|Pulse Width]], typ. Beispiel: [[IRMP#SIRCS|Sony SIRCS]]
* [[IRMP#Biphase|Biphase (Manchester)]], typ. Beispiel: Philips [[IRMP#RC5_+_RC5X|RC5]], [[IRMP#RC6_+_RC6A|RC6]]
* [[IRMP#Pulse Position|Pulse Position (NRZ)]], typ. Beispiel: [[IRMP#NETBOX|Netbox]]
* [[IRMP#Pulse Distance Width|Pulse Distance Width]], typ. Beispiel: [[IRMP#NUBERT|Nubert]]

Die Pulse werden dabei moduliert - üblicherweise mit 36kHz oder 38kHz - um Umwelteinflüsse wie Raum- oder Sonnenlicht ausfiltern zu können.

=== Pulse Distance ===

[[Datei:Pulse-Distance.png|miniatur|Pulse Distance Coding]]

Eine Pulse Distance Kodierung erkennt man an der folgenden Regel:

* es gibt nur '''eine Pulslänge''' und '''zwei verschiedene Pausenlängen.'''

=== Pulse Width ===

[[Datei:Pulse-Width.png|miniatur|Pulse Width Coding]]

Bei der Pulse Width Kodierung gilt die Regel:

* es gibt '''zwei verschiedene Pulslängen''' und nur '''eine Pausenlänge'''

=== Pulse Distance Width ===

[[Datei:Pulse-Distance-Width.png|miniatur|Pulse Distance Width Coding]]

Dies ist ein Mischmasch aus Pulse Distance und Pulse Width Coding.

Also:

* es gibt '''zwei verschiedene Pulslängen''' und '''zwei verschiedene Pausenlängen.'''

=== Biphase ===

[[Datei:Biphase-Coding.png|miniatur|Biphase Coding]]

Bei der Biphase Kodierung entscheidet die Reihenfolge von Puls und Pause über den Wert des Bits.

Damit erkennt man ein Biphase-Coding an folgendem Kriterium:

* es kommen genau '''eine''' Pausen- und eine Pulslänge, sowie jeweils die '''doppelten''' Puls-/Pausenlängen vor

Normalerweise sind die Längen für die Pulse und Pausen gleich, d.h. die Signalform ist symmetrisch. IRMP erkennt aber auch Protokolle, die mit unterschiedlichen Puls-/Pause-Längen arbeiten. Dies ist zum Beispiel bei dem [[IRMP#A1TVBOX|A1TVBOX]]-Protokoll der Fall.

=== Pulse Position ===

[[Datei:Pulse-Position.png|miniatur|Pulse Position Coding]]

Die Pulse Position Kodierung kennt man von den üblichen UARTs. Hier hat jedes Bit eine feste Länge. Je nach Wert (0 oder 1) ist es ein Puls oder eine Pause.

Typisches Kriterium für ein '''Pulse Position Protokoll''' ist:

* es kommen '''Vielfache''' einer Grund-Puls-/Pausenlänge vor

'''Eine tabellarische Aufstellung der verschiedenen IR-Protokolle findet man hier: [[IRMP#Die_IR-Protokolle_im_Detail|Die IR-Protokolle im Detail]].'''

Die dort angegebenen Timingwerte sind Idealwerte. Bei einigen Fernbedienungen in der Praxis weichen sie um bis zu 40% voneinander ab. Deshalb arbeitet [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] mit Minimum-/Maximumsgrenzen, um bzgl. des Zeitverhaltens tolerabel zu sein.

== Protokoll-Erkennung ==

Die von [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] decodierten Protokolle haben etwas gemeinsames: Sie weisen alle ein Start-Bit auf, welches vom Timing her ausgezeichnet, d.h. einmalig ist.

Anhand dieses Start-Bit-Timings werden die verschiedenen Protokolle unterschieden. [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] misst also das Timing des Start-Bits und stellt dann "on-thy-fly" seine Timingtabellen auf das erkannte Protokoll um, damit die nach dem Start-Bit gesandten Daten in einem Rutsch eingelesen werden können, ohne das komplette Telegramm (Frame) erst speichern zu müssen. [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] wartet also nicht darauf, dass ein kompletter Frame eingelesen wurde, sondern legt direkt nach der ersten Pulserkennung los.

Ist das gelesene Start-Bit nicht eindeutig, fährt [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] "mehrspurig", d.h. es werden zum Beispiel zwei mögliche Protokolle gleichzeitig verfolgt. Sobald aus Plausibilitätsgründen eines der beiden Protokolle nicht mehr möglich sein kann, wird komplett auf das andere Protokoll gewechselt.

Realisiert wird die Erkennung über eine [[Statemachine]], die [[AVR-GCC-Tutorial/Die_Timer_und_Zähler_des_AVR|timergesteuert]] über eine [[Interrupt|Interruptroutine]] in regelmäßigen Abständen (üblicherweise 15.000 mal in der Sekunde) aufgerufen wird. Die [[Statemachine]] kennt (unter anderem) folgende Zustände:

* Erkenne den ersten Puls des Start-Bits
* Erkenne die Pause des Start-Bits
* Erkenne den Puls des ersten Datenbits

Danach sind die Puls/Pause-Längen des Startbits bekannt. Nun werden alle vom Anwender aktivierten Protokolle nach diesen Längen durchsucht. Wurde ein Protokoll gefunden, werden die Timing-Tabellen dieses Protokolls geladen und im weiteren geprüft, ob die nachfolgenden Puls-/Pause-Zeiten innerhalb der geladenen Werte übereinstimmen.

Es geht also weiter in der [[Statemachine]] mit folgenden Zuständen

* Erkenne die Pausen der Datenbits
* Erkenne die Pulse der Datenbits
* Prüfe Timing. Wenn abweichend, schalte um auf ein anderes noch in Frage kommendes IR-Protokoll, ansonsten schalte [[Statemachine]] komplett zurück
* Erkenne das Stop-Bit, falls das Protokoll eines vorsieht
* Prüfe Daten auf Plausibilität, wie CRC oder andere redundante Datenbits
* Wandle die Daten in Geräte-Adresse und Kommando
* Erkenne Wiederholungen durch längere Tastendrücke, setze entsprechendes Flag

Tatsächlich ist die [[Statemachine]] noch etwas komplizierter, da manche Protokolle gar kein Start-Bit (z.B. [[IRMP#DENON|Denon]]) bzw. mehrere Start-Bits (z.B. 4 bei [[IRMP#B.26O|B&O]]) haben bzw. mitten im Frame ein weiteres Synchronisierungs-Bit (z.B. [[IRMP#SAMSUNG|Samsung]]) vorsehen. Diese besonderen Bedingungen werden durch protokollspezifische "Spezialbehandlungen" im Code abgefangen.

Das Umschalten auf ein anderes Protokoll kann mehrfach während des Empfangs des Frames geschehen, z.B. von [[IRMP#NEC42|NEC42]] (42 Bit) auf [[IRMP#NEC16|NEC16]] (8 Bit + Sync-Bit + 8 Bit), wenn vorzeitig ein zusätzliches Synchronisierungsbit erkannt wurde, oder von [[IRMP#NEC + extended NEC|NEC]]/[[IRMP#NEC42|NEC42]] (32/42 Bit) auf [[IRMP#JVC|JVC]] (16 Bit), wenn das Stop-Bit vorzeitig auftrat. Schwierig wird es dann, wenn zwei mögliche Protokolle nach Erkennung des Start-Bits unterschiedliche Kodierungen verwenden, z.B. wenn das eine Protokoll ein [[IRMP#Pulse Distance|Pulse Distance Coding]] und das andere ein [[IRMP#Biphase|Biphase Coding (Manchester)]] benutzt. Hier speichert [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] die jeweils völlig verschieden ermittelten Bits für beide Codierungen, um dann später die einen oder anderen
Werte wieder zu verwerfen.

Desweiteren senden einige Fernbedienungen bei bestimmten Protokollen aus Gründen der Redundanz (Fehlererkennung) oder wegen längeren Tastendrucks Wiederholungsframes. Diese werden von IRMP unterschieden: Die für die Fehlererkennung zuständigen Frames werden von IRMP geprüft, aber nicht an die Anwendung zurückgegeben, die anderen werden als langer Tastendruck erkannt und entsprechend von IRMP gekennzeichnet.

== Download ==

Version 2.4.0, Stand vom 20.02.2014

Download Release-Version: [http://www.mikrocontroller.net/wikifiles/7/79/Irmp.zip Irmp.zip]

[[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] & [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] sind nun auch über SVN abrufbar: [http://www.mikrocontroller.net/svnbrowser/irmp/ IRMP im SVN], Download [http://www.mikrocontroller.net/svnbrowser/irmp/?view=tar Tarball]

'''Achtung:'''

Die Version im SVN kann eine Zwischen- oder Test-Version sein, die nicht den hier dokumentierten Stand widerspiegelt! Im Zweifel verwendet man besser den obigen Download-Link auf Irmp.zip.

'''Die Software-Änderungen kann man sich hier anschauen: [http://www.mikrocontroller.net/articles/IRMP#Software-Historie_IRMP Software-Historie IRMP]'''

== Source-Code ==

Der Source-Code lässt sich einfach für AVR-µCs übersetzen, indem man unter Windows die Projekt-Datei irmp.aps in das AVR Studio 4 lädt.

Für andere Entwicklungsumgebungen ist leicht ein Projekt bzw. Makefile angelegt. Zum Source gehören:

* [http://www.mikrocontroller.net/svnbrowser/irmp/irmp.c?view=markup irmp.c] - Der eigentliche IR-Decoder
* [http://www.mikrocontroller.net/svnbrowser/irmp/irmpprotocols.h?view=markup irmpprotocols.h] - Sämtliche Definitionen zu den IR-Protokollen
* [http://www.mikrocontroller.net/svnbrowser/irmp/irmpsystem.h?view=markup irmpsystem.h] - Vom Zielsystem abhängige Definitionen für AVR/PIC/STM32
* [http://www.mikrocontroller.net/svnbrowser/irmp/irmp.h?view=markup irmp.h] - Include-Datei für die Applikation
* [http://www.mikrocontroller.net/svnbrowser/irmp/irmpconfig.h?view=markup irmpconfig.h] - Anzupassende Konfigurationsdatei

* [http://www.mikrocontroller.net/svnbrowser/irmp/main.c?view=markup main.c] - Beispiel Anwendung

{{Warnung|
;WICHTIG: Im Applikations-Source sollte nur irmp.h per include eingefügt werden, also lediglich:
<syntaxhighlight lang="c">
#include "irmp.h"
</syntaxhighlight>

Alle anderen Include-Dateien werden automatisch über irmp.h "eingefügt". Siehe dazu auch die Beispieldatei main.c.

Desweiteren muss die Preprocessor-Konstante '''F_CPU im Projekt bzw. Makefile''' gesetzt werden. Diese sollte mindestens den Wert 8000000UL haben, der Prozessor sollte also zumindest mit 8 MHz laufen.
}}

Auch auf PIC-Prozessoren ist [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] lauffähig. Für den PIC-CCS-Compiler sind entsprechende Preprocessor-Konstanten bereits gesetzt, so dass man [http://www.mikrocontroller.net/svnbrowser/irmp/irmp.c?view=markup irmp.c] direkt in der CCS-Entwicklungsumgebung verwenden kann. Lediglich eine kleine Interrupt-Routine wie

<syntaxhighlight lang="c">
void TIMER2_isr(void)
{
irmp_ISR ();
}
</syntaxhighlight>

ist hinzuzufügen, wobei man den Interrupt auf 66µs (also 15kHz) stellt.

Für AVR-Prozessoren ist ein Beispiel für die Anwendung von [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] in [http://www.mikrocontroller.net/svnbrowser/irmp/main.c?view=markup main.c] zu finden - im wesentlichen geht es da um die [[AVR-GCC-Tutorial/Die_Timer_und_Zähler_des_AVR|Timer]]-Initialisierung und den Abruf der empfangenen IR-Telegramme.

Für das Stellaris LM4F120 Launchpad von TI (ARM Cortex M4) ist eine entsprechende Timer-Initialisierungsfunktion in [http://www.mikrocontroller.net/svnbrowser/irmp/main.c?view=markup main.c] bereits integriert.

Ebenso kann [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] auf STM32-Mikroprozessoren eingesetzt werden.

=== Konfiguration ===

Die Konfiguration von [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] wird über Parameter in [http://www.mikrocontroller.net/svnbrowser/irmp/irmpconfig.h?view=markup irmpconfig.h] vorgenommen, nämlich:

* [[IRMP#F_INTERRUPTS|Anzahl Interrupts pro Sekunde]]
* [[IRMP#IRMP_SUPPORT_xxx_PROTOCOL|Unterstützte IR-Protokolle]]
* [[IRMP#IRMP_PORT_LETTER + IRMP_BIT_NUMBER|Hardware-Pin zum IR-Empfänger]]
* [[IRMP#IRMP_LOGGING|IR-Logging]]

=== Einstellungen in irmpconfig.h ===

[[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] decodiert sämtliche oben aufgelisteten Protokolle in einer ISR. Dafür sind einige Angaben nötig. Diese werden in [http://www.mikrocontroller.net/svnbrowser/irmp/irmpconfig.h?view=markup irmpconfig.h] eingestellt.

==== F_INTERRUPTS ====

Anzahl der Interrupts pro Sekunde. Der Wert kann zwischen 10000 und 20000 eingestellt werden. Je höher der Wert, desto besser die Auflösung und damit die Erkennung. Allerdings erkauft man sich diesen Vorteil mit erhöhter CPU-Last. Der Wert 15000 ist meist ein guter Kompromiss.

Standardwert:
<syntaxhighlight lang="c">
#define F_INTERRUPTS 15000 // interrupts per second
</syntaxhighlight>

==== IRMP_SUPPORT_xxx_PROTOCOL ====

Hier lässt sich einstellen, welche Protokolle von [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] unterstützt werden sollen. Die Standardprotokolle sind bereits aktiv. Möchte man weitere Protokolle einschalten bzw. einige aus Speicherplatzgründen deaktivieren, sind die entsprechenden Werte in [http://www.mikrocontroller.net/svnbrowser/irmp/irmpconfig.h?view=markup irmpconfig.h] anzupassen.

<syntaxhighlight lang="c">
// typical protocols, disable here! Enable Remarks F_INTERRUPTS Program Space
#define IRMP_SUPPORT_SIRCS_PROTOCOL 1 // Sony SIRCS >= 10000 ~150 bytes
#define IRMP_SUPPORT_NEC_PROTOCOL 1 // NEC + APPLE >= 10000 ~300 bytes
#define IRMP_SUPPORT_SAMSUNG_PROTOCOL 1 // Samsung + Samsung32 >= 10000 ~300 bytes
#define IRMP_SUPPORT_MATSUSHITA_PROTOCOL 1 // Matsushita >= 10000 ~50 bytes
#define IRMP_SUPPORT_KASEIKYO_PROTOCOL 1 // Kaseikyo >= 10000 ~250 bytes

// more protocols, enable here! Enable Remarks F_INTERRUPTS Program Space
#define IRMP_SUPPORT_DENON_PROTOCOL 0 // DENON, Sharp >= 10000 ~250 bytes
#define IRMP_SUPPORT_RC5_PROTOCOL 0 // RC5 >= 10000 ~250 bytes
#define IRMP_SUPPORT_RC6_PROTOCOL 0 // RC6 & RC6A >= 10000 ~250 bytes
#define IRMP_SUPPORT_JVC_PROTOCOL 0 // JVC >= 10000 ~150 bytes
#define IRMP_SUPPORT_NEC16_PROTOCOL 0 // NEC16 >= 10000 ~100 bytes
#define IRMP_SUPPORT_NEC42_PROTOCOL 0 // NEC42 >= 10000 ~300 bytes
#define IRMP_SUPPORT_IR60_PROTOCOL 0 // IR60 (SDA2008) >= 10000 ~300 bytes
#define IRMP_SUPPORT_GRUNDIG_PROTOCOL 0 // Grundig >= 10000 ~300 bytes
#define IRMP_SUPPORT_SIEMENS_PROTOCOL 0 // Siemens Gigaset >= 15000 ~550 bytes
#define IRMP_SUPPORT_NOKIA_PROTOCOL 0 // Nokia >= 10000 ~300 bytes

// exotic protocols, enable here! Enable Remarks F_INTERRUPTS Program Space
#define IRMP_SUPPORT_BOSE_PROTOCOL 0 // BOSE >= 10000 ~150 bytes
#define IRMP_SUPPORT_KATHREIN_PROTOCOL 0 // Kathrein >= 10000 ~200 bytes
#define IRMP_SUPPORT_NUBERT_PROTOCOL 0 // NUBERT >= 10000 ~50 bytes
#define IRMP_SUPPORT_BANG_OLUFSEN_PROTOCOL 0 // Bang & Olufsen >= 10000 ~200 bytes
#define IRMP_SUPPORT_RECS80_PROTOCOL 0 // RECS80 (SAA3004) >= 15000 ~50 bytes
#define IRMP_SUPPORT_RECS80EXT_PROTOCOL 0 // RECS80EXT (SAA3008) >= 15000 ~50 bytes
#define IRMP_SUPPORT_THOMSON_PROTOCOL 0 // Thomson >= 10000 ~250 bytes
#define IRMP_SUPPORT_NIKON_PROTOCOL 0 // NIKON camera >= 10000 ~250 bytes
#define IRMP_SUPPORT_NETBOX_PROTOCOL 0 // Netbox keyboard >= 10000 ~400 bytes (PROTOTYPE!)
#define IRMP_SUPPORT_ORTEK_PROTOCOL 0 // ORTEK (Hama) >= 10000 ~150 bytes
#define IRMP_SUPPORT_TELEFUNKEN_PROTOCOL 0 // Telefunken 1560 >= 10000 ~150 bytes
#define IRMP_SUPPORT_FDC_PROTOCOL 0 // FDC3402 keyboard >= 10000 (better 15000) ~150 bytes (~400 in combination with RC5)
#define IRMP_SUPPORT_RCCAR_PROTOCOL 0 // RC Car >= 10000 (better 15000) ~150 bytes (~500 in combination with RC5)
#define IRMP_SUPPORT_ROOMBA_PROTOCOL 0 // iRobot Roomba >= 10000 ~150 bytes
#define IRMP_SUPPORT_RUWIDO_PROTOCOL 0 // RUWIDO, T-Home >= 15000 ~550 bytes
#define IRMP_SUPPORT_A1TVBOX_PROTOCOL 0 // A1 TV BOX >= 15000 (better 20000) ~300 bytes
#define IRMP_SUPPORT_LEGO_PROTOCOL 0 // LEGO Power RC >= 20000 ~150 bytes
#define IRMP_SUPPORT_RCMM_PROTOCOL 0 // RCMM 12,24, or 32 >= 20000 ~150 bytes
</syntaxhighlight>

Jedes von [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] unterstützte IR-Protokoll "verbrät" ungefähr den oben angegebenen Speicher an Code. Hier kann man Optimierungen vornehmen: Zum Beispiel ist die Modulationsfrequenz von 455kHz beim [[IRMP#B&O|B&O]]-Protokoll weitab von den Frequenzen, die von den anderen Protokollen verwendet werden. Hier braucht man evtl. andere IR-Empfänger, anderenfalls kann man diese Protokolle einfach deaktiveren. Zum Beispiel kann man mit einem TSOP1738 kein [[IRMP#B&O|B&O]]-Protokoll (455kHz) mehr empfangen.

Ausserdem werden die Protokolle [[IRMP#SIEMENS_+_RUWIDO|SIEMENS]]/[[IRMP#FDC|FDC]]/[[IRMP#RCCAR|RCCAR]] erst ab einer Scan-Frequenz von ca. 15kHz zuverlässig erkannt. Bei [[IRMP#LEGO|LEGO]] sind es sogar 20kHz. Wenn man also diese Protokolle nutzen will, muss man [[IRMP#F_INTERRUPTS|F_INTERRUPTS]] entsprechend anpassen, sonst erscheint beim Übersetzen eine entsprechende Warnung und die entsprechenden Protokolle werden dann automatisch abgeschaltet.

==== IRMP_PORT_LETTER + IRMP_BIT_NUMBER ====

Über diese Konstanten wird der Pin am µC beschrieben, an welchem der IR-Empfänger angeschlossen ist.

Standardwert ist PORT B6:
<syntaxhighlight lang="c">
/*---------------------------------------------------------------------------
* Change hardware pin here for ATMEL AVR
*---------------------------------------------------------------------------
*/
#if defined (ATMEL_AVR) // use PB6 as IR input on AVR
# define IRMP_PORT_LETTER B
# define IRMP_BIT_NUMBER 6
</syntaxhighlight>

Diese beiden Werte sind an den tatsächlichen Hardware-Pin des µCs anzupassen.

Dies gilt ebenso für die STM32-µCs:

<syntaxhighlight lang="c">
/*----------------------------------------------------------------------------
* Change hardware pin here for ARM STM32
*----------------------------------------------------------------------------
*/
#elif defined (ARM_STM32) // use C13 as IR input on STM32
# define IRMP_PORT_LETTER C
# define IRMP_BIT_NUMBER 13
</syntaxhighlight>

Bei den PIC-Prozessoren gibt es lediglich die anzupassende Konstante '''IRMP_PIN''' - je nach Compiler:

<syntaxhighlight lang="c">
/*----------------------------------------------------------------------------
* Change hardware pin here for PIC C18 compiler
*----------------------------------------------------------------------------
*/
#elif defined (PIC_C18) // use RB4 as IR input on PIC
# define IRMP_PIN PORTBbits.RB4

/*----------------------------------------------------------------------------
* Change hardware pin here for PIC CCS compiler
*----------------------------------------------------------------------------
*/
#elif defined (PIC_CCS) // use PB4 as IR input on PIC
# define IRMP_PIN PIN_B4
</syntaxhighlight>

==== IRMP_USE_CALLBACK ====

Standardwert:
<syntaxhighlight lang="c">
#define IRMP_USE_CALLBACK 0 // flag: 0 = don't use callbacks, 1 = use callbacks, default is 0
</syntaxhighlight>

Wenn man Callbacks einschaltet, wird bei jeder Pegeländerung des Eingangs eine Callback-Funktion aufgerufen. Dies kann zum Beispiel dafür verwendet werden, das eingehende IR-Signal sichtbar zu machen, also als Signal an einem weiteren Pin auszugeben.

Hier ein Beispiel:

<syntaxhighlight lang="c">
#define LED_PORT PORTD // LED at PD6
#define LED_DDR DDRD
#define LED_PIN 6

/*-----------------------------------------------------------------------------------------------------------------------
* Called (back) from IRMP module
* This example switches a LED (which is connected to Vcc)
*-----------------------------------------------------------------------------------------------------------------------
*/
void
led_callback (uint8_t on)
{
if (on)
{
LED_PORT &= ~(1 << LED_PIN);
}
else
{
LED_PORT |= (1 << LED_PIN);
}
}

int
main ()
{
...
irmp_init ();

LED_DDR |= (1 << LED_PIN); // LED pin to output
LED_PORT |= (1 << LED_PIN); // switch LED off (active low)
irmp_set_callback_ptr (led_callback);

sei ();
...
}
</syntaxhighlight>

==== IRMP_LOGGING ====

Mit IRMP_LOGGING kann das Protokollieren von eingehenden IR-Frames eingeschaltet werden.

Standardwert:
<syntaxhighlight lang="c">
#define IRMP_LOGGING 0 // 1: log IR signal (scan), 0: do not. default is 0
</syntaxhighlight>

Weitere Erläuterungen siehe [[IRMP#Scannen_von_unbekannten_IR-Protokollen|Scannen von unbekannten IR-Protokollen]].

=== Anwendung von IRMP ===

Die von [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] unterstützten Protokolle weisen Bitlängen - teilweise variabel, teilweise fest - von 2 bis 48 Bit auf. Diese werden über Preprocessor-Defines beschrieben.

[[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] trennt diese IR-Telegramme prinzipiell in 3 Bereiche:

1. ID für verwendetes Protokoll
2. Adresse bzw. Herstellercode
3. Kommando

Mittels der Funktion

irmp_get_data (IRMP_DATA * irmp_data_p)

kann man ein decodiertes Telegramm abrufen. Der Return-Wert ist 1, wenn ein Telegramm eingelesen wurde, sonst 0. Im ersten Fall werden die Struct-Members

<syntaxhighlight lang="c">
irmp_data_p->protocol (8 Bit)
irmp_data_p->address (16 Bit)
irmp_data_p->command (16 Bit)
irmp_data_p->flags (8 Bit)
</syntaxhighlight>

gefüllt.

Das heisst: am Ende bekommt man dann über irmp_get_data() einfach drei
Werte (Protokoll, Adresse und Kommando-Code), die man über ein if oder switch checken kann, z. B. hier eine Routine, welche die Tasten 1-9 auf einer Fernbedienung auswertet:

<syntaxhighlight lang="c">
IRMP_DATA irmp_data;

if (irmp_get_data (&irmp_data))
{
if (irmp_data.protocol == IRMP_NEC_PROTOCOL && // NEC-Protokoll
irmp_data.address == 0x1234) // Adresse 0x1234
{
switch (irmp_data.command)
{
case 0x0001: key1_pressed(); break; // Taste 1
case 0x0002: key2_pressed(); break; // Taste 2
...
case 0x0009: key9_pressed(); break; // Taste 9
}
}
}
</syntaxhighlight>

Hier die möglichen Werte für irmp_data.protocol, siehe auch [http://www.mikrocontroller.net/svnbrowser/irmp/irmpprotocols.h?view=markup irmpprotocols.h]:

<syntaxhighlight lang="c">
#define IRMP_SIRCS_PROTOCOL 1 // Sony
#define IRMP_NEC_PROTOCOL 2 // NEC, Pioneer, JVC, Toshiba, NoName etc.
#define IRMP_SAMSUNG_PROTOCOL 3 // Samsung
#define IRMP_MATSUSHITA_PROTOCOL 4 // Matsushita
#define IRMP_KASEIKYO_PROTOCOL 5 // Kaseikyo (Panasonic etc)
#define IRMP_RECS80_PROTOCOL 6 // Philips, Thomson, Nordmende, Telefunken, Saba
#define IRMP_RC5_PROTOCOL 7 // Philips etc
#define IRMP_DENON_PROTOCOL 8 // Denon, Sharp
#define IRMP_RC6_PROTOCOL 9 // Philips etc
#define IRMP_SAMSUNG32_PROTOCOL 10 // Samsung32: no sync pulse at bit 16, length 32 instead of 37
#define IRMP_APPLE_PROTOCOL 11 // Apple, very similar to NEC
#define IRMP_RECS80EXT_PROTOCOL 12 // Philips, Technisat, Thomson, Nordmende, Telefunken, Saba
#define IRMP_NUBERT_PROTOCOL 13 // Nubert
#define IRMP_BANG_OLUFSEN_PROTOCOL 14 // Bang & Olufsen
#define IRMP_GRUNDIG_PROTOCOL 15 // Grundig
#define IRMP_NOKIA_PROTOCOL 16 // Nokia
#define IRMP_SIEMENS_PROTOCOL 17 // Siemens, e.g. Gigaset
#define IRMP_FDC_PROTOCOL 18 // FDC keyboard
#define IRMP_RCCAR_PROTOCOL 19 // RC Car
#define IRMP_JVC_PROTOCOL 20 // JVC (NEC with 16 bits)
#define IRMP_RC6A_PROTOCOL 21 // RC6A, e.g. Kathrein, XBOX
#define IRMP_NIKON_PROTOCOL 22 // Nikon
#define IRMP_RUWIDO_PROTOCOL 23 // Ruwido, e.g. T-Home Mediareceiver
#define IRMP_IR60_PROTOCOL 24 // IR60 (SDA2008)
#define IRMP_KATHREIN_PROTOCOL 25 // Kathrein
#define IRMP_NETBOX_PROTOCOL 26 // Netbox keyboard (bitserial)
#define IRMP_NEC16_PROTOCOL 27 // NEC with 16 bits (incl. sync)
#define IRMP_NEC42_PROTOCOL 28 // NEC with 42 bits
#define IRMP_LEGO_PROTOCOL 29 // LEGO Power Functions RC
#define IRMP_THOMSON_PROTOCOL 30 // Thomson
#define IRMP_BOSE_PROTOCOL 31 // BOSE
#define IRMP_A1TVBOX_PROTOCOL 32 // A1 TV Box
#define IRMP_ORTEK_PROTOCOL 33 // ORTEK - Hama
#define IRMP_TELEFUNKEN_PROTOCOL 34 // Telefunken (1560)
#define IRMP_ROOMBA_PROTOCOL 35 // iRobot Roomba vacuum cleaner
#define IRMP_RCMM32_PROTOCOL 36 // Fujitsu-Siemens (Activy remote control)
#define IRMP_RCMM24_PROTOCOL 37 // Fujitsu-Siemens (Activy keyboard)
#define IRMP_RCMM12_PROTOCOL 38 // Fujitsu-Siemens (Activy keyboard)
</syntaxhighlight>

Die Werte für die Adresse und das Kommando muss man natürlich einmal für eine unbekannte Fernbedienung auslesen und dann über ein UART oder LC-Display ausgeben, um sie dann im Programm hart zu kodieren. Oder man hat eine kleine Anlernroutine, wo man einmal die gewünschten Tasten drücken muss, um sie anschließend im EEPROM abzuspeichern. Ein Beispiel dazu findet man im Artikel [http://www.mikrocontroller.net/articles/DIY_Lernfähige_Fernbedienung_mit_IRMP Lernfähige IR-Fernbedienung mit IRMP].

Eine weitere [http://www.mikrocontroller.net/svnbrowser/irmp/main.c?view=markup Beispiel-Main-Funktion] ist im Zip-File enthalten, da sieht man dann auch die Initialisierung des Timers.

=== "Entprellen" von Tasten ===

Um zu unterscheiden, ob eine Taste lange gedrückt wurde oder lediglich einzeln, dient das Bit IRMP_FLAG_REPETITION. Dieses wird im Struct-Member '''flags''' gesetzt, wenn eine Taste auf der Fernbedienung längere Zeit gedrückt wurde und dadurch immer wieder dasselbe Kommando innerhalb kurzer Zeitabstände ausgesandt wird.

Beispiel:

<syntaxhighlight lang="c">
if (irmp_data.flags & IRMP_FLAG_REPETITION)
{
// Benutzer hält die Taste länger runter
// entweder:
// ich ignoriere die (Wiederholungs-)Taste
// oder:
// ich benutze diese Info, um einen Repeat-Effekt zu nutzen
}
else
{
// Es handelt sich um eine neue Taste
}
</syntaxhighlight>

Dies kann zum Beispiel dafür genutzt werden, um die Tasten 0-9 zu "entprellen", indem man Kommandos mit gesetztem Bit IRMP_FLAG_REPETITION ignoriert. Bei dem Drücken auf die Tasten VOLUME+ oder VOLUME- kann die wiederholte Auswertung ein und desselben Kommandos aber durchaus gewünscht sein - zum Beispiel, um [[LED-Fading|LEDs zu faden]].

Wenn man nur Einzeltasten auswerten will, kann man obigen IF-Block reduzieren auf:

<syntaxhighlight lang="c">
if (! (irmp_data.flags & IRMP_FLAG_REPETITION))
{
// Es handelt sich um eine neue Taste
// ACTION!
}
</syntaxhighlight>

== Arbeitsweise ==

Das "Working Horse" von [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] ist die Interrupt Service Routine irmp_ISR() welche 15.000 mal pro Sekunde aufgerufen werden sollte. Weicht dieser Wert ab, muss die Preprocessor-Konstante [[IRMP#F_INTERRUPTS|F_INTERRUPTS]] in [http://www.mikrocontroller.net/svnbrowser/irmp/irmpconfig.h?view=markup irmpconfig.h] angepasst werden. Der Wert kann zwischen 10kHz und 20kHz eingestellt werden.

irmp_ISR() detektiert zunächst die Länge und die Form des/der Startbits und ermittelt daraus das verwendete Protokoll. Sobald das Protokoll erkannt wurde, werden die weiter einzulesenden Bits parametrisiert, um dann möglichst effektiv in den weiteren Aufrufen das komplette IR-Telegramm einzulesen.

Um direkt Kritikern den Wind aus den Segeln zu nehmen:

Ich weiss, die ISR ist ziemlich groß. Aber da sie sich wie eine State Machine verhält, ist der tatsächlich ausgeführte Code pro Durchlauf relativ gering. Solange es "dunkel" ist (und das ist es ja die meiste Zeit ;-)) ist die aufgewendete Zeit sogar verschwindend gering. Im WordClock-Projekt werden mit ein- und demselben Timer 8 ISRs aufgerufen, davon ist die irmp_ISR() nur eine unter vielen. Bei mindestens 8 MHz CPU-Takt traten bisher keine Timing-Probleme auf. Daher sehe ich bei der Länge von irmp_ISR überhaupt kein Problem.

Ein Quarz ist nicht unbedingt notwendig, es funktioniert auch mit dem internen Oszillator des AVRs, wenn man die Prescaler-Fuse entsprechend gesetzt hat, dass die CPU auch mit 8MHz rennt ... Die Fuse-Werte für einen ATMEGA88 findet man in [http://www.mikrocontroller.net/svnbrowser/irmp/main.c?view=markup main.c].

== Scannen von unbekannten IR-Protokollen ==

Stellt man in [http://www.mikrocontroller.net/svnbrowser/irmp/irmpconfig.h?view=markup irmpconfig.h] in der Zeile

<syntaxhighlight lang="c">
#define IRMP_LOGGING 0 // 1: log IR signal (scan), 0: do not (default)
</syntaxhighlight>

den Wert für [[IRMP#IRMP_LOGGING|IRMP_LOGGING]] auf 1, wird in [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] eine Protokollierung eingeschaltet: Es werden dann die Hell- und Dunkelphase auf dem UART des Microntrollers mit 9600Bd ausgegeben: 1=Dunkel, 0=Hell. Eventuell müssen dann die Konstanten in den Funktionen uart_init() und uart_putc() angepasst werden; das kommt auf den verwendeten AVR-µC an.

'''Hinweis: Für PIC-Prozessoren gibt es ein eigenes Logging-Modul namens [http://www.mikrocontroller.net/svnbrowser/irmp/irmpextlog.c?view=markup irmpextlog.c]. Dieses ermöglicht das Logging über USB. Für AVR-Prozessoren ist [http://www.mikrocontroller.net/svnbrowser/irmp/irmpextlog.c?view=markup irmpextlog.c] irrelevant'''

Nimmt man diese Protokoll-Scans mit einem Terminal-Emulationsprogramm auf und speichert sie dann als normale Datei ab, kann man diese Scan-Dateien zur Analyse verwenden, um damit [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] an das unbekannte Protokoll anzupassen - siehe nächstes Kapitel.

Wer eine Fernbedienung hat, die nicht von [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] unterstützt wird, kann mir ([http://www.mikrocontroller.net/user/show/ukw ukw]) gern die Scan-Dateien zuschicken. Ich schaue dann, ob das Protokoll in das IRMP-Konzept passt und passe gegebenenfalls den Source an.

== IRMP unter Linux und Windows ==

=== Übersetzen ===

[http://www.mikrocontroller.net/svnbrowser/irmp/irmp.c?view=markup irmp.c] lässt sich auch unter Linux direkt kompilieren, um damit Infrarot-Scans, welche in Dateien gespeichert sind, direkt zu testen. Im Unterordner IR-Data finden sich solche Dateien, die man dem [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] direkt zum "Fraß" vorwerfen kann.

Das Übersetzen von [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] geht folgendermaßen:

make -f makefile.lnx

Dabei werden 3 IRMP-Versionen erzeugt:

* irmp-10kHz: Version für 10kHz Scans
* irmp-15kHz: Version für 15kHz Scans
* irmp-20kHz: Version für 20kHz Scans

=== Aufruf von IRMP ===

Der Aufruf geschieht dann über:

./irmp-nnkHz [-l|-p|-a|-v] < scan-file

Die angegebenen Optionen schließen sich aus, das heisst, es kann jeweils nur eine Option zu einer Zeit angegeben werden:

Option:

-l List gibt eine Liste der Pulse und Pausen aus
-a analyze analysiert die Puls-/Pausen und schreibt ein "Spektrum" in ASCII-Form
-v verbose ausführliche Ausgabe
-p Print Timings gibt für alle Protokolle eine Timing-Tabelle aus

Beispiele:

=== Normale Ausgabe ===

./irmp-10kHz < IR-Data/orion_vcr_07660BM070.txt

<syntaxhighlight lang="c">
-------------------------------------------------------------------------
# Taste 1
00000001110111101000000001111111 p = 2, a = 0x7b80, c = 0x0001, f = 0x00
-------------------------------------------------------------------------
# Taste 2
00000001110111100100000010111111 p = 2, a = 0x7b80, c = 0x0002, f = 0x00
-------------------------------------------------------------------------
# Taste 3
00000001110111101100000000111111 p = 2, a = 0x7b80, c = 0x0003, f = 0x00
-------------------------------------------------------------------------
# Taste 4
00000001110111100010000011011111 p = 2, a = 0x7b80, c = 0x0004, f = 0x00
-------------------------------------------------------------------------
...
</syntaxhighlight>

=== Listen-Ausgabe ===

./irmp-10kHz -l < IR-Data/orion_vcr_07660BM070.txt

<syntaxhighlight lang="c">
# Taste 1
pulse: 91 pause: 44
pulse: 6 pause: 5
pulse: 6 pause: 6
pulse: 6 pause: 5
pulse: 6 pause: 5
pulse: 6 pause: 5
pulse: 6 pause: 6
pulse: 6 pause: 5
pulse: 6 pause: 16
...
</syntaxhighlight>

=== Analyse ===

./irmp-10kHz -a < IR-Data/orion_vcr_07660BM070.txt

<syntaxhighlight lang="c">
-------------------------------------------------------------------------------
START PULSES:
90 o 1
91 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 33
92 ooo 2
pulse avg: 91.0=9102.8 us, min: 90=9000.0 us, max: 92=9200.0 us, tol: 1.1%
-------------------------------------------------------------------------------
START PAUSES:
43 oo 1
44 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 25
45 oooooooooooooooooooooooo 10
pause avg: 44.2=4425.0 us, min: 43=4300.0 us, max: 45=4500.0 us, tol: 2.8%
-------------------------------------------------------------------------------
PULSES:
5 o 17
6 ooooooooooooooooooooooooooooooooooooooooooooooooooooooo 562
7 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 609
pulse avg: 6.5= 649.8 us, min: 5= 500.0 us, max: 7= 700.0 us, tol: 23.1%
-------------------------------------------------------------------------------
PAUSES:
4 ooooooooooooooooooooooo 169
5 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 412
6 oooo 31
pause avg: 4.8= 477.5 us, min: 4= 400.0 us, max: 6= 600.0 us, tol: 25.7%
15 oooooo 43
16 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 425
17 oooooooooo 72
pause avg: 16.1=1605.4 us, min: 15=1500.0 us, max: 17=1700.0 us, tol: 6.6%
-------------------------------------------------------------------------------
</syntaxhighlight>

Hier sieht man die gemessenen Zeiten aller Pulse und Pausen als (liegende) Glockenkurven, welche natürlich wegen der ASCII-Darstellung nicht gerade einer Idealkurve entsprechen. Je schmaler die gemessenen Kanäle, desto besser ist das Timing der Fernbedienung.

Aus obigem Output kann man herauslesen:

* Das Start-Bit hat eine Pulslänge zwischen 9000 und 9200 usec, im Mittel sind es 9102 usec. Die Abweichung von diesem Mittelwert liegt bei 1,1 Prozent.

* Das Start-Bit hat eine Pausenlänge zwischen 4300 usec und 4500 usec, der Mittelwert beträgt 4424 usec. Der Fehler liegt bei 2,8 Prozent.

* Die Pulslänge eines Datenbits liegt zwischen 500 usec und 700 usec, im Mittel sind es 650 usec, der Fehler liegt bei (stolzen) 23,1 Prozent!

Desweiteren gibt es noch 2 verschieden lange Pausen (für die Bits 0 und 1), das Ablesen der Werte überlasse ich dem geneigten Leser ;-)

=== Ausführliche Ausgabe ===

./irmp-10kHz -v < IR-Data/orion_vcr_07660BM070.txt

<syntaxhighlight lang="c">
-------------------------------------------------------------------------------
# 1 - IR-cmd: 0x0001
0.200ms [starting pulse]
13.700ms [start-bit: pulse = 91, pause = 44]
protocol = NEC, start bit timings: pulse: 62 - 118, pause: 30 - 60
pulse_1: 3 - 8
pause_1: 11 - 23
pulse_0: 3 - 8
pause_0: 3 - 8
command_offset: 16
command_len: 16
complete_len: 32
stop_bit: 1
14.800ms [bit 0: pulse = 6, pause = 5] 0
16.000ms [bit 1: pulse = 6, pause = 6] 0
17.100ms [bit 2: pulse = 6, pause = 5] 0
18.200ms [bit 3: pulse = 6, pause = 5] 0
19.300ms [bit 4: pulse = 6, pause = 5] 0
20.500ms [bit 5: pulse = 6, pause = 6] 0
21.600ms [bit 6: pulse = 6, pause = 5] 0
23.800ms [bit 7: pulse = 6, pause = 16] 1
26.100ms [bit 8: pulse = 6, pause = 17] 1
28.300ms [bit 9: pulse = 6, pause = 16] 1
29.500ms [bit 10: pulse = 6, pause = 6] 0
31.700ms [bit 11: pulse = 6, pause = 16] 1
34.000ms [bit 12: pulse = 6, pause = 17] 1
36.200ms [bit 13: pulse = 6, pause = 16] 1
38.500ms [bit 14: pulse = 6, pause = 17] 1
39.600ms [bit 15: pulse = 6, pause = 5] 0
41.900ms [bit 16: pulse = 6, pause = 17] 1
43.000ms [bit 17: pulse = 6, pause = 5] 0
44.100ms [bit 18: pulse = 6, pause = 5] 0
45.200ms [bit 19: pulse = 6, pause = 5] 0
46.400ms [bit 20: pulse = 7, pause = 5] 0
47.500ms [bit 21: pulse = 6, pause = 5] 0
48.600ms [bit 22: pulse = 6, pause = 5] 0
49.800ms [bit 23: pulse = 6, pause = 6] 0
50.900ms [bit 24: pulse = 5, pause = 6] 0
53.100ms [bit 25: pulse = 6, pause = 16] 1
55.400ms [bit 26: pulse = 6, pause = 17] 1
57.600ms [bit 27: pulse = 6, pause = 16] 1
59.900ms [bit 28: pulse = 6, pause = 17] 1
62.100ms [bit 29: pulse = 6, pause = 16] 1
64.400ms [bit 30: pulse = 6, pause = 17] 1
66.700ms [bit 31: pulse = 6, pause = 17] 1
stop bit detected
67.300ms code detected, length = 32
67.300ms p = 2, a = 0x7b80, c = 0x0001, f = 0x00
-------------------------------------------------------------------------------
</syntaxhighlight>

=== Timing-Tabelle ===

./irmp-10kHz -p

<syntaxhighlight lang="c">
IRMP_TIMEOUT_LEN: 165
IRMP_KEY_REPETITION_LEN 1500

PROTOCOL S S-PULSE S-PAUSE PULSE-0 PAUSE-0 PULSE-1 PAUSE-1
====================================================================================
SIRCS 1 21 - 27 4 - 7 4 - 8 4 - 8 10 - 14 4 - 8
NEC 1 53 - 127 26 - 64 2 - 9 2 - 9 2 - 9 9 - 25
NEC (rep) 1 53 - 127 13 - 32 2 - 9 2 - 9 2 - 9 9 - 25
SAMSUNG 1 40 - 51 40 - 51 3 - 8 2 - 7 3 - 8 9 - 20
MATSUSHITA 1 27 - 43 27 - 43 4 - 13 4 - 13 4 - 13 15 - 38
KASEIKYO 1 29 - 38 14 - 20 1 - 8 1 - 7 1 - 8 5 - 20
RECS80 1 1 - 3 66 - 83 0 - 3 43 - 55 0 - 3 66 - 83
RC5 1 7 - 11 7 - 11 7 - 11
DENON 1 1 - 4 1 - 4 6 - 10 1 - 4 16 - 22
RC6 1 23 - 30 7 - 11 3 - 6
RECS80EXT 1 1 - 3 34 - 39 0 - 3 43 - 55 0 - 3 66 - 83
NUBERT 1 10 - 17 2 - 5 3 - 7 9 - 17 10 - 17 2 - 5
BANG_OLUFSEN 1 1 - 3 27 - 35
BANG_OLUFSEN 2 1 - 3 27 - 35
BANG_OLUFSEN 3 1 - 3 140 - 165
BANG_OLUFSEN 4 1 - 3 27 - 35
BANG_OLUFSEN - 1 - 3 27 - 35 1 - 3 83 - 104
GRUNDIG/NOKIA 1 3 - 7 22 - 33 3 - 7
SIEMENS 1 2 - 4 2 - 4 2 - 4
FDC 1 18 - 24 8 - 12 1 - 5 1 - 3 1 - 5 5 - 10
RCCAR 1 17 - 23 17 - 23 4 - 8 5 - 13 4 - 8 2 - 7
</syntaxhighlight>

Die Zahlen sind in diesem Fall Einheiten von 10kHz. Zum Beispiel entspricht die Zahl 27 dem Wert 27/10000 = 2,7msec.

Bei längeren Ausgaben sollte man das Programm "less" verwenden, um seitenweise zu blättern, z.B.:

./irmp-10kHz -v < IR-Data/Samsung_DVD_Rec_00062C.txt | less

Diese Scan-Dateien halfen mir nicht nur bei der Entwicklung des IRMP, sondern können auch bei der Anpassung des Sources an neue IR-Protokolle sehr hilfreich sein.

Mittlerweile kann man [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] auch unter Windows nutzen, nämlich folgendermaßen:

* Eingabeaufforderung starten
* In das Verzeichnis irmp wechseln
* Aufruf von:
irmp-10kHz.exe < IR-Data\rc5x.txt

Da manche Ausgaben sehr lang werden, empfiehlt es sich auch hier, die Ausgabe in eine Datei zu lenken oder in den more weiterzuleiten, damit man seitenweise blättern kann:

irmp-10kHz.exe < IR-Data\rc5x.txt | more

Auch hier gelten dieselben Optionen wie für die Linux-Version.

== Fernbedienungen ==

{| class="wikitable"
! Protokoll || Bezeichnung || Gerät || Device Address
|-
| [[IRMP#NEC_+_extended_NEC|NEC]] || Toshiba CT-9859 || Fernseher || 0x5F40
|-
| || Toshiba VT-728G || V-728G Videorekorder || 0x5B44
|-
| || Elta 8848 MP 4 || DVD-Player || 0x7F00
|-
| || AS-218 || Askey TV-View CHP03X (TV-Karte) || 0x3B86
|-
| || Cyberhome ??? || Cyberhome DVD Player || 0x6D72
|-
| || WD TV Live || Western Digital Multimediaplayer || 0x1F30
|-
| || Canon WL-DC100 || Kamera Canon PowerShot G5 || 0xB1CA
|-
| [[IRMP#NEC16|NEC16]] || Daewoo || Videorekorder || 0x0015
|-
| [[IRMP#KASEIKYO|KASEIKYO]] || Technics EUR646497 || AV Receiver SA-AX 730 || 0x2002
|-
| || Panasonic TV || Fernseher TX-L32EW6 || 0x2002
|-
| [[IRMP#RC5_+_RC5X|RC5]] || Loewe Assist/RC3/RC4 || Fernseher (FB auf TV-Mode) || 0x0000
|-
| [[IRMP#RC6_+_RC6A|RC6]] || Philips Television || Fernseher (FB auf TV-Mode) || 0x0000
|-
| [[IRMP#SIRCS|SIRCS]] || Sony RM-816 || Fernseher (FB auf TV-Mode) || 0x0000
|-
| [[IRMP#DENON|DENON]] || DENON RC970 || AVR3805 (Verstärker) || 0x0008
|-
| || DENON RC970 || DVD/CD-Player || 0x0002
|-
| || DENON RC970 || Tuner || 0x0006
|-
| [[IRMP#SAMSUNG32|SAMSUNG32]] || Samsung AA59-00484A || LE40D550 Fernseher || 0x0707
|-
| || LG AKB72033901 || Blu-Ray Player BD370 || 0x2D2D
|-
| [[IRMP#APPLE|APPLE]] || Apple || Apple Dock (iPod 2) || 0x0020
|-
|}

----

== IR-Tastaturen ==

[[Datei:irmp-fdc3402.jpg|miniatur|FDC-3402-Tastatur]]

[[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] unterstützt ab Version 1.7.0 auch IR-Tastaturen, nämlich die Infrarot-Tastatur FDC-3402 - erhältlich bei Pollin (Art. 711 056) für weniger als 2 EUR.

Beim Erkennen einer Taste gibt [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] folgende Daten zurück:

Protokoll-Nummer (irmp_data.protocol): 18
Addresse (irmp_data.address): 0x003F

Als Kommando (irmp_data.command) werden folgende Werte zurückgeliefert:

{| class="wikitable"
! Code || Taste || Code || Taste || Code || Taste || Code || Taste || Code || Taste || Code || Taste || Code || Taste || Code || Taste
|-
| 0x0000 || || 0x0010 || TAB || 0x0020 || 's' || 0x0030 || 'c' || 0x0040 || || 0x0050 || HOME || 0x0060 || || 0x0070 || MENUE
|-
| 0x0001 || '^' || 0x0011 || 'q' || 0x0021 || 'd' || 0x0031 || 'v' || 0x0041 || || 0x0051 || END || 0x0061 || || 0x0071 || BACK
|-
| 0x0002 || '1' || 0x0012 || 'w' || 0x0022 || 'f' || 0x0032 || 'b' || 0x0042 || || 0x0052 || || 0x0062 || || 0x0072 || FORWARD
|-
| 0x0003 || '2' || 0x0013 || 'e' || 0x0023 || 'g' || 0x0033 || 'n' || 0x0043 || || 0x0053 || UP || 0x0063 || || 0x0073 || ADDRESS
|-
| 0x0004 || '3' || 0x0014 || 'r' || 0x0024 || 'h' || 0x0034 || 'm' || 0x0044 || || 0x0054 || DOWN || 0x0064 || || 0x0074 || WINDOW
|-
| 0x0005 || '4' || 0x0015 || 't' || 0x0025 || 'j' || 0x0035 || ',' || 0x0045 || || 0x0055 || PAGE_UP || 0x0065 || || 0x0075 || 1ST_PAGE
|-
| 0x0006 || '5' || 0x0016 || 'z' || 0x0026 || 'k' || 0x0036 || '.' || 0x0046 || || 0x0056 || PAGE_DOWN || 0x0066 || || 0x0076 || STOP
|-
| 0x0007 || '6' || 0x0017 || 'u' || 0x0027 || 'l' || 0x0037 || '-' || 0x0047 || || 0x0057 || || 0x0067 || || 0x0077 || MAIL
|-
| 0x0008 || '7' || 0x0018 || 'i' || 0x0028 || 'ö' || 0x0038 || || 0x0048 || || 0x0058 || || 0x0068 || || 0x0078 || FAVORITES
|-
| 0x0009 || '8' || 0x0019 || 'o' || 0x0029 || 'ä' || 0x0039 || SHIFT_RIGHT || 0x0049 || || 0x0059 || RIGHT || 0x0069 || || 0x0079 || NEW_PAGE
|-
| 0x000A || '9' || 0x001A || 'p' || 0x002A || '#' || 0x003A || CTRL || 0x004A || || 0x005A || || 0x006A || || 0x007A || SETUP
|-
| 0x000B || '0' || 0x001B || 'ü' || 0x002B || CR || 0x003B || || 0x004B || INSERT || 0x005B || || 0x006B || || 0x007B || FONT
|-
| 0x000C || 'ß' || 0x001C || '+' || 0x002C || SHIFT_LEFT || 0x003C || ALT_LEFT || 0x004C || DELETE || 0x005C || || 0x006C || || 0x007C || PRINT
|-
| 0x000D || '´' || 0x001D || || 0x002D || '<' || 0x003D || SPACE || 0x004D || || 0x005D || || 0x006D || || 0x007D ||
|-
| 0x000E || || 0x001E || CAPSLOCK || 0x002E || 'y' || 0x003E || ALT_RIGHT || 0x004E || || 0x005E || || 0x006E || ESCAPE || 0x007E || ON_OFF
|-
| 0x000F || BACKSPACE || 0x001F || 'a' || 0x002F || 'x' || 0x003F || || 0x004F || LEFT || 0x005F || || 0x006F || || 0x007F ||
|-
|}

Zusatztasten links:

{| class="wikitable"
! Code || Taste
|-
|-
| 0x0400 || KEY_MOUSE_1
|-
| 0x0800 || KEY_MOUSE_2
|}

Dabei gelten die obigen Werte für das Drücken einer Taste. Wird die Taste wieder losgelassen, setzt [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] zusätzlich das 8. Bit im Kommando.

Beispiel:

Taste 'a' drücken: 0x001F
Taste 'a' loslassen: 0x009F

Ausnahme ist die EIN/AUS-Taste: Diese sendet nur beim Drücken einen Code, nicht beim Loslassen.

Wird eine Taste länger gedrückt, wird das in irmp_data.flag angezeigt.

Beispiel:

command flag
Taste 'a' drücken: 0x001F 0x00
Taste 'a' drücken: 0x001F 0x01
Taste 'a' drücken: 0x001F 0x01
Taste 'a' drücken: 0x001F 0x01
....
Taste 'a' loslassen: 0x009F 0x00

Werden Tastenkombinationen (zum Beispiel für ein großes 'A') gedrückt, dann sind die Rückgabewerte von [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] in folgendem Ablauf zu sehen:

Linke SHIFT-Taste drücken: 0x0002
Taste 'a' drücken: 0x001F
Taste 'a' loslassen: 0x009F
Linke SHIFT-Taste loslassen: 0x0082

In [http://www.mikrocontroller.net/svnbrowser/irmp/irmp.c?view=markup irmp.c] findet man für die LINUX-Version eine Funktion get_fdc_key(), welche als Vorlage dienen mag, die Keycodes einer FDC-Tastatur in die entsprechenden ASCII-Codes umzuwandeln. Diese Funktion kann man entweder lokal auf dem µC nutzen, um die Keycodes zu decodieren, oder auf einem Hostsystem (z.B. PC), an welches die IRMP-Data-Struktur gesandt wird. Dafür sollte man die Funktion incl. der dazugehörenden Preprozessor-Konstanten in seinen Applikations-Quelltext kopieren.

Hier der entsprechende Auszug:
<syntaxhighlight lang="c">
#define STATE_LEFT_SHIFT 0x01
#define STATE_RIGHT_SHIFT 0x02
#define STATE_LEFT_CTRL 0x04
#define STATE_LEFT_ALT 0x08
#define STATE_RIGHT_ALT 0x10

#define KEY_ESCAPE 0x1B // keycode = 0x006e
#define KEY_MENUE 0x80 // keycode = 0x0070
#define KEY_BACK 0x81 // keycode = 0x0071
#define KEY_FORWARD 0x82 // keycode = 0x0072
#define KEY_ADDRESS 0x83 // keycode = 0x0073
#define KEY_WINDOW 0x84 // keycode = 0x0074
#define KEY_1ST_PAGE 0x85 // keycode = 0x0075
#define KEY_STOP 0x86 // keycode = 0x0076
#define KEY_MAIL 0x87 // keycode = 0x0077
#define KEY_FAVORITES 0x88 // keycode = 0x0078
#define KEY_NEW_PAGE 0x89 // keycode = 0x0079
#define KEY_SETUP 0x8A // keycode = 0x007a
#define KEY_FONT 0x8B // keycode = 0x007b
#define KEY_PRINT 0x8C // keycode = 0x007c
#define KEY_ON_OFF 0x8E // keycode = 0x007c

#define KEY_INSERT 0x90 // keycode = 0x004b
#define KEY_DELETE 0x91 // keycode = 0x004c
#define KEY_LEFT 0x92 // keycode = 0x004f
#define KEY_HOME 0x93 // keycode = 0x0050
#define KEY_END 0x94 // keycode = 0x0051
#define KEY_UP 0x95 // keycode = 0x0053
#define KEY_DOWN 0x96 // keycode = 0x0054
#define KEY_PAGE_UP 0x97 // keycode = 0x0055
#define KEY_PAGE_DOWN 0x98 // keycode = 0x0056
#define KEY_RIGHT 0x99 // keycode = 0x0059
#define KEY_MOUSE_1 0x9E // keycode = 0x0400
#define KEY_MOUSE_2 0x9F // keycode = 0x0800

static uint8_t
get_fdc_key (uint16_t cmd)
{
static uint8_t key_table[128] =
{
// 0 1 2 3 4 5 6 7 8 9 A B C D E F
0, '^', '1', '2', '3', '4', '5', '6', '7', '8', '9', '0', 'ß', '´', 0, '\b',
'\t','q', 'w', 'e', 'r', 't', 'z', 'u', 'i', 'o', 'p', 'ü', '+', 0, 0, 'a',
's', 'd', 'f', 'g', 'h', 'j', 'k', 'l', 'ö', 'ä', '#', '\r', 0, '<', 'y', 'x',
'c', 'v', 'b', 'n', 'm', ',', '.', '-', 0, 0, 0, 0, 0, ' ', 0, 0,

0, '°', '!', '"', '§', '$', '%', '&', '/', '(', ')', '=', '?', '`', 0, '\b',
'\t','Q', 'W', 'E', 'R', 'T', 'Z', 'U', 'I', 'O', 'P', 'Ü', '*', 0, 0, 'A',
'S', 'D', 'F', 'G', 'H', 'J', 'K', 'L', 'Ö', 'Ä', '\'','\r', 0, '>', 'Y', 'X',
'C', 'V', 'B', 'N', 'M', ';', ':', '_', 0, 0, 0, 0, 0, ' ', 0, 0
};
static uint8_t state;

uint8_t key = 0;

switch (cmd)
{
case 0x002C: state |= STATE_LEFT_SHIFT; break; // pressed left shift
case 0x00AC: state &= ~STATE_LEFT_SHIFT; break; // released left shift
case 0x0039: state |= STATE_RIGHT_SHIFT; break; // pressed right shift
case 0x00B9: state &= ~STATE_RIGHT_SHIFT; break; // released right shift
case 0x003A: state |= STATE_LEFT_CTRL; break; // pressed left ctrl
case 0x00BA: state &= ~STATE_LEFT_CTRL; break; // released left ctrl
case 0x003C: state |= STATE_LEFT_ALT; break; // pressed left alt
case 0x00BC: state &= ~STATE_LEFT_ALT; break; // released left alt
case 0x003E: state |= STATE_RIGHT_ALT; break; // pressed left alt
case 0x00BE: state &= ~STATE_RIGHT_ALT; break; // released left alt

case 0x006e: key = KEY_ESCAPE; break;
case 0x004b: key = KEY_INSERT; break;
case 0x004c: key = KEY_DELETE; break;
case 0x004f: key = KEY_LEFT; break;
case 0x0050: key = KEY_HOME; break;
case 0x0051: key = KEY_END; break;
case 0x0053: key = KEY_UP; break;
case 0x0054: key = KEY_DOWN; break;
case 0x0055: key = KEY_PAGE_UP; break;
case 0x0056: key = KEY_PAGE_DOWN; break;
case 0x0059: key = KEY_RIGHT; break;
case 0x0400: key = KEY_MOUSE_1; break;
case 0x0800: key = KEY_MOUSE_2; break;

default:
{
if (!(cmd & 0x80)) // pressed key
{
if (cmd >= 0x70 && cmd <= 0x7F) // function keys
{
key = cmd + 0x10; // 7x -> 8x
}
else if (cmd < 64) // key listed in key_table
{
if (state & (STATE_LEFT_ALT | STATE_RIGHT_ALT))
{
switch (cmd)
{
case 0x0003: key = '²'; break;
case 0x0008: key = '{'; break;
case 0x0009: key = '['; break;
case 0x000A: key = ']'; break;
case 0x000B: key = '}'; break;
case 0x000C: key = '\\'; break;
case 0x001C: key = '~'; break;
case 0x002D: key = '|'; break;
case 0x0034: key = 'µ'; break;
}
}
else if (state & (STATE_LEFT_CTRL))
{
if (key_table[cmd] >= 'a' && key_table[cmd] <= 'z')
{
key = key_table[cmd] - 'a' + 1;
}
else
{
key = key_table[cmd];
}
}
else
{
int idx = cmd + ((state & (STATE_LEFT_SHIFT | STATE_RIGHT_SHIFT)) ? 64 : 0);

if (key_table[idx])
{
key = key_table[idx];
}
}
}
}
break;
}
}

return (key);
}
</syntaxhighlight>

Als letztes noch ein Beispiel einer Anwendung der Funktion get_fdc_key():

<syntaxhighlight lang="c">
if (irmp_get_data (&irmp_data))
{
uint8_t key;

if (irmp_data.protocol == IRMP_FDC_PROTOCOL &&
(key = get_fdc_key (irmp_data.command)) != 0)
{
if ((key >= 0x20 && key < 0x7F) || key >= 0xA0) // show only printable characters
{
printf ("ascii-code = 0x%02x, character = '%c'\n", key, key);
}
else // it's a non-printable key
{
printf ("ascii-code = 0x%02x\n", key);
}
}
}
</syntaxhighlight>

Alle nicht-druckbaren Zeichen werden dabei folgendermaßen codiert:

{| class="wikitable"
! Taste || Konstante || Wert
|-
| ESC || KEY_ESCAPE || 0x1B
|-
| Menü || KEY_MENUE || 0x80
|-
| Zurück || KEY_BACK || 0x81
|-
| Vorw. || KEY_FORWARD || 0x82
|-
| Adresse || KEY_ADDRESS || 0x83
|-
| Fenster || KEY_WINDOW || 0x84
|-
| 1. Seite || KEY_1ST_PAGE || 0x85
|-
| Stop || KEY_STOP || 0x86
|-
| Mail || KEY_MAIL || 0x87
|-
| Fav. || KEY_FAVORITES || 0x88
|-
| Neue Seite || KEY_NEW_PAGE || 0x89
|-
| Setup || KEY_SETUP || 0x8A
|-
| Schrift || KEY_FONT || 0x8B
|-
| Druck || KEY_PRINT || 0x8C
|-
| Ein/Aus || KEY_ON_OFF || 0x8E
|-
| Backspace || '\b' || 0x08
|-
| CR/ENTER || '\r' || 0x0C
|-
| TAB || '\t' || 0x09
|-
| Einfg || KEY_INSERT || 0x90
|-
| Entf || KEY_DELETE || 0x91
|-
| Cursor links || KEY_LEFT || 0x92
|-
| Pos1 || KEY_HOME || 0x93
|-
| Ende || KEY_END || 0x94
|-
| Cursor rechts || KEY_UP || 0x95
|-
| Cursor runter || KEY_DOWN || 0x96
|-
| Bild hoch || KEY_PAGE_UP || 0x97
|-
| Bild runter || KEY_PAGE_DOWN || 0x98
|-
| Cursor links || KEY_RIGHT || 0x99
|-
| Linke Maustaste || KEY_MOUSE_1 || 0x9E
|-
| Rechte Maustaste || KEY_MOUSE_2 || 0x9F
|-
|}

Die Funktion get_fdc_key berücksichtigt das Gedrückthalten der Shift-, Strg- und ALT-Tasten. Damit funktioniert nicht nur das Schreiben von Großbuchstaben, sondern auch das Auswählen der Sonderzeichen mit der Tastenkombination ALT + Taste, z.B. ALT + m = µ oder ALT + q = @. Ebenso kann man mit der Strg-Taste die Control-Zeichen CTRL-A bis CTRL-Z senden. Die CapsLock-Taste wird ignoriert, da ich sie sowieso für die überflüssigste Taste überhaupt halte ;-)

----

= IRSND - Infrarot-Multiprotokoll-Encoder =

[[Datei:irmp-title.png| |Scan eines NEC-kompatiblen Fernbedienungssignals]]

== Einleitung IRSND ==

[[Datei:ir-sender.png|miniatur|Anschluß eines einfachen IR-Senders an µC. 1k als Basiswiderstand sollte die Reichweite beträchtlich erhöhen.]]

[[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] ist das Gegenstück zu IRMP: es reproduziert aus den Daten, die mit [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] empfangen wurden, wieder den Original Frame, der dann über eine Infrarot-Diode ausgegeben werden kann.

=== Von IRSND unterstützte µCs ===

[[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] ist lauffähig auf folgenden AVR µCs:

* ATtiny87, ATtiny167
* ATtiny45, ATtiny85
* ATtiny44, ATtiny84
* ATmega8, ATmega16, ATmega32
* ATmega162
* ATmega164, ATmega324, ATmega644, ATmega644P, ATmega1284
* ATmega88, ATmega88P, ATmega168, ATmega168P, ATmega328P

Es gibt aber auch Portierungen auf diverse PIC µCs - für den CCS- und C18-Compiler. Auch ist [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] mittlerweile auf ARM STM32 lauffähig.

=== Von IRSND unterstützte Protokolle ===

[[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] unterstützt die folgenden Protokolle:

* [[IRMP#SIRCS|SIRCS]]
* [[IRMP#NEC_+_extended_NEC|NEC]]
* [[IRMP#SAMSUNG|SAMSUNG]]
* [[IRMP#SAMSUNG32|SAMSUNG32]]
* [[IRMP#MATSUSHITA|MATSUSHITA]]
* [[IRMP#RC5_+_RC5X|RC5]]
* [[IRMP#KASEIKYO|KASEIKYO]]
* [[IRMP#DENON|DENON]]
* [[IRMP#JVC|JVC]]
* [[IRMP#APPLE|APPLE]]
* [[IRMP#NUBERT|NUBERT]]
* [[IRMP#B&O|BANG_OLUFSON]]
* [[IRMP#GRUNDIG_+_NOKIA|GRUNDIG]]
* [[IRMP#GRUNDIG_+_NOKIA|NOKIA]]
* [[IRMP#SIEMENS_+_RUWIDO|SIEMENS]] (bei mind. ~15kHz)
* [[IRMP#FDC|FDC]] (bei mind. ~15kHz)
* [[IRMP#RCCAR|RCCAR]] (bei mind. ~15kHz)
* [[IRMP#RECS80|RECS80]] (bei mind. ~20kHz)
* [[IRMP#RECS80EXT|RECS80EXT]] (bei mind. ~20kHz)
* [[IRMP#NIKON|NIKON]]
* [[IRMP#RC6_+_RC6A|RC6]]
* [[IRMP#RC6_+_RC6A|RC6A]]
* [[IRMP#THOMSON|THOMSON]]
* [[IRMP#NEC16|NEC16]]
* [[IRMP#NEC42|NEC42]]
* [[IRMP#LEGO|LEGO]]
* [[IRMP#IR60 (SDA2008)|IR60 (SDA2008)]]
* [[IRMP#A1TVBOX|A1TVBOX]]
* [[IRMP#ROOMBA|ROOMBA]] '''(NEU, nur im SVN!)'''
* [[IRMP#SPEAKER|SPEAKER]] '''(NEU, nur im SVN!)'''
* [[IRMP#TELEFUNKEN|TELEFUNKEN]] '''(NEU, nur im SVN!)'''

[[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] unterstützt die folgenden Protokolle derzeit (noch) '''NICHT''':

* [[IRMP#KATHREIN|KATHREIN]]
* [[IRMP#NETBOX|NETBOX]]
* [[IRMP#ORTEK|ORTEK]]
* [[IRMP#RCMM|RCMM]]
* [[IRMP#LGAIR|LGAIR]]

== Download IRSND ==

Version 2.4.0, Stand vom 20.02.2014

Download Release-Version: [http://www.mikrocontroller.net/wikifiles/c/c7/Irsnd.zip Irsnd.zip]

[[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] & [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] sind nun auch über SVN abrufbar: [http://www.mikrocontroller.net/svnbrowser/irmp/ IRMP im SVN]

'''Achtung:'''

Die Version im SVN kann eine Zwischen- oder Test-Version sein, die nicht den hier dokumentierten Stand widerspiegelt! Im Zweifel verwendet man besser den obigen Download auf Irsnd.zip.

'''Die Software-Änderungen kann man sich hier anschauen: [http://www.mikrocontroller.net/articles/IRMP#Software-Historie_IRSND Software-Historie IRSND]'''

== Source-Code IRSND ==

Der Source-Code lässt sich einfach übersetzen, indem man unter Windows die Projekt-Datei irsnd.aps in das AVRStudio 4 lädt.

Auch für andere Entwicklungsumgebungen lässt sich leicht ein Projekt bzw. Makefile zusammenstellen. Zum IRSND-Source gehören folgende Dateien:

* [http://www.mikrocontroller.net/svnbrowser/irmp/irsnd.c?view=markup irsnd.c] - Der eigentliche IR-Encoder
* [http://www.mikrocontroller.net/svnbrowser/irmp/irmpprotocols.h?view=markup irmpprotocols.h] - Sämtliche Definitionen zu den IR-Protokollen
* [http://www.mikrocontroller.net/svnbrowser/irmp/irmpsystem.h?view=markup irmpsystem.h] - Vom Zielsystem abhängige Definitionen für AVR/PIC/STM32
* [http://www.mikrocontroller.net/svnbrowser/irmp/irsnd.h?view=markup irsnd.h] - Include-Datei für die Applikation
* [http://www.mikrocontroller.net/svnbrowser/irmp/irsndconfig.h?view=markup irsndconfig.h] - Anzupassende Konfigurationsdatei

* [http://www.mikrocontroller.net/svnbrowser/irmp/irsndmain.c?view=markup irsndmain.c] - Beispiel Anwendung

'''WICHTIG:'''

'''Im Applikations-Source sollte nur [http://www.mikrocontroller.net/svnbrowser/irmp/irsnd.h?view=markup irsnd.h] per include eingefügt werden, also lediglich:'''

<syntaxhighlight lang="c">
#include "irsnd.h"
</syntaxhighlight>

Alle anderen Include-Dateien werden automatisch über [http://www.mikrocontroller.net/svnbrowser/irmp/irsnd.h?view=markup irsnd.h] "eingefügt". Siehe dazu auch die Beispieldatei [http://www.mikrocontroller.net/svnbrowser/irmp/irsndmain.c?view=markup irsndmain.c].

[[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] encodiert sämtliche oben aufgelisteten Protokolle in einer ISR, siehe [http://www.mikrocontroller.net/svnbrowser/irmp/irsnd.c?view=markup irsnd.c].

=== Einstellungen in irsndconfig.h ===

==== F_INTERRUPTS ====

Anzahl der Interrupts pro Sekunde. Der Wert kann zwischen 10000 und 20000 eingestellt werden.

Standardwert:
<syntaxhighlight lang="c">
#define F_INTERRUPTS 15000 // interrupts per second
</syntaxhighlight>

==== IRSND_SUPPORT_xxx_PROTOCOL ====

Hier lässt sich einstellen, welche Protokolle von [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] unterstützt werden sollen. Die Standardprotokolle sind bereits aktiv. Möchte man weitere Protokolle einschalten bzw. einige aus Speicherplatzgründen deaktivieren, sind die entsprechenden Werte in [http://www.mikrocontroller.net/svnbrowser/irmp/irsndconfig.h?view=markup irsndconfig.h] anzupassen.

<syntaxhighlight lang="c">
// typical protocols, disable here! Enable Remarks F_INTERRUPTS Program Space
#define IRSND_SUPPORT_SIRCS_PROTOCOL 1 // Sony SIRCS >= 10000 ~200 bytes
#define IRSND_SUPPORT_NEC_PROTOCOL 1 // NEC + APPLE >= 10000 ~100 bytes
#define IRSND_SUPPORT_SAMSUNG_PROTOCOL 1 // Samsung + Samsung32 >= 10000 ~300 bytes
#define IRSND_SUPPORT_MATSUSHITA_PROTOCOL 1 // Matsushita >= 10000 ~200 bytes
#define IRSND_SUPPORT_KASEIKYO_PROTOCOL 1 // Kaseikyo >= 10000 ~300 bytes

// more protocols, enable here! Enable Remarks F_INTERRUPTS Program Space
#define IRSND_SUPPORT_DENON_PROTOCOL 0 // DENON, Sharp >= 10000 ~200 bytes
#define IRSND_SUPPORT_RC5_PROTOCOL 0 // RC5 >= 10000 ~150 bytes
#define IRSND_SUPPORT_RC6_PROTOCOL 0 // RC6 >= 10000 ~250 bytes
#define IRSND_SUPPORT_RC6A_PROTOCOL 0 // RC6A >= 10000 ~250 bytes
#define IRSND_SUPPORT_JVC_PROTOCOL 0 // JVC >= 10000 ~150 bytes
#define IRSND_SUPPORT_NEC16_PROTOCOL 0 // NEC16 >= 10000 ~150 bytes
#define IRSND_SUPPORT_NEC42_PROTOCOL 0 // NEC42 >= 10000 ~150 bytes
#define IRSND_SUPPORT_IR60_PROTOCOL 0 // IR60 (SDA2008) >= 10000 ~250 bytes
#define IRSND_SUPPORT_GRUNDIG_PROTOCOL 0 // Grundig >= 10000 ~300 bytes
#define IRSND_SUPPORT_SIEMENS_PROTOCOL 0 // Siemens, Gigaset >= 15000 ~150 bytes
#define IRSND_SUPPORT_NOKIA_PROTOCOL 0 // Nokia >= 10000 ~400 bytes

// exotic protocols, enable here! Enable Remarks F_INTERRUPTS Program Space
#define IRSND_SUPPORT_KATHREIN_PROTOCOL 0 // Kathrein >= 10000 DON'T CHANGE, NOT SUPPORTED YET!
#define IRSND_SUPPORT_NUBERT_PROTOCOL 0 // NUBERT >= 10000 ~100 bytes
#define IRSND_SUPPORT_BANG_OLUFSEN_PROTOCOL 0 // Bang&Olufsen >= 10000 ~250 bytes
#define IRSND_SUPPORT_RECS80_PROTOCOL 0 // RECS80 >= 15000 ~100 bytes
#define IRSND_SUPPORT_RECS80EXT_PROTOCOL 0 // RECS80EXT >= 15000 ~100 bytes
#define IRSND_SUPPORT_THOMSON_PROTOCOL 0 // Thomson >= 10000 ~250 bytes
#define IRSND_SUPPORT_NIKON_PROTOCOL 0 // NIKON >= 10000 ~150 bytes
#define IRSND_SUPPORT_NETBOX_PROTOCOL 0 // Netbox keyboard >= 10000 DON'T CHANGE, NOT SUPPORTED YET!
#define IRSND_SUPPORT_FDC_PROTOCOL 0 // FDC IR keyboard >= 10000 (better 15000) ~150 bytes
#define IRSND_SUPPORT_RCCAR_PROTOCOL 0 // RC CAR >= 10000 (better 15000) ~150 bytes
#define IRSND_SUPPORT_ROOMBA_PROTOCOL 0 // iRobot Roomba >= 10000 ~150 bytes
#define IRSND_SUPPORT_RUWIDO_PROTOCOL 0 // RUWIDO, T-Home >= 15000 ~250 bytes
#define IRSND_SUPPORT_A1TVBOX_PROTOCOL 0 // A1 TV BOX >= 15000 (better 20000) ~200 bytes
#define IRSND_SUPPORT_LEGO_PROTOCOL 0 // LEGO Power RC >= 20000 ~150 bytes
</syntaxhighlight>

Mit Setzen auf 0 wird das Protokoll deaktiviert, mit Setzen auf 1 wird es aktiviert. Die deaktivierten Protokolle werden dann nicht mitübersetzt. Das spart Speicherplatz im Flash, siehe Angaben in obigen Kommentaren. Wenn man unbedingt Speicherplatz sparen muss, gelten natürlich hier dieselben Tipps wie für IRMP.

Um das [[IRMP#APPLE|APPLE]]-Protokoll zu unterstützen, ist IRSND_SUPPORT_NEC_PROTOCOL auf 1 zu setzen, da es sich hier lediglich um einen Spezialfall vom [[IRMP#NEC_+_extended_NEC|NEC]]-Protokoll handelt.

==== IRSND_OCx ====

Für das Senden der IR-Signale benötigt [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] einen PWM-fähigen Output-Pin, da das Signal moduliert werden muss. Möglich sind eine der folgenden Einstellungen:

<syntaxhighlight lang="c">
#define IRSND_OCx IRSND_OC2 // OC2 on ATmegas supporting OC2, e.g. ATmega8
#define IRSND_OCx IRSND_OC2A // OC2A on ATmegas supporting OC2A, e.g. ATmega88
#define IRSND_OCx IRSND_OC2B // OC2B on ATmegas supporting OC2B, e.g. ATmega88
#define IRSND_OCx IRSND_OC0 // OC0 on ATmegas supporting OC0, e.g. ATmega162
#define IRSND_OCx IRSND_OC0A // OC0A on ATmegas/ATtinys supporting OC0A, e.g. ATtiny84, ATtiny85
#define IRSND_OCx IRSND_OC0B // OC0B on ATmegas/ATtinys supporting OC0B, e.g. ATtiny84, ATtiny85
</syntaxhighlight>

Standardwert:
<syntaxhighlight lang="c">
#define IRSND_OCx IRSND_OC2B
</syntaxhighlight>

Für die PIC- und STM32-µCs sind entsprechende Werte anzupassen, siehe Kommentare in [http://www.mikrocontroller.net/svnbrowser/irmp/irsndconfig.h?view=markup irsndconfig.h].

==== IRSND_USE_CALLBACK ====

Standardwert:
<syntaxhighlight lang="c">
#define IRSND_USE_CALLBACK 0 // flag: 0 = don't use callbacks, 1 = use callbacks, default is 0
</syntaxhighlight>

Wenn man Callbacks einschaltet, wird bei jeder Änderung des Signals (IR-Modulation ein/aus) eine Callback-Funktion aufgerufen. Dies kann zum Beispiel dafür verwendet werden, ein unmoduliertes Signal an einem weiteren Pin auszugeben.

Hier ein Beispiel:

<syntaxhighlight lang="c">
#define LED_PORT PORTD // LED at PD6
#define LED_DDR DDRD
#define LED_PIN 6

/*-----------------------------------------------------------------------------------------------------------------------
* Called (back) from IRSND module
* This example switches a LED (which is connected to Vcc)
*-----------------------------------------------------------------------------------------------------------------------
*/
void
led_callback (uint8_t on)
{
if (on)
{
LED_PORT &= ~(1 << LED_PIN);
}
else
{
LED_PORT |= (1 << LED_PIN);
}
}

int
main ()
{
...
LED_DDR |= (1 << LED_PIN); // LED pin to output
LED_PORT |= (1 << LED_PIN); // switch LED off (active low)
irsnd_init ();
irsnd_set_callback_ptr (led_callback);
sei ();
...
}

</syntaxhighlight>

=== Anwendung von IRSND ===

[[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] baut den zu sendenden Frame "on-the-fly" aus der IRMP-Datenstruktur wieder zusammen. Dazu zählen:

1. ID für verwendetes Protokoll
2. Adresse bzw. Herstellercode
3. Kommando

Mittels der Funktion

irsnd_send_data (IRMP_DATA * irmp_data_p)

kann man ein zu encodierendes Telegramm versenden. Der Return-Wert ist 1, wenn das Telegramm versendet werden kann, sonst 0. Im ersten Fall werden die Struct-Members

<syntaxhighlight lang="c">
irmp_data_p->protocol
irmp_data_p->address
irmp_data_p->command
irmp_data_p->flags
</syntaxhighlight>

ausgelesen und dann als Frame im jeweils gewünschten Protokoll gesendet.

irmp_data_p->flags gibt die Anzahl der Wiederholungen an, z.B.

irmp_data_p->flags = 0: keine Wiederholung
irmp_data_p->flags = 1: 1 Wiederholung
irmp_data_p->flags = 2: 2 Wiederholungen
usw.

'''Zu beachten: Es ist unbedingt darauf zu achten, dass irmp_data_p->flags vor dem Aufruf von irsnd_send_data() einen definierten Wert hat!'''

Hier ein Beispiel:

<syntaxhighlight lang="c">
IRMP_DATA irmp_data;

irmp_data.protocol = IRMP_NEC_PROTOCOL; // sende im NEC-Protokoll
irmp_data.address = 0x00FF; // verwende Adresse 0x00FF
irmp_data.command = 0x0001; // sende Kommando 0001
irmp_data.flags = 0; // keine Wiederholung!

(void) irsnd_send_data (&irmp_data, FALSE); // versende ohne Prüfung und ohne Warten
</syntaxhighlight>

Der Frame wird asynchron über die Interrupt-Routine irsnd_ISR() verschickt, so dass die Funktion irsnd_send_data() sofort zurückkommt.

Sind Wiederholungen angegeben, wird entweder der Frame nach einer Pause (protokollabhängig) neu ausgegeben oder ein protokollspezifischer Wiederholungsframe (z.B. für NEC) gesendet.

Wird erneut irsnd_send_data() aufgerufen, wartet diese, bis der vorhergenhende Frame vollständig verschickt wurde. Man kann aber auch selbst prüfen, ob [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] gerade "busy" ist oder nicht:

<syntaxhighlight lang="c">
while (irsnd_is_busy ())
{
; // selber warten oder was anderes tun...
}
(void) irsnd_send_data (&irmp_data, FALSE); // versende ohne Prüfung und ohne Warten
</syntaxhighlight>

Wird irsnd_send_data() mit dem 2. Argument TRUE aufgerufen, kommt diese Funktion erst zurück, wenn der Frame komplett ausgesendet wurde.

Im Beispiel-Source irsndmain.c findet man neben der Verwendung von irsnd_send_data() auch den [[AVR-GCC-Tutorial/Die_Timer_und_Zähler_des_AVR|Timer]]-Aufruf:

<syntaxhighlight lang="c">
ISR(TIMER1_COMPA_vect)
{
irsnd_ISR()) // call irsnd ISR
// call other timer interrupt routines...
}
</syntaxhighlight>

=== Paralleles Betreiben von IRMP und IRSND ===

Möchte man [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] und [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] parallel verwenden (also als Sender und Empfänger) schreibt man die ISR folgendermaßen:

<syntaxhighlight lang="c">
ISR(TIMER1_COMPA_vect)
{
if (! irsnd_ISR()) // call irsnd ISR
{ // if not busy...
irmp_ISR(); // call irmp ISR
}
// call other timer interrupt routines...
}
</syntaxhighlight>

Das heisst: Nur wenn irsnd_ISR() nichts zu tun hat, dann rufe die ISR des Empfängers auf. Damit ist der Empfänger solange abgeschaltet, während irsnd_ISR() noch Daten sendet. Die [[AVR-GCC-Tutorial/Die_Timer_und_Zähler_des_AVR|Timer]]-Initialisierungsroutine ist für [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] und [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] dann natürlich dieselbe.

Eine gemeinsame main-Funktion könnte dann zum Beispiel folgendermaßen aussehen:

<syntaxhighlight lang="c">
int
main (void)
{
IRMP_DATA irmp_data;

irmp_init(); // initialize irmp
irsnd_init(); // initialize irsnd
timer_init(); // initialize timer
sei (); // enable interrupts

for (;;)
{
if (irmp_get_data (&irmp_data))
{
irmp_data.flags = 0; // reset flags!
irsnd_send_data (&irmp_data);
}
}
}
</syntaxhighlight>

Die Funktion des obigen Sources ist offensichtlich: Ein empfangenes Telegramm wird nach vollständiger Decodierung wieder encodiert und dann wieder über die IR-Diode ausgesandt. Somit können dann zum Beispiel Signale "um die Ecke" oder streckenweise drahtgebunden übertragen werden.

Desweiteren könnte man auch Protokolle transformieren, zum Beispiel NEC-Telegramme in RC5 umwandeln, wenn man seine Original-RC5-FB zu seinem Philips-Gerät verlegt hat...

Der Rest bleibt der Phantasie des geneigten Lesers überlassen ;-)

Hier noch die möglichen Werte für irmp_data.protocol, siehe auch [http://www.mikrocontroller.net/svnbrowser/irmp/irmpprotocols.h?view=markup irmpprotocols.h]:

<syntaxhighlight lang="c">
#define IRMP_SIRCS_PROTOCOL 1 // Sony
#define IRMP_NEC_PROTOCOL 2 // NEC, Pioneer, JVC, Toshiba, NoName etc.
#define IRMP_SAMSUNG_PROTOCOL 3 // Samsung
#define IRMP_MATSUSHITA_PROTOCOL 4 // Matsushita
#define IRMP_KASEIKYO_PROTOCOL 5 // Kaseikyo (Panasonic etc)
#define IRMP_RECS80_PROTOCOL 6 // Philips, Thomson, Nordmende, Telefunken, Saba
#define IRMP_RC5_PROTOCOL 7 // Philips etc
#define IRMP_DENON_PROTOCOL 8 // Denon, Sharp
#define IRMP_RC6_PROTOCOL 9 // Philips etc
#define IRMP_SAMSUNG32_PROTOCOL 10 // Samsung32: no sync pulse at bit 16, length 32 instead of 37
#define IRMP_APPLE_PROTOCOL 11 // Apple, very similar to NEC
#define IRMP_RECS80EXT_PROTOCOL 12 // Philips, Technisat, Thomson, Nordmende, Telefunken, Saba
#define IRMP_NUBERT_PROTOCOL 13 // Nubert
#define IRMP_BANG_OLUFSEN_PROTOCOL 14 // Bang & Olufsen
#define IRMP_GRUNDIG_PROTOCOL 15 // Grundig
#define IRMP_NOKIA_PROTOCOL 16 // Nokia
#define IRMP_SIEMENS_PROTOCOL 17 // Siemens, e.g. Gigaset
#define IRMP_FDC_PROTOCOL 18 // FDC keyboard
#define IRMP_RCCAR_PROTOCOL 19 // RC Car
#define IRMP_JVC_PROTOCOL 20 // JVC (NEC with 16 bits)
#define IRMP_RC6A_PROTOCOL 21 // RC6A, e.g. Kathrein, XBOX
#define IRMP_NIKON_PROTOCOL 22 // Nikon
#define IRMP_RUWIDO_PROTOCOL 23 // Ruwido, e.g. T-Home Mediareceiver
#define IRMP_IR60_PROTOCOL 24 // IR60 (SDA2008)
#define IRMP_KATHREIN_PROTOCOL 25 // Kathrein
#define IRMP_NETBOX_PROTOCOL 26 // Netbox keyboard (bitserial)
#define IRMP_NEC16_PROTOCOL 27 // NEC with 16 bits (incl. sync)
#define IRMP_NEC42_PROTOCOL 28 // NEC with 42 bits
#define IRMP_LEGO_PROTOCOL 29 // LEGO Power Functions RC
#define IRMP_THOMSON_PROTOCOL 30 // Thomson
#define IRMP_BOSE_PROTOCOL 31 // BOSE
#define IRMP_A1TVBOX_PROTOCOL 32 // A1 TV Box
#define IRMP_ORTEK_PROTOCOL 33 // ORTEK - Hama
#define IRMP_TELEFUNKEN_PROTOCOL 34 // Telefunken (1560)
#define IRMP_ROOMBA_PROTOCOL 35 // iRobot Roomba vacuum cleaner
#define IRMP_RCMM32_PROTOCOL 36 // Fujitsu-Siemens (Activy remote control)
#define IRMP_RCMM24_PROTOCOL 37 // Fujitsu-Siemens (Activy keyboard)
#define IRMP_RCMM12_PROTOCOL 38 // Fujitsu-Siemens (Activy keyboard)
</syntaxhighlight>

Die Daten für die Adresse und das Kommando ermittelt man am besten über IRMP, siehe weiter oben ;-)

== IRSND unter Linux und Windows ==

=== Übersetzen von IRSND ===

[http://www.mikrocontroller.net/svnbrowser/irmp/irsnd.c?view=markup irsnd.c] lässt sich auch unter Linux direkt kompilieren, um damit Telegramme in Form von IRMP-Scan-Dateien zu erzeugen. Das geht folgendermaßen:

make -f makefile.unx

=== Aufruf von IRSND ===

Der Aufruf geht dann folgendermaßen:

./irsnd protocol-number hex-address hex-command [repeat] > filename.txt

also zum Beispiel für das NEC-Protokoll, Adresse 0x00FF, Kommando 0x0001

./irsnd 2 00FF 0001 > nec.txt # irsnd ausführen

=== IRSND unter Windows ===

[[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] kann man auch unter Windows nutzen, nämlich folgendermaßen:

* Eingabeaufforderung starten
* In das Verzeichnis von irsnd wechseln
* Aufruf von:

irsnd.exe 2 00FF 0001 > nec.txt

Nun kann man direkt mit [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] anschließend testen, ob das erzeugte Telegramm auch korrekt ist:

./irmp < nec.txt

bzw. unter Windows:

irmp.exe < nec.txt

Das Ganze geht auch ohne Zwischendatei, nämlich:

./irsnd 2 00FF 0001 | ./irmp

bzw. unter Windows:

irsnd.exe 2 00FF 0001 | irmp.exe

[[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] gibt dann als Ergebnis folgendes aus:

11111111000000001000000001111111 p = 2, a = 0x00ff, c = 0x0001, f = 0x00

[[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] konnte also aus dem von [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] generierten Frame wieder das Protokoll 2, Adresse 0x00FF und Kommando 0x0001 decodieren.

Bitte beachten: Je nach benutztem Protokoll sind die Bit-Breiten der Adressen bzw. Kommandos verschieden, siehe obige Tabelle [http://www.mikrocontroller.net/articles/IRMP#Protokolle].

Man kann also nicht mit jedem IR-Protokoll komplett 16-Bit breite Adressen oder Kommandos transparent übertragen.

----

= Anhang =

== Die IR-Protokolle im Detail ==

=== Pulse Distance Protokolle ===

[[Datei:Pulse-Distance.png|miniatur|Pulse Distance Coding]]

==== NEC + extended NEC ====

{| class="wikitable"
! '''[[IRMP#NEC-Protokoll|NEC + extended NEC]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 36 kHz / 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 32 Daten-Bits + 1 Stop-Bit
|-
| Daten NEC || 8 Adress-Bits + 8 invertierte Adress-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits
|-
| Daten ext. NEC || 16 Adress-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits
|-
| Start-Bit || 9000µs Puls, 4500µs Pause
|-
| 0-Bit || 560µs Puls, 560µs Pause
|-
| 1-Bit || 560µs Puls, 1690µs Pause
|-
| Stop-Bit || 560µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || 9000µs Puls, 2250µs Pause, 560µs Puls, ~100ms Pause
|-
| Bit-Order || LSB first
|-
|}

==== JVC ====

{| class="wikitable"
! '''[[IRMP#NEC16-Protokoll (JVC)|JVC]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 16 Daten-Bits + 1 Stop-Bit
|-
| Daten || 4 Adress-Bits + 12 Kommando-Bits
|-
| Start-Bit || 9000µs Puls, 4500µs Pause, 6000µs Pause bei Tasten-Wiederholung
|-
| 0-Bit || 560µs Puls, 560µs Pause
|-
| 1-Bit || 560µs Puls, 1690µs Pause
|-
| Stop-Bit || 560µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || Wiederholung nach Pause von 25ms
|-
| Bit-Order || LSB first
|-
|}

==== NEC16 ====

{| class="wikitable"
! '''NEC16''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 8 Adress-Bits + 1 Sync-Bit + 8 Daten-Bits + 1 Stop-Bit
|-
| Start-Bit || 9000µs Puls, 4500µs Pause
|-
| Sync-Bit || 560µs Puls, 4500µs Pause
|-
| 0-Bit || 560µs Puls, 560µs Pause
|-
| 1-Bit || 560µs Puls, 1690µs Pause
|-
| Stop-Bit || 560µs Puls
|-
| Wiederholung || keine/eine/zwei nach 25ms?
|-
| Tasten-Wiederholung || Wiederholung nach Pause von 25ms?
|-
| Bit-Order || LSB first
|-
|}

==== NEC42 ====

{| class="wikitable"
! '''NEC42''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 42 Daten-Bits + 1 Stop-Bit
|-
| Daten || 13 Adress-Bits + 13 invertierte Adress-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits
|-
| Start-Bit || 9000µs Puls, 4500µs Pause
|-
| 0-Bit || 560µs Puls, 560µs Pause
|-
| 1-Bit || 560µs Puls, 1690µs Pause
|-
| Stop-Bit || 560µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || nach 110ms (ab Start-Bit), 9000µs Puls, 2250µs Pause, 560µs Puls
|-
| Bit-Order || LSB first
|-
|}

==== LGAIR ====

{| class="wikitable"
! '''[[IRMP#LGAIR-Protokoll|LGAIR]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 28 Daten-Bits + 1 Stop-Bit
|-
| Daten || 8 Adress-Bits + 16 Kommando-Bits + 4 Checksum-Bits
|-
| Start-Bit || 9000µs Puls, 4500µs Pause (identisch mit [[IRMP#NEC_.2B_extended_NEC|NEC]])
|-
| 0-Bit || 560µs Puls, 560µs Pause (identisch mit [[IRMP#NEC_.2B_extended_NEC|NEC]])
|-
| 1-Bit || 560µs Puls, 1690µs Pause (identisch mit [[IRMP#NEC_.2B_extended_NEC|NEC]])
|-
| Stop-Bit || 560µs Puls (identisch mit [[IRMP#NEC_.2B_extended_NEC|NEC]])
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || unbekannt
|-
| Bit-Order || MSB first ('''abweichend''' zu [[IRMP#NEC_.2B_extended_NEC|NEC]])
|-
|}

==== SAMSUNG ====

{| class="wikitable"
! '''[[IRMP#SAMSUNG-Protokoll|SAMSUNG]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || ?? kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 16 Daten(1)-Bits + 1 Sync-Bit + 20 Daten(2)-Bits + 1 Stop-Bit
|-
| Daten(1) || 16 Adress-Bits
|-
| Daten(2) || 4 ID-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits
|-
| Start-Bit || 4500µs Puls, 4500µs Pause
|-
| 0-Bit || 550µs Puls, 550µs Pause
|-
| 1-Bit || 550µs Puls, 1650µs Pause
|-
| Sync-Bit || 550µs Puls, 4500µs Pause
|-
| Stop-Bit || 550µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || LSB first
|-
|}

==== SAMSUNG32 ====

{| class="wikitable"
! '''SAMSUNG32''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 32 Daten-Bits + 1 Stop-Bit
|-
| Daten || 16 Adress-Bits + 16 Kommando-Bits
|-
| Start-Bit || 4500µs Puls, 4500µs Pause
|-
| 0-Bit || 550µs Puls, 550µs Pause
|-
| 1-Bit || 550µs Puls, 1650µs Pause
|-
| Stop-Bit || 550µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || dritter, fünfter, siebter usw. identischer Frame
|-
| Bit-Order || LSB first
|-
|}

==== MATSUSHITA ====

{| class="wikitable"
! '''[[IRMP#MATSUHITA-Protokoll|MATSUSHITA]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 36 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 24 Daten-Bits + 1 Stop-Bit
|-
| Daten || 6 Hersteller-Bits + 6 Kommando-Bits + 12 Adress-Bits
|-
| Start-Bit || 3488µs Puls, 3488µs Pause
|-
| 0-Bit || 872µs Puls, 872µs Pause
|-
| 1-Bit || 872µs Puls, 2616µs Pause
|-
| Stop-Bit || 872µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames nach 40ms Pause
|-
| Bit-Order || LSB first?
|-
|}

==== KASEIKYO ====

{| class="wikitable"
! '''[[IRMP#KASEIKYO-Protokoll (auch "Japan-Protokoll")|KASEIKYO]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 48 Daten-Bits + 1 Stop-Bit
|-
| Daten || 16 Hersteller-Bits + 4 Parity-Bits + 4 Genre1-Bits + 4 Genre2-Bits + 10 Kommando-Bits + 2 ID-Bits + 8 Parity-Bits
|-
| Start-Bit || 3380µs Puls, 1690µs Pause
|-
| 0-Bit || 423µs Puls, 423µs Pause
|-
| 1-Bit || 423µs Puls, 1269µs Pause
|-
| Stop-Bit || 423µs Puls
|-
| Wiederholung || einmalig nach 74ms Pause
|-
| Tasten-Wiederholung || N-fache Wiederholung des 1. Original-Frames nach ca. 80ms Pause
|-
| Bit-Order || LSB first?
|-
|}

==== RECS80 ====

{| class="wikitable"
! '''[[IRMP#RECS80- und RECS80-Extended-Protokoll|RECS80]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bits + 10 Daten-Bits + 1 Stop-Bit
|-
| Daten || 1 Toggle-Bit + 3 Adress-Bits + 6 Kommando-Bits
|-
| Start-Bit || 158µs Puls, 7432µs Pause
|-
| 0-Bit || 158µs Puls, 4902µs Pause
|-
| 1-Bit || 158µs Puls, 7432µs Pause
|-
| Stop-Bit || 158µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || MSB first
|-
|}

==== RECS80EXT ====

{| class="wikitable"
! '''[[IRMP#RECS80- und RECS80-Extended-Protokoll|RECS80EXT]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 2 Start-Bits + 11 Daten-Bits + 1 Stop-Bit
|-
| Daten || 1 Toggle-Bit + 4 Adress-Bits + 6 Kommando-Bits
|-
| Start-Bit || 158µs Puls, 3637µs Pause
|-
| 0-Bit || 158µs Puls, 4902µs Pause
|-
| 1-Bit || 158µs Puls, 7432µs Pause
|-
| Stop-Bit || 158µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || MSB first
|-
|}

==== DENON ====

{| class="wikitable"
! '''[[IRMP#Denon-Protokoll|DENON]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz (in der Praxis, lt. Dokumentation: 32 kHz)
|-
| Kodierung || Pulse Distance
|-
| Frame || 0 Start-Bits + 15 Daten-Bits + 1 Stop-Bit
|-
| Daten || 5 Address-Bits + 10 Kommando-Bits
|-
| Kommando || 6 Datenbits + 2 Extension Bits + 2 Data Construction Bits (normal: 00, invertiert: 11)
|-
| Start-Bit || kein Start-Bit
|-
| 0-Bit || 310µs Puls, 745µs Pause (in der Praxis, lt. Doku: 275µs Puls, 775µs Pause)
|-
| 1-Bit || 310µs Puls, 1780µs Pause (in der Praxis, lt. Doku: 275µs Puls, 1900µs Pause)
|-
| Stop-Bit || 310µs Puls (310µs Puls, 745µs Pause (in der Praxis, lt. Doku: 275µs Puls)
|-
| Wiederholung || Nach 65ms Wiederholung des Frames mit invertieren Kommando-Bits (Data Construction Bits = 11)
|-
| Tasten-Wiederholung || N-fache Wiederholung der beiden Original-Frames nach 65ms
|-
| Bit-Order || MSB first
|-
|}

==== APPLE ====

{| class="wikitable"
! '''APPLE''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 32 Daten-Bits + 1 Stop-Bit
|-
| Daten || 16 Adress-Bits + 11100000 + 8 Kommando-Bits
|-
| Start-Bit || siehe [[IRMP#NEC_+_extended_NEC|NEC]]
|-
| 0-Bit || siehe [[IRMP#NEC_+_extended_NEC|NEC]]
|-
| 1-Bit || siehe [[IRMP#NEC_+_extended_NEC|NEC]]
|-
| Stop-Bit || siehe [[IRMP#NEC_+_extended_NEC|NEC]]
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || LSB first
|-
|}

==== BOSE ====

{| class="wikitable"
! '''BOSE''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 16 Daten-Bits + 1 Stop-Bit
|-
| Daten || 0 Adress-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits
|-
| Start-Bit || 1060µs Puls, 1425µs Pause
|-
| 0-Bit || 550µs Puls, 437µs Pause
|-
| 1-Bit || 550µs Puls, 1425µs Pause
|-
| Stop-Bit || 550µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || noch ungeklärt
|-
| Bit-Order || LSB first
|-
|}

==== B&O ====

{| class="wikitable"
! '''[[IRMP#Bang & Olufsen|B&O]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 455 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 4 Start-Bits + 16 Daten-Bits + 1 Trailer-Bit + 1 Stop-Bit
|-
| Daten || 0 Adress-Bits + 16 Kommando-Bits
|-
| Start-Bit 1 || 200µs Puls, 2925µs Pause
|-
| Start-Bit 2 || 200µs Puls, 2925µs Pause
|-
| Start-Bit 3 || 200µs Puls, 15425µs Pause
|-
| Start-Bit 4 || 200µs Puls, 2925µs Pause
|-
| 0-Bit || 200µs Puls, 2925µs Pause
|-
| 1-Bit || 200µs Puls, 9175µs Pause
|-
| R-Bit || 200µs Puls, 6050µs Pause, wiederholt das letzte Bit (repetition)
|-
| Trailer-Bit || 200µs Puls, 12300µs Pause
|-
| Stop-Bit || 200µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || MSB first
|-
|}

==== FDC ====

{| class="wikitable"
! '''FDC''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 40 Daten-Bits + 1 Stop-Bit
|-
| Daten || 8 Adress-Bits + 12 x 0-Bits + 4 Press/Release-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits
|-
| Start-Bit || 2085µs Puls, 966µs Pause
|-
| 0-Bit || 300µs Puls, 220µs Pause
|-
| 1-Bit || 300µs Puls, 715µs Pause
|-
| Stop-Bit || 300µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Drücken || Press/Release-Bits = 0000
|-
| Tasten-Loslassen || Press/Release-Bits = 1111
|-
| Tasten-Wiederholung || Wiederholung nach Pause von 60ms
|-
| Bit-Order || LSB first
|-
|}

==== NIKON ====

{| class="wikitable"
! '''NIKON''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 2 Daten-Bits + 1 Stop-Bit
|-
| Daten || 2 Kommando-Bits
|-
| Start-Bit || 2200µs Puls, 27100µs Pause
|-
| 0-Bit || 500µs Puls, 1500µs Pause
|-
| 1-Bit || 500µs Puls, 3500µs Pause
|-
| Stop-Bit || 500µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || unbekannt
|-
| Bit-Order || MSB first
|-
|}

==== KATHREIN ====

{| class="wikitable"
! '''KATHREIN''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 11 Daten-Bits + 1 Stop-Bit
|-
| Daten || 4 Adress-Bits + 7 Kommando-Bits
|-
| Start-Bit || 210µs Puls, 6218µs Pause
|-
| 0-Bit || 210µs Puls, 1400µs Pause
|-
| 1-Bit || 210µs Puls, 3000µs Pause
|-
| Stop-Bit || 210µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || nach 35ms?
|-
| Bit-Order || MSB first
|-
|}

==== LEGO ====

{| class="wikitable"
! '''[[IRMP#LEGO Power Functions RC|LEGO]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 16 Daten-Bits + 1 Stop-Bit
|-
| Daten || 16 Kommando-Bits
|-
| Start-Bit || 158µs Puls, 1026µs Pause
|-
| 0-Bit || 158µs Puls, 263µs Pause
|-
| 1-Bit || 158µs Puls, 553µs Pause
|-
| Stop-Bit || 158µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || unbekannt
|-
| Bit-Order || MSB first
|-
|}

==== THOMSON ====

{| class="wikitable"
! '''THOMSON''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 33 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame || 0 Start-Bits + 12 Daten-Bits + 1 Stop-Bit
|-
| Daten || 4 Adress-Bits + 1 Toggle-Bit + 7 Kommando-Bits
|-
| 0-Bit || 550µs Puls, 2000µs Pause
|-
| 1-Bit || 550µs Puls, 4500µs Pause
|-
| Stop-Bit || 550µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || Framewiederholung nach 35ms
|-
| Bit-Order || vermutlich MSB first
|-
|}

==== TELEFUNKEN ====

{| class="wikitable"
! '''TELEFUNKEN''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 15 Daten-Bits + 1 Stop-Bit
|-
| Daten || 0 Adress-Bits + 15 Kommando-Bits
|-
| Start-Bit || 600µs Puls, 1500µs Pause
|-
| 0-Bit || 600µs Puls, 600µs Pause
|-
| 1-Bit || 600µs Puls, 1500µs Pause
|-
| Stop-Bit || 600µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || unbekannt
|-
| Bit-Order || vermutlich MSB first
|-
|}

==== RCCAR ====

{| class="wikitable"
! '''RCCAR''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance
|-
| Frame || 1 Start-Bit + 13 Daten-Bits + 1 Stop-Bit
|-
| Daten || 13 Kommando-Bits
|-
| Start-Bit || 2000µs Puls, 2000µs Pause
|-
| 0-Bit || 600µs Puls, 900µs Pause
|-
| 1-Bit || 600µs Puls, 450µs Pause
|-
| Stop-Bit || 600µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || nach 40ms?
|-
| Bit-Order || LSB first
|-
|}

==== RCMM ====

{| class="wikitable"
! '''[[IRMP#RCMM-Protokoll|RCMM]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 36 kHz
|-
| Kodierung || Pulse Distance
|-
| Frame RCMM32 || 1 Start-Bit + 32 Daten-Bits + 1 Stop-Bit
|-
| Frame RCMM24 || 1 Start-Bit + 24 Daten-Bits + 1 Stop-Bit
|-
| Frame RCMM12 || 1 Start-Bit + 12 Daten-Bits + 1 Stop-Bit
|-
| Daten RCMM32 || 16 Adress-Bits (= 4 Mode-Bits + 12 Device-Bits) + 1 Toggle-Bit + 15 Kommando-Bits
|-
| Daten RCMM24 || 16 Adress-Bits (= 4 Mode-Bits + 12 Device-Bits) + 1 Toggle-Bit + 7 Kommando-Bits
|-
| Daten RCMM12 || 4 Adress-Bits (= 2 Mode-Bits + 2 Device-Bits) + 8 Kommando-Bits
|-
| Start-Bit || 500µs Puls, 220µs Pause
|-
| 00-Bits || 230µs Puls, 220µs Pause
|-
| 01-Bits || 230µs Puls, 380µs Pause
|-
| 10-Bits || 230µs Puls, 550µs Pause
|-
| 11-Bits || 230µs Puls, 720µs Pause
|-
| Stop-Bit || 230µs Puls
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || nach 80ms
|-
| Bit-Order || LSB first
|-
|}

=== Pulse Width Protokolle ===

[[Datei:Pulse-Width.png|miniatur|Pulse Width Coding]]

==== SIRCS ====

{| class="wikitable"
! '''[[IRMP#SIRCS-Protokoll|SIRCS]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
|Frequenz ||40 kHz
|-
| Kodierung || Pulse Width
|-
| Frame || 1 Start-Bit + 12-20 Daten-Bits, kein Stop-Bit
|-
| Daten || 7 Kommando-Bits + 5 Adress-Bits + bis zu 8 zusätzliche Bits
|-
| Start-Bit || 2400µs Puls, 600µs Pause
|-
| 0-Bit || 600µs Puls, 600µs Pause
|-
| 1-Bit || 1200µs Puls, 600µs Pause
|-
| Wiederholung || zweimalig nach ca. 25ms, d.h. 2. und 3. Frame
|-
| Tasten-Wiederholung || ab dem 4. identischen Frame, Abstand ca. 25ms
|-
| Bit-Order || LSB first
|-
|}

=== Pulse Distance Width Protokolle ===

[[Datei:Pulse-Distance-Width.png|miniatur|Pulse Distance Width Coding]]

==== NUBERT ====

{| class="wikitable"
! '''NUBERT''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 36 kHz?
|-
| Kodierung || Pulse Distance Width
|-
| Frame || 1 Start-Bit + 10 Daten-Bits + 1 Stop-Bit
|-
| Daten || 0 Adress-Bits + 10 Kommando-Bits ?
|-
| Start-Bit || 1340µs Puls, 340µs Pause
|-
| 0-Bit || 500µs Puls, 1300µs Pause
|-
| 1-Bit || 1340µs Puls, 340µs Pause
|-
| Stop-Bit || 500µs Puls
|-
| Wiederholung || einmalig nach 35ms
|-
| Tasten-Wiederholung || dritter, fünfter, siebter usw. identischer Frame
|-
| Bit-Order || MSB first?
|-
|}

==== SPEAKER ====

{| class="wikitable"
! '''SPEAKER''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance Width
|-
| Frame || 1 Start-Bit + 10 Daten-Bits + 1 Stop-Bit
|-
| Daten || 0 Adress-Bits + 10 Kommando-Bits ?
|-
| Start-Bit || 440µs Puls, 1250µs Pause
|-
| 0-Bit || 440µs Puls, 1250µs Pause
|-
| 1-Bit || 1250µs Puls, 440µs Pause
|-
| Stop-Bit || 440µs Puls
|-
| Wiederholung || einmalig nach ca. 38ms
|-
| Tasten-Wiederholung || dritter, fünfter, siebter usw. identischer Frame
|-
| Bit-Order || MSB first?
|-
|}

==== ROOMBA ====

{| class="wikitable"
! '''ROOMBA''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Distance Width
|-
| Frame || 1 Start-Bit + 7 Daten-Bits + 0 Stop-Bit
|-
| Daten || 0 Adress-Bits + 7 Kommando-Bits
|-
| Start-Bit || 2790µs Puls, 930µs Pause
|-
| 0-Bit || 930µs Puls, 2790µs Pause
|-
| 1-Bit || 2790µs Puls, 930µs Pause
|-
| Stop-Bit || kein Stop-Bit
|-
| Wiederholung || dreimalig nach jeweils 18ms?
|-
| Tasten-Wiederholung || noch unbekannt
|-
| Bit-Order || MSB first
|-
|}

=== Biphase Protokolle ===

[[Datei:Biphase-Coding.png|miniatur|Biphase Coding]]

==== RC5 + RC5X ====

{| class="wikitable"
! '''[[IRMP#RC5- und RC5x-Protokoll|RC5 + RC5X]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 36 kHz
|-
| Kodierung || Biphase (Manchester)
|-
| Frame RC5 || 2 Start-Bits + 12 Daten-Bits + 0 Stop-Bits
|-
| Daten RC5 || 1 Toggle-Bit + 5 Adress-Bits + 6 Kommando-Bits
|-
| Frame RC5X || 1 Start-Bit + 13 Daten-Bits + 0 Stop-Bit
|-
| Daten RC5X || 1 invertiertes Kommando-Bit + 1 Toggle-Bit + 5 Adress-Bits + 6 Kommando-Bits
|-
| Start-Bit || 889µs Pause, 889µs Puls
|-
| 0-Bit || 889µs Puls, 889µs Pause
|-
| 1-Bit || 889µs Pause, 889µs Puls
|-
| Stop-Bit || kein Stop-Bit
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || MSB first
|-
|}

==== RC6 + RC6A ====

{| class="wikitable"
! '''[[IRMP#RC6 und RC6A-Protokoll|RC6 + RC6A]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 36 kHz
|-
| Kodierung || Biphase (Manchester)
|-
| Frame RC6 || 1 Start-Bit + 1 Bit "1" + 3 Mode-Bits (000) + 1 Toggle-Bit + 16 Daten-Bits + 2666µs pause
|-
| Frame RC6A || 1 Start-Bit + 1 Bit "1" + 3 Mode-Bits (110) + 1 Toggle-Bit + 31 Daten-Bits + 2666µs pause
|-
| Daten RC6 || 8 Adress-Bits + 8 Kommando Bits
|-
| Daten RC6A || "1" + 14 Hersteller-Bits + 8 System-Bits + 8 Kommando-Bits
|-
| Daten RC6A Pace (Sky) || "1" + 3 Mode-Bits ("110") + 1 Toggle-Bit(UNUSED "0") + 16 Bit + 1 Toggle(!) + 15 Kommando-Bits
|-
| Start-Bit || 2666µs Puls, 889µs Pause
|-
| Toggle 0-Bit || 889µs Pause, 889µs Puls
|-
| Toggle 1-Bit || 889µs Puls, 889µs Pause
|-
| 0-Bit || 444µs Pause, 444µs Puls
|-
| 1-Bit || 444µs Puls, 444µs Pause
|-
| Stop-Bit || kein Stop-Bit
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms
|-
| Bit-Order || MSB first
|-
|}

==== GRUNDIG + NOKIA ====

{| class="wikitable"
! '''[[IRMP#Grundig-Protokoll|GRUNDIG + NOKIA]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz (?)
|-
| Kodierung || Biphase (Manchester)
|-
| Frame-Paket || 1 Start-Frame + 19,968ms Pause + N Info-Frames + 117,76ms Pause + 1 Stop-Frame
|-
| Start-Frame || 1 Pre-Bit + 1 Start-Bit + 9 Daten-Bits (alle 1) + 0 Stop-Bits
|-
| Info-Frame || 1 Pre-Bit + 1 Start-Bit + 9 Daten-Bits + 0 Stop-Bits
|-
| Stop-Frame || 1 Pre-Bit + 1 Start-Bit + 9 Daten-Bits (alle 1) + 0 Stop-Bits
|-
| Daten Grundig || 9 Kommando-Bits + 0 Adress-Bits
|-
| Daten Nokia || 8 Kommando-Bits + 8 Adress-Bits
|-
| Pre-Bit || 528µs Puls, 2639µs Pause
|-
| Start-Bit || 528µs Puls, 528µs Pause
|-
| 0-Bit || 528µs Pause, 528µs Puls
|-
| 1-Bit || 528µs Puls, 528µs Pause
|-
| Stop-Bit || kein Stop-Bit
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Info-Frames mit einem Pausenabstand von 117,76ms
|-
| Bit-Order || LSB first
|-
|}

==== IR60 (SDA2008) ====

{| class="wikitable"
! '''[[IRMP#IR60 (SDA2008 bzw. MC14497P)|IR60 (SDA2008)]]''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 30 kHz
|-
| Kodierung || Biphase (Manchester)
|-
| Start Frame || 1 Start-Bit + 101111 + 0 Stop-Bits + 22ms Pause
|-
| Daten Frame || 1 Start-Bit + 7 Daten-Bits + 0 Stop-Bits
|-
| Daten || 0 Adress-Bits + 7 Kommando-Bits
|-
| Start-Bit || 528µs Puls, 2639µs Pause
|-
| 0-Bit || 528µs Pause, 528µs Puls
|-
| 1-Bit || 528µs Puls, 528µs Pause
|-
| Stop-Bit || kein Stop-Bit
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || N-fache Wiederholung des Info-Frames mit einem Pausenabstand von 117,76ms
|-
| Bit-Order || LSB first
|-
|}

==== SIEMENS + RUWIDO ====

{| class="wikitable"
! '''SIEMENS + RUWIDO''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 36 kHz? (Merlin-Tastatur mit Ruwido-Protokoll: 56 kHz)
|-
| Kodierung || Biphase (Manchester)
|-
| Frame Siemens || 1 Start-Bit + 22 Daten-Bits + 0 Stop-Bits
|-
| Frame Ruwido || 1 Start-Bit + 17 Daten-Bits + 0 Stop-Bits
|-
| Daten Siemens || 11 Adress-Bits + 10 Kommando-Bits + 1 invertiertes Bit (letztes Bit davor nochmal invertiert)
|-
| Daten Ruwido || 9 Adress-Bits + 7 Kommando-Bits + 1 invertiertes Bit (letztes Bit davor nochmal invertiert)
|-
| Start-Bit || 275µs Puls, 275µs Pause
|-
| 0-Bit || 275µs Pause, 275µs Puls
|-
| 1-Bit || 275µs Puls, 275µs Pause
|-
| Stop-Bit || kein Stop-Bit
|-
| Wiederholung || 1-malige Wiederholung mit gesetztem Repeat-Bit (?)
|-
| Tasten-Wiederholung || N-fache Wiederholung des Original-Frames innerhalb von 100ms (?)
|-
| Bit-Order || MSB first
|-
|}

==== A1TVBOX ====

{| class="wikitable"
! '''A1TVBOX''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Biphase (Manchester) asymmetrisch
|-
| Frame || 2 Start-Bits + 16 Daten-Bits + 0 Stop-Bits
|-
| Daten || 8 Adress-Bits + 8 Kommando-Bits
|-
| Start-Bits || "10", also 250µs Puls, 150µs + 150µs Pause, 250µs Puls
|-
| 0-Bit || 150µs Pause, 250µs Puls
|-
| 1-Bit || 250µs Puls, 150µs Pause
|-
| Stop-Bit || kein Stop-Bit
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || unbekannt
|-
| Bit-Order || MSB first
|-
|}

==== ORTEK ====

{| class="wikitable"
! '''ORTEK''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Biphase (Manchester) symmetrisch
|-
| Frame || 2 Start-Bits + 18 Daten-Bits + 0 Stop-Bits
|-
| Daten || 6 Adress-Bits + 2 Spezial-Bits + 6 Kommando-Bits + 4 Spezial-Bits
|-
| Start-Bit || 2000µs Puls, 1000µs Pause
|-
| 0-Bit || 500µs Pause, 500µs Puls
|-
| 1-Bit || 500µs Puls, 500µs Pause
|-
| Stop-Bit || kein Stop-Bit
|-
| Wiederholung || 2 zusätzliche Frames mit gesetzten Spezial-Bits
|-
| Tasten-Wiederholung || N-fache Wiederholung des 2. Frames
|-
| Bit-Order || MSB first
|-
|}

=== Pulse Position Protokolle ===

==== NETBOX ====

{| class="wikitable"
! '''NETBOX''' || Wert
|-
|style="width: 15em"|
|style="width: 50em"|
|-
| Frequenz || 38 kHz?
|-
| Kodierung || Pulse Position
|-
| Frame || 1 Start-Bit + 16 Daten-Bits, kein Stop-Bit
|-
| Daten || 3 Adress-Bits + 13 Kommando-Bits
|-
| Start-Bit || 2400µs Puls, 800µs Pause
|-
| Bitlänge || 800µs
|-
| Wiederholung || keine
|-
| Tasten-Wiederholung || Abstand ca. 35ms?
|-
| Bit-Order || LSB first
|-
|}

== Software-Historie IRMP ==

Änderungen IRMP:

Version 2.5.3:

* 05.06.2014: '''Neues Protokoll''': [[IRMP#LGAIR|LGAIR]]

Version 2.5.0:

* 30.05.2014: '''Neues Protokoll''': [[IRMP#SPEAKER|SPEAKER]]

Version 2.4.1:

* 30.05.2014: Timings für [[IRMP#SAMSUNG|SAMSUNG]]-Protokolle optimiert

Version 2.4.0:

* 20.02.2014: Fehlerhaftes Decodieren des [[IRMP#SIEMENS_+_RUWIDO|SIEMENS]]-Protokolls korrigiert
* 19.02.2014: '''Neue Protokolle''': [[IRMP#RCMM|RCMM32, RCMM24 und RCMM12]]
* 17.09.2014: Timing für [[IRMP#ROOMBA|ROOMBA]] verbessert

Ältere Versionen:

* 09.04.2013: '''Neues Protokoll''': [[IRMP#ROOMBA|ROOMBA]] (nur im SVN!)
* 09.04.2013: Verbesserte Frame-Erkennung für [[IRMP#ORTEK|ORTEK (Hama)]]
* 19.03.2013: '''Neues Protokoll''': [[IRMP#ORTEK|ORTEK (Hama)]]
* 19.03.2013: '''Neues Protokoll''': [[IRMP#TELEFUNKEN|TELEFUNKEN]]
* 12.03.2013: Geänderte Timing-Toleranzen für [[IRMP#RECS80|RECS80]]- und [[IRMP#RECS80EXT|RECS80EXT]]-Protokoll
* 21.01.2013: Korrekturen Erkennung des Wiederholungsframes beim [[IRMP#DENON|DENON]]-Protokoll
* 17.01.2013: Korrekturen Frame-Erkennung beim [[IRMP#DENON|DENON]]-Protokoll
* 11.12.2012: '''Neues Protokoll''': [[IRMP#A1TVBOX|A1TVBOX]]
* 07.12.2012: Verbesserte Erkennung von [[IRMP#DENON|DENON]]-Wiederholungsframes
* 19.11.2012: Portierung auf Stellaris LM4F120 Launchpad von TI (ARM Cortex M4)
* 06.11.2012: Korrektur [[IRMP#DENON|DENON]]-Frame-Erkennung
* 26.10.2012: Einige Timer-Korrekturen, Anpassungen an Arduino
* 11.07.2012: '''Neues Protokoll''': [[IRMP#BOSE|BOSE]]
* 18.06.2012: Unterstützung für ATtiny87/167 hinzugefügt
* 05.06.2012: Kleinere Korrekturen Portierung auf ARM STM32
* 05.06.2012: Include-Korrektur in [http://www.mikrocontroller.net/svnbrowser/irmp/irmpextlog.c?view=markup irmpextlog.c]
* 05.06.2012: Bugfix, wenn nur [[IRMP#NEC_+_extended_NEC|NEC]] und [[IRMP#NEC42|NEC42]] aktiviert
* 23.05.2012: Portierung auf ARM STM32
* 23.05.2012: Bugfix Frame-Erkennung beim [[IRMP#DENON|DENON]]-Protokoll
* 27.02.2012: Bug in IR60-Decoder behoben
* 27.02.2012: Bug in CRC-Berechnung von [[IRMP#KASEIKYO|KASEIKYO]]-Frames behoben
* 27.02.2012: Portierung auf C18 Compiler für PIC-Mikroprozessoren
* 13.02.2012: Bugfix: oberstes Bit in Adresse falsch bei [[IRMP#NEC_+_extended_NEC|NEC]]-Protokoll, wenn auch [[IRMP#NEC42|NEC42]]-Protokoll eingeschaltet ist.
* 13.02.2012: Timing von [[IRMP#SAMSUNG|SAMSUNG]]- und [[IRMP#SAMSUNG32|SAMSUNG32]]-Protokoll korrigiert
* 13.02.2012: [[IRMP#KASEIKYO|KASEIKYO]]: Genre2-Bits werden nun im oberen Nibble von flags gespeichert.
* 20.09.2011: '''Neues Protokoll''': [[IRMP#KATHREIN|KATHREIN]]
* 20.09.2011: '''Neues Protokoll''': [[IRMP#SIEMENS_+_RUWIDO|RUWIDO]]
* 20.09.2011: '''Neues Protokoll''': [[IRMP#THOMSON|THOMSON]]
* 20.09.2011: '''Neues Protokoll''': [[IRMP#IR60 (SDA2008)|IR60 (SDA2008)]]
* 20.09.2011: '''Neues Protokoll''': [[IRMP#LEGO|LEGO]]
* 20.09.2011: '''Neues Protokoll''': [[IRMP#NEC16|NEC16]]
* 20.09.2011: '''Neues Protokoll''': [[IRMP#NEC42|NEC42]]
* 20.09.2011: '''Neues Protokoll''': [[IRMP#NETBOX|NETBOX]]
* 20.09.2011: Portierung auf ATtiny84 und ATtiny85
* 20.09.2011: Verbesserung von Tastenwiederholungen bei [[IRMP#RC5_+_RC5X|RC5]]
* 20.09.2011: Verbessertes Decodieren von [[IRMP#Biphase|Biphase]]-Protokollen
* 20.09.2011: Korrekturen am [[IRMP#RECS80|RECS80]]-Decoder
* 20.09.2011: Korrekturen beim Erkennen von zusätzlichen Bits im SIRCS-Protocol
* 18.01.2011: Korrekturen für [[IRMP#SIEMENS_+_RUWIDO|SIEMENS]]-Protokoll
* 18.01.2011: '''Neues Protokoll''': [[IRMP#NIKON|NIKON]]
* 18.01.2011: Speichern der zusätzlichen Bits (>12) im [[IRMP#SIRCS|SIRCS]]-Protokoll in der Adresse
* 18.01.2011: Timing-Korrekturen für [[IRMP#DENON|DENON]]-Protokoll

* 04.09.2010: Bugfix für F_INTERRUPTS >= 16000

* 02.09.2010: '''Neues Protokoll''': [[IRMP#RC6_+_RC6A|RC6A]]

* 29.08.2010: '''Neues Protokoll''': [[IRMP#JVC|JVC]]
* 29.08.2010: [[IRMP#KASEIKYO|KASEIKYO]]-Protokoll: Berücksichtigung der Genre-Bits. '''ACHTUNG: dadurch neue Command-Codes!'''
* 29.08.2010: [[IRMP#KASEIKYO|KASEIKYO]]-Protokoll: Verbesserte Behandlung von Wiederholungs-Frames
* 29.08.2010: Verbesserte Unterstützung des [[IRMP#APPLE|APPLE]]-Protokolls. '''ACHTUNG: dadurch neue Adress-Codes!'''

* 01.07.2010: Bugfix: Einführen eines Timeouts für [[IRMP#NEC_+_extended_NEC|NEC]]-Repetition-Frames, um "Geisterkommandos" zu verhindern.

* 26.06.2010: Bugfix: Deaktivieren von [[IRMP#RECS80|RECS80]], [[IRMP#RECS80EXT|RECS80EXT]] & [[IRMP#SIEMENS_+_RUWIDO|SIEMENS]] bei geringer Interrupt-Rate

* 25.06.2010: '''Neues Protokoll''': [[IRMP#RCCAR|RCCAR]]
* 25.06.2010: Tastenerkennung für [[IRMP#FDC|FDC]]-Protokoll (IR-keyboard) erweitert
* 25.06.2010: Interrupt-Frequenz nun bis zu 20kHz möglich

* 09.06.2010: '''Neues Protokoll''': [[IRMP#FDC|FDC]] (IR-keyboard)
* 09.06.2010: Timing für [[IRMP#DENON|DENON]]-Protokoll korrigiert

* 02.06.2010: '''Neues Protokoll''': [[IRMP#SIEMENS_+_RUWIDO|SIEMENS]] (Gigaset)

* 26.05.2010: '''Neues Protokoll''': [[IRMP#GRUNDIG_+_NOKIA|NOKIA]]
* 26.05.2010: Bugfix Auswertung von langen Tastendrücken bei [[IRMP#GRUNDIG_+_NOKIA|GRUNDIG]]-Protokoll

* 17.05.2010: Bugfix [[IRMP#SAMSUNG32|SAMSUNG32]]-Protokoll: Kommando-Bit-Maske korrigiert

* 16.05.2010: '''Neues Protokoll''': [[IRMP#GRUNDIG_+_NOKIA|GRUNDIG]]
* 16.05.2010: Behandlung von automatischen Frame-Wiederholungen beim [[IRMP#SIRCS|SIRCS]]-, [[IRMP#SAMSUNG32|SAMSUNG32]]- und [[IRMP#NUBERT|NUBERT]]-Protokoll verbessert.

* 28.04.2010: Nur einige kosmetische Code-Optimierungen

* 16.04.2010: Sämtliche Timing-Toleranzen angepasst/optimiert

* 12.04.2010: '''Neues Protokoll''': [[IRMP#B&O|Bang & Olufsen]]

* 29.03.2010: Bugfix beim Erkennen von mehrfachen [[IRMP#NEC_+_extended_NEC|NEC]]-Repetition-Frames
* 29.03.2010: Konfiguration in [http://www.mikrocontroller.net/svnbrowser/irmp/irmpconfig.h?view=markup irmpconfig.h] ausgelagert
* 29.03.2010: Einführung einer Programmversion in README.txt: Version 1.0

* 17.03.2010: '''Neues Protokoll''': [[IRMP#NUBERT|NUBERT]]

* 16.03.2010: Korrektur der RECS80-Startbit-Timings
* 16.03.2010: '''Neues Protokoll''': [[IRMP#RECS80EXT|RECS80 Extended]]

* 15.03.2010: Codeoptimierung

* 14.03.2010: Portierung auf PIC

* 11.03.2010: Anpassungen an verschiedene ATMega-Typen durchgeführt

* 07.03.2010: Bugfix: Zurücksetzen der Statemachine nach einem unvollständigen [[IRMP#RC5_+_RC5X|RC5]]-Frame

* 05.03.2010: '''Neues Protokoll''': [[IRMP#APPLE|APPLE]]
* 05.03.2010: Die Daten irmp_data.addr + irmp_data.command werden nun in der jeweiligen Bit-Order des verwendeten Protokolls gespeichert

* 04.03.2010: '''Neues Protokoll''': [[IRMP#SAMSUNG32|SAMSUNG32]] (Mix aus [[IRMP#SAMSUNG|SAMSUNG]] & [[IRMP#NEC_+_extended_NEC|NEC]]-Protokoll)
* 04.03.2010: Änderung der [[IRMP#SIRCS|SIRCS]]- und [[IRMP#KASEIKYO|KASEIKYO]]-Toleranzen

* 02.03.2010: [[IRMP#SIRCS|SIRCS]]: Korrekte Erkennung und Unterdrückung von automatischen Frame-Wiederholungen
* 02.03.2010: [[IRMP#SIRCS|SIRCS]]: Device-ID-Bits werden nun in irmp_data.command und nicht mehr in irmp_data.address gespeichert
* 02.03.2010: Vergrößerung des Scan Buffers (zwecks Protokollierung)

* 24.02.2010: Neue Variable flags in IRMP_DATA zur Erkennung von langen Tastendrücken

* 20.02.2010: Bugfix [[IRMP#DENON|DENON]]-Protokoll: Wiederholungsframe grundsätzlich invertiert

* 19.02.2010: Erkennung von [[IRMP#NEC_+_extended_NEC|NEC]]-Protokoll-Varianten, z. B. [[IRMP#APPLE|APPLE]]-Fernbedienung
* 19.02.2010: Erkennung von [[IRMP#RC6_+_RC6A|RC6]]- und [[IRMP#DENON|DENON]]-Protokoll
* 19.02.2010: Verbesserung des [[IRMP#RC5_+_RC5X|RC5]]-Decoders (Bugfixes)

* 13.02.2010: Bugfix: Puls/Pausen-Counter um 1 zu niedrig, nun bessere Erkennung bei Protokollen mit sehr kurzen Pulszeiten
* 13.02.2010: Erkennung der [[IRMP#NEC_+_extended_NEC|NEC]]-Wiederholungssequenz

* 12.02.2010: [[IRMP#RC5_+_RC5X|RC5]]-Protokoll-Decoder hinzugefügt

* 05.02.2010: Konflikt zwischen [[IRMP#SAMSUNG|SAMSUNG]]- und [[IRMP#MATSUSHITA|MATSUSHITA]]-Protokoll beseitigt

* 07.01.2010: Erste Version

== Software-Historie IRSND ==

Änderungen IRSND:

Version 2.5.2:

* 03.06.2014: '''Neues Protokoll''': [[IRMP#TELEFUNKEN|TELEFUNKEN]]

Version 2.5.1:

* 30.05.2014: '''Neues Protokoll''': [[IRMP#SPEAKER|SPEAKER]]

Version 2.4.1:

* 30.05.2014: Timings für [[IRMP#SAMSUNG|SAMSUNG]]-Protokolle optimiert

Version 2.4.0

* 20.02.2014: '''Neues Protokoll''': [[IRMP#SIEMENS_+_RUWIDO|RUWIDO]]

Ältere Versionen:

* 09.04.2013: '''Neues Protokoll''': [[IRMP#ROOMBA|ROOMBA]] ('''nur im SVN!''')
* 12.03.2013: 15kHz für [[IRMP#RECS80|RECS80]]- und [[IRMP#RECS80EXT|RECS80EXT]]-Protokoll ist nun auch erlaubt
* 17.01.2013: Unterstützung für ATtiny44 hinzugefügt
* 12.12.2012: '''Neues Protokoll''': [[IRMP#A1TVBOX|A1TVBOX]]
* 07.12.2012: Korrektur Timing beim [[IRMP#NIKON|NIKON]]-Protokoll
* 26.10.2012: Einige Timer-Korrekturen, Anpassungen an Arduino
* 18.06.2012: Unterstützung für ATtiny87/167 hinzugefügt
* 05.06.2012: Korrekturen Portierung auf ARM STM32 - nun getestet
* 23.05.2012: Portierung auf ARM STM32 (ungetestet!)
* 23.05.2012: Bugfix Timing für 2. Frame beim Denon-Protokoll
* 27.02.2012: '''Neues Protokoll''': [[IRMP#IR60 (SDA2008)|IR60 (SDA2008)]]
* 27.02.2012: Bug beim Senden von [[IRMP#Biphase|Biphase]]-Frames (Manchester) behoben
* 27.02.2012: Portierung auf C18 Compiler für PIC-Mikroprozessoren
* 15.02.2012: Bugfix: Nur der 1. Frame wurde gesendet
* 13.02.2012: Timing von [[IRMP#SAMSUNG|SAMSUNG]]- und [[IRMP#SAMSUNG32|SAMSUNG32]]-Protokoll korrigiert
* 13.02.2012: [[IRMP#KASEIKYO|KASEIKYO]]: Genre2-Bits werden nun im oberen Nibble von flags gespeichert.
* 13.02.2012: Zusätzliche Pause nach dem Senden des letzten Frames
* 20.09.2011: '''Neues Protokoll''': [[IRMP#THOMSON|THOMSON]]
* 20.09.2011: '''Neues Protokoll''': [[IRMP#LEGO|LEGO]]
* 20.09.2011: '''Neues Protokoll''': [[IRMP#NEC16|NEC16]]
* 20.09.2011: '''Neues Protokoll''': [[IRMP#NEC42|NEC42]]
* 20.09.2011: Portierung auf ATtiny84 und ATtiny85
* 20.09.2011: Korrektur von Pausenlängen
* 20.09.2011: Korrekturen von irsnd_stop()
* 20.09.2011: Korrektur des [[IRMP#SIEMENS_+_RUWIDO|SIEMENS]]-Timings
* 20.09.2011: Umstellung auf 36kHz Modulationsfrequenz für [[IRMP#DENON|DENON]]-Protokoll
* 20.09.2011: Korrektur Behandlung zusätzlicher Bits im [[IRMP#SIRCS|SIRCS]]-Protokoll
* 18.01.2011: '''Neues Protokoll''': [[IRMP#RC6_+_RC6A|RC6A]]
* 18.01.2011: '''Neues Protokoll''': [[IRMP#RC6_+_RC6A|RC6]]
* 18.01.2011: '''Neues Protokoll''': [[IRMP#NIKON|NIKON]]
* 18.01.2011: Beachten der zusätzlichen Bits (>12) im [[IRMP#SIRCS|SIRCS]]-Protokoll
* 18.01.2011: Korrektur der Pausenlängen
* 18.01.2011: Timing-Korrekturen für [[IRMP#DENON|DENON]]-Protokoll

* 02.09.2010: Neues Protokoll: [[IRMP#JVC|JVC]]
* 02.09.2010: Anpassung des [[IRMP#APPLE|APPLE]]-Encoders an IRMP-Version 1.7.3.

* 29.08.2010: Neues Protokoll: [[IRMP#KASEIKYO|KASEIKYO]] (Panasonic u.a.)

* 01.07.2010: Bugfix: Deaktivieren von [[IRMP#RECS80|RECS80]], [[IRMP#RECS80EXT|RECS80EXT]] & [[IRMP#SIEMENS_+_RUWIDO|SIEMENS]] bei geringer Interrupt-Rate

* 25.06.2010: Neues Protokoll: [[IRMP#RCCAR|RCCAR]]

* 09.06.2010: Neues Protokoll: [[IRMP#FDC|FDC]] (IR-keyboard)
* 09.06.2010: Timing für [[IRMP#DENON|DENON]]-Protokoll korrigiert

* 02.06.2010: Neues Protokoll: [[IRMP#SIEMENS_+_RUWIDO|SIEMENS]] (Gigaset)
* 02.06.2010: Simulation von langen Tastendrücken

* 26.05.2010: Neues Protokoll: [[IRMP#GRUNDIG_+_NOKIA|NOKIA]]

* 17.05.2010: Neues Protokoll: [[IRMP#GRUNDIG_+_NOKIA|GRUNDIG]]
* 17.05.2010: Behandlung von Frame-Wiederholungen für [[IRMP#SIRCS|SIRCS]], [[IRMP#SAMSUNG32|SAMSUNG32]] und [[IRMP#NUBERT|NUBERT]] korrigiert

* 28.04.2010: Unterstützung des [[IRMP#APPLE|APPLE]]-Protokolls
* 28.04.2010: Konfiguration über [http://www.mikrocontroller.net/svnbrowser/irmp/irsndconfig.h?view=markup irsndconfig.h]

* 16.04.2010: Sämtliche Timing-Toleranzen angepasst/optimiert

* 14.04.2010: Neues Protokoll: [[IRMP#B&O|Bang & Olufsen]]

* 17.03.2010: Neues Protokoll: [[IRMP#NUBERT|NUBERT]]
* 17.03.2010: Korrektur der Pausen zwischen Frame-Wiederholungen

* 16.03.2010: Korrektur des Timer-Registers TCCR2
* 16.03.2010: Korrektur der [[IRMP#RECS80|RECS80]]-Startbit-Timings
* 16.03.2010: Neues Protokoll: [[IRMP#RECS80EXT|RECS80 Extended]]

* 11.03.2010: Anpassungen an verschiedene ATMega-Typen durchgeführt

* 07.03.2010: Alpha-Version

== Literatur ==

=== IR-Übersicht ===

* http://www.sbprojects.com/knowledge/ir/index.php
* http://www.epanorama.net/links/irremote.html
* http://www.elektor.de/jahrgang/2008/juni/cc2-avr-projekt-%283%29-unsichtbare-kommandos.497184.lynkx?tab=4 (IR Übersicht & RC5)

=== SIRCS-Protokoll ===

* http://www.sbprojects.com/knowledge/ir/sirc.php
* http://www.ustr.net/infrared/sony.shtml
* http://users.telenet.be/davshomepage/sony.htm
* http://picprojects.org.uk/projects/sirc/
* http://www.celadon.com/infrared_protocol/infrared_protocols_samples.pdf

=== NEC-Protokoll ===

* http://www.sbprojects.com/knowledge/ir/nec.php
* http://www.ustr.net/infrared/nec.shtml
* http://www.celadon.com/infrared_protocol/infrared_protocols_samples.pdf

=== LGAIR-Protokoll ===

Der LG Air Conditioner ist eine Klimaanlage, die durch eine "intelligente" Fernbedienung gesteuert wird.
Dies sind die "entschlüsselten" Daten:

<code>
Befehl AAAAAAAA PW Z S T mmm tttt vvvv PPPP
--------------------------------------------------------------------
ON 23C 10001000 00 0 0 0 000 1000 0100 1100
ON 26C 10001000 00 0 0 0 000 1011 0100 1111

OFF 10001000 11 0 0 0 000 0000 0101 0001
TURN OFF 10001000 11 0 0 0 000 0000 0101 0001 (18C currently, identical with off)

TEMP DOWN 23C 10001000 00 0 0 1 000 1000 0100 0100
MODE (to mode0, 23C) 10001000 00 0 0 1 000 1000 0100 0100

TEMP UP (24C) 10001000 00 0 0 1 000 1001 0100 0101
TEMP DOWN 24C 10001000 00 0 0 1 000 1001 0100 0101

TEMP UP (25C) 10001000 00 0 0 1 000 1010 0100 0110
TEMP DOWN 25C 10001000 00 0 0 1 000 1010 0100 0110

TEMP UP (26C) 10001000 00 0 0 1 000 1011 0100 0111

MODE 10001000 00 0 0 1 011 0111 0100 0110 (to mode1, 22C - when switching to mode1 temp automaticall sets to 22C)
ON (mode1, 22C) 10001000 00 0 0 0 011 0111 0100 1110

MODE 10001000 00 0 0 1 001 1000 0100 0101 (to mode2, no temperature displayed)
ON (mode2) 10001000 00 0 0 0 001 1000 0100 1101
MODE (to mode3, 23C) 10001000 00 0 0 1 100 1000 0100 1000
ON (mode3, 23C) 10001000 00 0 0 0 100 1000 0100 0000

VENTILATION SLOW 10001000 00 0 0 1 000 0011 0000 1011
VENTILATION MEDIUM 10001000 00 0 0 1 000 0011 0010 1101
VENTILATION HIGH 10001000 00 0 0 1 000 0011 0100 1111
VENTILATION LIGHT 10001000 00 0 0 1 000 0011 0101 0000

SWING ON/OFF 10001000 00 0 1 0 000 0000 0000 0001

Format: 1 start bit + 8 address bits + 16 data bits + 4 checksum bits + 1 stop bit

Address: AAAAAAAA = 0x88 (8 bits)

Data: PW Z S T MMM tttt vvvv PPPP (16 bits)

PW: Power: 00 = On, 11 = Off

Z: N/A: Always 0

S: Swing: 1 = Toggle swing, all other data bits are zeros.

T: Temp/Vent: 1 = Set temperature and ventilation

MMM: Mode, can be combined with temperature
000=Mode 0
001=Mode 2
010=????
011=Mode 1
100=Mode 3
101=???
111=???

tttt: Temperature:
0000=used by OFF command
0001=????
0010=????
0011=18°C
0100=19°C
0101=20°C
0110=21°C
0111=22°C
1000=23°C
1001=24°C
1010=25°C
1011=26°C
1011=27°C
1100=28°C
1101=29°C
1111=30°C

vvvv: Ventilation:
0000=slow
0010=medium
0011=????
0100=high
0101=light
0110=????
0111=????
...
1111=????

Checksum: PPPP = (DataNibble1 + DataNibble2 + DataNibble3 + DataNibble4) & 0x0F
</code>

=== NEC16-Protokoll (JVC) ===

* http://www.sbprojects.com/knowledge/ir/jvc.php
* http://www.ustr.net/infrared/jvc.shtml

=== SAMSUNG-Protokoll ===

(wurde aus diversen Protokollen (Daewoo u.ä.) zusammengereimt, daher kein direkter Link auf irgendwelche SAMSUNG-Dokumentation verfügbar)

Hier ein Link zum Daewoo-Protokoll, welches dasselbe Prinzip des Sync-Bits in der Mitte eines Frames nutzt, jedoch mit anderen Timing-Werten arbeitet:

* http://users.telenet.be/davshomepage/daewoo.htm

=== MATSUHITA-Protokoll ===

* http://www.celadon.com/infrared_protocol/infrared_protocols_samples.pdf

=== KASEIKYO-Protokoll (auch "Japan-Protokoll") ===

* http://www.mikrocontroller.net/attachment/4246/IR-Protokolle_Diplomarbeit.pdf
* http://www.roboternetz.de/phpBB2/files/entwicklung_und_realisierung_einer_universalinfrarotfernbedienung_mit_timerfunktionen.pdf

=== RECS80- und RECS80-Extended-Protokoll ===

* http://www.sbprojects.com/knowledge/ir/recs80.php

=== RC5- und RC5x-Protokoll ===

* http://www.sbprojects.com/knowledge/ir/rc5.php
* http://users.telenet.be/davshomepage/rc5.htm
* http://www.celadon.com/infrared_protocol/infrared_protocols_samples.pdf
* http://www.opendcc.de/info/rc5/rc5.html

=== Denon-Protokoll ===

* http://www.mikrocontroller.com/de/IR-Protokolle.php#DENON
* http://www.manualowl.com/m/Denon/AVR-3803/Manual/170243

=== RC6 und RC6A-Protokoll ===

* http://www.sbprojects.com/knowledge/ir/rc6.php
* http://www.picbasic.nl/info_rc6_uk.htm

=== Bang & Olufsen ===

* http://www.mikrocontroller.net/attachment/33137/datalink.pdf

=== Grundig-Protokoll ===

* http://www.see-solutions.de/sonstiges/Grundig_10bit.pdf

=== Nokia-Protokoll ===

* http://www.sbprojects.com/knowledge/ir/nrc17.php

=== IR60 (SDA2008 bzw. MC14497P) ===

* http://www.datasheetcatalog.org/datasheet/motorola/MC14497P.pdf

=== LEGO Power Functions RC ===

* http://www.philohome.com/pf/LEGO_Power_Functions_RC_v110.pdf

=== RCMM-Protokoll ===

* http://www.sbprojects.com/knowledge/ir/rcmm.php

=== Diverse Protokolle ===

* http://www.mikrocontroller.net/attachment/4246/IR-Protokolle_Diplomarbeit.pdf
* http://www.celadon.com/infrared_protocol/infrared_protocols_samples.pdf
* http://www.roboternetz.de/phpBB2/files/entwicklung_und_realisierung_einer_universalinfrarotfernbedienung_mit_timerfunktionen.pdf

== IRMP auf Youtube ==

Einige Videos zu [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] habe ich auf Youtube gefunden:

* http://www.youtube.com/watch?v=Q7DJvLIyTEI

* http://www.youtube.com/watch?v=1tQ_aqayWZk

* http://www.youtube.com/watch?v=W4tI2axR3-w

* http://www.youtube.com/watch?v=SRs98dIe2WE

== Weitere Artikel zu IRMP ==

[http://www.infineon.com/dgdl/RF2ir+WhitePaper+V1.0.pdf?folderId=db3a3043191a246301192dd3ee2c2ae4&fileId=db3a30432b57a660012b5c16272c2e81 Whitepaper von Martin Gotschlich, Infineon Technologies AG]

== Hardware / IRMP-Projekte ==

=== IR-Tester ===

Eine Implementierung auf Basis [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] und [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]] als Multiprotokoll Dekoder mit LCD
von Klaus Leidinger:
* http://www.mikrocontroller-projekte.de/Mikrocontroller/index.html

=== IR-Tester mit AVR-NET-IO ===

Ähnliche Implementierung wie von Klaus Leidinger für Pollin AVR-NET-IO mit Pollin ADD-ON Board:
* http://son.ffdf-clan.de/include.php?path=forumsthread&threadid=703

=== USB IR Remote Receiver ===

USB IR Remote Receiver von Hugo Portisch:
* http://www.mikrocontroller.net/articles/USB_IR_Remote_Receiver

=== Servo-gesteuerter IR-Sender ===

Servo-gesteuerter IR-Sender mit Anlernfunktion von Stefan Pendsa:
* http://forum.mikrokopter.de/topic-21060.html
* [http://svn.mikrokopter.de/listing.php?repname=Projects&path=%2FServo-Controlled+IR-Transmitter%2F&#Ad2417800d6aa14bf08c571a896e9def7 SVN]

=== Lernfähige IR-Fernbedienung ===

Lernfähige IR-Fernbedienung von Robert und Frank M.
* http://www.mikrocontroller.net/articles/DIY_Lernfähige_Fernbedienung_mit_IRMP

=== AVR Moodlight ===

AVR Moodlight von Axel Schwenke
* http://www.mikrocontroller.net/topic/244768

=== Kinosteuerung ===

Kinosteuerung von Owagner
* http://ccc.zerties.org/index.php/Benutzer:Owagner

=== Phasenanschnittsdimmer ===

Phasenanschnittsdimmer - steuerbar über IR-Fernbedienung:

* http://flosserver.dyndns.org/phasenanschnittsdimmer.php

=== IRDioder – Ikea Dioder Hack ===

Ikea Dioder Hack mit Atmel und Infrarotempfaenger:

* http://marco-difeo.de/tag/infrared/

=== Arduino als IR-Empfänger ===

Arduino als IR-Empfänger:

* http://www.vdr-portal.de/board18-vdr-hardware/board13-fernbedienungen/110918-arduino-als-ir-empf%C3%A4nger-einsetzen/

=== IR-Lautstärkesteuerung mit Stellaris Launchpad ===

IR-Lautstärkesteuerung mit Stellaris Launchpad (ARM Cortex-M4F):

* http://www.anthonyvh.com/2013/03/31/ir-volume-control/

== Danksagung ==

Ganz herzlich bedanken möchte ich mich bei Vlad Tepesch, Klaus Leidinger und Peter K., die mich mit Scan-Dateien ihrer Infrarot-Fernbedienungen versorgt haben. Dank auch an Klaus für seine nächtelangen Tests von [[IRMP#IRMP_-_Infrarot-Multiprotokoll-Decoder|IRMP]] & [[IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder|IRSND]].

Ebenso bedanken möchte ich mich bei Christian F. für seine Tipps zur PIC-Portierung. Vielen Dank auch an gera für die Portierung auf den PIC-C18 Compiler. Für die Portierung auf ARM STM32 bedanke ich mich herzlich bei kichi (Michael K.). Vielen Dank auch an Markus Schuster für die Portierung auf Stellaris LM4F120 Launchpad von TI (ARM Cortex M4).

== Diskussion ==

Meinungen, Verbesserungsvorschläge, harsche Kritik und ähnliches kann im [http://www.mikrocontroller.net/topic/162119 Beitrag: Infrared Multi Protocol Decoder] geäussert werden.

Viel Spaß mit IRMP!

[[Kategorie:Infrarot]]
[[Kategorie:AVR-Projekte]]

Fehlersuche

2014-05-25T12:05:20Z

Maybee: Typo

== Einleitung ==

Auf neudeutsch [http://de.wikipedia.org/wiki/Debugger Debugging] genannt (engl. bug = Wanze). Die Fehlersuche in Geräten, welche defekt sind oder die man sogar selber gebaut hat, ist eine der Hauptbeschäftigungen beim Umgang mit Elektronik, egal ob Hardware oder Software. Deshalb sollte man sie möglichst effizient betreiben.

== Grundlagen ==

=== Vorgehen ===

Am Anfang kann man von unzähligen Fehlermöglichkeiten förmlich erschlagen werden. Und dann weiß man manchmal nicht so recht, wo man anfangen soll. Aber auch dafür gibt es Konzepte, welche sich dem individuellen Problem anpassen lassen.

* Einfach zu prüfende, grundlegend wichtige Dinge zuerst prüfen. Wenn ein Auto stehen bleibt, prüft man erstmal, ob noch Treibstoff im Tank ist und nicht, ob die Kurbelwelle gebrochen ist. Grundlegende Dinge sind
** Stromversorgung
** wichtige Eingangssignale
** wichtigen Zwischensignale
* Sind meine Messgeräte OK?
**Batterie im [[Multimeter]] noch halbwegs voll?
**Kalibrierung stimmt?
**Tastköpfe am Oszilloskop richtig kompensiert?
* Messe ich am richtigen IC und am richtigen Pin? Je nach Bauteil zeigt das Datenblatt die Pinbelegung von oben (top view) oder unten (bottom view).
* Keine voreiligen Schlüsse. Man sollte Fehlerursachen nur dann wirklich ausschließen, wenn man sie eindeutig geprüft und gemessen hat.
* Den Testaufbau schrittweise einschränken und vereinfachen. Nach Möglichkeit Schaltungs/- oder Softwareteile deaktivieren bzw. abklemmen oder austauschen (ICs, Module, Kabel, Programmteile, Funktionen, etc.).
* Teile und herrsche. Wenn in einer langen Signalkette das Ausgangssignal nicht stimmt, sollte man sich sich nicht Schritt für Schritt durchhangeln sondern immer erst die Mitte der Kette prüfen. Beispiel. In einer Kette von 10 Verstärkerstufen prüft man zuerst die 5. Stufe. Ist das Signal dort OK, liegt der Fehler zwischen Stufe 5 und 10, also prüft man danach Stufe 7 oder 8. Im anderen Fall, wenn Stufe 5 schon kein gutes Siganl mehr ausgibt, liegt der Fehler zwischen 1 bis 5, man prüft somit im nächsten Schritt Stufe 2 oder 3. Somit findet man in einer Kette bzw. Reihenschaltung von sehr vielen Elementen sehr schnell das Problem.

=== Hilfsmittel ===

Für die Fehlersuche in Hardware braucht man je nach Art der Schaltung

* ein oder mehrere [[Multimeter]]
* Labornetzteil mit Strombegrenzung
* Status-[[LED]]s
* [[Oszilloskop]]
* Logikanalysator
* Funktionsgenerator
* Netzwerkanalysator
* Trenntrafo

Typische Werkzeuge für das Softwaredebuggen sind

* Simulator: Damit wird der Code nur auf dem PC simuliert
* In Circuit Debugger: Er kann das echte Programm auf der echten Hardware debuggt werden, man kann Haltepunkte (engl. break points) im Programm setzen, Variablen anschauen und vieles mehr
* [[UART]] für Debugausgaben
* Status-[[LED]]s
* Testpins

=== Allgemeine Hinweise ===

*Wenn ein Fehler konstant vorliegt oder reproduzierbar ist, hat man in gewisser Weise Glück. Diese Fehler sind eher leicht zu finden und zu beheben. Ziel der Fehlersuche ist es, einen Fehler reproduzierbar zu machen.
*Sporadische Fehler sind sehr gefährlich und sehr schwer lokalisierbar, wie z.B. Hardwarefehler
**Wackelkontakte
**Haarrisse
**Risse durch mechanische oder thermische Spannungen
*oder Softwarefehler wie
**Zugriffsfehler auf Variablen in [[Interrupt]]s
**Variablenüberläufe, welche erst nach Stunden oder Tagen auftreten (Echtzeituhr, Datum, Ereigniszähler)
**Pufferüberläufe in Strings und Arrays
Gerade die sporadischen Fehler sollte man vermeiden, indem man möglichst solide arbeitet. D.h.
*Hardware
** gutes Konzept, d.h. die Schaltung sollte möglichst unempfindlich gegenüber Bauteiltoleranzen und Störungen sein
** sauber löten
** Bauteilkennwerte nicht überschreiten, Reserven einplanen
** Toleranzen und Temperaturverhalten der Bauteile beachten
*Software
** gutes Konzept
** [[Strukturierte Programmierung auf Mikrocontrollern | sauber programmieren]], keine Hackertricks
** defensiv programmieren, umfangreiche Fehlerbehandlung

== Fehlersuche in Hardware ==

* Stromversorgung
** Ist das Gerät ans Netz(teil) angeschlossen? Korrekte Polung?
** Ist die Sicherung OK?
** Liefert der Spannungsregler die korrekte Spannung?
** Ist mein Messgerät auf die richtige Spannungsform eingestellt (AC oder DC)?
** Liegt die Spannung an allen wichtigen ICs an?
** Liegt die Stromaufnahme im erwarteten Bereich?
* Signalpfade
** Wie sieht das Eingangssignal aus?
** Liegen die richtigen Ruhesignale (Arbeitspunkt, Ruhestrom) an den wichtigen Punkten der Schaltung an?
** Liegen die richtigen Signale an den Zwischenpunkten der Schaltung an?
** Sind Logikpegel sauber LOW und HIGH? Wenn nein, dann sind oft mehrere Ausgänge gleichzeitig auf einem [[Bus]] aktiv und ziehen in verschiedene Richtungen (Low und High). Oder Die Ausgänge sind zu schwach, um die Lasten zu treiben.
** Sind Taktsignale sauber ohne Überschwinger und Zacken in den Flanken? Falsche [[Wellenwiderstand | Terminierung]], schleche Leitungsführung (Masse) oder EMV-Probleme können die Ursache sein.
**Dabei sollte man aber auch sauber messen, um nicht einem Phantom hinterher zu jagen (Bandbreite des [[Oszilloskop#Tastköpfe richtig benutzen| Tastkopfes]] und [[Oszilloskop]]s, kurze Masseverbindung ([http://www.mikrocontroller.net/topic/81049#677911 ground spring]), möglichst keine Erdschleifen).
** Wenn Signale ganz fehlen oder sich nicht ändern? Kurzschlüsse? Unterbrechungen? Wackelkontakte?
*Fehlfunktionen
** Werden ICs ungewöhnlich heiß? Einfache Logik-ICs und Operationsverstärker werden normalerweise kaum warm, Endstufen, [[Treiber]], Leistungstransistoren, Linearregler und große ICs ([[FPGA]]s, Tranceiver etc.) dagegen schon.
** Schwingen Quarze und Oszillatoren korrekt? Vorsicht beim direkten Messen an Quarzen, die reagieren bisweilen empfindlich auf zusätzliche Lastkapazitäten, hier auf jeden Fall mit einem 10:1 Tastkopf messen
** "Hello World!" Minimaltest für Mikrocontroller. Eine LED im 1s Rhytmus blinken lassen. Damit kann man viele einfache Dinge erstmal prüfen, das sollte man am Anfang immer erst einmal machen.
*** Compiler funktioniert und erzeugt ein gültiges Hex-File
*** Programmierung funktioniert
*** Mikrocontroller kann das Programm ausführen, Spannung und Takt liegen an

=== Tips zum Hardwaredebugging ===

* Freie Pins an Mikrocontrollern, [[FPGA]]s, [[CPLD]]s auf Testpads legen, das ist vor allem bei kleinen Gehäusen wie TQFP, MLF oder gar [[BGA]]s notwendig, um dort mit Testspitzen und Drähten ranzukommen.
* In wichtige Punkte der Stromverteilung Null Ohm Widerstände einfügen, dort kann man später ein Messgerät einschleifen; alternativ wenigstens die Leiterbahn gut zugänglich auf der Ober- oder Unterseite layouten, damit man sie im Testfall mit dem Skalpell auftrennen kann.
* Viele Vorgänge in Mikrocontrollerschaltungen sind nicht periodisch. Um sie zu messen braucht man meist ein [[Oszilloskop | Digitaloszilloskop]]. Hat man sowas nicht zur Verfügung, muss man versuchen, die Vorgänge periodisch zu machen, indem man z.B. eine Datenausgabe per [[UART]] oder [[SPI]] in einer Schleife immer wieder ausführt. Damit kann man sie auch mit einem Analogoszilloskop darstellen.
* Testpins sind sehr nützlich, um Zeitverhalten von Software zu messen, z.B. Interruptroutinen. Zum Begin setzt man ein Pin auf HIGH, am Ende auf LOW, das kann man dann sehr einfach mit einem Oszilloskop messen
* Ebenfalls kann man mit so einem Testpin den Anfang eines speziellen Programmablaufs signalisieren, um ein Oszilloskop zu triggern, was sonst in einem komplexen Signalspiel nur sehr schwer möglich wäre
*Treten Fehler erst bei hohen oder niedrigen Temperaturen auf? Mit Kältespray und Heißluftpistole kann man sie provozieren.
*Einfache Logikschaltungen wie z.B. den [[SPI]]-[[Bus]] kann man auch ohne [[Oszilloskop]] anschauen, indem man das Timing der Steuersignale extrem verlangsamt. Das schafft man, indem man im Programm hinter jedem Portzugriff eine Pause von ca. 1s macht (avr gcc -> _delay_ms(1000)). Damit kann man an jedes Signal eine [[LED]] mit Vorwiderstand anschließen und das Signalspiel sichtbar machen. Das Gleiche gilt für [[I2C]], da auch dieser ein synchroner Bus ist und damit beliebig langsam getaktet werden kann. Man muss nur beachten, dass dadurch die Busleitungen mit den Open Drain Ausgängen nicht zu sehr belastet werden. Am Besten schließt man diese Test-LEDs ebenfalls invertiert an, parallel zu den Pull Up Widerständen, d.h. Anode über Vorwiderstand an VCC und die Kathode jeweils an die beiden Siganle SCL und SDA. Beim [[UART]] geht das leider nicht, dieser ist asynchron und auf ein genaues Timing angewiesen.

=== FPGAs und CPLDs ===

* In komplexeren FPGA-Schaltungen, welche z.B. Videodaten mittels [[AD-Wandler]] aufnehmen und verarbeiten, kann man den AD-Wandler zu Testzwecken durch ein synthetisches Modul im FPGA ersetzen, welches definierte Datenströme erzeugt, sozusagen ein digitaler Funktionsgenerator
* In FPGAs kann man auch virtuelle Logikanalysatoren einbauen, welche Datenströme im FPGA aufzeichnen; Die Steuerung erfolgt oft über [[JTAG]] oder spezielle Schnittstellen

=== Kurzschlüsse finden ===

In der Entwicklung von Schaltungen geht immer mal was kaputt. Bauteile brennen durch. Doch wie findet man sie, wenn sie zwar defekt, aber nicht äusserlich zerstört sind? Wie findet man einen defekten IC an einem [[SPI]]-[[Bus]] mit 10 angeschlossenen ICs?

* Verpolte Elektrolytkondensatoren findet man meist recht schnell, wenn man mit einem strombegrenzten Netzteil die Schaltung speist. Sie werden warm bis heiß, das findet man schnell.
*Kurzschlüsse auf verzweigten Netzen findet man per Milliohmmessung nach dem [http://de.wikipedia.org/wiki/Vierdrahtmessung Vierleiterprinzip].
**Schaltung ausschalten
**Über ein strombegrenztes Netzteil oder eine Spannungsquelle mit großem Vorwiderstand einen Konstantstrom in das fehlerhafte Netz einspeisen. Dabei richtet sich dessen Höhe nach der Art des elektrischen Netzes. Für ein Signal auf einer Platine reichen meist 100mA, für Stromversorgungsleitungen oder Verkabelung in einem Gerät können es schon mal 1-10A sein.
**Mit dem Multimeter im Millivolt-Messbereich die Spannung vom Einspeisepunkt zu den verschiedensten Punkten im Netz messen. Dort wo die größte Spannung abfällt, ist der Kurzschluss.
*Feine Kurzschlüsse auf Leiterbahnen, welche z.B. durch Fehler beim Ätzen entstehen, weil Dreck, Haare oder ähliches zur sehr feinen Kurzschlüssen geführt haben, kann man teilweise durch einen starken Strompuls aus einem großen Kondensator oder Netzteil freibrennen, der Kurzschluss verdampft dabei das Kupfer. Aber Vorsicht! Wenn man Pech hat verdampft auch gleich ein guter Teil der Leiterbahn!

=== Erstmaliges Einschalten einer Schaltung ===

Schaltet man eine Schaltung das erste Mal ein, sollte man einiges beachten, um im Fehlerfall nicht vor einem Haufen Asche zu sitzen. Das gilt vor allem für Schaltungen, die größere Leistungen beinhalten (Netzteile, Motorendstufen, Wechselrichter, etc.) oder aus sehr kräftigen Quellen gespeist werden (Stromstarke Netzteile, Akkumulatoren).
* Vor dem Einschalten die Platine noch einmal kontrollieren
** Sind alle Bauteile richtig bestückt?
** Polarität von Dioden und Kondensatoren stimmt?
** ICs nicht verdreht?
** Keine Kurzschlüsse durch Lötzinn?
** Ist alles um die Platine herum richtig angeschlossen?
*Schaltungen mit Kleinspannung aus einem Netzteil mit Strombegrenzung speisen, die Strombegrenzung nur wenig höher einstellen als das Gerät schätzungsweise benötigt.
*Schaltungen mit größerer Leistung bzw. Netzanschluss mit einem Sicherungsautomaten absichern.
*Nach dem Einschalten die wichtigsten Ströme und Spannungen messen und prüfen, ob sie wie erwartet sind
*Wichtige Zwischensignale messen und prüfen
*Wärmeentwicklung prüfen
*Belastung von Netzteilen und Verstärkern langsam steigern

== Fehlersuche in Software ==

=== Tips zum Softwaredebugging ===

* Eine Ausgabe von Debuginformationen per [[UART]] ist oft sehr nützlich, auch wenn das Gerät im Normalbetrieb keinerlei UART nutzt
* Im [[EEPROM]] kann man auch Debuginformationen ablegen und später wieder auslesen
* Wenn man fremde Projeke übernimmt, sollte man schrittweise vorgehen.
** Zuerst das Projekt, welches meist ein Beispiel enthält, ohne jegliche Änderungen/Anpassungen komplett kompilieren. Wenn das funktioniert, weiß man erstmal, dass der Compiler soweit funktioniert.
** Danach nur minimale Änderungen, z.b. Pinzuordungen, Konfigurationen vornehmen und testen.
** Nach erfolgreichem Test des Beispiels mit minimalen Änderungen kann man das Projekt in größerem Maße umbauen bzw. in sein Projekt integrieren. Aber auch hier sollte man eher kleine Schritte machen und zwischendurch immer wieder die Funktion testen. Das ist einfacher als sehr viele Änderungen auf einmal durchzuführen und danach zu testen.

== Siehe auch ==

* [[AVR Checkliste]]
* [http://www.mikrocontroller.net/topic/299061?goto=3206880#3206853 Forumsbeitrag]: Protokoll eines unbekannt Display mittels Chaosangriff entziffern

== Links ==

* Analog Circuits (World Class Designs) ISBN 978-0750686273, eine Zusammenstellung von verschiedensten Schaltungen mit ausführlichen Erklärungen; Filter, AD-Wandler, Lasertreiber, U-F Wandler, Mikrocontroller etc.
* Troubleshooting Analog Circuits, ISBN 978-0750694995, eine umfangreiche Mischung von Praxistips zur Entwicklung und Fehlersuche in analogen Schaltungen, viele Informationen über Bauteile und Konzepte, geschrieben von der Analoglegende [http://www.ti.com/ww/en/bobpease/index.html Bob Peace]
* http://www.repairfaq.org Seite mit umfangreichen Tips zur Fehlersuche, Reperatur diverser Elektronik, Laser und mehr (engl.)
[[Kategorie:Grundlagen]]
* [http://www.analog.com/library/analogdialogue/archives/43-09/linear_circuit_design_handbook.html Basic Linear Design seminar notes] - fundiertes eBook / PDFs mit nützlichen Infos zu Schaltungsdesign, parasitären Effekten und Fehlersuche

Motoransteuerung mit PWM

2014-05-19T19:33:27Z

Maybee: Typo

==Allgemeines==

Bei der Dimensionierung der Strombelastbarkeit der Bauteile muss man vor allem 2 Werte betrachten:
* Stromaufnahme des Motors im normalen Betrieb (also mit der Last)
* Stromaufnahme bei blockiertem Motor, bzw. Anlaufstrom. Hier wird der Strom nur durch den ohmschen Widerstand im Stromkreis begrenzt, er kann also je nach Motor schnell den 2-3 stelligen Amperebereich erreichen.

Die übliche Dimensionierung richtet sich vor allem nach dem ersten Wert und plant entsprechende Reserven ein (für ein paar Sekunden Faktor 2-5 des Stromes), da der zweite Wert in der Praxis aus Kostengründen meist nur schwer realisierbar und unnötig ist. Daher umgeht man das Problem entweder über eine schnelle Strombegrenzung oder über einen Sanftanlauf indem man die [[PWM]] langsam hoch fährt. Dadurch wird der maximale Strom auf einen deutlich niedrigeren Wert begrenzt, so dass die Bauteile schwächer und kostengünstiger ausfallen können.

Die Spannung am Motor und somit näherungsweise die Leerlaufdrehzahl ist proportional zu dem Tastverhältnis:

:<math>\text{Motorspannung} = \text{Betriebsspannung} \cdot \mathrm{Tastverh\ddot{a}ltnis}</math>

==Schaltungsvarianten==

===Mosfet mit Freilaufdiode, 1-Quadrantensteller===

[[Datei:Motor_PWM_1.gif|thumb|300px|1-Quadrantensteller]]
Die einfachste Schaltung besteht nur aus Transistor T1, dem Motor, der Freilaufdiode D1, dem Kondensator C1, sowie der eigentlichen [[PWM]]-Erzeugung und dem [[MOSFET-Übersicht#Mosfet-Treiber | Mosfettreiber]].

In der Einschaltphase von T1 liegt am Motor die gesamte Betriebsspannung an. Die Differenz zwischen der vom sich drehenden Motor erzeugten Generatorspannung und der Betriebsspannung fällt am Wicklungswiderstand sowie der Wicklungsinduktivität ab. Man hat es also mit einer RL Reihenschaltung zu tun. Da der Wicklungswiderstand recht klein ist, steigt der Strom näherungsweise linear an, bis T1 abschaltet. Dann übernimmt D1 den Stromfluss und schließt den Stromkreis solange, bis T1 den Strom wieder übernimmt (oder der Strom abgeklungen ist = lückender Betrieb). Obwohl keine Energie mehr von außen zugeführt wird, wird der Motor weiterhin durch die in der Wicklung gespeicherten Energie versorgt. Der Strom fällt nun wieder linear ab, bis T1 wieder durchsteuert und wieder Energie zuführt.

Der Strom durch die Diode D1 ist von der Amplitude her genauso groß wie der Strom durch T1, je nach Tastverhältnis ist der Effektivwert aber kleiner als der durch T1 (bei über 50% Tastverhältnis), gleich (bei 50% Tastverhältnis) oder sogar größer (bei einem Tastverhältnis kleiner 50%). Daher muss die Diode genauso stark dimensioniert werden wie der Transistor (möglichst eine schnelle Schaltdiode (z.B. Schottky) verwenden, keine langsamen Gleichrichterdioden wie 1N400x). Der Kondensator C1 ist notwendig, um den durch die PWM gepulsten Strom zu glätten, da aufgrund der steilen Flanken ansonsten in den Zuleitungen ein Spannungsabfall bzw. Spannungsspitzen auftreten würden (am besten 2 oder mehrere Kondensatoren unterschiedlicher Kapazität und Bauart verwenden, meistens ein Folienkondensator mit einigen Mikrofarad parallel zu einem Aluminiumelektrolytkondensator).

Der Transistor, die Diode und der Kondensator sollen möglichst nahe zusammen plaziert werden (kürzeste Verbindungen). Wenn die Diode am Motor angebracht wird, strahlt die Zuleitung massiv Störungen ab. Die Leitungen sollten am besten verdrillt werden.

===Synchrongleichrichtung, 2-Quadrantensteller===

[[Datei:Motor_PWM_2.gif|thumb|300px|2-Quadrantensteller]]
Um die Verluste in der Freilaufdiode zu verringern kann man diese durch einen zweiten Mosfet ersetzen, der immer dann eingeschaltet wird, wenn der andere abgeschaltet ist.

Da dieser Mosfet im Gegensatz zu einer Diode in beide Richtungen Strom leitet, ist es damit möglich den Motor kurzzuschließen und so den Motor zu bremsen. Allgemein kann man sagen: Ist die durch die PWM erzeugte mittlere Spannung größer als die Generatorspannung des Motors, wird dieser beschleunigt. Ist die Spannung kleiner, wird der Motor abgebremst. Durch T2 wird der Motor dabei kurzgeschlossen, so dass sich durch die Generatorspannung zunächst der Strom in der Motorwicklung ab- und dann in umgekehrter Richtung wieder aufbaut. Beim Abschalten von T2 und Einschalten von T1 fließt dieser Strom über T1 in C1 und somit die Spannungsquelle zurück. Die Energie wird beim Bremsen also nicht vernichtet, sondern wieder in elektrische Energie zurückverwandelt. Dies sollte man bedenken wenn man eine große Masse abbremst, denn die Spannungsquelle muss die Energie aufnehmen können. Sollte die Spannungsquelle z. B. aus einem Transformator mit Gleichrichter bestehen, kann dieser die Energie nicht aufnehmen sondern nur C1, was dazu führt, dass die Betriebsspannung ansteigt bis eventuell einer der Transistoren zerstört wird. Um dies zu verhindern ist eine Überspannungsbegrenzung in Form eines Bremswiderstands vorzusehen (Bremschopper). In einfachen Fällen reicht auch eine Leistung-Z-Diode oder ein passende Nachbildung aus Z-Diode und Leistungstransistor. Besteht die Spannungsquelle z. B. aus einem Akku dann nimmt dieser die Energie auf und wird beim Bremsen wieder etwas geladen.
Dies funktioniert allerdings nur, wenn das Tastverhältnis nicht 0% beträgt, also T2 und T1 abwechselnd schalten, so dass nicht die gesamte Energie in der Motorwicklung sowie T2 verheizt wird. Man sollte es daher vermeiden das Tastverhältnis schnell in eine der beiden Richtungen zu ändern, da dies zu einem hohen Strom führt.

Die Ansteuerschaltung muss weiterhin verhindern, dass T1 und T2 gleichzeitig leitend werden können, denn dies würde zu einem Kurzschluss der Betriebsspannung führen. Ein fertig aufgebauter Mosfet-Treiber verhindert dies.

===H-Brücke, 4-Quadrantensteller===

[[Datei:Motor_PWM_3.gif|thumb|300px|4-Quadrantensteller]]
Die H-Brücke, bzw. der 4-Quadrantensteller ist eine Erweiterung des 2-Quadrantenstellers durch eine zweite Halbbrücke. Diese ermöglicht neben dem Beschleunigen und Bremsen des Motors auch eine Umkehr der Drehrichtung. Dafür gibt es mehrere Ansteuerverfahren
#Das effizienteste ist, eine Hälfte wie beim 2-Quadrantensteller zu betreiben und mit der anderen den zweiten Motoranschluss an die Betriebsspannung zu legen. Für die andere Drehrichtung wechselt man einfach die Hälften, legt also den anderen Anschluss an die Betriebsspannung und verwendet die andere Hälfte als 2-Quadrantensteller.

#Das andere Verfahren steuert abwechselnd T1 und T4 oder T2 und T3 durch, legt also immer eine Spannung an den Motor. Ist das Tastverhältnis 50% fließt im Mittel ein Strom von 0A, da der Motor für jeweils die Hälfte der Zeit eine positive und eine negative Spannung erhält, der Motor steht also. Je nachdem ob man das Tastverhältnis darüber oder darunter wählt, legt man die Drehrichtung fest. Dieses Verfahren ist Ansteuertechnisch einfacher, erzeugt aber auch im Stillstand Schaltverluste in den Transistoren und Verluste im Motor.

==Beispielschaltungen==

===1-Quadrantensteller mit diskretem Mosfettreiber===

[[Datei:Motor_PWM1_real.gif|thumb|300px|Einfacher 1-Quadrantensteller]]
Diese Schaltung eignet sich für Motoren bis etwa 35V und 10A Dauerstrom.
Q1 und Q2 zusammen mit deren Beschaltung dienen als [[Pegelwandler]] von 3,3 oder 5V Digitalsignalen auf 12V für das Mosfet Gate. Die Schaltung arbeitet dabei invertierend, der Mosfet schaltet also bei einem Low am Eingang ein.
Sperrt Q1, wird Q2 über R1 durchgesteuert und liefert etwa 11-11,5V ans Gate des Mosfets. R2 begrenzt dabei den Strom.
Das Abschalten des Mosfets geschieht über den Pfad Q1 und D1. Gleichzeitig wird Q2 die Basisspannung weggenommen, so dass dieser sperrt.
D2 zwischen Basis und Kollektor von Q1 verhindert, dass dieser in die Sättigung kommt, so dass dieser nahezu verzögerungsfrei sperrt, sobald der Eingang auf Low wechselt. Ab ein paar Ampere benötigt die Freilaufdiode D3 einen kleinen [[Kühlkörper]], ebenso Q3. Sollte die Betriebsspannung V+ des Motors bei etwa 10-16V liegen, dann kann diese Spannung auch für die Mosfetansteuerung verwendet werden. Ansonsten sollte dafür eine getrennte Spannung mit etwa 12-15V verwendet werden.

===1-Quadrantensteller mit diskretem Highside-Mosfettreiber===

[[Datei:Motor_PWM1b_real.gif|thumb|300px|Einfacher 1-Quadrantensteller mit P-Kanal Mosfet]]

Diese Schaltung eignet sich für Motoren mit etwa 15-40V Betriebsspannung und mit bis zu 10A Dauerstrom. Schaltungen mit P-Kanal Mosfets sollte man wenn möglich vermeiden, da N-Kanal Mosfets prinzipbedingt um Faktor 3 bessere Werte aufweisen als P-Kanal Mosfets. Allerdings wird manchmal ein auf Masse bezogener Ausgang gefordert, dann ist diese Schaltung hier die richtige. Das Problem bei der Highsideansteuerung ist, dass man die Gate-Sourcespannung irgendwie auf max. 20V begrenzen muss, was hier durch eine zusätzliche Hilfsspannung von 12V wie bei der vorigen Schaltung, nicht so einfach geht. Daher wird hier ein anderer Weg eingeschlagen. Q1 und R2 bilden eine [[Konstantstromquelle]]. Dadurch, dass an der Basis eine feste Logikspannung ansteht, steuert Q1 so stark durch, bis er sich durch den Spannungsabfall an R2 selbst die Basisspannung reduziert. Der fließende Strom beträgt dabei (Logikpegel am Eingang - 0,6V Basis-Emitterspannung)/R2. Ein guter Wert für den Strom sind etwa 10-15mA. Bei der Dimensionierung sollte man auch die Verlustleistung beachten: 40V * 15mA = 0,6W. Dies ist für einen Transistor im TO92 Gehäuse deutlich zu viel. Dadurch, dass Q1 im Linearbetrieb arbeitet, kommt er nicht in die Sättigung, und es kann auf die Diode wie in der vorherigen Schaltung verzichtet werden. Ebenso ist ein Basiswiderstand unnötig bzw. sogar hier fehl am Platz. Da nun bekannt ist, dass im durchgesteuerten Zustand von Q1 bei 5V Logikspannung (5V-0,6V)/330Ω= 13,3mA fließen, kann man damit den Spannungsabfall an R1 berechnen, bzw. aus der gewünschten Spannung R1:
U(R1)=13,3mA*1kOhm=13,3V. Im eingeschalteten Zustand ist die Spannung am Kollektor von Q1 also um 13,3V negativer als V+ und das unabhängig von der Betriebsspannung! Da diese Spannung durch die als Emitterfolger geschalteten Transistor Q2 und Q3 gepuffert auch an das Gate des Mosfets gelegt werden, bekommt dieser also rund 13V Gatespannung im eingeschalteten Zustand. Dies passt gut, denn für die meisten Mosfets sollte man einen Wert zwischen 10 und 15V verwenden. Durch den Spannungsteiler aus R1 und R2 ergibt sich allerdings auch eine untere Grenze der Betriebsspannung, damit die Schaltung sauber funktioniert: Um die 13,3V über R2 zu erhalten, bzw. die 4,4V über R1 sind mindestens 17,7V für V+ notwendig.

===2-Quadrantensteller mit Halbbrücken Mosfettreiber===

[[Datei:Motor_PWM2_real.gif|thumb|300px|Einfacher 2-Quadrantensteller]]

Diese Schaltung eignet sich für Motoren bis etwa 35V und 20A Dauerstrom.
Um den Aufwand zu minimieren wird für die Halbbrücke ein fertiger Halbbrückentreiber IR2184 verwendet. Dieser besitzt eine integrierte Totzeit (engl. dead time) von 500ns zwischen dem Umschalten der Mosfets, so dass ein gleichzeitiges Einschalten beider Mosfets ausgeschlossen ist. Da der Mosfet gegen V+ angeschlossen ist, arbeitet auch diese Schaltung invertierend. Der Grund, warum der Motor nicht gegenüber GND angeschlossen ist, ist folgender:
Für die Ansteuerung des Highside Mosfets Q2 ist eine Spannung von etwa 10V mehr als die Betriebsspannung V+ notwendig. Diese wird über die Bootstrapschaltung aus C2 und D1 erzeugt. Ist Q1 durchgesteuert, läd sich C2 über D1 auf. Schaltet anschließend Q1 ab und Q2 ein, wird dessen Ansteuerspannung aus C2 entnommen. Da Q2 nun VS mit V+ verbindet, steigt auch das Potential an C2 an. An dem VB Pin stehen nun etwa V+ + 12V-0,7V (12V Betriebsspannung-Flusspannung von D1) an. Aufgrund von Leckströmen, entläd sich C2 allerdings innerhalb einiger Millisekunden. Daher ist die maximale Einschaltdauer von Q2 begrenzt. 100% Einschaltdauer wären daher nicht möglich. Um dieses Problem zu umgehen ist der Motor gegen V+ geschaltet, so dass für 100% Einschaltdauer Q1 eingeschaltet werden muss, was kein Problem ist, denn dessen Treiber wird direkt auf den 12V versorgt. Ist Q1 dagegen dauerhaft aus, Q2 also an, bremst der Motor, bzw. er steht, so dass kein Strom durch die Mosfets fließt. Daher ist es auch nicht weiter schlimm, wenn Q2 nach einer kurzen Zeit wieder abschaltet. Das einzige was nicht möglich ist, ist ein dauerhaftes Bremsen des Motors mittels Q2, aber dies wird in der Praxis auch nur in den seltensten Fällen benötigt. Über den IN Pin, wird das invertierte PWM Signal mit Logikpegeln eingespeist. Über den SD\ Pin, lassen sich beide Mosfets gemeinsam abschalten. Damit ist ein ungebremstes Auslaufen lassen des Motors möglich (Freilauf). Ab etwa 5Ampere benötigen die Mosfets einen kleinen [[Kühlkörper]].

==Wahl der PWM-Frequenz==

Bei der Wahl der PWM Frequenz muss man mehrere Faktoren berücksichtigen und einen Kompromiss eingehen:
* Die Motorinduktivität L glättet den Strom, der Wicklungswiderstand R führt zu einem Abfallen des Stromes, daraus ergibt sich die elektrische Zeitkonstante des Motors <math>t=\frac{L}{R}</math>. Bei vielen Motoren liegt diese um 1ms. Bei hochwertigen Motoren sollte diese Angabe im Datenblatt zu finden sein. Um den Stromripple gering, also das Drehmoment konstant zu halten, sollte die Periodendauer der PWM diese Zeit nicht überschreiten. Vor allem im 2 bzw. 4-Quadratentebetrieb ist dies wichtig, denn dort kann der Strom auch seine Richtung ändern, was zu einem Abbremsen, somit zu einem deutlichen Ruckeln und zu Vibrationen des Motors und zu unnötigen Verlusten führt.
* Frequenzen zwischen 100Hz und 10kHz erzeugen hörbare Pfeifgeräusche im Motor
* Mit zunehmender Frequenz steigen die Schaltverluste in den Transistoren sowie die Verluste in der Ankerwicklung sowie in deren Kern.

Die aus elektrischer Sicht ideale PWM Frequenz liegt daher meist bei 1-2kHz. Allerdings ist dies genau der Bereich, in dem das Gehör am empfindlichsten ist. Wenn das Pfeifen des Motors nicht stört, ist dies also der ideale Bereich.
Da die untere Frequenz durch die elektrische Zeitkonstante des Motors begrenzt ist, kann man nur nach oben ausweichen. Ein Kompromiss ist daher der Bereich 5-15kHz in dem das Gehör deutlich unempfindlicher ist, sich die Verluste noch in Grenzen halten. Verwendet man die einfache Schaltung mit der Freilaufdiode und legt keinen Wert auf einen runden Lauf, bzw. hat eine hohe Masse am Motor, so dass dieser träge ist, dann kann man als Alternative zu den >5kHz die PWM Frequenz auch bis auf 200Hz reduzieren um das Geräusch erträglicher zu machen. Allerdings reduziert sich dann der Wirkungsgrad aufgrund des hohen Stromripples.

== Siehe auch ==

*[[PWM]]
*[[Treiber]]
*[[MOSFET-Übersicht#MOSFET-Treiber | Mosfet-Treiber]]
*[[H-Brücken Übersicht]]
*[http://www.mikrocontroller.net/topic/103116#900247 Forumsbeitrag]: Highside Mosfetansteuerung mit diskretem Treiber
* [http://www.mikrocontroller.net/topic/191616#1870643 Forumsbeitrag]: Zur Erklärung der PWM Steuerung, Bremsen und Unterschied zum Relais
* [http://www.mikrocontroller.net/topic/280480#2960070 Forumsbeitrag]: Clevere MOSFET-Treiber mit kleinsten Trafos

==Links==

*[http://de.wikipedia.org/wiki/Zweiquadrantensteller Zweiquadrantensteller bei Wikipedia]
*[http://de.wikipedia.org/wiki/Vierquadrantensteller Vierquadrantensteller bei Wikipedia]
*[http://homepages.which.net/~paul.hills/SpeedControl/SpeedControllersBody.html Grundlagen zum Thema Motoransteuerung (englisch)]

[[Kategorie:Leistungselektronik]]
[[Kategorie:Motoren]]

AVR-GCC-Tutorial/LCD-Ansteuerung

2014-02-23T08:59:25Z

Maybee: Änderung 81760 von 2.205.104.107 (Diskussion) rückgängig gemacht.

==Das LCD und sein Controller==

Die meisten Text-LCDs verwenden den Controller [[HD44780]] oder einen kompatiblen (z. B. KS0070) und haben 14 oder 16 Pins. Hier ist die häufigste Anschluss-Belegung angegeben.

;Achtung: Es gibt Displays mit abweichender Anschluss-Belegung, z.B. TC1602E (Pollin 120420). Falscher Anschluss kann zur Zerstörung führen! Daher immer das zugehörige Datenblatt zu Rate ziehen. Einzelheiten unter Artikel zum Controller [[HD44780]].

{| class="wikitable"
! Pin # || Bezeichnung || Funktion
|-
! 1
| Vss || GND (beim TC1602E Vdd=Vcc)
|-
! 2
| Vdd/Vcc || 5V (beim TC1602E Vss=Gnd)
|-
! 3
| Vee || Kontrastspannung (0V bis 5V)
|-
! 4
| RS || Register Select (Befehle/Daten)
|-
! 5
| RW || Read/Write
|-
! 6
| E
| Enable
|-
! 7
| DB0 ||rowspan="8"| Datenbits 0−7
|-
! 8
| DB1
|-
! 9
| DB2
|-
! 10
| DB3
|-
! 11
| DB4
|-
! 12
| DB5
|-
! 13
| DB6
|-
! 14
| DB7
|-
! 15
| A || LED-Beleuchtung, Anode
|-
! 16
| K || LED-Beleuchtung, Kathode
|}

{{Warnung|
;Achtung: Unbedingt von der richtigen Seite zu zählen anfangen! Meistens ist neben Pin 1 eine kleine 1 auf der LCD-Platine. Ansonsten im Datenblatt nachschauen! Oft ist Pin 1 auch durch ein rechteckiges statt rundes Pad gekennzeichnet.

:Bei LCDs mit 16-poligem Anschluss sind die beiden letzten Pins für die Hintergrundbeleuchtung reserviert. Hier unbedingt das Datenblatt zu Rate ziehen, die beiden Anschlüsse sind je nach Hersteller oft anders beschaltet. Falls kein Datenblatt vorliegt, kann man mit einem Durchgangsprüfer feststellen, welcher Anschluss mit Masse (GND) verbunden ist.
}}

Vss wird ganz einfach an GND angeschlossen und Vcc an 5V. Vee kann man testweise auch an GND legen. Wenn das LCD dann zu dunkel sein sollte muss man ein 10k-Potentiometer zwischen GND und 5V schalten, mit dem Schleifer an Vee:

[[Bild:LCD_Vee.gif]]

Es gibt zwei verschiedene Möglichkeiten zur Ansteuerung eines solchen Displays: den '''8-bit-''' und den '''4-bit-'''Modus.
* Für den '''8-bit-Modus''' werden (wie der Name schon sagt) alle acht Datenleitungen zur Ansteuerung verwendet, somit kann durch einen Zugriff immer ein ganzes Byte übertragen werden.
* Der '''4-bit-Modus''' verwendet nur die oberen vier Datenleitungen ('''DB4-DB7'''). Um ein Byte zu übertragen braucht man somit zwei Zugriffe, wobei zuerst das höherwertige '''"Nibble"''' (= 4 Bits), also Bit 4 bis Bit 7 übertragen wird und dann das niederwertige, also Bit 0 bis Bit 3. Die unteren Datenleitungen des LCDs, die beim Lesezyklus Ausgänge sind, lässt man offen (siehe Datasheets, z. B. vom KS0070).

Der 4-bit-Modus hat den Vorteil, dass man 4 IO-Pins weniger benötigt als beim 8-bit-Modus, weshalb ich mich hier für eine Ansteuerung mit 4bit entschieden habe.

Neben den vier Datenleitungen (DB4, DB5, DB6 und DB7) werden noch die Anschlüsse '''RS''', '''RW''' und '''E''' (ist in manchen Unterlagen auch '''EN''' für ''Enable'' abgekürzt) benötigt.

* Über '''RS''' wird ausgewählt, ob man einen Befehl oder ein Datenbyte an das LCD schicken möchte. Ist RS Low, dann wird das ankommende Byte als Befehl interpretiert, ist RS high, dann wird das Byte auf dem LCD angezeigt.
* '''RW''' legt fest, ob geschrieben oder gelesen werden soll. High bedeutet lesen, low bedeutet schreiben. Wenn man RW auf lesen einstellt und RS auf Befehl, dann kann man das '''Busy-Flag''' an DB7 lesen, das anzeigt, ob das LCD den vorhergehenden Befehl fertig verarbeitetet hat (diese Methode u.a. in der LCD-Library von Peter Fleury verwendet). Ist RS auf Daten eingestellt, dann kann man z. B. den Inhalt des Displays lesen - was jedoch nur in den wenigsten Fällen Sinn macht. Deshalb kann man RW dauerhaft auf low lassen (= an GND anschließen), so dass man noch ein IO-Pin am Controller einspart. Der Nachteil ist, dass man dann das Busy-Flag nicht lesen kann, weswegen man nach jedem Befehl vorsichtshalber ein paar Mikrosekunden warten sollte, um dem LCD Zeit zum Ausführen des Befehls zu geben. Dummerweise schwankt die Ausführungszeit von Display zu Display und ist auch von der Betriebsspannung abhängig. Für professionellere Sachen also lieber den IO-Pin opfern und Busy abfragen.
* Der '''E''' Anschluss schließlich signalisiert dem LCD, dass die übrigen Datenleitungen jetzt korrekte Pegel angenommen haben und es die gewünschten Daten von den Datenleitungen bzw. Kommandos von den Datenleitungen übernehmen kann.

== Anschluss an den Controller ==

Jetzt da wir wissen, welche Anschlüsse das LCDs benötigt, können wir das LCD mit dem Mikrocontroller verbinden:

ACHTUNG: Es gibt Displays mit abweichender Anschluss-Belegung, falscher Anschluss kann zur Zerstörung führen! Daher immer das zugehörige Datenblatt zu Rate ziehen.

Einzelheiten unter [http://www.mikrocontroller.net/articles/HD44780 Artikel zum Controller HD44780]

{| class="wikitable"
!Pin #-LCD || Bezeichnung-LCD || Pin-µC
|-
!1
| Vss || GND
|-
!2
| Vcc || 5V
|-
!3
| Vee || GND oder Poti (siehe oben)
|-
!4
| RS || PD4 am AVR
|-
!5
| RW || GND
|-
!6
| E || PD5 am AVR
|-
!7
| DB0 ||rowspan="4"| offen (unbenutzt)
|-
!8
| DB1
|-
!9
| DB2
|-
!10
| DB3
|-
!11
| DB4 || PD0 am AVR
|-
!12
| DB5 || PD1 am AVR
|-
!13
| DB6 || PD2 am AVR
|-
!14
| DB7 || PD3 am AVR
|}

Wenn man die Steuerleitungen EN und RS auf Pins an einem anderen Port legen möchte, kann man so wie in diesem [http://www.mikrocontroller.net/topic/88543#751982 Forumsbeitrag] oder wie im Artikel [[Erweiterte LCD-Ansteuerung]] vorgehen.

Ok, alles ist verbunden, wenn man jetzt den Strom einschaltet sollten ein oder zwei schwarze Balken auf dem Display angezeigt werden. Erscheint trotz korrektem Anschluss nichts auf dem Display, so kann das auch am Kontrast des LCDs liegen. Die Balken werden dann zwar theoretisch angezeigt, sind aber nicht sichtbar, weil die Kontrastspannung zu hoch ist. Abhilfe schafft es hier, wenn man die Spannung am Schleifer des Potis nachmisst und in Richtung 0V verstellt. Zwischen 1V und 0V treten die Balken dann meist hervor.
Doch wie bekommt man jetzt die Befehle und Daten in das Display?

== Programmierung ==

=== Die LCD Routinen ===

Der folgende Satz von Ansteuerroutinen für ein Text-LCD ist in der Datei '''lcd-routines.c''' zusammengefasst. Diese Datei muss man beim Einrichten zusätzlich zum eigenen Hauptprogramm in sein Projekt aufnehmen. Dies geschieht beim AVR Studio unter Source Files im Fenster AVR GCC oder bei WinAVR im Makefile (z. B. durch SRC += lcd-routines.c).

Wichtig ist außerdem, dass die Optimierung bei der Compilierung eingeschaltet ist, sonst stimmen die Zeiten der Funktionen _delay_us() und _delay_ms() nicht und der Code wird wesentlich länger (Siehe Dokumentation der libc im WinAVR).

Als weitere Datei ist die Includedatei '''lcd-routines.h''' notwendig, die im Hauptprogramm und in '''lcd-routines.c''' eingebunden wird. Die Anpassung der Pinbelegung etc. macht man in dieser Datei.

==== Datei '''lcd-routines.h''' ====
<syntaxhighlight lang="c">
// Ansteuerung eines HD44780 kompatiblen LCD im 4-Bit-Interfacemodus
// http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung
//

#ifndef LCD_ROUTINES_H
#define LCD_ROUTINES_H

////////////////////////////////////////////////////////////////////////////////
// Hier die verwendete Taktfrequenz in Hz eintragen, wichtig!

#ifndef F_CPU
#define F_CPU 3686400
#endif

////////////////////////////////////////////////////////////////////////////////
// Pinbelegung für das LCD, an verwendete Pins anpassen
// Alle LCD Pins müssen an einem Port angeschlossen sein und die 4
// Datenleitungen müssen auf aufeinanderfolgenden Pins liegen

// LCD DB4-DB7 <--> PORTD Bit PD0-PD3
#define LCD_PORT PORTD
#define LCD_DDR DDRD
#define LCD_DB PD0

// LCD RS <--> PORTD Bit PD4 (RS: 1=Data, 0=Command)
#define LCD_RS PD4

// LCD EN <--> PORTD Bit PD5 (EN: 1-Impuls für Daten)
#define LCD_EN PD5

////////////////////////////////////////////////////////////////////////////////
// LCD Ausführungszeiten (MS=Millisekunden, US=Mikrosekunden)

#define LCD_BOOTUP_MS 15
#define LCD_ENABLE_US 20
#define LCD_WRITEDATA_US 46
#define LCD_COMMAND_US 42

#define LCD_SOFT_RESET_MS1 5
#define LCD_SOFT_RESET_MS2 1
#define LCD_SOFT_RESET_MS3 1
#define LCD_SET_4BITMODE_MS 5

#define LCD_CLEAR_DISPLAY_MS 2
#define LCD_CURSOR_HOME_MS 2

////////////////////////////////////////////////////////////////////////////////
// Zeilendefinitionen des verwendeten LCD
// Die Einträge hier sollten für ein LCD mit einer Zeilenlänge von 16 Zeichen passen
// Bei anderen Zeilenlängen müssen diese Einträge angepasst werden

#define LCD_DDADR_LINE1 0x00
#define LCD_DDADR_LINE2 0x40
#define LCD_DDADR_LINE3 0x10
#define LCD_DDADR_LINE4 0x50

////////////////////////////////////////////////////////////////////////////////
// Initialisierung: muss ganz am Anfang des Programms aufgerufen werden.
void lcd_init( void );

////////////////////////////////////////////////////////////////////////////////
// LCD löschen
void lcd_clear( void );

////////////////////////////////////////////////////////////////////////////////
// Cursor in die 1. Zeile, 0-te Spalte
void lcd_home( void );

////////////////////////////////////////////////////////////////////////////////
// Cursor an eine beliebige Position
void lcd_setcursor( uint8_t spalte, uint8_t zeile );

////////////////////////////////////////////////////////////////////////////////
// Ausgabe eines einzelnen Zeichens an der aktuellen Cursorposition
void lcd_data( uint8_t data );

////////////////////////////////////////////////////////////////////////////////
// Ausgabe eines Strings an der aktuellen Cursorposition
void lcd_string( const char *data );

////////////////////////////////////////////////////////////////////////////////
// Definition eines benutzerdefinierten Sonderzeichens.
// data muss auf ein Array[8] mit den Zeilencodes des zu definierenden Zeichens
// zeigen
void lcd_generatechar( uint8_t code, const uint8_t *data );

////////////////////////////////////////////////////////////////////////////////
// Ausgabe eines Kommandos an das LCD.
void lcd_command( uint8_t data );

////////////////////////////////////////////////////////////////////////////////
// LCD Befehle und Argumente.
// Zur Verwendung in lcd_command

// Clear Display -------------- 0b00000001
#define LCD_CLEAR_DISPLAY 0x01

// Cursor Home ---------------- 0b0000001x
#define LCD_CURSOR_HOME 0x02

// Set Entry Mode ------------- 0b000001xx
#define LCD_SET_ENTRY 0x04

#define LCD_ENTRY_DECREASE 0x00
#define LCD_ENTRY_INCREASE 0x02
#define LCD_ENTRY_NOSHIFT 0x00
#define LCD_ENTRY_SHIFT 0x01

// Set Display ---------------- 0b00001xxx
#define LCD_SET_DISPLAY 0x08

#define LCD_DISPLAY_OFF 0x00
#define LCD_DISPLAY_ON 0x04
#define LCD_CURSOR_OFF 0x00
#define LCD_CURSOR_ON 0x02
#define LCD_BLINKING_OFF 0x00
#define LCD_BLINKING_ON 0x01

// Set Shift ------------------ 0b0001xxxx
#define LCD_SET_SHIFT 0x10

#define LCD_CURSOR_MOVE 0x00
#define LCD_DISPLAY_SHIFT 0x08
#define LCD_SHIFT_LEFT 0x00
#define LCD_SHIFT_RIGHT 0x04

// Set Function --------------- 0b001xxxxx
#define LCD_SET_FUNCTION 0x20

#define LCD_FUNCTION_4BIT 0x00
#define LCD_FUNCTION_8BIT 0x10
#define LCD_FUNCTION_1LINE 0x00
#define LCD_FUNCTION_2LINE 0x08
#define LCD_FUNCTION_5X7 0x00
#define LCD_FUNCTION_5X10 0x04

#define LCD_SOFT_RESET 0x30

// Set CG RAM Address --------- 0b01xxxxxx (Character Generator RAM)
#define LCD_SET_CGADR 0x40

#define LCD_GC_CHAR0 0
#define LCD_GC_CHAR1 1
#define LCD_GC_CHAR2 2
#define LCD_GC_CHAR3 3
#define LCD_GC_CHAR4 4
#define LCD_GC_CHAR5 5
#define LCD_GC_CHAR6 6
#define LCD_GC_CHAR7 7

// Set DD RAM Address --------- 0b1xxxxxxx (Display Data RAM)
#define LCD_SET_DDADR 0x80

#endif
</syntaxhighlight>

==== Datei '''lcd-routines.c''': ====
<syntaxhighlight lang="c">
// Ansteuerung eines HD44780 kompatiblen LCD im 4-Bit-Interfacemodus
// http://www.mikrocontroller.net/articles/HD44780
// http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung
//
// Die Pinbelegung ist über defines in lcd-routines.h einstellbar

#include <avr/io.h>
#include "lcd-routines.h"
#include <util/delay.h>

////////////////////////////////////////////////////////////////////////////////
// Erzeugt einen Enable-Puls
static void lcd_enable( void )
{
LCD_PORT |= (1<<LCD_EN); // Enable auf 1 setzen
_delay_us( LCD_ENABLE_US ); // kurze Pause
LCD_PORT &= ~(1<<LCD_EN); // Enable auf 0 setzen
}

////////////////////////////////////////////////////////////////////////////////
// Sendet eine 4-bit Ausgabeoperation an das LCD
static void lcd_out( uint8_t data )
{
data &= 0xF0; // obere 4 Bit maskieren

LCD_PORT &= ~(0xF0>>(4-LCD_DB)); // Maske löschen
LCD_PORT |= (data>>(4-LCD_DB)); // Bits setzen
lcd_enable();
}

////////////////////////////////////////////////////////////////////////////////
// Initialisierung: muss ganz am Anfang des Programms aufgerufen werden.
void lcd_init( void )
{
// verwendete Pins auf Ausgang schalten
uint8_t pins = (0x0F << LCD_DB) | // 4 Datenleitungen
(1<<LCD_RS) | // R/S Leitung
(1<<LCD_EN); // Enable Leitung
LCD_DDR |= pins;

// initial alle Ausgänge auf Null
LCD_PORT &= ~pins;

// warten auf die Bereitschaft des LCD
_delay_ms( LCD_BOOTUP_MS );

// Soft-Reset muss 3mal hintereinander gesendet werden zur Initialisierung
lcd_out( LCD_SOFT_RESET );
_delay_ms( LCD_SOFT_RESET_MS1 );

lcd_enable();
_delay_ms( LCD_SOFT_RESET_MS2 );

lcd_enable();
_delay_ms( LCD_SOFT_RESET_MS3 );

// 4-bit Modus aktivieren
lcd_out( LCD_SET_FUNCTION |
LCD_FUNCTION_4BIT );
_delay_ms( LCD_SET_4BITMODE_MS );

// 4-bit Modus / 2 Zeilen / 5x7
lcd_command( LCD_SET_FUNCTION |
LCD_FUNCTION_4BIT |
LCD_FUNCTION_2LINE |
LCD_FUNCTION_5X7 );

// Display ein / Cursor aus / Blinken aus
lcd_command( LCD_SET_DISPLAY |
LCD_DISPLAY_ON |
LCD_CURSOR_OFF |
LCD_BLINKING_OFF);

// Cursor inkrement / kein Scrollen
lcd_command( LCD_SET_ENTRY |
LCD_ENTRY_INCREASE |
LCD_ENTRY_NOSHIFT );

lcd_clear();
}

////////////////////////////////////////////////////////////////////////////////
// Sendet ein Datenbyte an das LCD
void lcd_data( uint8_t data )
{
LCD_PORT |= (1<<LCD_RS); // RS auf 1 setzen

lcd_out( data ); // zuerst die oberen,
lcd_out( data<<4 ); // dann die unteren 4 Bit senden

_delay_us( LCD_WRITEDATA_US );
}

////////////////////////////////////////////////////////////////////////////////
// Sendet einen Befehl an das LCD
void lcd_command( uint8_t data )
{
LCD_PORT &= ~(1<<LCD_RS); // RS auf 0 setzen

lcd_out( data ); // zuerst die oberen,
lcd_out( data<<4 ); // dann die unteren 4 Bit senden

_delay_us( LCD_COMMAND_US );
}

////////////////////////////////////////////////////////////////////////////////
// Sendet den Befehl zur Löschung des Displays
void lcd_clear( void )
{
lcd_command( LCD_CLEAR_DISPLAY );
_delay_ms( LCD_CLEAR_DISPLAY_MS );
}

////////////////////////////////////////////////////////////////////////////////
// Sendet den Befehl: Cursor Home
void lcd_home( void )
{
lcd_command( LCD_CURSOR_HOME );
_delay_ms( LCD_CURSOR_HOME_MS );
}

////////////////////////////////////////////////////////////////////////////////
// Setzt den Cursor in Spalte x (0..15) Zeile y (1..4)

void lcd_setcursor( uint8_t x, uint8_t y )
{
uint8_t data;

switch (y)
{
case 1: // 1. Zeile
data = LCD_SET_DDADR + LCD_DDADR_LINE1 + x;
break;

case 2: // 2. Zeile
data = LCD_SET_DDADR + LCD_DDADR_LINE2 + x;
break;

case 3: // 3. Zeile
data = LCD_SET_DDADR + LCD_DDADR_LINE3 + x;
break;

case 4: // 4. Zeile
data = LCD_SET_DDADR + LCD_DDADR_LINE4 + x;
break;

default:
return; // für den Fall einer falschen Zeile
}

lcd_command( data );
}

////////////////////////////////////////////////////////////////////////////////
// Schreibt einen String auf das LCD

void lcd_string( const char *data )
{
while( *data != '\0' )
lcd_data( *data++ );
}

////////////////////////////////////////////////////////////////////////////////
// Schreibt ein Zeichen in den Character Generator RAM

void lcd_generatechar( uint8_t code, const uint8_t *data )
{
// Startposition des Zeichens einstellen
lcd_command( LCD_SET_CGADR | (code<<3) );

// Bitmuster übertragen
for ( uint8_t i=0; i<8; i++ )
{
lcd_data( data[i] );
}
}
</syntaxhighlight>

=== LCD Beispiel 1 ===
Ein Hauptprogramm, welches die LCD Funktionen benutzt, sieht zb. so aus:

<syntaxhighlight lang="c">
//
// Anpassungen im makefile:
// ATMega8 => MCU=atmega8 im makefile einstellen
// lcd-routines.c in SRC = ... Zeile anhängen
//
#include <avr/io.h>
#include "lcd-routines.h"

int main(void)
{
// Initialisierung des LCD
// Nach der Initialisierung müssen auf dem LCD vorhandene schwarze Balken
// verschwunden sein
lcd_init();

// Text in einzelnen Zeichen ausgeben
lcd_data( 'T' );
lcd_data( 'e' );
lcd_data( 's' );
lcd_data( 't' );

// Die Ausgabemarke in die 2te Zeile setzen
lcd_setcursor( 0, 2 );

// erneut Text ausgeben, aber diesmal komfortabler als String
lcd_string("Hello World!");

while(1)
{
}

return 0;
}
</syntaxhighlight>

=== LCD Beispiel 2 ===
Ein Hauptprogramm, welches eine Variable ausgibt, sieht zb. so aus.
Mittels der itoa() Funktion (itoa = Integer To Ascii ) wird von einem Zahlenwert eine textuelle Repräsentierung ermittelt (sprich: ein String erzeugt) und dieser String mit der bereits vorhandenen Funktion lcd_string ausgegeben. Das Einrichten des Projekts ist wie in Beispiel 1.

<syntaxhighlight lang="c">
//
// Anpassungen im makefile:
// ATMega8 => MCU=atmega8 im makefile einstellen
// lcd-routines.c in SRC = ... Zeile anhängen
//
#include <avr/io.h>
#include <stdlib.h>
#include "lcd-routines.h"

// Beispiel
int variable = 42;

int main(void)
{
lcd_init();

// Ausgabe des Zeichens dessen ASCII-Code gleich dem Variablenwert ist
// (Im Beispiel entspricht der ASCII-Code 42 dem Zeichen *)
// http://www.code-knacker.de/ascii.htm
lcd_data( variable );

lcd_setcursor( 0, 2 );

// Ausgabe der Variable als Text in dezimaler Schreibweise
{
// ... umwandeln siehe FAQ Artikel bei http://www.mikrocontroller.net/articles/FAQ
// WinAVR hat eine itoa()-Funktion, das erfordert obiges #include <stdlib.h>
char Buffer[20]; // in diesem {} lokal
itoa( variable, Buffer, 10 );

// ... ausgeben
lcd_string( Buffer );
}

while(1)
{
}

return 0;
}
</syntaxhighlight>

== Siehe auch ==

* [[Erweiterte LCD-Ansteuerung]]
* [[Pseudo-Graphische LCD-Ansteuerung]]
* [http://www.mikrocontroller.net/topic/316826#3431235 Ermittlung der Startadresse der einzelnen Zeilen]

== Weblinks ==

* [http://homepage.hispeed.ch/peterfleury/avr-software.html#libs Lib zur HD44780 Ansteuerung (AVR)]
* [http://pic-projekte.de/wordpress/?p=908 Lib zur HD44780 Ansteuerung (PIC)]
* [http://www.nongnu.org/avr-libc/user-manual/group__stdiodemo.html Using the standard IO facilities] - Demoprojekt zur Text-LCD Ansteuerung (HD44780 komp.) in der avr-libc

[[Kategorie:Avr-gcc Tutorial]]
[[Kategorie:LCD]]

MOSFET-Übersicht

2013-04-26T23:10:55Z

Maybee: /* P-Kanal MOSFET */

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 entstehen, wo auch die Bezugsquellen angegeben sind. Bezugsquellen sollten nach Möglichkeit solche sein, die auch für den privaten Bastler in Frage kommen.

Der Thread zum Thema: http://www.mikrocontroller.net/topic/41588

siehe auch : [[Transistor-Übersicht]] - [[Dioden-Übersicht]] - [[Standardbauelemente]]

== P-Kanal MOSFET==

{| {{Tabelle}} border="1" class="sortable" id="pkanalmosfets"
|- style="background-color:#eeeeee"
! Bezeichnung
! Package
! Hersteller
! UGS/V
! UDS/V
! ID/A
! P/W
! RDS,on/mOhm
! Bemerkung
! Lieferant
! Einzelpreis
|-
| [http://www.mikrocontroller.net/part/BS250 BS250]
| TO-92/SOT-23
| Siliconix
| 4,0
| 60
| 0,12
| 0,35
| 10000
| -
|[[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Buerklin|Bü]]
| 0,32 €
|-
| [http://www.mikrocontroller.net/part/BSH205 BSH205]
| SOT23
| Phi
| 1,0
| 12
| 0,75
| 0,4
| 500
| kleine Gatekapazität (3.8nC)
| [[Elektronikversender#csd-electronics|csd]] (a.A.)
| 0,30 €
|-
| [http://www.mikrocontroller.net/part/SI2301 SI2301]
| SOT23
| Vishay
| 1,5
| 20
| 2,0
| 0,7
| 150
| kleine Gatekapazität (typ 4.5nC)
| [[Elektronikversender#farnell|farnell]]
| 0,30 €
|-
| [http://www.mikrocontroller.net/part/IRLML6402 IRLML6402PBF]
| SOT23
| IRF
| 1,2
| 20
| 3,7
| 1,3
| 65
| Ultra-Low On-Resistance, Logic-level
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#csd-electronics|csd]],[[Elektronikversender#Buerklin|Bü]]
| 0,15 €
|-
| [http://www.mikrocontroller.net/part/IRLML6302 IRLML6302PBF]
| SOT23
| IRF
| 1,5
| 20
| 0,75
| 0,54
| 600
| ähnlich BSH205
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#csd-electronics|csd]],[[Elektronikversender#Buerklin|Bü]]
| 0,18 €
|-
| [http://www.mikrocontroller.net/part/BSS83 BSS83P]
| SOT143
| Inf
| 3,0
| 60
| 0,33
| 0,35
| 2000
| -
| [[Elektronikversender#Reichelt|Rei]]
| 0,11 €
|-
| [http://www.mikrocontroller.net/part/BSS84 BSS84]
| SOT23
| Fairchild,NXP
| 2,0
| 50
| 0,13
| 0,35
| 10000
| -
| [[Elektronikversender#Farnell|Fa]]
| 0,28 €
|-
| [http://www.mikrocontroller.net/part/BSS83 BSS83]
| TO-97, SOT23
| Phi
| 3,0
| 50
| 0,13
| 0,35
| 10000
| -
| [[Elektronikversender#Conrad|Con]],[[Elektronikversender#Reichelt|Rei]]
| 0,07 €
|-
| [http://www.mikrocontroller.net/part/BSS110 BSS110]
| TO-97, SOT23
| Phi
| 3,0
| 50
| 0,17
| 0,35
| 10000
| -
| ?
| ?
|-
| [http://www.mikrocontroller.net/part/PMV65XP PMV65XP]
| SOT23
| Phi
| 1,4
| 20
| 3,9
| ?
| 76
| grosser ID für Bauform
| [[Elektronikversender#Spoerle|Spo]], [[Elektronikversender#RS_Components|RS]]
| 0,10 € (3000er-Rolle)
|-
| [http://www.mikrocontroller.net/part/IRF4905S IRF4905S]
| D2Pack
| irf
| 4,0
| 55
| 64
| 3,8
| 20
| -
| [[Elektronikversender#Reichelt|Rei]], [[Elektronikversender#Conrad|Con]]
| 1,10 €
|-
| [http://www.mikrocontroller.net/part/IRF4905 IRF4905]
| TO-220AB
| irf
| 4,0
| 55
| 74
| 3,8
| 20
| -
|[[Elektronikversender#Reichelt|Rei]]
| 0,93 €
|-
| [http://www.mikrocontroller.net/part/IRF5210S IRF5210S]
| D2Pack
| irf
| 10,0
| 100
| 40
| ?
| 60
| -
|[[Elektronikversender#Reichelt|Rei]]
| 1,25 €
|-
| [http://www.mikrocontroller.net/part/IRF7104 IRF7104]
| SO-8
| irf
| 3,0
| 20
| 2,3
| 2,0
| 250
| 2 FETs im Gehäuse
|[[Elektronikversender#Reichelt|Rei]]
| 0,36 €
|-
| [http://www.mikrocontroller.net/part/IRF7205 IRF7205]
| SO-8
| irf
| 3,0
| 30
| 4,6
| 2,5
| 70
| ?
|[[Elektronikversender#Reichelt|Rei]]
| 0,34 €
|-
| [http://www.mikrocontroller.net/part/FDC604P FDC604P]
| SuperSOT-6
| Fairchild
| 1,5
| 20
| 5,5
| 0,8-1,6
| 33
| -
| [[Elektronikversender#csd-electronics|csd]] (a.A.)
| 0,70 €
|-
| [http://www.mikrocontroller.net/part/NDS0610 NDS0610]
| SOT-23
| Fairchild
| 1,8
| 60
| 0,12
| 0,36
| 10000
| -
| [[Elektronikversender#csd-electronics|csd]]
| 0,07 €
|-
| [http://www.mikrocontroller.net/part/IRF5305 IRF5305]
| TO-220AB
| irf
| 3,0
| 55
| 31
| 110
| 60
| -
|[[Elektronikversender#Reichelt|Rei]]
| 0,59 €
|-
| [http://www.mikrocontroller.net/part/NDS352P NDS352P]
| SOT23
| Fairchild
| 4,5
| 20
| 0,85
| 0,5
| 500
| -
| [[Elektronikversender#Conrad|Con]]
| 0,76 €
|-
| [http://www.mikrocontroller.net/part/BSP171 BSP171]
| SOT-223
| Siemens
| 1,4
| 60
| 1,7
| 1,8
| 350
| -
|[[Elektronikversender#Reichelt|Rei]]
| 0,51 €
|-
| [http://www.mikrocontroller.net/part/IRFD9014 IRFD9014]
| HEXDIP/DIP4
| irf
| 2,0
| 60
| 1,1
| 1,3
| 500
| -
| [[Elektronikversender#Conrad|Con]]
| 0,65 €
|-
| [http://www.mikrocontroller.net/part/IRFD9024 IRFD9024]
| HEXDIP/DIP4
| irf
| 2,0
| 60
| 1,6
| 1,3
| 280
| -
| [[Elektronikversender#Conrad|Con]],[[Elektronikversender#Reichelt|Rei]]
| 0,50 €
|-
| [http://www.mikrocontroller.net/part/IRF7416 IRF7416]
| SO-8
| irf
| 1,0
| 30
| 10
| 2,5
| 20
| -
| [[Elektronikversender#Conrad|Con]],[[Elektronikversender#Reichelt|Rei]]
| 0,60 €
|-
| [http://www.mikrocontroller.net/part/SUP75P03 SUP75P03-007]
| TO-220AB
| VISHAY
| 3,0
| 30
| 75
| 187
| 7
| -
| nessel-elektronik.de
| 2,30 €
|-
| [http://www.mikrocontroller.net/part/IRF7220 IRF7220]
| SO-8
| irf
| 0,6
| 14
| 11
| 2,5
| 8,2
| spezifiziert ab 2,5V Vgs, Qg=84nC
| [[Elektronikversender#Conrad|Con]], [[Elektronikversender#Reichelt|Rei]]
| 0,58 €
|-
| [http://www.mikrocontroller.net/part/IRF7410 IRF7410]
| SO-8
| irf
| 0,4...0,9
| 12
| 16
| 2,5
| 7
| spezifiziert ab 1,8V Vgs, Qg=91nC
| distrelec.de [[Elektronikversender#Reichelt|Rei]]
| 1,80 € 0,85 €
|}

(Tabelle mit Click im Kopfbereich sortierbar; a.A. = Auf Anfrage)

== N-Kanal MOSFET==

{| {{Tabelle}} class="sortable" id="nkanalmosfets"
|- style="background-color:#eeeeee"
! Bezeichnung
! Package
! Hersteller
! UGS(th)/V
! UDS/V
! ID/A
! P/W
! RDS,on/mOhm
! Bemerkung
! Lieferant
! Preis/EUR
|-
| IRFP 4310Z
| TO-247AC
| irf
| 2-4
| 100
| 120
| 280
| 4.8
|
| [[Elektronikversender#Reichelt|Rei]]
| 1.80
|-
| [http://www.mikrocontroller.net/part/IRFP450 IRFP450]
| TO-247
| irf
| 3
| 500
| 14
| 190
| 400
|
| [[Elektronikversender#Reichelt|Rei]]
| 1.20
|-
| [http://www.mikrocontroller.net/part/IRF530 IRF530]
| TO-220
| irf
| 2.9
| 100
| 16
| 94
| 160
| Linearbetrieb möglich
| [[Elektronikversender#Reichelt|Rei]]
| 0.44
|-
| [http://www.mikrocontroller.net/part/IRL3103 IRL3103]
| TO-220AB
| irf
| 1.0
| 30
| 64
| 94
| 12
| Qg=33nC (!)
| [[Elektronikversender#Segor-electronics|Seg]]
| 0.95
|-
| [http://www.mikrocontroller.net/part/IRF730A IRF730A]
| TO-220AB
| irf
| 2.0
| 400
| 5.5
| 74
| 1000
| Qg=22nC (!)
| [[Elektronikversender#Reichelt|Rei]]
| 0.54
|-
| [http://www.mikrocontroller.net/part/IRFP064 IRFP064]
| TO-247AC
| irf
| 2.0
| 60
| 70
| 300
| 9
| Qg=190 nC
| [[Elektronikversender#Reichelt|Rei]]
| 1.65
|-
| [http://www.mikrocontroller.net/part/IRF3205 IRF3205]
| TO-220AB
| irf
| 2.0
| 55
| 110
| 200
| 8
|
| [[Elektronikversender#Reichelt|Rei]]
| 0.86
|-
| [http://www.mikrocontroller.net/part/IRL3803 IRL3803]
| TO-220AB
| irf
| 1.0
| 30
| 140
| 200
| 6
| Qg=140nC
| [[Elektronikversender#Reichelt|Rei]]
| 0.96
|-
| [http://www.mikrocontroller.net/part/IRF540 IRF540]
| TO-220AB
| irf
| 3
| 100
| 28
| 150
| 77
| Linearbetrieb möglich
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Kessler|Kes]]
| 0.52
|-
| [http://www.mikrocontroller.net/part/IRF7401 IRF7401]
| SO-8
| irf
| 2.7
| 20
| 8.7
| 2.0
| 22
|
| [[Elektronikversender#Reichelt|Rei]]
| 0.72
|-
| [http://www.mikrocontroller.net/part/IRF7403 IRF7403]
| SO-8
| irf
| 4.85
| 30
| 8.5
| 2.5
| 22
|
| [[Elektronikversender#Reichelt|Rei]]
| 0.42
|-
| [http://www.mikrocontroller.net/part/IRF7413 IRF7413]
| SO-8
| irf
| 3.0
| 30
| 13.0
| 2.5
| 11
|
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Kessler|Kes]]
| 0.41
|-
| [http://www.mikrocontroller.net/part/BUZ11 BUZ11]
| TO-220
| ST
| 5.0
| 50
| 33.0
| 90.0
| 30
| Linearbetrieb möglich, Achtung! Der BUZ11 von STM hat deutlich niedrigere SOA-Grenzen als von anderen Herstellern!
| [[Elektronikversender#Reichelt|Rei]]
| 0.50
|-
| [http://www.mikrocontroller.net/part/BS170 BS170]
| TO-92
| gs
| 2.0
| 60
| 0.3
| 0.83
| 5000
| Linearbetrieb möglich
| [[Elektronikversender#Reichelt|Rei]]
| 0.13
|-
| [http://www.mikrocontroller.net/part/BSN20 BSN20]
| SOT-23
| gs
| 1.8
| 50
| 0.18
| 0.35
| 6000
| Linearbetrieb möglich
| [[Elektronikversender#Reichelt|Rei]]
| 0.092
|-
| [http://www.mikrocontroller.net/part/BSS138 BSS138]
| SOT-23
| div
| 0.8-1.6
| 50
| 0.22
| 0.36
| 2000
| Linearbetrieb möglich
| [[Elektronikversender#Reichelt|Rei]]
| 0.06
|-
| [http://www.mikrocontroller.net/part/BSS123 BSS123]
| SOT-23
| div
| 0.8-1.6
| 100
| 0.17
| 0.36
| 10000 @ 4,5V,
| Linearbetrieb möglich
| [[Elektronikversender#Reichelt|Rei]]
| 0.06
|-
| [http://www.mikrocontroller.net/part/IRFP2907 IRFP2907]
| TO-247AC
| irf
| 4.0
| 75
| 209
| 470
| 4.5
|
| [[Elektronikversender#Reichelt|Rei]]
| 4.70
|-
| [http://www.mikrocontroller.net/part/2N7000 2N7000]
| TO-92
| ON
| 3.0
| 60
| 0.2
| 0.35
| 5000
| Linearbetrieb möglich
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Kessler|Kes]]
| 0.13
|-
| [http://www.mikrocontroller.net/part/BS107 BS107]
| TO-92
| ON, Phi
| 3.0
| 200
| 0.25
| 0.35
| 6400/14000
| Linearbetrieb möglich
| [[Elektronikversender#Reichelt|Rei]]
| 0.18
|-
| [http://www.mikrocontroller.net/part/BS108 BS108]
| TO-92
| ON, Phi
| 2.0
| 200
| 0.25
| 0.35
| 8000
| Linearbetrieb möglich
| [[Elektronikversender#Reichelt|Rei]]
| 0.14
|-
| [http://www.mikrocontroller.net/part/BUK100 BUK100]
| TO-220
| Phi
| 3.0
| 50
| 13.5
| 40
| 125
| Overload-Protection, ESD-Protection
| [[Elektronikversender#Reichelt|Rei]]
| 1.40
|-
| [http://www.mikrocontroller.net/part/IRL3705N IRL3705N]
| TO-220AB
| irf
| 2.0
| 55
| 89
| 170
| 10
| Qg=98nC
| [[Elektronikversender#Reichelt|Rei]]
| 1.20
|-
| [http://www.mikrocontroller.net/part/BUZ72 BUZ72A]
| TO-220
| Infineon
| 4.0
| 100
| 9.0
| 40
| 250
| Linearbetrieb möglich
| [[Elektronikversender#Reichelt|Rei]]
| 0.45
|-
| [http://www.mikrocontroller.net/part/IRLZ34N IRLZ34N]
| TO-220
| irf
| 2.5
| 55
| 30
| 68
| 35
| 5V Logic-Level, Linearbetrieb möglich
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Farnell|Far]],[[Elektronikversender#Conrad|Con]]
| 0.45
|-
| [http://www.mikrocontroller.net/part/IRLML2502 IRLML2502]
| SOT23
| irf
| 1.2
| 20
| 4.2
| 1
| 45
| Logic-Level
| [[Elektronikversender#csd-electronics|csd]] [[Elektronikversender#Reichelt|Rei (neu)]]
| 0.21
|-
| [http://www.mikrocontroller.net/part/IRF1404 IRF1404]
| TO-220AB
| irf
| 4.0
| 40
| 202
| 333
| 4
| -
| [[Elektronikversender#Reichelt|Rei]]
| 1.10
|-
| [http://www.mikrocontroller.net/part/IRL1004 IRL1004]
| TO-220
| irf
| 2.7
| 40
| 130
| 200
| 6.5
| -
| [[Elektronikversender#Reichelt|Rei]]
| 1.25
|-
| [http://www.mikrocontroller.net/part/IRL530 IRL530]
| TO220, D2Pack
| irf
| 2
| 100
| 15.0
| 88
| 160
|
| [[Elektronikversender#Reichelt|Rei]]
| 0.57/0.78
|-
| [http://www.mikrocontroller.net/part/IRF830 IRF830]
| TO220AB
| irf
| 2.0-4.5
| 500
| 5.0
| 74
| 1400
| Linearbetrieb möglich
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Kessler|Kes]]
| 0.57
|-
| [http://www.mikrocontroller.net/part/IRF840 IRF840]
| TO220AB
| irf
| 2.0-4.0
| 500
| 8.0
| 125
| 850
|
| [[Elektronikversender#Reichelt|Rei]]
| 0.57
|-
| [http://www.mikrocontroller.net/part/FDC645N FDC645N]
| SuperSOT-6
| Fairchild
| 1.5
| 30
| 5.5
| 0.8/1.6
| 30
| -
| [[Elektronikversender#csd-electronics|csd]] (a.A.), Far
| 0.7
|-
| [http://www.mikrocontroller.net/part/BSP297 BSP297]
| SOT-223
| Siemens/Infineon
| 0.8-2.4
| 200
| 0.65
| 1.8
| 6000
| 200V <math>U_{DS}</math>, SMD und Logic Level (seltene Kombinaton), Linearbetrieb möglich
| [[Elektronikversender#Farnell|Far]], [[Elektronikversender#Schuricht|Schu]], [[Elektronikversender#RS_Components|RS]]
| 0.56
|-
| [http://www.mikrocontroller.net/part/IRF7455 IRF7455]
| SO-8
| irf
| 4.5
| 30
| 15
| 2.5
| 7.5
|
| [[Elektronikversender#Kessler|Kes]]
| 1.04
|-
| [http://www.mikrocontroller.net/part/SI4442DY SI4442DY]
| SO-8
| vis
| 2.5
| 30
| 22
| 2.5
| 5/4.5V
|
| [[Elektronikversender#Kessler|Kes]]
| 1.64
|-
| [http://www.mikrocontroller.net/part/IRLU2905 IRLU2905]
| TO251, DPack
| irf
| 2.0
| 55
| 42
| 110
| 27
| Logic-Level
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Farnell|Far]]
| 1.89
|-
| [http://www.mikrocontroller.net/part/IRFD014 IRFD014]
| HEXDIP/DIP4
| irf
| 2.0-4.0
| 60
| 1.7
| 1.3
| 200
|
| [[Elektronikversender#Conrad|Con]],[[Elektronikversender#Reichelt|Rei]]
| 0.52
|-
| [http://www.mikrocontroller.net/part/IRFD024 IRFD024]
| HEXDIP/DIP4
| irf
| 2.0-4.0
| 60
| 2.5
| 1.3
| 100
|
| [[Elektronikversender#Conrad|Con]],[[Elektronikversender#Reichelt|Rei]]
| 0.54
|-
| [http://www.mikrocontroller.net/part/IRLD024 IRLD024]
| HEXDIP/DIP4
| irf
| 1.0-2.0
| 60
| 2.5
| 1.3
| 100
| Logic-Level
| [[Elektronikversender#Conrad|Con]],[[Elektronikversender#Reichelt|Rei]]
| 0.47
|-
| [http://www.mikrocontroller.net/part/IRLU3717 IRLU3717]
| I-Pak
| irf
| 2.0
| 20
| 120
| 1.5/89
| 4
| Qg=21nC
| [[Elektronikversender#Conrad|Con]],[[Elektronikversender#Reichelt|Rei]]
| 1.15
|-
| [http://www.mikrocontroller.net/part/IRFP3703 IRFP3703]
| TO-247AC
| irf
| 4.0
| 30
| 210
| 230
| 2.8
|
| [[Elektronikversender#Conrad|Con]]
| 5.08
|-
| [http://www.mikrocontroller.net/part/IRF3710 IRF3710]
| TO-220AB
| irf
| 5
| 100
| 57
| 200
| 23
|
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Conrad|Con]]
| 0.83
|-
| [http://www.mikrocontroller.net/part/IRLR7843 IRLR7843]
| D-Pack
| irf
| 2.3
| 30
| 164
| 140
| 3.3
| Qg: 34nC, Rds_on bei GS=4.5V: max. 4.0mOhm
| [http://www.flymotec.de/]
| 0.70
|-
| [http://www.mikrocontroller.net/part/IRF1010N IRF1010N]
| TO-220AB
| irf
| 4
| 55
| 85
| 180
| 11
|
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Farnell|Far]]
| 1.99
|-
| [http://www.mikrocontroller.net/part/IRF1010Z IRF1010Z]
| TO-220AB
| irf
| 4
| 55
| 75
| 140
| 7.5
|
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Conrad|Con]], [[Elektronikversender#Farnell|Far]]
| 1.99
|-
| [http://www.mikrocontroller.net/part/IRLIZ44N IRLIZ44N]
| TO-220-Fullpak
| irf
| 1.0 - 2.0
| 55
| 30
| 45
| 25
| Logic Level
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Conrad|Con]]
| 0.80
|-
| [http://www.mikrocontroller.net/part/IRLU024N IRLU024N]
| TO-251AA
| irf
| 1.0 - 2.0
| 55
| 17
| 45
| 80
| Logic Level, Qg=15 nC (!)
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Conrad|Con]]
| 0.40
|-
| IRFZ48N
| TO-220AB
| irf
| 3
| 55
| 64
| 130
| 14
|
| [[Elektronikversender#Reichelt|Rei]],[[Elektronikversender#Conrad|Con]]
| 0.60
|-
| [http://www.irf.com/product-info/datasheets/data/irl2505.pdf IRL2505]
| TO-220AB
| irf
| 2,5
| 55
| 104
|
| 8
|
| [[Elektronikversender#Farnell|Far]]
| 3.99
|-
| [http://www.irf.com/product-info/datasheets/data/irf7607.pdf IRF7607]
| Micro8
| irf
| 12
| 20
| 6.5
| 1.8
| 3
|
| [[Elektronikversender#Conrad|Con]]
| 1.89
|-
| [http://www.irf.com/product-info/datasheets/data/irf3708.pdf IRF3708]
| TO-220AB
| irf
| 12
| 30
| 62
| 87
| 8
|
| [[Elektronikversender#Conrad|Con]]
| 1.49
|-
| [http://www.mikrocontroller.net/part/GF2304 GF2304]
| SOT-23
| gs
| 1.0
| 30
| 2.5
| 1.25
| 135
| Qg=3.7nC
| [[Elektronikversender#Pollin_Electronic|Pol]]
| 0.05

|}

(Tabelle mit Click im Kopfbereich sortierbar, a.A.=Auf Anfrage)

== N-Kanal J-FET==

{| {{Tabelle}} border="1" class="sortable" id="fetpaare"
|- style="background-color:#eeeeee"
! Bezeichnung
! Package
! Hersteller
! UGS(co)/V
! UDS/V
! ID(max)/mA
! Lieferant
! Einzelpreis
|-
| [http://www.mikrocontroller.net/part/BF245 BF245A]
| TO-92
| diverse
| -2,2
| 30
| 6,5
| [[Elektronikversender#Reichelt|Rei]]
| 0,15 €
|-
| [http://www.mikrocontroller.net/part/BF245 BF245B]
| TO-92
| diverse
| -3,8
| 30
| 15
| [[Elektronikversender#Reichelt|Rei]]
| 0,15 €
|-
| [http://www.mikrocontroller.net/part/BF245 BF245C]
| TO-92
| diverse
| -7,5
| 30
| 25
| [[Elektronikversender#Reichelt|Rei]]
| 0,15 €
|-
| [http://www.mikrocontroller.net/part/BF246 BF246A]
| TO-92
| diverse
| -4
| 25
| 80
| [[Elektronikversender#Reichelt|Rei]]
| 0,15 €
|-
| [http://www.mikrocontroller.net/part/BF246 BF246B]
| TO-92
| diverse
| -7
| 25
| 140
| [[Elektronikversender#Reichelt|Rei]]
| 0,17 €
|-
| [http://www.mikrocontroller.net/part/BF246 BF246C]
| TO-92
| diverse
| -12
| 25
| 250
| ??
| ??
|-
| [http://www.mikrocontroller.net/part/BF511 BF511]
| SOT-23
| diverse
| -1,5
| 20
| 7
| [[Elektronikversender#Reichelt|Rei]]
| 0,36 €
|-
| [http://www.mikrocontroller.net/part/BFR30 BFR30]
| SOT-23
| diverse
| -4
| 25
| 10
| ?
| ?
|-
| [http://www.mikrocontroller.net/part/BFR31 BFR31]
| SOT-23
| diverse
| -2
| 25
| 5
| ?
| ?
|-
| [http://www.mikrocontroller.net/part/MMBF4416 MMBF4416]
| SOT-23
| Fairchild
| -5,5
| 15
| 5
| [[Elektronikversender#Conrad|Con]]
| 0,52 €
|}

(Tabelle mit Click im Kopfbereich sortierbar)

== FET-Paare ==

{| {{Tabelle}} border="1" class="sortable" id="fetpaare"
|- style="background-color:#eeeeee"
! Bezeichnung
! Package
! Hersteller
! UGS/V
! UDS/V
! ID/A
! P/W
! RDSon/mOhm
! Bemerkung
! Lieferant
! Einzelpreis
|-
| [http://www.mikrocontroller.net/part/IRF7389 IRF7389]
| SO-8
| IRF
| 3,0
| 30
| 7,3/-5,3
| 2,0
| 29/58
| P+N
| [[Elektronikversender#Reichelt|Rei]]
| 0,56 €
|-
| [http://www.mikrocontroller.net/part/IRF7501 IRF7501]
| micro8
| IRF
| 2,7
| 20
| 2,4
| ?
| 135 @4,5VGS
| 2*N
| [[Elektronikversender#Kessler|Kessler]], [[Elektronikversender#Conrad|Con]]
| 1,64 €
|-
| [http://www.mikrocontroller.net/part/IRF7506 IRF7506]
| micro8
| IRF
| 4,5
| 30
| 1,7
| ?
| 270 @10VGS
| 2*P
| [[Elektronikversender#Kessler|Kessler]], [[Elektronikversender#Conrad|Con]]
| 0,56 €
|-
| [http://www.mikrocontroller.net/part/IRF7103 IRF7103]
| SO-8
| IRF
| 4,5
| 50
| 2,3
| 2
| 130 @10VGS
| 2*N
|[[Elektronikversender#Reichelt|Rei]], [[Elektronikversender#Conrad|Con]]
| 0,32 €
|-
| [http://www.mikrocontroller.net/part/IRF7104 IRF7104]
| SO-8
| IRF
| 4,5
| 20
| 2,3
| 2
| 250 @10VGS
| 2*P
|[[Elektronikversender#Reichelt|Rei]]
| 0,32 €
|-
| [http://www.mikrocontroller.net/part/IRF7316 IRF7316]
| SO-8
| IRF
| 4,5
| 30
| 4,9
| ?
| 58 @10VGS
| 2*P
|[[Elektronikversender#Reichelt|Rei]]
| 0,49 €
|-
| [http://www.mikrocontroller.net/part/IRF7313 IRF7313]
| SO-8
| IRF
| 4,5
| 30
| 6,5
| ?
| 46 @4.5VGS
| 2*N
| [[Elektronikversender#Kessler|Kessler]], [[Elektronikversender#Conrad|Con]]
| 0,66 €
|-
| [http://www.mikrocontroller.net/part/FDD8424H FDD8424H]
| Dual DPAK4L
| Fairchild
|
| 40
| 9/-6,5
| 3
| 24/54 @10VGS 30/70 @4,5VGS
| P+N
| [[Elektronikversender#Digi-Key|Digi-Key]]
| 0,73 €
|-
| [http://www.mikrocontroller.net/part/SUD50NP04-94 SUD50NP04-94]
| TO252-4L DPAK4L
| Vishay
| 2
| 40
| 8
| 8?
| 41/53 @10VGS 45/72 @4,5VGS
| P+N
| [[Elektronikversender#Farnell|Farnell]]
| 0,56 €
|-
| [http://www.mikrocontroller.net/part/IRFI4024H-117P IRFI4024H-117P]
| TO-220-5
| IRF
| 2
| 55
| 11
| 14
| 50 @10VGS
| 2*N
| [[Elektronikversender#Reichelt|Reichelt]]
| 2,10 €
|}

(Tabelle mit Click im Kopfbereich sortierbar)

== MOSFET-Treiber ==
* Detaillierte [[Treiber]]-Dimensionierung
{| {{Tabelle}} border="1" class="sortable" id="fettreiber"
|- style="background-color:#eeeeee"
! Bezeichnung
! Low / High-Side
! Strom
! Spannung
! Logikeingang
! Sockel
! Lieferant / Datenblatt
! Einzelpreis
|-
| [http://www.mikrocontroller.net/part/IR2101 IR2101]
| High & Low-Side Driver
| 130/270mA
| 600V
| 3,3V
| DIL8/SO8
| [[Elektronikversender#Conrad|Con]]
| 2,30 €
|-
| [http://www.mikrocontroller.net/part/IR2104 IR2104]
| Half Bridge Driver
| 130/270mA
| 600V
| 3,3V
| DIL8/SO8
| [[Elektronikversender#Conrad|Con]]
| 2,00 €
|-
| [http://www.mikrocontroller.net/part/IR2110 IR2110]
| High & Low-Side Driver
| 2A
| 500V
| 3,3V
| DIL14/SO16
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
| 1,55 €
|-
| [http://www.mikrocontroller.net/part/IR2111 IR2111]
| Half Bridge Driver
| 200/430mA
| 600V
| 10-20V CMOS Eingang
| DIL8/SO8, maximale Kriechwege
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
| 1,10 €
|-
| [http://www.mikrocontroller.net/part/IR2112 IR2112]
| High & Low-Side Driver
| 200/420mA
| 600V
| 3,3V
| DIL14/SO16
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
| 1,45 €
|-
| [http://www.mikrocontroller.net/part/IR2113 IR2113]
| High & Low-Side Driver
| 2A
| 600V
| 3,3V
| DIL14/SO16
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
| 1,85 €
|-
| [http://www.mikrocontroller.net/part/IR2117 IR2117]
| Single High Side Driver
| 200/420mA
| 600V
| 10-20V CMOS Eingang
| DIL8/SO8, maximale Kriechwege
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
| 1,20 €
|-
| [http://www.mikrocontroller.net/part/IR2121 IR2121]
| Low Side Driver
| 1A/2A
| ?
| 2,5V
| DIL8/SO8, Strombegrenzung
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
| 2,15 €
|-
| [http://www.mikrocontroller.net/part/IR2125 IR2125]
| Single Channel High Side Driver
| 1A/2A
| 500V
| 2,5V
| DIL8/SO8, Strombegrenzung, maximale Kriechwege
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
| 4,20 €
|-
| [http://www.mikrocontroller.net/part/IR2127 IR2127]
| Single Channel High Side Driver
| 200/420mA
| ?
| 3,3V
| DIL8/SO8, maximale Kriechwege, Fehlerausgang
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
| 2,40 €
|-
| [http://www.mikrocontroller.net/part/IR2130 IR2130]
| 3-Phase Bridge Driver
| 200/420mA
| 600V
| 2,5V
| DIL28/SO28
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
| 2,50 €
|-
| [http://www.mikrocontroller.net/part/IR2151 IR2151]
| Self Oscillating Half Bridge Driver
| 100/210mA
| 600V
| ?
| DIL8/SO8
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
| 2,50 €
|-
| [http://www.mikrocontroller.net/part/IR2153 IR2153]
| Self Oscillating Half Bridge Driver
| 100/210mA
| 600V
| n/a
| DIL8/SO8
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
| 1,20 €
|-
| [http://www.mikrocontroller.net/part/IR2155 IR2155]
| Self Oscillating Half Bridge Driver
| 210/420mA
| 600V
| n/a
| DIL8/SO8
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
| 3,50 €
|-
| [http://www.mikrocontroller.net/part/IR2181 IR2181]
| High & Low-Side Driver
| 1.4A/1.8A
| 600V
| 3,3V
| DIL8/SO8
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
| 2,10 €
|-
| [http://www.mikrocontroller.net/part/IR2183 IR2183]
| Half Bridge Driver
| 1.4A/1.8A
| 600V
| 3,3V
| DIL8/SO8
| [[Elektronikversender#Reichelt|Rei]]
| 4,00 €
|-
| [http://www.mikrocontroller.net/part/IR2184 IR2184]
| Half Bridge Driver
| 1.4A/1.8A
| 600V
| 3,3V/5V
| DIL8/SO8
| [[Elektronikversender#Reichelt|Rei]] [[Elektronikversender#Conrad|Con]]
| 3,20 €
|-
| [http://www.mikrocontroller.net/part/IR2136 IR2136]
| 3 Phase Driver
| 120/250mA
| 600V
| 3,3V
| DIP28/SOIC28,
| [[Elektronikversender#Conrad|Con]]
| 1,80 €
|-
| [http://www.mikrocontroller.net/part/ICL7667 ICL7667]
| Dual Power MOSFET Driver
| ?
| 4.5-15V, 7Ω
| 3,3V
| DIL8/SO8
| [[Elektronikversender#Reichelt|Rei]]
| 2,00 €
|-
| [http://www.mikrocontroller.net/part/HIP4081A HIP4081A]
| Full Bridge Driver
| 2,5A
| 80V
| ?
| DIP20/SOIC20
| [[Elektronikversender#Farnell|Far]]
| 8,00 €
|-
| [http://www.mikrocontroller.net/part/HIP4082 HIP4082]
| Full Bridge Driver
| 1,2A
| 80V
| ?
| DIP16/SOIC16
| [[Elektronikversender#Farnell|Far]] [[Elektronikversender#Farnell|Far]]
| 6,20 €
|-
| [http://www.mikrocontroller.net/part/HIP4083 HIP4083]
| 3 Phase High side N-channel MOSFET driver
| 0,3A
| 80V
| ?
| DIP16/SOIC16
| [[Elektronikversender#Farnell|Far]]
| 4,80 €

|-
| [http://www.mikrocontroller.net/part/HIP4086 HIP4086]
| 3 Phase Driver
| 0.5A
| 80V
| ?
| DIP24/SOIC24
| [[Elektronikversender#Farnell|Far]]
| 8,00 €
|-
| [http://www.mikrocontroller.net/part/TC4451 TC4451/TC4452]
| High Speed MOSFET Driver
| 12A peak, 2,5A DC
| ?
| 4,5-18V
| DIL8/SO8
| [[Elektronikversender#Farnell|Far]]
| 3,00 €
|-
| [http://www.mikrocontroller.net/part/LM5104 LM5104]
| Half Bridge Driver
| 1,6/1,8A
| 100V
| 2,5V
| SO8/LLP10
| [[Elektronikversender#RS_Components|RS]]
| 3,20 €
|-
| [http://www.mikrocontroller.net/part/MCP1407 MCP1407-E/P]
| High Speed MOSFET Driver
| 6A peak, 1,3A DC
| ?
| 4,5-18V
| DIL8/SO8
| [[Elektronikversender#Reichelt|Rei]]
| 0,95 €
|-
| [http://www.mikrocontroller.net/part/MAX626 MAX626]
| Dual Power MOSFET drivers, inverting
| ?
| ?
| 4,5-18 V
| DIL8/SO8
| [[Elektronikversender#Reichelt|Rei]]
| 3,40 €
|}

== Anmerkungen ==
* UGS - 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.
* Logic Level - FET schaltet bei niedrigen Gatespannungen von typisch 4,5V (z. B. CMOS Logikpegel) hinreichend durch. Normale MOSFETs brauchen hierfür typisch 10V.
* UGS(co) - Gate Source Cut Off Spannung, bei welcher der Drainstrom ID eines JFETs praktisch Null ist. Die Messbedingung ist jedoch nicht genormt (0,5nA..200µA).
* N-Kanal MOSFETs mit niedrigem RDS,On 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]]).
* 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. B. für den IRF540 nicht mehr 28A, sondern nur noch ca. 12-15A.
* Restströme sind auch stark von der Temperatur abhä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.
* 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. B. 4-10nC). Diese können in gewissen Grenzen recht gut direkt an digitalen [[Ausgangsstufen Logik-ICs | Logikausgängen]] betrieben werden. 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.

== Lieferantenübersicht ==
* [[Elektronikversender#Reichelt|Rei]]<nowiki>chelt</nowiki>
* [[Elektronikversender#Conrad|Con]]<nowiki>rad</nowiki>
* [[Elektronikversender#Kessler|Kes]]<nowiki>sler</nowiki>
* [[Elektronikversender#csd-electronics|csd]]<nowiki>-electronics</nowiki>
* [[Elektronikversender#Farnell|Far]]<nowiki>nell</nowiki> (nur gewerbliche Kunden oder Studenten)
* HBE-Shop (FARNELL-Fachhändler, auch als nichtgewerblicher Kunde)
* [[Elektronikversender#Schuricht|Schu]]<nowiki>richt</nowiki>
* [[Elektronikversender#RS_Components|RS]]
* [[Elektronikversender#Spoerle|Spo]]<nowiki>erle</nowiki>

== Herstellerübersicht ==
* [irf] [http://www.irf.com International Rectifier]
* [Siliconix] [http://www.vishay.com/company/brands/siliconix/ Vishay Siliconix]
* [st] [http://www.st.com/web/en/home.html STMicroelectronics]

== IRF MOSFET-Codierung ==
* IRF: Alle "Standardtransistoren", also TO-220-Gehäuse
* IRFB: Hochspannungs-MosFETs
* IRFD: MosFETs im Dip-4-Gehäuse
* IRFI: MosFETs im isolierten TO-220-Gehäuse
* IRFP: MosFETs im TO-247AC-Gehäuse
* IRFR: MosFETs im D-Pak
* IRFU: MosFETs im I-Pak
* IRFZ: Also die die ich kenne liegen alle so bei 50-60V mit relativ niedrigem Rds(on), also so für mittlere Leistungen
* IRG: Afaik sind das IGBTs
* IRL: Logic-Level MosFETs
* IRLD: Logic-Level MosFETs im Dip-4 Gehäuse
* IRLI: Logic-Level MosFETs im isolierten TO-220-Gehäuse
* IRLR: Logic-Level MosFETs im D-Pak
* IRLU: Logic-Level MosFETs im I-Pak

== Links ==
* [[FET]]
* [[IGBT]]
* [[Treiber]]
* [[H-Brücken Übersicht]]
* [http://www.mikrocontroller.net/topic/280480#2960070 Forumsbeitrag]: Clevere MOSFET-Treiber mit kleinsten Trafos
* [http://www.mikrocontroller.net/topic/283585#3004839 Forumsbeitrag]: Galvanisch getrennte Ansteuerung eines MOSFETs mittels Übertrager und 100% Tastverhältnis

== Weblinks ==
* [http://www.sprut.de/electronic/switch/nkanal/nkanal.html N-Kanal MOSFET leicht erklärt bei sprut.de]
* [http://www.sprut.de/electronic/switch/pkanal/pkanal.html P-Kanal MOSFET leicht erklärt bei sprut.de]
* [http://elektronik-kompendium.de/sites/bau/0510161.htm MOSFET im ElKo]
* [http://elektronik-kompendium.de/public/schaerer/battoff.htm Abschaltverzögerung beim ElKo]
* [http://elektronik-kompendium.de/sites/bau/0207011.htm FET beim ElKo]
* [http://de.wikipedia.org/wiki/Mosfet MOSFET bei Wikipedia]


== Parametrische Suche beim Hersteller ==
* [http://www.infineon.com/cms/de/product/channel.html?channel=db3a304319c6f18c011a14e5341b25f1 Infineon]
* [http://www.nxp.com/#/ps/ps=%5Bi%3D48014%5D%7Cpp%3D%5Bt%3Dpfp%2Ci%3D48014%5D NXP standard Mosfets]
* [http://www.onsemi.com/PowerSolutions/parametrics.do?id=809&lctn=home ONsemi]
* [http://www.diodes.com/zetex/?ztx=3.0/3-3-1@tcatid~7 Diodes (vormals Zetex)]
* [http://www.irf.com/product-info/hexfet/ IRF]
* [http://www.vishay.com/mosfets/ Vishay]

[[Kategorie:Liste mit Bauteilen]]

ATxMega Stick - First Steps

2012-11-29T18:45:23Z

Maybee:

[[Datei:ATxMegaStick-1.jpg|thumb|Platine des ATxMega Stick]]
[[Datei:ATxMegaStick_revC-p1.png|thumb|Schaltplan - Seite 1]]
[[Datei:ATxMegaStick_revC-p2.png|thumb|Schaltplan - Seite 2]]
Der ATxMega Stick ist eine kleine Platine (27 mm x 80 mm) mit ATxmega128A3, USB-Device-Anschluss und Micro-SD-Kartenslot.

== Eigenschaften ==

* Mikrocontroller ATxmega128A3
* USB-Baustein [http://kweb/wiki/images/b/ba/MCP2200_22228A.pdf MCP2200]
* Mini-USB-B-Device-Anschluss
* Micro-SD-Kartenslot
* Programmierung via PDI (z.B. AVRISP mkII)
* Reset-Taster
* 2 LEDs zur Signalisierung von USB-Transfers
* 2 frei verwendbare LEDs
* On-board-Spannungsregler (3.3 V, Versorgung über USB oder extern)
* 6 x 8-Bit-Ports auf Stiftleisten verfügbar, davon ist ein Port belegt (2-mal LED, RX und TX zum USB-Baustein, SPI zum Micro-SD-Kartenslot)

== Hinweise zum Aufbau ==

=== Anmerkungen zum Schaltplan vom 15.09.2011 23:08:38 ===

* Seite 1: C1 hat 22µF 
* Seite 1: C14, C15 haben 3.3µF
* Seite 2: Verbindungsbezeichnung bei "<tt>I/Os</tt>" µC Pin 27 und JP4 Pin 4 und bei "<tt>LEDs</tt>" muss <tt>LED3</tt> lauten statt <tt>LED1</tt>
* Seite 2: Verbindungsbezeichnung bei "<tt>I/Os</tt>" µC Pin 26 und JP4 Pin 3 und bei "<tt>LEDs</tt>" muss <tt>LED4</tt> lauten statt <tt>LED2</tt>

=== Stromversorgung ===

Auf JP1 muss ein Jumper bestückt werden:
* zum Platinenrand hin für Versorgung über USB
* zur Platinenmitte hin für externe Versorgung

Hinweis:

Der Jumper sollte unbedingt gesteckt sein, wenn USB verwendet wird. Steht dieser auf externer Versorung, muss diese dabei auch anliegen. Wird der MCP2200 per USB versorgt, ohne dass am ATxMega Versorgungsspannung anliegt, kommt es über die UART-Leitung zu einem Stromfluss über das entsprechende I/O-Pin des ATxMega, da dieser sich ohne Spannung intern in einem undefinierten Zustand befindet. Auf VCC liegen dann etwa 2.8 V an. Durch den Stromfluss erwärmt sich der MCP2200 deutlich, was zur eventuellen Beschädigung des ICs führen kann.

=== Löten des SD-Halters ===

* Zuerst muss man den Halten ausrichen und einen Punkt am Rand festlöten.
* Dann muss man alle 4 Ecken festlöten
* Jetzt kann man mit der Lötspitze oben durch die Aussparungen und führt den Zinn durch die Öffnung für die SD-Karte.
* So lötet man dann alle 8 Kontakte.
* Lötbrücken sind hier nicht schön, lässt sich aber dann noch mit Entlötlitze entfernen (Entlötlitze statt Zinn durch die Öffnung führen)

== Betrieb unter Linux ==

Damit man als User auf den Stick zugreifen kann, empfiehlt es sich, einen UDEV-Eintrag für den Stick anzulegen, z.B. neue Datei /etc/udev/rules.d/15_USB_uC.rules anlegen:

ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="00df", GROUP="MeineGruppe", MODE="0660", SYMLINK+="ATxMegaStick%n"

Für "MeineGruppe" einen geeigneten Werte verwenden, d.h. eine Gruppe, der man selbst angehört.

Jetzt kann man nach dem Anschließen folgende Links sehen:

ls -l /dev/ATxMegaStick*
lrwxrwxrwx 1 root root 7 2011-10-17 00:04 /dev/ATxMegaStick0 -> ttyACM0
lrwxrwxrwx 1 root root 11 2011-10-17 00:04 /dev/ATxMegaStick1 -> usb/hiddev1
lrwxrwxrwx 1 root root 7 2011-10-17 00:04 /dev/ATxMegaStick2 -> hidraw2
lrwxrwxrwx 1 root root 15 2011-10-17 00:04 /dev/ATxMegaStick3 -> bus/usb/001/042

Und die Zugriffrechte sehen so aus:

ls -lL /dev/ATxMegaStick*
crw-rw---- 1 root dialout 166, 0 2011-10-17 00:04 /dev/ATxMegaStick0
crw-rw---- 1 root mgr 180, 97 2011-10-17 00:04 /dev/ATxMegaStick1
crw-rw---- 1 root mgr 251, 2 2011-10-17 00:04 /dev/ATxMegaStick2
crw-rw-r-- 1 root mgr 189, 41 2011-10-17 00:04 /dev/ATxMegaStick3

== Fuses ==

Default-Werte der Fuses:

=== <tt>signature</tt>: Signatur ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U signature:r:-:h
0x1e,0x97,0x42
:0x1e9742 = ATxmega128A3

=== <tt>fuse0</tt>: JTAG User ID ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse0:r:-:h
0xff
:JTAG User ID (JTAGUID) = 0xff '''(das Manual sagt: 0x00)'''

=== <tt>fuse1</tt>: Watchdog Configuration ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse1:r:-:h
0x0
:Watchdog Window Timeout Period (WDWPER) = n.a.
:Watchdog Timeout Period (WDPER) = n.a.

=== <tt>fuse2</tt>: Reset Configuration ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse2:r:-:h
0xff
:Reset Vector (BOOTRST) = Application Reset
:BOD operation in power-down mode (BODPD) = BOD disabled

=== <tt>fuse4</tt>: Start-up Configuration ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse4:r:-:h
0xfe
:External Reset Disable (RSTDISBL) = no
:Start-up time (STARTUPTIME) = 0
:Watchdog Timer lock (WDLOCK) = no
:JTAG enabled (JTAGEN) = yes

Bei Bedarf ändern:
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse4:w:0xff:m
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse4:r:-:h
0xff
:JTAG enabled (JTAGEN) = no

=== <tt>fuse5</tt>: BODACT, BODLEVEL, EESAVE ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse5:r:-:h
0xff
:BOD operation in active mode (BODACT) = BOD disabled
:EEPROM memory is preserved through the Chip Erase (EESAVE) = no
:BOD voltage level (BODLEVEL) = 1.6V

Bei Bedarf ändern:
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse5:w:0xf7:m
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse5:r:-:h
0xf7
:EEPROM memory is preserved through the Chip Erase (EESAVE) = yes

== Software ==

=== Clock System ===

Takt zu Testzwecken auf Port C Pin 7 (d.h. JP3 Pin 3) ausgeben.
PORTC.DIRSET = 0x80;
PORTCFG.CLKEVOUT = 0x01;

==== 32 MHz mit dem externen Quarz ====

Unter Verwendung der Software zu AVR1003 (-> Siehe auch) kann man den Takt auf 32 MHz einstellen:

#include "clksys_driver.h"

void init_clock( void )
{
CLKSYS_XOSC_Config( OSC_FRQRANGE_12TO16_gc, false, OSC_XOSCSEL_XTAL_16KCLK_gc );
CLKSYS_Enable( OSC_XOSCEN_bm );
CLKSYS_PLL_Config( OSC_PLLSRC_XOSC_gc, 2 );
CLKSYS_Enable( OSC_PLLEN_bm );
CLKSYS_Prescalers_Config( CLK_PSADIV_1_gc, CLK_PSBCDIV_1_1_gc );
do {} while ( CLKSYS_IsReady( OSC_PLLRDY_bm ) == 0 );
CLKSYS_Main_ClockSource_Select( CLK_SCLKSEL_PLL_gc );
CLKSYS_Disable( OSC_XOSCEN_bm );
} /* init_clock() */

=== USART ===

==== USART über USB ====

So stellt man unter Verwendung der Software zu AVR1307 (-> Siehe auch) bei 32 MHz Takt den USART für die Übertragung per USB ein:

#include "usart_driver.h"

#define USART USARTD0

void init_usart( void )
{
PORTD.DIRSET = PIN3_bm;
PORTD.DIRCLR = PIN2_bm;
USART_Format_Set( &USART, USART_CHSIZE_8BIT_gc, USART_PMODE_DISABLED_gc, false );
/*
* BSEL[11:0]-Wert bei 32MHz Takt und BSCALE[3:0]==0:
* 207 : 9600
* 103 : 19200
* 51 : 38400
* 34 : 57600
* 16 : 115200
*/
USART_Baudrate_Set( &USART, 34 , 0 );
USART_Rx_Enable( &USART );
USART_Tx_Enable( &USART );
} /* init_usart() */

== Siehe auch ==

* [http://www.mikrocontroller.net/topic/227310 Ursprungsbeitrag im Forum]
* [http://www.jtronics.de/avr-projekte/xmega-tutorial.html XMEGA Tutorial in C] - Tutorial ATxmega (ATxmega128A3U)
* [http://www.atxmega-board.de/stick Die Seite des Sticks] mit Schaltplan und Stückliste
* <del>[http://www.stromflo.de/dokuwiki/doku.php?id=xmega-c-tutorial XMEGA-C-Tutorial auf stromflo.de]</del> :-(
* [http://www.atmel.com/dyn/products/product_card.asp?part_id=4302 Produktseite des ATxmega128A3] mit jeder Menge an Dokumentation und Application Notes
* [http://www.atmel.com/dyn/resources/prod_documents/doc8072.pdf AVR1003: Using the XMEGA Clock System] (PDF) und [http://www.atmel.com/dyn/resources/prod_documents/AVR1003.zip Software] (ZIP)
* [http://www.atmel.com/dyn/resources/prod_documents/doc8049.pdf AVR1307: Using the XMEGA USART] (PDF) und [http://www.atmel.com/dyn/resources/prod_documents/AVR1307.zip Software] (ZIP)
* [http://www.microchip.com/wwwproducts/devices.aspx?dDocName=en546923 Produktseite des MCP2200] mit Dokumentation und Tools

[[Kategorie:AVR-Projekte]]

ATxMega Stick - First Steps

2012-11-29T18:40:19Z

Maybee: Schaltplan

[[Datei:ATxMegaStick-1.jpg|thumb|Platine des ATxMega Stick]]
[[Datei:ATxMegaStick_revC-p1.png|thumb|Schaltplan - Seite 1]]
[[Datei:ATxMegaStick_revC-p2.png|thumb|Schaltplan - Seite 1]]
Der ATxMega Stick ist eine kleine Platine (27 mm x 80 mm) mit ATxmega128A3, USB-Device-Anschluss und Micro-SD-Kartenslot.

== Eigenschaften ==

* Mikrocontroller ATxmega128A3
* USB-Baustein [http://kweb/wiki/images/b/ba/MCP2200_22228A.pdf MCP2200]
* Mini-USB-B-Device-Anschluss
* Micro-SD-Kartenslot
* Programmierung via PDI (z.B. AVRISP mkII)
* Reset-Taster
* 2 LEDs zur Signalisierung von USB-Transfers
* 2 frei verwendbare LEDs
* On-board-Spannungsregler (3.3 V, Versorgung über USB oder extern)
* 6 x 8-Bit-Ports auf Stiftleisten verfügbar, davon ist ein Port belegt (2-mal LED, RX und TX zum USB-Baustein, SPI zum Micro-SD-Kartenslot)

== Hinweise zum Aufbau ==

=== Anmerkungen zum Schaltplan vom 15.09.2011 23:08:38 ===

* Seite 1: C1 hat 22µF 
* Seite 1: C14, C15 haben 3.3µF
* Seite 2: Verbindungsbezeichnung bei "<tt>I/Os</tt>" µC Pin 27 und JP4 Pin 4 und bei "<tt>LEDs</tt>" muss <tt>LED3</tt> lauten statt <tt>LED1</tt>
* Seite 2: Verbindungsbezeichnung bei "<tt>I/Os</tt>" µC Pin 26 und JP4 Pin 3 und bei "<tt>LEDs</tt>" muss <tt>LED4</tt> lauten statt <tt>LED2</tt>

=== Stromversorgung ===

Auf JP1 muss ein Jumper bestückt werden:
* zum Platinenrand hin für Versorgung über USB
* zur Platinenmitte hin für externe Versorgung

Hinweis:

Der Jumper sollte unbedingt gesteckt sein, wenn USB verwendet wird. Steht dieser auf externer Versorung, muss diese dabei auch anliegen. Wird der MCP2200 per USB versorgt, ohne dass am ATxMega Versorgungsspannung anliegt, kommt es über die UART-Leitung zu einem Stromfluss über das entsprechende I/O-Pin des ATxMega, da dieser sich ohne Spannung intern in einem undefinierten Zustand befindet. Auf VCC liegen dann etwa 2.8 V an. Durch den Stromfluss erwärmt sich der MCP2200 deutlich, was zur eventuellen Beschädigung des ICs führen kann.

=== Löten des SD-Halters ===

* Zuerst muss man den Halten ausrichen und einen Punkt am Rand festlöten.
* Dann muss man alle 4 Ecken festlöten
* Jetzt kann man mit der Lötspitze oben durch die Aussparungen und führt den Zinn durch die Öffnung für die SD-Karte.
* So lötet man dann alle 8 Kontakte.
* Lötbrücken sind hier nicht schön, lässt sich aber dann noch mit Entlötlitze entfernen (Entlötlitze statt Zinn durch die Öffnung führen)

== Betrieb unter Linux ==

Damit man als User auf den Stick zugreifen kann, empfiehlt es sich, einen UDEV-Eintrag für den Stick anzulegen, z.B. neue Datei /etc/udev/rules.d/15_USB_uC.rules anlegen:

ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="00df", GROUP="MeineGruppe", MODE="0660", SYMLINK+="ATxMegaStick%n"

Für "MeineGruppe" einen geeigneten Werte verwenden, d.h. eine Gruppe, der man selbst angehört.

Jetzt kann man nach dem Anschließen folgende Links sehen:

ls -l /dev/ATxMegaStick*
lrwxrwxrwx 1 root root 7 2011-10-17 00:04 /dev/ATxMegaStick0 -> ttyACM0
lrwxrwxrwx 1 root root 11 2011-10-17 00:04 /dev/ATxMegaStick1 -> usb/hiddev1
lrwxrwxrwx 1 root root 7 2011-10-17 00:04 /dev/ATxMegaStick2 -> hidraw2
lrwxrwxrwx 1 root root 15 2011-10-17 00:04 /dev/ATxMegaStick3 -> bus/usb/001/042

Und die Zugriffrechte sehen so aus:

ls -lL /dev/ATxMegaStick*
crw-rw---- 1 root dialout 166, 0 2011-10-17 00:04 /dev/ATxMegaStick0
crw-rw---- 1 root mgr 180, 97 2011-10-17 00:04 /dev/ATxMegaStick1
crw-rw---- 1 root mgr 251, 2 2011-10-17 00:04 /dev/ATxMegaStick2
crw-rw-r-- 1 root mgr 189, 41 2011-10-17 00:04 /dev/ATxMegaStick3

== Fuses ==

Default-Werte der Fuses:

=== <tt>signature</tt>: Signatur ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U signature:r:-:h
0x1e,0x97,0x42
:0x1e9742 = ATxmega128A3

=== <tt>fuse0</tt>: JTAG User ID ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse0:r:-:h
0xff
:JTAG User ID (JTAGUID) = 0xff '''(das Manual sagt: 0x00)'''

=== <tt>fuse1</tt>: Watchdog Configuration ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse1:r:-:h
0x0
:Watchdog Window Timeout Period (WDWPER) = n.a.
:Watchdog Timeout Period (WDPER) = n.a.

=== <tt>fuse2</tt>: Reset Configuration ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse2:r:-:h
0xff
:Reset Vector (BOOTRST) = Application Reset
:BOD operation in power-down mode (BODPD) = BOD disabled

=== <tt>fuse4</tt>: Start-up Configuration ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse4:r:-:h
0xfe
:External Reset Disable (RSTDISBL) = no
:Start-up time (STARTUPTIME) = 0
:Watchdog Timer lock (WDLOCK) = no
:JTAG enabled (JTAGEN) = yes

Bei Bedarf ändern:
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse4:w:0xff:m
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse4:r:-:h
0xff
:JTAG enabled (JTAGEN) = no

=== <tt>fuse5</tt>: BODACT, BODLEVEL, EESAVE ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse5:r:-:h
0xff
:BOD operation in active mode (BODACT) = BOD disabled
:EEPROM memory is preserved through the Chip Erase (EESAVE) = no
:BOD voltage level (BODLEVEL) = 1.6V

Bei Bedarf ändern:
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse5:w:0xf7:m
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse5:r:-:h
0xf7
:EEPROM memory is preserved through the Chip Erase (EESAVE) = yes

== Software ==

=== Clock System ===

Takt zu Testzwecken auf Port C Pin 7 (d.h. JP3 Pin 3) ausgeben.
PORTC.DIRSET = 0x80;
PORTCFG.CLKEVOUT = 0x01;

==== 32 MHz mit dem externen Quarz ====

Unter Verwendung der Software zu AVR1003 (-> Siehe auch) kann man den Takt auf 32 MHz einstellen:

#include "clksys_driver.h"

void init_clock( void )
{
CLKSYS_XOSC_Config( OSC_FRQRANGE_12TO16_gc, false, OSC_XOSCSEL_XTAL_16KCLK_gc );
CLKSYS_Enable( OSC_XOSCEN_bm );
CLKSYS_PLL_Config( OSC_PLLSRC_XOSC_gc, 2 );
CLKSYS_Enable( OSC_PLLEN_bm );
CLKSYS_Prescalers_Config( CLK_PSADIV_1_gc, CLK_PSBCDIV_1_1_gc );
do {} while ( CLKSYS_IsReady( OSC_PLLRDY_bm ) == 0 );
CLKSYS_Main_ClockSource_Select( CLK_SCLKSEL_PLL_gc );
CLKSYS_Disable( OSC_XOSCEN_bm );
} /* init_clock() */

=== USART ===

==== USART über USB ====

So stellt man unter Verwendung der Software zu AVR1307 (-> Siehe auch) bei 32 MHz Takt den USART für die Übertragung per USB ein:

#include "usart_driver.h"

#define USART USARTD0

void init_usart( void )
{
PORTD.DIRSET = PIN3_bm;
PORTD.DIRCLR = PIN2_bm;
USART_Format_Set( &USART, USART_CHSIZE_8BIT_gc, USART_PMODE_DISABLED_gc, false );
/*
* BSEL[11:0]-Wert bei 32MHz Takt und BSCALE[3:0]==0:
* 207 : 9600
* 103 : 19200
* 51 : 38400
* 34 : 57600
* 16 : 115200
*/
USART_Baudrate_Set( &USART, 34 , 0 );
USART_Rx_Enable( &USART );
USART_Tx_Enable( &USART );
} /* init_usart() */

== Siehe auch ==

* [http://www.mikrocontroller.net/topic/227310 Ursprungsbeitrag im Forum]
* [http://www.jtronics.de/avr-projekte/xmega-tutorial.html XMEGA Tutorial in C] - Tutorial ATxmega (ATxmega128A3U)
* [http://www.atxmega-board.de/stick Die Seite des Sticks] mit Schaltplan und Stückliste
* <del>[http://www.stromflo.de/dokuwiki/doku.php?id=xmega-c-tutorial XMEGA-C-Tutorial auf stromflo.de]</del> :-(
* [http://www.atmel.com/dyn/products/product_card.asp?part_id=4302 Produktseite des ATxmega128A3] mit jeder Menge an Dokumentation und Application Notes
* [http://www.atmel.com/dyn/resources/prod_documents/doc8072.pdf AVR1003: Using the XMEGA Clock System] (PDF) und [http://www.atmel.com/dyn/resources/prod_documents/AVR1003.zip Software] (ZIP)
* [http://www.atmel.com/dyn/resources/prod_documents/doc8049.pdf AVR1307: Using the XMEGA USART] (PDF) und [http://www.atmel.com/dyn/resources/prod_documents/AVR1307.zip Software] (ZIP)
* [http://www.microchip.com/wwwproducts/devices.aspx?dDocName=en546923 Produktseite des MCP2200] mit Dokumentation und Tools

[[Kategorie:AVR-Projekte]]

Datei:ATxMegaStick revC-p2.png

2012-11-29T18:39:23Z

Maybee: Schaltplan zum ATxMegaStick rev C - Seite 2 von 2

Schaltplan zum ATxMegaStick rev C - Seite 2 von 2

Datei:ATxMegaStick revC-p1.png

2012-11-29T18:37:26Z

Maybee: Schaltplan zum ATxMegaStick rev C - Seite 1 von 2

Schaltplan zum ATxMegaStick rev C - Seite 1 von 2

Entprellung

2012-09-28T09:53:22Z

Maybee: cli(), sei() unnötig in get_key_state()

Mechanische Schalter prellen beim Ein- und Ausschalten, d.h sie schalten schnell aus und ein, verursacht durch mechanisches Vibrationen des Schaltkontaktes. Vereinfacht dargestellt sieht eine von einem Schalter oder Taster geschaltete Spannung beim Schalten wie folgt aus:

[[Bild:Entprellen.png]]

Für die Auswertung dieses unsauberen Signals gibt es verschiedene Ansätze:

== Hardwareentprellung ==

===Wechselschalter===

Für die Entprellung von Wechselschaltern (engl. Double Throw Switch) kann ein klassisches RS-[[Flipflop]] genutzt werden. Bei dieser Variante werden neben zwei NAND-Gattern nur noch zwei Pull-Up Widerstände benötigt.

[[Bild:NAND_debouncer.png|framed|left|'''Taster entprellen mit NAND-RS-Flipflop''']]

 

In der gezeigten Schalterstellung liegt an der Position /S der Pegel 0 an. Damit ist das Flipflop gesetzt und der Ausgang auf dem Pegel 1. Schließt der Schalter zwischen den Kontakten 2 und 3, liegt an der Postion /R der Pegel 0 an. Dies bedeutet, dass der Ausgang des Flipflops auf den Pegel 0 geht. Sobald der Schalter von einem zum anderen Kontakt wechselt, beginnt er in der Regel zu prellen. Während des Prellens wechselt der Schalter zwischen den beiden Zuständen "Schalter berührt Kontakt" und "Schalter ist frei in der Luft". Der Ausgang des Flipflops bleibt in dieser Prellzeit aber stabil, da der Schalter während des Prellens nie den gegenüberliegenden Kontakt berührt und das RS-Flipflop seinen Zustand allein halten kann. Die Prellzeit ist stark vom Schaltertyp abhängig und liegt zwischen 0,1 und 10ms. Die Dimensionierung der Widerstände ist relativ unkritisch. Als Richtwert können hier 100kOhm verwendet werden.

===Einfacher Taster===

Auch wenn das RS-Flipflop sehr effektiv ist, wird diese Variante der Entprellung nur selten angewendet. Grund dafür ist, dass in Schaltungen häufiger einfache Taster eingesetzt werden. Diese sind oft kleiner und preisgünstiger. Um einfache Taster (engl. Single Throw Switch) zu entprellen, kann ein einfacher RC-Tiefpass eingesetzt werden. Hierbei wird ein Kondensator über einen Widerstand je nach Schalterstellung auf- oder entladen. Das RC-Glied bildet einen Tiefpass, sodass die Spannung über den Kondensator nicht von einen Pegel auf den anderen springen kann.

[[Bild:RC_debouncer.png|framed|left|'''Taster entprellen mit RC-Entpreller''']]

 

Wenn der Schalter geöffnet ist, lädt sich der Kondensator langsam über die beiden Widerstände R1 und R2 auf Vcc auf. Beim Erreichen der Umschaltschwelle springt der Ausgang auf den Pegel 0. Wird der Schalter geschlossen, entlädt sich der Kondensator langsam über den Widerstand R2. Demnach ändert sich der Ausgang des Inverters auf den Pegel 1. Während der Taster prellt, kann sich die Spannung über dem Kondensator nicht sprunghaft ändern, da das Auf- und Entladen eher langsam über die Widerstände erfolgt. Außerdem sind die Schaltschwellen für den Übergang LOW->HIGH und HIGH->LOW stark verschieden (Hysterese, siehe Artikel [[Schmitt-Trigger]]). Bei richtiger Dimensionierung der Bauelemente wird somit der Ausgang des Inverters prellfrei.

Zu beachten ist, dass der Inverter '''unbedingt''' einer mit [[Schmitt-Trigger]] Eingängen sein muss, weil bei Standard-Logikeingängen im Bereich von üblicherweise 0,8V - 2,0V der Ausgang nicht definiert ist. Als Inverter kann zum Beispiel der 74HC14 oder der CD40106 (pinkompatibel) eingesetzt werden. Alternativ kann auch ein CD4093 eingesetzt werden. Bei dem CD4093 handelt es sich um NAND-Gatter mit Schmitt-Trigger-Eingängen. Um aus einem NAND-Gatter einen Inverter zu machen, müssen einfach nur die beiden Eingänge verbunden werden oder ein Eingang fest auf HIGH gelegt werden.

Für eine geeignete Dimensionierung muss man etwas mit den Standardformeln für einen Kondensator jonglieren. Die Spannung über den Kondensator beim Entladen berechnet sich nach:
:<math>U_C(t) = U_0 \cdot e^{\frac{-t}{R_2 C_1}}</math>

Damit der Ausgang des Inverters stabil ist, muss die Spannung über den Kondensator und damit die Spannung am Eingang des Inverters über der Spannung bleiben, bei welcher der Inverter umschaltet. Diese Schwellwertspannung ist genau die zeitabhängige Spannung über den Kondensator.
:<math>U_C(t)\!\ = U_{th}</math>

Durch Umstellen der Formel ergibt sich nun:
:<math>R_2=\frac{-t}{C_1 \cdot ln\left(\frac{U_{th}}{U_0} \right)}</math>

Ein Taster prellt üblicherweise etwa 10ms. Zur Sicherheit kann bei der Berechnung der Widerstandes eine Prellzeit von 20ms angenommen werden. U_0 ist die Betriebsspannung also Vcc. Die Schwellwertspannung muss aus dem Datenblatt des eingesetzten Schmitt-Triggers abgelesen werden. Beim 74HC14 beträgt der gesuchte Wert 2,0V. Nimmt man für den Kondensator 1µF und beträgt die Betriebsspannung 5V, ergibt sich für den Widerstand ein Wert von etwa 22kOhm.

Wird der Schalter geöffnet, lädt sich der Kondensator nach folgender Formel auf:
:<math>U_C(t) = U_0 \cdot \left( 1-e^{\frac{-t}{(R_1+R_2)\cdot C_1}} \right)</math>

Mit U_th=U_C ergibt das Umstellen nach (R_1+R_2):
:<math>R_1+R_2 = \frac{-t}{C_1 \cdot ln\left(1-\frac{U_{th}}{U_0} \right)} </math>

Für die Schwellspannung lässt sich aus dem Datenblatt ein Wert von 2,3V ablesen. Mit diesem Wert und den Annahmen von oben ergibt sich für R_1+R_2 ein Wert von 32kOhm. Somit ergibt sich für R_1 ein Wert von etwa 10kOhm.

Anmerkung: Beim 74LS14 von Hitachi z. B. sind die oberen und unteren Schaltschwellwerte unterschiedlich. Es muss darauf geachtet werden, dass U_{th} beim Entladen die untere Schwelle und U_{th} beim Laden die obere Schwelle einnimmt.

== Softwareentprellung ==

Bei Verwendung eines Mikrocontrollers kann man sich die zusätzliche Hardware sparen, da die Entprellung genauso gut in Software funktioniert. Dabei ist zu beachten, dass zusätzliche Rechenleistung und je nach Umsetzung auch Hardwareressourcen benötigt werden (z. B. Timer).

=== Flankenerkennung ===
Bei einem Taster gibt es insgesamt 4 Zustände:

* 1. war nicht gedrückt und ist nicht gedrückt
* 2. war nicht gedrückt und ist gedrückt (steigende Flanke)
* 3. war gedrückt und ist immer noch gedrückt
* 4. war gedrückt und ist nicht mehr gedrückt (fallende Flanke)

Diese einzelnen Zustände lassen sich jetzt bequem abfragen/durchlaufen. Die Entprellung geschieht dabei durch die ganze Laufzeit des Programms.

Die Taster werden hierbei als Active-Low angeschlossen um die internen Pull-Ups zu nutzen.

Diese Routine gibt für den Zustand "steigende Flanke" den Wert "1" zurück, sonst "0"

<c>
#define TASTERPORT PINC
#define TASTERBIT PINC1

char taster(void)
{
static unsigned char zustand;
char rw = 0;

if(zustand == 0 && !(TASTERPORT & (1<<TASTERBIT))) //Taster wird gedrueckt (steigende Flanke)
{
zustand = 1;
rw = 1;
}
else if (zustand == 1 && !(TASTERPORT & (1<<TASTERBIT))) //Taster wird gehalten
{
zustand = 2;
rw = 0;
}
else if (zustand == 2 && (TASTERPORT & (1<<TASTERBIT))) //Taster wird losgelassen (fallende Flanke)
{
zustand = 3;
rw = 0;
}
else if (zustand == 3 && (TASTERPORT & (1<<TASTERBIT))) //Taster losgelassen
{
zustand = 0;
rw = 0;
}

return rw;
}
</c>

=== Warteschleifen-Verfahren ===

Alle mechanischen Kontakte, sei es von Schaltern, Tastern oder auch von Relais, haben die unangenehme Eigenschaft zu prellen. Dies bedeutet, dass beim Schalten eines Kontaktes derselbe nicht direkt den endgültigen Zustand aufweist, sondern zwischenzeitlich möglicherweise mehrfach ein- und ausschaltet.

Soll nun mit einem Mikrocontroller gezählt werden, wie oft ein solcher Kontakt geschaltet wird, muss das Prellen des Kontakts berücksichtigt werden, da sonst pro Schaltvorgang möglicherweise mehrfache Impulse gezählt werden. Diesem Phänomen muss beim Schreiben des Programms unbedingt Rechnung getragen werden.

Beim folgenden einfachen Beispiel für eine Entprellung ist zu beachten, dass der AVR im Falle eines Tastendrucks 200ms wartet, also brach liegt. Bei zeitkritische Anwendungen sollte man ein anderes Verfahren nutzen (z. B. Abfrage der Tastenzustände in einer Timer-Interrupt-Service-Routine).

<c>
#include <avr/io.h>
#include <inttypes.h>
#ifndef F_CPU
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h> /* bei alter avr-libc: #include <avr/delay.h> */

/* Einfache Funktion zum Entprellen eines Tasters */
inline uint8_t debounce(volatile uint8_t *port, uint8_t pin)
{
if ( !(*port & (1 << pin)) )
{
/* Pin wurde auf Masse gezogen, 100ms warten */
_delay_ms(50); // Maximalwert des Parameters an _delay_ms
_delay_ms(50); // beachten, vgl. Dokumentation der avr-libc
if ( *port & (1 << pin) )
{
/* Anwender Zeit zum Loslassen des Tasters geben */
_delay_ms(50);
_delay_ms(50);
return 1;
}
}
return 0;
}

int main(void)
{
DDRB &= ~( 1 << PB0 ); /* PIN PB0 auf Eingang Taster) */
PORTB |= ( 1 << PB0 ); /* Pullup-Widerstand aktivieren */
...
if (debounce(&PINB, PB0))
{
/* Falls Taster an PIN PB0 gedrueckt */
/* LED an Port PD7 an- bzw. ausschalten: */
PORTD = PORTD ^ ( 1 << PD7 );
}
...
}
</c>

Die obige Routine hat leider mehrere Nachteile:
* sie detektiert nur das Loslassen (unergonomisch)
* sie verzögert die Mainloop immer um 100ms bei gedrückter Taste
* sie verliert Tastendrücke, je mehr die Mainloop zu tun hat.

Eine ähnlich einfach zu benutzende Routine, aber ohne all diese Nachteile findet sich im Forenthread
[http://www.mikrocontroller.net/topic/164194#new Entprellung für Anfänger]

Der ''DEBOUNCE'' Befehl in dem BASIC-Dialekt BASCOM für AVR ist ebenfalls nach dem Warteschleifen-Verfahren programmiert. Die Wartezeit beträgt standardmäßig 25 ms, kann aber vom Anwender überschrieben werden. Vgl. [http://avrhelp.mcselec.com/bascom-avr.html?DEBOUNCE BASCOM Online-Manual zu DEBOUNCE].

Eine C-Implementierung für eine Tastenabfrage mit Warteschleife ist im Artikel [[AVR-GCC-Tutorial#IO-Register_als_Parameter_und_Variablen|AVR-GCC-Tutorial: IO-Register als Parameter und Variablen]] angeben.

Der Nachteil dieses Verfahrens ist, dass der Controller durch die Warteschleife blockiert wird. Günstiger ist die Implementierung mit einem Timer-Interrupt.

==== Warteschleifenvariante mit Maske und Pointer (nach Christian Riggenbach) ====

Hier eine weitere Funktion, um Taster zu entprellen: Durch den zusätzlichen Code kann eine Entprellzeit von durchschnittlich 1-3ms (mindestens 8*150µs = 1ms) erreicht werden. Grundsätzlich prüft die Funktion den Pegel der Pins auf einem bestimmten Port. Wenn die/der Pegel 8 Mal konstant war, wird die Schleife verlassen. Diese Funktion kann sehr gut eingesetzt werden, um in einer Endlosschleife Taster anzufragen, da sie, wie erwähnt, eine kurze Wartezeit hat.

<c>
void entprellung( volatile uint8_t *port, uint8_t maske ) {
uint8_t port_puffer;
uint8_t entprellungs_puffer;

for( entprellungs_puffer=0 ; entprellungs_puffer!=0xff ; ) {
entprellungs_puffer<<=1;
port_puffer = *port;
_delay_us(150);
if( (*port & maske) == (port_puffer & maske) )
entprellungs_puffer |= 0x01;
}
}
</c>
Die Funktion wird wie folgt aufgerufen:
<c>
// Bugfix 20100414
// http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass
entprellung( &PINB, (1<<PINB2) ); // ggf. Prellen abwarten
if( PINB & (1<<PINB2) ) // dann stabilen Wert einlesen
{
// mach was
}
else
{
// mach was anderes
}
</c>
Als Maske kann ein beliebiger Wert übergeben werden. Sie verhindert, dass nichtverwendete Taster die Entprellzeit negativ beeinflussen.

==== Debounce-Makro von Peter Dannegger ====

Peter Dannegger hat in [http://www.mikrocontroller.net/topic/164194#1566921 "Entprellen für Anfänger"] folgende vereinfachtes Entprellverfahren beschrieben. Das Makro arbeitet in der Originalversion mit ''active low'' geschalteten Tastern, kann aber einfach für ''active high'' geschaltete Taster angepasst werden ([[Pollin Funk-AVR-Evaluationsboard#Tasty Reloaded|Tasty Reloaded]]).

<c>
/************************************************************************/
/* */
/* Not so powerful Debouncing Example */
/* No Interrupt needed */
/* */
/* Author: Peter Dannegger */
/* */
/************************************************************************/
// Target: ATtiny13

#include <avr/io.h>
#define F_CPU 9.6e6
#include <util/delay.h>

#define debounce( port, pin ) \
({ \
static uint8_t flag = 0; /* new variable on every macro usage */ \
uint8_t i = 0; \
\
if( flag ){ /* check for key release: */ \
for(;;){ /* loop ... */ \
if( !(port & 1<<pin) ){ /* ... until key pressed or ... */ \
i = 0; /* 0 = bounce */ \
break; \
} \
_delay_us( 98 ); /* * 256 = 25ms */ \
if( --i == 0 ){ /* ... until key >25ms released */ \
flag = 0; /* clear press flag */ \
i = 0; /* 0 = key release debounced */ \
break; \
} \
} \
}else{ /* else check for key press: */ \
for(;;){ /* loop ... */ \
if( (port & 1<<pin) ){ /* ... until key released or ... */ \
i = 0; /* 0 = bounce */ \
break; \
} \
_delay_us( 98 ); /* * 256 = 25ms */ \
if( --i == 0 ){ /* ... until key >25ms pressed */ \
flag = 1; /* set press flag */ \
i = 1; /* 1 = key press debounced */ \
break; \
} \
} \
} \
i; /* return value of Macro */ \
})

/*
Testapplication
*/
int main(void)
{
DDRB &= ~(1<<PB0);
PORTB |= 1<<PB0;
DDRB |= 1<<PB2;
DDRB &= ~(1<<PB1);
PORTB |= 1<<PB1;
DDRB |= 1<<PB3;
for(;;){
if( debounce( PINB, PB1 ) )
PORTB ^= 1<<PB2;
if( debounce( PINB, PB0 ) )
PORTB ^= 1<<PB3;
}
}

</c>

Wenn das Makro für die gleiche Taste (Pin) an mehreren Stellen aufgerufen werden soll, muss eine Funktion angelegt werden, damit beide Aufrufe an die gleiche Zustandsvariable ''flag'' auswerten [http://www.mikrocontroller.net/topic/195914#1918727]:

<c>
// Hilfsfunktion
uint8_t debounce_C1( void )
{
return debounce(PINC, PC1);
}

// Beispielanwendung
int main(void)
{
DDRB |= 1<<PB2;
DDRB |= 1<<PB3;
DDRC &= ~(1<<PC1);
PORTC |= 1<<PC1; // Pullup für Taster

for(;;){
if( debounce_C1() ) // nicht: debounce(PINC, PC1)
PORTB ^= 1<<PB2;
if( debounce_C1() ) // nicht: debounce(PINC, PC1)
PORTB ^= 1<<PB3;
}
}
</c>

=== Timer-Verfahren (nach Peter Dannegger) ===

==== Grundroutine (AVR Assembler) ====

Siehe dazu: [http://www.mikrocontroller.net/forum/read-4-20435.html#new Forum]

Vorteile
* besonders kurzer Code
* schnell

Außerdem können 8 Tasten (aktiv low) gleichzeitig bearbeitet werden, es dürfen also
alle exakt zur selben Zeit gedrückt werden. Andere Routinen können z. B. nur eine Taste verarbeiten, d.h. die zuerst oder zuletzt gedrückte gewinnt, oder es kommt Unsinn heraus.

Die eigentliche Einlese- und Entprellroutine ist nur 8 Instruktionen
kurz. Der entprellte Tastenzustand ist im Register ''key_state''. Mit nur 2 weiteren Instruktionen wird dann der Wechsel von ''Taste offen'' zu
''Taste gedrückt'' erkannt und im Register ''key_press'' abgelegt. Im Beispielcode werden dann damit 8 LEDs ein- und ausgeschaltet. Jede Taste entspricht einem Bit in den Registern, d.h. die Verarbeitung erfolgt bitweise mit logischen Operationen. Zum Verständnis empfiehlt es sich daher, die Logikgleichungen mit Gattern für ein Bit = eine Taste aufzumalen. Die Register kann man sich als Flipflops denken, die mit der Entprellzeit als Takt arbeiten. D.h. man kann das auch so z. B. in einem GAL22V10 realisieren.

Als Kommentar sind neben den einzelnen Instruktionen alle 8 möglichen
Kombinationen der 3 Signale dargestellt.

Beispielcode für AVR (Assembler):

<avrasm>
.nolist
.include "c:\avr\inc\1200def.inc"
.list
.def save_sreg = r0
.def iwr0 = r1
.def iwr1 = r2

.def key_old = r3
.def key_state = r4
.def key_press = r5

.def leds = r16
.def wr0 = r17

.equ key_port = pind
.equ led_port = portb

rjmp init
.org OVF0addr ;timer interrupt 24ms
in save_sreg, SREG
get8key: ;/old state iwr1 iwr0
mov iwr0, key_old ;00110011 10101010 00110011
in key_old, key_port ;11110000
eor iwr0, key_old ; 11000011
com key_old ;00001111
mov iwr1, key_state ; 10101010
or key_state, iwr0 ; 11101011
and iwr0, key_old ; 00000011
eor key_state, iwr0 ; 11101000
and iwr1, iwr0 ; 00000010
or key_press, iwr1 ;store key press detect
;
; insert other timer functions here
;
out SREG, save_sreg
reti
;-------------------------------------------------------------------------
init:
ldi wr0, 0xFF
out ddrb, wr0
ldi wr0, 1<<CS02 | 1<<CS00 ;divide by 1024 * 256
out TCCR0, wr0
ldi wr0, 1<<TOIE0 ;enable timer interrupt
out TIMSK, wr0

clr key_old
clr key_state
clr key_press
ldi leds, 0xFF
main: cli
eor leds, key_press ;toggle LEDs
clr key_press ;clear, if key press action done
sei
out led_port, leds
rjmp main
;-------------------------------------------------------------
</avrasm>

==== Komfortroutine (C für AVR) ====

Siehe dazu: [http://www.mikrocontroller.net/forum/read-4-310276.html Forum]

'''Anmerkung''' Wenn statt active-low (Ruhezustand High) active-high (Ruhezustand Low) verwendet wird muss eine Zeile geändert werden siehe:
[http://www.mikrocontroller.net/forum/read-4-310276.html gesamter Beitrag im Forum],
[http://www.mikrocontroller.net/topic/48465#606555 Stelle 1 im Beitrag], ([http://www.mikrocontroller.net/topic/48465#2306398 Stelle 2 im Beitrag] muss *nicht* geändert werden, da hier die Polarität gar keinen Einfluß hat).

Funktionsprinzip wie oben plus zusätzliche Features:
* Kann Tasten sparen durch unterschiedliche Aktionen bei kurzem oder langem Drücken
* Wiederholfunktion, z. B. für die Eingabe von Werten

Das Programm ist für avr-gcc/avr-libc geschrieben, kann aber mit ein paar Anpassungen auch mit anderen Compilern und Mikrocontrollern verwendet werden. Eine Portierung für den AT91SAM7 findet man [http://www.google.com/codesearch?q=show:ac2viP-2E2Y:pzkOO5QRsoc:RPICuprYy-A&sa=N&cd=1&ct=rc&cs_p=svn://mikrocontroller.net/mp3dec/trunk&cs_f=keys.c#a0 hier] (aus dem Projekt [[ARM MP3/AAC Player]]).
<c>
/************************************************************************/
/* */
/* Debouncing 8 Keys */
/* Sampling 4 Times */
/* With Repeat Function */
/* */
/* Author: Peter Dannegger */
/* danni@specs.de */
/* */
/************************************************************************/

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

#ifndef F_CPU
#define F_CPU 1000000 // processor clock frequency
#warning kein F_CPU definiert
#endif

#define KEY_DDR DDRB
#define KEY_PORT PORTB
#define KEY_PIN PINB
#define KEY0 0
#define KEY1 1
#define KEY2 2
#define ALL_KEYS (1<<KEY0 | 1<<KEY1 | 1<<KEY2)

#define REPEAT_MASK (1<<KEY1 | 1<<KEY2) // repeat: key1, key2
#define REPEAT_START 50 // after 500ms
#define REPEAT_NEXT 20 // every 200ms

#define LED_DDR DDRA
#define LED_PORT PORTA
#define LED0 0
#define LED1 1
#define LED2 2

volatile uint8_t key_state; // debounced and inverted key state:
// bit = 1: key pressed
volatile uint8_t key_press; // key press detect

volatile uint8_t key_rpt; // key long press and repeat

ISR( TIMER0_OVF_vect ) // every 10ms
{
static uint8_t ct0, ct1, rpt;
uint8_t i;

TCNT0 = (uint8_t)(int16_t)-(F_CPU / 1024 * 10e-3 + 0.5); // preload for 10ms

i = key_state ^ ~KEY_PIN; // key changed ?
ct0 = ~( ct0 & i ); // reset or count ct0
ct1 = ct0 ^ (ct1 & i); // reset or count ct1
i &= ct0 & ct1; // count until roll over ?
key_state ^= i; // then toggle debounced state
key_press |= key_state & i; // 0->1: key press detect

if( (key_state & REPEAT_MASK) == 0 ) // check repeat function
rpt = REPEAT_START; // start delay
if( --rpt == 0 ){
rpt = REPEAT_NEXT; // repeat delay
key_rpt |= key_state & REPEAT_MASK;
}
}

///////////////////////////////////////////////////////////////////
//
// check if a key has been pressed. Each pressed key is reported
// only once
//
uint8_t get_key_press( uint8_t key_mask )
{
cli(); // read and clear atomic !
key_mask &= key_press; // read key(s)
key_press ^= key_mask; // clear key(s)
sei();
return key_mask;
}

///////////////////////////////////////////////////////////////////
//
// check if a key has been pressed long enough such that the
// key repeat functionality kicks in. After a small setup delay
// the key is reported being pressed in subsequent calls
// to this function. This simulates the user repeatedly
// pressing and releasing the key.
//
uint8_t get_key_rpt( uint8_t key_mask )
{
cli(); // read and clear atomic !
key_mask &= key_rpt; // read key(s)
key_rpt ^= key_mask; // clear key(s)
sei();
return key_mask;
}

///////////////////////////////////////////////////////////////////
//
// check if a key is pressed right now
//
uint8_t get_key_state( uint8_t key_mask )

{
key_mask &= key_state;
return key_mask;
}

///////////////////////////////////////////////////////////////////
//
uint8_t get_key_short( uint8_t key_mask )
{
cli(); // read key state and key press atomic !
return get_key_press( ~key_state & key_mask );
}

///////////////////////////////////////////////////////////////////
//
uint8_t get_key_long( uint8_t key_mask )
{
return get_key_press( get_key_rpt( key_mask ));
}

int main( void )
{
LED_PORT = 0xFF;
LED_DDR = 0xFF;

// Configure debouncing routines
KEY_DDR &= ~ALL_KEYS; // configure key port for input
KEY_PORT |= ALL_KEYS; // and turn on pull up resistors

TCCR0 = (1<<CS02)|(1<<CS00); // divide by 1024
TCNT0 = (uint8_t)(int16_t)-(F_CPU / 1024 * 10e-3 + 0.5); // preload for 10ms
TIMSK |= 1<<TOIE0; // enable timer interrupt

sei();

while(1){
if( get_key_short( 1<<KEY1 ))
LED_PORT ^= 1<<LED1;

if( get_key_long( 1<<KEY1 ))
LED_PORT ^= 1<<LED2;

// single press and repeat

if( get_key_press( 1<<KEY2 ) || get_key_rpt( 1<<KEY2 )){
uint8_t i = LED_PORT;

i = (i & 0x07) | ((i << 1) & 0xF0);
if( i < 0xF0 )
i |= 0x08;
LED_PORT = i;
}
}
}
</c>

Das single-press-und-repeat-Beispiel geht nicht in jeder Beschaltung; folgendes Beispiel sollte universeller sein (einzelne LED an/aus):
<c>
// single press and repeat
if( get_key_press( 1<<KEY2 ) || get_key_rpt( 1<<KEY2 )){
LED_PORT ^=0x08;
</c>

===== Funktionsweise =====
Der Code basiert auf 8 parallelen vertikalen Zählern, die über die Variablen ct0 und ct1 aufgebaut werden

[[Bild:VertCount.png|framed|center|'''8 vertikale Zähler in 2 8-Bit Variablen''']]

wobei jeweils ein Bit in ct0 mit dem gleichwertigen Bit in ct1 zusammengenommen einen 2-Bit-Zähler bildet.
Der Code der sich um die 8 Zähler kümmert, ist so geschrieben, daß er alle 8 Zähler gemeinsam parallel behandelt.

<C>
i = key_state ^ ~KEY_PIN; // key changed ?
</C>
i enthält an dieser Stelle für jede Taste, die sich im Vergleich mit dem vorhergehenden entprellten Zustand (keystate) verändert hat, ein 1 Bit.

<C>
ct0 = ~( ct0 & i ); // reset or count ct0
ct1 = ct0 ^ (ct1 & i); // reset or count ct1
</C>

Diese beiden Anweisungen erniedrigen den 2-Bit Zähler ct0/ct1 für jedes Bit um 1, welches in i gesetzt ist. Liegt an der entsprechenden Stelle in i ein 0 Bit vor (keine Änderung des Zustands), so wird der Zähler ct0/ct1 für dieses Bit auf 1 gesetzt.
Der Grundzustand des Zählers ist als ct0 == 1 und ct1 == 1 (Wert 3). Der Zähler zählt daher mit jedem ISR Aufruf, bei dem die Taste im Vergleich zu keystate als verändert erkannt wurde

ct1 ct0
1 1 // 3
1 0 // 2
0 1 // 1
0 0 // 0
1 1 // 3

<C>
i &= ct0 & ct1; // count until roll over ?
</C>
in i bleibt nur dort ein 1-Bit erhalten, wo sowohl in ct1 als auch in ct0 ein 1 Bit vorgefunden wird, der betreffenede Zähler also bis 3 zählen konnte. Durch die zusätzliche Verundung mit i wird der Fall abgefangen, dass ein konstanter Zählerwert von 3 in i ein 1 Bit hinterlässt. Im Endergebnis bedeutet dass, dass nur ein Zählerwechsel von 0 auf 3 zu einem 1 Bit an der betreffenden Stelle in i führt. Das heißt, ein Tastendruck wird erkannt, wenn die Taste 4 mal hintereinander in einem anderen Zustand vorgefunden wurde als dem zuletzt bekannten entprellten Tastenzustand.

An dieser Stelle ist i daher ein Vektor von 8 Bits, von denen jedes einzelne der Bits darüber Auskunft gibt, ob die entsprechende Taste mehrmals hintereinander im selben Zustand angetroffen wurde, der nicht mit dem zuletzt bekannten Tastenzustand übereinstimmt. Ist das der Fall, dann wird eine entsprechende Veränderung des Tastenzustands in key_state registriert
<C>
key_state ^= i; // then toggle debounced state
</C>
und wenn sich in key_state das entsprechende Bit von 0 auf 1 verändert hat, wird dieses Ereignis als 'Taste wurde niedergedrückt' gewertet.
<C>
key_press |= key_state & i; // 0->1: key press detect
</C>

Damit ist der Tasteneingang entprellt. Und zwar sowohl beim Drücken einer Taste als auch beim Loslassen (damit Tastenpreller beim Loslassen nicht mit dem Niederdrücken einer Taste verwechselt werden). Der weitere Code beschäftigt sich dann nur noch damit, diesen entprellten Tastenzustand weiter zu verarbeiten.

Der Codeteil sieht durch die Verwendung der vielen bitweisen Operationen relativ komplex aus. Behält man aber im Hinterkopf, dass einige der bitweisen wie ein 'paralles If' gleichzeitig auf allen 8 Bits eingesetzt werden, dann vereinfacht sich vieles. Ein
<C>
key_press |= key_state & i;
</C>
ist nichts anderes als ein
<C>
// teste ob Bit 0 sowohl in key_state als auch in i gesetzt ist
// und setze Bit 0 in key_press, wenn das der Fall ist
if( ( key_state & ( 1 << 0 ) ) &&
( i & ( 1 << 0 ) )
key_press |= ( 1 << 0 );

// Bit 1
if( ( key_state & ( 1 << 1 ) ) &&
( i & ( 1 << 1 ) )
key_press |= ( 1 << 1 );

// Bit 2
if( ( key_state & ( 1 << 2 ) ) &&
( i & ( 1 << 2 ) )
key_press |= ( 1 << 2 );

...
</C>
nur als wesentlich kompaktere Operation ausgeführt und für alle 8 Bits gleichzeitig.
Die Kürze und Effizienz dieser paar Codezeilen ergibt sich aus dem Umstand, dass jedes Bit in den Variablen für eine Taste steht und alle 8 (maximal möglichen) Tasten gleichzeitig die Operationen durchlaufen.

== Links ==
* [[AVR-Tutorial: Tasten]]
* [[AVR-GCC-Tutorial#.28Tasten-.29Entprellung|AVR-GCC-Tutorial Tastenentprellung]]
* [http://www.mikrocontroller.net/forum/read-4-20435.html Beitrag im Forum, AVR Assembler]
* [http://www.ganssle.com/debouncing.pdf A guide to debouncing (engl.), praktische Erläuterungen zum Entprellen in Soft- und Hardware]
* [http://www.pololu.com/docs/0J16/all Understanding Destructive LC Voltage Spikes]

[[Category:AVR]]
[[Kategorie:Signalverarbeitung]]

Pegelwandler

2012-09-21T19:58:31Z

Maybee: Änderung 68438 von 88.69.135.22 (Diskussion) wurde rückgängig gemacht.

== Vorwort ==

Dies ist die erste aufgeräumte Version. Sicher nicht die letzte.

* [http://www.mikrocontroller.net/forum/read-1-375051.html "Stein des Anstosses"]
* [http://www.mikrocontroller.net/forum/list-1-1.html?filter=pegelwand*+levelsh*&x=0&y=0 Suche in den Forenartikel]

== Einleitung ==

Pegelwandeln (engl. level shifting) wird oft notwendig, wenn Systeme mit unterschiedlicher Ausgangs- und Eingangsspannungen (z. B. Versorgungs- oder Logikspannungen) miteinander verbunden werden sollen. Das vielleicht bekannteste Beispiel ist die Umsetzung von 0V/5V [[TTL]] Logikpegeln auf die -12V/12V Pegel einer seriellen [[RS232]] Schnittstelle. Die Probleme beim Pegelwandeln können sein:

# Überlastung einer oder beider Seiten
# Inkompatible Logikpegel und daraus resultierendes Nichtfunktionieren der Schaltung, oder noch schlimmer, sporadische Fehlfunktionen
# Verzögerungen der Signale durch die Pegelwandlung und daraus resultierende maximale Signalfrequenzen

=== Überlastung ===

Das Erzeugen von verschiedenen Versorgungsspannungen ist ziemlich einfach, aber man muss sicher gehen, daß man die Signalleitungen zwischen den Bauteilen überprüft. Wenn ein 5V Bauteil ein Signal an ein 3V Bauteil schickt, können beide Bauteile beschädigt werden. Vor allem für neue ICs ist es ein Problem mit "hohen" Spannungen wie 5V zu arbeiten. Auf Grund der immer kleineren Schaltkreisstrukturen (der aktuelle Pentium wird mit 45nm Technologie hergestellt!) werden auch die Abstände und Schichtdicken immer geringer. Das reduziert natürlich auch die Spannungsfestigkeit der Transistoren auf dem IC. Neue ICs vertragen deshalb meist nur noch 3.3V, teilweise sogar weniger! Die Überlastung erfolgt durch zu hohe Spannung und dadurch mehr oder weniger langsame Zerstörung des ICs.

=== Schutzdioden ===

Hauptursache Nummer zwei für Überlastung von ICs mit verschiedenen Betriebsspannungen sind die in nahezu allen ICs integrierten Schutzdioden. Deren Aufgabe ist es in Normalfall, elektrostatische Entladungen auf eine sichere, niedrige Spannung zu begrenzen. Die Entladungen geschehen durch unsachgemässe Handhabung und Transport von ICs, z. B. wenn jemand über einen Kunstfaserteppich läuft, sich dabei elektrostatisch auflädt und einen IC anfasst. Oder wenn Bauteile in einem Gerät eingebaut sind und der Anwender berührt offen liegende Kontakte (RS232 Eingang, USB-Stick, PCI-Steckkarten beim Einbau etc.). Die Schutzdioden beginnen Strom zu leiten, wenn die Eingangsspannung ca. 500mV über VCC ansteigt oder mehr als 500mV unter GND absinkt. Im Normalbetrieb sollten die Schutzdioden keinen Strom leiten. Manchmal kann man sie aber zur Spannungsbegrenzung missbrauchen, siehe [[#STEP-DOWN:_5V_-.3E_3.3V | Step Down mit Vorwiderstand]].

[[bild:pw_schutzdioden.png]]

=== 5 V tolerante Eingänge ===

5-Volt-tolerant bedeutet, dass 3-Volt-Bausteine ohne Probleme von einem 5-Volt-Baustein angesteuert werden dürfen.

Viele Bauteile mit einer Betriebsspannung von 3 V verfügen über 5-V-tolerante Eingänge. Man sollte aber grundsätzlich im Datenblatt dies nachschauen, bevor die Schaltung aufgebaut wird. Sind sie es nicht, so ist ein Pegelwandler auf den Verbindungsleitungen zwischen den Bauteilen notwendig. Ein Pegelwandler kann eine einfache Zener-Diode mit einem Widerstand sein, es kann aber auch ein eigens dafür vorgesehener IC sein. Sind die Signalwege bidirektional, so wird man meist die Lösung mit einem eigenen IC bevorzugen.

[[AVR]]s sind generell '''nicht''' 5-V-tolerant, wenn sie mit 3,3 V betrieben werden! Die absolute obere Grenze für Eingangsspannungen liegt bei Vcc + 0,5 V. Zu finden in den elektrischen Spezifikationen im Datenblatt.

Ob ein Bauteil 5-V-tolerant ist und unter welchen Betriebsbedingungen das gilt, steht im Datenblatt des betreffenden Bauteils vom betreffenden Hersteller. Wenn es auf diese Eigenschaft ankommt, lieber genau bei Lieferanten nachsehen, von welchem Hersteller die Bauteile kommen.

Vorsicht bei:

* 74'''LVX'''xxxx und 74'''LCX'''xxxx (245, 244, 240 ...) an Vcc = 3,3 V. Achtung: Nicht alle 74LVX sind für 5 V -> 3,3 V geeignet, da jeder Hersteller die ICs anders baut!

=== Kompatibilität von Logikpegeln ===

Siehe auch http://www.interfacebus.com/Design_Translation.html

Verschiedene Mikroprozessoren haben eigene elektrische Kenndaten für HIGH und LOW Pegel, die abhängig von der Versorgungsspannung sind, z. B. der [[R8C]]:

* HIGH grösser 0,8 * Vcc
* LOW kleiner 0,2 * Vcc

Man muss die Spannungen der Aus- und Eingänge vergleichen. Wenn es um ein Hobbyprojekt geht, kann man einfach messen. Wenn es um eine kommerzielle Anwendung geht, die man verkaufen will, sollte man besser die Spezifikationen der ICs studieren.

== UNIDIREKTIONAL ==

=== 1,8 V -> 5 V ===

* Die besondere Eigenschaft der alten TTL Schaltkreise, nämlich dass Strom bei LOW '''aus''' dem Eingang in den treibenden Ausgang fliesst kann man sich zu nutze machen, wie die nachfolgende Schaltung zeigt. In dieser wird der HIGH-Pegel des 1,8-V-Signals durch eine Schottkydiode um ca. 0,3 V auf 2,1 V erhöht. Damit ist man fast offiziell im HIGH-Bereich für TTL (Schaltschwelle 1,4 V, HIGH > 2,0 V). Der LOW-Pegel wird auf ca. 0,3 V erhöht, was voll den TTL-Richtlinien entspricht. Als Schaltkreisfamilie '''muss''' ein [[74xx|TTL-Typ]] eingesetzt werdem, also LS, F, AS oder ähnlich. CMOS-Typen wie HC, LVC etc. funktionieren '''nicht'''!

[[bild:pw_LS.png]]

Achtung: Diese Schaltung entspricht bei HIGH ungefähr einem offenen TTL-Eingang, was zwar meistens funktioniert, aber etwas störempfindlich sein kann. Davon wurde in der TTL-Ära stets abgeraten. Zudem ist der Pegelwechsel LOW nach HIGH durch den niedrigen Strom eher langsam. Man kann das jedoch mit einem Pullup-Widerstand absichern. Dann sind auch Gatter der 74HCT-Reihe einsetzbar.

=== 3.3V -> 5V ===

* 3.3V Pegel werden bei TTL kompatiblen Eingängen richtig erkannt (Schaltschwelle 1,4V). Es ist kein Pegelwandler erforderlich. Direkte Verbindung.

* 5V CMOS Eingänge haben typisch eine minimale Eingangsspannug für HIGH (<math>V_{IH}</math>) von 0.6 * VCC = 0.6 * 5V = 3V. Das kann ein 3.3V CMOS Ausgang direkt treiben, allerdings kann sich das Zeitverhalten dadurch etwas ändern weil der HIGH Pegel später erkannt wird. Vorsicht! Viele 5V CMOS ICs wollen für HIGH offiziell mindestens 0.7V * VCC = 3.5V oder manche auch 0.8 * VCC = 4.0V! Das geht dann offiziell nicht mehr mit einem 3.3V Ausgang! Für Hobbyzwecke kann man das aber ggf. probieren.

* 3.3V [[Ausgangsstufen_Logik-ICs | Open Collector]] nach 5V (TTL oder CMOS): Einfach einen Pull-Up Widerstand hinzufügen und gut. Allerdings verbraucht der Pull-Up Widerstand bei LOW relativ viel Strom und kann bei HIGH nicht allzuviel Strom liefern. Die Schaltgeschwindigkeit von LOW nach HIGH wird durch die Grösse des Pull-Ups bestimmt.

[[bild:pw_oc_3-5.png]]

* 3,3V auf echte 5V (CMOS) geht am einfachsten mit einem Baustein der HCT Familie (NICHT HC !). Diese haben TTL-compatible Eingänge und echte CMOS Ausgänge

* Man kann einen Komparator in nichtinvertierender Schaltung benutzen (LM339/393). Allerdings ist diese Lösung meist relativ langsam, abhängig vom verwendeten Komparator.

[[bild:pw_comp_3-5.png]]

'''Bauteile'''

* 74HCTxxx (245, 244, 240 ...)
* 74HCT125: OE Pins auf Masse und dann das Signal einfach anschließen.
* SN74LVC07AD

=== 5V -> 9..15V ===

* Am einfachsten geht das mit einem Open Collector Ausgang, einfach einen Pull-Up hinzufügen (an die hohe Spannung) und fertig.

[[bild:pw_oc_5-12.png]]

* Man kann einen Komparator benutzen. Allerdings ist diese Lösung meist relativ langsam, abhängig vom verwendeten Komparator. Wenn nur zwei Signale pegelgewandlet werden müssen bietet sich der LM393 an, ein Doppelkomparator mit Open Collector Ausgang, mit dem man auf einen beliebigen Pegel ausgeben kann. Der LM339 ist ein Vierfachkomparator mit den gleichen Eigenschaften. Wenn wenig Platz vorhanden ist, dann ist der TL311 im winzigen SOT-23 Gehäuse sehr empfehlenswert. Bei jedem Komparator kann auch einfach eine Invertierung gemacht werden, einfach die Eingänge + und - vertauschen. Diese Komparatoren eignen sich bis ca. 1 MHz.

* [http://www.elektronik-kompendium.de/sites/praxis/bausatz_pegelwandler-mit-transistoren.htm Pegelwandler mit Transistor, invertierend]

[[bild:pw_trans_inv.png]]

* Pegelwandler mit Transistor, nicht invertierend

[[bild:pw_trans_ni.png]]

Die Idee ist einfach. Wenn der Ausgang des 5V Gatters auf HIGH ist dann ist der Transistor ausgeschaltet, der Pull-Up Widerstand R7 zieht den Ausgang auf +12V. Ist der Ausgang des 5V Gatters auf LOW ist, dann ist er vollkommen durchgesteuert und der Ausgang nahe 0V (je nach Typ ca. 300mV). Der Vorteil ist hier erhöhte Störsicherheit im Gegensatz zur einfachen Ansteuerung der Basis über einen Vorwiderstand. Ausserdem wird dadurch nicht die Logik invertiert. Nachteilig ist der geringe Strom, der bei HIGH zur Verfügung steht (typisch 100μA). Diese Schaltung ist die seltene Anwendung einer Basisschaltung für digitale Signale.

* Wenn mehr Geschwindigkeit, Ausgangsstrom und weniger Stromverbrauch nötig ist, dann muss ein spezieller Baustein her, wie z. B. 
** [[Mosfet-Übersicht#Mosfet-Treiber|MOSFET-Treiber]] z.B. ICL7667
** [[H-Brücken Übersicht | Motortreiber]] ICs: (z. B. L293, L298, UCC27325 und deren Verwandte), wenns nicht zu schnell ist (einige Dutzend kHz)
** CD40109, bei Reichelt verfügbar
** HEF4104, 4fach LOW-HIGH Pegelwandler mit normalen und invertierten Augängen sowie Tristate. Um ggf. sicherzustellen, dass wie im Datenblatt beschrieben immer VDDI <= VDDO ist, kann man einfach eine Diode von VDDO nach VDDI schalten (z. B. Schottky SB120, aber auch 1N4148 & Co sollte problemlos funktionieren)
** CMOS 4504, 6fach LOW-HIGH/HIGH-LOW 3-20V Pegelwandler, TTL/CMOS (umschaltbar) => CMOS, kein Reihenfolge von Vcc/Vee erforderlich (Bezugsquelle: CSD)
** MAX232, der braucht nur 5V Versorgungsspannung. Allerdings ist der Ausgangswiderstand relativ hoch (ca. 300Ω) und man kann nur ca. 5mA Ausgangstrom liefern. Die Ausgangsspannung beträgt maximal 10V.

=== 5V -> 3.3V ===

* Zuerst sollte man prüfen, ob die Eingänge 5V tolerant sind. Dann kann man die ICs direkt verbinden. Sehr schnell und billig!

* Wenn die Eingänge nicht 5V tolerant sind und es trotzdem schnell sein soll, muss ein Gatter aus der LVC oder AHC Familie dazwischen geschaltet werden. Bei 3V Betriebsspannung kann man problemlos 5V an den Eingang anlegen. Der Baustein 74HC4050 erlaubt per Definition eine Pegelwandlung bis etwa 15V (siehe Datenblatt). Beide Anordungen verbrauchen auch sehr wenig Ruhestrom.

: '''Bauteile'''

:* 74LVC245A ('A' ist wichtig, I/Os 5V-tolerant)
:* 74LVC245DW
:* 74LVT245
:* 74LVXxxx (245, 244, 240 ...) an Vcc=3,3V. Achtung: Nicht alle 74LVX sind für 5V -> 3,3V geeignet, da jeder Hersteller die ICs anders baut!
:** 74LVX04
:** 74LVX244 (Fairchild)
:** 74LVX245 (nicht von Reichelt, nicht 5V tolerant)
:** bei TI heissen die 74LVX... nur 74LV...

:* 74HC4050 (bis 15V Step Down Pegelwandlung laut Datenblatt, bei Reichelt in DIP und SO erhältlich)
:* MAX3373/MAX3375
:* NC7SZ08 oder andere aus derselben Serie. CMOS-Logik mit 5V-toleranten Eingängen, recht flott und braucht dank SOT-23 auch wenig Platz auf dem Print

* 5V Open Collector auf 3.3V Eingang. Einfach einen Pull-Up hinzufügen (Pull-Up liegt auf 3.3V). Nachteilig ist der relativ hohe Stromverbrauch bei LOW, die begrenzte Geschwindigkeit bei hochohmigen Pull-Ups und der relativ geringe Ausgangsstrom bei HIGH (abhängig vom Pull-Up).

[[bild:pw_oc_5-3.png]]

* Spannungsteiler mit 680Ω und 1kOhm. Der Nachteil dieser Lösung ist der relativ hohe Stromverbrauch (~3mA), der relativ geringe Ausgangsstrom (mehr als 200..300uA sollte man da nicht rausziehen) und die relativ geringe Geschwindigkeit (ca. 10 MHz).

[[bild:pw_st_5-3.png]]

* 1 kOhm Vorwiderstand. Dadurch wird der Strom vom 5V Ausgang in die 3.3V Versorgung durch die internen Schutzdioden auf ca. 1mA begrenzt. Diese Lösung ist auch relativ langsam (ca. 5MHz). Ggf. kann man den Vorwiderstand auf 100Ω reduzieren, das erhöht dann wieder die Geschwindigkeit. Aufpassen, einige ICs vertragen nur 1mA oder weniger durch die Schutzdioden! Ausserdem muss man aufpassen, das jetzt von der 5V Seite Strom in die 3.3V Versorgung eingespeist wird. Besonders in Schaltungen mit sehr niedrigem Stromverbrauch kann das zum Problem werden, wenn weniger Strom verbraucht wird als über die Vorwiderstände eingespeist wird. Dann nimmt es meist der Spannungsregler für 3.3V übel wenn jemand "schiebt", sprich, Strom einspeist. Denn die allermeisten Spannungsregler können nur Strom liefern (source), aber keinen Strom aufnehmen (sink). Es gibt 4-fach-Diodennetzwerke, die die internen Schutzdioden entlasten können (Schottkydioden mit kleinerer Flusspannung von ~0,3V als die internen Silizizumdioden mit ~0,7V), außerdem ist teilweise noch eine [[Diode#Z-Diode|Zenerdiode]] enthalten, die ggf. den überschüssig eingespeisten Strom aufnehmen kann.

[[bild:pw_vw_5-3.png]]

Achtung: Mindestens für 74HC(T) Gatter ist dokumentiert (Philips 74HC/T High-Speed CMOS User Guide), dass auch schon geringer Strom durch die internen Schutzdioden zu einer unerwünschten Kopplung von Eingängen führen kann, d.h. der Strom fliesst zu einem anderen Eingang wieder hinaus. Sind also andere Eingänge ebenso hochohmig angeschlossen, kann dieser Querstrom zu Fehlfunktion führen.

== BIDIREKTIONAL ==

Für bidirektionale Busse gibt es spezielle Pegelwandler mit 2 Versorgungsspannungen. Allerdings brauchen die meist ein Signal zur Richtungsumschaltung. Auch muss man die Reihenfolge der Versorgungsspannungen beim Einschalten beachten. Aktive bidirektionale Pegelwandler OHNE Steuereingang zur Richtungsumschaltung sind mit Vorsicht zu geniessen, denn die brauchen teilweise kurzzeitig einen relativ hohen Strom, um die Eingänge zu treiben.

=== 5V <-> 3.3V ===

* Wenn die 5V Seite TTL-kompatible Eingänge hat kann wieder der Spannungsteiler oder Vorwiderstand wie bei der unidirektionalen Anpassung verwendet werden (mit all seinen Vor- und Nachteilen).

'''Bauteile'''

* SN74CB3T3306
* SN74CBTD3861 (10 Bit,flow through, Betrieb mit 5 Volt)
* MAX1741
* MAX3378E
* 74AHC126 s.u.
* ST2378 (bei CSD erhältlich, 3.5 eur, leider TSSOP)
* TXS0104E (TI: 4-BIT BIDIRECTIONAL VOLTAGE-LEVEL TRANSLATOR FOR OPEN-DRAIN AND PUSH-PULL APPLICATIONS)
* SN74LVC07A

=== 1,65V...5,5V <-> 1,65V...5,5V ===

'''Bauteile'''
* SN74LVC1T45
* SN74LVC2T45
* SN74LVC(H)8T245
* SN74LVC(H)16T245

=== 1,2V...3,6V <-> 1,65V...5,5V ===

'''Bauteile'''
* TXB0101
* TXB0102
* TXB0104
* TXB0106
* TXB0108

=== 1,2V...3,6V <-> 1,2V...3,6V ===

'''Bauteile'''
* SN74AVC(H)1T45
* SN74AVC(H)2T45
* SN74AVC(H)4T245
* SN74AVC(H)8T245
* SN74AVC(H)16T245
* SN74AVC(H)20T245
* SN74AVC(H)24T245
* SN74AVC(H)32T245

=== 1,5V...3,6V <-> 1,5V...5,5V ===

'''Bauteile'''
* 74LVC4245A

== Mit galvanischer Trennung ==

* [[Optokoppler]]

[[bild:pw_opto.png]]

* GMR-Koppler von der Firma NVE
* iCoupler Technologie von der Firma Analog Devices
* [[Kapazitiver Koppler]]

Lit.: ''Galvanische Trennung: Optokoppler, GMR-Koppler oder iCoupler?'', Siegfried W. Best, Redaktion elektronik industrie, [http://www.elektronik-industrie.de/ei/11,2003/article/2f0082f824c.html elektronik industrie 11-2003, S. 22ff.]

== Praktische Beispiele ==

=== Einfaches RS232-Interface ===

[http://web.archive.org/web/20050122013618/http://www.henrik-reimers.de/control/rs232interface.gif Erfolgreicher Einsatz bis 19200 Baud und bis zu 10 m Leitungslänge]

Beschränkungen:

* ggf. Platzbedarf
* Geschwindigkeit s.o.

Beispiel: http://www.hagtech.com/pdf/translator.pdf

=== [[I2C]]-Bus: gemeinsam 3.3V und 5V ===

* [[MSP430]] an 3,3V/5V: http://www-s.ti.com/sc/psheets/slaa148/slaa148.pdf

* Philips [http://www.nxp.com/documents/data_sheet/PCA9515.pdf PCA9515]: I2C Puffer mit Pegelwandlung. Der PCA9515 ist ein I2C-Bus Repeater, welcher I2C Busse mit verschiedenen Spannungen isoliert. Verfügbar bei Reichelt und DigiKey.

* [http://ics.nxp.com/support/documents/interface/pdf/an97055.pdf Philips AN97055 Bi-directional level shifter for I²C-bus and other systems]

* Bevor man ein Philips I2C Chip auswählt sollte man prüfen ob er verfügbar ist und auch das verfügbare Gehäuse wählen. Man sollte auch überlegen ob ein Puffer wirklich gebraucht wird. Wenn man echte I2C ICs mit 5V betreibt, dann sind die Eingänge vom Typ Schmitt Trigger CMOS (z. B. PCF8574). Dann müssen 3.3V Pegel auf 5V umgesetzt werden. Wenn man jedoch SMBUS Ics verwendet (z. B. ADT7461, Silabs 8051) dann sind die Schwellspannungen TTL kompatibel und es ist keine Anpassung notwendig. Für neue Pegelwandler sollte man hier nachschauen. http://www.bus-buffer.com

* [http://www.edn.com/article/CA193193.html "Two-transistor circuit replaces IC"]. Für diese Anwendung kann ENABLE direkt mit 3.3V verbunden werden. Es ist eigentlich nur dazu da, den ICs "hot-swappable" zu machen (kann unter Spannung gesteckt und getrennt werden). Es geht sogar mit nur einem [[Transistor]] [http://www.mikrocontroller.net/topic/92447 siehe Forum]. Man sollte beachten, daß die Schaltung sowohl für SCL als auch SDA benötigt wird.
* Noch einfachere Lösungen mit nur einem MOSFET und zwei Pull-Up Widerständen pro Leitung sind in den folgenden Links zu finden. Vielleicht ist es sogar noch billiger Bipolartransistoren zu verwenden.
** http://www.semiconductors.philips.com/markets/mms/protocols/i2c/facts/#levelshifting
** http://www.semiconductors.philips.com/acrobat_download/literature/9398/39340011.pdf (Kapitel 18), bei der Berechnung der erreichbaren Geschwindigkeit dürfen die parasitären Kapazitäten der FETs nicht ignoriert werden

=== Auswählbare Pegel ===

'''Frage:'''
Ein CMOS Logikpegel zwischen 1,8V, 2,5V und 3,3V (abhängig von der Anwendung) muss auf 5V CMOS Logikpegel gewandelt werden. Es geht nur um diese Richtung mit maximal 8MHz. Es gibt die Stromversorgung für alle Pegel. Ein normaler Komparator wie LM311 ist nicht möglich, da er beim Betrieb mit 5V Versorgunsspannung erst ab 1V zu schalten anfängt. Meine Idee ist die Verwendung eines High Speed OPVs mit R2R Eingang, z. B. LMH6645.

'''Antworten:'''
* Man könnte einen ultra-low threshold N-Kanal MOSFET nehmen und als Open Drain mit einem Pull-Up nach 5V betreiben, BSH103 könnte passen (Schwellspannung ~0,4V).
* High-Speed Single Supply Komparator wie z. B. [http://www-s.ti.com/sc/ds/tl712.pdf TL712] .

'''Frage:'''
Ich suchen einen IC, welcher eine Pegelwandlung von 3,3V nach 1,8V, 2,0V oder 5V ermöglicht und während des Betriebs umgeschaltet werden kann.

'''Antworten:'''
* So ein IC ist der Linear [http://www.linear.com/pc/productDetail.jsp?navId=H0,C1,C1007,C1071,P1601 LTC1555L-1.8] .

=== AVR SPI (SDC/MMC)===

Für '''bidirektionalen Betrieb''' zwischen 5V-AVR und 3,3V-Geräten und anders herum gibt es den Level-Translator '''MAX3378E''' von Maxim.

Wenn die Datenrichtung am SPI im Zielsystem festgelegt ist, reichen '''unidirektionale Bausteine''':
* 3x von 5V nach 3,3V und 1x von 3,3V nach 5V: '''MAX3392E'''
* 1x von 5V nach 3,3V und 3x von 3,3V nach 5V: '''MAX3390E'''

Zum Anschließen einer SDC/MMC an einen 5V-AVR eignen sich somit der MAX3978E und der MAX3392E. Beide sind u.A. im winzigen TSSOP-14-Gehäuse verfügbar, nehmen sehr wenig Energie auf und eignen sich auch für andere Spannungen. Mit 3,3 und 5V beträgt die garantierte Übertragungsrate 8Mbps.

* [http://datasheets.maxim-ic.com/en/ds/MAX3372E-MAX3393E.pdf Datenblatt]

Eine weitere Möglichkeit zum Übersetzen zwischen 3,3 und 5V liegt in der Verwendung des '''74LVC245'''.

5V-AVR an eine MMC (ohne Level-Shifter-Baustein):
* [http://www.microsyl.com/index.php/2010/03/24/led-sign-with-mmc-memory-card/ Projektseite]
* [http://www.microsyl.com/projects/ledsign/ledsign1.pdf Schaltplan]

=== µC <-> Parallelport ([[ISP]]-Dongle, [[JTAG]] Wiggler, ...) ===

Dieser Schaltplan funktioniert auch bei 3.3V wenn man einen 74HC244 anstatt eines 74LS244 verwendet: [http://www.epanorama.net/circuits/parallel_output.html Parallel port interfacing made easy: Simple circuits and programs to show how to use PC parallel port output capabilities].

=== 2 Leitungspaare RX/TX 5V/3,3V ===

Der [http://www.hackaday.com/2008/06/19/sparkfuns-logic-level-converter/ SparkFun's Logic Level Converter] ist eine Baugruppe mit MOSFETs [http://www.fairchildsemi.com/pf/BS/BSS138.html BSS138] für die Pegelwandlung von 5V auf 3,3V. 5V/2,8V und 5V/1,8V sind ebenfalls machbar.

= Bauteile =

* '''74ALVC164245''' - ''16bit dual supply translating transceiver''. Eine Seite von 1.5V bis 3.6V, die andere von 1.5 bis 5.5V.
* '''74LVX573''' (unidirektional, Latch, nicht alle Hersteller bauen diesen 5V tolerant!)
* '''74LVX245''' (bidirektional, nicht alle Hersteller bauen diesen 5V tolerant!)
* '''74LVX125''' - ''Low Voltage Quad Buffer with 3-STATE Outputs''. http://www.fairchildsemi.com/pf/74/74LVX125.html
* '''SN74LVC2T45'''
* '''SN74LVC8T245''' - ''8-Bit Dual-Supply Bus Transceiver with Configurable Voltage Translation and Three-State Outputs''. http://focus.ti.com/docs/prod/folders/print/sn74lvc8t245.html
* '''74LCX244MSA''' von Fairchild.
* '''MAX3377'''
* '''MAX3000''' 8-Kanal bidirektioneler Pegelwandler ohne Richtungsumschaltung
* '''ADG3308''' 8-Kanal bi-dir. Pegelwandler ohne Richtungsumschaltung, 1,15V..5,5V, 50MBps

Vierfachdioden im kleinen 6-poligen SMD-Gehäuse:
* http://www.st.com/stonline/products/literature/ds/12635/dsilc6-4xx.pdf
* http://www.st.com/stonline/products/literature/ds/11599.pdf
* http://www.st.com/stonline/products/literature/ds/6477/dalc208.pdf
* [http://www.diodes.com/datasheets/ds30195.pdf QSBT40, vierfach Schottky Terminator für Datenleitungen]
* [http://www.littlefuse.com/data/en/Data_Sheets/SP724Lead_Free.pdf SP724, Siliziumschutzarray]

= Weblinks =

* Gaurang Kavaiya, [http://www.edn.com/contents/images/6335309.pdf Don’t pay for level translators in systems using multiple power-supply voltages], EDN, MAY 25, 2006, 81-86 (PDF)
* [http://www.elektronik-kompendium.de/public/schaerer/scf3_lc.htm Einfacher Pegelwandler im ELKO]
* [http://www.prog-link.com/dcf77/dcf77-17.html Pegelwandler für DFC77 Module]
* [http://elektronik.kai-uwe-schmidt.de/index.php?page=mp3_blueschaltung Pegelwandler für [[I2C]] Bus in einem MP3 Player]
* [http://www.mikrocontroller.net/attachment.php/256452/levelshifter.pdf Application Note von Philips, I2C Pegelwandler]
* [http://www.semiconductors.philips.com/acrobat_download/literature/9398/39340011.pdf I2C Spezifikation]
* [http://www.mikrocontroller.net/forum/read-1-234277.html#new Forumsbeitrag zum Thema 1,8V-5V Pegelwandler]
* [http://www.st.com/stonline/products/literature/ds/5186/74lcx16245.pdf 74LCX16245, 16 Bit Pegelwandler]
* [http://www.standardics.nxp.com/products/lvc/buffers/ LVC Logikfamilie]
* [http://www.standardics.nxp.com/products/lvc/transceivers/ LVC Tranceiver]
* [http://www.leg-gmbh.de/html/signalanpassung.html Pegelwandler für die Automatisierungstechnik]
* [http://www.microchip.com/stellent/groups/techpub_sg/documents/devicedoc/en026368.pdf 3V Tips ‘n Tricks] (PDF) von Microchip
* [http://www.ti.com/lit/an/slaa148/slaa148.pdf Interfacing the 3-V MSP430 to 5-V Circuits] (PDF) von Texas Instruments

[[Category:Bauteile]]
[[Kategorie:Datenübertragung]]

ATxMega Stick - First Steps

2012-09-09T22:20:41Z

Maybee: /* Siehe auch */

[[Datei:ATxMegaStick-1.jpg|thumb|Platine des ATxMega Stick]]
Der ATxMega Stick ist eine kleine Platine (27 mm x 80 mm) mit ATxmega128A3, USB-Device-Anschluss und Micro-SD-Kartenslot.

== Eigenschaften ==

* Mikrocontroller ATxmega128A3
* USB-Baustein [http://kweb/wiki/images/b/ba/MCP2200_22228A.pdf MCP2200]
* Mini-USB-B-Device-Anschluss
* Micro-SD-Kartenslot
* Programmierung via PDI (z.B. AVRISP mkII)
* Reset-Taster
* 2 LEDs zur Signalisierung von USB-Transfers
* 2 frei verwendbare LEDs
* On-board-Spannungsregler (3.3 V, Versorgung über USB oder extern)
* 6 x 8-Bit-Ports auf Stiftleisten verfügbar, davon ist ein Port belegt (2-mal LED, RX und TX zum USB-Baustein, SPI zum Micro-SD-Kartenslot)

== Hinweise zum Aufbau ==

=== Anmerkungen zum Schaltplan vom 15.09.2011 23:08:38 ===

* Seite 1: C1 hat 22µF 
* Seite 1: C14, C15 haben 3.3µF
* Seite 2: Verbindungsbezeichnung bei "<tt>I/Os</tt>" µC Pin 27 und JP4 Pin 4 und bei "<tt>LEDs</tt>" muss <tt>LED3</tt> lauten statt <tt>LED1</tt>
* Seite 2: Verbindungsbezeichnung bei "<tt>I/Os</tt>" µC Pin 26 und JP4 Pin 3 und bei "<tt>LEDs</tt>" muss <tt>LED4</tt> lauten statt <tt>LED2</tt>

=== Stromversorgung ===

Auf JP1 muss ein Jumper bestückt werden:
* zum Platinenrand hin für Versorgung über USB
* zur Platinenmitte hin für externe Versorgung

Hinweis:

Der Jumper sollte unbedingt gesteckt sein, wenn USB verwendet wird. Steht dieser auf externer Versorung, muss diese dabei auch anliegen. Wird der MCP2200 per USB versorgt, ohne dass am ATxMega Versorgungsspannung anliegt, kommt es über die UART-Leitung zu einem Stromfluss über das entsprechende I/O-Pin des ATxMega, da dieser sich ohne Spannung intern in einem undefinierten Zustand befindet. Auf VCC liegen dann etwa 2.8 V an. Durch den Stromfluss erwärmt sich der MCP2200 deutlich, was zur eventuellen Beschädigung des ICs führen kann.

=== Löten des SD-Halters ===

* Zuerst muss man den Halten ausrichen und einen Punkt am Rand festlöten.
* Dann muss man alle 4 Ecken festlöten
* Jetzt kann man mit der Lötspitze oben durch die Aussparungen und führt den Zinn durch die Öffnung für die SD-Karte.
* So lötet man dann alle 8 Kontakte.
* Lötbrücken sind hier nicht schön, lässt sich aber dann noch mit Entlötlitze entfernen (Entlötlitze statt Zinn durch die Öffnung führen)

== Betrieb unter Linux ==

Damit man als User auf den Stick zugreifen kann, empfiehlt es sich, einen UDEV-Eintrag für den Stick anzulegen, z.B. neue Datei /etc/udev/rules.d/15_USB_uC.rules anlegen:

ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="00df", GROUP="MeineGruppe", MODE="0660", SYMLINK+="ATxMegaStick%n"

Für "MeineGruppe" einen geeigneten Werte verwenden, d.h. eine Gruppe, der man selbst angehört.

Jetzt kann man nach dem Anschließen folgende Links sehen:

ls -l /dev/ATxMegaStick*
lrwxrwxrwx 1 root root 7 2011-10-17 00:04 /dev/ATxMegaStick0 -> ttyACM0
lrwxrwxrwx 1 root root 11 2011-10-17 00:04 /dev/ATxMegaStick1 -> usb/hiddev1
lrwxrwxrwx 1 root root 7 2011-10-17 00:04 /dev/ATxMegaStick2 -> hidraw2
lrwxrwxrwx 1 root root 15 2011-10-17 00:04 /dev/ATxMegaStick3 -> bus/usb/001/042

Und die Zugriffrechte sehen so aus:

ls -lL /dev/ATxMegaStick*
crw-rw---- 1 root dialout 166, 0 2011-10-17 00:04 /dev/ATxMegaStick0
crw-rw---- 1 root mgr 180, 97 2011-10-17 00:04 /dev/ATxMegaStick1
crw-rw---- 1 root mgr 251, 2 2011-10-17 00:04 /dev/ATxMegaStick2
crw-rw-r-- 1 root mgr 189, 41 2011-10-17 00:04 /dev/ATxMegaStick3

== Fuses ==

Default-Werte der Fuses:

=== <tt>signature</tt>: Signatur ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U signature:r:-:h
0x1e,0x97,0x42
:0x1e9742 = ATxmega128A3

=== <tt>fuse0</tt>: JTAG User ID ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse0:r:-:h
0xff
:JTAG User ID (JTAGUID) = 0xff '''(das Manual sagt: 0x00)'''

=== <tt>fuse1</tt>: Watchdog Configuration ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse1:r:-:h
0x0
:Watchdog Window Timeout Period (WDWPER) = n.a.
:Watchdog Timeout Period (WDPER) = n.a.

=== <tt>fuse2</tt>: Reset Configuration ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse2:r:-:h
0xff
:Reset Vector (BOOTRST) = Application Reset
:BOD operation in power-down mode (BODPD) = BOD disabled

=== <tt>fuse4</tt>: Start-up Configuration ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse4:r:-:h
0xfe
:External Reset Disable (RSTDISBL) = no
:Start-up time (STARTUPTIME) = 0
:Watchdog Timer lock (WDLOCK) = no
:JTAG enabled (JTAGEN) = yes

Bei Bedarf ändern:
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse4:w:0xff:m
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse4:r:-:h
0xff
:JTAG enabled (JTAGEN) = no

=== <tt>fuse5</tt>: BODACT, BODLEVEL, EESAVE ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse5:r:-:h
0xff
:BOD operation in active mode (BODACT) = BOD disabled
:EEPROM memory is preserved through the Chip Erase (EESAVE) = no
:BOD voltage level (BODLEVEL) = 1.6V

Bei Bedarf ändern:
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse5:w:0xf7:m
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse5:r:-:h
0xf7
:EEPROM memory is preserved through the Chip Erase (EESAVE) = yes

== Software ==

=== Clock System ===

Takt zu Testzwecken auf Port C Pin 7 (d.h. JP3 Pin 3) ausgeben.
PORTC.DIRSET = 0x80;
PORTCFG.CLKEVOUT = 0x01;

==== 32 MHz mit dem externen Quarz ====

Unter Verwendung der Software zu AVR1003 (-> Siehe auch) kann man den Takt auf 32 MHz einstellen:

#include "clksys_driver.h"

void init_clock( void )
{
CLKSYS_XOSC_Config( OSC_FRQRANGE_12TO16_gc, false, OSC_XOSCSEL_XTAL_16KCLK_gc );
CLKSYS_Enable( OSC_XOSCEN_bm );
CLKSYS_PLL_Config( OSC_PLLSRC_XOSC_gc, 2 );
CLKSYS_Enable( OSC_PLLEN_bm );
CLKSYS_Prescalers_Config( CLK_PSADIV_1_gc, CLK_PSBCDIV_1_1_gc );
do {} while ( CLKSYS_IsReady( OSC_PLLRDY_bm ) == 0 );
CLKSYS_Main_ClockSource_Select( CLK_SCLKSEL_PLL_gc );
CLKSYS_Disable( OSC_XOSCEN_bm );
} /* init_clock() */

=== USART ===

==== USART über USB ====

So stellt man unter Verwendung der Software zu AVR1307 (-> Siehe auch) bei 32 MHz Takt den USART für die Übertragung per USB ein:

#include "usart_driver.h"

#define USART USARTD0

void init_usart( void )
{
PORTD.DIRSET = PIN3_bm;
PORTD.DIRCLR = PIN2_bm;
USART_Format_Set( &USART, USART_CHSIZE_8BIT_gc, USART_PMODE_DISABLED_gc, false );
/*
* BSEL[11:0]-Wert bei 32MHz Takt und BSCALE[3:0]==0:
* 207 : 9600
* 103 : 19200
* 51 : 38400
* 34 : 57600
* 16 : 115200
*/
USART_Baudrate_Set( &USART, 34 , 0 );
USART_Rx_Enable( &USART );
USART_Tx_Enable( &USART );
} /* init_usart() */

== Siehe auch ==

* [http://www.mikrocontroller.net/topic/227310 Ursprungsbeitrag im Forum]
* [http://www.jtronics.de/avr-projekte/xmega-tutorial.html XMEGA Tutorial in C] - Tutorial ATxmega (ATxmega128A3U)
* [http://www.atxmega-board.de/stick Die Seite des Sticks] mit Schaltplan und Stückliste
* <del>[http://www.stromflo.de/dokuwiki/doku.php?id=xmega-c-tutorial XMEGA-C-Tutorial auf stromflo.de]</del> :-(
* [http://www.atmel.com/dyn/products/product_card.asp?part_id=4302 Produktseite des ATxmega128A3] mit jeder Menge an Dokumentation und Application Notes
* [http://www.atmel.com/dyn/resources/prod_documents/doc8072.pdf AVR1003: Using the XMEGA Clock System] (PDF) und [http://www.atmel.com/dyn/resources/prod_documents/AVR1003.zip Software] (ZIP)
* [http://www.atmel.com/dyn/resources/prod_documents/doc8049.pdf AVR1307: Using the XMEGA USART] (PDF) und [http://www.atmel.com/dyn/resources/prod_documents/AVR1307.zip Software] (ZIP)
* [http://www.microchip.com/wwwproducts/devices.aspx?dDocName=en546923 Produktseite des MCP2200] mit Dokumentation und Tools

[[Kategorie:AVR-Projekte]]

AVR-GCC-Codeoptimierung

2012-07-24T22:39:11Z

Maybee: /* Logische Operatoren werden auf int-Größe erweitert */

Entstanden aus diesem [http://www.mikrocontroller.net/topic/66690 Thread] sollen hier ein paar Hinweise/Erfahrungen gegeben werden, um den Quellcode in Punkto Größe und Geschwindigkeit zu optimieren. ''En detail'' ist das Thema komplex, da es stark von der Codeoptimierung des Compilers abhängt. Es ist im Einzelfall ratsam zu prüfen, ob die eigenen Maßnahmen auch erfolgreich waren. Die Diskussionen [http://www.mikrocontroller.net/topic/132624] bzw. [http://www.mikrocontroller.net/topic/180800#new] können als Anhaltspunkte dienen, wie eine solche Prüfung ablaufen kann.

== Prinzipien der Optimierung ==

Wie so oft sollte man nicht einfach wild drauf los optimieren und sich zunächst ein paar Dinge klar machen.

* Warum will ich optimieren?
* Was kann man sinnvoll optimieren?
* Wieviel Rechenzeit oder Speicher soll dabei gespart werden?
* Wie kann optimiert werden?
* "Verfrühte Optimierung ist die Wurzel allen Übels"

Viele Optimierungen sind "Angst-Optimierungen", die nicht wirklich nötig sind. Die Gefahr mit Optimierungen ist, den Code tot zu optimieren, sprich Lesbarkeit, Portierbarkeit und ggf. Fehlerfreiheit sinken massgeblich. Kurz und knapp in diesem [http://blogs.msdn.com/b/audiofool/archive/2007/06/14/the-rules-of-code-optimization.aspx BLOG] formuliert.

=== Warum ===

Optimieren sollte man nur, wenn
* der Speicher nicht mehr ausreicht (RAM, Flash)
* Die Laufzeit für bestimmte Programmteile zu groß wird und somit bestimmte (Echtzeit-)Ausgaben nicht im erforderlichen Zeitrahmen erledigt werden

Weiter sollte man folgende Punkte gegeneinander abwägen:

* Codeverbrauch
* Datenverbrauch. Statisch/Stack/Heap
* Mittlere Laufzeit/maximale Laufzeit
* Entwicklungszeit
* Portabilität (Compiler, Hardware, ...)
* Verständlichkeit der Quelle, siehe [[Strukturierte Programmierung auf Mikrocontrollern]]
* ABI-Konformität

=== Was ===

Die goldene Regle lautet: 90% der Rechenleistung werden in 10% des Codes verbraucht. Diese 10% muss man finden und zum richtigen Zeitpunkt optimieren. Der Rest muss nur sauber und lesbar geschrieben sein. Was jedoch nichts bringt, ist eine Funktion, die von 1 Minute Programmlaufzeit lediglich 1 Sekunde verbraucht, um den Faktor 10 schneller zu machen. Die Programmlaufzeit sinkt dann von 60 Sekunden auf 59.1 Sekunden. Der Aufwand, die Funktion um einen Faktor 10 schneller zu machen ist aber meistens beträchtlich! Kann ich aber den Code, der für die 59 Sekunden verantwortlich ist um einen Faktor 10 schneller machen, dann sinkt die Gesamtlaufzeit von 60 Sekunden auf 6.9 Sekunden. Dort bringt Optimieren augenscheinlich viel mehr!

Um die optimierungswürdigen Stellen zu finden, muss man sein Programm analysieren. Dazu gibt es verschiedene Möglichkeiten.

====Speicherverbrauch nach Funktionen aufschlüsseln====

;map-File:
:dort sind alle globalen und statischen Variablen enthalten. Eine Map-Datei kann mit den GNU-Tools während des Linkens angelegt werden:
::<pre>> avr-gcc ... -Wl,-Map,foo.map</pre>
: Die Option -Wl bewirkt, daß avr-gcc die angehängen Optionen unverändert an den Linker weiterreicht. Dieser erzeugt dann das Mapfile "foo.map", eine Textdatei.
;avr-size: Mit Tools wie avr-size kann die Platzbelegung einzelner Module ermittelt werden:
::<pre>> avr-size -x foo1.o foo2.o ...</pre>
:bzw. die Platzbelegung der elf-Datei:
::<pre>> avr-size foo.elf</pre>
;avr-nm:
::<pre>> avr-nm --size-sort -S foo.elf</pre>
:ergibt eine Liste mit der Größe aller Objekte: der erste Spalte enthälte die Adresse, die zweite Spalte die Größe, die dritte den Typ und die vierte Spalte den zugehörigen Symbolnamen. Der Typ ergibt sich aus der folgenden Zuordnung, wobei Großbuchstaben globale Symbole kennzeichnen und Kleinbuchstaben Symbole, die Modul-lokal sind:
:;T/t: Objekte in der text-Section: Funktionen, Daten im Flash
:;D/d: Objekte im data-Segment (initialisierte Daten)
:;B/b: Objekte im bss-Segment (Null-initialisierte Daten)

;avr-gcc: Der Compiler hat bereits Informationen über die übersetzten Funktionen, die man direkt zur Analyse verwenden kann. Dazu lässt man avr-gcc die Assembler-Ausgabe, die ohne weiteres Zutun nur als temporäre Datei angelegt wird, abspeichern. Etwa für die Quelldatei foo.c:
::<pre>> avr-gcc -save-temps foo.c -c ...</pre>
:Die Assembler-Datei wird damit als foo.s angelegt und nicht gelöscht. (Das ebenfalls angelegte Präcompilat foo.i wird nicht benötigt). Für jede Funktion gibt avr-gcc 3.4.x im Prolog einen Kommentar der Form<ref>Für avr-gcc 4.x sehen die Kommentare anders aus oder fehlen je nach Compilerversion ganz</ref>
::<pre>/* prologue: frame size=0 */</pre>
:aus, was die Größe des aktuellen Frames angibt. Dies ist der Platz auf dem Stack, der für lokale Variablen benötigt wird. Am besten ist es, wenn die Frame-Size wie im Beispiel gleich 0 ist. Ansonsten sollte man versuchen, diese Größe auf Null zu bringen. Für Variablen, die nicht in Registern gehalten werden können, müssen Speicherzugriffe in den Stack erzeugt werden. Diese machen das Programm sowohl größer aus auch langsamer. Zudem reserviert avr-gcc bei solche Funktionen das Y-Register als Frame-Pointer; das Y-Register steht damit nicht mehr für lokale Variablen zur Verfügung was sich ebenfalls ungünstig auf die Codegüte auswirkt. Ein Grund für das Anlegen eines Frames können zu viele lokale Variablen sein (zB lokale Puffer/Arrays) oder lokale Variablen/Strukturen/Parameter mit ungünstigen Größen, etwa eine 3-Byte große Struktur.

: Neben dieser Information gibt avr-gcc Kommentare der Gestalt
::<pre>/* prologue end (size=2) */</pre>
:aus die darüber informieren, wie viele Register auf dem Stack gesichert wurden.

: Zusammen mit Werkzeugen wie grep, die in jedem Linux und jeder WinAVR-Distribution enthalten sind, findet man schnell Übeltäter wie Funktionen mit Frame.

;Assembler-Code sichten: Ein kurzer Blick auf den erzeugten Assembler-Code zeigt oft, wie gut der Compiler den Code umgesetzt hat. Den erzeugten Assembler-Code zu überfliegen ist wesentlich zeitsparender als selbst in Assembler zu programmieren. Je nach Gusto verwendet man zur Einsicht den Assembler-Code, den avr-gcc ausgibt (s.o.), Assembler-Dumps des Assemblers, List-Files oder HEX-Dumps. Siehe auch<ref>[http://rn-wissen.de/index.php/Assembler-Dump_erstellen_mit_avr-gcc roboternetz.de: Assembler-Dump erstellen mit avr-gcc]</ref>

;Hilfsmittel: einkaufen oder selber bauen. Es gilt herauszufinden, welche Funktion massig Stack durch lokale Variablen verbraucht. Stacktracer können das. Wenn man keinen hat, dann muss man sich eben selber einen bauen, indem man den Stackpointer mitloggt. Zur Not einen Code-Review machen: Alle Funktionen optisch durchgehen und die identifizieren, die viele Variablen anlegen. Dann die Aufrufhierarchie der Funktion feststellen: Wirken sich die vielen Variablen überhaupt aus oder entsteht mein Problem durch eine tiefe Funktionsaufrufhierarchie, bei der zwar wenige Variablen pro Funktion im Spiel sind, aber die Menge der ineinandergeschachtelten Aufrufe 'das Kraut fett macht'
;Profitools: können das alles fast auf Knopfdruck, kosten aber viel Geld

====Laufzeit messen====

*Simulator
*In Echtzeit mittels Testpin, welche an Anfang einer Funktion/Blocks gesetzt wird und am Ende wieder gelöscht wird. Mit einem [[Oszilloskop]] kann man so sehr einfach die Laufzeit messen.

; Anmerkung: Solche Messverfahren liefern immer nur eine ''untere'' Schranke für die Laufzeit, niemals eine obere Schranke. Eine obere Schranke, wie man sie etwa in sicherheitsktitischen Systemen benötigt, liefert eine statische Codeanalyse.

=== Wieviel ===

Der Aufwand von Optimierungen wächst exponentiell. Die letzten paar Prozent brauchen überproportional viel Aufwand.

=== Wie ===

Meist muss man die Wahl treffen ob man Speicher oder Rechenzeit sparen will, beides gleichzeitg geht meist nicht. Das Konzept heißt 'Space for Time' und kann in beide Richtungen verwendet werden. Als Beispiel soll eine komplizierte Berechnung dienen. Diese kann man relativ kompakt in eine Funktion packen, welche dann aber eher langsam ist. Oder man benutzt eine sehr große Tabelle, in welcher die Ergebnisse schon für jeden Eingangswert vorausberechnet wurden. Diese Lösung ist sehr schnell, verbraucht aber sehr viel Speicher.

* Inlining von Funktionen erhöht den Speicherverbrauch, senkt aber die Laufzeit. Beispiel: Funktion A ist 50 Byte groß und wird 10 mal im Programm aufgerufen. Ein Aufruf kostet 10 Byte:
** Ohne Inline: 10 * 10Byte + 50 Byte = 150 Byte Platzverbrauch
** Mit Inline: 10 * 50 Byte = 500 Byte
* Optimierer einschalten
* möglichst keine Floating Point Operationen, besser ist meist [[Festkommaarithmetik]]
* Formeln umstellen und zusammenfassen
* Variablen so klein wie möglich, uint8_t wo's nur geht.
* Wirklich zeitkritische Funktionen und Interrupts als Assemblercode in separater Datei

== GCC-Optionen ==

=== Optimierungs-Level ===

avr-gcc kennt mehrere Optimierungsstufen:
;<tt>-O0</tt>: Keine Optimierung des erzeugten Codes. Diese Optimierungsstufe optimiert den Resourcenverbrauch des ''Hostrechners'' und die Nachvollziehbarkeit der erzeugten Codes anhand von Debug-Information. Alle lokalen Variablen werden auf dem Stack angelegt und nicht in Registern gehalten. Es werden keine komplexen Optimierungsalgorithmen angewandt; lediglich Konstanten wie 1+2 werden zu 3 gefaltet.

;<tt>-O1</tt>: Je höher die Optimierungsstufe, desto schwieriger ist der erzeugte Code nachvollziehbar — auch mit Debugger. Diese O-Stufe ist ein Kompromiss zwischen aggressiver Optimierung und Nachvollziehbarkeit des erzeugten Codes. Ein ehernes Gesetz in GCC ist, dass er den gleichen Code erzeugen muss unabhängig davon, ob Debug-Information erzeugt wird oder nicht. Im Umkehrschluss erlaubt volle Debug-Unterstützung nicht alle Optimierungen, wozu diese Optimierungsstufe dient.

;<tt>-O2</tt>: Optimierung auf Geschwindigkeit. Für AVR nur mässig sinnvoll, da sich der Codezuwachs nicht in einen entsprechenden Geschwindigkeitszuwachs transformiert. Dies liegt vor allem daran, daß Sprünge und Funktionsaufrufe auf AVR im Vergleich zu anderen Architekturen sehr billig sind. Es bringt also kaum einen Geschwindigkeitszuwachs, einen Block zu kopieren um einen Sprung zu sparen. Hingegen vergrößert dies den Code deutlich.

;<tt>-O3</tt>: Ditto. Auf Teufel-komm-raus Funktionen zu inlinen, Schleifen aufzurollen oder gar Funktionen mehrfach für unterschiedliche Aufruf-Szenarien zu implementieren, ist auf einem kleinen µC wie AVR der Overkill.

;<tt>-Os</tt>: Optimierung auf Codegröße. Die bevorzugte Optimierungsstufe für AVR und viele andere µC.

Jede O-Option ist ein Sammlung von verschiedenen Schaltern, welche bestimmte Optimierungsstrategien aktivieren. Um zu sehen, welche Schalter dies genau sind, erzeugt man wie oben beschrieben mit den Schalten
-save-temps -fverbose-asm
die Assembler-Ausgabe von gcc und schaut die Optionen im s-File nach. Einzelne Optionen lassen sich gezielt aktivieren bzw. deaktivieren und damit zum Beispiel zum <tt>-Os</tt>-Paket hinzufügen.

Eine Ausnahme bildet <tt>-O0</tt>: Hier ist Code-Optimierung generell deaktiviert, und Optimierungsschalter bleiben ohne Wirkung.

=== Feinabstimmung der Optimizer ===

Kandidaten für Optimierungsoptionen sind folgende Schalter. <tt>-m</tt> kennzeichnet maschinenspezifische Schalter, die nur für AVR gültig sind. <tt>-f</tt> bzw. <tt>-fno-</tt> sind maschinenunabhängige Schalter, die auch für andere Architekturen verfügbar sind.

;<tt>-fno-split-wide-types</tt>: Je nach Quelle kann die Deaktivierung von <tt>-fsplit-wide-types</tt> besseren Code ergeben.

;<tt>-fno-inline-small-functions</tt>: Relativ kleine Funktionen /immer/ zu inlinen kann den Code unnötig vergrößern, dieser Schalter unterbindet das automatische Inlinen kleiner Funktionen.

;<tt>-finline-limit=</tt>''wert'': Maximalwert für automatisch geinlinte Funktionen. In einschlägigen Foren werden kleine Werte für ''wert'' vorgeschlagen, z.B. 1…3

;<tt>-mcall-prologues</tt>: Die für aufwändige Funktionen mitunter recht langen push/pop-Sequenzen werden durch Hilfsfunktionen ersetzt. Das kann vor allem bei grossen Programmen Platz sparen. Die Ausführungszeit steigt an.

;<tt>-fno-jump-tables</tt>: Switch-Statements werden hierdurch mitunter deutlich kürzer.

;<tt>-fno-move-loop-invariants -fno-tree-loop-optimize</tt>: Einige Schleifenoptimierungen, welche die Registerlast erhöhen und für AVR kaum zu einem Geschwindigkeitszuwachs führen, werden deaktiviert.

;<tt>-fno-tree-switch-conversion</tt>: Neue GCC-Versionen können switch/case Anweisungen u.U. in Loopup-Tabellen umwandeln, die im RAM abgelegt werden, siehe auch [http://gcc.gnu.org/PR49857 PR49857]. Dieser Optimierung ist bei RAM-Knappheit in Betracht zu ziehen, bring aber natürlich nur dann etwas, wenn diese Optimierung auch ausgeführt wurde.

;<tt>-fno-optimize-sibling-calls</tt>:Tailcall-Optimierung kann den Code vergrößern, wenn Epiloge mehrfach erzeugt werden. In diesem Fall deaktiviert man die Tailcall-Optimierung. Wirksam ab Version 4.7.

;<tt>-maccumulate-args</tt>: Ab 4.7: Funktionen, die mehrere printf-artige Aufrufe enthalten und viele Artumente per Stack an diese übergeben, werden u.U kleiner.

;<tt>-mstrict-X</tt>: Ab 4.7: Beeinflusst die Art und Weise, wie das X-Register zur Adressierung verwendet wird.

;<tt>-mbranch-cost=</tt>''wert'': Setzt die Kosten, mit der der Compiler einen bedingten Sprunge veranschlagt. Default-Wert ist ''wert''<tt>=0</tt>.

;<tt>-fno-caller-saves</tt>: Kann zu effizienteren Pro-/Epilogen beitragen.

;<tt>-fno-tree-ter</tt>: Es gibt Fälle, in denen der Compiler die Berechnung temporärer Variablen über volatile-Zugriffe und Memory-Barriers zieht, siehe [http://gcc.gnu.org/PR53033 PR53033]. Von der C-Spezifikation her ist dies zulässig, kann aber zu unerwünschter Umsortierung der volatile-Operation führe, z.B. wenn es sich dabei um eine <tt>SEI</tt>-Instruktion handelt. Ohne diese Optimierung wird der Code evtl. etwas größer, aber Probleme wie im PR beschrieben können vermieden werden.

;<tt>--param case-values-threshold=</tt>''wert'': Ab 4.7: Schwellwert an Einträgen in einem switch/case, ab dem anstatt eines binären if/else-Entscheidungsbaums eine Sprungtabelle zu den case-Labels erzeugt wird. Voreinstellung ab 4.7 ist ''wert''<tt>=7</tt>. Ältere Compilerversionen verwenden andere Werte. Siehe auch <tt>-f[no-]jump-tables</tt>.

Generell gilt für all diese Optionen, daß sie abhängig vom Projekt zu einer Codeverbesserung oder -verschlechterung führen können — dies ist i.d.R. vom Projektcode abhängig.

=== Linker-Optionen ===

;<tt>-ffunction-sections -Wl,--gc-sections</tt>: Der Linker wirft nicht referenzierte Sections weg, was die Codegröße günstig beeinflussen kann. Diese Optimierung verkleinert den Code nur dann, wenn nicht verwendete Funktionen in der Anwendung rumgammeln. Weil der Linker nur auf Section-Ebene optimieren kann, muss zusätzlich der Compiler mit <tt>-ffunction-sections</tt> aufgerufen werden, um die Anwendung auf möglichst viele Sections zu verteilen.

;<tt>-Wl,--relax -mrelax</tt>: Der Linker fasst Tail-Calls wie
::<tt>CALL some_function RET</tt>
: zusammen als
::<tt>JMP some_function</tt>
: Siehe auch die Compiler-Option <tt>-f[no-]optimize-sibling-calls</tt> von oben. Zudem wird <tt>CALL</tt> umgewandelt zur kürzeren <tt>RCALL</tt>-Instruktion falls das Sprungziel im ±4 KiB-Zielbereich von <tt>RCALL</tt> liegt. Analog für <tt>JMP</tt> zu <tt>RJMP</tt>.

: Die beiden Optionen sind gleichwertig; die erste Variante veranlasst den Compiler, den Linker mit <tt>--relax</tt> aufzurufen. Die zweite Variante verwendet den allgemeinen <tt>-Wl</tt>-Mechanismus, um eine Option von der Compiler-Kommandozeile an den Linker durchzureichen.

=== Weitere Optionen ===

;<tt>-mtiny-stack</tt>: Der Compiler ändert nur das Low-Byte des Stackpointers (SP), was auf Controllern mit 16-Bit SP zu kleinerem Code führen kann. Benötigt der Code Platz auf dem Stack, so erzeugt der Compiler u.U. Code, der den SP liest, einen Offset aufaddiert/abzieht und den SP dann zurückschreibt. Dies ist aufwändig. Für den Fall, daß sich dabei das High-Byte SP nicht ändert, kann Code eingespart werden.

:Beispiel: ATtiny44 hat RAM von <tt>0x60</tt> bis <tt>0x15f</tt>. Braucht die Anwendung nicht mehr als <tt>0x60</tt> = 96 Bytes an Stack, dann kann mit <tt>-mtiny-stack</tt> compiliert werden.

=== Änderung des Binärinterfaces per Option ===

{{Warnung|
;Warnung: Im Gegensatz zu den Optionen der vorherigen Abschnitte, bei denen es sich um reine Optimierungsoptionen handelt, ändern die folgenden Optionen das Binärinterface (ABI) des vom Compiler erzeugten Codes und sind daher nur nach eingehender Prüfung anzuwenden! Wird eine Anwendung mit diesen Schaltern übersetzt, dann ist sicher zu stellen, daß ''alle'' Module inclusive Libraries damit derzeugt werden oder die ABI-Änderung sich nicht auf Code in Bibliotheken auswirkt!
}}

Vorsicht in auch deshalb geboten, weil manche Entwicklungsumgebungen wie "Atmel Studio" das ABI ''per Default'' verändern und ohne daß der Anwender es extra anfordert.

;<tt>-funsigned-char</tt>: Anders als im avr-gcc ABI ist der Typ <tt>char</tt> unsigned anstatt signed.
:Besser: Verwende die C99-Typen wie <tt>uint8_t</tt> aus dem C99-Header <tt>stdint.h</tt>.

;<tt>-funsigned-bitfields</tt>: Bitfelder mit Basetype <tt>char</tt>, <tt>short</tt>, <tt>int</tt> <tt>long</tt> und <tt>long long</tt> werden als unsigned implementiert anstatt als signed wie in der avr-gcc ABI.
:Besser: Wenn ein Bitfeld unsigned sein soll, dann mach es unsigned!

;<tt>-fpack-struct</tt>: Im Gegensatz zur avr-gcc ABI werden Strukturen und Unions per defulat gepackt.
:Besser: Wenn ein zusammengesetzter Typ gepackt werden soll, mache ein Typedef mit explizitem <tt>__attribute__((packed))</tt>!

;<tt>-fshort-enums</tt>: Enum-Typen werden so kurz wie möglich implementiert anstatt als <tt>int</tt> gemäß avr-gcc ABI.

;<tt>-mint8</tt>: Ein <tt>int</tt> ist nur nocht 8 Bits breit. Dies entspricht nicht mehr dem C-Standard und wird nicht durch die C-Bibliothek wie AVR-Libc unterstützt! Die Codegröße kann sich im Vergleich zu 8-Bit Operationen ohne diese Option verkleinern, weil andere Integer-Promotion Regeln angewandt werden. Literals müssen ggf. angepasst bzw gecastet, siehe auch Makros wie <tt>UINT16_C</tt> aus dem C99-Header <tt>stdint.h</tt>.

== Anpassungen der Quelle ==

=== Attribute noreturn, OS_main und OS_task ===

Mikrocontroller-Programme laufen normalerweise in einer Endlosschleife, so dass die main-Routine nie verlassen wird.
Teilt man dies dem Compiler mit, kann er bestimmte Optimierungen durchführen.
So ist es zum Beispiel unnötig, Code zum Sichern und Zurücklesen von Registern zu erzeugen.

Das Mitteilen funktioniert beim gcc über Attribute, die man der Deklaration oder bei der Implementierung einer Funktion anhängt:
<c>static void main_loop (void) __attribute__((noreturn));
void main_loop (void)
{
while (1)
{
// Hauptschleife
}
}</c>
oder
<c>static void __attribute__((noreturn))
main_loop (void)
{
while (1)
{
// Hauptschleife
}
}</c>

Die Funktion <tt>main_loop</tt> kann dann in <tt>main</tt> aufgerufen werden:

<c>int main (void)
{
main_loop();

return 0;
}</c>
Das abschließende <tt>return</tt> wird vom Compiler wegoptimiert und belegt keinen Speicher.

<tt>avr-gcc</tt> kennt weiterhin die Attribute <tt>OS_main</tt> und <tt>OS_task</tt>.
Die Verwendung von <tt>OS_main</tt> kann etwa aussehen wie folgt. Natürlich kann auch wie oben die Hauptschleife in einer eigenen Funktion implementiert werden, und das <tt>return</tt> verursacht keinen zusätzlichen Code:
<c>int __attribute__((OS_main))
main (void)
{
while (1)
{
// Hauptschleife
}

return 0;
}</c>

=== Statische Variablen in einer Struktur sammeln ===

Gibt es in einem Programm mehrere inhaltlich zusammengehörende Variablen, dann ist es sinnvoll diese in einer Struktur zu vereinigen. Neben einer klareren Programm- bzw. Datenstruktur kann dies auch zu kleinerem Code führen.

Beispiel ist die folgende kleine Routine, welche die Teit in der globalen <tt>time</tt>-Strukture um eine Sekunde erhöht:

Beispiel:
<c>
#include <stdint.h>

typedef struct
{
uint8_t second;
uint8_t minute;
uint8_t hour;
} time_t;

// Globale time-Struktur enthält die Zeit
time_t time;

void next_second (void)
{
// Zeiger auf die globale time-Struktur
time_t *ptime = &time;

// time um 1 Sekunde erhöhen

if (++ptime->second == 60)
{
ptime->second = 0;

if (++ptime->minute == 60)
{
ptime->minute = 0;

if (++ptime->hour == 24)
ptime->hour = 0;
}
}
}
</c>

Die Funktion enthält mehrere indirekte Zugriffe auf die <tt>time</tt>-Struktur, und es wäre günstig, wenn <tt>avr-gcc</tt> indirekte Adressierung für die Zugriffe verwendet: Alle Zugriffe geschehen über den Struktur-Zeiger <tt>ptime</tt>, und ein indirekter Zugriff per <tt>LD</tt>, <tt>LDD</tt>, <tt>ST</tt> oder <tt>STT</tt> kostet 2 Code, während die direkten Spreicherzugriffe <tt>LDS</tt> und <tt>STS</tt> jeweils 4 Bytes verbrauchen.

<tt>avr-gcc</tt> erzeugt jedoch folgenden Code, wenn auf Größe optimiert wird:

<c>
next_second:
// if (++ptime->second == 60)
lds r24, time
subi r24, -1
sts time, r24
cpi r24, 60
brne .L1
// ptime->second = 0;
sts time, __zero_reg__
// if (++ptime->minute == 60)
lds r24, time+1
subi r24, -1
sts time+1, r24
cpi r24, 60
brne .L1
// ptime->minute = 0;
sts time+1, __zero_reg__
// if (++ptime->hour == 24)
lds r24,time+2
subi r24, -1
sts time+2, r24
cpi r24, 24
brne .L1
// ptime->hour = 0;
sts time+2, __zero_reg__
.L1:
ret
</c>
D.h. obwohl der C-Code indirekt zugreift, enthält das Compilat direkte Zugriffe und der Code belegt 56 Bytes an Flash. Grund ist, daß der Compiler den Inhalt der Variablen <tt>ptime</tt> kennt und daher die indirekten Struktur-Zugriffe in direkte umwandelt.

Um indirekte Adressierung im erzeugten Code zu erzwingen, kann man die Struktur-Adresse als Parameter übergeben:
<c>
void next_second (time_t *ptime)
</c>
oder – als hässliche Lösung – dem Compiler des Wissen um den Inhalt von <tt>ptime</tt> per Inline-Assembler nehmen:
<c>
asm ("" : "+r" (ptime));
</c>

Dies führe denn zu folgendem Code, der um 25% kleiner ist und nur noch 42 Bytes Flash belegt:
<c>
next_second:
// time_t *ptime = &time;
// asm ("" : "+r" (ptime));
ldi r30, lo8(time)
ldi r31, hi8(time)
// if (++ptime->second == 60)
ld r24, Z
subi r24, -1
st Z, r24
cpi r24, 60
brne .L1
// ptime->second = 0;
st Z, __zero_reg__
// if (++ptime->minute == 60)
ldd r24, Z+1
subi r24, -1
std Z+1, r24
cpi r24, 60
brne .L1
// ptime->minute = 0;
std Z+1, __zero_reg__
// if (++ptime->hour == 24)
ldd r24, Z+2
subi r24, -1
std Z+2, r24
cpi r24, 24
brne .L1
// ptime->hour = 0;
std Z+2, __zero_reg__
.L1:
ret
</c>

Weil AVRs nur zwei Zeiger-Register haben, die über diese Addressierungsart verfügen (Y und Z), ist diese Optimierung nur eingeschränkt anwendbar.

Werden etwa Z oder Y für andere Zwecke benötigt – etwa für Flash-Adressierung per <tt>LPM</tt> oder Y als Frame-Pointer gebraucht – verkleinert sich das Anwendungsfeld noch weiter. Zudem müssen genügend Struktur-Zufriffe nacheinander erfolgen, damit ein positiven Effekt auf die Codegröße zustande kommt. Immerhin muss die Adresse geladen werden, das Zeiger-Register wird belegt, und im Falle von Y kommen <tt>PUSH</tt>/<tt>POP</tt> im Prolog/Epilog hinzu. Gibt es Zugriffe auf viele ("viele" relativ zu den zur Verfügung stehenden Pointer-Registern), kann die Codegröße auch ansteigen.

=== Multiplikationen mit Konstanten ===

Der Compiler instanziiert sofort eine teure allgemeine Bibliotheksfunktion, auch wenn es anders ginge. Ich hatte eine einzige 32-bit Multiplikation mit 10 drin, die mir ein mulsi3 beschert hat. Mit a = (b<<3) + (b<<1) geht es in dem Fall kürzer. Wie gesagt, map-File beobachten.

;Anmerkung: Variablen als unsigned definieren, dann sollte der Compiler das selbst machen.

;Anmerkung: Auch Schieben ist teuer auf AVR. Schauen wir uns also mal an, was aus folgendem Code wird:

<c>
uint32_t foo (uint32_t i)
{
return i*10;
}

uint32_t bar (uint32_t i)
{
return (i << 1) + (i << 3);
}
</c>

{{Scrollbox|15ex;|
<pre>
00000032 <foo>:
32: 2a e0 ldi r18, 0x0A ; 10
34: 30 e0 ldi r19, 0x00 ; 0
36: 40 e0 ldi r20, 0x00 ; 0
38: 50 e0 ldi r21, 0x00 ; 0
3a: 19 d0 rcall .+50 ; 0x6e <__mulsi3>
3c: 08 95 ret

0000003e <bar>:
3e: 26 2f mov r18, r22
40: 37 2f mov r19, r23
42: 48 2f mov r20, r24
44: 59 2f mov r21, r25
46: 22 0f add r18, r18
48: 33 1f adc r19, r19
4a: 44 1f adc r20, r20
4c: 55 1f adc r21, r21
4e: e3 e0 ldi r30, 0x03 ; 3
50: 66 0f add r22, r22
52: 77 1f adc r23, r23
54: 88 1f adc r24, r24
56: 99 1f adc r25, r25
58: ea 95 dec r30
5a: d1 f7 brne .-12 ; 0x50 <__SREG__+0x11>
5c: 26 0f add r18, r22
5e: 37 1f adc r19, r23
60: 48 1f adc r20, r24
62: 59 1f adc r21, r25
64: 95 2f mov r25, r21
66: 84 2f mov r24, r20
68: 73 2f mov r23, r19
6a: 62 2f mov r22, r18
6c: 08 95 ret

0000006e <__mulsi3>:
6e: ff 27 eor r31, r31
70: ee 27 eor r30, r30
72: bb 27 eor r27, r27
74: aa 27 eor r26, r26

00000076 <__mulsi3_loop>:
76: 60 ff sbrs r22, 0
78: 04 c0 rjmp .+8 ; 0x82 <__mulsi3_skip1>
7a: a2 0f add r26, r18
7c: b3 1f adc r27, r19
7e: e4 1f adc r30, r20
80: f5 1f adc r31, r21

00000082 <__mulsi3_skip1>:
82: 22 0f add r18, r18
84: 33 1f adc r19, r19
86: 44 1f adc r20, r20
88: 55 1f adc r21, r21
8a: 96 95 lsr r25
8c: 87 95 ror r24
8e: 77 95 ror r23
90: 67 95 ror r22
92: 89 f7 brne .-30 ; 0x76 <__mulsi3_loop>
94: 00 97 sbiw r24, 0x00 ; 0
96: 76 07 cpc r23, r22
98: 71 f7 brne .-36 ; 0x76 <__mulsi3_loop>

0000009a <__mulsi3_exit>:
9a: 9f 2f mov r25, r31
9c: 8e 2f mov r24, r30
9e: 7b 2f mov r23, r27
a0: 6a 2f mov r22, r26
a2: 08 95 ret

</pre>
}}

: Der Funktionsaufruf samt Lib-Funktion ist garnicht sooo teuer. Bereits mit zwei Multiplikationen im Programm — auch einer Multiplikation mit einer anderen Konstanten oder einer Variablen — gewinnt die lib-Version, da der Code wiederverwendet wird. Übrigens sind diese Multiplikationsroutinen und auch die in die libgcc enthaltenen Divisionen keine "normalen" Funktionen wie sie von C erzeugt werden. avr-gcc weiß genau, welche Register diese Routinen belegen und welche nicht. Damit ist der Aufruf einer solchen Funktion billiger als ein herkömmlicher Funktionsaufruf, bei dem die Funktion als Blackbox behandelt werden muss, die alle call-clobbered Register zerstört.

=== Alle Variablen nur so breit wie nötig ===

Hatte ich eigentlich schon, nur an einigen wenigen Stellen war ich da etwas nachlässig. Mitunter reicht ein kleinerer Typ doch, wenn man z. B. vorher geeignet skaliert. Am besten nur die skalaren Typen aus <stdint.h> verwenden, das erleichtert auch das Folgende. Bei RAM Knappheit: kann ich Strings sinnvollerweise aus dem RAM ins Flash verbannen? Kann ich es mir leisten mehrere Flag-Variablen in ein Byte zusammenzufassen, auch wenn dann die Zugriffe möglicherweise etwas langsamer werden.

=== Logische Operatoren werden auf int-Größe erweitert ===

Obwohl der AVR ein 8-Bit Controller ist, verlangt der C-Standard, daß ein <tt>int</tt> mindestens 16 Bits groß ist. Wegen den Promotion-Regeln von C werden 8-Bit Operanden in Operationen auf 16 Bits aufgeweitet. Beispiel:

<c>
#include <stdint.h>

uint8_t c;

void foo (uint8_t a, uint8_t b)
{
if (a == ~b)
c = 0;
}
</c>
Den zweiten Operanden mit dem Komplement weitet der Compiler auf 16 Bit auf, wodurch alle high-Bits von <tt>~b</tt> gesetzt werden. Der Compiler erkennt, daß der Vergleich niemals wahr ist und optimiert ihn weg:
<c>
foo:
ret
</c>

Ein Cast verhindert dieses:
<c>
void foo (uint8_t a, uint8_t b)
{
if (a == (uint8_t) ~b)
c = 0;
}
</c>
was übersetzt wird zu:
<c>
foo:
// if (a == (uint8_t) ~b)
com r22
cpse r24, r22
rjmp .L1
// c = 0
sts c, __zero_reg__
.L1:
ret

</c>

;Achtung: Tatsächlich handelt es sich dabei nicht um ein Optimierungsproblem, sondern einen typischen Programmierfehler. Die beiden Varianten sind keineswegs identisch! Bei Variablen vom Typ <tt>uint8_t</tt> ist der Ausdruck <tt>(a == ~b)</tt> immer falsch!

=== Speichern von globalen Flags ===

Oft werden in den Programmen Flags verwendet um beispielsweise eingetroffene Interrupts in der main-Routine auszuwerten. Hierzu wird üblicherweise eine globale Variable verwendet.

Um den Wert dieser Variable abzufragen, muss sie jedoch erst aus dem SRAM in ein Register geladen werden, und kann dann erst auf ihren Status hin überprüft werden. Eine Möglichkeit ist, der globalen Variablen ein einziges Register fest zuzuordnen:
<c>
register uint8_t counter8_1 asm("r2");
register uint8_t counter8_2 asm("r3");
register uint16_t counter16_1 asm("r4"); // r4:r5
register uint16_t counter16_2 asm("r6"); // r6:r7
</c>
siehe auch: http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_regbind

Als Alternative kann man ein nicht verwendetes Register des I/O-Bereichs verwenden. Dabei würde sich z. B. das Register eines zweiten UARTs, oder das EEPROM-Register anbieten, falls diese nicht benötigt werden.

Neuere AVR-Modelle besitzen für diesen Zweck 3 frei verwendbare Bytes im bitadressierbaren I/O-Bereich: GPIOR0-2.

{{Warnung|
;Warnung: Dieses Vorgehen verändert das ABI! Um dieses Feature fehlerfrei anzuwenden, ist einiges an Wissen über die Interna von GCC notwendig. Auch ein korrekt funktionierendes Programm ist keine Garantie dafür, daß die globalen Register fehlerfrei implementiert wurden. Unter Umständen bringen erst spätere Codeänderungen/-erweiterung den Fehler zum Vorschein, und weil der Fehler vorher nicht akut war, sucht man sich den Wolf an der falschen Stelle im Code anstatt bei der globalen Registern. Siehe auch [[Globale Register]].}}

=== Puffern von volatile-Variablen ===

Der Compiler behandelt volatile-Variablen bei mehreren Manipulationen wie heiße Kartoffeln. Für jeden einzelnen Vorgang wiederholt sich das Spiel:

* aus dem Speicher holen
* bearbeiten
* zurückspeichern

Unter Umständen ist dieses Verhalten unsinnig. Ein Minimalbeispiel:

<c>
volatile char var;

ISR()
{
var++;

if (var > 100)
var = 0;
}

void main (void)
{
while (1)
printf (var);
}
</c>

Hier wird '''var''' pro [[ISR]]-Ausführung zwei mal aus dem RAM geholt und zurückgeschrieben. Das ist überflüssig, weil die Interruptrountine nicht unterbrochen werden kann. Aus Sicht der ISR bräuchte man eigentlich kein volatile, kann es aber wegen des Zugriffs aus main heraus nicht weglassen. Eine Lösung findet sich im folgenden Schnipsel:

<c>
volatile char var;

ISR()
{
char temp = var;

if (++temp > 100)
temp=0;

var = temp;
}

void main (void)
{
while (1)
printf (var);
}
</c>

Hier wird die globale Variable '''var''' in der lokalen Variable '''temp''' gepuffert. Ein Nachteil durch das Anlegen von '''temp''' ergibt sich nicht, da das dafür verwendete Register für die Manipulation sowieso benötigt wird.

Wie alle Optimierungen kann dieses Vorgehen auch nach hinten losgehen: Wenn Laden und Zurückspeichern von '''var''' weit auseinanderliegen (extrem lange ISR), müllt man sich die Register zu. Im schlimmsten Fall wird '''temp''' sogar zwischenzeitlich auf dem Stack ausgelagert.

=== Schleifen ===

Bei Schleifen, die eine bestimmte Anzahl an Durchläufen ausgeführt werden sollen, ist es besser den Schleifenzähler vorher auf einen Wert zu setzen, und am Ende einer Do-While Schleife diesen zu dekrementieren.
So beschränkt sich die Sprungbedingung auf ein brne (branch if not equal).

Beispiel:
<c>
uint8_t counter;
counter = 100;
do
{
// mach irgendetwas
} while (--counter);
</c>

==Optimierung der Ausführungsgeschwindigkeit==

Hierzu gibt es schon eine Application-Note von Atmel. Diese AppNote bezieht sich auf den IAR-Compiler. Die darin genannten "Optimierungen" sind für avr-gcc größtenteils obsolet oder bleiben bestenfalls ohne Effekt.

Weblinks:
* [http://www.atmel.com/dyn/resources/prod_documents/doc1497.pdf AVR035]: Efficient C Coding for AVR
* [http://en.wikipedia.org/wiki/Program_optimization Program optimization] auf Wikipedia, engl.
* [http://bleaklow.com/2012/06/20/sensor_smoothing_and_optimised_maths_on_the_arduino.html Sensor smoothing and optimised maths on the Arduino] - Multiplikation vs. Division

== Fußnoten ==
<references/>

== Links ==
[http://www.atmel.com/Images/doc8453.pdf Atmel AVR4027]: Tips and Tricks to Optimize Your C Code for 8-bit AVR Microcontrollers ([http://www.atmel.com/Images/AVR4027.zip Beispiel-Code])

[[Category:avr-gcc]]

ATxMega Stick - First Steps

2012-07-18T06:03:08Z

Maybee: /* Siehe auch */ Typo

[[Datei:ATxMegaStick-1.jpg|thumb|Platine des ATxMega Stick]]
Der ATxMega Stick ist eine kleine Platine (27 mm x 80 mm) mit ATxmega128A3, USB-Device-Anschluss und Micro-SD-Kartenslot.

== Eigenschaften ==

* Mikrocontroller ATxmega128A3
* USB-Baustein [http://kweb/wiki/images/b/ba/MCP2200_22228A.pdf MCP2200]
* Mini-USB-B-Device-Anschluss
* Micro-SD-Kartenslot
* Programmierung via PDI (z.B. AVRISP mkII)
* Reset-Taster
* 2 LEDs zur Signalisierung von USB-Transfers
* 2 frei verwendbare LEDs
* On-board-Spannungsregler (3.3 V, Versorgung über USB oder extern)
* 6 x 8-Bit-Ports auf Stiftleisten verfügbar, davon ist ein Port belegt (2-mal LED, RX und TX zum USB-Baustein, SPI zum Micro-SD-Kartenslot)

== Hinweise zum Aufbau ==

=== Anmerkungen zum Schaltplan vom 15.09.2011 23:08:38 ===

* Seite 1: C1 hat 22µF 
* Seite 1: C14, C15 haben 3.3µF
* Seite 2: Verbindungsbezeichnung bei "<tt>I/Os</tt>" µC Pin 27 und JP4 Pin 4 und bei "<tt>LEDs</tt>" muss <tt>LED3</tt> lauten statt <tt>LED1</tt>
* Seite 2: Verbindungsbezeichnung bei "<tt>I/Os</tt>" µC Pin 26 und JP4 Pin 3 und bei "<tt>LEDs</tt>" muss <tt>LED4</tt> lauten statt <tt>LED2</tt>

=== Stromversorgung ===

Auf JP1 muss ein Jumper bestückt werden:
* zum Platinenrand hin für Versorgung über USB
* zur Platinenmitte hin für externe Versorgung

Hinweis:

Der Jumper sollte unbedingt gesteckt sein, wenn USB verwendet wird. Steht dieser auf externer Versorung, muss diese dabei auch anliegen. Wird der MCP2200 per USB versorgt, ohne dass am ATxMega Versorgungsspannung anliegt, kommt es über die UART-Leitung zu einem Stromfluss über das entsprechende I/O-Pin des ATxMega, da dieser sich ohne Spannung intern in einem undefinierten Zustand befindet. Auf VCC liegen dann etwa 2.8 V an. Durch den Stromfluss erwärmt sich der MCP2200 deutlich, was zur eventuellen Beschädigung des ICs führen kann.

=== Löten des SD-Halters ===

* Zuerst muss man den Halten ausrichen und einen Punkt am Rand festlöten.
* Dann muss man alle 4 Ecken festlöten
* Jetzt kann man mit der Lötspitze oben durch die Aussparungen und führt den Zinn durch die Öffnung für die SD-Karte.
* So lötet man dann alle 8 Kontakte.
* Lötbrücken sind hier nicht schön, lässt sich aber dann noch mit Entlötlitze entfernen (Entlötlitze statt Zinn durch die Öffnung führen)

== Betrieb unter Linux ==

Damit man als User auf den Stick zugreifen kann, empfiehlt es sich, einen UDEV-Eintrag für den Stick anzulegen, z.B. neue Datei /etc/udev/rules.d/15_USB_uC.rules anlegen:

ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="00df", GROUP="MeineGruppe", MODE="0660", SYMLINK+="ATxMegaStick%n"

Für "MeineGruppe" einen geeigneten Werte verwenden, d.h. eine Gruppe, der man selbst angehört.

Jetzt kann man nach dem Anschließen folgende Links sehen:

ls -l /dev/ATxMegaStick*
lrwxrwxrwx 1 root root 7 2011-10-17 00:04 /dev/ATxMegaStick0 -> ttyACM0
lrwxrwxrwx 1 root root 11 2011-10-17 00:04 /dev/ATxMegaStick1 -> usb/hiddev1
lrwxrwxrwx 1 root root 7 2011-10-17 00:04 /dev/ATxMegaStick2 -> hidraw2
lrwxrwxrwx 1 root root 15 2011-10-17 00:04 /dev/ATxMegaStick3 -> bus/usb/001/042

Und die Zugriffrechte sehen so aus:

ls -lL /dev/ATxMegaStick*
crw-rw---- 1 root dialout 166, 0 2011-10-17 00:04 /dev/ATxMegaStick0
crw-rw---- 1 root mgr 180, 97 2011-10-17 00:04 /dev/ATxMegaStick1
crw-rw---- 1 root mgr 251, 2 2011-10-17 00:04 /dev/ATxMegaStick2
crw-rw-r-- 1 root mgr 189, 41 2011-10-17 00:04 /dev/ATxMegaStick3

== Fuses ==

Default-Werte der Fuses:

=== <tt>signature</tt>: Signatur ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U signature:r:-:h
0x1e,0x97,0x42
:0x1e9742 = ATxmega128A3

=== <tt>fuse0</tt>: JTAG User ID ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse0:r:-:h
0xff
:JTAG User ID (JTAGUID) = 0xff '''(das Manual sagt: 0x00)'''

=== <tt>fuse1</tt>: Watchdog Configuration ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse1:r:-:h
0x0
:Watchdog Window Timeout Period (WDWPER) = n.a.
:Watchdog Timeout Period (WDPER) = n.a.

=== <tt>fuse2</tt>: Reset Configuration ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse2:r:-:h
0xff
:Reset Vector (BOOTRST) = Application Reset
:BOD operation in power-down mode (BODPD) = BOD disabled

=== <tt>fuse4</tt>: Start-up Configuration ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse4:r:-:h
0xfe
:External Reset Disable (RSTDISBL) = no
:Start-up time (STARTUPTIME) = 0
:Watchdog Timer lock (WDLOCK) = no
:JTAG enabled (JTAGEN) = yes

Bei Bedarf ändern:
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse4:w:0xff:m
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse4:r:-:h
0xff
:JTAG enabled (JTAGEN) = no

=== <tt>fuse5</tt>: BODACT, BODLEVEL, EESAVE ===
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse5:r:-:h
0xff
:BOD operation in active mode (BODACT) = BOD disabled
:EEPROM memory is preserved through the Chip Erase (EESAVE) = no
:BOD voltage level (BODLEVEL) = 1.6V

Bei Bedarf ändern:
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse5:w:0xf7:m
avrdude -Pusb -cavrispmkII -px128a3 -q -q -U fuse5:r:-:h
0xf7
:EEPROM memory is preserved through the Chip Erase (EESAVE) = yes

== Software ==

=== Clock System ===

Takt zu Testzwecken auf Port C Pin 7 (d.h. JP3 Pin 3) ausgeben.
PORTC.DIRSET = 0x80;
PORTCFG.CLKEVOUT = 0x01;

==== 32 MHz mit dem externen Quarz ====

Unter Verwendung der Software zu AVR1003 (-> Siehe auch) kann man den Takt auf 32 MHz einstellen:

#include "clksys_driver.h"

void init_clock( void )
{
CLKSYS_XOSC_Config( OSC_FRQRANGE_12TO16_gc, false, OSC_XOSCSEL_XTAL_16KCLK_gc );
CLKSYS_Enable( OSC_XOSCEN_bm );
CLKSYS_PLL_Config( OSC_PLLSRC_XOSC_gc, 2 );
CLKSYS_Enable( OSC_PLLEN_bm );
CLKSYS_Prescalers_Config( CLK_PSADIV_1_gc, CLK_PSBCDIV_1_1_gc );
do {} while ( CLKSYS_IsReady( OSC_PLLRDY_bm ) == 0 );
CLKSYS_Main_ClockSource_Select( CLK_SCLKSEL_PLL_gc );
CLKSYS_Disable( OSC_XOSCEN_bm );
} /* init_clock() */

=== USART ===

==== USART über USB ====

So stellt man unter Verwendung der Software zu AVR1307 (-> Siehe auch) bei 32 MHz Takt den USART für die Übertragung per USB ein:

#include "usart_driver.h"

#define USART USARTD0

void init_usart( void )
{
PORTD.DIRSET = PIN3_bm;
PORTD.DIRCLR = PIN2_bm;
USART_Format_Set( &USART, USART_CHSIZE_8BIT_gc, USART_PMODE_DISABLED_gc, false );
/*
* BSEL[11:0]-Wert bei 32MHz Takt und BSCALE[3:0]==0:
* 207 : 9600
* 103 : 19200
* 51 : 38400
* 34 : 57600
* 16 : 115200
*/
USART_Baudrate_Set( &USART, 34 , 0 );
USART_Rx_Enable( &USART );
USART_Tx_Enable( &USART );
} /* init_usart() */

== Siehe auch ==

* [http://www.mikrocontroller.net/topic/227310 Ursprungsbeitrag im Forum]
* [http://www.atxmega-board.de/stick Die Seite des Sticks] mit Schaltplan und Stückliste
* [http://www.stromflo.de/dokuwiki/doku.php?id=xmega-c-tutorial XMEGA-C-Tutorial auf stromflo.de]
* [http://www.atmel.com/dyn/products/product_card.asp?part_id=4302 Produktseite des ATxmega128A3] mit jeder Menge an Dokumentation und Application Notes
* [http://www.atmel.com/dyn/resources/prod_documents/doc8072.pdf AVR1003: Using the XMEGA Clock System] (PDF) und [http://www.atmel.com/dyn/resources/prod_documents/AVR1003.zip Software] (ZIP)
* [http://www.atmel.com/dyn/resources/prod_documents/doc8049.pdf AVR1307: Using the XMEGA USART] (PDF) und [http://www.atmel.com/dyn/resources/prod_documents/AVR1307.zip Software] (ZIP)
* [http://www.microchip.com/wwwproducts/devices.aspx?dDocName=en546923 Produktseite des MCP2200] mit Dokumentation und Tools

[[Kategorie:AVR-Projekte]]

USB Koppelfeld für Festplatten

2012-07-01T08:48:33Z

Maybee: /* Hub-Stapel & Vusb-Steuerung */

''von Torsten Crull''

Es entsteht ein modulares System, welches sich zu nahezu beliebig großen Quasi- [http://de.wikipedia.org/wiki/Koppelfeld Koppelfeldern] für Festplatten kaskadieren läßt. Ein Koppelfeld-Modul hat Anschlüsse für vierzehn Festplatten; das entspricht einem 19"-Baugruppenträger. Die Stromversorgung der Festplatten läßt sich einzeln schalten. Die Platten werden - gesteuert vom Mikrocontroller - wahlweise über USB-SATA-Bridges, USB-IDE-Bridges oder über einen eSATA Port-Multiplier mit einem Host-Computer verbunden.

[[Bild:USBMuxBlockschaltbild.png|720px]]

== Einleitung ==

Das Projekt umfaßt:
* '''Koppelfeld-Module''' in mehreren Varianten, entweder mit SATA-Port-Multiplier oder mit fünf USB-HUBs. Unabhängig von der Variante werden diese Module im folgenden Text als "Koppelfeld" bezeichnet.
* Eine '''Steuerplatine''' für bis zu sechzehn Koppelfelder; die Steuerung von außen erfolgt über RS232, USB oder Ethernet. Die Koppelfelder werden über I²C adressiert; die übrigen Signale werden über eine [http://de.wikipedia.org/wiki/Serial_Peripheral_Interface SPI-Schnittstelle] übertragen.
* Eine optionale '''230V-Relaisbox''' zum ein- und ausschalten der Stromversorgung, um die Standby-Ströme zu verringern.
* '''Relaisplatinen''' um die Stromversorgung (5V und 12V) der Festplatten zu schalten.

Es können '''handelsübliche USB-Bridges''' verwendet werden; diese kosten etwa fünf Euro pro Stück:

[[Bild:UAB_SATA_Bridges_Dsc_5364.jpg|400px]]

[[Bild:HDDMuxBaumarkt.jpg|right]]
== Architektur und Mechanischer Aufbau ==

Da in einem 19"-Baugruppenträger bis zu vierzehn handelsübliche 3,5"-Festplatten untergebracht werden können, sind die Koppelfelder auf vierzehn Festplatten ausgelegt. Pro Baugruppenträger ist also eine Koppelfeld-Platine nötig.

Es sind wahlweise USB- und SATA-Koppelfelder vorgesehen, man kann also beliebig Baugruppenträger mit USB-SATA-Bridges und Baugruppenträger mit eSATA Port-Multiplyer vermischen. Die Anzahl von maximal sechzehn Baugruppenträgern ergibt sich aus der Adressierung über I²C.

Jedes Koppelfeld hat eine Ansteuerung für eine 230V-Box: Um Strom zu sparen, wenn alle Festplatten im betreffenden Baugruppenträger ausgeschaltet sind, kann jedes Netzteil auf der Primärseite ausgeschaltet werden. Es können übliche Netzteile aus alten PC-Gehäusen verwendet werden (ATX-PC oder AT-PC). In der Firmware muß sicher gestellt werden, dass pro Baugruppenträger nicht mehr Festplatten eingschaltet werden, als das Netzteil versorgen kann und dass ggf. eine minimal benötigte Belastung des Netzteils für den Netzteil-Regler nicht unterschritten wird.

Alternativ zu einem teuren Baugruppenträger kann man sich auch aus gelochten Stahlbändern vom Baumarkt einen Rahmen für die Festplatten bauen; das sieht dann aus wie aus 'nem Trix-Metallbaukasten (s. Bild).

== Hardware ==

Die Hardware besteht aus den oben genannten Modulen, die im Folgenden beschrieben werden:

=== Steuerplatine ===

[[Bild:USBMuxSteuerplatine.png]]

Zentrales Element der Steuerplatine ist ein PIC32MX764F128L-I/PT von Microchip. Er enthält bereits alle verwendeten Schnittstellen: UART (RS232), Ethernet, USB, I²C, SPI und Analogeingang.

Für die CPU-Platine sind folgende Integrationsstufen geplant:

1. Gefädelte Lochrasterplatine mit Adapterplatine für das TQFP-100-Gehäuse und vornehmlich DIL-Gehäusen.

2. Aufbau mit professionell gefertigten Platinen mit Lötstopplack und vornehmlich SMD-Gehäusen.

2. Redesign und kleinserientaugliche Lösung.

Die Gefädelte Lochrasterplatine wird während der Entwicklung Stück für Stück erweitert. In der ersten Ausbaustufe wird der Mikrocontroller über den integrierten UART und eine USB-RS232C-Brigde mit dem Host verbunden, damit die Software noch ohne USB-Stack auskommt. In der ersten Ausbaustufe soll zunächst die praktische Nutzbarkeit des Systems gewährleistet sein, um Erfahrung mit dem System zu sammeln.

In weiteren Ausbaustufen werden dann der Analogeingang, die Ethernet-Schnittstelle und die USB-Schnittstelle in Betrieb genommen.

Über den Analogeingang kann der Mikrocontroller die Spannungen an den Netzteilen der angeschlossenen Baugruppenträger bestimmen und überwachen; Details sind der Beschreibung der Koppelfelder (s.u.) zu entnehmen.

==== Stromversorgung ====

Damit die Netzteile nicht ständig Standby-Strom verbrauchen, kann der Mikrocontroller alle Netzteile primärseitig über eine 230V-Relaisbox ausschalten, auch das Netzteil, von dem die Steuerplatine versorgt wird.

Wenn das Gerät über USB vom Host gesteuert wird, verhält sich das Gerät wie ein "self-powered USB-device". Es nutzt die max. 100mA vom USB-Anschluss, um damit einen Optokoppler in der der 230V-Relaisbox für die Aktivierung des Netzteils anzusteuern und kann sich dann aus dem Netzteil mit Strom versorgen.

Wenn das Gerät über Wakeup-on-LAN eingeschaltet werden soll, wird es bei ausgeschaltetem Netzteil von einem Handy-Akku versorgt.

Die 230V-Relaisbox hat optional einen 230V-Ausgang für den Host-Computer, der primärseitig vom Netz getrennt werden kann, um die Stromkosten in den Standby-Zeiten zu senken.

==== Display-Platine ====

Optional ist eine Display-Platine mit einem Dreh-Drück-Geber und Siebensegment LED-Anzeigen vorgesehen. Sie ist auf Steuerplatine montiert und über einen zehnpolige Steckverbindung mit der Steuerplatine verbunden.

Das Bedienkonzept steht noch nicht im Detail fest, nur soviel: Über den Dreh-Drück-Geber läßt sich das System einschalten und der anzuzeigende Wert auswählen. Angezeigt werden die Nummern der aktiven Festplatten und die gemessenen Spannungen an den Netzteilen. Der Aufwand für eine umfangreiche Benutzerschnittstelle über die Display-Platine lohnt sich kaum, da in der Praxis die Steuerung über RS232, Ethernet oder USB erfolgen wird.

=== USB Koppelfeld ===

Aus der [http://www.mikrocontroller.net/topic/262844#2729270 Diskussion zu diesem Projekt] ergab sich, dass die Variante 2 mit gestapelten USB-Hubs umgesetzt wird:

[[Bild:USBMuxVarianten.png]]

Die ursprüngliche Idee aus einer [http://www.mikrocontroller.net/articles/Datei:FSUSB42_Matrix.png Matrix mit FSUSB42-ICs] wurde verworfen; die Vorteile der Varianten:

'''Variante 1: FSUSB42-Matrix'''

* geringere Latenzzeiten, da die USB-Daten einen HUB weniger passieren müssen.
* möglicher Weise bessere Kompatibilität beim Verbinden und Trennen der USB-Verbindung, da die Datenleitungen unterbrochen werden.

'''Variante 2: USB-Hub-Stapel:'''

* Keine Begrenzung auf drei gleichzeitig aktive Festplatten
* geringere Kosten
* weniger Bauteile; die FSUSB42-ICs sind sehr winzig und lassen sich nur schwer von Hand bestücken.
* geringere Störanfälligkeit, da der USB-Hub wie ein Repeater die USB-Signale auffrischt.

==== Hub-Stapel & Vusb-Steuerung ====

Das Herzstück eines USB Koppelfeldes sind die USB-Hubs und optionale USB-Power-Schalter für die 5V-Spannung "Vusb", jeweils an Pin 1 der USB-Anschlüsse. Über Vusb werden die USB-SATA-Bridges aktiviert und deaktiviert:

[[Bild:USBMuxModul.png]]

Um Kosten zu sparen, kann man die USB-Power-Schalter auch weglassen, dann werden die USB-SATA-Bridges zusammen mit den 5V der Festplatten geschaltet. Diese "Spar-Variante" ist natürlich nicht konform zur USB-Spezifikation.

Da die 5V der Festplatten auf separaten Relais-Platinen geschaltet werden, sind zwei Varianten der Verkabelung mit den Relais-Platinen vorgesehen. In der Variante 2 (s. Bild, "Spar-Variante") werden jeweils vier Adern pro Relais-Platine angeschlossen; bei der Verwendung von USB-Power-Schalten dürfen jeweils nur zwei Adern angeschlossen sein.

[[Bild:USBMuxFlachband.png]]

'''Legende:'''

1 Micromatch-Steckverbinder 
2 Zwölfadriges Flachbandkabel, in Variante 1 ("Spar-Variante") komplett 
3 Sechzehnadriges Flachbandkabel, in Variante 1 ("Spar-Variante") komplett 
4 Vierpoliger Micromatch-Steckverbinder, einer pro Relaisplatine 
5 Flachbandkabel, in Variante 2 (spezifikationskonform) fehlen jede dritte und vierte Ader. 

Von den vier Adern pro Relais-Platine werden zwei Adern zum getrennten Einschalten der Stromversorgung von zwei Festplatten verwedet; über die anderen zwei Adern werden optional die geschalteten 5V für die Versorgung der USB-Bridges zurückgeführt. Falls USB-Power-Schalter verbaut sind, müssen diese Adern abgekniffen werden.

==== Schieberegister für Steuerungsbits ====

Die Steuerungsbits werden mit dem [http://de.wikipedia.org/wiki/Serial_Peripheral_Interface SPI-Protokoll] von einem Microcontroller in die kaskadierten Schieberegister (daisy chain) geschrieben. Die Slave-Select-Signale für die [http://de.wikipedia.org/wiki/Serial_Peripheral_Interface SPI-Schnittstelle] werden von einem I²C-Expander (IC1, PCF8574) (s.u.) gesteuert.

Um das Clock-Signal bei /SS = high (inaktivem Slave-Select) zu unterdrücken, ist noch ein Oder-Gatter vor den Clock-Eingang vorgesehen. (ToDo: Im Forum ansprechen)

* Bild folgt

==== Slave-Select per I²C ====

Von einem I²C-Expander (IC1, PCF8574) und einem '''3:8 Decoder''' (IC37, 74HC138) werden pro Baugruppenträger die konkreten Slave-Select-Signale für das SPI (s.o.) erzeugt. Dadurch ist es möglich, bis zu sechzen Koppelfelder per I²C-Protokoll zu adrerssieren.

Der 74HC138 enthält kein Latch. Um unerlaubte Zustände beim Umschalten der Adresse am 3:8 Decoder zu vermeiden, muß der Mikrocontroller beim Umschalten das globale Slave-Select-Signal "/SS" auf "high" halten. (ToDo: Schaltbild aktualisieren)

[[Bild:USB-Koppelfeld-I2C.png|600px]]

Die I²C-Adresse des Baugruppenträgers wird über S1 und eine Bestückungsvariante für IC1 eingestellt.

==== Analogsignal "Probe" ====

Von allen Baugruppenträgern wird eine gemeinsame "Probe"-Leitung verwendet, um eine zu messende Spannung an den Analogeingang des Mikrocontrollers zu geben. Über Analogschalter (IC32, s. Bild) wird die zu messende Spannung mit der "Probe"-Leitung verbunden. Die Firmware muß sicher stellen, dass immer nur ein Analogschalter auf allen Baugruppen leitend ist.

==== Ansteuerung der Relais-Platinen ====

Um die Festplatten-Stromversorgung über Relais oder MOSFTEs zu steuern, führen vom Koppelfeld insgesamt 56 Flachbandadern zu den Relaisplatinen. Die Belegung der Adern ist im Kapitel "Vusb-Steuerung" (s.o.) beschrieben.

Sowohl Relais als auch die MOSFET-Transistoren werden über Open-Collector-Ausgänge eines ULN2003A angesteuert. Gegenüber einzelnen Transistoren hat ein ULN2003 keinen finanziellen Nachteil, es sind jedoch weniger Teile zu bestücken und das Platinenlayout vereinfacht sich.

[[Bild:USB-Koppelfeld-ULN2003a.png]]

==== USB-Versorgung der USB-SATA/PATA-Bridges ====

Wie oben beschrieben, gibt es eine "Spar-Variante" Nr. 1 und eine spezifikationskonforme Variante Nr. 2. Bei der "Spar-Variante" werden die USB-Power-Schalter nicht bestückt und die 5V Vusb kommen über die Pins 3,4,7,8, ... von X1 und X2 von der geschalteten 5V-Stromversorgung der Festplatten.

[[Bild:USB-Koppelfeld-HighSide.png]]

==== Steuerung der 230V-Relaisbox ====

Die Relais in der 230V-Relaisbox (s.u.) werden über die Open-Collector-Ausgänge eines ULN2003A geschaltet. Durch die Open-Collector-Ausgänge können entweder Relais erregt werden, MOSFETs geschaltet oder Optokoppler angesteuert werden.

6-Pin-DIN-Stecker dienen der Verbindung zwischen der dem Koppelfeld und der Relaisbox.

[[Bild:USB-Koppelfeld-ULN2003b.png]]

=== eSATA Koppelfeld ===

* Details folgen

=== Relaisplatine ===
[[Bild:USBMuxRelaisModul.png]]

Die Relaismodule schalten in Zweiergruppen die Stromversorgung der Festplatten und sind mit vier Stromschienen aus Kupferdraht miteinander verbunden:

[[Bild:USBMuxRelaisPlatine.png]]

'''Legende:'''

1 Relaisplatine mit Anschlussklemmen für das Netzteil, davon wird nur eine Platine pro Baugruppenträger benötigt. 
2 Anschlussklemmen (4 x 4mm²) für das Netzteil (ToDo: Alternativen klären) 
3 Anschlussklemmen (optional) für Kupferdraht (Nr. 4); der Kuperdraht kann auch flächig auf freistehendem Kupfer der Platine verlötet werden, um Kosten zu sparen. 
4 Vier "Stromschienen" aus 2,5mm² Kupferdraht (z.B. NYM-J 3x2,5 vom Baumarkt) 
5 Bohrungen zur Befestigung an der Rückseite an einem 19"-Baugruppenträger 
6 Relaisplatine mit Anschlussklemmen für das Netzteil 
7 Ritzung in der Platine, um Anschlussklemmen-Teil abbrechen zu können. 
8 4-Pin Micromatch-Verbinder (2 x Schalteingang, 2 x 5V-Ausgang) 
9 Durchkontaktierungen zum Anschluß eines Kabelschwanzes zur Stromversorgung einer Festplatte. Wahlweise können für aktuelle Platten SATA-Stecker oder für ältere Platten Molex-Stecker an den Kabelschwänzen sein. 
10 Zwei Relais (á zwei Wechser) oder vier MOSFETs 
11 Optionale Block-Kondensatoren, um Stromspitzen beim Einschalten der Festplatte abzublocken. 

Das Relaismodul gibt es in zwei Varianten: Mit elektromagnetischen Schaltern und mit Halbleiter-Schaltern (MOSFETs):

[[Bild:USBMuxRelaisModul1.png]] [[Bild:USBMuxRelaisModul2.png]]

=== 230V-Relaisbox ===
[[Bild:USBMux230VBox.png]]

Die Relaisbox kann optional über einen 6-poligen DIN-Stecker an eines der Koppelfelder angeschlossen werden, um die Netzteile für die Festplatten und für den Host-PC primärseitig vom Stromnetz zu trennen.

Die Relaisbox muß nach VDE-Richtlinien aufgebaut sein. Damit beim Betrieb nicht ständig ein Relais angezogen (erregt) sein muß, kommen bistabile 230V-Relais zum Einsatz, die über Optokoppler (Halbleiterrelais) ein- und ausgeschaltet werden können.

Am 230V-Anschluss hinter der Sicherung ist ein Gasableiter für einen zusätzlichen Blitzschutz vorgesehen.

Bei Verwendung moderner Netzteile mit geringen Standby-Leistungen kann man natürlich auf die 230V-Relaisbox verzichten.

* Details folgen

=== Zustandsautomaten ===
== Software / Firmware ==

Die Firmware wird komplet im internen EEPROM des PIC32MX764F128L-I/PT gespeichert und per In-Curcit-Debugger in den Mikrocontroller geladen.

Die detaillierte Beschreibung der Firmware folgt, hier nur eine naheliegende Reihenfolge der Softwarestände der Integrationsstufen (s. o.):

'''1.1.''' Unidirektionale Steuerung über UART (RS232) zur Ansteuerung der Relaisplatinen in der "Spar-Variante". 
'''1.2.''' Rücksendung von Status- und Messwerten über RS232 
'''1.3.''' Ansteuerung der 230V-Box, Stromversorgung über USB bei ausgeschaltetem Netzteil 
'''1.4.''' Implementierung der spezifikationskonformen Variante Nr. 2. der USB-Koppelfelder 
'''1.5.''' Ansteuerung der Display-Platine zur Ausgabe der gemessenen Spannungspegel 
'''1.6.''' Implementierung des Batteriebetriebes 
'''1.7.''' Ansteuerung von eSATA-Koppelfeldern 
'''1.8.''' Implementierung des Ethernet-Anschlusses zur Steuerung über HTTP/Get-Kommandos 
'''2.1.''' Implementierung von Wakup-on-LAN 
'''2.2.''' Implementierung der USB-Schnittstelle des Mikrocontrollers als USB-HID als Alternative zur Steuerung über die RS232-USB-Bridge 
'''2.3.''' Unterstützung des "[http://www.mikrocontroller.net/topic/262844#2730914 SetPortFeature(PORT_POWER) request]" um die Festplatten ohne Kommunikation mit dem Mikrocontroller schalten zu können.

=== Zustandsautomaten ===
Bevor die Implementierung der Software beginnt, sollten die Anforderungen klar sein. Viele Anforderungen lassen sich wie in den folgenden Kapiteln in Zustandsautomaten beschreiben:

==== Betriebszustände ====
(ToDo: Kapitel vervollständigen)

[[Bild:HDDMuxBZStateChart.png]]
===== Zustand '''off''' =====
Dieser Zustand wird
* bei leerer oder nicht verbauter Batterie erreicht, wenn die aktive Stromversorgung ausfällt,
* wenn bei leerer Batterie keine aktive Stromversorgung angeschlossen ist oder
* wenn der Benutzer z.B. vor einem Urlaub über eine der Benutzerschnittstellem das System komplett ausschaltet, damit der Akku nicht entladen wird.

Ereignis "5V plugged 1":
* Wenn eine Mini-USB-Buchse verbaut ist und dort ein externes USB-Steckernetzteil angeschlossen ist, wechselt das System in den Zustand "5V powered".

Ereignis "POE plugged 1":
* Wenn die Ethernet-Schnittstelle verbaut ist und dort eine Versorgungsspannung anliegt, wechselt das System in den Zustand "POE powered".

Ereignis "USB plugged 1":
* Wenn der Stecker zum Host-PC angeschlossen ist und dort Vusb anliegt, wechselt das System in den Zustand "USB-powered-100".

Ereignis "on":
* Falls eine Batterie verbaut ist und der Dreh-Drück-Geber gedrückt wird, wechselt das System in den Zustand "USB-powered-100".

Ereignis "230V-Set":
* Wenn eine 230V-Relaibox verbaut ist und an der Box der On-Taster gedrückt wird oder
* wenn der 230V-Stecker gesteckt wird bzw. nach einem Stromausfall bei nicht verbautem oder leerem Akku
wechselt das System in den Zustand "Battery" und prüft den Ladezustand der Batterie; wenn der obere Wert der Batteriespannungshysterese unterschritten ist, wird im Zustand "Battery" sofort versucht, den Akku zu laden.

===== Zustand '''5V powered''' =====
Falls eine Mini-USB-Buchse verbaut und dort ein externes USB-Ladegerät angeschlossen ist, kann das Sytem in diesen Zustand wechseln. Wenn eine Batterie verbaut und nicht voll geladen ist, wird sie automatisch mit bis zu maximal zulässigem Ladestrom geladen; dabei wird die Versorgungsspannung über einen Analogeingang beobachtet, um Überlastungen des Netzteils zu verhindern. Wenn der Webserver aktiv ist, ist er über Ethernet erreichbar. Am USB-Anschluss verhält sich das System als "self powered USB Device".

Ereignis "blackout 1":
* …
Ereignis "POE plugged 2":
* …
Ereignis "USB plugged 2":
* …
Ereignis "battery full 1":
* …
Ereignis "HDD on 1":
* …

===== Zustand '''POE powered''' =====
Falls die Ethernet-Schnittstelle verbaut ist und dort eine Versorgungsspannung anliegt, kann das Sytem in diesen Zustand wechseln und verhält sich wie im Zustand "5V powered". Der Akku wird ggf. mit maximal 10 Watt über die 48V geladen; dabei wird die 48V über einen Analogeingang beobachtet, um Überlastungen der POE-Versorgung zu verhindern.

Ereignis "blackout 2":
* …
Ereignis "blackout 5":
* …
Ereignis "HDD on 2":
* …

===== Zustand '''USB-powered-100''' =====
Falls das System über USB an ein einem Host-PC angeschlossen ist und und dort Vusb größer als 4,5V ist, kann das Sytem in diesen Zustand wechseln und wartet,
* bis es in einen der Zustände "USB-powered-500", "5V powered" oder "POE powered" wechseln kann oder
* bis es in den Zustand "Power on" wechseln soll, um eine Festplatte einzuschalten, oder
* bis es in den Zustand "Power on" wechseln muss, um den Akku zu laden.
(ToDo: Wert von 4,5V prüfen)

Ereignis "blackout 3":
* …
Ereignis "5V plugged 2":
* …
Ereignis "POE plugged 3":
* …
Ereignis "500mA available":
* …
Ereignis "USB unplugged":
* …
Ereignis "HDD on 3":
* …

===== Zustand '''USB-powered-500''' =====
Falls das System über USB an ein einem Host-PC angeschlossen ist und und dort 500mA zur Verfügung stehen, kann das Sytem in diesen Zustand wechseln und verhält sich wie im Zustand "5V powered", der Akku wird ggf. mit maximal 400mA über Vusb geladen.

Ereignis "overcurrent":
* …
Ereignis "battery full 2":
* …
Ereignis "HDD on 4":
* …

===== Zustand '''Battery'''=====
Ereignis "bat low 1":
* …
Ereignis "off":
* …
Ereignis "bat low 2":
* …
Ereignis "5V plugged 3":
* …
Ereignis "POE plugged 4":
* …
Ereignis "USB plugged 2":
* …
Ereignis "bat low 3":
* …
Ereignis "HDD on 5":
* …

===== Zustand '''Power on''' =====
Ereignis "blackout 4":
* …
Ereignis "all HDD off 1":
* …
Ereignis "all HDD off 2":
* …
Ereignis "all HDD off 3":
* …
Ereignis "all HDD off 4":
* …

== Downloads ==

* Downloads (*.SCH, *.BRD, *.C) folgen

== Siehe auch ==

* Diskussion zu diesem Projekt: http://www.mikrocontroller.net/topic/262844

[[Kategorie:PIC-Projekte]] [[Kategorie:Projekte]]

USB Koppelfeld für Festplatten

2012-07-01T08:47:24Z

Maybee: /* Zustandsautomaten */

''von Torsten Crull''

Es entsteht ein modulares System, welches sich zu nahezu beliebig großen Quasi- [http://de.wikipedia.org/wiki/Koppelfeld Koppelfeldern] für Festplatten kaskadieren läßt. Ein Koppelfeld-Modul hat Anschlüsse für vierzehn Festplatten; das entspricht einem 19"-Baugruppenträger. Die Stromversorgung der Festplatten läßt sich einzeln schalten. Die Platten werden - gesteuert vom Mikrocontroller - wahlweise über USB-SATA-Bridges, USB-IDE-Bridges oder über einen eSATA Port-Multiplier mit einem Host-Computer verbunden.

[[Bild:USBMuxBlockschaltbild.png|720px]]

== Einleitung ==

Das Projekt umfaßt:
* '''Koppelfeld-Module''' in mehreren Varianten, entweder mit SATA-Port-Multiplier oder mit fünf USB-HUBs. Unabhängig von der Variante werden diese Module im folgenden Text als "Koppelfeld" bezeichnet.
* Eine '''Steuerplatine''' für bis zu sechzehn Koppelfelder; die Steuerung von außen erfolgt über RS232, USB oder Ethernet. Die Koppelfelder werden über I²C adressiert; die übrigen Signale werden über eine [http://de.wikipedia.org/wiki/Serial_Peripheral_Interface SPI-Schnittstelle] übertragen.
* Eine optionale '''230V-Relaisbox''' zum ein- und ausschalten der Stromversorgung, um die Standby-Ströme zu verringern.
* '''Relaisplatinen''' um die Stromversorgung (5V und 12V) der Festplatten zu schalten.

Es können '''handelsübliche USB-Bridges''' verwendet werden; diese kosten etwa fünf Euro pro Stück:

[[Bild:UAB_SATA_Bridges_Dsc_5364.jpg|400px]]

[[Bild:HDDMuxBaumarkt.jpg|right]]
== Architektur und Mechanischer Aufbau ==

Da in einem 19"-Baugruppenträger bis zu vierzehn handelsübliche 3,5"-Festplatten untergebracht werden können, sind die Koppelfelder auf vierzehn Festplatten ausgelegt. Pro Baugruppenträger ist also eine Koppelfeld-Platine nötig.

Es sind wahlweise USB- und SATA-Koppelfelder vorgesehen, man kann also beliebig Baugruppenträger mit USB-SATA-Bridges und Baugruppenträger mit eSATA Port-Multiplyer vermischen. Die Anzahl von maximal sechzehn Baugruppenträgern ergibt sich aus der Adressierung über I²C.

Jedes Koppelfeld hat eine Ansteuerung für eine 230V-Box: Um Strom zu sparen, wenn alle Festplatten im betreffenden Baugruppenträger ausgeschaltet sind, kann jedes Netzteil auf der Primärseite ausgeschaltet werden. Es können übliche Netzteile aus alten PC-Gehäusen verwendet werden (ATX-PC oder AT-PC). In der Firmware muß sicher gestellt werden, dass pro Baugruppenträger nicht mehr Festplatten eingschaltet werden, als das Netzteil versorgen kann und dass ggf. eine minimal benötigte Belastung des Netzteils für den Netzteil-Regler nicht unterschritten wird.

Alternativ zu einem teuren Baugruppenträger kann man sich auch aus gelochten Stahlbändern vom Baumarkt einen Rahmen für die Festplatten bauen; das sieht dann aus wie aus 'nem Trix-Metallbaukasten (s. Bild).

== Hardware ==

Die Hardware besteht aus den oben genannten Modulen, die im Folgenden beschrieben werden:

=== Steuerplatine ===

[[Bild:USBMuxSteuerplatine.png]]

Zentrales Element der Steuerplatine ist ein PIC32MX764F128L-I/PT von Microchip. Er enthält bereits alle verwendeten Schnittstellen: UART (RS232), Ethernet, USB, I²C, SPI und Analogeingang.

Für die CPU-Platine sind folgende Integrationsstufen geplant:

1. Gefädelte Lochrasterplatine mit Adapterplatine für das TQFP-100-Gehäuse und vornehmlich DIL-Gehäusen.

2. Aufbau mit professionell gefertigten Platinen mit Lötstopplack und vornehmlich SMD-Gehäusen.

2. Redesign und kleinserientaugliche Lösung.

Die Gefädelte Lochrasterplatine wird während der Entwicklung Stück für Stück erweitert. In der ersten Ausbaustufe wird der Mikrocontroller über den integrierten UART und eine USB-RS232C-Brigde mit dem Host verbunden, damit die Software noch ohne USB-Stack auskommt. In der ersten Ausbaustufe soll zunächst die praktische Nutzbarkeit des Systems gewährleistet sein, um Erfahrung mit dem System zu sammeln.

In weiteren Ausbaustufen werden dann der Analogeingang, die Ethernet-Schnittstelle und die USB-Schnittstelle in Betrieb genommen.

Über den Analogeingang kann der Mikrocontroller die Spannungen an den Netzteilen der angeschlossenen Baugruppenträger bestimmen und überwachen; Details sind der Beschreibung der Koppelfelder (s.u.) zu entnehmen.

==== Stromversorgung ====

Damit die Netzteile nicht ständig Standby-Strom verbrauchen, kann der Mikrocontroller alle Netzteile primärseitig über eine 230V-Relaisbox ausschalten, auch das Netzteil, von dem die Steuerplatine versorgt wird.

Wenn das Gerät über USB vom Host gesteuert wird, verhält sich das Gerät wie ein "self-powered USB-device". Es nutzt die max. 100mA vom USB-Anschluss, um damit einen Optokoppler in der der 230V-Relaisbox für die Aktivierung des Netzteils anzusteuern und kann sich dann aus dem Netzteil mit Strom versorgen.

Wenn das Gerät über Wakeup-on-LAN eingeschaltet werden soll, wird es bei ausgeschaltetem Netzteil von einem Handy-Akku versorgt.

Die 230V-Relaisbox hat optional einen 230V-Ausgang für den Host-Computer, der primärseitig vom Netz getrennt werden kann, um die Stromkosten in den Standby-Zeiten zu senken.

==== Display-Platine ====

Optional ist eine Display-Platine mit einem Dreh-Drück-Geber und Siebensegment LED-Anzeigen vorgesehen. Sie ist auf Steuerplatine montiert und über einen zehnpolige Steckverbindung mit der Steuerplatine verbunden.

Das Bedienkonzept steht noch nicht im Detail fest, nur soviel: Über den Dreh-Drück-Geber läßt sich das System einschalten und der anzuzeigende Wert auswählen. Angezeigt werden die Nummern der aktiven Festplatten und die gemessenen Spannungen an den Netzteilen. Der Aufwand für eine umfangreiche Benutzerschnittstelle über die Display-Platine lohnt sich kaum, da in der Praxis die Steuerung über RS232, Ethernet oder USB erfolgen wird.

=== USB Koppelfeld ===

Aus der [http://www.mikrocontroller.net/topic/262844#2729270 Diskussion zu diesem Projekt] ergab sich, dass die Variante 2 mit gestapelten USB-Hubs umgesetzt wird:

[[Bild:USBMuxVarianten.png]]

Die ursprüngliche Idee aus einer [http://www.mikrocontroller.net/articles/Datei:FSUSB42_Matrix.png Matrix mit FSUSB42-ICs] wurde verworfen; die Vorteile der Varianten:

'''Variante 1: FSUSB42-Matrix'''

* geringere Latenzzeiten, da die USB-Daten einen HUB weniger passieren müssen.
* möglicher Weise bessere Kompatibilität beim Verbinden und Trennen der USB-Verbindung, da die Datenleitungen unterbrochen werden.

'''Variante 2: USB-Hub-Stapel:'''

* Keine Begrenzung auf drei gleichzeitig aktive Festplatten
* geringere Kosten
* weniger Bauteile; die FSUSB42-ICs sind sehr winzig und lassen sich nur schwer von Hand bestücken.
* geringere Störanfälligkeit, da der USB-Hub wie ein Repeater die USB-Signale auffrischt.

==== Hub-Stapel & Vusb-Steuerung ====

Das Herzstück eines USB Koppelfeldes sind die USB-Hubs und optionale USB-Power-Schalter für die 5V-Spannung "Vusb", jeweils an Pin 1 der USB-Anschlüsse. Über Vusb werden die USB-SATA-Bridges aktiviert und deaktiviert:

[[Bild:USBMuxModul.png]]

Um Kosten zu sparen, kann man die USB-Power-Schalter auch weglassen, dann werden die USB-SATA-Bridges zusammen mit den 5V der Festplatten geschaltet. Diese "Spar-Variante" ist natürlich nicht konform zur USB-Spezifikation.

Da die 5V der Festplatten auf separaten Relais-Platinen geschaltet werden, sind zwei Varianten der Verkabelung mit den Relais-Platinen vorgesehen. In der Variante 2 (s. Bild, "Spar-Variante") werden jeweils vier Adern pro Relais-Platine angeschlossen; bei der Verwendung von USB-Power-Schalten dürfen jeweils nur zwei Adern angeschlossen sein.

[[Bild:USBMuxFlachband.png]]

'''Legende:'''

1 Mitromatch-Steckverbinder 
2 Zwölfadriges Flachbandkabel, in Variante 1 ("Spar-Variante") komplett 
3 Sechzehnadriges Flachbandkabel, in Variante 1 ("Spar-Variante") komplett 
4 Vierpoliger Mitromatch-Steckverbinder, einer pro Relaisplatine 
5 Flachbandkabel, in Variante 2 (spezifikationskonform) fehlen jede dritte und vierte Ader. 

Von den vier Adern pro Relais-Platine werden zwei Adern zum getrennten Einschalten der Stromversorgung von zwei Festplatten verwedet; über die anderen zwei Adern werden optional die geschalteten 5V für die Versorgung der USB-Bridges zurückgeführt. Falls USB-Power-Schalter verbaut sind, müssen diese Adern abgekniffen werden.

==== Schieberegister für Steuerungsbits ====

Die Steuerungsbits werden mit dem [http://de.wikipedia.org/wiki/Serial_Peripheral_Interface SPI-Protokoll] von einem Microcontroller in die kaskadierten Schieberegister (daisy chain) geschrieben. Die Slave-Select-Signale für die [http://de.wikipedia.org/wiki/Serial_Peripheral_Interface SPI-Schnittstelle] werden von einem I²C-Expander (IC1, PCF8574) (s.u.) gesteuert.

Um das Clock-Signal bei /SS = high (inaktivem Slave-Select) zu unterdrücken, ist noch ein Oder-Gatter vor den Clock-Eingang vorgesehen. (ToDo: Im Forum ansprechen)

* Bild folgt

==== Slave-Select per I²C ====

Von einem I²C-Expander (IC1, PCF8574) und einem '''3:8 Decoder''' (IC37, 74HC138) werden pro Baugruppenträger die konkreten Slave-Select-Signale für das SPI (s.o.) erzeugt. Dadurch ist es möglich, bis zu sechzen Koppelfelder per I²C-Protokoll zu adrerssieren.

Der 74HC138 enthält kein Latch. Um unerlaubte Zustände beim Umschalten der Adresse am 3:8 Decoder zu vermeiden, muß der Mikrocontroller beim Umschalten das globale Slave-Select-Signal "/SS" auf "high" halten. (ToDo: Schaltbild aktualisieren)

[[Bild:USB-Koppelfeld-I2C.png|600px]]

Die I²C-Adresse des Baugruppenträgers wird über S1 und eine Bestückungsvariante für IC1 eingestellt.

==== Analogsignal "Probe" ====

Von allen Baugruppenträgern wird eine gemeinsame "Probe"-Leitung verwendet, um eine zu messende Spannung an den Analogeingang des Mikrocontrollers zu geben. Über Analogschalter (IC32, s. Bild) wird die zu messende Spannung mit der "Probe"-Leitung verbunden. Die Firmware muß sicher stellen, dass immer nur ein Analogschalter auf allen Baugruppen leitend ist.

==== Ansteuerung der Relais-Platinen ====

Um die Festplatten-Stromversorgung über Relais oder MOSFTEs zu steuern, führen vom Koppelfeld insgesamt 56 Flachbandadern zu den Relaisplatinen. Die Belegung der Adern ist im Kapitel "Vusb-Steuerung" (s.o.) beschrieben.

Sowohl Relais als auch die MOSFET-Transistoren werden über Open-Collector-Ausgänge eines ULN2003A angesteuert. Gegenüber einzelnen Transistoren hat ein ULN2003 keinen finanziellen Nachteil, es sind jedoch weniger Teile zu bestücken und das Platinenlayout vereinfacht sich.

[[Bild:USB-Koppelfeld-ULN2003a.png]]

==== USB-Versorgung der USB-SATA/PATA-Bridges ====

Wie oben beschrieben, gibt es eine "Spar-Variante" Nr. 1 und eine spezifikationskonforme Variante Nr. 2. Bei der "Spar-Variante" werden die USB-Power-Schalter nicht bestückt und die 5V Vusb kommen über die Pins 3,4,7,8, ... von X1 und X2 von der geschalteten 5V-Stromversorgung der Festplatten.

[[Bild:USB-Koppelfeld-HighSide.png]]

==== Steuerung der 230V-Relaisbox ====

Die Relais in der 230V-Relaisbox (s.u.) werden über die Open-Collector-Ausgänge eines ULN2003A geschaltet. Durch die Open-Collector-Ausgänge können entweder Relais erregt werden, MOSFETs geschaltet oder Optokoppler angesteuert werden.

6-Pin-DIN-Stecker dienen der Verbindung zwischen der dem Koppelfeld und der Relaisbox.

[[Bild:USB-Koppelfeld-ULN2003b.png]]

=== eSATA Koppelfeld ===

* Details folgen

=== Relaisplatine ===
[[Bild:USBMuxRelaisModul.png]]

Die Relaismodule schalten in Zweiergruppen die Stromversorgung der Festplatten und sind mit vier Stromschienen aus Kupferdraht miteinander verbunden:

[[Bild:USBMuxRelaisPlatine.png]]

'''Legende:'''

1 Relaisplatine mit Anschlussklemmen für das Netzteil, davon wird nur eine Platine pro Baugruppenträger benötigt. 
2 Anschlussklemmen (4 x 4mm²) für das Netzteil (ToDo: Alternativen klären) 
3 Anschlussklemmen (optional) für Kupferdraht (Nr. 4); der Kuperdraht kann auch flächig auf freistehendem Kupfer der Platine verlötet werden, um Kosten zu sparen. 
4 Vier "Stromschienen" aus 2,5mm² Kupferdraht (z.B. NYM-J 3x2,5 vom Baumarkt) 
5 Bohrungen zur Befestigung an der Rückseite an einem 19"-Baugruppenträger 
6 Relaisplatine mit Anschlussklemmen für das Netzteil 
7 Ritzung in der Platine, um Anschlussklemmen-Teil abbrechen zu können. 
8 4-Pin Micromatch-Verbinder (2 x Schalteingang, 2 x 5V-Ausgang) 
9 Durchkontaktierungen zum Anschluß eines Kabelschwanzes zur Stromversorgung einer Festplatte. Wahlweise können für aktuelle Platten SATA-Stecker oder für ältere Platten Molex-Stecker an den Kabelschwänzen sein. 
10 Zwei Relais (á zwei Wechser) oder vier MOSFETs 
11 Optionale Block-Kondensatoren, um Stromspitzen beim Einschalten der Festplatte abzublocken. 

Das Relaismodul gibt es in zwei Varianten: Mit elektromagnetischen Schaltern und mit Halbleiter-Schaltern (MOSFETs):

[[Bild:USBMuxRelaisModul1.png]] [[Bild:USBMuxRelaisModul2.png]]

=== 230V-Relaisbox ===
[[Bild:USBMux230VBox.png]]

Die Relaisbox kann optional über einen 6-poligen DIN-Stecker an eines der Koppelfelder angeschlossen werden, um die Netzteile für die Festplatten und für den Host-PC primärseitig vom Stromnetz zu trennen.

Die Relaisbox muß nach VDE-Richtlinien aufgebaut sein. Damit beim Betrieb nicht ständig ein Relais angezogen (erregt) sein muß, kommen bistabile 230V-Relais zum Einsatz, die über Optokoppler (Halbleiterrelais) ein- und ausgeschaltet werden können.

Am 230V-Anschluss hinter der Sicherung ist ein Gasableiter für einen zusätzlichen Blitzschutz vorgesehen.

Bei Verwendung moderner Netzteile mit geringen Standby-Leistungen kann man natürlich auf die 230V-Relaisbox verzichten.

* Details folgen

=== Zustandsautomaten ===
== Software / Firmware ==

Die Firmware wird komplet im internen EEPROM des PIC32MX764F128L-I/PT gespeichert und per In-Curcit-Debugger in den Mikrocontroller geladen.

Die detaillierte Beschreibung der Firmware folgt, hier nur eine naheliegende Reihenfolge der Softwarestände der Integrationsstufen (s. o.):

'''1.1.''' Unidirektionale Steuerung über UART (RS232) zur Ansteuerung der Relaisplatinen in der "Spar-Variante". 
'''1.2.''' Rücksendung von Status- und Messwerten über RS232 
'''1.3.''' Ansteuerung der 230V-Box, Stromversorgung über USB bei ausgeschaltetem Netzteil 
'''1.4.''' Implementierung der spezifikationskonformen Variante Nr. 2. der USB-Koppelfelder 
'''1.5.''' Ansteuerung der Display-Platine zur Ausgabe der gemessenen Spannungspegel 
'''1.6.''' Implementierung des Batteriebetriebes 
'''1.7.''' Ansteuerung von eSATA-Koppelfeldern 
'''1.8.''' Implementierung des Ethernet-Anschlusses zur Steuerung über HTTP/Get-Kommandos 
'''2.1.''' Implementierung von Wakup-on-LAN 
'''2.2.''' Implementierung der USB-Schnittstelle des Mikrocontrollers als USB-HID als Alternative zur Steuerung über die RS232-USB-Bridge 
'''2.3.''' Unterstützung des "[http://www.mikrocontroller.net/topic/262844#2730914 SetPortFeature(PORT_POWER) request]" um die Festplatten ohne Kommunikation mit dem Mikrocontroller schalten zu können.

=== Zustandsautomaten ===
Bevor die Implementierung der Software beginnt, sollten die Anforderungen klar sein. Viele Anforderungen lassen sich wie in den folgenden Kapiteln in Zustandsautomaten beschreiben:

==== Betriebszustände ====
(ToDo: Kapitel vervollständigen)

[[Bild:HDDMuxBZStateChart.png]]
===== Zustand '''off''' =====
Dieser Zustand wird
* bei leerer oder nicht verbauter Batterie erreicht, wenn die aktive Stromversorgung ausfällt,
* wenn bei leerer Batterie keine aktive Stromversorgung angeschlossen ist oder
* wenn der Benutzer z.B. vor einem Urlaub über eine der Benutzerschnittstellem das System komplett ausschaltet, damit der Akku nicht entladen wird.

Ereignis "5V plugged 1":
* Wenn eine Mini-USB-Buchse verbaut ist und dort ein externes USB-Steckernetzteil angeschlossen ist, wechselt das System in den Zustand "5V powered".

Ereignis "POE plugged 1":
* Wenn die Ethernet-Schnittstelle verbaut ist und dort eine Versorgungsspannung anliegt, wechselt das System in den Zustand "POE powered".

Ereignis "USB plugged 1":
* Wenn der Stecker zum Host-PC angeschlossen ist und dort Vusb anliegt, wechselt das System in den Zustand "USB-powered-100".

Ereignis "on":
* Falls eine Batterie verbaut ist und der Dreh-Drück-Geber gedrückt wird, wechselt das System in den Zustand "USB-powered-100".

Ereignis "230V-Set":
* Wenn eine 230V-Relaibox verbaut ist und an der Box der On-Taster gedrückt wird oder
* wenn der 230V-Stecker gesteckt wird bzw. nach einem Stromausfall bei nicht verbautem oder leerem Akku
wechselt das System in den Zustand "Battery" und prüft den Ladezustand der Batterie; wenn der obere Wert der Batteriespannungshysterese unterschritten ist, wird im Zustand "Battery" sofort versucht, den Akku zu laden.

===== Zustand '''5V powered''' =====
Falls eine Mini-USB-Buchse verbaut und dort ein externes USB-Ladegerät angeschlossen ist, kann das Sytem in diesen Zustand wechseln. Wenn eine Batterie verbaut und nicht voll geladen ist, wird sie automatisch mit bis zu maximal zulässigem Ladestrom geladen; dabei wird die Versorgungsspannung über einen Analogeingang beobachtet, um Überlastungen des Netzteils zu verhindern. Wenn der Webserver aktiv ist, ist er über Ethernet erreichbar. Am USB-Anschluss verhält sich das System als "self powered USB Device".

Ereignis "blackout 1":
* …
Ereignis "POE plugged 2":
* …
Ereignis "USB plugged 2":
* …
Ereignis "battery full 1":
* …
Ereignis "HDD on 1":
* …

===== Zustand '''POE powered''' =====
Falls die Ethernet-Schnittstelle verbaut ist und dort eine Versorgungsspannung anliegt, kann das Sytem in diesen Zustand wechseln und verhält sich wie im Zustand "5V powered". Der Akku wird ggf. mit maximal 10 Watt über die 48V geladen; dabei wird die 48V über einen Analogeingang beobachtet, um Überlastungen der POE-Versorgung zu verhindern.

Ereignis "blackout 2":
* …
Ereignis "blackout 5":
* …
Ereignis "HDD on 2":
* …

===== Zustand '''USB-powered-100''' =====
Falls das System über USB an ein einem Host-PC angeschlossen ist und und dort Vusb größer als 4,5V ist, kann das Sytem in diesen Zustand wechseln und wartet,
* bis es in einen der Zustände "USB-powered-500", "5V powered" oder "POE powered" wechseln kann oder
* bis es in den Zustand "Power on" wechseln soll, um eine Festplatte einzuschalten, oder
* bis es in den Zustand "Power on" wechseln muss, um den Akku zu laden.
(ToDo: Wert von 4,5V prüfen)

Ereignis "blackout 3":
* …
Ereignis "5V plugged 2":
* …
Ereignis "POE plugged 3":
* …
Ereignis "500mA available":
* …
Ereignis "USB unplugged":
* …
Ereignis "HDD on 3":
* …

===== Zustand '''USB-powered-500''' =====
Falls das System über USB an ein einem Host-PC angeschlossen ist und und dort 500mA zur Verfügung stehen, kann das Sytem in diesen Zustand wechseln und verhält sich wie im Zustand "5V powered", der Akku wird ggf. mit maximal 400mA über Vusb geladen.

Ereignis "overcurrent":
* …
Ereignis "battery full 2":
* …
Ereignis "HDD on 4":
* …

===== Zustand '''Battery'''=====
Ereignis "bat low 1":
* …
Ereignis "off":
* …
Ereignis "bat low 2":
* …
Ereignis "5V plugged 3":
* …
Ereignis "POE plugged 4":
* …
Ereignis "USB plugged 2":
* …
Ereignis "bat low 3":
* …
Ereignis "HDD on 5":
* …

===== Zustand '''Power on''' =====
Ereignis "blackout 4":
* …
Ereignis "all HDD off 1":
* …
Ereignis "all HDD off 2":
* …
Ereignis "all HDD off 3":
* …
Ereignis "all HDD off 4":
* …

== Downloads ==

* Downloads (*.SCH, *.BRD, *.C) folgen

== Siehe auch ==

* Diskussion zu diesem Projekt: http://www.mikrocontroller.net/topic/262844

[[Kategorie:PIC-Projekte]] [[Kategorie:Projekte]]