Mikrocontroller.net - Benutzerbeiträge [de]

Labornetzgeräte

2016-03-18T08:02:03Z

8023:

Ein Labornetzgerät wird dazu verwendet, Schaltungen oder einzelne Bauteile mit einer definierten Spannung oder einem definierten Strom zu versorgen.

== Funktionen ==

Labornetzgeräte sind im Gegensatz zu einfachen Festspannungs-Netzteilen sehr flexibel einsetzbar und haben üblicherweise mindestens folgende Einstellmöglichkeiten und Funktionen:

=== Einfache Labornetzteile ===

Einfache Labornetzgeräte haben eine einstellbare Ausgangsspannung, die normalerweise von 0 bis zu einem bestimmten Maximalwert eingestellt werden kann. Zusätzlich bieten diese Geräte eine einstellbare Strombegrenzung, die auch von 0 aus bis zum Nennstrom des Geräts eingestellt werden kann.

Labornetzgeräte haben außerdem noch eine Anzeige für Ausgangsspannung und Strom. Dafür sind entweder analoge oder digitale Instrumente eingebaut. Bei digitalen Anzeigen werden üblicherweise 3 Stellen angezeigt, die Genauigkeit der Anzeige liegt üblicherweise im Bereich 1%.

Der Ausgang sollte kurzschlussfest sein, was allerdings nicht bei allen Labornetzgeräten der Fall ist. Manche Geräte sind nur kurzzeitig kurzschlussfest (für einige Sekunden), normalerweise sind Labornetzgeräte dauerhaft kurzschlussfest.

=== Labornetzteile mit erweiterten Funktionen ===

Die Labornetzgeräte der gehobenen Preisklasse haben zusätzlich zu den Grundfunktionen noch weitere Funktionen, wie z.B.:

* Abschaltbarer Ausgang
* Getrennte Anzeige von Soll- und Ist-Werten
* Höhere Messgenauigkeit der Istwerte als bei einfachen Geräten
* Einstellbare Grenzwerte für Strom, Spannung, Leistung
* Alarm/Abschaltung bei Überschreitung von einstellbaren Schwellwerten
* Programmierbare Spannungs-/Stromverläufe
* Master-Slave-Funktion für Reihen-/Parallelschaltung von mehreren Geräten
* Analoge Schnittstelle für Soll- und Istwerte
* PC-Schnittstelle

== Wichtige Eigenschaften ==

=== Lineare Netzgeräte vs. Schaltnetzgeräte ===

Es gibt bei Labornetzgeräten sowohl linear geregelte als auch Schaltnetzteile.

Lineare Netzgeräte haben den Vorteil, dass die Regelung üblicherweise schneller und genauer ist. Die Ausgangskapazität ist bei linearen Netzgeräten relativ klein, dadurch kann die Strombegrenzung sehr schnell ansprechen.

Schaltnetzgeräte haben dagegen einen besseren Wirkungsgrad, erzeugen also weniger Abwärme und sind kleiner und leichter als lineare Netzgeräte gleicher Leistung. Deshalb sind vor allem Labornetzgeräte mit hoher Leistung bevorzugt als Schaltnetzteil aufgebaut.

Wenn bei Schaltnetzgeräten eine sehr kleine Ausgangs-Spannung eingestellt wird, wird diese oft nicht sauber ausgeregelt. Meistens brauchen solche Geräte eine bestimmte Mindestspannung am Ausgang.

Weiterhin besteht bei Schaltnetzteilen die Gefahr, dass am Ausgang Störungen sichtbar sind, die durch die interne PWM erzeugt werden.

Weiterhin gibt es auch Geräte, bei denen ein Schaltnetzteil und eine lineare Regelung kombiniert sind. Dadurch werden die Vorteile von beiden Verfahren kombiniert, es ergeben sich dadurch aber auch einige Probleme:

* Bei schnellen Laständerungen kann es passieren, dass das Schaltnetzteil nicht schnell genug nachregelt. Dadurch ändert sich das Regelverhalten und die Ausgangsspannung bzw. Strom sind dann nicht mehr so stabil wie bei einem richtigen linear geregelten Netzgerät.

* Bei schnellen periodischen Laständerungen kann es zusätzlich passieren, dass die Verlustleistung im Linearregler sehr viel höher wird als im Betrieb mit konstanter Ausgangsleistung. Da die lineare Endstufe meistens nicht dafür dimensioniert ist, kann es hier thermische Probleme geben.

=== Verlustleistung und Kühlung ===

Das ist vor allem bei linear geregelten Geräten ein sehr wichtiges Kapitel, da eine gute Kühlung relativ viel Geld kostet und die Gerätehersteller hier gerne sparen. Folgende Punkte sollten hier beachtet werden:

==== Passive Kühlung oder Kühlung mit Lüfter ====
Geräte mit passiver Kühlung erzeugen keine Geräusche, was ein großer Vorteil ist. Passive Kühlung ist aber nur bei Geräten mit relativ geringer Leistung üblich. Bei Lüfter-gekühlen Geräten sollte darauf geachtet werden, dass der Lüfter relativ ruhig läuft.

==== Außenliegender Kühlkörper ====
Bei passiv gekühlten Geräten kann der Kühler ziemlich warm werden. Wenn der Kühler außen am Gehäuse montiert ist, besteht die Gefahr, dass man ihn versehentlich berührt und sich verbrennt oder dass wärmeempfindliche Gegenstände (z.B. kunststoff-isolierte Leitungen) bei Berührung beschädigt werden. Deshalb sollte man Geräte bevorzugen, bei denen der Kühler innerhalb des Gehäuses montiert ist.

==== Lüftungsschlitze ====
Bei Geräten, die Lüftungsschlitze auf der Oberseite haben, besteht die Gefahr, dass Gegenstände reinfallen können, wodurch das Gerät beschädigt werden kann. Weiterhin kann es passieren, dass der Luftstrom durch die Schlitze behindert wird, wenn man etwas auf dem Gerät ablegt oder mehrere Geräte aufeinander stapelt.
Je nach dem, wo das Gerät aufgestellt werden soll, können deshalb seitliche Lüftungsschlitze vorteilhaft sein. Allerdings sind seitliche Lüftungsöffnungen meistens mit einem aktiven Lüfter kombiniert.

==== Dimensionierung der Kühlkörper und Leistungstransistoren ====
Bei vielen billigen Netzgeräten ist die Kühlung zu knapp dimensioniert. Das kann man relativ einfach testen, indem man den Ausgangsspannung und Strom jeweils auf Maximalwerte einstellt und dann den Ausgang kurzschließt.

In diesem Zustand sollte das Gerät längere Zeit (einige Stunden) betrieben werden, bis alles thermisch eingeschwungen ist. Dann muss bei allen Leistungsbauteilen die Temperatur gemessen werden, am einfachsten geht das mit einer Wärmebildkamera. Es sollten nach Möglichkeit keine Temperaturen oberhalb von 100°C auftreten. Wärme-empfindliche Bauteile (z.B. Elkos) sollten nicht wärmer als 70°C sein.

Besonders kritisch sind hier:
* Netztrafo
* Gleichrichter
* Leistungstransistoren und Kühlkörper

=== Stabilität und Genauigkeit ===

Wichtige Eigenschaften bei Labornetzgeräten ist die Stabilität und die Genauigkeit.

==== Stabilität ====

Damit wird angegeben, wie konstant ein eingestellter Wert über einen längeren Zeitraum gehalten wird. Hier ist wichtig, dass das Gerät einen kleinen Temperaturkoeffizient hat, so dass die Ausgangsspannung auch bei Temperaturschwankungen möglichst stabil bleibt.

==== Genauigkeit ====

Hier muss unterschieden werden zwischen der Anzeigegenauigkeit und der Einstellgenauigkeit.

Die Genauigkeit der Anzeige gibt an, wie genau die angezeigte Ausgangsspannung oder Strom mit der tatsächlichen Spannung übereinstimmt (siehe dazu auch Artikel [[Auflösung und Genauigkeit]]).

Die Einstellgenauigkeit gibt an, wie genau ein bestimmter Sollwert eingestellt werden kann und wie gut die tatsächlichen Werte mit den Sollwerten übereinstimmen. Bei Geräten mit digitaler Sollwertvorgabe muss hier die kleinste Schrittweite beachtet werden.

== Weitere Funktionen ==

=== Schnittstelle ===

Einige Labornetzgeräte bieten eine Schnittstelle zum PC, damit können sie als per Software steuerbares Netzgerät verwendet werden. Will man das Netzgerät per Mikrocontroller steuern, so sind Typen mit [[RS232]] Anschluß den Typen mit [[USB]] vorzuziehen.

=== Beleuchtung ===

Folgende Display-Arten sind bei Labornetzgeräten üblich:
* Analoginstrument (unbeleuchtet oder beleuchtet)
* LCD 7-Segment Anzeige (unbeleuchtet oder beleuchtet)
* LCD Punktmatrix-Anzeige (in der Regel beleuchtet)
* LED 7-Segment Anzeige (selbstleuchtend)
* OLED-Anzeigen (selbstleuchtend)
* VFD-Anzeigen (selbstleuchtend)

Anzeigen mit Beleuchtung bzw. selbstleuchtende Anzeigen sind wesentlich besser ablesbar als unbeleuchtete LCD-Anzeigen. Da Labornetzgeräte immer am Netz betrieben werden, ist der Stromverbrauch der Beleuchtung nicht relevant.

Unbeleuchtete LCD-Anzeigen sind bei schlechter Beleuchtung oder ungünstigem Blickwinkel manchmal schlecht ablesbar, bei 7-Segment LED-Anzeigen ist die Ablesbarkeit wesentlich besser.

Mit 7-Segment Anzeigen lassen sich allerdings nur Ziffern und einige wenige Buchstaben darstellen. Für Geräte mit komplexen Einstellungen und Menu-Führung werden deshalb häufig Punkt-Matrix LCD-Anzeigen verwendet.

Mit VFD-Anzeigen [http://de.wikipedia.org/wiki/Fluoreszenzanzeige], die ebenfalls sehr gut ablesbar sind, könnnen auch komplexe Menüs dargestellt werden. Diese haben einen sehr weiten Blickwinkel und sehr scharfe und klare Zeichen. Allerdings sind diese Anzeigen relativ teuer, weshalb sie vor allem in eher teueren Geräten eingesetzt werden.

== Vergleichstabelle Labornetzgeräte ==

In den folgende Tabellen werden wichtige technischen Daten einiger aktueller Labornetzgeräte zusammengestellt. Um die Übersichtlichkeit zu erhöhen, werden die Geräte eingeteilt in einfache Geräte und Geräte mit Zusatzfunktionen

Die Einteilung geschieht aufgrund der Funktionen, die die Geräte bieten. Das ist also keine Aussage über die Qualität der Geräte.

=== Einfache lineare Labornetzgeräte ===

Hier werden Geräte aufgelistet, welche neben den Grundfunktionen (Strom- und Spannungseinstellung, Anzeige der Istwerte) keine weiteren Funktionen besitzen.

{| border="1" class="wikitable sortable" id="einfache"
|-
!Hersteller
!Bezeichnung
!Preis [EUR]
!Spannung [V]
!Strom [A]
!Kanäle
|-
|Agilent
|E3616A
|620
|35
|1.7
|1
|-
|Hameg
|HM8040-3(Benötigt HM8001)
|280
|20 + 20 + 5
|0.5 + 0.5 + 1
|3
|-
|Peaktech
|6080
|50
|15
|3
|1
|-
|McVoice
|WNT0-15-2000
|38
|15
|2
|1
|-

|Statron
|2223.1
|150
|30
|2.5
|1
|-
|Statron
|2250.0
|225
|40
|5
|1
|-
|Statron
|2229.2
|260
|40 + 40
|2.5 + 2.5
|2
|-
|Statron
|2229.5
|340
|32 + 32 + 5
|3 + 3 + 3
|3
|-
|Statron
|2225.6
|310
|30 + 30
|5 + 5
|2
|-
|Voltcraft
|PS-1302 D
|95
|30
|2
|1
|-
|Voltcraft
|VLP 1303pro
|180
|30 + 6
|3 + 2
|2
|-
|Voltcraft
|VSP 2403
|345
|40 + 40 + 6
|3 + 3 + 1.5
|3
|}

=== Einfache Schaltnetzgeräte ===
{| border="1" class="wikitable sortable" id="einfache"
|-
!Hersteller
!Bezeichnung
!Preis [EUR]
!Spannung [V]
!Strom [A]
!Kanäle
|-
|Delta Elektronika
|ES 030-5
|624
|30
|5
|1
|-
|Quatpower
|LN-3003
|40
|30
|3
|1
|}

=== Netzgeräte mit Zusatzfunktionen ===

Diese Geräte haben mindestens folgende Funktionen:
* abschaltbare Ausgänge
* Anzeige der Sollwerte für Strom und Spannung

{| border="1" class="wikitable sortable" id="hochwertige"
|-
!Hersteller
!Bezeichnung
!Preis [EUR]
!Spannung [V]
!Strom [A]
!Kanäle
!linear/getaktet
|-
|Agilent
|U8001A
|290
|30
|3
|1
|linear
|-
|Agilent
|E3616A
|620
|35
|1.7
|1
|linear
|-
|Agilent
|E3643A
|690
|35 / 60 (umschaltbar)
|1.4 / 0.8
|1
|linear
|-
|Agilent
|E3632A
|990
|15 / 30 (umschaltbar)
|7 / 4
|1
|linear
|-
|BK Precision
|BK 1786
|490
|32
|3
|1
|linear
|-
|BK Precision
|BK 1788
|615
|32
|6
|1
|linear
|-
|BK Precision
|BK 9130
|685
|30 + 30 + 5
|3 + 3 + 3
|3
|linear
|-
|EA Elektro-Automatik
|PSI 6032-03
|425
|32
|3
|1
|linear
|-
|EA Elektro-Automatik
|EA-PS 2042-06B
|235
|42
|6
|1
|getaktet
|-
|EA Elektro-Automatik
|EA-PS 2342-06B
|580
|42 + 42 + 6
|6 + 6 + 4
|3
|getaktet
|-
|EA Elektro-Automatik
|EA-PS 3032-05B
|355
|32
|5
|1
|linear
|-
|EA Elektro-Automatik
|EA-PS 8032-10 DT
|940
|32
|10
|1
|getaktet
|-
|ELV
|PPS 5330
|120
|30
|3
|1
|linear
|-
|ELV
|SPS 5630
|200
|30
|6 (max. 75W)
|1
|getaktet
|-
|Hameg
|HM7042-5
|685
|32 + 32 + 5,5
|2 + 2 + 5
|3
|linear
|-
|Hameg
|HMP2020
|1190
|32 + 32
|10 + 5
|2
|getaktet + linear
|-
|Hameg
|HMP2030
|1500
|32 + 32 + 32
|5 + 5 + 5
|3
|getaktet + linear
|-
|Rigol
|DP832 **)
|362
|30 + 30 + 5
|3 + 3 + 3
|3
|linear
|-
|Voltcraft
|VLP 1405pro
|1190
|40 + 6
|5 + 2
|2
|linear
|-
|PeakTech
|1885
|270
|40
|5
|1
|getaktet
|-
|Voltcraft
|VLP 2403pro
|320
|40 + 40 + 6
|3 + 3 + 2
|3
|linear
|-
|Voltcraft
|VSP 2410
|470
|40 + 40 + 6
|10 + 10 + 1.5
|3
|getaktet
|-
|TTI
|EX355R
|330
|35
|5
|1
|Mixed-mode (getaktet + linear)
|-
|TTI
|EX354RD
|480
|35 + 35
|4 + 4
|2
|Mixed-mode (getaktet + linear)
|-
|TTI
|EX354RT
|540
|35 + 35 + (1,5-5)
|4 + 4 + 5
|3
|Mixed-mode (getaktet + linear)
|}

**) Das Rigol DP832(A) schaltet die Ausgänge nicht physisch/galvanisch ab. Die Power-MOSFETs der Ausgangsstufe werden lediglich auf Soll-NULL gesetzt. Dies kann bei Drift auch durchaus ungleich 0,00 Volt bedeuten!

== Siehe auch ==

[[Kategorie:Grundlagen]]
[[Kategorie:Spannungsversorgung_und_Energiequellen]]

Labornetzgeräte

2016-03-18T05:12:36Z

8023:

Kühlkörper

2016-03-18T05:10:36Z

8023:

Dieser Artikel versteht sich als Unterpunkt zum Artikel [[Leistungselektronik]].

== Einleitung ==

Ein Kühlkörper (engl. ''heat sink'') dient der Begrenzung der Betriebstemperatur elektronischer Bauteile. Er wird immer dann benötigt, wenn die Verlustleistung so hoch ist, dass die sich aufgrund der herrschenden Randbedingungen wie Wärmeleitfähigkeit, Luftkonvektion und Umgebungstemperatur einstellende Bauteiltemperatur den höchst zulässigen Wert übersteigen würde. 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 besser an die Umgebung abgeben zu können. Damit wird der Unterschied zwischen Lufttemperatur und Bauteiltemperatur gesenkt. Technisch spricht man hierbei von einer Verringerung des Temperaturwiderstandes.

[[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. Zudem sind sie so gefertigt und platziert, dass die Luftkonvektion unterstützt wird. 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 und 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 (Konvektion). Effektive Abstrahlung braucht immer recht hohe Temperaturdifferenzen von 100K und mehr, wie sie meist nur von Leistungswiderständen und Elektronenröhren erreicht werden. 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 ([https://de.wikipedia.org/wiki/Thermal_Pad Thermal Pad]) 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 und der Umgebung angegeben.

*<math>R_{\theta JA}</math> - Wärmewiderstand (griechisches Zeichen [https://de.wikipedia.org/wiki/Theta Groß-Theta]) zwischen Sperrschicht und Umgebung ohne zusätzlichen Kühlkörper in K/W

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

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

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 ist bei einigen Leistungsbauteilen im Datenblatt angegeben, manchmal kann er 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!

==== Beispiel ====

Gesucht:

*<math>R_{\theta S}</math> - max. Wärmewiderstand des Kühlkörpers

Gegeben:

*<math>P_{\theta}</math> : 10 W
*<math>R_{\theta JC}</math> : 3 K/W
*<math>R_{\theta CS}</math> : 0,5 K/W
*<math>T_J</math> : 130 °C
*<math>T_A</math> : 40 °C

Rechnung:

Um die Berechnung durchführen zu können, müssen wir zuerst die maximal zulässige Temperaturdifferenz zwischen Sperrschicht und Umgebung festlegen. Je größer man diesen Wert wählt, umso kleiner kann der Kühlkörper sein, aber umso heißer wird auch das Bauteil im Inneren betrieben.
Eine Angabe dazu findet man manchmal im Datenblatt (Operating junction temperature). Achtung, manchmal wird nur die zulässige Umgebungstemperatur genannt (Operationg temperature)! Wenn nicht, kann man sich an folgenden Angaben orientieren
* Leistungsbauteile wie [[Transistor]]en, [[TRIAC]]s etc. sind meist bis 150°C Sperrschichttemperatur ausgelegt, teilweise auch bis 200°C
* Leistungs-LEDs verkraften dauerhaft nur um die 80°C
* Man sollte die maximalen Betriebstemperaturen nicht ausreizen, wenn man eine hohe Lebensdauer und Funktionssicherheit anstrebt und 10-30K unter den Maximalwerten bleiben

<math>\Delta T = T_J - T_A = 130 ^\circ C - 40 ^\circ C = 90 K</math>

<math>R_{\theta} = \frac { \Delta T}{P_{\theta}} = \frac {90K}{10W} = 9 K/W </math>

<math>R_{\theta S} = R_{\theta} - R_{\theta JC} - R_{\theta CS} = 9 K/W - 3 K/W - 0,5K/W = 5,5 K/W</math>

Ergebnis:

<math>R_{\theta S} \leqq 5,5 K/W</math>

Der Kühlkörper darf einen maximalen Wärmewiderstand von 5,5 K/W haben, wenn die oben genannten Bedingungen eingehalten werden sollen. Ein Kühlkörper mit einem kleineren Wärmewiderstand hält das Bauteil kühler.

=== 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 oder die entstehende Eigenkonvektion zu gering ist?

Hier kommen die Lüfter zum Einsatz, das Ganze nennt sich dann Zwangskühlung. Der Effekt beruht darauf, dass wesentlich mehr Luft am Kühlkörper vorbeiströmen kann und damit (bei gleicher Temperaturerhöhung des Luftvolumenelementes) insgesamt mehr Wärme abgegeben werden kann.

Durch den Einsatz eines Lüfters lässt sich der effektive Wärmewiderstand eines Kühlkörpers etwa um mehrere Faktoren verbessern, bzw. der Kühlkörper kann in der Größe entsprechend reduziert werden. Dabei sind je nach Einbausituation des Kühlers und des Lüfters Faktoren zwischen 3-10 möglich. Ein typischer Wert, der sich bei durchschnittlich dimensionierten Kühlkörpern ergibt, ist ein Faktor 4-5. Die Temperaturüberhöhung schrumpft dabei z.B. von 80 Grad auf 20 Grad zusammen. Dies sind jedoch nur Richtwerte für den ersten Entwurf, eine Prüfung durch Messung ist unbedingt erforderlich.

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. 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 oder das Verbauen mehrerer Lüfter, sodass der Ausfall eines einzigen nicht sofort zu einem Geräteausfall führt.

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

Diese Werte sind jedoch nur theoretisch von Interesse, da die Praxis gezeigt hat, dass die effektive Kühlwirkung sehr stark von den sich einstellenden Mikroturbulenzen am Bauteil abhängt. Diese sind für den Wärmegradienten zwischen Kühleroberfläche und Umgebungsluft verantwortlich. Durch eine stark laminare = gleichförmig strömende Luft wird ein Bauteil eher schlecht gekühlt. Bestimmte Bauformen von Bauelementen und Kühlern begünstigen die Turbulenzbildung, behindern damit zwar den Luftstrom, da der Widerstand steigt, kühlen aber letztlich besser. So ist es zu erklären, dass manche Bauteile ohne Kühlung auskommen, da sie die Eigenkonvektion fördern und günstig im Luftstrom sitzen und von einem Kühler weniger profitieren, als andere Problembauteile.

Generell kann man sagen, dass flache, breite Bauteile zunehmend schlechter selbstkühlend sind, je größer sie werden und damit eher einen KK brauchen. FPGAs und Grafikchips sind solche Kandidaten. Hier empfehlen sich teilweise eigene Chipkühler. Auch RAM-Riegel mit sehr flachen Chips können so sehr effektiv kühl gehalten werden.

== 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/84303 Forumsbeitrag]: Beispielrechnung
*[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?
* [https://www.mikrocontroller.net/topic/205307#4091697 Forumsbeitrag]: Wärmewiderstand einfacher Bleche

== 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 Thermal Design], 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.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
* [http://www.zabex.de/site/kurios.html#wafeila Ungewöhnliche Hochlastwiderstände im Eigenbau]

[[Kategorie:Bauteile]]
[[Kategorie:Leistungselektronik]]
[[Category:Grundlagen]]

AVR-GCC-Tutorial/Die Timer und Zähler des AVR

2016-03-18T01:08:11Z

8023:

Die heutigen Mikrocontroller und insbesondere die RISC-[[AVR]]s sind für viele Steuerungsaufgaben zu schnell. Wenn wir beispielsweise eine [[LED]] oder Lampe blinken lassen wollen, können wir selbstverständlich nicht die CPU-Frequenz verwenden, da ja dann nichts mehr vom Blinken zu bemerken wäre.

Wir brauchen also eine Möglichkeit, Vorgänge in Zeitabständen durchzuführen, die geringer als die Taktfrequenz des Controllers sind. Selbstverständlich sollte die resultierende Frequenz auch noch möglichst genau und stabil sein.

Hier kommen die im AVR vorhandenen Timer/Counter zum Einsatz.

== Einleitung ==
Ein Timer ist ganz einfach ein bestimmtes Register im µC, das völlig ohne Zutun des Programms, also per Hardware, hochgezählt wird. Das alleine wäre noch nicht allzu nützlich, wenn nicht dieses Hardwareregister bei bestimmten Zählerständen einen Interrupt auslösen könnte.

Ein solches Ereignis ist der Overflow (Überlauf): Da die Bitbreite des Registers beschränkt ist, kommt es natürlich auch vor, dass der Zähler so hoch zählt, dass der nächste Zählerstand mit dieser Bitbreite nicht mehr darstellbar ist und der Zähler wieder auf 0 zurückgesetzt wird. Dieses Ereignis nennt man den Overflow und es ist möglich an dieses Ereignis einen Interrupt zu koppeln.

Ein anderes Anwendungsgebiet ist das Zählen von Impulsen, welche über einen I/O-Pin zugeführt werden.

Als Eingangstakt für die Timer/Counter kann entweder die CPU-Taktfrequenz, der Vorteiler-Ausgang oder ein an einen I/O-Pin angelegtes Signal verwendet werden. Wenn ein externes Signal verwendet wird, so darf dessen Frequenz nicht höher sein als die Hälfte des CPU-Taktes.

Die folgenden Ausführungen beziehen sich im Wesentlichen auf den AT90S2313. Für andere Modelltypen müsst ihr euch die allenfalls notwendigen Anpassungen aus den Datenblättern der entsprechenden Controller herauslesen.

== Der Vorteiler (Prescaler) ==

Der Vorteiler dient dazu, den CPU-Takt vorerst um einen einstellbaren Faktor zu reduzieren. Die so geteilte Frequenz wird den Eingängen der Timer zugeführt.

Wenn wir mit einem CPU-Takt von 4 MHz arbeiten und den Vorteiler auf 1024 einstellen, wird der Timer mit einer Frequenz von 4 MHz / 1024, also mit etwas weniger als 4 kHz versorgt. Wenn der Timer läuft, wird das Zählregister (TCNTx) mit dieser Frequenz inkrementiert.

== Timer-Bitzahlen verschiedener AVRs ==

Wir unterscheiden grundsätzlich zwischen 8-Bit Timern, welche eine Auflösung von 256 (2^8) aufweisen und 16-Bit Timern mit einer Auflösung von 65536 (2^16).

Alle AVR-Modelle verfügen über mindestens einen, teilweise sogar zwei, 8-Bit Timer.

:{| class="wikitable" style="text-align:center"
|-
! AVR-Typ || Timer/Counter0 || Timer/Counter1 || Timer/Counter2
|-
| AT90S2313 || 8 || 16 || -
|-
| ATtiny2313 || 8 || 16 || -
|-
| ATtiny25 || 8 || 8 || -
|-
| ATmega8 || 8 || 16 || 8
|-
| ATmega88 || 8 || 16 || 8
|-
| ATmega16 || 8 || 16 || 8
|-
| ATmega32 || 8 || 16 || 8
|-
| ATmega644 || 8 || 16 || 8
|}

== 8-Bit Timer/Counter ==

Der 8-Bit Timer wird z.B bei AT90S2313 über folgende Register angesprochen (bei anderen Typen weitestgehend analog):

{| class="wikitable"
|-
| width="100" | '''TCCR0'''
| '''T'''imer/'''C'''ounter '''C'''ontrol '''R'''egister
Timer '''0'''

In diesem Register stellen wir ein, wie wir den Timer/Counter verwenden möchten.

Das Register ist wie folgt aufgebaut:

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7|| 6|| 5|| 4|| 3|| 2|| 1|| 0
|-
! Name
|| '''-'''|| '''-'''|| '''-'''|| '''-'''|| '''-'''|| '''CS02'''|| '''CS01'''|| '''CS00'''
|-
! R/W
| R|| R|| R|| R|| R|| R/W|| R/W|| R/W
|-
! Initialwert
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0
|}

'''CS02, CS01, CS00''' ('''C'''lock '''S'''elect Bits)
:Diese 3 Bits bestimmen die Quelle für den Timer/Counter:

:{| class="wikitable"
|-
! CS02 || CS01 || CS00 || Resultat
|-
| align="center" | 0
| align="center" | 0
| align="center" | 0
| Stopp, Der Timer/Counter wird angehalten.
|-
| align="center" | 0
| align="center" | 0
| align="center" | 1
| CPU-Takt
|-
| align="center" | 0
| align="center" | 1
| align="center" | 0
| CPU-Takt / 8
|-
| align="center" | 0
| align="center" | 1
| align="center" | 1
| CPU-Takt / 64
|-
| align="center" | 1
| align="center" | 0
| align="center" | 0
| CPU-Takt / 256
|-
| align="center" | 1
| align="center" | 0
| align="center" | 1
| CPU-Takt / 1024
|-
| align="center" | 1
| align="center" | 1
| align="center" | 0
| Externer Pin '''TO''', fallende Flanke
|-
| align="center" | 1
| align="center" | 1
| align="center" | 1
| Externer Pin '''TO''', steigende Flanke
|}

:Wenn als Quelle der externe Pin '''TO''' verwendet wird, so wird ein Flankenwechsel auch erkannt, wenn der Pin '''TO''' als Ausgang geschaltet ist.

|-
| '''TCNT0'''
| '''T'''imer/'''C'''ou'''nt'''er Daten Register Timer '''0''' 
Dieses ist als 8-Bit Aufwärtszähler mit Schreib- und Lesezugriff
realisiert. Wenn der Zähler den Wert 255 erreicht hat, beginnt er beim
nächsten Zyklus wieder bei 0.

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7|| 6|| 5|| 4|| 3|| 2|| 1|| 0
|-
! Name
| '''MSB'''||  ||  ||  ||  ||  ||  || '''LSB'''
|-
! R/W
| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W
|-
! Initialwert
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0
|}
|}

Um nun also den Timer0 in Betrieb zu setzen und ihn mit einer Frequenz von 1/8-tel des CPU-Taktes zählen zu lassen, schreiben wir die folgende Befehlszeile:

<syntaxhighlight lang="c">
TCCR0 = (1<<CS01);
</syntaxhighlight>

Der Zähler zählt nun aufwärts bis 255, um dann wieder bei 0 zu beginnen. Der aktuelle Zählerstand steht in TCNT0. Bei jedem Überlauf von 255 auf 0 wird das Timer Overflow Flag '''TOV0''' im Timer Interrupt Flag '''TIFR'''-Register gesetzt und, falls so konfiguriert, ein entsprechender Timer-Overflow-Interrupt ausgelöst und die daran gebundene Interrupt-Service-Routine (ISR) abgearbeitet. Das TOV Flag
lässt sich durch das Hineinschreiben einer 1 und nicht wie erwartet einer 0 wieder zurücksetzen.

=== Overflow Interrupt ===

Jedesmal wenn der Timer seinen höchsten Wert erreicht hat, erfolgt ein Overflow und der Timer beginnt wieder bei 0 zu zählen. An diesen Overflow kann eine Funktion, die sog. Overflow-ISR, gebunden werden. Damit hat man die Möglichkeit, bestimmte Funktionalitäten in regelmäßigen Zeitabständen ausführen zu lassen. Wie groß diese Zeitabstände sind, wird ausschließlich von der Zählfrequenz des Timers und der Bitbreite des Timers (also dem höchsten Wert, den der Timer erreichen kann) bestimmt. Die Zählfrequenz wiederrum hängt von Taktfrequenz des Controllers und dem eingestellten Vorteiler ab.

<syntaxhighlight lang="c">
/* uC: AT90S2313 */
#include <avr/io.h>
#include <avr/interrupt.h>

int main(void)
{
// Timer 0 konfigurieren
TCCR0 = (1<<CS01); // Prescaler 8

// Overflow Interrupt erlauben
TIMSK |= (1<<TOIE0);

// Global Interrupts aktivieren
sei();

while(1)
{
/* Sonstige Aktionen */
}
}

/*
Der Overflow Interrupt Handler
wird aufgerufen, wenn TCNT0 von
255 auf 0 wechselt (256 Schritte),
d.h. ca. alle 2 ms
*/
#ifndef TIMER0_OVF_vect
// Für ältere WinAVR Versionen z.B. WinAVR-20071221
#define TIMER0_OVF_vect TIMER0_OVF0_vect
#endif

ISR (TIMER0_OVF_vect)
{
/* Interrupt Aktion alle
(1000000/8)/256 Hz = 488,28125 Hz
bzw.
1/488,28125 s = 2,048 ms
*/
}
</syntaxhighlight>

Grundsätzlich kann man in einer ISR jeden beliebigen Code ausführen lassen. Allerdings sollte man sich an die Grundregeln der ISR Programmierung halten: Nur das tun was unbedingt notwendig ist. Eine ISR sollte (zeitlich gesehen) so kurz wie möglich aber so lang wie notwendig sein. Komplexe Ausgaben auf LCD oder gar auf die UART gehören nicht in eine ISR. Sie dauern einfach zu lange und blockieren so den Prozessor zu lange. Programme, die mehrere Dinge quasi gleichzeitig machen, werden so zu lange blockiert.

Die Taktfrequenz, mit der eine ISR aufgerufen wird, erscheint nach obigen Ausführungen recht starr, aber sie lässt sich feiner anpassen. Eine Möglichkeit bestünde darin, den Zählerstand des Registers TCNT0 nach einem Overflow auf einen Wert größer als 0 zu setzen. Somit blieben bis zum nächsten Overflow weniger Zähltakte, was die Frequenz erhöhen würde.

Modernere AVRs kennen allerdings einen eleganteren Weg zur Anpassung der Interrupt-Frequenz: den CTC Modus

=== '''CTC''' Clear Timer on Compare Match (Auto Reload) ===

Im CTC Modus des Timers ist es möglich, anstelle der durch die Hardware bedingten Obergrenze des Timers, einen anderen Wert zu benutzen, an dem der Timer einen Interrupt auslöst und wieder bei 0 zu zählen anfängt. Neben dem Aktivieren des CTC Modus genügt es dazu, einfach den gewünschten Endwert in ein spezielles Register, das OCR0A, zu laden. Und natürlich hat auch die ISR dann einen anderen Namen. Weitere Anmerkungen und Erläuterungen finden sich im CTC-Kapitel der 16-Bit Timer.

<syntaxhighlight lang="c">
/* uC: Attiny2313 */
#include <avr/io.h>
#include <avr/interrupt.h>

//Variablen für die Zeit
volatile unsigned int millisekunden;
volatile unsigned int sekunde;
volatile unsigned int minute;
volatile unsigned int stunde;

int main(void)
{
// Timer 0 konfigurieren
TCCR0A = (1<<WGM01); // CTC Modus
TCCR0B |= (1<<CS01); // Prescaler 8
// ((1000000/8)/1000) = 125
OCR0A = 125-1;

// Compare Interrupt erlauben
TIMSK |= (1<<OCIE0A);

// Global Interrupts aktivieren
sei();

while(1)
{
/*Hier kann die aktuelle Zeit
ausgeben werden*/
}
}

/*
Der Compare Interrupt Handler
wird aufgerufen, wenn
TCNT0 = OCR0A = 125-1
ist (125 Schritte), d.h. genau alle 1 ms
*/
ISR (TIMER0_COMPA_vect)
{
millisekunden++;
if(millisekunden == 1000)
{
sekunde++;
millisekunden = 0;
if(sekunde == 60)
{
minute++;
sekunde = 0;
}
if(minute == 60)
{
stunde++;
minute = 0;
}
if(stunde == 24)
{
stunde = 0;
}
}
}
</syntaxhighlight>

Anm.: In diesem Beispiel ist es egal, ob TCCR0B absolut gesetzt wird (TCCR0B = (1<<CS01)) oder der Prescaler-Wert zum alten Inhalt hinzugefügt wird (TCCR0B |= (1<<CS01)). Die anderen Bits in TCCR0B sind nach dem Reset 0 und sollen auch 0 bleiben. Wenn man sicher nur bestimmte Bits ändern will, ist das ODER (bzw. UND mit dem Kehrwert) sicherer. Näheres dazu im Artikel [[Bitmanipulation]].

== 16-Bit Timer/Counter ==

Viele AVR-Modelle besitzen außer den 8-Bit Timern auch 16-Bit Timer. Die 16-Bit Timer/Counter sind etwas komplexer aufgebaut als die 8-Bit Timer/Counter, bieten dafür aber auch viel mehr Möglichkeiten, als da sind:

* Die [[PWM]]-Betriebsart zur Erzeugung eines pulsweitenmodulierten Ausgangssignals.
* Vergleichswert-Überprüfung mit Erzeugung eines Ausgangssignals (Output Compare Match).
* Einfangen eines Eingangssignals mit Speicherung des aktuellen Zählerwertes (Input Capturing), mit zuschaltbarer Rauschunterdrückung (Noise Filtering).

Folgende Register sind dem Timer/Counter 1 zugeordnet:

{| class="wikitable"
|-
| width="100" | '''TCCR1A'''
| '''T'''imer/'''C'''ounter '''C'''ontrol '''R'''egister '''A''' Timer '''1''' 
In diesem und dem folgenden Register stellen wir ein, wie wir den Timer/Counter verwenden möchten. 
Das Register ist wie folgt aufgebaut:

{| class="wikitable"
|-
! Bit
| 7|| 6|| 5|| 4|| 3|| 2|| 1|| 0
|-
! Name
| '''COM1A1'''|| '''COM1A0'''|| '''-'''|| '''-'''|| '''-'''|| '''-'''|| '''PWM11'''|| '''PWM10'''
|-
! R/W
| R/W|| R/W|| R|| R|| R|| R|| R/W|| R/W
|-
! Initialwert
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0
|}

'''COM1A1''', '''COM1A0''' ('''Co'''mpare '''M'''atch Control Bits)
:Diese 2 Bits bestimmen die Aktion, welche am Output-Pin '''OC1''' ausgeführt werden soll, wenn der Wert des Datenregisters des Timer/Counter 1 den Wert des Vergleichsregisters erreicht, also ein so genannter Compare Match auftritt.
:Der Pin '''OC1''' ('''PB3''' beim 2313) muss mit dem Datenrichtungsregister als Ausgang konfiguriert werden.

:{| class="wikitable"
|-
! COM1A1 || COM1A0 || Resultat
|-
| align="center" | 0
| align="center" | 0
| Output-Pin '''OC1''' wird nicht angesteuert.
|-
| align="center" | 0
| align="center" | 1
| Das Signal am Pin '''OC1''' wird invertiert (Toggle).
|-
| align="center" | 1
| align="center" | 0
| Der Output Pin '''OC1''' wird auf 0 gesetzt.
|-
| align="center" | 1
| align="center" | 1
| Der Output Pin '''OC1''' wird auf 1 gesetzt.
|}

:In der PWM-Betriebsart haben diese Bits eine andere Funktion.

:{| class="wikitable"
|-
! COM1A1 || COM1A0 || Resultat
|-
| align="center" | 0
| align="center" | 0
| Output-Pin '''OC1''' wird nicht angesteuert.
|-
| align="center" | 0
| align="center" | 1
| Output-Pin '''OC1''' wird nicht angesteuert.
|-
| align="center" | 1
| align="center" | 0
| Wird beim Hochzählen der Wert im Vergleichsregister erreicht, so wird der Pin '''OC1''' auf 0 gesetzt.
Wird beim Herunterzählen der Wert im Vergleichsregister erreicht, so wird der Pin auf 1 gesetzt.

Man nennt dies ''nicht invertierende PWM''.
|-
| align="center" | 1
| align="center" | 1
| Wird beim Hochzählen der Wert im Vergleichsregister erreicht, so wird der Pin '''OC1''' auf 1 gesetzt.
Wird beim Herunterzählen der Wert im Vergleichsregister erreicht, so wird der Pin auf 0 gesetzt.

Man nennt dies ''invertierende PWM''.
|}

'''PWM11''', '''PWM10''' ('''PWM''' Mode Select Bits)
:Mit diesen 2 Bits wird die PWM-Betriebsart des Timer/Counter 1 gesteuert.
* PWM10 PWM11 wurden umbenannt in WGM10 und WGM11
:{| class="wikitable"
|-
! PWM11 || PWM10 || Resultat
|-
| align="center" | 0
| align="center" | 0
| Die PWM-Betriebsart ist nicht aktiviert. Timer/Counter 1 arbeitet als normaler Timer bzw. Zähler.
|-
| align="center" | 0
| align="center" | 1
| 8-Bit PWM Betriebsart aktivieren.
|-
| align="center" | 1
| align="center" | 0
| 9-Bit PWM Betriebsart aktivieren.
|-
| align="center" | 1
| align="center" | 1
| 10-Bit PWM Betriebsart aktivieren.
|}

|-
| '''TCCR1B'''
| '''T'''imer/'''C'''ounter '''C'''ontrol '''R'''egister '''B''' Timer '''1'''

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''ICNC1'''|| '''ICES1'''|| '''-'''|| '''WGM13'''|| '''WGM12 (CTC1)'''|| '''CS12'''|| '''CS11'''|| '''CS10'''
|-
! R/W
| R/W || R/W || R || R || R/W || R/W || R/W || R/W
|-
! Initialwert
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0
|}

'''ICNC1''' ('''I'''nput '''C'''apture '''N'''oise '''C'''anceler (4 CKs) Timer/Counter 1
:oder auf Deutsch Rauschunterdrückung des Eingangssignals.
:Wenn dieses Bit gesetzt ist und mit dem Input Capture Signal gearbeitet wird so werden nach der Triggerung des Signals mit der entsprechenden Flanke (steigend oder fallend) am Input Capture Pin '''ICP''' jeweils 4 Messungen mit der CPU-Frequenz des Eingangssignals abgefragt. Nur dann, wenn alle 4 Messungen den gleichen Zustand aufweisen gilt das Signal als erkannt.

'''ICES1''' ('''I'''nput '''C'''apture '''E'''dge '''S'''elect Timer/Counter '''1''')
:Mit diesem Bit wird bestimmt, ob die steigende ('''ICES1'''=1) oder fallende ('''ICES1'''=0) Flanke zur Auswertung des Input Capture Signals an Pin '''ICP''' heran gezogen wird.

'''CTC1''' ('''C'''lear '''T'''imer/'''C'''ounter on Compare Match Timer/Counter '''1''')
:Wenn dieses Bit gesetzt ist, so wird nach einer Übereinstimmung des Datenregisters '''TCNT1H'''/'''TCNT1L''' mit dem Vergleichswert in '''OCR1H'''/'''OCR1L''' das Datenregister '''TCNT1H'''/'''TCNT1L''' auf 0 gesetzt.
:Da die Übereinstimmung im Takt nach dem Vergleich behandelt wird, ergibt sich je nach eingestelltem Vorteiler ein etwas anderes Zählverhalten:
:Wenn der Vorteiler auf 1 gestellt, und C der voreingestellte Vergleichswert ist, dann nimmt das Datenregister, im CPU-Takt betrachtet, folgende Werte an:
:... | C-2 | C-1 | C | 0 | 1 |...
:Wenn der Vorteiler z. B. auf 8 eingestellt ist, dann nimmt das Datenregister folgende Werte an:
:... | C-2, C-2, C-2, C-2, C-2, C-2, C-2, C-2 | C-1, C-1, C-1, C-1, C-1, C-1, C-1, C-1 | C, 0, 0, 0, 0, 0, 0, 0 |...
:In der PWM-Betriebsart hat dieses Bit keine Funktion.

'''CS12''', '''CS11''', '''CS10''' ('''C'''lock '''S'''elect Bits)
:Diese 3 Bits bestimmen die Quelle für den Timer/Counter:

:{| class="wikitable"
|-
! CS12 || CS11 || CS10 || Resultat
|-
| align="center" | 0
| align="center" | 0
| align="center" | 0
| Stopp, Der Timer/Counter wird angehalten.
|-
| align="center" | 0
| align="center" | 0
| align="center" | 1
| CPU-Takt
|-
| align="center" | 0
| align="center" | 1
| align="center" | 0
| CPU-Takt / 8
|-
| align="center" | 0
| align="center" | 1
| align="center" | 1
| CPU-Takt / 64
|-
| align="center" | 1
| align="center" | 0
| align="center" | 0
| CPU-Takt / 256
|-
| align="center" | 1
| align="center" | 0
| align="center" | 1
| CPU-Takt / 1024
|-
| align="center" | 1
| align="center" | 1
| align="center" | 0
| Externer Pin T1, fallende Flanke
|-
| align="center" | 1
| align="center" | 1
| align="center" | 1
| Externer Pin T1, steigende Flanke
|}

:Wenn als Quelle der externe Pin T1 verwendet wird, so wird ein Flankenwechsel auch erkannt, wenn der Pin T1 als Ausgang geschaltet ist.
|-
| '''TCNT1H''' '''TCNT1L'''
| '''T'''imer/'''C'''ou'''nt'''er Daten Register Timer/Counter '''1'''
Dieses ist als 16-Bit Aufwärtszähler mit Schreib- und Lesezugriff realisiert. Wenn der Zähler den Wert 65535 erreicht hat, beginnt er beim nächsten Zyklus wieder bei 0.

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0 ||
|-
! Name
| '''MSB'''||  ||  ||  ||  ||  ||  ||  || '''TCNT1H'''
|-
! Name
||  ||  ||  ||  ||  ||  ||  || '''LSB'''|| '''TCNT1L'''
|-
! R/W
| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W||  
|-
! Initialwert
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0||  
|}

In der PWM-Betriebsart wird das Register als Auf/Ab-Zähler verwendet, d.h. der Wert steigt zuerst von 0, bis er den Überlauf von 65535 auf 0 erreicht hat. Dann zählt das Register rückwärts wiederum bis 0.

Zum Auslesen des Registers wird von der CPU ein internes TEMP-Register verwendet. Das gleiche Register wird auch verwendet, wenn auf '''OCR1''' oder '''ICR1''' zugegriffen wird.

Deshalb müssen vor dem Zugriff auf eines dieser Register alle Interrupts gesperrt werden, weil sonst die Möglichkeit des gleichzeitigen Zugriffs auf das Temporärregister gegeben ist, was natürlich zu fehlerhaftem Verhalten des Programms führt.. Zudem muss zuerst '''TCNT1L''' und erst danach '''TCNT1H''' ausgelesen werden.

Wenn in das Register geschrieben werden soll, müssen ebenfalls alle Interrrupts gesperrt werden. Dann muss zuerst das '''TCNT1H'''-Register und erst danach das '''TCNT1L'''-Register geschrieben werden, also genau die umgekehrte Reihenfolge wie beim Lesen des Registers.
|-
| '''OCR1H''' '''OCR1L'''
| Timer/Counter '''O'''utput '''C'''ompare '''R'''egister Timer/Counter '''1'''
{| class="wikitable" style="text-align:center"
|-
! Bit
| 7|| 6|| 5|| 4|| 3|| 2|| 1|| 0||  
|-
! Name
| '''MSB'''||  ||  ||  ||  ||  ||  ||  || '''OCR1H'''
|-
! Name
|  ||  ||  ||  ||  ||  ||  || '''LSB'''|| '''OCR1L'''
|-
! R/W
| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W||  
|-
! Initialwert
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0||  
|}

Der Wert im Output Compare Register wird ständig mit dem aktuellen Wert im Datenregister TCNT1H/TCNT1L verglichen. Stimmen die beiden Werte überein, so wird ein sogenannter Output Compare Match ausgelöst. Die entsprechenden Aktionen werden über die Timer/Counter 1 Control und Status Register eingestellt.

Zum Auslesen des Registers wird von der CPU ein internes TEMP-Register verwendet. Das gleiche Register wird auch verwendet, wenn auf '''TCNT1''' oder '''ICR1''' zugegriffen wird.
Deshalb müssen vor dem Zugriff auf eines dieser Register alle Interrupts gesperrt werden, weil sonst die Möglichkeit des gleichzeitigen Zugriffs auf das Temporärregister gegeben ist, was natürlich zu fehlerhaftem Verhalten des Programms führt. Zudem muss zuerst '''OCR1L''' und erst danach '''OCR1H''' ausgelesen werden.

Wenn in das Register geschrieben werden soll, müssen ebenfalls alle Interrupts gesperrt werden. Dann muss zuerst das '''OCR1H'''-Register und erst danach das '''OCR1L'''-Register geschrieben werden, also genau die umgekehrte Reihenfolge wie beim Lesen des Registers.
|-
| '''ICR1H''' '''ICR1L'''
| Timer/Counter '''I'''nput '''C'''apture '''R'''egister Timer/Counter '''1''' 
{| class="wikitable" style="text-align:center"
|-
! Bit
| 7|| 6|| 5|| 4|| 3|| 2|| 1|| 0||  
|-
! Name
| '''MSB'''||  ||  ||  ||  ||  ||  ||  || '''ICR1H'''
|-
! Name
|  ||  ||  ||  ||  ||  ||  || '''LSB'''|| '''ICR1L'''
|-
! R/W
| R|| R|| R|| R|| R|| R|| R|| R||  
|-
! Initialwert
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0||  
|}

Das Input Capture Register ist ein 16-Bit Register. Bei einigen AVR Modellen kann es als TOP Value für bestimmte PWM Modes verwendet werden.

Wenn am Input Capture Pin '''ICP''' die gemäß Einstellungen im '''TCCR1B''' definierte Flanke erkannt wird, so wird der aktuelle Inhalt des Datenregisters '''TCNT1H'''/'''TCNT1L''' sofort in dieses Register kopiert und das Input Capture Flag '''ICF1''' im Timer Interrupt Flag Register '''TIFR''' gesetzt.

{{Warnung|Wie bereits oben erwähnt, müssen vor dem Zugriff auf dieses Register alle Interrupts gesperrt werden. Zudem müssen Low- und Highbyte des Registers in der richtigen Reihenfolge bearbeitet werden:
;Lesen:: '''ICR1L''' → '''ICR1H'''
Bei Verwendung des Compilers wird der Zugriff in der korrekten Reihenfolge ausgeführt, wenn man das 16-Bit register ICR1 verwendet anstatt zwei Zugriffe auf 8-Bit Register.
}}

|}

=== Die PWM-Betriebsart ===

Wenn der Timer/Counter 1 in der PWM-Betriebsart betrieben wird, so bilden das Datenregister '''TCNT1H'''/'''TCNT1L''' und das Vergleichsregister '''OCR1H'''/'''OCR1L''' einen 8-, 9- oder 10-Bit, frei laufenden PWM-Modulator, welcher als PWM-Signal am '''OC1'''-Pin ('''PB3''' beim 2313) abgegriffen werden kann. Das Datenregister '''TCNT1H'''/'''TCNT1L''' wird dabei als Auf-/Ab-Zähler betrieben, welcher von 0 an aufwärts zählt bis zur Obergrenze und danach wieder zurück auf 0.
Die Obergrenze ergibt sich daraus, ob 8-, 9- oder 10-Bit PWM verwendet wird, und zwar gemäß folgender Tabelle:

{| class="wikitable" style="text-align:center"
|-
! Auflösung || Obergrenze || Frequenz
|-
| 8 || 255 || fTC1 / 510
|-
| 9 || 511 || fTC1 / 1022
|-
|10 || 1023 || fTC1 / 2046
|}

Wenn nun der Zählerwert im Datenregister den in '''OCR1H'''/'''OCR1L''' gespeicherten Wert erreicht, wird der Ausgabepin '''OC1''' gesetzt bzw. gelöscht, je nach Einstellung von '''COM1A1''' und '''COM1A0''' im '''TCCR1A'''-Register.

Ich habe versucht, die entsprechenden Signale in der folgenden Grafik zusammenzufassen

[[Image:PWM Theorie 3.gif]] [[Image:PWM Theorie 4.gif]]

=== Vergleichswert-Überprüfung (Compare Match) ===

Hier wird in ein spezielles Vergleichswertregister ('''OCR1H'''/'''OCR1L''') ein Wert eingeschrieben, welcher ständig mit dem aktuellen Zählerwert verglichen wird.
Erreicht der Zähler den in diesem Register eingetragenen Wert, so kann ein Signal (0 oder 1) am Pin '''OC1''' erzeugt und/oder ein Interrupt ausgelöst werden.

Zu erwähnen ist in dem Zusammenhang, dass das zur Compare-Einheit gehörende Interrupt-Flag erst beim auf die Übereinstimmung der Werte folgenden Timertakt gesetzt wird. Das ist v.a. deshalb wichtig, da es sonst bei OCRnx = 0 einen undefinierten Zustand gäbe.

Möchte man ein Compare-Ereignis 100 Takte nach dem Timerüberlauf auslösen, dann muss in das betreffende Compare-Register eine 99 geschrieben werden.

=== CTC-Betriebsart (Clear Timer on Compare Match) ===

Das sogenannte '''Compare Match-Ereignis''' kann auch dazu verwendet werden, um den Timer automatisch zurückzusetzen (d.h. das TCNT-Register wird zu Null gesetzt). Diese Betriebsart heißt "Clear Timer on Compare Match", also auf deutsch "Lösche Timer bei Vergleichsübereinstimmung".

Mit dieser Funktionalität ist es möglich, sehr präzise Taktsignale zu erzeugen, ohne dabei programmtechnisch eingreifen zu müssen. '''Diese Funktion ersetzt das bei anderen Controllern und Timern ohne Compare-Einheit erforderliche Timer Reload''' (also das Nachladen des Zählregisters mit "Überlaufwert minus gewünschte Taktzahl bis zum Überlauf", v.a. verbreitet bei 8051er-µCs).

Zur Erzeugung eines Taktes per Hardware muss lediglich eine der CTC-Betriebsarten ausgewählt werden und einer der OCnx-Pins so gesetzt werden, dass er bei Auftreten des Compare Match getoggelt wird (über die COM-Bits).

Die Frequenz des Taktes am entsprechenden Ausgang ist dann:
<math>f_\text{OC} = \frac{f_\text{CPU}}{\text{Prescaler} \cdot \left( \text{OCRnx} + 1 \right)}</math>

Umgeformt gilt für OCRnx:
<math>\text{OCRnx} = \frac{f_\text{CPU}}{\text{Prescaler} \cdot f_\text{OC}} - 1</math>

Diese Betriebsart macht das Timer-Nachladen, das bei AVRs, die ja im Unterschied zu 8051-Derivaten keine Auto-Reload-Funktion haben, immer mit Ungenauigkeiten und programmtechnischen Klimmzügen verbunden ist, überflüssig. Ist das OCRnx einmal gesetzt, dann wird das Signal am Ausgang kontinuierlich ausgegeben, ohne dass die Anwendersoftware eingreifen muss (es sei denn, die Frequenz soll geändert werden).

Beim ATmega8 hat der 8-Bit-Timer 0 keine Compare-Einheit, so dass dort CTC und auch sonstige automatische Vergleichsoperationen nicht möglich sind. Bei Timer 1 und Timer 2 ist das jedoch möglich. Bei den neueren AVRs besitzen i.d.R. ''alle'' Timer eine oder mehrere Compare-Einheiten, so dass dort eine größere Flexibilität gegeben ist.

Im Unterschied zu den PWM-Betriebsarten wird die Registeraktualisierung bei CTC nicht automatisch synchronisiert. Schreibt man einen neuen Compare-Wert, dann wird dieser sofort übernommen, was zu Fehlfunktionen führen kann, wenn der neue Compare-Wert höher ist, als der aktuelle Stand von TCNTnx. In den PWM-Betriebsarten wird hingegen der TOP-Wert synchron bei Erreichen von TOP oder BOTTOM aktualisiert.

=== Einfangen eines Eingangssignals (Input Capturing) ===

Bei dieser Betriebsart wird an den Input Capturing Pin (ICP) des Controllers eine Signalquelle angeschlossen.
Nun kann je nach Konfiguration entweder ein Signalwechsel von 0 nach 1 (steigende Flanke) oder von 1 nach 0 (fallende Flanke) erkannt werden und der zu diesem Zeitpunkt aktuelle Zählerstand in ein spezielles Register abgelegt werden. Gleichzeitig kann auch ein entsprechender Interrupt ausgelöst werden.
Wenn die Signalquelle ein starkes Rauschen beinhaltet, kann die Rauschunterdrückung eingeschaltet werden. Dann wird beim Erkennen der konfigurierten Flanke über 4 Taktzyklen das Signal überwacht und nur dann, wenn alle 4 Messungen gleich sind, wird die entsprechende Aktion ausgelöst.

In Verbindung mit dem eingebauten Analogvergleicher, einem externen Operationsverstärker (als Integrator beschaltet) und einem externen Analogsignalschalter lässt sich ein präziser [[ADC|A/D-Wandler]] nach dem Zweiflankenverfahren, ggf. mit automatischer Nullpunktkorrektur aufbauen.

== Timer2 im Asynchron Mode ==

Bei den (meisten) Atmegas lässt sich der Timer2 asynchron betreiben. Das bedeutet, daß der Timer unabhängig vom CPU-Takt mit einer eigenen Taktquelle betrieben werden kann.
In Verbindung mit einem 32,768KHz-Quarz, auch Uhrenquarz genannt, lässt sich so auf einfache Weise eine RTC (Real Time Clock) integrieren, die eine externe RTC überflüssig macht.

Beim ATMega48...328 wird, wie beim ATMega8, der Uhrenquarz alternativ zum "normalen" Quarz an XTAL1 und XTAL2 angeschlossen.
Diese Controller müssen dann mit dem internen RC-Oszillator als CPU-Takt betrieben werden. ATMEGA644 & Co. haben einen
separaten Anschluss für den Uhrenquarz.

'''Für den Anschluss des Uhrenquarzes müssen keine Fuses verändert werden!'''

<syntaxhighlight lang="c">
/* uC: ATMega48PA */
#include <avr/io.h>
#include <avr/interrupt.h>

//Variablen für die Zeit
volatile unsigned char sekunde;
volatile unsigned char minute;
volatile unsigned char stunde;

int main(void)
{
// Timer 2 konfigurieren
GTCCR |= (1 << TSM) | (1 << PSRASY); //Timer anhalten, Prescaler Reset
ASSR |= (1 << AS2); //Asynchron Mode einschalten
TCCR2A = (1 << WGM21); //CTC Modus
TCCR2B |= (1 << CS22) | (1 << CS21); //Prescaler 256
// 32768 / 256 / 1 = 128 Intervall = 1s
OCR2A = 128 - 1;
TIMSK2 |= (1<<OCIE2A); //Enable Compare Interrupt
GTCCR &= ~(1 << TSM); //Timer starten
sei(); //Enable global Interrupts

while(1)
{
/*Hier kann die aktuelle Zeit
ausgeben werden*/
}
}

/*
Der Compare Interrupt Handler
wird aufgerufen, wenn
TCNT2 = OCR2A = 128-1
ist (128 Schritte), d.h. genau alle 1s
*/
ISR (TIMER2_COMPA_vect)
{
TCCR2B = TCCR2B; //Wird weiter unten im Text erklärt!
sekunde++;
if(sekunde == 60)
{
minute++;
sekunde = 0;
}
if(minute == 60)
{
stunde++;
minute = 0;
}
if(stunde == 24)
{
stunde = 0;
}
// Wird weiter unten im Text erklärt!
while(ASSR & ((1<<TCN2UB) | (1<<OCR2AUB) | (1<<OCR2BUB) |
(1<<TCR2AUB) | (1<<TCR2BUB)));
}
</syntaxhighlight>

Der Timer-Interrupt wird jetzt im Sekundentakt aufgerufen. Dieser Aufruf geschieht jedoch nicht nur im normalen Betrieb des Controllers, sondern auch im Sleep-Mode!
Hierzu gibt es extra den Sleep-Mode Power-save. In diesem Mode wird praktisch der gesamte Controller bis auf den Timer2 mit seinem Quarz abgeschaltet.

Das Aufwecken geschieht automatisch mit jedem Interrupt des Timers. Der Stromverbrauch sinkt dabei auf bis zu 0,75µA.

Das "Schlafenlegen" muß dabei in der Mainloop erfolgen, damit der Controller nach der Abarbeitung des Interrupts wieder in den Sleep-Mode geschickt wird.
Dies geschieht nicht automatisch!

Die üblichen 32-kHz-Quarze haben eine vergleichsweise lange Anschwingdauer. Je nach Quarz sind Zeiten von mehreren 100 ms bis zu einer Sekunde keine Seltenheit. Entsprechend dauert es nach dem ersten Einschalten des AS2-Bits einige Zeit, bis der Timer losläuft. U.a. aus diesem Grund wird in dem obigen Initialisierungsbeispiel der Timer mit PSRASY im GTCCR angehalten. Nach Löschen des TSM im selben Register
wird das PSRASY mit dem nächsten Takt des Timers selbständig gelöscht und der Timer gestartet. Wobei ich es grundsätzlich als sinnvoll ansehe, einen Timer erst nach der Konfiguration definiert loslaufen zu lassen.

=== Wenn er die Minute in 20s schafft ===

Alle zum Timer2 gehörigen Register werden weiterhin synchron beschrieben.
Allerdings nicht synchron zum CPU-Takt von üblicherweise 1MHz oder 8MHz, sondern synchron zum Takt des Timer2. Diese Taktung des Timers erfolgt jetzt mit 32,768KHz.

Wenn TCNT2 == OCR2A, wird das OCF2A-Flag im TIFR2-Register gesetzt und der Sleep-Mode verlassen.

Der Controller stellt jetzt fest, daß das OCF2A-Flag gesetzt ist und springt auf den COMP2A-Interrupt-Vektor und dann weiter in die ISR. Dabei werden die Rücksprungadresse
auf den Stack gelegt und das OCF2A-Flag gelöscht.
Das heisst, es wird genau genommen nicht gelöscht, sondern es wird ein internes Bit gesetzt, daß mit dem nächsten Takt in das TIFR2- Register geschrieben wird. Der nächste Takt
ist aber der nächste Takt des 32,768KHz Timers. Erst nach diesem Takt wird das Flag tatsächlich gelöscht!

Läuft der Controller mit 8MHz, dauert es vom Auslösen des Interrupt und dem Vorbereiten des Löschens 8MHz / 32768Hz = 244 Takte, abzüglich der paar CPU-Takte, die bis jetzt vergangen sind,
bis das Flag gelöscht ist. Schafft der Controller es aber, die ISR in dieser Zeit abzuarbeiten, kehrt er zurück, stellt fest, daß das OCF2A-Flag immer noch gesetzt ist und springt wieder in die ISR,
um dieselbe Sekunde nochmal zu zählen. Wenn er das auch noch ein drittes Mal schafft, dauert die Minute nur noch 20 Sekunden.

Beim Betrieb mit 1MHz sind es nur 31 Takte, die werden fast schon durch den Interrupt als solches erreicht. Daher läuft die Uhr meistens mit 1MHz richtig und mit 8MHz zu schnell.

Um jetzt kein Delay in die ISR einzufügen, kann man einen Schreibvorgang auf ein Timer-Register ausführen und im ASSR-Register abfragen, ob dieser Schreibvorgang erfolgt ist. Wenn dies der
Fall ist, sind auch alle anderen Timer-Register geschrieben. Vor allen Dingen ist das OCF2A-Flag gelöscht.

Dafür dienen diese beiden Zeilen im Beispiel oben:
TCCR2B = TCCR2B; //Dummy Write
// Warten bis Write erfolgt ist
while(ASSR & ((1<<TCN2UB) | (1<<OCR2AUB) | (1<<OCR2BUB) |
(1<<TCR2AUB) | (1<<TCR2BUB)));

=== Kalibrieren des internen Oszillators mit Timer2 als Zeitbasis ===

Bei den Atmega48..328 sowie Atmega8, auf den hier nicht weiter eingegangen wird, wird der Uhrenquarz an Stelle des "normalen" Quarzes eingesetzt.

Für Datenübertragung über UART steht daher nur der Takt des internen Oszillators zur Verfügung. Eine Übertragung bis zu 9600 Bit/s ist mit den Atmega48..328 weitestgehend möglich. Dies ist jedoch nicht ideal und immer mit einem Risiko behaftet. Eine einfache Möglichkeit, Datenübertragung sicher und auch erheblich schneller zu machen, ist die Kalibrierung des internen Oszillators auf eine Baudratenfrequenz. Damit sind auch 115K2 Bit/s problemlos möglich.

Der interne Oszillator der Atmega48..328 wird vom Hersteller bei Vcc = 3V und einer Temperatur von 25°C auf 8MHz kalibriert. Dazu wird ein entsprechender Wert in das OSCCAL-Register des Controllers geschrieben.
Dieser Wert lässt sich u.a. mit dem AVRISPMKII auslesen. Die im Datenblatt angegebene Toleranz (+-10%) bezieht sich auf den gesamten zulässigen Temperatur- und Spannungsbereich des Controllers. Bei 3V/25° ist die Abweichung vom Sollwert <1%. Dieser Wert wird auch mit der hier vorgestellten Kalibrierung erreicht.

Zur Kalibrierung gibt der Timer2 ein Zeitintervall vor, in dem der Timer1 zählt. Bei richtiger Frequenz muß der Wert des TCNT1 annähernd dem errechneten Sollwert entsprechen. Ist der Wert grösser, läuft der Timer zu schnell, d.h. die Frequenz des Oszillators ist zu hoch, ist der Wert kleiner, ist die Oszillatorfrequenz zu niedrig. Entsprechend wird der Inhalt des OSCCAL-Registers dann inkrementiert oder dekrementiert.

Im Projekt ist die Sollfrequenz als F_CPU einzustellen. Bei gesetzter CKDIV8-Fuse sind dies 921600Hz, ohne CKDIV8 7372800Hz. In beiden Fällen wird der Oszillator tatsächlich auf 7,3728MHz kalibriert, da die niedrige Frequenz über einen Teiler generiert wird. Gemäss Datenblatt wird als Frequenzbereich für die Kalibrierung 7,3 - 8,1 Mhz empfohlen. Laut Atmel ist nur in diesem Bereich der Schreibzugriff auf das Flash und das EEPROM sicher. Das ist insbesondere dann von Bedeutung, wenn die Kalibrierung in einem und für einen Bootloader erfolgt.

<syntaxhighlight lang="c">
/* uC: ATMega48PA */

#ifndef F_CPU
#error F_CPU not defined.
#endif
#define REF_CLOCK 32768L
#if F_CPU == 921600
#define COUNT_PRE (1 << CS10)
#define COUNT_PREDIV 1
#else
#if F_CPU == 7372800
#define COUNT_PRE (1 << CS11)
#define COUNT_PREDIV 8
#else
#error "No Baudrate Frequency defined"
#endif
#endif
#define REF_VAL F_CPU / (REF_CLOCK / 256) / COUNT_PREDIV
#define REF_MIN REF_VAL - 50
#define REF_MAX REF_VAL + 10

GPIOR0 = OSCCAL;
unsigned char nTimeOut = 1;
//Timer anhalten, Prescaler Reset
GTCCR |= (1 << TSM) | (1 << PSRASY);
ASSR = (1 << AS2);
TCCR2B = (1 << CS20);
GTCCR &= ~(1 << TSM);//Timer starten
while(!(TIFR2 & (1 << TOV2)));
//Clear Interrupt Flags
TIFR2 = (1 << OCF2B) | (1 << OCF2A) | (1 << TOV2);
TCCR1B = COUNT_PRE;

while(nTimeOut)
{
if(TIFR2 & (1 << TOV2))//Poll Timer2
{
//Stop Timer1, Prescaler Reset
GTCCR = (1 << TSM) | (1 << PSRSYNC);//*
TIFR2 = (1 << OCF2B) | (1 << OCF2A) | (1 << TOV2);
unsigned int nTcnt1 = TCNT1;

if(!(nTimeOut & (1 << 0)))
{
if((nTcnt1 >= REF_MIN) && (nTcnt1 <= REF_MAX)) break;
else
{
if(nTcnt1 < REF_VAL) OSCCAL++;
if(nTcnt1 > REF_VAL) OSCCAL--;
}
TCNT1 = 0;
}
else GTCCR = 0;//Start Timer1 *
nTimeOut++;
}
}
if(!nTimeOut)
{
//Error, Kalibrierung abgebrochen
}
//Register wiederherstellen (Reset-Zustand)
ASSR = 0;
TCCR2B = 0;
TCCR1B = 0;
TCNT2 = 0;
OSCCAL = GPIOR0; //ggf. zurück setzen auf 8Mhz
GPIOR0 = 0;
// Clear Interrupt Flags
TIFR1 = (1 << ICF1) | (1 << OCF1B) | (1 << OCF1A) | (1 << TOV1);
//Start Timer1
GTCCR = 0;
</syntaxhighlight>
Die Messung erfolgt bei beiden Frequenzen mit einem Takt von 1MHz bis 921,6KHz für Timer1. Entweder durch CLKDIV8 (F_Timer = F_CPU) oder durch Prescaler = 8 des Timers (F_Timer = F_CPU/8). Dadurch ergeben sich bei der Kalibrierung die selben Parameter für beide Frequenzen.

Wird F_CPU auf 7,3728Mhz kalibriert, wird Timer1 mit Prescaler = 8 getaktet. Dieser muß vor der Messung zurück gesetzt werden, da der 1. Timertakt sonst zufällig nach 1 bis 8 CPU-Takten auftritt. Für die Genauigkeit der Messung muß dieser aber immer nach 8 Takten auftreten. Ansonsten kann das soweit führen, daß der Sollwert gar nicht erreicht wird und die Kalibrierung mit Timeout abgebrochen wird.

Die Kalibrierung war erfolgreich, wenn nTimeOut > 0 ist.

Das Wiederherstellen der verwendeten Register in den Reset-Zustand ist nur bei einem Bootloader wichtig. In einer normalen Anwendung ist es Sache des Programmierers, die veränderten Register entsprechend zu berücksichtigen und beispielsweise die Initialisierung der beiden Timer für eine andere Verwendung im Programm mit fester Zuweisung (=) statt mit Veroderung (|=) vorzunehmen. GTCCR ist in jedem Fall auf 0 zu setzen, da sowohl Timer0 als auch Timer1 beim Verlassen der Kalibrierung "stehen". Auch die Interrupt-Flags von Timer1 sollten gelöscht werden.

Die Kalibrierung verwendet keine Interrupts sondern pollt nur das TOV2-Flag des Timer2. Die Flags des Timer2 werden in der Kalibrierungsschleife direkt nach der Abfrage gelöscht.

Sollte die Kalibrierung in einem Bootlaoder erfolgen, kann man den ermittelten OSCCAL-Wert, sofern der ursprüngliche Wert (1 oder 8 MHz)wiederhergestellt wurde, in einem der GPIORx-Register an die Anwendung übergeben. Dann braucht diese eine evtl. notwendige Kalibrierung nur durchführen, wenn sie ohne Bootloader gestartet wurde. Ansonsten kann der Wert aus GPIORx ins OSCCAL geschrieben werden. Die GPIORx-Register werden (bislang) vom GCC nicht angetastet.

== Gemeinsame Register ==

Verschiedene Register beinhalten Zustände und Einstellungen, welche sowohl
für den 8-Bit, als auch für den 16-Bit Timer/Counter in ein und demselben
Register zu finden sind.

Dies gilt für viele ATTiny und die älteren ATMega, wie z.B. Atmega8.
Die neueren ATMegas und einige ATTiny haben bei einigen mit Ausnahme des GIMSK sowie dem korrespondierenden GIFR exklusive Register für jeden Timer.

{| class="wikitable"
|-
| width="100" | '''TIMSK'''
| '''T'''imer/Counter '''I'''nterrupt '''M'''a'''sk'''
Register

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''TOIE1'''|| '''OCIE1A'''|| '''-'''|| '''-'''|| '''TICIE'''|| '''-'''|| '''TOIE0'''|| '''-'''
|-
! R/W
| R/W || R/W || R || R || R/W || R || R/W || R
|-
! Initialwert
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0
|}

'''TOIE1''' ('''T'''imer/Counter '''O'''verflow '''I'''nterrupt '''E'''nable Timer/Counter '''1''')
:Wenn dieses Bit gesetzt ist, wird bei einem Überlauf des Datenregisters des Timer/Counter 1 ein Timer Overflow 1 Interrupt ausgelöst. Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.

'''OCIE1A''' ('''O'''utput '''C'''ompare Match '''I'''nterrupt '''E'''nable Timer/Counter '''1''')
:Beim Timer/Counter 1 kann zusätzlich zum Überlauf ein Vergleichswert definiert werden.

:Wenn dieses Bit gesetzt ist, wird beim Erreichen des Vergleichswertes ein Compare Match Interrupt ausgelöst. Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.

'''TICIE''' ('''T'''imer/Counter '''I'''nput '''C'''apture '''I'''nterrupt '''E'''nable)
:Wenn dieses Bit gesetzt ist, wird ein Capture Event Interrupt ausgelöst, wenn ein entsprechendes Signalereignis am Pin PD6(ICP) auftritt. Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein, wenn auch ein entsprechender Interrupt ausgelöst werden soll.

'''TOIE0''' ('''T'''imer/Counter '''O'''verflow '''I'''nterrupt '''E'''nable Timer/Counter '''0''')
:Wenn dieses Bit gesetzt ist, wird bei einem Überlauf des Datenregisters des Timer/Counter 0 ein Timer Overflow 0 Interrupt ausgelöst. Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.

|-
| '''TIFR'''
| '''T'''imer/Counter '''I'''nterrupt '''F'''lag '''R'''egister

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''TOV1'''|| '''OCF1A'''|| '''-'''|| '''-'''|| '''ICF1'''|| '''-'''|| '''TOV0'''|| '''-'''
|-
! R/W
| R/W|| R/W|| R|| R|| R/W|| R|| R/W|| R
|-
! Initialwert
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0
|}

'''TOV1''' ('''T'''imer/Counter '''O'''verflow Flag Timer/Counter '''1''')
:Dieses Bit wird vom Controller gesetzt, wenn beim Timer 1 ein Überlauf des Datenregisters stattfindet.

:In der PWM-Betriebsart wird das Bit gesetzt, wenn die Zählrichtung von auf- zu abwärts und umgekehrt geändert wird (Zählerwert = 0).

:Das Flag wird automatisch gelöscht, wenn der zugehörige Interrupt-Vektor aufgerufen wird. Es kann jedoch auch gelöscht werden, indem eine logische 1 (!) in das entsprechende Bit geschrieben wird.

'''OCF1A''' ('''O'''utput '''C'''ompare '''F'''lag Timer/Counter '''1''')
:Dieses Bit wird gesetzt, wenn der aktuelle Wert des Datenregisters von Timer/Counter 1 mit demjenigen im Vergleichsregister '''OCR1''' übereinstimmt.

:Das Flag wird automatisch gelöscht, wenn der zugehörige Interrupt-Vektor aufgerufen wird. Es kann jedoch auch gelöscht werden, indem eine logische 1 (!) in das entsprechende Bit geschrieben wird.

'''ICF1''' ('''I'''nput '''C'''apture '''F'''lag Timer/Counter '''1''')
:Dieses Bit wird gesetzt, wenn ein Capture-Ereignis aufgetreten ist, welches anzeigt, dass der Wert des Datenregisters des Timer/Counter 1 in das Input Capture Register ICR1 übertragen wurde.

:Das Flag wird automatisch gelöscht, wenn der zugehörige Interrupt-Vektor aufgerufen wird. Es kann jedoch auch gelöscht werden, indem eine logische 1 (!) in das entsprechende Bit geschrieben wird.

'''TOV0''' ('''T'''imer/Counter '''O'''verflow Flag Timer/Counter '''0''')
:Dieses Bit wird vom Controller gesetzt, wenn beim Timer 0 ein Überlauf des Datenregisters stattfindet.

:Das Flag wird automatisch gelöscht, wenn der zugehörige Interrupt-Vektor aufgerufen wird. Es kann jedoch auch gelöscht werden, indem eine logische 1 (!) in das entsprechende Bit geschrieben wird.
|}

[[Kategorie:avr-gcc Tutorial]]
[[Kategorie:Timer und Uhren]]

Kühlkörper

2016-03-18T01:07:40Z

8023:

Labornetzgeräte

2016-03-18T01:07:16Z

8023:

Scheduler mit Erweiterung zum Mini-Betriebssystem

2016-03-17T05:49:28Z

8023:

<big> '''Vorwort'''</big>: 
Dieser Artikel behandelt die Erstellung eines Schedulers, der zu einem Mini-OS erweitert wird. Ziel ist es, das Verständnis sowie die Funktion eines OS besser verstehen zu können. Wie so manch ein anderer habe auch ich mich gefragt, wie ein Betriebssystem eigentlich funktioniert, und - weil Nachbauen eine der besten Möglichkeit ist etwas zu verstehen - habe mir mein eigenes kleines System geschrieben. Es geht nicht darum ein „Suppa-Duppa“ OS zu schreiben, sondern zu verstehen wie größere (RTOS->Linux->Windows) funktionieren. 
Von: Sebastian Balz 

{{Warnung |
'''Warnung'''
 
Es werden gute Kenntnisse in C und Assembler, sowie gute Kenntnisse der CPU benötigt. Des Weiteren ersetzt ein selbst geschriebenes OS keinesfalls ein herkömmliches OS (RTOS …), da diese zuverlässiger und effizienter laufen und mehr Funktionen haben.

}} 
Alle Beispiele beziehen sich auf einen ARM-Cortex-M4 (SAM4SD32C), sollten jedoch auf alle gängigen µC portiert werden können. Um den Kontext-Switch zu vereinfachen werden keine Gleitkomma Berechnungen unterstützt. 
 

= Voraussetzungen =
 
* Gute C und Assembler Kenntnisse
* Gute Kenntnisse des UC‘s
* Viel Zeit und Motivation :)
 

= Zielsetzung=
 
Das beschriebene System soll in der Lage sein:
* Zwischen verschiedenen Aufgaben (Tasks) zu wechseln(Context-Switch). D.h. jeder Task hat das Gefühl, dass der UC ihm gehört.
* Fähigkeit der Task’s sich selber zu beenden oder zu pausieren, um so CPU-Ressourcen zu sparen.
* Keinerlei Auswirkung aufs Interrupt Handling.
* Ein Zeit Management
* Tasks und Threads mit Return-Wert und Kill
* Kommunikation zwischen den Tasks mit Schreib-Kontrolle

 

= Grundlagen =

Die Hauptaufgabe des Systems ist es, zwischen den verschiedenen Tasks wechseln zu können.
Um dies realisieren zu können, muss man erst einmal verstehen, wie überhaupt ein Kontext ausschaut.

 

== Register==
Register sind die Speicherzellen, die direkt mit der CPU verbunden sind. Sie haben die besten Lese- und Schreibraten, sind jedoch „teuer“, weshalb in einer CPU nur relativ wenige Register vorhanden sind.
In der ARM-Cortex-M4 Serie sind es 12 sog. „General-Purpose Register“ und ein paar Spezial-Register.

 

[[Datei:Register Balz.PNG|900px]] 

Quelle: Datenblatt Register
 

== Stack ==

Der Stack ist ein LIFO (Last in, First out), d.h. der zuletzt hinzugefügte Wert wird als erstes wieder ausgelesen. Über Push (Speicher) und POP (Laden) kann man Register-Inhalte auf den Stack speichern und laden.
Des Weiteren gibt es einen Stack-Pointer. Dieser zeigt immer auf die letzte Adresse im Stack.
Der Stack baut sich von einer Speicherzelle aus nach unten auf. D.h., wenn ein Wert auf den Stack geschrieben wird, verringert sich die Stack-Adresse.

Jedes Programm schreibt und erstellt seine lokalen Variablen auf dem Stack (RAM). Bei einem Funktionsaufruf werden Übergabeparameter und die Rücksprungadresse im Stack hinterlegt.
Die aufgerufene Funktion des Speichers (Push) hat also so viele Register auf dem Stack, wie sie selber Register benötigt, damit beim „Return“ wieder die Start-Register vom Stack geholt (POP) werden können und damit der „vor-Funktion-Zustand“ wieder hergestellt ist.

 

== Exception Call ==
Wird eine Funktion durch einen Interrupt unterbrochen, werden R0-R3,R12, LR, PC und xPSR (eine Verbindung aus “Interrupt Program Status Register“, “Application Program Status Register“, „Program Status Register“ und „Execution Program Status Register“) auf den Stack gepusht.
[[Datei:Stack Balz.PNG]] 

Quelle Datenblatt: Interrupt Stack 
Der µC schreibt beim “Interrupt entry“ eine EXC_Return_Value ins Link um zu signalisieren, dass gerade eine Interrupt-Routine aktiv ist. 
 

[[Datei:EXC Return Balz.PNG |700px]] 

Quelle: Datenblatt Exc_Return 
 
Beim Verlassen des ISRs müssen nun nur noch die Register R0-R3, LR,SP und die Status-Register wieder hergestellt werden. 
 

= Context-Switch =

== Theorie==
Um nun den aktuellen Kontext zu wechseln, müssen in einem Interrupt sämtliche Register gespeichert werden (PUSH R0-R12) und der Stack-Pointer auf den Stack des neuen Task‘s verschoben werden. Nun können die Register wieder hergestellt werden (POP R0-R12). Das Link-Register kann hier außer Acht gelassen werden, da es immer den Wert 0xFFFFFF9 (Return to Thread mode without floating point calculation) hat.
Wenn man nun das ISR von außen betrachtet, darf man keinen Unterschied zum letzten Speicherzeitpunkt feststellen.

 
[[Datei:Move Stack Balz.jpg]]

== Praxis ==
=== Speicher ===
Die Praxis ist leider etwas komplizierter: Zunächst einmal muss der Task-Stack im Speicher reserviert werden. Hierfür kann entweder malloc() verwendet werden - um dynamisch zur Laufzeit den Speicher zu reservieren - oder man „belegt“ den Speicher über Arrays. Da ein Stack-Overflow mit, dass Schlimmste ist, was unserem System passieren kann (Überschreibung der anderen Stacks/globalen Variablen), sollte die Größe des Stacks eher großzügig definiert sein. 

=== Stackerzeugen===
Da ein Stack sich von oben nach unten (aus Sicht des Speichers) aufbaut, muss der Stack-Pointer auf die Speicheradresse des letzten Array-Elementes zeigen.
Da beim Kontext-Switch der letzte Zustand wiederhergestellt wird, muss nun der Stack befüllt werden:

* Programm Counter: hier wird die Startadresse des Task‘s eingetragen
* Link–Register: Da die Task-Ansicht keine Funktion ist und im Normalfall nicht irgendwann verlassen wird, kann dieses Feld freigelassen werden. Alternativ kann auch auf die Adresse eines Dummy-Handlers verwiesen werden, der sich dann um die Beendigung des Tasks kümmert.
* Program Status Register: Im Status Register (xPSR) wird der Wert hinterlegt, der der CPU signalisiert, dass der aktuelle Programmabschnitt sich gerade in einem Interrupt befindet.
* Register 0-3,12 sind die Register, die vor einem Interrupt gesichert und nach dem Interrupt wieder hergestellt werden. Da der Task noch keine Registerwerte verwendet hat, können diese Zellen frei bleiben.

Wenn nun ein Kontext-Switch ausführt wird, wird man relativ schnell feststellen, dass etwas noch nicht passt.
Die Interrupt-Routine hat selber auch Variablen, die auf dem „alten“ Stack gespeichert und nach Verlassen des Stacks wieder vom Stack „gelöscht“ werden müssen. Diese müssen in dem neuen Stack berücksichtigt werden. Leider kann man hier keinen pauschalen Wert nennen, was dazu führt, dass jede Veränderung an der Interrupt-Routine Folgen haben kann. So muss z.B. bei dem neuem Stack die Anzahl der lokalen Register einbezogen werden.

=== Kontext wechseln ===
Nun, da der Speicher reserviert und der Stack aufgebaut worden ist, kann man den Kontext wechseln.
Hierfür müssen alle General-Purpose-Register auf den Stack gespeichert werden.
Da zu einem späteren Zeitpunkt der Stack wieder zurück gewechselt werden soll, muss nun der aktuelle Stack-Pointer gesichert werden, z.B. in der Task_List (siehe Task_Liste).
Der „alte“ Kontext ist nun gesichert, und so kann der „Neue“ geladen werden. Zunächst muss der Stack-Pointer umgezogen werden.
Um sicher zu stellen, dass der µC nun den neuen Stack auch verwendet, muss ein „Pipeline flush“ getätigt werden. Hierfür ist im TUMB2-Befehlssatz der Befehl „ISB“ (Instruction Synchronization Barrier) vorhanden, der direkt nach dem Stack-Pointer-Tausch ausgeführt werden sollte.
Nun können die Register 0-12 wieder hergestellt werden. Das Linkregister verändert sich nicht, da das Exc_return Value immer gleich ist.

Wird nun die Interrupt Routine verlassen, werden die lokalen Variablen vom Stack gelöscht und die ISR-Inhalte gePOP’t. Der Prozessor springt dann „zurück“ in den neuen Task.

==== BSP1 ====
Im folgenden Bild kann man gut sehen, wie zwei Tasks (weiße Kästen: PWM) abwechselnd aufgerufen werden. Dargestellt ist die Aktivität der Tasks als Funktion der Zeit; alle 50 ms wird in diesem Beispiel der Task gewechselt: 
 

[[Datei:Context Switch.JPG | 900px]]

 

== Task-Liste==
Damit das System weiß, wie viele und welche Tasks gerade ausgeführt werden, muss eine Liste erstellt werden, in der die jeweiligen IDs der Tasks enthalten sind, sowie:
* Stack-Pointer
* Stack Start Adresse
* Stack-Size
Optional kann in dieser Liste auch noch:
* Task Status/Message
* Thread Return_Value
enthalten sein.
=== Stack Pointer ===
Um bei einem Kontext Switch den alten Task wieder herzustellen, muss bekannt sein, an welcher Stelle im Speicher der Stack liegt.
 
=== Stack Start Adresse ===
Ist relevant, wenn überprüft werden soll, ob es einen Stack Overflow gab. Sollte es ein Stack-Overflow geben muss dies gemeldet und das System wieder auf den Ursprungszustand gesetzt werden.
 

=== Stack-Size ===
Wird in Verbindung mit der Stack_Start Adresse für die Overflow-Erkennung benötigt.
 
=== Task Status ===
Hier kann ein Task seinen Status mitteilen
* IDLE
* Started(läuft der Task gerade?)
* Oder soll der Stack des Task‘s aufgebaut werden
* Lese Fehler (siehe Speicher Management)

=== Return Value ===
wird ein Thread auf geplante Weise verlassen – (d.h. er beendet sich selber) –kann dieser auch ein Return_Value als Ergebnis hinterlegen. Hat der Thread z.B. die Aufgabe, eine Nutzereingabe zu erkennen und zu analysieren, so kann der erstellende Task (der die ID kennt) über das Ergebnis informiert werden.
 
== Zeitmanagement ==

=== System-Zeit ===
Oftmals kommt es vor, dass ein Task eine Tätigkeit alle x ms ausführen soll. Da jedoch die Tasks möglichst unabhängig sein sollen (sie wissen also nicht mit welcher Taktrate der Prozessor läuft), ist es sinnvoll, über eine RTT oder einen Timer/Counter die Zeit mitzuzählen und diese über eine Funktion allen Tasks und Threads zur Verfügung zu stellen.
Auch ist es sinnvoll, eine Funktion bereit zu stellen, die überprüft ob eine bestimmt Zeit vergangen ist; unter Berücksichtigung, dass die System-Zeit irgendwann wieder bei 0 anfängt.
Eine solche Funktion könnte wie folgt aussehen:

<syntaxhighlight lang="c">
int vergangene_zeit(int os_lasttime, int soll_time){
int time_know = get_os_time(); // hole die aktuelle Systhem Zeit
int delta;
if (zeit-lasttime <0) // hat ein System-Zeit Wraparound stattgefunden
{
zeit += os_max_time; // addiere Max SysthemZeit drauf
}
delta = zeit-lasttime;
return delta >= sollzeit;
}

</syntaxhighlight>
 

So kann ein Task einfach in einer <syntaxhighlight lang="c"> while(!(vergangene_zeit(lasttime,soll_time))){}</syntaxhighlight> darauf warten, dass die Soll Zeit abgelaufen ist.

 
=== Kontext-Switch ===
Natürlich ist es auch wichtig, dass der Kontext-Switch zentral gesteuert wird. Hier ist es empfehlenswert, den Real-Time-Timer oder einen Timer/Counter zu verwenden, der die Systemzeit managt. Über ein Static counter kann/soll eine bestimmte Anzahl an Zyklen bestimmt werden, bei denen der Kontext-Switch getriggert wird.
 

=== IDLE ===
Hat man mehrere Tasks die darauf warten, dass Zeit vergeht, wird viel Rechenleistung verbraucht, da die Tasks mit Nichtstun beschäftigt sind, während andere Tasks diese Rechenzeit gut brauchen könnten.
Um diesem Problem zu entgehen, sollte ein Task in der Lage sein, sich als inaktiv zu deklarieren. Dies könnte über einen Status-Bit geschehen, welches der Time_manager bei jedem Erhöhen der Systemzeit überprüft und den Kontext-Switch triggert.
Eine bessere Lösung wäre jedoch, zusätzlich zur IDLE Funktion einen Software Interrupt auszulösen, welcher den TC_Handler oder RTT_Handler des Zeitmanagements triggert.
So kann im Zeitmanagement geprüft werden, ob ein Task IDLE ist, oder ob der Interrupt auf herkömmliche Weise generiert worden ist.
Sollten ein Großteil oder alle Task IDLE sein, sollte die CPU in ein LOW-Power-Mode wechseln.

 

==== Beispiel 1====

Im folgenden Beispiel kann gut erkannt werden, wie sich Task1 zur Hälfte der möglichen Laufzeit als IDLE deklariert und einen Kontext-Switch triggert.

 
[[Datei:Task IDLE.JPG|900px]]
Saleae Logic Analyser: Task IDLE
 

= Tasks und Threads zur Laufzeit erstellen und beenden =

Eine weite Stärke eines solchen Systems ist es, dass dann ohne großen Aufwand einfach ein neuer Task oder Thread hinzugefügt werden kann.
Ein Thread hat eine feste Aufgabe die er erfüllen soll. Ist diese erfüllt, können weitere Ereignisse getriggert werden, oder der Thread kann beendet werden.

 

=== Starten ===
Hierfür muss lediglich ein neuer Stack mit Linkregister, Einsprung-Adresse etc. hinzugefügt werden und über die Task_Liste dem Zeitmanagement mitgeteilt werden, sodass es einen neuen Taskeintrag gibt, der gestartet werden soll.
==== Beispiel 2 ====

Hier kann gut erkannt werden, wie Thread 1 während der Laufzeit erstellt wird und von nun an vom Scheduler aufgerufen wird. Hierdurch werden jedoch Task1 und Task2 seltener aufgerufen.
 
[[Datei:Thread start.JPG |900px]] 
 

=== Beenden ===
Ein Thread kann auf zwei Arten beendet werden. Die reguläre Art ist, dass er sich selber schließt. Hierfür kann eine Funktion geschrieben werden, die der Task_Liste mitteilt, dass der Task beim nächsten Kontext-Switch nicht mehr aufgerufen werden soll. Optional kann in der Task_List ein Return Value hinterlegt werden, damit der Ersteller des Tasks z. B. ein Ergebnis erhält. Hierbei ist wichtig, zuerst den Return_value zu setzen bevor der Task als beendet definiert wird, da ansonsten ein ungünstiges Timing mit dem Kontext-Switch das Schreiben des Return_Values verhindert. Nachdem Return_value und der Task als beendet definiert worden sind, sollte der Task einen Task_IDLE an den Zeitmanager senden, um so den Task direkt zu verlassen und keine Rechenzeit zu vergeuden.
Auch ist es nötig, dass der Ersteller des Threads die ID des Threads in der Task_Liste erhält, da hinter der ID des Threads auch der Return_Value gespeichert wird.
Eine andere Art ein Thread zu beenden ist, ihn zu killen. Wenn z. B. die Ausführung des Threads nicht mehr relevant ist, weil das Ergebnis zu spät kommen würde (Real-Time-OS), oder die Ausführung des Threads nicht mehr benötigt wird, kann man einen Thread auch über die Task-Liste von außen beenden. Hierbei muss nur das Task_Active-Bit gelöscht werden.
 

==== Beispiel 3 ====
 
[[Datei:Thread closing.JPG|900px]]
 
Hier kann gut erkannt werden, wie Thread1 wieder geschlossen wird. Dadurch werden Task 1 und Task 2 wieder öfter aufgerufen. 

= Interrupte =
 
Eigentlich sollte es keinerlei Probleme bereiten, einen Interrupt auszuführen, da dieser den aktuellen Task nicht berührt.
Es muss lediglich auf zwei Punkte Rücksicht genommen werden:
* Der Zeitmanager muss in der niedrigsten Priorität laufen. Würde er mit einer höheren Priorität laufen während gerade ein anderer Interrupt aktiv ist, würden die gespeicherten Register in den falschen Stack abgelegt. Die wieder herzustellenden Register kämen aus einem Stack, in dem keine Register gesichert worden sind. Dieser Vorgang würde beide Stacks zerstören.
* Während des Kontext Switches dürfen keine anderen Interrupts aktiv werden, da es auch hier zu Problemen mit den Stacks kommen könnte.
Deshalb ist es empfehlenswert, den Zeitmanager in der niedrigsten Priorität laufen zu lassen und während der Ausführung andere Interrupts zu unterbinden.

 

= Erweiterung zum OS =
Von nun an sind die Übergänge zu einem Betriebssystem fließend.
 
== Priorisierung ==
in Arbeit!
 

==Speicher Management ==
Der erste Schritt in Richtung Betriebssystem ist ein Speicher-Management, welches in der Lage ist, Speicher zu reservieren und gegebenenfalls auch zu blockieren, sowie freizugeben. Hier kommt wieder – wie beim Stack-Aufbau - malloc() oder ein Array zum Einsatz. Der Einfachheit halber werden die einzelnen Speicher über ID’s angesprochen. Auch muss zentral geregelt werden, ob die jeweilige ID bereits in Verwendung ist.
 
=== Erstellen ===
Möchte ein Task oder Thread einen solchen Speicher erstellen, muss zunächst überprüft werden, ob noch Speicherplätze frei sind. In diesem Fall kann die ID der Speicherzelle zurückgegeben werden (return-Wert). Andernfalls sollte ein Error_Value zurück geliefert werden.
 
=== Freigeben ===
Um Speicher zu sparen, müssen Task und Threads in der Lage sein, den Speicher wieder frei zu geben. Sollte ein Task der beim Speicher durch einen Kontext –Switch unterbrochen worden ist, auf denselben Speicher zugreifen, sollte vor dem Freigeben überprüft werden, ob und warum der Speicher gesperrt worden ist.
 

=== Speichern ===
Um ein ungünstiges Timing zu verhindern (z. B. ein Prozess beschreibt eine Speicherzelle und wird während des Schreibvorganges durch einen Kontext-Switch unterbrochen), sollte nun der Speicher durch einen anderen Task wieder freigegeben werden. Hierzu muss vor dem Schreibvorgang signalisiert werden, dass die jeweilige Zelle blockiert ist. Als Return kann hier dann entweder ein Error_value oder ein Success_Value übertragen werden. 

=== Lesen ===
Zum Lesen muss lediglich überprüft werden, ob der Speicher der angegebenen ID reserviert ist. Als Return kann hier dann entweder der gespeicherte Wert oder ein Error_Value verwendet werden. Um zu erkennen ob es sich hier um einen Fehler handelt oder um einen gespeicherten Wert, kann über die Task_Liste (ID sollte bekannt sein!) ein Statusbit gesetzt werden. 
 

== Kommunikation mit anderen Task‘s ==
Oftmals ist es notwendig, dass die Tasks in der Lage sind, miteinander zu kommunizieren und so Ergebnisse auszutauschen. Hierfür kann ein weiterer Eintrag in der Task-Liste weiterhelfen, der einen anderen Task darüber informiert unter welcher Speicher-ID neue Informationen verfügbar sind. Die jeweiligen Tasks müssen dazu jedoch über die ID der jeweils anderen Task Bescheid wissen.
 

== Realtime ==
Je nach Anwendungsfall kann es wichtig sein, dass manche Threads innerhalb einer bestimmten Zeit ausgeführt werden müssen. Hierzu werden für die Threads Prioritäten vergeben, welche gewährleisten, dass die Threads länger oder häufiger ausgeführt werden (je nach Definition). Möglicherweise ergibt die Ausführung/Beendigung eines Threads auch nach einem bestimmten Zeitpunkt keinen Sinn mehr.
Beispiel: Ein Sensor soll alle 10 ms ausgelesen werden. Der Sensor liefert immer das aktuelle Messergebnis. Wird nun der Thread (der alle 10 ms getriggert wird um einen Sensor auszulesen) von einem wichtigeren Ereignis unterbrochen und so z. B. über 50ms verzögert, so warten dann 5 getriggerte Threads darauf, CPU Zeit zugewiesen zu bekommen. Da aber immer nur der aktuelle Sensorwert ausgegeben werden kann, liefern alle 5 Threads dasselbe Ergebnis. Um nun Ressourcen zu sparen, muss erkannt werden, ob die Ausführung dieses Threads noch sinnvoll ist. Andernfalls sollten die Threads beendet werden und es kann eine Fehlermeldung generiert werden.

 

= Fehlersuche und Kontrolle =
== Register Kontrolle ==
Zunächst ist es wichtig zu überprüfen, ob alle Variablen und Register denselben Wert wie nach einem Kontext Switch haben. Hier ist es empfehlenswert, beim Erstellen des Tasks lokale Variablen mit eindeutigen Werten zu erstellen und anschließend in einer while(1)-Schleife laufen zu lassen.
Die einfachste Überprüfung ist hier: Mit dem Debugger einen Breakpoint in der while(1)-Schleife des Programms zu setzen und nach dem Kontext-Switch anzuhalten, um auf diese Weise die Variablen zu überprüfen.

Mögliche Fehlerquellen:
* Stack Pointer zeigt auf die falsche Adresse
* Zuviele oder nicht ausreichend lokale Variablen -der ISR- nach Verlassen der ISR gelöscht
* Register in falscher Reihenfolge wiederhergestellt
'''Beispiel'''
<syntaxhighlight lang="c">
Void Test_Task1(){
Start_task();
int a = 3;
int b = 1;
int c = 2;
int d = 3;
int e = 4;
int f = 5;
int g = 6;
int h = 7;
while(1){
}
}
</syntaxhighlight>

 

== Rechenoperationen ==
Wenn sichergestellt wurde, dass die Register und Variablen nach einem Kontext Switch unverändert bestehen, kann mit einer einfachen Rechenoperation, die je nach Ausgangswert ein anderes Ergebnis liefert, überprüft werden, ob die Wiedereinsprungsadresse stimmt.
Da lokale Variablen zerstört werden können, sollten globale Variablen hierfür verwendet werden, da diese eben nicht im Stack gespeichert werden. Zusätzlich sollte ein Fehlercounter inkrementiert werden.

Mögliche Fehlerquellen:
* Falsches Link Register
* Falscher PC
* Fehlerhafte Register und/oder Variablen
'''Beispiel'''
Hier eignet sich die Berechnung der ersten Fibonacci-Zahlen, da hier jedes weitere Ergebnis vom Vorherigen abhängt.
<syntaxhighlight lang="c">
Int error;
Void Test_Task2(){
Start_Task();
int a = 1;
int b = 1;
int c;
int counter = 0;
while(1){
c = a;
a = b+a;
b = c;
switch(counter){
case 0:if(!(b==1)){
error++;
}break;
case 1:if(!(b==2)){
error++;}break;
case 2:if(!(b==3)){
error++;}break;
case 3:if(!(b==5)){
error++;}break;

...
...
...

default:counter = -1; b = 1; a = 1;break;
}
counter ++;
}
}

</syntaxhighlight>
 

== Funktionskaskade ==
Um zu überprüfen, ob Linkregister und Programmcounter richtig gesichert wurden, kann man via Funktionkaskaden überprüfen, ob alle Funktionen in der richtigen Reihenfolge aufgerufen werden, und ob sie auch wieder richtig verlassen werden. Auch wichtig sind Übergabeparameter und return values.
Sollte es hier zu einem Fehler kommen, kann es sein, dass nur die lokalen Variablen verloren gehen. Es kann jedoch auch passieren, dass nach dem Verlassen der Funktion zu viel oder zu wenig vom Stack geladen wird, wodurch eine falsche Rücksprungadresse geladen wird. Mit etwas Glück erkennt der µC dies und springt dann in einen Fault-Handler.
 

Möglichen Fehler Quellen:
* Link Register hatt die Falsche Adresse
* Fehlerhafte Register und/oder Variablen
* Falscher Programcounter
* Register 7 (kann von UC, Compiler oder IDE unterschiedlich sein) bei einem Funktions Call wird in einem Register der alte Stackpointer hinterlegt, ob zu zeigen, wie viele Lokale Variablen nach Verlassen der aktuellen Funktion auf dem Stack nicht mehr benötigt werden.

'''Beispiel'''
<syntaxhighlight lang="c">
int tester;
int error;
void Task_test3(){
while(1){
tester = 1;
int dummy = test1(5,6);

if(dummy != 9 || tester != 4){
error ++;
}
}
}

int test1(int a, int b){
if(tester != 1){
error++;
}
tester = 2;
int dummy = test2(7);
if(a != 5 || b != 6 || dummy != 8 || tester != 3){
error++;
}
tester = 4;
return 9;
}

int test2(int a)
{
if(a != 7 || tester != 2){
error ++;
}
tester = 3;
return 8;
}

</syntaxhighlight >
 

== Kein Kontext Switch mehr ==
Sollten plötzlich keine Kontext-Switche mehr stattfinden(ein Task wird nicht mehr verlassen) sollten man im Interrupt_Manager –„ Nested Vectored Interrupt Controller“ (NVIC) - nachschauen, ob das Interrupt_Active_Bit gesetzt ist. Sollte dies der Fall sein, wurde der Kontext-Switch nicht richtig verlassen und der Prozessor glaubt, er würde noch immer den Interrupt ausführen. Viele Prozessoren - unter anderem ARM - erlauben kein Repending(doppeltes Ausführen) eines Interruptes.
 
Mögliche Fehlerquellen:
* Linkregister: Bei einem Interrupt Aufruf wird das Link Register mit einem Exp_return_Value beschreiben. Dieser sagt aus, auf welche Art und ob nach Verlassen der Funktion das Interrupt abgeschlossen wurde. So weiss der UC, ob z.B. noch ein Interrupt mit einer niedrigeren Priorität unterbrochen wurde.

 

= Lektüre =
* µC/OS-III: The Real-Time Kernel https://www.micrium.com/books/ucosiii/
* http://infocenter.arm.com
* Datenblatt
* '''Grundlagen:''' https://www.mikrocontroller.net/articles/Multitasking
 

= Quellen =
* µC/OS-III: The Real-Time Kernel
* SAM4S-Datenblatt http://www.atmel.com/Images/Atmel-11100-32-bit%20Cortex-M4-Microcontroller-SAM4S_Datasheet.pdf

= Link Sammlung =
* https://www.mikrocontroller.net/topic/381051
* https://www.mikrocontroller.net/topic/389195?goto=4457089#4457089
 

= Autor =
Sebastian Balz
[[Kategorie:ARM]]
[[Kategorie:Betriebssysteme]]

Lehrvideos

2016-03-17T05:48:23Z

8023:

=Lehrvideos zu FPGA, VHDL, Verilog und Digital Design=
Hier ensteht eine Linkliste von Lehrvideos und Demos, die den Einstieg und Meisterschaft(?) im Design von digitalen Systemen erleichtern sollen. Die Videos sollen zeigen, wie man mit den Tools arbeitet.

Eine kurze Durchsicht bei youtube zeigt auf, dass nur ein kleiner Teil der Videos als Lehrvideo taugt, der Großteil sind Promotion-Videos, die hier nicht gelistet werden.

== VHDL and Xilinx Spartan FPGA 1/2 ==

* [http://www.youtube.com/watch?v=Bg_4nqSs2OY| VHDL and Xilinx Spartan FPGA 1/2] (Video privat, nicht einsehbar)
* [http://www.youtube.com/watch?v=SRsISGjRj-4| VHDL and Xilinx Spartan FPGA 2/2] (Video privat, nicht einsehbar)

Auf englisch kommentierte Demo die zeigt, wie man zu einem zugehörigen Blockbild den VHDL-Code schreibt und diesen synthetisiert. Gezeigt werden die Xilinxtools ISE, RTL-View, Core Generator.

== Einstieg mit Altera DE1 Board ==
*FPGA Tutorial 1. Blinking LEDs on DE1 Altera Board
[http://www.youtube.com/watch?v=T9VbBI3foGQ|Youtube-Video "FPGA Tutorial 1. Blinking LEDs on DE1 Altera Board"]
*FPGA Tutorial 2. Functions and procedures in VHDL on DE1 Altera Board
[http://www.youtube.com/watch?v=j2lAPIjpF1w|Youtube-Video "FPGA Tutorial 2. Functions and procedures in VHDL on DE1 Altera Board"]
*FPGA Tutorial 3. UART in VHDL on Altera DE1 Board
[http://www.youtube.com/watch?v=fMmcSpgOtJ4|Youtube-Video "FPGA Tutorial 3. UART in VHDL on Altera DE1 Board"]
*FPGA Tutorial 4: VGA interface in VHDL on DE1 Altera Board
[http://www.youtube.com/watch?v=mS0VZwnZssA|Youtube-Video "FPGA Tutorial 4: VGA interface in VHDL on DE1 Altera Board."]

== Introductory tutorial on Verilog ==
* [http://www.youtube.com/watch?NR=1&v=jkiHUaNIAKg| Introductory tutorial on Verilog] PowerPoint Vorlesung, einschläfernde Stimme, aber im Inhalt solide.
Erklärt werden die Beschreibungsformen (gatter, Verhalten, Prozeduraler Ansatz) und die Grundelemente register,wire,module.

== How to Setup Simulation in ModelSim ==
*[http://www.youtube.com/watch?v=VTMelKXXmho| Modelsim]
Dieser Englischsprachiger Screencast erklärt vornehmlich die GUI-basierte Bedienung des modelsim-Simulators, auf die script-steuerung wird kurz hingewiesen. Erklärt werden compile, compile-Order, Filestruktur, Fenstergruppierung. Leider wird kaum auf die Bedienung des wave-Fensters eingegangen.

==Statische Timing-Analyse==
*[http://www.youtube.com/watch?v=pEj6LR-C84Y| Lec-33 static timing analysis.wmv]
*[http://www.youtube.com/watch?v=mrY0MzCBgAo| Lec-34 static timing analysis]
Über zwei Stunden feinstes Indian English von Hold/Set-time zu clock-constrainst, false pathes und SDF. Hochschulvortrag mit handgezeichnetet Folien.

==Timing constraints - Xilinx==
*[http://www.youtube.com/watch?v=dRM0HVdqvZo&| Kapitel eins - Definition und Zweck von Timing constraints]
*[http://www.youtube.com/watch?v=38Px7CmGczo| Kapitel zwei - period, jitter, Offset]
*[http://www.youtube.com/watch?v=P3rQssXEFm8| Kapitel drei - Optionen, Eingabemöglichkeiten]
Offizielles Xilinx-Lehrmodul zu timing-constraints als PowerPoint-Vortrag. Das Video folgt der klassichen Lehrmethodik: Präsentation neues Wissens and anschliessende Vertiefung durch Beispiele und Frage/Antwort
Da die Basics der Timing-Constraints (kritischer Pfad, jitter, ...) für alle FPGA-Familien gleich sind, lohnt sich mindestens das erste Kapitel auch für Nutzer von Altera, Actel und andere.

== Programming/Bitstream download with Xilinx Impact ==
*[http://www.youtube.com/watch?v=gnSiwBn0djQ| Intro to FPGAs for Software Engineers - Part 5 - Programming, JTAG, PROMs, & iMPACT]
Dieser Screencast zeigt die Klicks und Eingaben um ein Board (FPGA,PROMS) mit JTAG-Schnittstelle über das Impact-tool der Xilinx-ISE zu programmieren. Perfekt lesbar an einem 1080 Monitor.

== How to use KCPSM3 in VHDL FPGA based project ==
* [http://www.youtube.com/watch?v=An3x5tKL5Js| How to use KCPSM3 in VHDL FPGA based project ]
Der KCPSM3 ist der Vorläufer der 8-Bit Soft-CPU Picoblaze von Xilinx. Das unkommentierte, aber mit Musik unterlegte Video zeigt wie im ISE Editor der VHDL-Code (Component-Instanziierung) hierfür erstellt wird. Einzelne Clicks in der Tooliste sind grafisch hervorgehoben. Der Text ist nicht sonderlich gut lesbar.

== Noch ohne abschliessende Bewertung ==

* [http://www.youtube.com/watch?v=Ob7B6x5g6tw FPGA Xilinx VHDL Video Tutorial]: Zeigt das Aufsetzen eines Projektes in der Xilinx-ISE.

* [http://www.youtube.com/watch?v=FxF0M3DA68Y Basic Schematic Input Tutorial] Xilinx-ISE, project from the scratch, fürchterlicher Ton

* [http://www.eejournal.com/design/fpga/on-demand] EEJournal Webcasts und Videos zum Thema FPGA and Programmable Logic Design

=== Vorlesungen Prof.S.Srinivasan , Madras, Indien ===
bspw.:
*[http://www.youtube.com/watch?v=RZQTTfU9TNA| Lecture 30 Encoders and Decoders]
Vorlesungsvideo, stark akzentgefärbtes Englisch, erklärt werden die Grundlagen des Digitaldesigns, EDA-Tools werden vorgestellt.

==Nicht empfohlen==

[[Kategorie:FPGA und Co]]

Labornetzgeräte

2016-03-17T05:47:46Z

8023:

Scheduler mit Erweiterung zum Mini-Betriebssystem

2016-03-17T05:46:59Z

8023:

<big> '''Vorwort'''</big>: 
Dieser Artikel behandelt die Erstellung eines Schedulers, der zu einem Mini-OS erweitert wird. Ziel ist es, das Verständnis sowie die Funktion eines OS besser verstehen zu können. Wie so manch ein anderer habe auch ich mich gefragt, wie ein Betriebssystem eigentlich funktioniert, und - weil Nachbauen eine der besten Möglichkeit ist etwas zu verstehen - habe mir mein eigenes kleines System geschrieben. Es geht nicht darum ein „Suppa-Duppa“ OS zu schreiben, sondern zu verstehen wie größere (RTOS->Linux->Windows) funktionieren. 
Von: Sebastian Balz 
 
Alle Beispiele beziehen sich auf einen ARM-Cortex-M4 (SAM4SD32C), sollten jedoch auf alle gängigen µC portiert werden können. Um den Kontext-Switch zu vereinfachen werden keine Gleitkomma Berechnungen unterstützt. 
 

= Voraussetzungen =
 
* Gute C und Assembler Kenntnisse
* Gute Kenntnisse des UC‘s
* Viel Zeit und Motivation :)
 

= Zielsetzung=
 
Das beschriebene System soll in der Lage sein:
* Zwischen verschiedenen Aufgaben (Tasks) zu wechseln(Context-Switch). D.h. jeder Task hat das Gefühl, dass der UC ihm gehört.
* Fähigkeit der Task’s sich selber zu beenden oder zu pausieren, um so CPU-Ressourcen zu sparen.
* Keinerlei Auswirkung aufs Interrupt Handling.
* Ein Zeit Management
* Tasks und Threads mit Return-Wert und Kill
* Kommunikation zwischen den Tasks mit Schreib-Kontrolle

 

= Grundlagen =

Die Hauptaufgabe des Systems ist es, zwischen den verschiedenen Tasks wechseln zu können.
Um dies realisieren zu können, muss man erst einmal verstehen, wie überhaupt ein Kontext ausschaut.

 

== Register==
Register sind die Speicherzellen, die direkt mit der CPU verbunden sind. Sie haben die besten Lese- und Schreibraten, sind jedoch „teuer“, weshalb in einer CPU nur relativ wenige Register vorhanden sind.
In der ARM-Cortex-M4 Serie sind es 12 sog. „General-Purpose Register“ und ein paar Spezial-Register.

 

[[Datei:Register Balz.PNG|900px]] 

Quelle: Datenblatt Register
 

== Stack ==

Der Stack ist ein LIFO (Last in, First out), d.h. der zuletzt hinzugefügte Wert wird als erstes wieder ausgelesen. Über Push (Speicher) und POP (Laden) kann man Register-Inhalte auf den Stack speichern und laden.
Des Weiteren gibt es einen Stack-Pointer. Dieser zeigt immer auf die letzte Adresse im Stack.
Der Stack baut sich von einer Speicherzelle aus nach unten auf. D.h., wenn ein Wert auf den Stack geschrieben wird, verringert sich die Stack-Adresse.

Jedes Programm schreibt und erstellt seine lokalen Variablen auf dem Stack (RAM). Bei einem Funktionsaufruf werden Übergabeparameter und die Rücksprungadresse im Stack hinterlegt.
Die aufgerufene Funktion des Speichers (Push) hat also so viele Register auf dem Stack, wie sie selber Register benötigt, damit beim „Return“ wieder die Start-Register vom Stack geholt (POP) werden können und damit der „vor-Funktion-Zustand“ wieder hergestellt ist.

 

== Exception Call ==
Wird eine Funktion durch einen Interrupt unterbrochen, werden R0-R3,R12, LR, PC und xPSR (eine Verbindung aus “Interrupt Program Status Register“, “Application Program Status Register“, „Program Status Register“ und „Execution Program Status Register“) auf den Stack gepusht.
[[Datei:Stack Balz.PNG]] 

Quelle Datenblatt: Interrupt Stack 
Der µC schreibt beim “Interrupt entry“ eine EXC_Return_Value ins Link um zu signalisieren, dass gerade eine Interrupt-Routine aktiv ist. 
 

[[Datei:EXC Return Balz.PNG |700px]] 

Quelle: Datenblatt Exc_Return 
 
Beim Verlassen des ISRs müssen nun nur noch die Register R0-R3, LR,SP und die Status-Register wieder hergestellt werden. 
 

= Context-Switch =

== Theorie==
Um nun den aktuellen Kontext zu wechseln, müssen in einem Interrupt sämtliche Register gespeichert werden (PUSH R0-R12) und der Stack-Pointer auf den Stack des neuen Task‘s verschoben werden. Nun können die Register wieder hergestellt werden (POP R0-R12). Das Link-Register kann hier außer Acht gelassen werden, da es immer den Wert 0xFFFFFF9 (Return to Thread mode without floating point calculation) hat.
Wenn man nun das ISR von außen betrachtet, darf man keinen Unterschied zum letzten Speicherzeitpunkt feststellen.

 
[[Datei:Move Stack Balz.jpg]]

== Praxis ==
=== Speicher ===
Die Praxis ist leider etwas komplizierter: Zunächst einmal muss der Task-Stack im Speicher reserviert werden. Hierfür kann entweder malloc() verwendet werden - um dynamisch zur Laufzeit den Speicher zu reservieren - oder man „belegt“ den Speicher über Arrays. Da ein Stack-Overflow mit, dass Schlimmste ist, was unserem System passieren kann (Überschreibung der anderen Stacks/globalen Variablen), sollte die Größe des Stacks eher großzügig definiert sein. 

=== Stackerzeugen===
Da ein Stack sich von oben nach unten (aus Sicht des Speichers) aufbaut, muss der Stack-Pointer auf die Speicheradresse des letzten Array-Elementes zeigen.
Da beim Kontext-Switch der letzte Zustand wiederhergestellt wird, muss nun der Stack befüllt werden:

* Programm Counter: hier wird die Startadresse des Task‘s eingetragen
* Link–Register: Da die Task-Ansicht keine Funktion ist und im Normalfall nicht irgendwann verlassen wird, kann dieses Feld freigelassen werden. Alternativ kann auch auf die Adresse eines Dummy-Handlers verwiesen werden, der sich dann um die Beendigung des Tasks kümmert.
* Program Status Register: Im Status Register (xPSR) wird der Wert hinterlegt, der der CPU signalisiert, dass der aktuelle Programmabschnitt sich gerade in einem Interrupt befindet.
* Register 0-3,12 sind die Register, die vor einem Interrupt gesichert und nach dem Interrupt wieder hergestellt werden. Da der Task noch keine Registerwerte verwendet hat, können diese Zellen frei bleiben.

Wenn nun ein Kontext-Switch ausführt wird, wird man relativ schnell feststellen, dass etwas noch nicht passt.
Die Interrupt-Routine hat selber auch Variablen, die auf dem „alten“ Stack gespeichert und nach Verlassen des Stacks wieder vom Stack „gelöscht“ werden müssen. Diese müssen in dem neuen Stack berücksichtigt werden. Leider kann man hier keinen pauschalen Wert nennen, was dazu führt, dass jede Veränderung an der Interrupt-Routine Folgen haben kann. So muss z.B. bei dem neuem Stack die Anzahl der lokalen Register einbezogen werden.

=== Kontext wechseln ===
Nun, da der Speicher reserviert und der Stack aufgebaut worden ist, kann man den Kontext wechseln.
Hierfür müssen alle General-Purpose-Register auf den Stack gespeichert werden.
Da zu einem späteren Zeitpunkt der Stack wieder zurück gewechselt werden soll, muss nun der aktuelle Stack-Pointer gesichert werden, z.B. in der Task_List (siehe Task_Liste).
Der „alte“ Kontext ist nun gesichert, und so kann der „Neue“ geladen werden. Zunächst muss der Stack-Pointer umgezogen werden.
Um sicher zu stellen, dass der µC nun den neuen Stack auch verwendet, muss ein „Pipeline flush“ getätigt werden. Hierfür ist im TUMB2-Befehlssatz der Befehl „ISB“ (Instruction Synchronization Barrier) vorhanden, der direkt nach dem Stack-Pointer-Tausch ausgeführt werden sollte.
Nun können die Register 0-12 wieder hergestellt werden. Das Linkregister verändert sich nicht, da das Exc_return Value immer gleich ist.

Wird nun die Interrupt Routine verlassen, werden die lokalen Variablen vom Stack gelöscht und die ISR-Inhalte gePOP’t. Der Prozessor springt dann „zurück“ in den neuen Task.

==== BSP1 ====
Im folgenden Bild kann man gut sehen, wie zwei Tasks (weiße Kästen: PWM) abwechselnd aufgerufen werden. Dargestellt ist die Aktivität der Tasks als Funktion der Zeit; alle 50 ms wird in diesem Beispiel der Task gewechselt: 
 

[[Datei:Context Switch.JPG | 900px]]

 

== Task-Liste==
Damit das System weiß, wie viele und welche Tasks gerade ausgeführt werden, muss eine Liste erstellt werden, in der die jeweiligen IDs der Tasks enthalten sind, sowie:
* Stack-Pointer
* Stack Start Adresse
* Stack-Size
Optional kann in dieser Liste auch noch:
* Task Status/Message
* Thread Return_Value
enthalten sein.
=== Stack Pointer ===
Um bei einem Kontext Switch den alten Task wieder herzustellen, muss bekannt sein, an welcher Stelle im Speicher der Stack liegt.
 
=== Stack Start Adresse ===
Ist relevant, wenn überprüft werden soll, ob es einen Stack Overflow gab. Sollte es ein Stack-Overflow geben muss dies gemeldet und das System wieder auf den Ursprungszustand gesetzt werden.
 

=== Stack-Size ===
Wird in Verbindung mit der Stack_Start Adresse für die Overflow-Erkennung benötigt.
 
=== Task Status ===
Hier kann ein Task seinen Status mitteilen
* IDLE
* Started(läuft der Task gerade?)
* Oder soll der Stack des Task‘s aufgebaut werden
* Lese Fehler (siehe Speicher Management)

=== Return Value ===
wird ein Thread auf geplante Weise verlassen – (d.h. er beendet sich selber) –kann dieser auch ein Return_Value als Ergebnis hinterlegen. Hat der Thread z.B. die Aufgabe, eine Nutzereingabe zu erkennen und zu analysieren, so kann der erstellende Task (der die ID kennt) über das Ergebnis informiert werden.
 
== Zeitmanagement ==

=== System-Zeit ===
Oftmals kommt es vor, dass ein Task eine Tätigkeit alle x ms ausführen soll. Da jedoch die Tasks möglichst unabhängig sein sollen (sie wissen also nicht mit welcher Taktrate der Prozessor läuft), ist es sinnvoll, über eine RTT oder einen Timer/Counter die Zeit mitzuzählen und diese über eine Funktion allen Tasks und Threads zur Verfügung zu stellen.
Auch ist es sinnvoll, eine Funktion bereit zu stellen, die überprüft ob eine bestimmt Zeit vergangen ist; unter Berücksichtigung, dass die System-Zeit irgendwann wieder bei 0 anfängt.
Eine solche Funktion könnte wie folgt aussehen:

<syntaxhighlight lang="c">
int vergangene_zeit(int os_lasttime, int soll_time){
int time_know = get_os_time(); // hole die aktuelle Systhem Zeit
int delta;
if (zeit-lasttime <0) // hat ein System-Zeit Wraparound stattgefunden
{
zeit += os_max_time; // addiere Max SysthemZeit drauf
}
delta = zeit-lasttime;
return delta >= sollzeit;
}

</syntaxhighlight>
 

So kann ein Task einfach in einer <syntaxhighlight lang="c"> while(!(vergangene_zeit(lasttime,soll_time))){}</syntaxhighlight> darauf warten, dass die Soll Zeit abgelaufen ist.

 
=== Kontext-Switch ===
Natürlich ist es auch wichtig, dass der Kontext-Switch zentral gesteuert wird. Hier ist es empfehlenswert, den Real-Time-Timer oder einen Timer/Counter zu verwenden, der die Systemzeit managt. Über ein Static counter kann/soll eine bestimmte Anzahl an Zyklen bestimmt werden, bei denen der Kontext-Switch getriggert wird.
 

=== IDLE ===
Hat man mehrere Tasks die darauf warten, dass Zeit vergeht, wird viel Rechenleistung verbraucht, da die Tasks mit Nichtstun beschäftigt sind, während andere Tasks diese Rechenzeit gut brauchen könnten.
Um diesem Problem zu entgehen, sollte ein Task in der Lage sein, sich als inaktiv zu deklarieren. Dies könnte über einen Status-Bit geschehen, welches der Time_manager bei jedem Erhöhen der Systemzeit überprüft und den Kontext-Switch triggert.
Eine bessere Lösung wäre jedoch, zusätzlich zur IDLE Funktion einen Software Interrupt auszulösen, welcher den TC_Handler oder RTT_Handler des Zeitmanagements triggert.
So kann im Zeitmanagement geprüft werden, ob ein Task IDLE ist, oder ob der Interrupt auf herkömmliche Weise generiert worden ist.
Sollten ein Großteil oder alle Task IDLE sein, sollte die CPU in ein LOW-Power-Mode wechseln.

 

==== Beispiel 1====

Im folgenden Beispiel kann gut erkannt werden, wie sich Task1 zur Hälfte der möglichen Laufzeit als IDLE deklariert und einen Kontext-Switch triggert.

 
[[Datei:Task IDLE.JPG|900px]]
Saleae Logic Analyser: Task IDLE
 

= Tasks und Threads zur Laufzeit erstellen und beenden =

Eine weite Stärke eines solchen Systems ist es, dass dann ohne großen Aufwand einfach ein neuer Task oder Thread hinzugefügt werden kann.
Ein Thread hat eine feste Aufgabe die er erfüllen soll. Ist diese erfüllt, können weitere Ereignisse getriggert werden, oder der Thread kann beendet werden.

 

=== Starten ===
Hierfür muss lediglich ein neuer Stack mit Linkregister, Einsprung-Adresse etc. hinzugefügt werden und über die Task_Liste dem Zeitmanagement mitgeteilt werden, sodass es einen neuen Taskeintrag gibt, der gestartet werden soll.
==== Beispiel 2 ====

Hier kann gut erkannt werden, wie Thread 1 während der Laufzeit erstellt wird und von nun an vom Scheduler aufgerufen wird. Hierdurch werden jedoch Task1 und Task2 seltener aufgerufen.
 
[[Datei:Thread start.JPG |900px]] 
 

=== Beenden ===
Ein Thread kann auf zwei Arten beendet werden. Die reguläre Art ist, dass er sich selber schließt. Hierfür kann eine Funktion geschrieben werden, die der Task_Liste mitteilt, dass der Task beim nächsten Kontext-Switch nicht mehr aufgerufen werden soll. Optional kann in der Task_List ein Return Value hinterlegt werden, damit der Ersteller des Tasks z. B. ein Ergebnis erhält. Hierbei ist wichtig, zuerst den Return_value zu setzen bevor der Task als beendet definiert wird, da ansonsten ein ungünstiges Timing mit dem Kontext-Switch das Schreiben des Return_Values verhindert. Nachdem Return_value und der Task als beendet definiert worden sind, sollte der Task einen Task_IDLE an den Zeitmanager senden, um so den Task direkt zu verlassen und keine Rechenzeit zu vergeuden.
Auch ist es nötig, dass der Ersteller des Threads die ID des Threads in der Task_Liste erhält, da hinter der ID des Threads auch der Return_Value gespeichert wird.
Eine andere Art ein Thread zu beenden ist, ihn zu killen. Wenn z. B. die Ausführung des Threads nicht mehr relevant ist, weil das Ergebnis zu spät kommen würde (Real-Time-OS), oder die Ausführung des Threads nicht mehr benötigt wird, kann man einen Thread auch über die Task-Liste von außen beenden. Hierbei muss nur das Task_Active-Bit gelöscht werden.
 

==== Beispiel 3 ====
 
[[Datei:Thread closing.JPG|900px]]
 
Hier kann gut erkannt werden, wie Thread1 wieder geschlossen wird. Dadurch werden Task 1 und Task 2 wieder öfter aufgerufen. 

= Interrupte =
 
Eigentlich sollte es keinerlei Probleme bereiten, einen Interrupt auszuführen, da dieser den aktuellen Task nicht berührt.
Es muss lediglich auf zwei Punkte Rücksicht genommen werden:
* Der Zeitmanager muss in der niedrigsten Priorität laufen. Würde er mit einer höheren Priorität laufen während gerade ein anderer Interrupt aktiv ist, würden die gespeicherten Register in den falschen Stack abgelegt. Die wieder herzustellenden Register kämen aus einem Stack, in dem keine Register gesichert worden sind. Dieser Vorgang würde beide Stacks zerstören.
* Während des Kontext Switches dürfen keine anderen Interrupts aktiv werden, da es auch hier zu Problemen mit den Stacks kommen könnte.
Deshalb ist es empfehlenswert, den Zeitmanager in der niedrigsten Priorität laufen zu lassen und während der Ausführung andere Interrupts zu unterbinden.

 

= Erweiterung zum OS =
Von nun an sind die Übergänge zu einem Betriebssystem fließend.
 
== Priorisierung ==
in Arbeit!
 

==Speicher Management ==
Der erste Schritt in Richtung Betriebssystem ist ein Speicher-Management, welches in der Lage ist, Speicher zu reservieren und gegebenenfalls auch zu blockieren, sowie freizugeben. Hier kommt wieder – wie beim Stack-Aufbau - malloc() oder ein Array zum Einsatz. Der Einfachheit halber werden die einzelnen Speicher über ID’s angesprochen. Auch muss zentral geregelt werden, ob die jeweilige ID bereits in Verwendung ist.
 
=== Erstellen ===
Möchte ein Task oder Thread einen solchen Speicher erstellen, muss zunächst überprüft werden, ob noch Speicherplätze frei sind. In diesem Fall kann die ID der Speicherzelle zurückgegeben werden (return-Wert). Andernfalls sollte ein Error_Value zurück geliefert werden.
 
=== Freigeben ===
Um Speicher zu sparen, müssen Task und Threads in der Lage sein, den Speicher wieder frei zu geben. Sollte ein Task der beim Speicher durch einen Kontext –Switch unterbrochen worden ist, auf denselben Speicher zugreifen, sollte vor dem Freigeben überprüft werden, ob und warum der Speicher gesperrt worden ist.
 

=== Speichern ===
Um ein ungünstiges Timing zu verhindern (z. B. ein Prozess beschreibt eine Speicherzelle und wird während des Schreibvorganges durch einen Kontext-Switch unterbrochen), sollte nun der Speicher durch einen anderen Task wieder freigegeben werden. Hierzu muss vor dem Schreibvorgang signalisiert werden, dass die jeweilige Zelle blockiert ist. Als Return kann hier dann entweder ein Error_value oder ein Success_Value übertragen werden. 

=== Lesen ===
Zum Lesen muss lediglich überprüft werden, ob der Speicher der angegebenen ID reserviert ist. Als Return kann hier dann entweder der gespeicherte Wert oder ein Error_Value verwendet werden. Um zu erkennen ob es sich hier um einen Fehler handelt oder um einen gespeicherten Wert, kann über die Task_Liste (ID sollte bekannt sein!) ein Statusbit gesetzt werden. 
 

== Kommunikation mit anderen Task‘s ==
Oftmals ist es notwendig, dass die Tasks in der Lage sind, miteinander zu kommunizieren und so Ergebnisse auszutauschen. Hierfür kann ein weiterer Eintrag in der Task-Liste weiterhelfen, der einen anderen Task darüber informiert unter welcher Speicher-ID neue Informationen verfügbar sind. Die jeweiligen Tasks müssen dazu jedoch über die ID der jeweils anderen Task Bescheid wissen.
 

== Realtime ==
Je nach Anwendungsfall kann es wichtig sein, dass manche Threads innerhalb einer bestimmten Zeit ausgeführt werden müssen. Hierzu werden für die Threads Prioritäten vergeben, welche gewährleisten, dass die Threads länger oder häufiger ausgeführt werden (je nach Definition). Möglicherweise ergibt die Ausführung/Beendigung eines Threads auch nach einem bestimmten Zeitpunkt keinen Sinn mehr.
Beispiel: Ein Sensor soll alle 10 ms ausgelesen werden. Der Sensor liefert immer das aktuelle Messergebnis. Wird nun der Thread (der alle 10 ms getriggert wird um einen Sensor auszulesen) von einem wichtigeren Ereignis unterbrochen und so z. B. über 50ms verzögert, so warten dann 5 getriggerte Threads darauf, CPU Zeit zugewiesen zu bekommen. Da aber immer nur der aktuelle Sensorwert ausgegeben werden kann, liefern alle 5 Threads dasselbe Ergebnis. Um nun Ressourcen zu sparen, muss erkannt werden, ob die Ausführung dieses Threads noch sinnvoll ist. Andernfalls sollten die Threads beendet werden und es kann eine Fehlermeldung generiert werden.

 

= Fehlersuche und Kontrolle =
== Register Kontrolle ==
Zunächst ist es wichtig zu überprüfen, ob alle Variablen und Register denselben Wert wie nach einem Kontext Switch haben. Hier ist es empfehlenswert, beim Erstellen des Tasks lokale Variablen mit eindeutigen Werten zu erstellen und anschließend in einer while(1)-Schleife laufen zu lassen.
Die einfachste Überprüfung ist hier: Mit dem Debugger einen Breakpoint in der while(1)-Schleife des Programms zu setzen und nach dem Kontext-Switch anzuhalten, um auf diese Weise die Variablen zu überprüfen.

Mögliche Fehlerquellen:
* Stack Pointer zeigt auf die falsche Adresse
* Zuviele oder nicht ausreichend lokale Variablen -der ISR- nach Verlassen der ISR gelöscht
* Register in falscher Reihenfolge wiederhergestellt
'''Beispiel'''
<syntaxhighlight lang="c">
Void Test_Task1(){
Start_task();
int a = 3;
int b = 1;
int c = 2;
int d = 3;
int e = 4;
int f = 5;
int g = 6;
int h = 7;
while(1){
}
}
</syntaxhighlight>

 

== Rechenoperationen ==
Wenn sichergestellt wurde, dass die Register und Variablen nach einem Kontext Switch unverändert bestehen, kann mit einer einfachen Rechenoperation, die je nach Ausgangswert ein anderes Ergebnis liefert, überprüft werden, ob die Wiedereinsprungsadresse stimmt.
Da lokale Variablen zerstört werden können, sollten globale Variablen hierfür verwendet werden, da diese eben nicht im Stack gespeichert werden. Zusätzlich sollte ein Fehlercounter inkrementiert werden.

Mögliche Fehlerquellen:
* Falsches Link Register
* Falscher PC
* Fehlerhafte Register und/oder Variablen
'''Beispiel'''
Hier eignet sich die Berechnung der ersten Fibonacci-Zahlen, da hier jedes weitere Ergebnis vom Vorherigen abhängt.
<syntaxhighlight lang="c">
Int error;
Void Test_Task2(){
Start_Task();
int a = 1;
int b = 1;
int c;
int counter = 0;
while(1){
c = a;
a = b+a;
b = c;
switch(counter){
case 0:if(!(b==1)){
error++;
}break;
case 1:if(!(b==2)){
error++;}break;
case 2:if(!(b==3)){
error++;}break;
case 3:if(!(b==5)){
error++;}break;

...
...
...

default:counter = -1; b = 1; a = 1;break;
}
counter ++;
}
}

</syntaxhighlight>
 

== Funktionskaskade ==
Um zu überprüfen, ob Linkregister und Programmcounter richtig gesichert wurden, kann man via Funktionkaskaden überprüfen, ob alle Funktionen in der richtigen Reihenfolge aufgerufen werden, und ob sie auch wieder richtig verlassen werden. Auch wichtig sind Übergabeparameter und return values.
Sollte es hier zu einem Fehler kommen, kann es sein, dass nur die lokalen Variablen verloren gehen. Es kann jedoch auch passieren, dass nach dem Verlassen der Funktion zu viel oder zu wenig vom Stack geladen wird, wodurch eine falsche Rücksprungadresse geladen wird. Mit etwas Glück erkennt der µC dies und springt dann in einen Fault-Handler.
 

Möglichen Fehler Quellen:
* Link Register hatt die Falsche Adresse
* Fehlerhafte Register und/oder Variablen
* Falscher Programcounter
* Register 7 (kann von UC, Compiler oder IDE unterschiedlich sein) bei einem Funktions Call wird in einem Register der alte Stackpointer hinterlegt, ob zu zeigen, wie viele Lokale Variablen nach Verlassen der aktuellen Funktion auf dem Stack nicht mehr benötigt werden.

'''Beispiel'''
<syntaxhighlight lang="c">
int tester;
int error;
void Task_test3(){
while(1){
tester = 1;
int dummy = test1(5,6);

if(dummy != 9 || tester != 4){
error ++;
}
}
}

int test1(int a, int b){
if(tester != 1){
error++;
}
tester = 2;
int dummy = test2(7);
if(a != 5 || b != 6 || dummy != 8 || tester != 3){
error++;
}
tester = 4;
return 9;
}

int test2(int a)
{
if(a != 7 || tester != 2){
error ++;
}
tester = 3;
return 8;
}

</syntaxhighlight >
 

== Kein Kontext Switch mehr ==
Sollten plötzlich keine Kontext-Switche mehr stattfinden(ein Task wird nicht mehr verlassen) sollten man im Interrupt_Manager –„ Nested Vectored Interrupt Controller“ (NVIC) - nachschauen, ob das Interrupt_Active_Bit gesetzt ist. Sollte dies der Fall sein, wurde der Kontext-Switch nicht richtig verlassen und der Prozessor glaubt, er würde noch immer den Interrupt ausführen. Viele Prozessoren - unter anderem ARM - erlauben kein Repending(doppeltes Ausführen) eines Interruptes.
 
Mögliche Fehlerquellen:
* Linkregister: Bei einem Interrupt Aufruf wird das Link Register mit einem Exp_return_Value beschreiben. Dieser sagt aus, auf welche Art und ob nach Verlassen der Funktion das Interrupt abgeschlossen wurde. So weiss der UC, ob z.B. noch ein Interrupt mit einer niedrigeren Priorität unterbrochen wurde.

 

= Lektüre =
* µC/OS-III: The Real-Time Kernel https://www.micrium.com/books/ucosiii/
* http://infocenter.arm.com
* Datenblatt
* '''Grundlagen:''' https://www.mikrocontroller.net/articles/Multitasking
 

= Quellen =
* µC/OS-III: The Real-Time Kernel
* SAM4S-Datenblatt http://www.atmel.com/Images/Atmel-11100-32-bit%20Cortex-M4-Microcontroller-SAM4S_Datasheet.pdf

= Link Sammlung =
* https://www.mikrocontroller.net/topic/381051
* https://www.mikrocontroller.net/topic/389195?goto=4457089#4457089
 

= Autor =
Sebastian Balz
[[Kategorie:ARM]]
[[Kategorie:Betriebssysteme]]

Scheduler mit Erweiterung zum Mini-Betriebssystem

2016-03-17T05:46:13Z

8023:

<big> '''Vorwort'''</big>: 
Dieser Artikel behandelt die Erstellung eines Schedulers, der zu einem Mini-OS erweitert wird. Ziel ist es, das Verständnis sowie die Funktion eines OS besser verstehen zu können. Wie so manch ein anderer habe auch ich mich gefragt, wie ein Betriebssystem eigentlich funktioniert, und - weil Nachbauen eine der besten Möglichkeit ist etwas zu verstehen - habe mir mein eigenes kleines System geschrieben. Es geht nicht darum ein „Suppa-Duppa“ OS zu schreiben, sondern zu verstehen wie größere (RTOS->Linux->Windows) funktionieren. 
Von: Sebastian Balz 

}} 
Alle Beispiele beziehen sich auf einen ARM-Cortex-M4 (SAM4SD32C), sollten jedoch auf alle gängigen µC portiert werden können. Um den Kontext-Switch zu vereinfachen werden keine Gleitkomma Berechnungen unterstützt. 
 

= Voraussetzungen =
 
* Gute C und Assembler Kenntnisse
* Gute Kenntnisse des UC‘s
* Viel Zeit und Motivation :)
 

= Zielsetzung=
 
Das beschriebene System soll in der Lage sein:
* Zwischen verschiedenen Aufgaben (Tasks) zu wechseln(Context-Switch). D.h. jeder Task hat das Gefühl, dass der UC ihm gehört.
* Fähigkeit der Task’s sich selber zu beenden oder zu pausieren, um so CPU-Ressourcen zu sparen.
* Keinerlei Auswirkung aufs Interrupt Handling.
* Ein Zeit Management
* Tasks und Threads mit Return-Wert und Kill
* Kommunikation zwischen den Tasks mit Schreib-Kontrolle

 

= Grundlagen =

Die Hauptaufgabe des Systems ist es, zwischen den verschiedenen Tasks wechseln zu können.
Um dies realisieren zu können, muss man erst einmal verstehen, wie überhaupt ein Kontext ausschaut.

 

== Register==
Register sind die Speicherzellen, die direkt mit der CPU verbunden sind. Sie haben die besten Lese- und Schreibraten, sind jedoch „teuer“, weshalb in einer CPU nur relativ wenige Register vorhanden sind.
In der ARM-Cortex-M4 Serie sind es 12 sog. „General-Purpose Register“ und ein paar Spezial-Register.

 

[[Datei:Register Balz.PNG|900px]] 

Quelle: Datenblatt Register
 

== Stack ==

Der Stack ist ein LIFO (Last in, First out), d.h. der zuletzt hinzugefügte Wert wird als erstes wieder ausgelesen. Über Push (Speicher) und POP (Laden) kann man Register-Inhalte auf den Stack speichern und laden.
Des Weiteren gibt es einen Stack-Pointer. Dieser zeigt immer auf die letzte Adresse im Stack.
Der Stack baut sich von einer Speicherzelle aus nach unten auf. D.h., wenn ein Wert auf den Stack geschrieben wird, verringert sich die Stack-Adresse.

Jedes Programm schreibt und erstellt seine lokalen Variablen auf dem Stack (RAM). Bei einem Funktionsaufruf werden Übergabeparameter und die Rücksprungadresse im Stack hinterlegt.
Die aufgerufene Funktion des Speichers (Push) hat also so viele Register auf dem Stack, wie sie selber Register benötigt, damit beim „Return“ wieder die Start-Register vom Stack geholt (POP) werden können und damit der „vor-Funktion-Zustand“ wieder hergestellt ist.

 

== Exception Call ==
Wird eine Funktion durch einen Interrupt unterbrochen, werden R0-R3,R12, LR, PC und xPSR (eine Verbindung aus “Interrupt Program Status Register“, “Application Program Status Register“, „Program Status Register“ und „Execution Program Status Register“) auf den Stack gepusht.
[[Datei:Stack Balz.PNG]] 

Quelle Datenblatt: Interrupt Stack 
Der µC schreibt beim “Interrupt entry“ eine EXC_Return_Value ins Link um zu signalisieren, dass gerade eine Interrupt-Routine aktiv ist. 
 

[[Datei:EXC Return Balz.PNG |700px]] 

Quelle: Datenblatt Exc_Return 
 
Beim Verlassen des ISRs müssen nun nur noch die Register R0-R3, LR,SP und die Status-Register wieder hergestellt werden. 
 

= Context-Switch =

== Theorie==
Um nun den aktuellen Kontext zu wechseln, müssen in einem Interrupt sämtliche Register gespeichert werden (PUSH R0-R12) und der Stack-Pointer auf den Stack des neuen Task‘s verschoben werden. Nun können die Register wieder hergestellt werden (POP R0-R12). Das Link-Register kann hier außer Acht gelassen werden, da es immer den Wert 0xFFFFFF9 (Return to Thread mode without floating point calculation) hat.
Wenn man nun das ISR von außen betrachtet, darf man keinen Unterschied zum letzten Speicherzeitpunkt feststellen.

 
[[Datei:Move Stack Balz.jpg]]

== Praxis ==
=== Speicher ===
Die Praxis ist leider etwas komplizierter: Zunächst einmal muss der Task-Stack im Speicher reserviert werden. Hierfür kann entweder malloc() verwendet werden - um dynamisch zur Laufzeit den Speicher zu reservieren - oder man „belegt“ den Speicher über Arrays. Da ein Stack-Overflow mit, dass Schlimmste ist, was unserem System passieren kann (Überschreibung der anderen Stacks/globalen Variablen), sollte die Größe des Stacks eher großzügig definiert sein. 

=== Stackerzeugen===
Da ein Stack sich von oben nach unten (aus Sicht des Speichers) aufbaut, muss der Stack-Pointer auf die Speicheradresse des letzten Array-Elementes zeigen.
Da beim Kontext-Switch der letzte Zustand wiederhergestellt wird, muss nun der Stack befüllt werden:

* Programm Counter: hier wird die Startadresse des Task‘s eingetragen
* Link–Register: Da die Task-Ansicht keine Funktion ist und im Normalfall nicht irgendwann verlassen wird, kann dieses Feld freigelassen werden. Alternativ kann auch auf die Adresse eines Dummy-Handlers verwiesen werden, der sich dann um die Beendigung des Tasks kümmert.
* Program Status Register: Im Status Register (xPSR) wird der Wert hinterlegt, der der CPU signalisiert, dass der aktuelle Programmabschnitt sich gerade in einem Interrupt befindet.
* Register 0-3,12 sind die Register, die vor einem Interrupt gesichert und nach dem Interrupt wieder hergestellt werden. Da der Task noch keine Registerwerte verwendet hat, können diese Zellen frei bleiben.

Wenn nun ein Kontext-Switch ausführt wird, wird man relativ schnell feststellen, dass etwas noch nicht passt.
Die Interrupt-Routine hat selber auch Variablen, die auf dem „alten“ Stack gespeichert und nach Verlassen des Stacks wieder vom Stack „gelöscht“ werden müssen. Diese müssen in dem neuen Stack berücksichtigt werden. Leider kann man hier keinen pauschalen Wert nennen, was dazu führt, dass jede Veränderung an der Interrupt-Routine Folgen haben kann. So muss z.B. bei dem neuem Stack die Anzahl der lokalen Register einbezogen werden.

=== Kontext wechseln ===
Nun, da der Speicher reserviert und der Stack aufgebaut worden ist, kann man den Kontext wechseln.
Hierfür müssen alle General-Purpose-Register auf den Stack gespeichert werden.
Da zu einem späteren Zeitpunkt der Stack wieder zurück gewechselt werden soll, muss nun der aktuelle Stack-Pointer gesichert werden, z.B. in der Task_List (siehe Task_Liste).
Der „alte“ Kontext ist nun gesichert, und so kann der „Neue“ geladen werden. Zunächst muss der Stack-Pointer umgezogen werden.
Um sicher zu stellen, dass der µC nun den neuen Stack auch verwendet, muss ein „Pipeline flush“ getätigt werden. Hierfür ist im TUMB2-Befehlssatz der Befehl „ISB“ (Instruction Synchronization Barrier) vorhanden, der direkt nach dem Stack-Pointer-Tausch ausgeführt werden sollte.
Nun können die Register 0-12 wieder hergestellt werden. Das Linkregister verändert sich nicht, da das Exc_return Value immer gleich ist.

Wird nun die Interrupt Routine verlassen, werden die lokalen Variablen vom Stack gelöscht und die ISR-Inhalte gePOP’t. Der Prozessor springt dann „zurück“ in den neuen Task.

==== BSP1 ====
Im folgenden Bild kann man gut sehen, wie zwei Tasks (weiße Kästen: PWM) abwechselnd aufgerufen werden. Dargestellt ist die Aktivität der Tasks als Funktion der Zeit; alle 50 ms wird in diesem Beispiel der Task gewechselt: 
 

[[Datei:Context Switch.JPG | 900px]]

 

== Task-Liste==
Damit das System weiß, wie viele und welche Tasks gerade ausgeführt werden, muss eine Liste erstellt werden, in der die jeweiligen IDs der Tasks enthalten sind, sowie:
* Stack-Pointer
* Stack Start Adresse
* Stack-Size
Optional kann in dieser Liste auch noch:
* Task Status/Message
* Thread Return_Value
enthalten sein.
=== Stack Pointer ===
Um bei einem Kontext Switch den alten Task wieder herzustellen, muss bekannt sein, an welcher Stelle im Speicher der Stack liegt.
 
=== Stack Start Adresse ===
Ist relevant, wenn überprüft werden soll, ob es einen Stack Overflow gab. Sollte es ein Stack-Overflow geben muss dies gemeldet und das System wieder auf den Ursprungszustand gesetzt werden.
 

=== Stack-Size ===
Wird in Verbindung mit der Stack_Start Adresse für die Overflow-Erkennung benötigt.
 
=== Task Status ===
Hier kann ein Task seinen Status mitteilen
* IDLE
* Started(läuft der Task gerade?)
* Oder soll der Stack des Task‘s aufgebaut werden
* Lese Fehler (siehe Speicher Management)

=== Return Value ===
wird ein Thread auf geplante Weise verlassen – (d.h. er beendet sich selber) –kann dieser auch ein Return_Value als Ergebnis hinterlegen. Hat der Thread z.B. die Aufgabe, eine Nutzereingabe zu erkennen und zu analysieren, so kann der erstellende Task (der die ID kennt) über das Ergebnis informiert werden.
 
== Zeitmanagement ==

=== System-Zeit ===
Oftmals kommt es vor, dass ein Task eine Tätigkeit alle x ms ausführen soll. Da jedoch die Tasks möglichst unabhängig sein sollen (sie wissen also nicht mit welcher Taktrate der Prozessor läuft), ist es sinnvoll, über eine RTT oder einen Timer/Counter die Zeit mitzuzählen und diese über eine Funktion allen Tasks und Threads zur Verfügung zu stellen.
Auch ist es sinnvoll, eine Funktion bereit zu stellen, die überprüft ob eine bestimmt Zeit vergangen ist; unter Berücksichtigung, dass die System-Zeit irgendwann wieder bei 0 anfängt.
Eine solche Funktion könnte wie folgt aussehen:

<syntaxhighlight lang="c">
int vergangene_zeit(int os_lasttime, int soll_time){
int time_know = get_os_time(); // hole die aktuelle Systhem Zeit
int delta;
if (zeit-lasttime <0) // hat ein System-Zeit Wraparound stattgefunden
{
zeit += os_max_time; // addiere Max SysthemZeit drauf
}
delta = zeit-lasttime;
return delta >= sollzeit;
}

</syntaxhighlight>
 

So kann ein Task einfach in einer <syntaxhighlight lang="c"> while(!(vergangene_zeit(lasttime,soll_time))){}</syntaxhighlight> darauf warten, dass die Soll Zeit abgelaufen ist.

 
=== Kontext-Switch ===
Natürlich ist es auch wichtig, dass der Kontext-Switch zentral gesteuert wird. Hier ist es empfehlenswert, den Real-Time-Timer oder einen Timer/Counter zu verwenden, der die Systemzeit managt. Über ein Static counter kann/soll eine bestimmte Anzahl an Zyklen bestimmt werden, bei denen der Kontext-Switch getriggert wird.
 

=== IDLE ===
Hat man mehrere Tasks die darauf warten, dass Zeit vergeht, wird viel Rechenleistung verbraucht, da die Tasks mit Nichtstun beschäftigt sind, während andere Tasks diese Rechenzeit gut brauchen könnten.
Um diesem Problem zu entgehen, sollte ein Task in der Lage sein, sich als inaktiv zu deklarieren. Dies könnte über einen Status-Bit geschehen, welches der Time_manager bei jedem Erhöhen der Systemzeit überprüft und den Kontext-Switch triggert.
Eine bessere Lösung wäre jedoch, zusätzlich zur IDLE Funktion einen Software Interrupt auszulösen, welcher den TC_Handler oder RTT_Handler des Zeitmanagements triggert.
So kann im Zeitmanagement geprüft werden, ob ein Task IDLE ist, oder ob der Interrupt auf herkömmliche Weise generiert worden ist.
Sollten ein Großteil oder alle Task IDLE sein, sollte die CPU in ein LOW-Power-Mode wechseln.

 

==== Beispiel 1====

Im folgenden Beispiel kann gut erkannt werden, wie sich Task1 zur Hälfte der möglichen Laufzeit als IDLE deklariert und einen Kontext-Switch triggert.

 
[[Datei:Task IDLE.JPG|900px]]
Saleae Logic Analyser: Task IDLE
 

= Tasks und Threads zur Laufzeit erstellen und beenden =

Eine weite Stärke eines solchen Systems ist es, dass dann ohne großen Aufwand einfach ein neuer Task oder Thread hinzugefügt werden kann.
Ein Thread hat eine feste Aufgabe die er erfüllen soll. Ist diese erfüllt, können weitere Ereignisse getriggert werden, oder der Thread kann beendet werden.

 

=== Starten ===
Hierfür muss lediglich ein neuer Stack mit Linkregister, Einsprung-Adresse etc. hinzugefügt werden und über die Task_Liste dem Zeitmanagement mitgeteilt werden, sodass es einen neuen Taskeintrag gibt, der gestartet werden soll.
==== Beispiel 2 ====

Hier kann gut erkannt werden, wie Thread 1 während der Laufzeit erstellt wird und von nun an vom Scheduler aufgerufen wird. Hierdurch werden jedoch Task1 und Task2 seltener aufgerufen.
 
[[Datei:Thread start.JPG |900px]] 
 

=== Beenden ===
Ein Thread kann auf zwei Arten beendet werden. Die reguläre Art ist, dass er sich selber schließt. Hierfür kann eine Funktion geschrieben werden, die der Task_Liste mitteilt, dass der Task beim nächsten Kontext-Switch nicht mehr aufgerufen werden soll. Optional kann in der Task_List ein Return Value hinterlegt werden, damit der Ersteller des Tasks z. B. ein Ergebnis erhält. Hierbei ist wichtig, zuerst den Return_value zu setzen bevor der Task als beendet definiert wird, da ansonsten ein ungünstiges Timing mit dem Kontext-Switch das Schreiben des Return_Values verhindert. Nachdem Return_value und der Task als beendet definiert worden sind, sollte der Task einen Task_IDLE an den Zeitmanager senden, um so den Task direkt zu verlassen und keine Rechenzeit zu vergeuden.
Auch ist es nötig, dass der Ersteller des Threads die ID des Threads in der Task_Liste erhält, da hinter der ID des Threads auch der Return_Value gespeichert wird.
Eine andere Art ein Thread zu beenden ist, ihn zu killen. Wenn z. B. die Ausführung des Threads nicht mehr relevant ist, weil das Ergebnis zu spät kommen würde (Real-Time-OS), oder die Ausführung des Threads nicht mehr benötigt wird, kann man einen Thread auch über die Task-Liste von außen beenden. Hierbei muss nur das Task_Active-Bit gelöscht werden.
 

==== Beispiel 3 ====
 
[[Datei:Thread closing.JPG|900px]]
 
Hier kann gut erkannt werden, wie Thread1 wieder geschlossen wird. Dadurch werden Task 1 und Task 2 wieder öfter aufgerufen. 

= Interrupte =
 
Eigentlich sollte es keinerlei Probleme bereiten, einen Interrupt auszuführen, da dieser den aktuellen Task nicht berührt.
Es muss lediglich auf zwei Punkte Rücksicht genommen werden:
* Der Zeitmanager muss in der niedrigsten Priorität laufen. Würde er mit einer höheren Priorität laufen während gerade ein anderer Interrupt aktiv ist, würden die gespeicherten Register in den falschen Stack abgelegt. Die wieder herzustellenden Register kämen aus einem Stack, in dem keine Register gesichert worden sind. Dieser Vorgang würde beide Stacks zerstören.
* Während des Kontext Switches dürfen keine anderen Interrupts aktiv werden, da es auch hier zu Problemen mit den Stacks kommen könnte.
Deshalb ist es empfehlenswert, den Zeitmanager in der niedrigsten Priorität laufen zu lassen und während der Ausführung andere Interrupts zu unterbinden.

 

= Erweiterung zum OS =
Von nun an sind die Übergänge zu einem Betriebssystem fließend.
 
== Priorisierung ==
in Arbeit!
 

==Speicher Management ==
Der erste Schritt in Richtung Betriebssystem ist ein Speicher-Management, welches in der Lage ist, Speicher zu reservieren und gegebenenfalls auch zu blockieren, sowie freizugeben. Hier kommt wieder – wie beim Stack-Aufbau - malloc() oder ein Array zum Einsatz. Der Einfachheit halber werden die einzelnen Speicher über ID’s angesprochen. Auch muss zentral geregelt werden, ob die jeweilige ID bereits in Verwendung ist.
 
=== Erstellen ===
Möchte ein Task oder Thread einen solchen Speicher erstellen, muss zunächst überprüft werden, ob noch Speicherplätze frei sind. In diesem Fall kann die ID der Speicherzelle zurückgegeben werden (return-Wert). Andernfalls sollte ein Error_Value zurück geliefert werden.
 
=== Freigeben ===
Um Speicher zu sparen, müssen Task und Threads in der Lage sein, den Speicher wieder frei zu geben. Sollte ein Task der beim Speicher durch einen Kontext –Switch unterbrochen worden ist, auf denselben Speicher zugreifen, sollte vor dem Freigeben überprüft werden, ob und warum der Speicher gesperrt worden ist.
 

=== Speichern ===
Um ein ungünstiges Timing zu verhindern (z. B. ein Prozess beschreibt eine Speicherzelle und wird während des Schreibvorganges durch einen Kontext-Switch unterbrochen), sollte nun der Speicher durch einen anderen Task wieder freigegeben werden. Hierzu muss vor dem Schreibvorgang signalisiert werden, dass die jeweilige Zelle blockiert ist. Als Return kann hier dann entweder ein Error_value oder ein Success_Value übertragen werden. 

=== Lesen ===
Zum Lesen muss lediglich überprüft werden, ob der Speicher der angegebenen ID reserviert ist. Als Return kann hier dann entweder der gespeicherte Wert oder ein Error_Value verwendet werden. Um zu erkennen ob es sich hier um einen Fehler handelt oder um einen gespeicherten Wert, kann über die Task_Liste (ID sollte bekannt sein!) ein Statusbit gesetzt werden. 
 

== Kommunikation mit anderen Task‘s ==
Oftmals ist es notwendig, dass die Tasks in der Lage sind, miteinander zu kommunizieren und so Ergebnisse auszutauschen. Hierfür kann ein weiterer Eintrag in der Task-Liste weiterhelfen, der einen anderen Task darüber informiert unter welcher Speicher-ID neue Informationen verfügbar sind. Die jeweiligen Tasks müssen dazu jedoch über die ID der jeweils anderen Task Bescheid wissen.
 

== Realtime ==
Je nach Anwendungsfall kann es wichtig sein, dass manche Threads innerhalb einer bestimmten Zeit ausgeführt werden müssen. Hierzu werden für die Threads Prioritäten vergeben, welche gewährleisten, dass die Threads länger oder häufiger ausgeführt werden (je nach Definition). Möglicherweise ergibt die Ausführung/Beendigung eines Threads auch nach einem bestimmten Zeitpunkt keinen Sinn mehr.
Beispiel: Ein Sensor soll alle 10 ms ausgelesen werden. Der Sensor liefert immer das aktuelle Messergebnis. Wird nun der Thread (der alle 10 ms getriggert wird um einen Sensor auszulesen) von einem wichtigeren Ereignis unterbrochen und so z. B. über 50ms verzögert, so warten dann 5 getriggerte Threads darauf, CPU Zeit zugewiesen zu bekommen. Da aber immer nur der aktuelle Sensorwert ausgegeben werden kann, liefern alle 5 Threads dasselbe Ergebnis. Um nun Ressourcen zu sparen, muss erkannt werden, ob die Ausführung dieses Threads noch sinnvoll ist. Andernfalls sollten die Threads beendet werden und es kann eine Fehlermeldung generiert werden.

 

= Fehlersuche und Kontrolle =
== Register Kontrolle ==
Zunächst ist es wichtig zu überprüfen, ob alle Variablen und Register denselben Wert wie nach einem Kontext Switch haben. Hier ist es empfehlenswert, beim Erstellen des Tasks lokale Variablen mit eindeutigen Werten zu erstellen und anschließend in einer while(1)-Schleife laufen zu lassen.
Die einfachste Überprüfung ist hier: Mit dem Debugger einen Breakpoint in der while(1)-Schleife des Programms zu setzen und nach dem Kontext-Switch anzuhalten, um auf diese Weise die Variablen zu überprüfen.

Mögliche Fehlerquellen:
* Stack Pointer zeigt auf die falsche Adresse
* Zuviele oder nicht ausreichend lokale Variablen -der ISR- nach Verlassen der ISR gelöscht
* Register in falscher Reihenfolge wiederhergestellt
'''Beispiel'''
<syntaxhighlight lang="c">
Void Test_Task1(){
Start_task();
int a = 3;
int b = 1;
int c = 2;
int d = 3;
int e = 4;
int f = 5;
int g = 6;
int h = 7;
while(1){
}
}
</syntaxhighlight>

 

== Rechenoperationen ==
Wenn sichergestellt wurde, dass die Register und Variablen nach einem Kontext Switch unverändert bestehen, kann mit einer einfachen Rechenoperation, die je nach Ausgangswert ein anderes Ergebnis liefert, überprüft werden, ob die Wiedereinsprungsadresse stimmt.
Da lokale Variablen zerstört werden können, sollten globale Variablen hierfür verwendet werden, da diese eben nicht im Stack gespeichert werden. Zusätzlich sollte ein Fehlercounter inkrementiert werden.

Mögliche Fehlerquellen:
* Falsches Link Register
* Falscher PC
* Fehlerhafte Register und/oder Variablen
'''Beispiel'''
Hier eignet sich die Berechnung der ersten Fibonacci-Zahlen, da hier jedes weitere Ergebnis vom Vorherigen abhängt.
<syntaxhighlight lang="c">
Int error;
Void Test_Task2(){
Start_Task();
int a = 1;
int b = 1;
int c;
int counter = 0;
while(1){
c = a;
a = b+a;
b = c;
switch(counter){
case 0:if(!(b==1)){
error++;
}break;
case 1:if(!(b==2)){
error++;}break;
case 2:if(!(b==3)){
error++;}break;
case 3:if(!(b==5)){
error++;}break;

...
...
...

default:counter = -1; b = 1; a = 1;break;
}
counter ++;
}
}

</syntaxhighlight>
 

== Funktionskaskade ==
Um zu überprüfen, ob Linkregister und Programmcounter richtig gesichert wurden, kann man via Funktionkaskaden überprüfen, ob alle Funktionen in der richtigen Reihenfolge aufgerufen werden, und ob sie auch wieder richtig verlassen werden. Auch wichtig sind Übergabeparameter und return values.
Sollte es hier zu einem Fehler kommen, kann es sein, dass nur die lokalen Variablen verloren gehen. Es kann jedoch auch passieren, dass nach dem Verlassen der Funktion zu viel oder zu wenig vom Stack geladen wird, wodurch eine falsche Rücksprungadresse geladen wird. Mit etwas Glück erkennt der µC dies und springt dann in einen Fault-Handler.
 

Möglichen Fehler Quellen:
* Link Register hatt die Falsche Adresse
* Fehlerhafte Register und/oder Variablen
* Falscher Programcounter
* Register 7 (kann von UC, Compiler oder IDE unterschiedlich sein) bei einem Funktions Call wird in einem Register der alte Stackpointer hinterlegt, ob zu zeigen, wie viele Lokale Variablen nach Verlassen der aktuellen Funktion auf dem Stack nicht mehr benötigt werden.

'''Beispiel'''
<syntaxhighlight lang="c">
int tester;
int error;
void Task_test3(){
while(1){
tester = 1;
int dummy = test1(5,6);

if(dummy != 9 || tester != 4){
error ++;
}
}
}

int test1(int a, int b){
if(tester != 1){
error++;
}
tester = 2;
int dummy = test2(7);
if(a != 5 || b != 6 || dummy != 8 || tester != 3){
error++;
}
tester = 4;
return 9;
}

int test2(int a)
{
if(a != 7 || tester != 2){
error ++;
}
tester = 3;
return 8;
}

</syntaxhighlight >
 

== Kein Kontext Switch mehr ==
Sollten plötzlich keine Kontext-Switche mehr stattfinden(ein Task wird nicht mehr verlassen) sollten man im Interrupt_Manager –„ Nested Vectored Interrupt Controller“ (NVIC) - nachschauen, ob das Interrupt_Active_Bit gesetzt ist. Sollte dies der Fall sein, wurde der Kontext-Switch nicht richtig verlassen und der Prozessor glaubt, er würde noch immer den Interrupt ausführen. Viele Prozessoren - unter anderem ARM - erlauben kein Repending(doppeltes Ausführen) eines Interruptes.
 
Mögliche Fehlerquellen:
* Linkregister: Bei einem Interrupt Aufruf wird das Link Register mit einem Exp_return_Value beschreiben. Dieser sagt aus, auf welche Art und ob nach Verlassen der Funktion das Interrupt abgeschlossen wurde. So weiss der UC, ob z.B. noch ein Interrupt mit einer niedrigeren Priorität unterbrochen wurde.

 

= Lektüre =
* µC/OS-III: The Real-Time Kernel https://www.micrium.com/books/ucosiii/
* http://infocenter.arm.com
* Datenblatt
* '''Grundlagen:''' https://www.mikrocontroller.net/articles/Multitasking
 

= Quellen =
* µC/OS-III: The Real-Time Kernel
* SAM4S-Datenblatt http://www.atmel.com/Images/Atmel-11100-32-bit%20Cortex-M4-Microcontroller-SAM4S_Datasheet.pdf

= Link Sammlung =
* https://www.mikrocontroller.net/topic/381051
* https://www.mikrocontroller.net/topic/389195?goto=4457089#4457089
 

= Autor =
Sebastian Balz
[[Kategorie:ARM]]
[[Kategorie:Betriebssysteme]]

Scheduler mit Erweiterung zum Mini-Betriebssystem

2016-03-17T05:44:54Z

8023:

<big> '''Vorwort'''</big>: 
Dieser Artikel behandelt die Erstellung eines Schedulers, der zu einem Mini-OS erweitert wird. Ziel ist es, das Verständnis sowie die Funktion eines OS besser verstehen zu können. Wie so manch ein anderer habe auch ich mich gefragt, wie ein Betriebssystem eigentlich funktioniert, und - weil Nachbauen eine der besten Möglichkeit ist etwas zu verstehen - habe mir mein eigenes kleines System geschrieben. Es geht nicht darum ein „Suppa-Duppa“ OS zu schreiben, sondern zu verstehen wie größere (RTOS->Linux->Windows) funktionieren. 
Von: Sebastian Balz 

{{Warnung |
'''Warnung'''
 
Deutsche, Kauft nicht bei den Juden! Heil Hitler!

}} 
Alle Beispiele beziehen sich auf einen ARM-Cortex-M4 (SAM4SD32C), sollten jedoch auf alle gängigen µC portiert werden können. Um den Kontext-Switch zu vereinfachen werden keine Gleitkomma Berechnungen unterstützt. 
 

= Voraussetzungen =
 
* Gute C und Assembler Kenntnisse
* Gute Kenntnisse des UC‘s
* Viel Zeit und Motivation :)
 

= Zielsetzung=
 
Das beschriebene System soll in der Lage sein:
* Zwischen verschiedenen Aufgaben (Tasks) zu wechseln(Context-Switch). D.h. jeder Task hat das Gefühl, dass der UC ihm gehört.
* Fähigkeit der Task’s sich selber zu beenden oder zu pausieren, um so CPU-Ressourcen zu sparen.
* Keinerlei Auswirkung aufs Interrupt Handling.
* Ein Zeit Management
* Tasks und Threads mit Return-Wert und Kill
* Kommunikation zwischen den Tasks mit Schreib-Kontrolle

 

= Grundlagen =

Die Hauptaufgabe des Systems ist es, zwischen den verschiedenen Tasks wechseln zu können.
Um dies realisieren zu können, muss man erst einmal verstehen, wie überhaupt ein Kontext ausschaut.

 

== Register==
Register sind die Speicherzellen, die direkt mit der CPU verbunden sind. Sie haben die besten Lese- und Schreibraten, sind jedoch „teuer“, weshalb in einer CPU nur relativ wenige Register vorhanden sind.
In der ARM-Cortex-M4 Serie sind es 12 sog. „General-Purpose Register“ und ein paar Spezial-Register.

 

[[Datei:Register Balz.PNG|900px]] 

Quelle: Datenblatt Register
 

== Stack ==

Der Stack ist ein LIFO (Last in, First out), d.h. der zuletzt hinzugefügte Wert wird als erstes wieder ausgelesen. Über Push (Speicher) und POP (Laden) kann man Register-Inhalte auf den Stack speichern und laden.
Des Weiteren gibt es einen Stack-Pointer. Dieser zeigt immer auf die letzte Adresse im Stack.
Der Stack baut sich von einer Speicherzelle aus nach unten auf. D.h., wenn ein Wert auf den Stack geschrieben wird, verringert sich die Stack-Adresse.

Jedes Programm schreibt und erstellt seine lokalen Variablen auf dem Stack (RAM). Bei einem Funktionsaufruf werden Übergabeparameter und die Rücksprungadresse im Stack hinterlegt.
Die aufgerufene Funktion des Speichers (Push) hat also so viele Register auf dem Stack, wie sie selber Register benötigt, damit beim „Return“ wieder die Start-Register vom Stack geholt (POP) werden können und damit der „vor-Funktion-Zustand“ wieder hergestellt ist.

 

== Exception Call ==
Wird eine Funktion durch einen Interrupt unterbrochen, werden R0-R3,R12, LR, PC und xPSR (eine Verbindung aus “Interrupt Program Status Register“, “Application Program Status Register“, „Program Status Register“ und „Execution Program Status Register“) auf den Stack gepusht.
[[Datei:Stack Balz.PNG]] 

Quelle Datenblatt: Interrupt Stack 
Der µC schreibt beim “Interrupt entry“ eine EXC_Return_Value ins Link um zu signalisieren, dass gerade eine Interrupt-Routine aktiv ist. 
 

[[Datei:EXC Return Balz.PNG |700px]] 

Quelle: Datenblatt Exc_Return 
 
Beim Verlassen des ISRs müssen nun nur noch die Register R0-R3, LR,SP und die Status-Register wieder hergestellt werden. 
 

= Context-Switch =

== Theorie==
Um nun den aktuellen Kontext zu wechseln, müssen in einem Interrupt sämtliche Register gespeichert werden (PUSH R0-R12) und der Stack-Pointer auf den Stack des neuen Task‘s verschoben werden. Nun können die Register wieder hergestellt werden (POP R0-R12). Das Link-Register kann hier außer Acht gelassen werden, da es immer den Wert 0xFFFFFF9 (Return to Thread mode without floating point calculation) hat.
Wenn man nun das ISR von außen betrachtet, darf man keinen Unterschied zum letzten Speicherzeitpunkt feststellen.

 
[[Datei:Move Stack Balz.jpg]]

== Praxis ==
=== Speicher ===
Die Praxis ist leider etwas komplizierter: Zunächst einmal muss der Task-Stack im Speicher reserviert werden. Hierfür kann entweder malloc() verwendet werden - um dynamisch zur Laufzeit den Speicher zu reservieren - oder man „belegt“ den Speicher über Arrays. Da ein Stack-Overflow mit, dass Schlimmste ist, was unserem System passieren kann (Überschreibung der anderen Stacks/globalen Variablen), sollte die Größe des Stacks eher großzügig definiert sein. 

=== Stackerzeugen===
Da ein Stack sich von oben nach unten (aus Sicht des Speichers) aufbaut, muss der Stack-Pointer auf die Speicheradresse des letzten Array-Elementes zeigen.
Da beim Kontext-Switch der letzte Zustand wiederhergestellt wird, muss nun der Stack befüllt werden:

* Programm Counter: hier wird die Startadresse des Task‘s eingetragen
* Link–Register: Da die Task-Ansicht keine Funktion ist und im Normalfall nicht irgendwann verlassen wird, kann dieses Feld freigelassen werden. Alternativ kann auch auf die Adresse eines Dummy-Handlers verwiesen werden, der sich dann um die Beendigung des Tasks kümmert.
* Program Status Register: Im Status Register (xPSR) wird der Wert hinterlegt, der der CPU signalisiert, dass der aktuelle Programmabschnitt sich gerade in einem Interrupt befindet.
* Register 0-3,12 sind die Register, die vor einem Interrupt gesichert und nach dem Interrupt wieder hergestellt werden. Da der Task noch keine Registerwerte verwendet hat, können diese Zellen frei bleiben.

Wenn nun ein Kontext-Switch ausführt wird, wird man relativ schnell feststellen, dass etwas noch nicht passt.
Die Interrupt-Routine hat selber auch Variablen, die auf dem „alten“ Stack gespeichert und nach Verlassen des Stacks wieder vom Stack „gelöscht“ werden müssen. Diese müssen in dem neuen Stack berücksichtigt werden. Leider kann man hier keinen pauschalen Wert nennen, was dazu führt, dass jede Veränderung an der Interrupt-Routine Folgen haben kann. So muss z.B. bei dem neuem Stack die Anzahl der lokalen Register einbezogen werden.

=== Kontext wechseln ===
Nun, da der Speicher reserviert und der Stack aufgebaut worden ist, kann man den Kontext wechseln.
Hierfür müssen alle General-Purpose-Register auf den Stack gespeichert werden.
Da zu einem späteren Zeitpunkt der Stack wieder zurück gewechselt werden soll, muss nun der aktuelle Stack-Pointer gesichert werden, z.B. in der Task_List (siehe Task_Liste).
Der „alte“ Kontext ist nun gesichert, und so kann der „Neue“ geladen werden. Zunächst muss der Stack-Pointer umgezogen werden.
Um sicher zu stellen, dass der µC nun den neuen Stack auch verwendet, muss ein „Pipeline flush“ getätigt werden. Hierfür ist im TUMB2-Befehlssatz der Befehl „ISB“ (Instruction Synchronization Barrier) vorhanden, der direkt nach dem Stack-Pointer-Tausch ausgeführt werden sollte.
Nun können die Register 0-12 wieder hergestellt werden. Das Linkregister verändert sich nicht, da das Exc_return Value immer gleich ist.

Wird nun die Interrupt Routine verlassen, werden die lokalen Variablen vom Stack gelöscht und die ISR-Inhalte gePOP’t. Der Prozessor springt dann „zurück“ in den neuen Task.

==== BSP1 ====
Im folgenden Bild kann man gut sehen, wie zwei Tasks (weiße Kästen: PWM) abwechselnd aufgerufen werden. Dargestellt ist die Aktivität der Tasks als Funktion der Zeit; alle 50 ms wird in diesem Beispiel der Task gewechselt: 
 

[[Datei:Context Switch.JPG | 900px]]

 

== Task-Liste==
Damit das System weiß, wie viele und welche Tasks gerade ausgeführt werden, muss eine Liste erstellt werden, in der die jeweiligen IDs der Tasks enthalten sind, sowie:
* Stack-Pointer
* Stack Start Adresse
* Stack-Size
Optional kann in dieser Liste auch noch:
* Task Status/Message
* Thread Return_Value
enthalten sein.
=== Stack Pointer ===
Um bei einem Kontext Switch den alten Task wieder herzustellen, muss bekannt sein, an welcher Stelle im Speicher der Stack liegt.
 
=== Stack Start Adresse ===
Ist relevant, wenn überprüft werden soll, ob es einen Stack Overflow gab. Sollte es ein Stack-Overflow geben muss dies gemeldet und das System wieder auf den Ursprungszustand gesetzt werden.
 

=== Stack-Size ===
Wird in Verbindung mit der Stack_Start Adresse für die Overflow-Erkennung benötigt.
 
=== Task Status ===
Hier kann ein Task seinen Status mitteilen
* IDLE
* Started(läuft der Task gerade?)
* Oder soll der Stack des Task‘s aufgebaut werden
* Lese Fehler (siehe Speicher Management)

=== Return Value ===
wird ein Thread auf geplante Weise verlassen – (d.h. er beendet sich selber) –kann dieser auch ein Return_Value als Ergebnis hinterlegen. Hat der Thread z.B. die Aufgabe, eine Nutzereingabe zu erkennen und zu analysieren, so kann der erstellende Task (der die ID kennt) über das Ergebnis informiert werden.
 
== Zeitmanagement ==

=== System-Zeit ===
Oftmals kommt es vor, dass ein Task eine Tätigkeit alle x ms ausführen soll. Da jedoch die Tasks möglichst unabhängig sein sollen (sie wissen also nicht mit welcher Taktrate der Prozessor läuft), ist es sinnvoll, über eine RTT oder einen Timer/Counter die Zeit mitzuzählen und diese über eine Funktion allen Tasks und Threads zur Verfügung zu stellen.
Auch ist es sinnvoll, eine Funktion bereit zu stellen, die überprüft ob eine bestimmt Zeit vergangen ist; unter Berücksichtigung, dass die System-Zeit irgendwann wieder bei 0 anfängt.
Eine solche Funktion könnte wie folgt aussehen:

<syntaxhighlight lang="c">
int vergangene_zeit(int os_lasttime, int soll_time){
int time_know = get_os_time(); // hole die aktuelle Systhem Zeit
int delta;
if (zeit-lasttime <0) // hat ein System-Zeit Wraparound stattgefunden
{
zeit += os_max_time; // addiere Max SysthemZeit drauf
}
delta = zeit-lasttime;
return delta >= sollzeit;
}

</syntaxhighlight>
 

So kann ein Task einfach in einer <syntaxhighlight lang="c"> while(!(vergangene_zeit(lasttime,soll_time))){}</syntaxhighlight> darauf warten, dass die Soll Zeit abgelaufen ist.

 
=== Kontext-Switch ===
Natürlich ist es auch wichtig, dass der Kontext-Switch zentral gesteuert wird. Hier ist es empfehlenswert, den Real-Time-Timer oder einen Timer/Counter zu verwenden, der die Systemzeit managt. Über ein Static counter kann/soll eine bestimmte Anzahl an Zyklen bestimmt werden, bei denen der Kontext-Switch getriggert wird.
 

=== IDLE ===
Hat man mehrere Tasks die darauf warten, dass Zeit vergeht, wird viel Rechenleistung verbraucht, da die Tasks mit Nichtstun beschäftigt sind, während andere Tasks diese Rechenzeit gut brauchen könnten.
Um diesem Problem zu entgehen, sollte ein Task in der Lage sein, sich als inaktiv zu deklarieren. Dies könnte über einen Status-Bit geschehen, welches der Time_manager bei jedem Erhöhen der Systemzeit überprüft und den Kontext-Switch triggert.
Eine bessere Lösung wäre jedoch, zusätzlich zur IDLE Funktion einen Software Interrupt auszulösen, welcher den TC_Handler oder RTT_Handler des Zeitmanagements triggert.
So kann im Zeitmanagement geprüft werden, ob ein Task IDLE ist, oder ob der Interrupt auf herkömmliche Weise generiert worden ist.
Sollten ein Großteil oder alle Task IDLE sein, sollte die CPU in ein LOW-Power-Mode wechseln.

 

==== Beispiel 1====

Im folgenden Beispiel kann gut erkannt werden, wie sich Task1 zur Hälfte der möglichen Laufzeit als IDLE deklariert und einen Kontext-Switch triggert.

 
[[Datei:Task IDLE.JPG|900px]]
Saleae Logic Analyser: Task IDLE
 

= Tasks und Threads zur Laufzeit erstellen und beenden =

Eine weite Stärke eines solchen Systems ist es, dass dann ohne großen Aufwand einfach ein neuer Task oder Thread hinzugefügt werden kann.
Ein Thread hat eine feste Aufgabe die er erfüllen soll. Ist diese erfüllt, können weitere Ereignisse getriggert werden, oder der Thread kann beendet werden.

 

=== Starten ===
Hierfür muss lediglich ein neuer Stack mit Linkregister, Einsprung-Adresse etc. hinzugefügt werden und über die Task_Liste dem Zeitmanagement mitgeteilt werden, sodass es einen neuen Taskeintrag gibt, der gestartet werden soll.
==== Beispiel 2 ====

Hier kann gut erkannt werden, wie Thread 1 während der Laufzeit erstellt wird und von nun an vom Scheduler aufgerufen wird. Hierdurch werden jedoch Task1 und Task2 seltener aufgerufen.
 
[[Datei:Thread start.JPG |900px]] 
 

=== Beenden ===
Ein Thread kann auf zwei Arten beendet werden. Die reguläre Art ist, dass er sich selber schließt. Hierfür kann eine Funktion geschrieben werden, die der Task_Liste mitteilt, dass der Task beim nächsten Kontext-Switch nicht mehr aufgerufen werden soll. Optional kann in der Task_List ein Return Value hinterlegt werden, damit der Ersteller des Tasks z. B. ein Ergebnis erhält. Hierbei ist wichtig, zuerst den Return_value zu setzen bevor der Task als beendet definiert wird, da ansonsten ein ungünstiges Timing mit dem Kontext-Switch das Schreiben des Return_Values verhindert. Nachdem Return_value und der Task als beendet definiert worden sind, sollte der Task einen Task_IDLE an den Zeitmanager senden, um so den Task direkt zu verlassen und keine Rechenzeit zu vergeuden.
Auch ist es nötig, dass der Ersteller des Threads die ID des Threads in der Task_Liste erhält, da hinter der ID des Threads auch der Return_Value gespeichert wird.
Eine andere Art ein Thread zu beenden ist, ihn zu killen. Wenn z. B. die Ausführung des Threads nicht mehr relevant ist, weil das Ergebnis zu spät kommen würde (Real-Time-OS), oder die Ausführung des Threads nicht mehr benötigt wird, kann man einen Thread auch über die Task-Liste von außen beenden. Hierbei muss nur das Task_Active-Bit gelöscht werden.
 

==== Beispiel 3 ====
 
[[Datei:Thread closing.JPG|900px]]
 
Hier kann gut erkannt werden, wie Thread1 wieder geschlossen wird. Dadurch werden Task 1 und Task 2 wieder öfter aufgerufen. 

= Interrupte =
 
Eigentlich sollte es keinerlei Probleme bereiten, einen Interrupt auszuführen, da dieser den aktuellen Task nicht berührt.
Es muss lediglich auf zwei Punkte Rücksicht genommen werden:
* Der Zeitmanager muss in der niedrigsten Priorität laufen. Würde er mit einer höheren Priorität laufen während gerade ein anderer Interrupt aktiv ist, würden die gespeicherten Register in den falschen Stack abgelegt. Die wieder herzustellenden Register kämen aus einem Stack, in dem keine Register gesichert worden sind. Dieser Vorgang würde beide Stacks zerstören.
* Während des Kontext Switches dürfen keine anderen Interrupts aktiv werden, da es auch hier zu Problemen mit den Stacks kommen könnte.
Deshalb ist es empfehlenswert, den Zeitmanager in der niedrigsten Priorität laufen zu lassen und während der Ausführung andere Interrupts zu unterbinden.

 

= Erweiterung zum OS =
Von nun an sind die Übergänge zu einem Betriebssystem fließend.
 
== Priorisierung ==
in Arbeit!
 

==Speicher Management ==
Der erste Schritt in Richtung Betriebssystem ist ein Speicher-Management, welches in der Lage ist, Speicher zu reservieren und gegebenenfalls auch zu blockieren, sowie freizugeben. Hier kommt wieder – wie beim Stack-Aufbau - malloc() oder ein Array zum Einsatz. Der Einfachheit halber werden die einzelnen Speicher über ID’s angesprochen. Auch muss zentral geregelt werden, ob die jeweilige ID bereits in Verwendung ist.
 
=== Erstellen ===
Möchte ein Task oder Thread einen solchen Speicher erstellen, muss zunächst überprüft werden, ob noch Speicherplätze frei sind. In diesem Fall kann die ID der Speicherzelle zurückgegeben werden (return-Wert). Andernfalls sollte ein Error_Value zurück geliefert werden.
 
=== Freigeben ===
Um Speicher zu sparen, müssen Task und Threads in der Lage sein, den Speicher wieder frei zu geben. Sollte ein Task der beim Speicher durch einen Kontext –Switch unterbrochen worden ist, auf denselben Speicher zugreifen, sollte vor dem Freigeben überprüft werden, ob und warum der Speicher gesperrt worden ist.
 

=== Speichern ===
Um ein ungünstiges Timing zu verhindern (z. B. ein Prozess beschreibt eine Speicherzelle und wird während des Schreibvorganges durch einen Kontext-Switch unterbrochen), sollte nun der Speicher durch einen anderen Task wieder freigegeben werden. Hierzu muss vor dem Schreibvorgang signalisiert werden, dass die jeweilige Zelle blockiert ist. Als Return kann hier dann entweder ein Error_value oder ein Success_Value übertragen werden. 

=== Lesen ===
Zum Lesen muss lediglich überprüft werden, ob der Speicher der angegebenen ID reserviert ist. Als Return kann hier dann entweder der gespeicherte Wert oder ein Error_Value verwendet werden. Um zu erkennen ob es sich hier um einen Fehler handelt oder um einen gespeicherten Wert, kann über die Task_Liste (ID sollte bekannt sein!) ein Statusbit gesetzt werden. 
 

== Kommunikation mit anderen Task‘s ==
Oftmals ist es notwendig, dass die Tasks in der Lage sind, miteinander zu kommunizieren und so Ergebnisse auszutauschen. Hierfür kann ein weiterer Eintrag in der Task-Liste weiterhelfen, der einen anderen Task darüber informiert unter welcher Speicher-ID neue Informationen verfügbar sind. Die jeweiligen Tasks müssen dazu jedoch über die ID der jeweils anderen Task Bescheid wissen.
 

== Realtime ==
Je nach Anwendungsfall kann es wichtig sein, dass manche Threads innerhalb einer bestimmten Zeit ausgeführt werden müssen. Hierzu werden für die Threads Prioritäten vergeben, welche gewährleisten, dass die Threads länger oder häufiger ausgeführt werden (je nach Definition). Möglicherweise ergibt die Ausführung/Beendigung eines Threads auch nach einem bestimmten Zeitpunkt keinen Sinn mehr.
Beispiel: Ein Sensor soll alle 10 ms ausgelesen werden. Der Sensor liefert immer das aktuelle Messergebnis. Wird nun der Thread (der alle 10 ms getriggert wird um einen Sensor auszulesen) von einem wichtigeren Ereignis unterbrochen und so z. B. über 50ms verzögert, so warten dann 5 getriggerte Threads darauf, CPU Zeit zugewiesen zu bekommen. Da aber immer nur der aktuelle Sensorwert ausgegeben werden kann, liefern alle 5 Threads dasselbe Ergebnis. Um nun Ressourcen zu sparen, muss erkannt werden, ob die Ausführung dieses Threads noch sinnvoll ist. Andernfalls sollten die Threads beendet werden und es kann eine Fehlermeldung generiert werden.

 

= Fehlersuche und Kontrolle =
== Register Kontrolle ==
Zunächst ist es wichtig zu überprüfen, ob alle Variablen und Register denselben Wert wie nach einem Kontext Switch haben. Hier ist es empfehlenswert, beim Erstellen des Tasks lokale Variablen mit eindeutigen Werten zu erstellen und anschließend in einer while(1)-Schleife laufen zu lassen.
Die einfachste Überprüfung ist hier: Mit dem Debugger einen Breakpoint in der while(1)-Schleife des Programms zu setzen und nach dem Kontext-Switch anzuhalten, um auf diese Weise die Variablen zu überprüfen.

Mögliche Fehlerquellen:
* Stack Pointer zeigt auf die falsche Adresse
* Zuviele oder nicht ausreichend lokale Variablen -der ISR- nach Verlassen der ISR gelöscht
* Register in falscher Reihenfolge wiederhergestellt
'''Beispiel'''
<syntaxhighlight lang="c">
Void Test_Task1(){
Start_task();
int a = 3;
int b = 1;
int c = 2;
int d = 3;
int e = 4;
int f = 5;
int g = 6;
int h = 7;
while(1){
}
}
</syntaxhighlight>

 

== Rechenoperationen ==
Wenn sichergestellt wurde, dass die Register und Variablen nach einem Kontext Switch unverändert bestehen, kann mit einer einfachen Rechenoperation, die je nach Ausgangswert ein anderes Ergebnis liefert, überprüft werden, ob die Wiedereinsprungsadresse stimmt.
Da lokale Variablen zerstört werden können, sollten globale Variablen hierfür verwendet werden, da diese eben nicht im Stack gespeichert werden. Zusätzlich sollte ein Fehlercounter inkrementiert werden.

Mögliche Fehlerquellen:
* Falsches Link Register
* Falscher PC
* Fehlerhafte Register und/oder Variablen
'''Beispiel'''
Hier eignet sich die Berechnung der ersten Fibonacci-Zahlen, da hier jedes weitere Ergebnis vom Vorherigen abhängt.
<syntaxhighlight lang="c">
Int error;
Void Test_Task2(){
Start_Task();
int a = 1;
int b = 1;
int c;
int counter = 0;
while(1){
c = a;
a = b+a;
b = c;
switch(counter){
case 0:if(!(b==1)){
error++;
}break;
case 1:if(!(b==2)){
error++;}break;
case 2:if(!(b==3)){
error++;}break;
case 3:if(!(b==5)){
error++;}break;

...
...
...

default:counter = -1; b = 1; a = 1;break;
}
counter ++;
}
}

</syntaxhighlight>
 

== Funktionskaskade ==
Um zu überprüfen, ob Linkregister und Programmcounter richtig gesichert wurden, kann man via Funktionkaskaden überprüfen, ob alle Funktionen in der richtigen Reihenfolge aufgerufen werden, und ob sie auch wieder richtig verlassen werden. Auch wichtig sind Übergabeparameter und return values.
Sollte es hier zu einem Fehler kommen, kann es sein, dass nur die lokalen Variablen verloren gehen. Es kann jedoch auch passieren, dass nach dem Verlassen der Funktion zu viel oder zu wenig vom Stack geladen wird, wodurch eine falsche Rücksprungadresse geladen wird. Mit etwas Glück erkennt der µC dies und springt dann in einen Fault-Handler.
 

Möglichen Fehler Quellen:
* Link Register hatt die Falsche Adresse
* Fehlerhafte Register und/oder Variablen
* Falscher Programcounter
* Register 7 (kann von UC, Compiler oder IDE unterschiedlich sein) bei einem Funktions Call wird in einem Register der alte Stackpointer hinterlegt, ob zu zeigen, wie viele Lokale Variablen nach Verlassen der aktuellen Funktion auf dem Stack nicht mehr benötigt werden.

'''Beispiel'''
<syntaxhighlight lang="c">
int tester;
int error;
void Task_test3(){
while(1){
tester = 1;
int dummy = test1(5,6);

if(dummy != 9 || tester != 4){
error ++;
}
}
}

int test1(int a, int b){
if(tester != 1){
error++;
}
tester = 2;
int dummy = test2(7);
if(a != 5 || b != 6 || dummy != 8 || tester != 3){
error++;
}
tester = 4;
return 9;
}

int test2(int a)
{
if(a != 7 || tester != 2){
error ++;
}
tester = 3;
return 8;
}

</syntaxhighlight >
 

== Kein Kontext Switch mehr ==
Sollten plötzlich keine Kontext-Switche mehr stattfinden(ein Task wird nicht mehr verlassen) sollten man im Interrupt_Manager –„ Nested Vectored Interrupt Controller“ (NVIC) - nachschauen, ob das Interrupt_Active_Bit gesetzt ist. Sollte dies der Fall sein, wurde der Kontext-Switch nicht richtig verlassen und der Prozessor glaubt, er würde noch immer den Interrupt ausführen. Viele Prozessoren - unter anderem ARM - erlauben kein Repending(doppeltes Ausführen) eines Interruptes.
 
Mögliche Fehlerquellen:
* Linkregister: Bei einem Interrupt Aufruf wird das Link Register mit einem Exp_return_Value beschreiben. Dieser sagt aus, auf welche Art und ob nach Verlassen der Funktion das Interrupt abgeschlossen wurde. So weiss der UC, ob z.B. noch ein Interrupt mit einer niedrigeren Priorität unterbrochen wurde.

 

= Lektüre =
* µC/OS-III: The Real-Time Kernel https://www.micrium.com/books/ucosiii/
* http://infocenter.arm.com
* Datenblatt
* '''Grundlagen:''' https://www.mikrocontroller.net/articles/Multitasking
 

= Quellen =
* µC/OS-III: The Real-Time Kernel
* SAM4S-Datenblatt http://www.atmel.com/Images/Atmel-11100-32-bit%20Cortex-M4-Microcontroller-SAM4S_Datasheet.pdf

= Link Sammlung =
* https://www.mikrocontroller.net/topic/381051
* https://www.mikrocontroller.net/topic/389195?goto=4457089#4457089
 

= Autor =
Sebastian Balz
[[Kategorie:ARM]]
[[Kategorie:Betriebssysteme]]

Kühlkörper

2016-03-17T05:44:00Z

8023:

Lehrvideos

2016-03-17T05:11:08Z

8023:

Kühlkörper

2016-03-17T05:10:29Z

8023:

Labornetzgeräte

2016-03-17T05:09:35Z

8023:

Scheduler mit Erweiterung zum Mini-Betriebssystem

2016-03-17T05:08:07Z

8023: Wie arm im Geiste muss man eigentlich sein, für solchen Kinderkram?

PIC

2016-03-13T19:00:30Z

8023: Bitte mit Duden erneut versuchen.

Ein PIC ist ein [[Mikrocontroller]] der Firma Microchip. Zu aller erst möchte ich die Aufteilung der PICs veranschaulichen. Die PIC-Familien werden fast immer wie folgt bezeichnet: als Beispiel „PIC18“ oder „18er PIC“ bedeutet, es handelt sich um ein PIC18Fxxxx Microcontroller. Alle PICs haben die [[Harvard-Architektur]]. Es können auch alle PICs mittels dem ICSP-Adapter programmiert werden. ICSP steht für In-Ciruit-Serial-Programmer, also ist mittels diesem Anschluss ein brennen möglich, wenn der PIC schon in der Schaltung eingebaut ist. Zudem haben alle PICs, wie auch Microcontroller anderer Hersteller, interne Module. Ein Modul übernimmt eine spezielle Aufgabe, die von der Software nur konfiguriert und nicht zusätzlich ausgeführt wird. Ein Beispiel ist das PWM-Modul. Man kann eine PWM mit der Software generieren (SoftPWM), aber einfacher geht es mit dem Modul, dass nur konfiguriert werden muss. Die Ausgabe der PWM erfolgt anschließend allein durch das Modul und nicht der Software. Da die PICs aber sonst sehr unterschiedlich sind, sollten sie getrennt aufgeführt werden. Grob unterteilt werden sie anhand ihrer Datenbreite.

== 8 Bit ==

Die 8 Bit Microcontroller-Familien sind '''PIC10, PIC12, PIC16 und PIC18'''. Bei den 8-bittigen PICs gibt es einmal den Buchstaben „F“ hinter der Familienbezeichnung und den Buchstaben „C“. Die mit einem „F“ in der Bezeichnung haben einen [http://www.mikrocontroller.net/articles/Flash-ROM Flash]-Programmspeicher, dieser ist somit mehrmals beschreibbar. Das „C“ bedeutet, dass der Programmspeicher entweder ein [http://www.mikrocontroller.net/articles/OTP-ROM OTP]-Speicher (One-Time-Programable – Nur ein mal beschreibbar), oder aber ein [[EPROM]]-Speicher ist, den man nur mit Hilfe von UV-Licht löschen kann. Aus diesem Grund sind die „C“-Varianten uninteressant für Hobby-Elektroniker, zudem sind die C-Varianten ziemlich alt und sogut wie alle PICs sind ausschließlich mit Flash-Speicher verfügbar. Die Typen der Familien haben unterschiedliche Ausstattung, dennoch kann man sagen, je höher die Zahl, desto Leistungsfähiger ist der PIC. Jedoch: Ein Typ der PIC10 Familie mag zwar deutlich schwächer sein, als ein PIC18, dafür gibt es den PIC10 in einem SOT23-Gehäuse, wohingegen der kleinste PIC18 ein SOIC18 ist. Zudem ist der PIC10 billiger, als ein PIC18. Es kommt also immer auf den Anwendungsfall an.

8 Bit PICs können folgendes beinhalten:
* bis zu 128k [[Byte]] ROM
* bis zu 4k [[Byte]] [[RAM]]
* bis zu 1024 [[Byte]] [[EEPROM]]
* 6 bis 100 Pins / 4 bis 70 IOs
* Internen Oscillator
* 8/10/12-bit [[ADC]]
* 5/8-bit [[DAC]]
* [[SPI]]
* [http://www.mikrocontroller.net/articles/I2C I²C]
* [[UART]]
* [[CAN]]
* [[USB]]
* [[PWM]]
* [[Komparator]]
* [[Opamp]]
* 8x8 Hardware Multiplier
* CTMU (Charge Time Measurement Unit, für Cap-Touch-Anwendungen)
* [http://de.wikipedia.org/wiki/Ethernet Ethernet]

Eine Sonderform der 8 Bit Microcontroller ist der rfPIC12F675. Dieser ist extra für RF, also Funkanwendungen ausgelegt und besitzt einen internen [http://de.wikipedia.org/wiki/Dezimeterwelle UHF] [http://de.wikipedia.org/wiki/Amplitude_Shift_Keying ASK]/[http://de.wikipedia.org/wiki/Frequenzumtastung FSK] Transmitter. Eine weitere Sonderform ist der PIC16HV785, der kompatibel zum PIC16F785 ist. Allerdings geht der Spannungsbereich von 2V bis hin zu 15V. Somit kann man diesen auch direkt in ein 12V-System stecken und spart sich ggf. Levelshifter und Spannungsregler. Eine detailiertere Übersicht findet man auf der [http://www.microchip.com/en_US/family/8bit/architecture/ Microchip-Seite] und eine Liste aller Typen ist für jede Familie verfügbar: [http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=1009&mid=10&lang=en&pageId=74 PIC10], [http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=1001&mid=10&lang=en&pageId=74 PIC12], [http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=1002&mid=10&lang=en&pageId=74 PIC16], [http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=1004&mid=10&lang=en&pageId=74 PIC18].

== 16 Bit ==
Die Vertreter der 16 Bit Microcontroller sind '''PIC24E, PIC24F, PIC24H, dsPIC30F, dsPIC33E, dsPIC33F'''. Trotz dessen nicht überall ein „F“ in der Bezeichnung ist, haben diese Familien dennoch einen Flash-Speicher. Die dsPICs haben, wie der Name schon vermuten lässt, eine zusätzliche [[DSP]]-Einheit, die extra für komplexere Berechnungen wie [http://de.wikipedia.org/wiki/Schnelle_Fourier-Transformation FFT] oder [http://de.wikipedia.org/wiki/Digitales_Filter Digital-Filter] benutzt werden können.

16 Bit PICs können folgendes beinhalten:
* bis zu 70 [[MIPS]]
* bis zu 536k [[Byte]] Rom
* bis zu 96k [[Byte]] Ram
* bis zu 4k [[Byte]] [[EEPROM]]
* 14 bis 144 Pins / 12 bis 122 IOs
* “Single Cycle” Multiplikation 16x16 und 32/16 sowie 16/16 Division
* bis zu 32 Channel 10/12-bit [[ADC]]
* 10/16-bit [[DAC]]
* Digital Power, Motor Control und Audio Peripherals
* [http://www.mikrocontroller.net/articles/I2C I²C]
* [[SPI]]
* [[CAN]]
* [[PWM]]
* PMP (Parallel Master Port)
* [[USB]]-OTG
* CTMU
* [http://de.wikipedia.org/wiki/Echtzeituhr RTCC] (Real Time Clock&Calendar)
* [[DMA]] Channels für schnelleren Datentransfer

Die Übersicht ist wieder unter der [http://www.microchip.com/en_US/family/16bit/architecture/ Microchip-Seite] zu finden und auch hier gibt es die Typenlisten für die Familien [http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=8187&mid=14&lang=en PIC24E], [http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=8181&mid=14&lang=en&pageId=75 PIC24F]
[http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=8186&mid=14&lang=en&pageId=75 PIC24H], [http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=8182&mid=14&lang=en&pageId=75 dsPIC30F], [http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=8188&mid=14&lang=en dsPIC33E], [http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=8183&mid=14&lang=en&pageId=75 dsPIC33F].

== 32 Bit ==
Der 32 Bit Microcontroller hat nicht mehr viel mit den anfänglichen PICs gemeinsam. Er besitzt einen „MIPS M4K“-Kern aber ist trotzdem Pin-Kompatibel zu den 16 Bit PICs. Die Typen der PIC32-Familie unterstützen zusätzlich das [[JTAG]]-Interface. Es wurde außerdem auf PIC32-Basis eine [http://de.wikipedia.org/wiki/Arduino-Plattform Arduino]-Alternative entwickelt, die dadurch deutlich leistungsfähiger ist. Genannt wurde dies „chipKIT“ und ist im Moment in 2 Varianten verfügbar. Die Entwicklungsumgebung für die chipKITs basiert auf der Arduino-Software und somit sollen auch alle für den Arduino programmierten Progamme auf dem chipKIT laufen. Es gibt auch PIC32er im DIP-Gehäuse. Somit kann man auch den 32bit Microcontroller von Microchip auf z.B. eine Lochrasterkarte bringen und hat nicht soviele (evtl sogar überflüssige) Pins, wie in den kleinen TQFP/N- oder BGA-Gehäusen.

32 Bit PICs können folgendes beinhalten:
* 80 MHz, 1.56 DMIPS/MHz
* bis zu 512k [[Byte]] Rom
* bis zu 128k [[Byte]] Ram
* Full-speed [[USB]] Host/Device/OTG
* 10/100 [http://de.wikipedia.org/wiki/Ethernet Ethernet] MAC mit MII/RMII Interfaces
* [[CAN]] 2.0B
* [[UART]]
* [http://www.mikrocontroller.net/articles/I2C I²C]
* [[SPI]]
* bis zu 8 Channel [[DMA]]
* Analoger [[Komparator]]
* [[PWM]]
* 16-Channel 10bit [[ADC]]
* [http://de.wikipedia.org/wiki/Echtzeituhr RTCC]

Die Übersicht ist wieder unter der [http://www.microchip.com/en_US/family/32bit/architecture/ Microchip-Seite] zu finden und auch hier gibt es eine Typenliste für die Familie: [http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=211&mid=10&lang=en&pageId=74 PIC32MX].

Neu hinzugekommen ist die Serie PIC32MZXXX mit u. a. folgenden wichtigen Neuerungen zu den bestehenden
PIC32MX:
* 200 MHz / 330DMIPS
* teilweise mit FPU (FloatingPointUnit)
* bis zu 2MB Flash
* bis zu 512K RAM
* EBI (External Bus Interface)
* SQI (Serial Quad Interface)
* crypto engine

== Dokumentation ==

Bei den PICs gibt es zu jedem Mikrocontroller ein Datenblatt. Bei den Familien 10F, 12F, 16F und 18F wird in diesem Datenblatt jeweils der ganze Controller incl. seiner Peripherie ausführlich beschrieben. Bei den 16 & 32 Bit Familien (PIC24F und aufwärts) gibt es hingegen zu jedem Controller ein Kurzdatenblatt das die genauen Leistungsmerkmale sowie die wichtigsten Informationen für den alltäglichen Gebrauch enthält. Da bestimmte Peripherie (bspw. I2C, SPI, ... ) aber sehr komplex ist und innerhalb einer Familie (PIC24/dSPic/32) sich identisch verhält, gibt es bei diesen Familien zu jeder Familie die sogenannten Family-Datasheets, welche alle Module im Detail beschreiben.

== Compiler und IDE ==
=== MPLAB ===

MPLAB ist die freie [http://de.wikipedia.org/wiki/Integrierte_Entwicklungsumgebung IDE] von Microchip und unterstützt von vornherein alle Brenner, Debugger, Emulatoren von Microchip. Zudem kann das Programm in der IDE per Software emuliert werden. Um Programme in [[C]] zu schreiben, können [[C]]-[[Compiler]], sofern die Software das unterstützt, in die [http://de.wikipedia.org/wiki/Integrierte_Entwicklungsumgebung IDE] eingebettet werden, wie z.B. der HI-TECH C-Compiler. Genaueres kann man auf der [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469 Microchip-Seite] anschauen.

=== MPLAB X ===
MPLAB X ist ist eine Weiterentwicklung von MPLAB. Es beinhaltet alle Funktionen von MPLAB (v8). Jedoch wurde die Software komplett neu gestaltet. Vom Simulator bis zum Projektmanagement ist alles modernisiert worden. MPLAB X ist für alle gängigen Betriebssysteme erhältlich (Windows, Linux und OS X).
Weitere Informationen findet man auf der [http://www.microchip.com/pagehandler/en-us/family/mplabx/ Produktseite von MPLAB X].

=== C-Compiler ===
Microchip bietet direkt [[C]]-[[Compiler]] an. Diese wären C18 (für PIC18 Typen), C30 (für 16bit Typen) und C32 (für 32bit Typen). Diese [[Compiler]] können als nicht-kommerzielle Freeware-Version heruntergeladen werden. Dabei wird nach einer gewissen Zeit die Optimierung eingeschränkt. Diese ist für Hobby-Bastler allerdings nicht unbedingt kritisch. Da die [[C]]-[[Compiler]] C30 und C32 von Microchip auf Open-Source aufbauen, sollte der Sourcecode direkt von deren Seite heruntergeladen und die Aufhebung entfernt werden können (sofern man die Möglichkeit hat, die Software danach wieder zu kompilieren).
Es gibt auch andere [[Compiler]], wie z.B. der [[C]]-[[Compiler]] von HI-TECH.
Andere wären noch CC5X oder Compiler der Firma mikroElektronika. Letzterer unterstützt nicht nur alle PICs, sondern ist auch für [[AVR]]s, [[8051]]er und [[ARM]] Microcontroller, sowie jeweils auch in [[Basic]] und [http://de.wikipedia.org/wiki/Pascal_%28Programmiersprache%29 Pascal] erhältlich. MikroE-Compiler, sowie der CC5X sind in der Freeware-Version allerdings Codegrößenbegrenzt, was gerade bei 16bit oder 32bit PICs schnell eng werden kann.

Mit der Einführung von MPLAB X wurden auch die neuen [http://www.microchip.com/pagehandler/en_us/promo/mplabxc/ XC] Compiler von Microchip veröffentlicht. XC8 für 8Bit PICs, XC16 für [[PIC24]] und [[dsPIC]]s und XC32 für [[PIC32]] Mikrocontroller. Auch hier sind Free-Versionen erhältlich.

Ein Vergleich einiger C-Compiler ist in diesem Artikel zu sehen:
[[PIC C-Compilervergleich]]

== Programmiergeräte ==
Um das Programm auf einen PIC zu bekommen, muss dieses per Gerät auf den PIC „gebrannt“ werden. Microchip bietet dazu das PICKIT2 und PICKIT3 an. Das PICKIT3 ist das aktuellere, was bedeutet, dass Firmwareupdates hauptsächlich für diese Version entwickelt werden. Spürbar ist das jetzt schon bei den PIC32MX, die nur vom PICKIT3 unterstützt werden. Wenn man aber kein PIC32 benutzen möchte, kann man bis jetzt aber auch noch zum PICKIT2 greifen, das zusätzlich noch als kleiner Logik-Analyzer dienen kann. Das nächst bessere, was Microchip bietet, ist ein ICD (In-Circuit-Debugger), das eine erweiterte Debuggermöglichkeit bietet. Das „Flagschiff“ ist der REAL-ICE (In-Circuit-Emulator), der zusätzlich noch in der Hardware emulieren kann. Eine Übersicht ist [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2519&param=en534451&page=wwwdevMPLABEmulatorDebuggers hier] zu sehen.

Wie für andere Microcontroller, gibt es auch für den PIC Selbstbaubrenner. Der wohl Bekannteste ist der [http://sprut.de/electronic/pic/brenner/ Brenner8] von der [http://sprut.de Sprut-Seite]. Doch allgemein gilt für Third-Party-Brenner: Es werden neue Microcontroller-Typen, wenn überhaupt, erst später unterstützt, als bei einem originalen Brenner und es führt zu zusätzlichen, möglichen Fehlerquellen durch den Bau. Denn wer kommt schon auf die Idee den Fehler im Brenner zu suchen und nicht in der Schaltung. Hier im Forum sind schon mehrere solcher Fälle vorgekommen. Außerdem bekommt man das "Henne oder Ei"-Problem zu spüren, denn für den Brenner8 muss man einen PIC18 brennen, d.h. man muss sich irgendwo seinen PIC brennen lassen, bevor man es selbst tun kann. Zudem wird nicht jeder bzw. kaum ein Selbst-Bau-Brenner von der IDE unterstützt, was bedeutet, dass man mindestens 2 Programme braucht - Eine zum brennen und eine zum programmieren. Der Brenner8 unterstützt auch kein Debugging, wie es das PICKIT3 jedoch tut. Die Hilfestellung bei einem verbreitetem Programmiergerät ist selbstverständlich besser als bei einem opensource Selbsbau-Brenner. Zudem wird so ein Brenner und die Software meist von einer Einzelperson gepflegt. Dies bedeutet aber auch, dass die Updates usw von dieser Person abhängig ist. Fällt dieser aus (Krankheit oder persönliche Gründe), geht erstmal nichts weiter voran. Es muss also jeder selbst abwägen, ob einem das die ca. 10€ weniger Wert ist. Wenn es jemanden darum geht, den Brenner selbst zu bauen, der kann auch das PICKIT2 nachbauen, denn [http://ww1.microchip.com/downloads/en/DeviceDoc/51553E.pdf Schaltplan] (Seite 77+78) und [http://ww1.microchip.com/downloads/en/DeviceDoc/PK2V023200.zip Firmware] sind offen auf der Herstellerseite verfügbar. Hier ist zwar immer noch die mögliche Fehlerquelle beim Zusammenbau vorhanden, jedoch hat man damit einen besseren Brenner. Wenn einem der originale Brenner zu teuer ist, kann man sich bei Ebay auch nach einem Clone vom PICKIT2 oder PICKIT3 umsehen. Diese kosten im Moment zwischen 15€ und 25€.

== Missverständnisse und Eigenheiten ==
Es gibt einiges, was einen PIC-Neuling abschrecken oder verwirren könnte. Manchmal hört man z.B. dass kaum oder schlechte Peripherie verbaut wurde, wobei dies meist, wenn überhaupt zutreffend, für sehr alte PICs gilt (90er Jahre). Neue PICs habe oft mehr/bessere Peripherie als ATmegas. Es wird auch oft bemängelt, dass der Quarz-Takt bei 8bit PICs durch 4 und bei 16bit PICs durch 2 geteilt wird. Dafür werden so gut wie alle Befehle in einem System-Takt ausgeführt, wo andere mehr brauchen. 8bit PICs gibt es mit bis zu 64MHz (16 MIPS).
Fallen für Neulinge gibt es nur wenige und unkritische (im Vergleich zum „verfusen“ eines [[AVR]]s). Es muss zum Beispiel bedacht werden, dass, um auf manche Register zugreifen zu können, die Bank gewechselt werden muss - dies macht ein [[C]]-[[Compiler]] aber automatisch. Außerdem muss die geplante Vierteilung von oben bedacht werden, um Zeitschleifen zu berechnen. Verwirrend kann gerade für Leute, die den [[AVR]] gewohnt sind sein, dass das Register zum Konfigurieren der IOs eine 1 für einen Eingang braucht, und keine 0. Doch merken kann man sich, dass die 1 wie ein großes I aussieht und für Input -> Eingang steht. Andersrum steht die 0 für ein großes O wie Output -> Ausgang.

Wer sich hier im Forum schon mal rumgetrieben hat, kann eventuell auch den „kleinen Krieg“ zwischen [[AVR]] und PIC mitbekommen haben. Dazu will ich auch nur sagen, dass an sich jeder Microcontroller seine Daseinsberechtigung hat. Ob PIC oder [[AVR]], ob 8 Bit oder 32 Bit. Deswegen sollte man einfach die Microcontroller ausprobieren und selbst entscheiden. Wenn jemand sich einen, meiner Meinung nach guten Vergleich zwischen [[AVR]] und PIC angucken will, kann sich das ->[http://www.youtube.com/watch?v=DBftApUQ8QI EEVBlog #63]<- Video auf Youtube angucken. Da wird auch erläutert, warum es keinen Grund gibt, einen der beiden Microcontroller zu meiden. Zudem ist es auch etwas unprofessionell, ohne selbst eigene Erfahrung gesammelt zu haben, eine Familie oder sogar einen ganzen Hersteller abzuschreiben.

== Alte und neue PICs ==
Microchip stellt schon seit Anfang der 90er Microcontroller her. Damals war die Technik logischerweise noch nicht auf dem Stand wie heute. Es wird immer kleiner und dennoch schneller und stromsparender. Doch da manche wohl einfach nicht von den alten PICs loskommen, werden diese Heutzutage auch noch teilweilse eingesetzt. Außerdem gibt es mehrere (oft alte) fertige Projekte, die eben so einen alten PIC verwenden und da viele die Projekte nachbauen und nichts neu programmieren (wollen), sind diese PICs immer wieder oft zu finden. Die neuen PICs sind nicht nur Stromsparender und haben mehr Platz, sondern sind auch noch billiger. Ich hab mal zwei alte/ältere und oft zu findende PICs rausgesucht (PIC16F84A und PIC16F887) und einfach mal mit neuen PICs der selben Pinzahl und Bauform(DIP) verglichen:

{| class="wikitable"
|+ '''PIC16F84A vs. PIC16F1827'''
|-
! || PIC16F84A || PIC16F1827
|-
| ROM/Flash || 1k Word || 4k Word
|-
| SRAM || 68 Byte || 384 Byte
|-
| EEPROM || 64 Byte || 256 Byte
|-
| Pins/IOs || 18/13 || 18/16
|-
| Max. Frequenz || 20MHz || 32MHz
|-
| Internal Oscillator || - || 32MHz, 32kHz
|-
| Comparators || 0 || 2
|-
| ADC-Channels || 0 || 12
|-
| Communication || - || 1xUART, 2xI²C/SPI
|-
| CCP || - || 2xECCP, 2xCCP
|-
| Timer || 1x8bit || 4x8bit, 1x16bit
|-
| Preis Reichelt (30.03.2012) || 3,15€ || 1,60€
|}

{| class="wikitable"
|+ '''PIC16F887 vs. PIC16F1939'''
|-
! || PIC16F887 || PIC16F1939
|-
| ROM/Flash || 8k Word || 16k Word
|-
| SRAM || 368 Byte || 1024 Byte
|-
| EEPROM || 256 Byte || 256 Byte
|-
| Pins/IOs || 40/36 || 40/36
|-
| Max. Frequenz || 20MHz || 32MHz
|-
| Internal Oscillator || 8MHz, 32kHz || 32MHz, 32kHz
|-
| Comparators || 2 || 2
|-
| ADC-Channels || 14 || 14
|-
| Communication || 1xUART, 1xI²C/SPI || 1xUART, 1xI²C/SPI
|-
| CCP || 1xECCP, 1xCCP || 3xECCP, 2xCCP
|-
| Timer || 2x8bit, 1x16bit || 4x8bit, 1x16bit
|-
| Preis Reichelt (30.03.2012)|| 2,65€ || 2,15€
|}

Hier sieht man gerade bei dem verbreitetem PIC16F84A, dass dieser aus heutiger Sicht total klein, schlecht und dafür überteuert ist und man für das gleiche Geld 2 bessere bekommt. Der einzige Grund, der für ältere PICs spricht, ist der, dass man eine vorhandene Software benutzen und nicht umschreiben will. Sollte es aber ein neues, eigenes Projekt werden, tut euch einen Gefallen, spart Geld und kauf neue PICs ;)

== Bezugsquellen ==

=== Controller ===

Versandhäuser für Privatpersonen
* [http://reichelt.de/PIC-Microcontroller/2/index.html?;ACTION=2;LA=2;GROUPID=2961;SHOW=1; Reichelt]
* [http://de.rs-online.com/web/c/?sra=oss&searchTerm=pic&x=0&y=0 RS-Online]
* [https://www.distrelec.de/ishopWebFront/search/luceneSearch.do?dispatch=show&fromCatalog=true&filterHierarchyNodeId=178072&filterHierarchyLevel=5&hierarchyDepth=0&autoAttributeEnabled=false Distrelec]

=== Evaluation Boards ===

* [http://de.farnell.com/jsp/search/browse.jsp?N=2008+202682&Ntk=gensearch&Ntt=pic&Ntx=mode+matchallpartial Farnell] Microchip Boarde
* [http://thinkembedded.ch/PIC:::12.html Thinkembedded Webshop] Olimex Boarde
* [http://www.futurlec.com/Boards.shtml Futurelec]
* [http://pic-projekte.de/wordpress/?p=653 StartPIC18]

== Links und Literatur ==
* [http://www.microchip.com/ Microchip Homepage]
* [http://www.htsoft.com/ Hi-TECH Homepage]
* [http://www.bknd.com/cc5x/ CC5X Homepage]
* [http://www.mikroe.com/eng/home/index MikroElektronika Homepage]
* [http://pic-projekte.de/phpBB3/ PIC-Forum (deutsch)]
* [http://sprut.de/ Sprut Homepage]
* [http://pic-projekte.de/ Tutorials (PIC/C) und PIC-Forum]
* [http://sprut.de/electronic/pic/projekte/brenner8/index.htm Brenner8 Projektseite]

[[Kategorie:Mikrocontroller]]
[[Kategorie:PIC| ]]

Zoll und Abgaben

2016-03-13T15:27:56Z

8023: müll

==Grundsätzlich==
Grundsätzlich gilt:
* Sitzt der Versender in der EU, ist für Privatpersonen alles harmlos. Der Versender zahlt die Umsatzsteuer (Mehrwertsteuer) in seinem Land und fertig. Der Zoll kommt gar nicht ins Spiel.

Der Rest dieses Wiki-Eintrags beschäftigt sich hauptsächlich mit dem Versand aus dem nicht-EU Ausland.

* Der Zoll ist nicht doof und kennt die gängigen und weniger gängigen Tricks. Das ist deren Job. Da sind die gut drin.
:Wenn ein asiatischer Versender auf ein Paket in der Zollerklärung "''Geschenk, Wert $40''" schreibt, dann ist es fast sicher, dass sich der deutsche Zoll das genauer ansieht. Ebenso glaubt der Zoll nicht an kostenlosen Versand und nimmt regelmäßig ziemlich saftige Versandgebühren an, die dann versteuert werden. Passiert das, und kann man die echten Kosten nachweisen, kann man gegen den Steuerbescheid Widerspruch einlegen. Wie das geht, sollte in einer Rechtsbehelfsbelehrung auf dem Steuerbescheid stehen.

* Gültige Informationen finden sich unter http://www.zoll.de.

* Unterlagen, Mails, etc. gut durchlesen und entsprechend handeln. Wegschauen, den kleinen Doofen spielen, ignorieren usw. hilft nicht.

==Kosten==
Bei einem Angebot aus dem Ausland (besonders Nicht-EU) sollten folgende Kosten auf jeden Fall mit einkalkuliert werden:
* Einfuhrumsatzsteuer
::Vereinfacht ausgedrückt das Äquivalent zur Mehrwertsteuer das bei der Einfuhr anfällt [http://www.zoll.de/DE/Fachthemen/Steuern/Einfuhrumsatzsteuer/einfuhrumsatzsteuer_node.html]. Zur Zeit 19%.

* Einfuhrzoll
::Hängt von der Warenart ab und ist in der EU einheitlich in der TARIC-Liste geregelt [http://ec.europa.eu/taxation_customs/dds2/taric/taric_consultation.jsp]. Die gute Nachricht ist, dass viele für den Bastler interessante Waren einen niedrigen Zollsatz oder sogar gar keinen haben.

* Bankgebühren (Währungsumrechnung, Kreditkartengebühren, Transfergebühren, etc.)
::Beliebter Beschiss eines Marktplatzes mit eigenem Zahlungsdienst: Auf dem Marktplatz werden unverbindliche "ca." Umrechnungskurse verwendet, die "zufälligerweise" immer günstiger sind als die Umrechnungskurse, die der eigene Zahlungsdienstleister nur Sekunden später verwendet.
::Beliebte Falle bei Kreditkarten: Es wird mit einer günstigen prozentualen Gebühr für die Währungsumrechnung geworben, die aber wegen einer saftigen Mindestgebühr gar nicht zum Tragen kommt.

* Versandgebühren (Versand, Zollpapiere)

* Bearbeitungsgebühren, Servicegebühren des Kurierdienstes
::Kurierdienste, auch DHL '''Express''', schlagen diese Gebühren nachträglich für fiktive oder reale Tätigkeiten drauf. So zum Beispiel dafür, dass sie eine Sendung vorgeblich oder wirklich beim Zoll zur Abfertigung vorstellen und die entsprechenden Papieren vorgeblich oder wirklich ausfüllen. Warum diese Gebühren nicht Teil der Versandkosten sind, bleibt das Geheimnis der Kurierdienste.

::Einige Kurierdienste sind für ihre extrem hohen Gebühren berüchtigt. Darunter zum Beispiel alle, die ihre Einfuhr in Deutschland durch die [https://www.gdsk.de/ger/index.html GDSK] erledigen lassen, wie zum Beispiel EMS China oder manchmal FEDEX. Ebenso DHL '''Express''' (siehe unten).

:Einige Kurierdienste sind dafür bekannt, dass deren Mitarbeiter schlicht und ergreifend nicht wissen was sie tun. Da werden dann mehr oder weniger zufällig Gebühren aus der Preisliste berechnet. Beliebt ist zum Beispiel, dass für jeden Einzelposten Gebühren berechnet werden, statt für die gesamte Sendung. Ebenso beliebt ist es, Gebühren, die bereits abgebucht wurden, nochmals bei Auslieferung an der Haustür zu erheben.

::Eigentlich ist es so, dass ein Kurierdienst vom Empfänger mit der Verzollung beauftragt werden muss, sonst kann er sich die Gebühren in die Haare schmieren. In der Praxis wird das manchmal noch ignoriert. Alternativ versuchen manche Kurierdienste den Kunden dadurch unter Druck zu setzen, dass sie eine entsprechende Benachrichtigung mit der Bitte um Auftragserteilung extrem spät versenden. So hat der Kunde praktisch keine andere Wahl, als den Auftrag zu erteilen oder es entstehen zusätzliche Lagergebühren oder die Ware geht zurück.

::Wer solche Gebühren vermeiden möchte, kann unter Umständen eine ''Selbstverzollung'' durchführen, die allerdings einige Mühe macht. Das funktioniert natürlich nur, wenn man genug Zeit hat, siehe oben. Allerdings haben Kurierdienste neben der späten Benachrichtigung noch einen Trick auf Lager:
::*Gebühr für die Übergabe zur Selbstverzollung
:::Sie kassieren also dafür, dass sie eine Leistung nicht erbringen.

::Eine Sonderregelung gibt es bei der Post, aber nicht für alle Teile des Postkonzerns. Die Post berechnet bei per "echter" Post versendeter Waren keine Gebühren für die Vorführung zur Verzollung. Der zur Post gehörende Kurierdienst DHL '''Express''' berechnet seit dem 1.6.2014 eine ''Kapitalbereitstellungsprovision'' von 2%, aber mindestens 10€ + 19% MWSt = 11,90€.

Das sind aber noch nicht alle Kosten, die anfallen können. Im schlimmsten falls entstehen z.B. noch
* Zollkosten durch Amtshandlungen oder Lagerung.
::Schon deshalb sollte man auf Schreiben oder andere Nachrichten unverzüglich reagieren.

==Checkliste==
Checkliste für den Kauf im Ausland:
* Artikelbeschreibung genau lesen
* ist der Import überhaupt legal (Plagiat, Konformität) bzw. anmeldepflichtig
* Einfuhrabgaben, z.B. Einfuhrumsatzsteuer
* Zollgebühren (basieren auf der )
* Bankgebühren (Währungsumrechnung, Transferkosten)
* Versandkosten (bzw. was der Zoll bei kostenlosem Versand veranschlagt)
* Versandart und Dienstleister (hat großen Einfluss auf den Zolldurchlauf, ggf kassiert der Dienstleister die Gebühren einfach bei Lieferung an der Haustür)

==Praktisches==
===Post, DHL===
====Unterschied Post/DHL/Post-Paketdienst zu DHL Express====

DHL war ursprüngliche eine Spedition, die die Post übernommen hat. DHL enthielt auch einen Kurierdienst, der mit der Übernahme von DHL als DHL '''Express''' zur Post kam. Darüber hinaus begann die Post die Bezeichnung DHL auch für andere Bereiche, wie ihren ganz normalen Paketdienst zu verwenden.

Wenn es um Zoll und Abgaben beim Import aus dem Nicht-EU-Ausland geht, muss man zwei DHL-Bereiche innerhalb der Post unterscheiden, da die Abläufe in diesen Bereichen völlig verschieden sind:

;DHL: Der normale Post-Paketdienst
:Diese hat, wie weiter unter beschrieben, noch Sonderrechte aus der alten Zeit der Post als Behörde (Bundespost).

;DHL '''Express''': Der mit DHL zur Post gekommene Kurierdienst
:DHL '''Express''' verhält sich wie ein Kurierdienst und hat (oder nutzt) die Sonderrechte der Post bei der Einfuhr nicht.

Man hat zwar ein gemeinsames Logo und die selbe Konzernfarbe, aber beide dieser DHLs, der Post-Paketdienst und der Kurierdienst, arbeiten im Postkonzern so nebeneinander her. Sie haben unterschiedliche Abläufe, Verfahren und Preise. DHL '''Express''' ist eine eigene Welt innerhalb des Postkonzerns. DHL '''Express''' unterteilt sich intern nochmal in einen nationalen und internationalen Bereich. Dazu scheint es einen oder mehrere spezielle Bereiche an den 'Hubs' für den Import und die Zollabwicklung zu geben. Bei all diesen Bereichen hat man den Eindruck, dass sie so nebeneinander her arbeiten und man nicht viel miteinander redet, reden möchte oder reden darf.

Selbstverständlich wird vom Kunden erwartet, dass er die interne Organisation im Detail kennt. Wehe dem Kunden, der versehentlich bei der falschen Hotline anruft oder im falschen Bereich landet. Da wird schon mal behauptet, dass eine Abteilung kein Telefon hätte.

====DHL Express====
DHL Express ist ein Kurierdienst, eine Spedition. So verhält sich DHL Express auch. Im Gegensatz zur Post, mit ihrem Paketdienst DHL, hat DHL Express keine Sonderrechte beim Import von Lieferungen aus dem Ausland (oder sie nutzen diese nicht).

DHL Express liefert nicht an DHL Packstationen und hat keinen Zugang zu DHL Paketkästen. DHL Express gibt Lieferungen auch nicht bei der nächsten Post oder Postagentur zur Selbstabholung ab. Ebenso funktioniert der DHL Wunschfilialen-Service nicht bei Lieferungen per DHL Express.

DHL Express fährt nicht zustellbare Lieferungen lieber 100 km oder 200 km zu ihrer nächsten ''DHL Express Station'' zurück. Es gibt von diesen ''DHL Express Stationen'' nur 30 in ganz Deutschland. Wer nicht wirklich das Glück hat zufällig in der Nähe der richtigen Station zu wohnen hat keine Möglichkeit der Selbstabholung.

Insgesamt ist die nicht-Integration von DHL Express in den normalen DHL-Service ein ziemliches Armutszeugnis für das Post/DHL-Management.

DHL Express erhebt seit dem 1.6.2014 sehr kreative Gebühren. Seit dieser Zeit verlangt DHL Express eine ''Kapitalbereitstellungsprovision''<ref>[http://www.dhl.de/content/dam/dhlde/downloads/express/dhl-express-preise-und-laufzeiten-012015.pdf DHL Express Preisliste]</ref>:

:''Provision für die Benutzung des DHL Express eigenen Aufschubkontos zum Zwecke der Kapitalbereitstellung für anfallende Steuern und Zölle | 2 % der verauslagten Einfuhrabgaben; mind. 10,00 EUR''

Darauf fallen noch 19% Mehrwertsteuer an, also mindestens 11,90€ Kapitalbereitstellungsprovision. Angeblich kann man das ominöse Aufschubkonto dadurch umgehen, dass man bei DHL Express ein Kundenkonto eröffnet und DHL die Abbuchung vom eigenen Bankkonto erlaubt. Nach diversen Berichten braucht man dazu angeblich eine [http://www.zoll.de/DE/Fachthemen/Zoelle/EORI-Nummer/eori-nummer_node.html EORI Nummer] und muss damit bei DHL Express mittels Post-Ident-Verfahren ein SEPA-Mandat erteilen.

DHL Express' Verhalten macht DHL Express für Privatpersonen sehr unattraktiv. Vielleicht ist dies durchaus gewollt.

====Post, Post-Paketdienst DHL - aber nicht DHL Express====

Die Post, mit ihrem Paketdienst DHL (aber nicht DHL Express) genießt bei der Einfuhr einige Sonderrechte, im Gegensatz zu Kurierdiensten wie DHL Express. Diese stammen noch aus der Zeit als die Post eine Behörde war. Daher kann es von Vorteil sein, Waren mit der Post versenden zu lassen. Allerdings vermindert sich der Vorteil immer mehr, da die Post für die frühere Amtshandlung der nachträglichen Postverzollung nun auch gebühren verlangt.

Unter anderem darf die Post selber entscheiden, ob eine Sendung dem Zoll vorgeführt werden muss oder nicht. Wenn entschieden wurde eine Sendung nicht dem Zoll vorzuführen erhält sie einen grünen Aufkleber

:'''Von zollamtlicher Behandlung befreit - Deutsche Post ''<Name des Postamts>'''''

und wird einfach zugestellt.

Führt die Post eine Sendung beim Zoll vor, und können die entsprechenden Abgaben bestimmt werden, dann kassiert die Post diese Abgaben für den Zoll bei der Auslieferung der Sendung an der Haustüre. Dafür berechnet die Post keine Gebühren. (Siehe http://www.zoll.de/SharedDocs/Boxen/DE/Fragen/0074_sendungen_direkt_zugestellt.html)

Führt die Post eine Sendung beim Zoll vor, und die entsprechenden Abgaben können nicht bestimmt werden, weil zum Beispiel keine glaubhafte Rechnung vorliegt, oder es besteht der Verdacht die Einfuhr ist nicht legal [http://www.mikrocontroller.net/attachment/249800/CCI06032015_00000.jpg], übergibt die Post die Sendung an ein Zollamt. Im Gegensatz zu Kurierdiensten, bei denen die Sendungen immer beim nächsten Zoll am Einfuhrort (Flughafen, Seehafen) landet, ist dies ein dem Empfänger relativ naheliegendes, zuständiges Zollamt. Die Sendung kommt also schon mal halbwegs in die richtige Richtung und bleibt, im Gegensatz zu Kurierdiensten, nicht am Flughafen oder im Hafen liegen.

In diesem Fall erhält man von der Post eine Aufforderung entsprechende Unterlagen beim Zollamt einzureichen (siehe http://www.zoll.de/SharedDocs/Boxen/DE/Fragen/0075_sendung_liegt_beim_zoll.html) Reicht man die Unterlagen persönlich ein werden diese überprüft, man zahlt direkt und nimmt die Sendung mit.

Alternativ kann man die Post mit der sogenannten nachträglichen Postverzollung beauftragen. Die Post verlangt dafür seit August 2015 eine Gebühr von 28,50 Euro. Dazu kommen die eigentlichen Zollgebühren, Abgaben und Steuern. Man muss natürlich trotzdem die vom Zoll geforderten Unterlagen bereitstellen. Der Zoll übergibt nach der Berechnung der Abgaben die Sendung wieder der Post. Die stellt die Sendung zu und kassiert.

===Diverses===
Praktische Regelungen (Stand Anfang 2014):
* Geschenke von Privatpersonen bis 45 EUR gehen meist ohne weitere Abgaben durch.
* Waren bis 150€ sind zollfrei, ab 22€ fallen jedoch 19% Umsatzsteuer an.
* Einfuhrabgaben von weniger als 5 Euro werden nicht erhoben.
* ... manchmal hat man einfach Glück. Da hatte der Zoll dann wohl was wichtigeres zu tun.

===Merkwürdigkeiten===
====Diverses====
Gerade bei asiatischen Versendern kann man immer wieder diverse Merkwürdigkeiten erleben

* Es wird behauptet die Ware sei bereits in Deutschland oder der EU. In Wirklichkeit wird sie dann z.B. aus China versendet und man wird unvorhergesehen mit zusätzlichen Abgaben konfrontiert. Eventuell hilft eine Beschwerde beim Marktplatz über den man gekauft hat.

* Der Absender der Sendung stimmt nicht mit dem Verkäufer überein.
:Das ist bei chinesischen Verkäufern völlig normal. Die agieren gerne mit mehreren Fantasienamen gleichzeitig auf Marktplätzen wie eBay und/oder der Verkäufer betreibt Dropshipping [http://de.wikipedia.org/wiki/Streckengesch%C3%A4ft].

* Die Zollinhaltserklärung auf der Sendung hat rein gar nichts mit dem Inhalt der Sendung zu tun.
:Leider ist das bei chinesischen Versendern auch völlig normal. Zum Teil ist es einfach Schlamperei, zu Teil ist es der Versuch Zölle zu umgehen. Einige chinesische Versender preisen eine falsche Zolldeklaration sogar als Service an. Natürlich kennt der deutsche Zoll diesen "Trick" nur allzu gut (siehe [http://www.zoll.de/DE/Privatpersonen/Post-Internet/Sendungen-aus-einem-Nicht-EU-Staat/Zoll-und-Steuern/Geschenksendungen/frage_6.html]). Bestenfalls nützt er nichts, im schlimmsten Fall erregt die Sendung damit die besondere Aufmerksamkeit des Zolls. Leider kann man chinesischen Versendern diese Unsitte nicht ausreden.

* Fehlen von jeglichen Versandpapieren (Rechnung, Lieferschein, etc.)
:Auch das ist bei chinesischen Versendern völlig normal und verzögert eventuell die Zollabfertigung. Auch diese Unsitte kann man chinesischen Versendern nicht ausreden.

* Die Sendung enthält eine dubiose (unbekannte Firma, Postfach) Rücksendeadresse in Deutschland.
:Der Versender benutzt einen Dienstleiter, der für ihn nicht zustellbare Sendungen einsammelt. Versendet wurde trotzdem aus dem Ausland. Der Dienstleister hinter der Adresse will mit irgendwelchen Problemen bei der Einfuhr nichts zu tun haben.

* Der Versand dauert lange und der Versender behauptet die Ware liegt beim Zoll.
:Das ist eine beliebte Ausrede, die aber nicht stimmt. Der Zoll sammelt keine Ware um sie später zu kontrollieren, sollte man sich beim Zoll langweilen. Der Zoll ist permanent ausgelastet oder überlastet. Der muss sich nichts "für schlechte Zeiten aufheben".

:Wahrscheinlicher ist dass die Ware (noch) nicht versendet wurde, sie verloren ging, der Spediteur/Kurier überlastet ist und die Ware noch gar nicht beim Zoll vorgeführt hat (Ware liegt im Container im Lager des Spediteurs) oder die angeblich per Luftpost versendete Ware dümpelt noch in irgendeinem Seecontainer auf einem Seelenverkäufer herum.

:Das man vom Versender mit einer Lüge bedacht wurde, merkt man zum Beispiel dann, wenn die Ware ohne Trackingnummer versendet wurde. Woher will der Versender ohne Tracking wissen, wo sich die Ware gerade befindet?

* Es kann passieren, dass ein Versender mit seiner lokalen Post versendet und die Auslieferung in Deutschland trotzdem durch einen Kurierdienst und nicht durch die deutsche Post erfolgt - mit für Kurierdiensten üblichen Zusatzgebühren. Beispiel EMS China -> GDSK.
:In diesem Fall hat die Post des Absenders aus Kostengründen eine Vereinbarung mit dem Kurierdienst und hat die Sendung an den Kurierdienst übergeben. Der Zoll sieht nur die Einfuhr durch den Kurierdienst und behandelt die Einfuhr entsprechend.

* 'Querschläger'
:Da kommt eine Lieferung aus China plötzlich mit der Post zum Beispiel aus Singapur, den Niederlanden oder Großbritannien. Das ist ein Zeichen für die Kreativität chinesischer Versender wenn es um das Einsparen von Versandgebühren geht. Der Versender hat die Ware auf anderem Weg (Seefracht, Kurier) in das entsprechende Land verbracht und der dortigen Post übergeben. Ein solches Vorgehen bricht regelmäßig das Tracking.
:Beim diesem Weiterversand per Post kann es passieren, dass die Auslands-Post die Sendung ebenfalls an ein deutsches Binnenzollamt übergibt wenn sie das für nötig hält. Dann erhält man vom Zollamt eine Benachrichtigung über eine Sendung aus einem Land aus dem man eventuell gar keine Sendung erwartet.

* Manche Versender übernehmen mit ihren Versandgebühren auch die Umsatzsteuer, Zoll und Kuriergebühren. Leider kommt es immer wieder vor, dass der Kurierdienst sich nicht an die Vereinbarung mit dem Versender gebunden fühlt und trotzdem noch Gebühren für die Vorführung beim Zoll und Zollgebühren verlangt. Der einzige, der einem in so einem Fall helfen kann ist der Versender. Als Empfänger wird man von Kurierdiensten nicht ernst genommen, es lohnt sich nicht mit denen zu diskutieren.

====eBay Global Shipping Program, Pitney Bowes====
eBay bietet für US-Versender einen Dienst an, bei dem ein Dienstleister, Pitney Bowes, den Versand nach Deutschland übernimmt (''Global Shipping Program''). Da viele US-Versender sich bei dem Gedanken an einen Versand ins Ausland ins Hemd scheißen, nehmen sie immer häufiger diese Dienstleistung in Anspruch.

Der Dienstleister wird vom Käufer, also von uns, bezahlt. Die in eBay-Angeboten angezeigten Gebühren sind nur unverbindliche Schätzungen und man verpflichtet sich laut AGB [http://pages.ebay.de/shipping/globalshipping/buyer-tnc.html#programfees] alles zu zahlen was später verlangt wird. Ebenso stimmt man zu, die zolltarifliche Einstufung der Ware durch den Dienstleiter nicht zu hinterfragen. Man liefert sich auf Gedeih und Verderben dem Dienstleister aus, der irgendwo in Kentucky seine Entscheidungen fällt.

Hinzu kommt, dass der Dienstleister den Transport nicht selbst durchführt, sondern eigenständig einen Kurier aussucht. Man hat keine Kontrolle darüber mit welchem Kurierdienst die Ware geliefert wird und was der beim deutschen Zoll veranstaltet. Es gibt Berichte im Internet, dass der Dienstleister gut verpackte Ware umpackte und die Verpackung aus Kostengründen durch eine leichte, aber ungeeignete ersetzte. Die Ware wurde dann einem billigen Kurier ohne Transportversicherung übergeben.

Pitney Bowes Kerngeschäft ist die Herstellung von Frankiermaschinen und anderen Gerätschaften für die Sortierung und den Transport von Post. Man hat es mit der geballten Kompetenz eines Herstellers von Stempelsystemen im internationalen Zollsystem zu tun. Ähm ja ...

Völlig unklar ist, ob Pitney Bowes die über das System kassierte Einfuhrumsatzsteuer an den deutschen Fiskus entrichtet. In den AGBs ist der Käufer dafür verantwortlich. Bei ebay wird man aber darüber getäuscht, es heisst, dass "Keine zusätzlichen Gebühren bei Lieferung!" anfallen würden.
Tatsächlich interessiert das das Zollamt nicht, und die Einfuhrumsatzsteuer musste erneut entrichtet werden!

====Dynamic Currency Conversion (DCC)====

Bietet ein Verkäufer in einem Nicht-Euroland eine Kartenzahlung in Euro an sollte man vorsichtig sein. Wahrscheinlich verwendet er Dynamic Currency Conversion (DCC)

DCC ist ein Verfahren bei der Bezahlung mit Kreditkarte oder anderen Karten, bei Zahlungen in ausländischer Währung (also nicht Euro), welches häufig zu Ungunsten des Zahlenden ausgenutzt wird. Der Trick liegt in

* der Verwendung sehr ungünstiger Wechselkurse,
* dem Aufschlagen von diversen erfundenen Gebühren für den Service,
* der Unwissenheit des Käufers über den offiziellen Wechselkurs und möglicher Gebühren,
* dem verklausulierten Angebot von DCC "Do you want to pay in Euros?". Der Zahlende soll nicht merken dass er DCC "gewählt" hat.

Normalerweise rechnen bei Auslandszahlungen der Verkäufer in seiner Landeswährung gegenüber dem Käufer und Kreditkartenunternehmen ab. Erst das Kreditkartenunternehmen rechnet die Landeswährung in die Währung des Käufers (Euro) um. Dabei ist das Kreditkartenunternehmen an gesetzliche Vorgaben zum Währungskurs gebunden. Zusätzlich erhebt das Kreditkartenunternehmen eine Gebühr. Auch bei der Gebühr gibt es gesetzliche Beschränkungen.

Bei DCC bietet der Verkäufer dem Käufer eine Abrechnung in Euro, also nicht in seiner Landeswährung, an. Die Umrechnungskurse, die dabei verwendet werden sind typischerweise sehr ungünstig. Die Abrechnung erfolgt nicht direkt gegenüber dem Kreditkartenunternehmen, sondern einem Dritten, einem sog. Acquirer.

Der Acquirer legt den für den Kaufer ungünstigen Umrechnungskurs willkürlich fest. Er zahlt den Verkäufer in seiner Landeswährung aus, plus einem Bonus ("Schmiergeld"). Der Bonus soll den Verkäufer animieren so viele Kunden wie möglich zu DCC zu bewegen.

Der Acquirer rechnet die Landeswährung in Euro um. Dabei berechnet er, zusätzlich zum ungünstigen Wechselkurs willkürlich Gebühren in Euro. Er belastet dann die Kreditkarte des Kunden in Euro, einschließlich seiner Gebühren.

In der Summe ist es sehr wahrscheinlich, dass die bei DCC anfallenden Gebühren und der ungünstige Wechselkurs höher sind, als wenn das Kreditkartenunternehmen umrechnet und Gebühren erhebt.

=Beschwerden=

Kurierdienste, die Post, DHL, etc. sind alle ziemlich immun gegen Beschwerden oder Bitten um Hilfe. Sie haben kein Problem damit Beschwerden hartnäckig zu ignorieren. Man kann es als "Erfolg" werten, wenn man wenigstens so weit vorgedrungen ist, dass man nach ein paar Wochen einen nutzlosen, nicht unterschriebenen Formbrief "''Was mit der an Sie gerichteten Sendung geschehen ist, können wir nicht feststellen.''"<ref>Zitat Kundenservice Deutsche Post.</ref> erhält.

Was je nach Situation helfen kann:

* Beim Absender beschweren
:Kurierdienste, die Post, DHL etc. nehmen Absender ernster als Empfänger. Aus deren Sicht ist der Absender, nicht der Empfänger, der Kunde. Denn formal beauftragt der Absender und zahlt die Gebühr an den Kurierdienst.

* Öffentlich über Facebook oder Twitter beschweren
:Aus Gründen, die sie vermutlich nicht einmal selbst kennen, werden die Unternehmen bei öffentlichen Beschwerden über Facebook oder Twitter plötzlich sehr aktiv. So antwortet DHL auf Twitter häufig mit einer speziellen E-Mail Adresse, über die die Beschwerde dann bearbeitet wird, während Beschwerden an DHLs offizielle Serviceadresse unbeantwortet bleiben.

:Gelegentlich fahren Kurierdienste irgendwelche Imagekampagnen. Diese Kampagnen sollte man nicht allzu ernst nehmen. Sollte die Kampagne im "Social Web" laufen kann man sie allerdings nutzen um eine Beschwerde noch öffentlichkeitswirksamer anzubringen.

=Hilfreiche Links=
<references />
* http://www.zoll.de/
* Muster: http://www.zoll.de/DE/Fachthemen/Zoelle/Zollbefreiungen/Aussertarifliche-Zollbefreiung/Absatzfoerderung/Warenmuster-und-proben/warenmuster-und-proben_node.html
* Geschenke: http://www.zoll.de/DE/Privatpersonen/Post-Internet/Sendungen-aus-einem-Nicht-EU-Staat/Verfahren/frage_4.html?nn=115522
* geringer Wert: http://www.zoll.de/DE/Privatpersonen/Post-Internet/Sendungen-aus-einem-Nicht-EU-Staat/Zoll-und-Steuern/Sendungen-mit-geringem-Wert/sendungen-mit-geringem-wert.html
* Kosten allgemein: http://www.zoll.de/DE/Privatpersonen/Post-Internet/Sendungen-aus-einem-Nicht-EU-Staat/Zoll-und-Steuern/zoll-und-steuern_node.html

[[Kategorie:Lieferanten]]

Nachttischlampe

2016-03-13T15:27:37Z

8023: müll

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

== Einleitung ==
Ausgehend von den von den Unzulänglichkeiten meiner bisherigen Nachttischlampe und der mich nicht überzeugenden Funktion einer Beleuchtung für den Schlafraum eines niederländischen Herstellers, entstand die Idee zu diesem Projekt.
Im Ergebnis ergeben sich ein angenehmeres Aufstehen, mehr Komfort und die Möglichkeit bei einem von zwei Personen bewohntem Schlafzimmer einander weniger zu stören.
=== Features für den Nutzer ===
* Zwei separate Beleuchtungskanäle
** Hintergrundbeleuchtung
** Leselicht
* Intuitive Bedienung über einen Drehencoder mit Tastfunktion
** Dynamische Schrittweitenanpassung für die schnelle und genaue Einstellung der Helligkeit und anderer Werte
* Anzeige mit 16x2 hintergrundbeleuchtetem LCD
* Anpassung der Helligkeitssteuerung an die Empfindlichkeitskurve des menschlichen Auges
* Anpassung der Helligkeit an das Umgebungslicht
* Fernbedienbar
* Vernetzbar innerhalb eines Raumes
** Synchronlauf der Helligkeiten von Lampen aktivierbar
** Alarmfunktion kann andere Lampen aktivieren
* Weck-Funktion
** Bis zu 7 wochentagsabhängige oder - unabhängige Alarme
** Alarme überspringbar
** Alarmsignal durch
*** separat in Zeit und Helligkeit einstellbares Eindimmen von Hintergrund- und Leselicht
*** angenehmes akustisches Signal mit einstellbarer Verzögerung zum Alarmstart und ansteigender Lautstärke

=== Technische Eigenschaften ===
* LEDs
** Nichia NS6W183 auf Star-Platine
** 4 Stück warmweis für die Hintergrundbeleuchtung
** 2 Stück kaltweiss für das Leselicht
** andere LED Bestückungen bis 5 LED je Strang bei 24V Eingangsspannung möglich
* LED-Treiber
** Zwei unabhängige PWM-gesteuerte Kanäle
** Nachführung der PWM-Frequenz zur Vergrößerung des dynamischen Bereiches der LED-Treiber ohne Flackern der Beleuchtung
** Zwei verschiedene Treiber möglich:
*** Diodes ZXLD1362
*** Diodes ZXLD1374
** Hysteric Step-Down-LED-Driver
** maximal 60V, 1A bzw. 1,5A; 24V, 500mA in diesem Projekt
* Step-Down Regler für Steuer-Modul
** Zwei verschieden Schaltregler möglich
*** LM2674 ADJ auf 3,3V eingestellt, maximale Eingangsspannung 40V
*** LT1676 auf 3,3V eingestellt, maximale Eingangsspannung 60V
* MCU
** NXP 89LPC936, 8051 mit 2-Takt Kern
** 16k Byte Flash (ca. 10k Byte belegt), 768 Byte RAM, 512 Byte EEPROM, ISP
** 3,3 Volt, niedriger Stromverbrauch
** 6 MHz Takt mittels Resonator, 18 MHz maximal
** 8 Bit DAC und ADC
** 16 Bit CCU mit PLL und 4 Kanälen
* LCD
** Electronic Assembly DOGM162W-A mit amber-farbener Hintergrundbeleuchtung
** Hintergrundbeleuchtung mit PWM-Ansteuerung
** Anschluss an MCU via SPI
* RTC RV 3029-C2 mit integriertem Quarz
* Erzeugung des akustischen Signals
** DDS zur Erzeugung eines sauberen und angenehmen Sinussignals
** Alternativ: Hardware vorbereitet für das Abspielen von unkomprimierten Audiodaten aus 4M Byte Flash
** Ausgabe über DAC im MCU
** Tiefpassfilter 3. Ordnung, 8,6kHz Frequenz , mit 3/4 MCP6404
** Einstellung der Lautstärke in 4 Stufen mit CMOS-Schalter 1/2 74HC4052
** Lautsprecheransteuerung durch Brückenverstärker LM4861
* Messung der Umgebungshelligkeit
** Linearer I-U Wandler mit 1/4 MCP6404
** Widerstand über CMOS-Schalter 1/2 74HC4052 1:1000 umschaltbar in 4 Stufen
** 8-Bit ADC der MCU
** Gesamtdynamikbereich von 1:256000
** Moving-Average-Filter mit 64 Datenpunkten
* Kommunikation
** Empfängt und sendet IR-Signale gemäß RC5-Protokoll
* Stromversorgung
** Phihong, PSAA 30R-240 (30W, 24V)
** Niedrige Standby-Leistung von 300mW
** Ausreichend für zwei Lampen
** Messung der Leistungsaufnahme von der 24V Versorgung am Prototypen mit LM2674 und 2x ZXLD1362:
*** Standby: 170mW
*** Volllast: 11,5W
** Messung der Leistungsaufnahme von der 230V Versorgung an einem Netzteil mit zwei Prototypen mit LM2674 und 2x ZXLD1362:
*** Standby: 0,5W
*** Volllast: 26W
** Messung der Leistungsaufnahme von der 24V Versorgung am Prototypen mit LT1676 und 2x ZXLD1374:
*** Standby: 72mW

* Struktur
** Steuerplatine 36x100mm², doppelseitig
** Leistungsplatine 80x100mm², einseitig
** Verbindung über einzelnes 10 pol. Flachbandkabel
** Stromversorgung über Steckernetzteil

* Mechanik
** Konstruktion aus eloxierten Aluminium Profilen von Item

* Software
** Open Source C für SDCC 3.2
** Verwendet Stromsparmodi der MCU
** State-Machines für Drehencoder und RC5-Dekodierung

== Bilder ==

=== Design ===
* Symmetrisches Pärchen, Vorder- und Rückseite
[[Bild:Symmetrisches Pärchen.jpg|200px]]
[[Bild:Symmetrisches Pärchen Rückseite.jpg|200px]]
* Detail Ansteuerung, Vorder- und Rückseite
[[Bild:Detail Ansteuerung.jpg|200px]]
[[Bild:Detail Ansteuerung Rückseite.jpg|200px]]
* Detail Leselicht
[[Bild:Detail Leselicht.jpg|200px]]

=== Lichtwirkung ===
* Leselicht allein mit 10% Helligkeit
[[Bild:Leselicht 10%.jpg|300px]]
* Leselicht allein mit 100% Helligkeit
[[Bild:Leselicht 100%.jpg|300px]]
* Hintergrundlicht allein mit 10% Helligkeit
[[Bild:Hintergrundlicht 10%.jpg|300px]]
* Lese- und Hintergrundlicht zusammen mit 100% Helligkeit
[[Bild:Lese- und Hintergrundlicht 100%.jpg|300px]]

Die Bilder wurden alle bei den gleichen fixen Kamera-Einstellungen aufgenommen. Der effektive dimmbare Bereich liegt zwischen 3 und 100%. Zur PWM-Ansteuerung der LEDs wird der quadrierte Wert verwendet.

== Beschreibung ==

=== Software ===

Die Software besteht aus folgenden Teilen:
* Hauptschleife

* Interrupt-Routinen
** RC5 Decoder, ausgelöst durch Timer 0
** Update der Zeit, jede Minute durch RTC ausgelöst
** Drehencoder, ausgelöst durch Timer 1 bei 366Hz
** Update PWM-Werte und einlesen der Tasten, ausgelöst durch Timer aus RTC der MCU bei 25Hz

* Ansteuerung des Display via SPI

* Initialisierung der MCU
** Core Funktionen, hauptsächliche Stromsparfunktionen
** I/O Pins
** SPI auf Master mit 1,5MHz Takt, MSB first
** I2C auf 375kHz
** ADC fixed channel, single conversion mode für ADC0 bei 3MHz
** DAC
** Interne RTC als 25Hz Taktgeber: 6*10^6/128/25=1875 reload
** Watchdog wird abgeschaltet
** CCU output compare: non-inverted PWM, PLL: auf Lock-in abwarten
** Interrupts freischalten

* Auswertung Drehencoder

* Helligkeitsmessung

* I2C und RTC
Die Funktionen stellen einerseits die Kommunikation via I2C sicher und sind anderseits in der Lage, die RTC nach einem Batteriewechsel automatisch zu konfigurieren, die Zeit zu lesen und zu schreiben.
Die Kommunikation via I2C nutzt bisher nicht den zugehörigen Interrupt und ist nicht fehlertolerant.

* RC5 Decoder und Sender
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()").
Der Sender ist mittels Bit-Banging realisiert. Aufgrund des strikten Timings werden alle Interrupts abgeschaltet. Die Adresse für die Fernbedienung kann vom Benutzer eingestellt werden oder angelernt werden. Die Adressen für die Kommunikation der Lampen untereinander lauten 27, 28, 29.

* Optionsmenü

* Setzen der Helligkeit

* Auswertung Tasten
Es werden die Tasten entprellt und die Dauer des Tastendrucks wird festgestellt.

* Erzeugung des akustischen Signals in "AcusticDDSAlarm()"
Das Sinussignal wird mittels direkter digitaler Signalsynthese erzeugt. Dazu erzeugt ein in einer Schleife laufender Akkumulator mit Hilfe einer Tabelle von Sinuswerten einen Datenstrom der dem DAC zugeführt wird. Frequenz und Dauer der einzelnen Töne wird in einem zweidimensionalen Array in Code abgelegt.
Aufgrund des strikten Timings werden alle Interrupts abgeschaltet. Die Helligkeitsmessung wird auch unterbrochen, da die gleichen Pins die Lautstärke steuern.
Parallel werden nur die Tasten überwacht.

[[Bild:Menüstruktur V2.svg|400px]]

=== Elektronik ===
Die Elektronik gliedert sich in zwei Teile:
* Leistungsteil
* Steuerung

Der Leistungsteil entspricht im wesentlichen den Applikationsvorschlägen der Hersteller. Um Wechselwirkungen zwischen den Schaltreglern zu reduzieren wurden in den Stromzuführungen PI-Filter mit Feriten und Keramikkondensatoren eingesetzt und die gemeinsame Versorgung über einen größeren schaltfesten Elko abgeblockt.
Zur Erhöhung der Betriebssicherheit sind ferner eine Suppressor-Diode und ein Verpolschutz vorgesehen.

Variante für ZXLD1362
Die einseitige Leiterplatte kann weitestgehend in SMD aufgebaut werden. Wo möglich wurde die Bauform 1206 verwendet, damit auch selbst gefertigte Platinen verwendbar sind. Große Masseflächen dienen auch zur Verteilung der Wärme. Die Anschlussklemmen und der Elko sind so platziert, dass sie im Inneren des Aluminium-Profils Platz finden.

Variante für ZXLD1374
Gegenüber dem Entwurf mit ZXLD1362 wurde ein sparsamer Schaltregler (LT1676) für die Versorgung der Steuerung verwendet. Mit diesem Chip erhöht sich, wenn Kondensatoren und Suppressordiode angepasst werden auch die maximale zulässige Eingangsspannung.
Der LED-Treiber lässt sich deutlich besser kühlen und bietet eine bessere Dynamik in der PWM-Ansteuerung bei gleichzeitig höherer Wiederhohlrate. Letzteres reduziert den Stroboskop-Effekt beim Dimmen. Das Gehäuse erfordert jedoch eine doppelseitige Platine mit Durchkontaktierung.

Die Steuerung gruppiert sich um eine MCU von NXP der 8051 Serie. Praktisch ist die 4-kanalige 16-bit CCU mit PLL, die sowohl die beiden LED-Stränge als auch die Hintergrundbeleuchtung des LCD steuern. Das kärgliche On-Chip der klassischen 8051 hat NXP um 512 Byte aufgebessert, was die Programmierung mit dem SDCC erleichtert. Die Einstellungen vom Benutzers werden im internen EEPROM abgelegt. Ein Resonator sorgt für einen genaueren Takt als der interne RC-Oszilator und eine "bequeme, glatte" Frequenz von 6MHz.
Als RTC kommt ein externer Baustein mit integriertem Quarz, Temperaturkompensation und Batterieumschaltung zum Einsatz. Damit lässt sich eine sehr gute Frequenzkonstanz erreichen. Die Lithiumbatterie sollte eine Zeit von 220mAh/1µA = 220kh = 25a erreichen. Die Stützbatterie wird durch einen Reihenwiderstand vor Defekten in der Schaltung die zu einem Stromfluss in die Batterie führen könnten geschützt. Der Anschluss der RTC zum Datenaustausch erfolgt über die I2C-Hardware des MCU. Die interne RTC des MCU wird als Timer verwendet.
Als Display kommt eine moderne Variante des klassischen 16x2 Zeichen LCD zum Einsatz. Die Modernisierungen betreffen die digitale Kontrast-Einstellung, 3,3V-Betrieb und das SPI mit passend zur MCU geringer Pin-Anzahl.
Die Kommunikation per IR erfordert nur das entsprechende Empfangsmodul und einen kleinen MOSFET zur Ansteuerung der Sendediode. Es sind zwei positionen auf der Platine vorgesehen, damit die Richtung der Abstrahlung gewählt werden kann. Falls beide Sendedioden bestückt werden, sollten die Vorwiderstände auf je 10 Ohm verdoppelt werden. Um das den 3,3V Schaltregler und den MOSFET nicht zu überfordern wird die Sendediode nur mit 300mA bei 25% Duty-Cycle betrieben. Ferner sind großzügige keramische Stützkondensatoren vorgesehen. Die Empfänger können parallel betrieben werden, um der Schaltung eine Rund-um-Sicht zu ermöglichen.
Recht aufwändig sind dagegen die Messung der Umgebungshelligkeit und die Erzeugung des akustischen Signales geraten. Zu nächst zur Helligkeitsmessung: Für diese Aufgabenstellung gibt es spezialisierte IC, die jedoch schwer erhältlich sind. Deshalb wurde ein Transimpedanzverstärker mit umschaltbarem Rückkoppelwiderstand aufgebaut. Die MCU ist zwar mit einem ADC ausgestattet, jedoch ist deren Dynamikbereich allein nicht ausreichend. Zusammen wird jedoch ein Bereich von 1:255000 entsprechend 108dB abgedeckt. In Software wird das Signal noch gefiltert und die Messwerte, zu die von der Hintergrundbeleuchtung des LCDs oder der IR-Sendediode beeinflusst worden sein könnten, übersprungen.
Die das akustische Signal sollte einen möglichst angenehmen Klang haben. Daher läuft auf der MCU eine DDS mit ca. 20kHz zur Erzeugung eines Sinussignals, welches über den ADC ausgegeben wird. Dann folgt zu nächst ein Buffer und eine Pegelanpassung, die ein Übersteuern der OPVs im folgenden Tiefpass mit ca. 7kHz verhindern. Über einen CMOS Schalter lässt sich das Signal in drei 10dB Stufen abgeschwächt dem ausgangsseitigen Brückenverstärker zuführen. Dieser wird zur Reduktion des Stromverbrauches von der MCU nur bei Bedarf aktiviert. Er ist auch auf eine Bandbreite von 8kHz begrenzt, um die Oberwellen weiter zu reduzieren.
Die beiden letztgenannten Schaltungsteile profitieren besonders von einem PI-Filter mit einer 4,7µH Drossel und größeren keramischen Kondensatoren. So werden Störungen aus Schaltreglern und der PWM-Ansteuerung der Hintergrundbeleuchtung ferngehalten.
RC-Glieder schützen die MCu vor Störeinstrahlung- und leitung durch die Kabel zu Drehencoder und Leistungsteil.
Die recht hohe Packungsdichte, der enge Pin-Abstand von MCU, OPV und RTC und die notwendigen Masseflächen erfordern eine professionelle doppelseitige Platine. Die Masseflächen wurden durch eine Vielzahl von vergrößerten und verteilten Vias verbunden. Die Entstörkondensatoren an den Halbleitern sind mit 1µF recht groß gewählt. Ob die Störfestigkeit unter der gegenüber 100nF reduzierten Resonanzfrequenz der Kondensatoren geringer ist, wurde nicht untersucht. (Es funktioniert.) Ein keramischer 1nF Kondensator hält Störungen vom Reset-Pin der MCU fern.

Die Steuerplatine trägt zwei 5*2 polige Pfostenleisten. Die äußere dient primär zur Programmierung der MCU, kann aber auch für Erweiterungen mit I2C-Anschluss verwendet werden. Die innere stellt die Anschlüsse für Drehencoder und Leistungsteil zur Verfügung. Dazu muss somit ein Flachbandkabel mit drei Enden gepresst werden: 5*2 polig (Steuerung), offen (Drehencoder), 3*2 polig (Leistungsteil)

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
** Baud Rate: 7200
** Interface: None (ISP)
** Oscillator (MHz): 7,373
** Erase block used by Hex File
* Unter ISP, Device Configuration wird die MCU konfiguriert:
** Statt des internen Oszillators muss ein externer High-Speed Oszillator gewählt werden. Die in FlashMagic einzustellende Frequenz ändert sich dann von 7.373 MHz auf 6 MHz
** Der Reset-Pin muss ausgeschaltet werden.

Das Netzteil ist so ausgelegt, dass zwei Lampen mittels eines Y-Kabels versorgt werden können. Dadurch entfallen die Leerlaufverluste, Kosten und Platzbedarf des zweiten Netzteils.

Kosten der Steuerplatine (Teile: Reichelt, MCU: Ebay, 5 Platinen von PCB-Pool): ca. 56€ je Stück

=== Optoelektronik ===

Die Auswahl der LEDs wird primär von den Wünschen nach der Lichtwirkung bestimmt. Hier ist nur ein Vorschlag angegeben. Daneben gibt es noch die Schnittstellen zur Mechanik und zur Elektronik.
Die Ansteuerung kann bei Versorgung mit 24V 1 bis 5 LEDs je Strang bedienen. Der Strom ist auf 500mA eingestellt, auch wenn der ZXLD1362 auch größere Ströme verkraften sollte. Beim SOT23-5 Gehäuse hatte ich jedoch dann in einem anderen Projekt insbesondere bei höheren Spannungen Probleme mit der Wärmeabführung. Mittlerweile können auch andere Gehäuseformen mit geringerem Wärmewiderstand bzw. leistungsfähigere Chips wie der ZXLD1374 eingesetzt werden. Der ZXLD1374 kann auch kürzere PWM-Impulse noch sauber in Stromimpulse für die LEDs umsetzen, womit ein größerer dimbarer Bereich erzielt wird. Jedoch muss der PWM-Pin von einem Push-Pull- statt einem Open-Drain-Ausgang angesteuert werden, da der interne Pull-Up des LED-Treibers sehr schwach ist und der Chip dann nur bei relativ langen Pulsen aus dem Standby aufwacht. Zum ZXLD1374 ist ein zusätzlicher Schaltplan mit Layout im Repository abgelegt. Der LM267X musste bei diesem Entwurf einem sparsameren und spannungsfesteren LT1676 weichen.
Sollen mehr als 5 LEDs je Strang angesteuert werden, muss die Supressor-Diode am Stromversorgungseingang angepasst und der LT1676 zur Versorgung der Steuerplatine verwendet werden. Die ZXLD1362 vertragen bis zu 60V, sollten jedoch mit mindestens 17V versorgt werden, damit der Schalt-MOSFET voll durchschaltet.

{| class="wikitable"
|+ '''Teile von Leds.de'''
|-
! Anzahl || Artikel-Nr. || Bezeichnung || Kommentar
|-
| 4 || 65659 || Nichia NS6L183BT, warmweiß, CRI 80, mit Platine (Star) || bessere Farbwiedergabe bei schlechterer Effizienz: austauschbar gegen NS6L183AT-H3 (CRI 85) oder NS6L183AT-H1 (CRI 90+)
|-
| 2 || 65656 || Nichia NS6W183BT, weiß, CRI 80, mit Platine (Star) ||
|-
| 2 || 60354 || Carclo Linse für Luxon Rebel, frosted wide || passt auch für Nichia NS6_183T
|-
| 2 || 60456 || Linsenhalter rund für Luxon Rebel, transparent || muss deutlich mit Säge und Feile angepasst werden
|}

Kosten ca. 27€

=== Mechanik ===
Bei einer Nachttischlampe ist natürlich auch das Design eine wichtiges Merkmal. Ich bevorzuge ein klares einfaches Design und Materialien wie Glas und eloxiertes Aluminium. Die verwendeten Profile (Item, Profil X 8, leicht) ermöglichen es die Kabel und die Leistungselektronik im Inneren zu verstecken.
Es haben aber auch einige Kunststoffteile Verwendung gefunden, da sie mir den Verschluss der Aluminiumprofile ohne sichtbare Schrauben ermöglichen.

Der sichere Stand wird durch die Füllung des Profil X 8 80x80 mit kleinen Kieseln für Aquarien gewährleistet. Die Oberen 1 bis 2cm bleiben frei und dienen dem Lautsprecher als Resonanzraum.

Die Frontplatte wird laut Zeichnung von der Schaeffer AG (Datei bei Downloads) gefertigt. Sie "schwebt" auf vier Distanzhülsen über der Steuerungselektronik. Dadurch bleibt umlaufend ein Spalt von 12mm Höhe, durch den die Steuerung per RC5 kommuniziert, die Umgebungshelligkeit gemessen wird und der Schall vom Lautsprecher abgestrahlt wird.

{| class="wikitable"
|+ '''Teile von Item'''
|-
! Anzahl || Länge || Art.-Nr. || Bezeichnung
|-
| 1 || 160mm || 0.0.493.04 || Profil X 8 80x80 8N leicht
|-
| 1 || 160mm || 0.0.492.88 || Profil X 8 40x40 4N leicht
|-
| 1 || 480mm || 0.0.492.88 || Profil X 8 40x40 4N leicht
|-
| 1 || - || 0.0.601.13 || Gelenk X 8 40x40 mit Klemmhebel
|-
| 4 || - || 0.0.026.07 || Standard-Verbindungssatz 8
|-
| 1 || - || 0.0.489.98 || Abdeckkappe X 8 80x80 grau
|-
| 1 || - || 0.0.489.61 || Abdeckkappe X 8 80x40 grau
|-
| 1 || - || 0.0.489.60 || Abdeckkappe X 8 40x40 grau
|}

Kosten: Item ca. 90€, Schaeffer AG ca. 25€

Der Klemmhebel kann bei ästhetischen Bedenken auch gegen eine Schraube getauscht werden. Von zwei Standard-Verbindungssätzen wird nur die Schraube zur Befestigung des Gelenks verwendet.

Die Bohr- und Fräsarbeiten habe ich durch [http://dw-metall.de/ Daniel Wulfänger] durchführen lassen.

Ein 3D-Model für FreeCAD befindet sich im SVN-Repository (s.u.).

2D-Zeichnungen auf Anfrage per PM bei [http://www.mikrocontroller.net/user/show/mclausen Martin Clausen]

== Montage ==

Wenn alle Teile laut Zeichnung bearbeitet worden sind, werden zunächst die Standard-Verbinder für die Verbindung von Arm und Fuß eingeschraubt. Da aus optischen Gründen kein Loch zum Festziehen der Schrauben vorhanden ist, werden die Standardverbinder vorsichtig angezogen, so dass der Arm beim Aufschieben beginnt zu klemmen. Dann wir die Fläche zwischen Arm und Fuß mit Alkohol geschmiert und der Arm mit einigen Hammerschlägen montiert. Dabei sollte eine Unterlage (z.B. ein Stück Holz) verwendet werden.

Nun wird der Drehencoder verdrahtet und in die große Abdeckkappe geschraubt und mit Heißkleber versiegelt.

[[Bild:Drehencoder mit Kabel.jpg|300px]]

Im folgenden wird die Stromversorgungsbuchse in die 80x40 Abdeckkappe geschraubt und diese in den Fuß gepresst.

[[Bild:Durchführung Kabel.jpg|200px]]

Dann werden die LEDs mit etwas Wärmeleitpaste und einer Isolierscheibe unter jeder Schraube montiert. Kabel werden in das Profil gefädelt und an gelötet. Ein fester Draht kann dabei nützlich sein. Dann wird die Leistungselektronik im Fuß platziert. Für die Positionierung sorgen 10 und 12 mm Distanzbuchsen jeweils mit und ohne Außengewinde.
Jetzt bietet sich ein kurzer Funktionstest an.

[[Bild:Montage LEDs.jpg|300px]]

Für die Front-LEDs werden nun die Halter modifiziert und aufgeklemmt. Dann werden die Linsen eingerastet.

Nun wird grober Aquarien-Kies gewaschen, gründlich getrocknet und in den Fuß gefüllt. Dabei muss ausreichend Raum für die Halter der großen Abdeckkappe gelassen werden. Diese wird nun aufgepresst. Dann wird der Fuß weiter verfüllt.

[[Bild:Verfüllung Fuß.jpg|200px]]

Jetzt werden noch Steuerelektronik mit 5mm Distanzbuchsen und M3x10 Schrauben montiert. Zum Schluss wird die Frontplatte mit M3x20 Edelstahl Senk-Inbusschrauben und 12mm Distanzbuchsen befestigt.

== Downloads ==

* [https://github.com/martinclausen2/Nachttischlampe.git Link zum Repository für Software, Schaltpläne, Platinen und Mechanik]
* [[Datei:Hex-File Nachttischlampe.zip|Hex-File jeweils für ZXLD1374 ZXLD1362 V5]]

== Siehe auch ==

* [[Wake-Up Light]]
* [[LED-Pendellampe]]
* [[LED]]
* Diskussion zu diesem Projekt: http://www.mikrocontroller.net/topic/297859#3182303

[[Kategorie:Projekte]]
[[Kategorie:8051]]
[[Kategorie:Timer und Uhren]]

LED-Pendellampe

2016-03-13T15:27:06Z

8023: müll

''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 können alternativ mit Konstantspannung direkt via PWM gedimmt 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
|-
| 1 || Min. Light || blau || minimale Helligkeit beim Einschalten der LED
|-
| 2 || Offset Light || blau || minimales Ausgangssignal, ab dem das Netzteil anfängt die LED zu bestromen, wird auf das Netzteil eingestellt
|-
| 3 || Light Alarm || wechselt Farbe nach Wert || maximale Helligkeit der LED beim Ende eines Alarms
|-
| 4 || Light Fading || wechselt Farbe nach Wert || Dauer des Dimmens bei einem Alarm
|-
| 5 || 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.
|-
| 6 || Det.Bright.Limit || wechselt Farbe nach Wert || maximale Helligkeit, bei der der Bewegungsmelder noch aktiv ist
|-
| 7 || Set RC Address || wechselt Farbe bei Empfang eines gültigen RC5-Codes || Lernt RC5 Adresse
|-
| 8 || Receiver Mode || wechselt Farbe nach Wert || bestimmt das Zusammenspiel mit anderen Lampen
|-
| 9 || Reset settings || wechselt Farbe für Freigabe des Resets || Setzt Steuerung auf Werkseinstellungen zurück
|-
| 10 || LCD Contrast || - || nur mit LCD
|-
| 11 || 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 oder MOSFETS auf Betriebsspannungs-Niveau gehoben.
Je nach Anforderung sollte nur '''eine''' Variante also PWM '''oder''' analog Steuerung bestückt werden.
LED-Streifen für Konstantspannungsbetrieb können direkt per PWM gedimmt werden. Dazu wird die Software-Variante 'Noninverted PWM' verwendet und ein MOSFET wie IRLML 6344 als Ausgangsstufe verwendet. Der Gate-Vorwiderstand sollte dann bei 100 Ohm liegen, der Pull-Down bei 47k Ohm. Für den Betrieb bei 24V sind die Spannungsfestigkeit von Suppressordiode und Keramikkondensatoren zu prüfen. Außerdem sollte mit dem Oszi überprüft werden, ob es zu Überschwingern der Drai-Source-Spannung beim Abschalten des MOSFETS kommt. In diesem Fall kann eine Z-Diode mit z.B. 27V helfen. Die Vorwiderstände der RGB-LED erhöhen sich auf 4,7k Ohm.

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!
* [https://github.com/martinclausen2/Lampensteuerung.git Link zum Repository für die Software und Schaltpläne]

== Siehe auch ==

* [[Nachttischlampe]]
* [[Wake-Up Light]]
* [[LED]]

[[Kategorie:Projekte]]
[[Kategorie:8051]]

ESP8266

2016-03-13T11:23:19Z

8023: /* Bezugsquellen */

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

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

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

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

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

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

=== Pinbelegung einiger ESP8266-Module ===
====ESP8266-01====
<gallery>
Datei:ESP8266-PinBelegung1.jpg|Pinbelegung - Groß mit PCB-Antenne
Datei:ESP8266-PinBelegung2.jpg|Pinbelegung - Klein mit Keramik-Antenne
</gallery>
Quelle <ref>[http://pan.baidu.com/share/link?shareid=727869034&uk=1900861665 ''Seller Information''] Abgerufen am 26. August 2014.</ref>.
====ESP8266-07====
Achtung, beim ESP8266-07 Modul sind einige mit vertauschten Beschriftungen von GPIO4 und GPIO5 unterwegs!!.

== Möglichkeiten der Nutzung und Programmierung ==
===== Benutzung einer Firmware =====
Verschiedene Projekte betreiben die Entwicklung einer Firmware. Man kann die Firmware "einfach nur" flashen und benutzen oder sich auch aktiv an der Entwicklung beteiligen. Es gibt unter anderem folgende Projekte:
* AT-Befehle: Firmware, mit welcher das Modul über UART angesprochen wird.
* Micropython: Firmware, die das Ablaufen von Python Scripts ermöglicht
* NodeMCU: Firmware, die das Ablaufen von Lua-Scripts ermöglicht ([https://github.com/nodemcu/nodemcu-firmware Github])
* smartJS: Firmware, die das Ausführen von JavaScript erlaubt ([https://github.com/cesanta/smart.js Github])
* Arduino core for ESP8266 WiFi chip: Programmierumgebung & Firmware, die das Ausführen von C Programmen ermöglicht, im Stil der bekannten Arduino Plattform. [https://github.com/esp8266/Arduino Github - ink. Anleitung]
* ESP8266 Basic: Firmware, die das Ausführen von Basic Programmen und das Editieren über WLAN erlaubt [http://www.esp8266basic.com/]

===== Erstellen (Kompilieren) einer Firmware =====
Für die Erstellung einer individuellen Firmware gibt es zwei Möglichkeiten:
* Software Development Kit (SDK): Erstellen einer Firmware mit einer GCC-Toolchain
* Arduino IDE: Erstellen einer Firmware mit einer Arduino IDE
Projekte, die eine Firmware für das ESP8266 entwickeln (siehe vorheriger Abschnitt), benutzen eine dieser beiden Möglichkeiten.

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

[http://bbs.espressif.com/viewtopic.php?f=5&t=433 Flash Download Tool vom Hersteller] 
[http://github.com/themadinventor/esptool Python Tool zum Flashen (von Fredrik Ahlberg)] 
[http://github.com/3s1d/esp_prog Extension zum Tool von Fredrik Ahlberg] 
[http://www.mikrocontroller.net/topic/342240?page=2#3857075 Tool zum Flashen (von Christian Klippel)] 
[http://defcon-cc.dyndns.org/wiki/ESP8266#Update Anleitung, extern] 
[http://www.mikrocontroller.net/topic/342240?page=3#3810559 Anleitung, Forum]

Der Hersteller veröffentlich regelmässig [http://bbs.espressif.com/viewforum.php?f=5 Firmwareupdates] als Bestandteil des esp_iot_sdk. Die Firmware-Dateien befinden sich im Verzeichnis bin. Das Update wird beispielweise für Firmware 0.9.5 folgendermaßen durchgeführt: 
<pre>
python esptool.py --baud 9600 --port com6 write_flash 0x00000 boot_v1.2.bin 0x01000 at/user1.512.new.bin 0x3e000 blank.bin 0x7e000 blank.bin
</pre>

Abhängig von der Flashgröße muß man die Firmware ab Version 1.0.1 selbst compilieren. Siehe Diskussion [http://www.esp8266.com/viewtopic.php?p=16515 hier] und [http://bbs.espressif.com/viewtopic.php?f=16&t=400 hier].

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

Einstellen des Moduls als AP

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

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

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

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

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

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

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

Einstellen des Moduls als Station

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

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

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

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

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

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

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

== Links ==
[https://en.wikipedia.org/wiki/ESP8266 ESP8266-Eintrag auf en.wikipedia.org] 
[http://www.esp8266.com/ ESP8266 Community Forum] 
[http://github.com/esp8266 ESP8266 Github mit Wiki und Source-Code Samples] 
[https://hackaday.com/tag/esp8266/ Hackaday Posts zu ESP8266] 
[http://espressif.com/en/products/esp8266/ ESP8266-Seite des Herstellers] 
[http://bbs.espressif.com/ ESP8266-Forum des Herstellers] 

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

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

[http://blog.thomasheldt.de/ Viele Projekte und Informationen zum ESP8266] 
[http://stefanfrings.de/wlan_io/ Projekt I/O Schnittstellen Modul mit WLAN]

=== Dokumente ===
[http://neilkolban.com/tech/esp8266/ Kolban’s book on the ESP8266] Sehr empfehlenswert! 
[https://drive.google.com/folderview?id=0B5bwBE9A5dBXaExvdDExVFNrUXM&usp=sharing Anleitung/HOWTO für das Setup der virtuellen Maschine (SDK) sowie für das Kompilieren] 
[https://nurdspace.nl/ESP8266 Übersetztes Datenblatt] 
[http://www.electrodragon.com/w/Wi07c AT Instructions Set (English)] und [http://www.electrodragon.com/w/Wi07c#First_time_use_guide Anleitung zum Betrieb an einem Arduino (inkl. Code)] 
[http://thomaspfeifer.net/esp8266_wlan_seriell_modul_at_kommandos.htm Beschreibung der AT-Kommandos mit Beispielen] 
[http://www.mikrocontroller.net/attachment/229016/Espressif_IoT_AT____v0.1.5.906.pdf Espressif AT Instruction Set(Chinese)] 
[http://www.seeedstudio.com/document/pdf/ESP8266%20Specifications(Chinese).pdf ESP8266 Specifications(Chinese)] 
[http://nodemcu.readthedocs.org/en/dev/ NodeMCU Documentation] 
[https://cknodemcu.wordpress.com/2015/11/24/building-an-iot-node-for-less-than-15/ Building an IoT Node for less than 15$] (Paper, Kindle via Amazon)

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

=== Bezugsquellen ===
[http://espressif.com/en/company/contact/buy-a-sample/ Offizieller Espressif Vertriebskanal] (Sample Purchase) 
[http://www.aliexpress.com/wholesale?SearchText=ESP8266 aliexpress.com] ~ 2€ 
[http://www.banggood.com/?zf=283997 banggood.com] ~ 3.50€ 
[http://www.ebay.de/ Ebay]
ab 3€ inkl. Versand, Einzelstückpreis: ESP-01/02/03/04/05 
(Suchbegriff: ESP8266, Option Artikelstandort: "Weltweit") 
(10 Stück ab 27 EUR inkl. Versand; Suchbegriff: 10pcs ESP8266) 
ab 3.20€ inkl. Versand, Einzelstückpreis: ESP-07/08/09/11 
[http://www.electrodragon.com/?s=esp8266&post_type=product electrodragon.com] ~ 3.50€ (zzgl. Versand) 
[https://ex-store.de/advanced_search_result.php?keywords=esp8266&x=0&y=0 eX-store.de] (ESP-01/02/03/05/07/12/13) ab 3.35€ (zzgl. Versand) 
[https://www.it-wns.de/themes/suche/index.php?suchekategorie=&sucheallgemein=esp8266 IT-WNS.de] (ESP-01/02/03/06/07/12E) je 3.99€ (zzgl. Versand) 
[http://www.seeedstudio.com/depot/WiFi-Serial-Transceiver-Module-w-ESP8266-p-1994.html seeedstudio.com] ~ 5.50€ 
[http://shop.in-circuit.de/index.php?cPath=21 In-Circuit.de] ESP-ADC DIL Modul mit ESP8266EX 9.90€ Einzelpreis 
[http://www.watterott.com/index.php?page=search&desc=off&sdesc=off&keywords=ESP8266 watterott.com] ab ~ 4€ (zzgl. Versand) 

==Anderes==
*[http://www.mikrocontroller.net/articles/ESP8266-CPCB PCB für Community-Modul (Vorschlag)]
*[http://fkainka.de/esp8266-in-der-arduino-ide/ ESP8266 mit Arduino IDE programmieren]
*[http://www.arduinesp.com Arduino IDE Integration (ab 1.6.x)]
*[https://cknodemcu.wordpress.com/ NodeMCU (Lua) Anwendungen]

== Einzelnachweise ==
<references />

--von [[axhieb]]

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