Differences

This shows you the differences between two versions of the page.

--- de:examples:timer:software_delay [2010/11/09 23:58] – Wember
+++ de:examples:timer:software_delay [2020/07/20 09:00] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
-====== Software Verzögerungen ======
+====== Softwareverzögerungen ======
-//Necessary knowledge: [HW] [[en:hardware:homelab:controller]], [AVR] [[en:avr:architecture]], [LIB] [[en:software:homelab:library:pin]], [LIB] [[en:software:homelab:library:delay]]//
+//Notwendiges Wissen: [HW] [[en:hardware:homelab:controller]], [AVR] [[en:avr:architecture]], [LIB] [[en:software:homelab:library:pin]], [LIB] [[en:software:homelab:library:delay]]//
 ===== Theorie =====
-Oft ist es wichtig in einem Programm eines Microcontrollers Verzögerungen einzubauen, es ist notwendig einige Aktionen zu timen, oder zu warten bis sie abgeschlossen sind. Die einfachste Methode die Arbeit eines Microcontrollers zu pausieren ist, ihn mit einer alternativen Operation zu überladen - z.B. einen Befehl um große Nummern zu zählen. Von der Taktfrequenz des Prozessors kann man ableiten wie weit das Programm in einer bestimmten Zeit zählt.
+Oft ist es wichtig in einem Programm eines Mikrocontrollers Verzögerungen einzubauen, einige Aktionen zu terminieren, oder zu warten bis sie abgeschlossen sind. Die einfachste Methode die Arbeit eines Mikrocontrollers zu pausieren ist, ihn mit einer alternativen Operation zu überladen - z.B. durch einen Befehl, große Nummern zu zählen. Aus der Taktfrequenz des Prozessors kann man errechnen, wie weit das Programm zählen sollte um eine Verzögerung hervorzurufen.
-Eine Zahl von Null bis zum Wert der Taktfrequenz des Prozessors in Hz, sollte theoretisch eine Verzögerung von einer Sekunde erzeugen. Aus einer Nummer von Gründen ist es leider praktisch nicht ganz so einfach.
+Eine Zahl von Null bis zum Wert der Taktfrequenz des Prozessors in Hz, sollte theoretisch eine Verzögerung von einer Sekunde erzeugen. Aus verschiedenen Gründen ist dieses jedoch praktisch nicht ganz so einfach.
-Wenn der Prozessor des Microcontrollers mit Nummern rechnet, welche Binäreform so groß wie der innere Bus sind (AVR hat 8 Bits), dann brauch es einen Taktzyklus des Prozessors eine arithmetische Operation, wie z.B. 1 zu einem Wert zu addieren, durchzuführen. Aber wenn der Prozessor mit größeren Werten rechnet, und die Nummer 16 oder 32 Bit sein muss, brauch der 8 Bit Prozessor mehr als eine Taktfrequenz, diese zu berechnen. Daher sollte man sich mit der Arbeitsweise des Prozessors auskennen, wenn man mit großen Werten arbeitet.
+Wenn der Prozessor des Microcontrollers mit Nummern rechnet, deren Binärform so groß ist wie der innere Bus (AVR hat 8 Bits), dann braucht es einen Taktzyklus des Prozessors um eine arithmetische Operation, wie z.B. 1 zu einem Wert zu addieren, durchzuführen. Soll mit tausenden oder millionen gerechnet werden, muss die Nummer 16 oder 32 Bit groß sein und ein 8-Bit Prozessor benötigt zur Berechnung mehr als eine Taktfrequenz. Daher sollte man sich mit der Arbeitsweise und insbesondere den Befehlen des Prozessors auskennen, wenn man mit großen Werten arbeitet.
-Wenn man in fortgeschrittenen Sprachen programmiert ( z.B. C), werden die Programme nicht auf Basis des Befehls geschrieben, um eine Softwareverzögerung zu erzeugen, muss man auch den Compiler kennen, welcher das Programm zu Maschinencode konvertiert. Darauf basiert, wie viele Befehle (und Phasen) es braucht um eine arithmetische Operation durchzuführen. Das wird durch mehrere Gründe komplexer, durch die Fähigkeit des Compilers das Programm in Maschinencode umzuwandeln - z.B. dadurch, dass der Maschinencode für Speicherverbrauch optimiert wird, oder einfacher auszuführen wird. Diesen Compilervorgang nennt man Optimierung. Mit verschieden Optimierungsmodi werden die Maschinencodes und die verursachte Verzögerung der Softwareverzögerung anders.
+Wenn man in fortgeschrittenen Sprachen programmiert (z.B. C), werden die Programme nicht auf Basis des Befehls geschrieben, um eine Softwareverzögerung zu erzeugen. Vielmehr muss man auch den Compiler kennen, welcher das Programm zu Maschinencode konvertiert. Davon hängt ab, wie viele Befehle (und Phasen) es braucht um eine arithmetische Operation durchzuführen. Das wird durch mehrere Gründe komplexer, durch die Fähigkeit des Compilers das Programm in Maschinencode umzuwandeln - z.B. dadurch, dass der Maschinencode für Speicherverbrauch optimiert, oder einfacher auszuführen wird. Diesen Compilervorgang nennt man Optimierung. Durch verschiedene Optimierungsmodi verändern sich die Maschinencodes für die Softwareverzögerung sowie die Dauer der Verzögerung.
 ===== Beispiel ======
-Das folgende Beispiel generiert eine Softwareverzögerung im AVR Microcontroller. Ein Teil des in C geschriebenen Programms, zählt eine Variable x in einem for-Zyklus von 0 bis 100.
+Das folgende Beispiel generiert eine Softwareverzögerung im AVR Mikrocontroller. Ein Teil des in C geschriebenen Programms zählt eine Variable x in vier Zyklen von 0 bis 100.
-In jedem Zyklus wird ein "no-action" leerer Befehl ausgeführt. Dies wird benötigt, da wenn der Inhalt des Zyklus leer ist, der Compiler ihn auf Grund des leeren Inhalts aus dem Programm optimiert.
+In jedem Zyklus wird ein leerer "no-action empty" Befehl ausgeführt. Dieser wird benötigt, der Compiler einen Zyklus ohne Inhalt als nutzlos betrachtet und ihn daher aus dem Programm werfen würde.
 <code c>
 unsigned char x;
-// Cycle until x is 100
+// Zyklus bis x ist 100
 for (x = 0; x < 100; x++)
 {
-	// With empty instruction nop
+	// Mit "empty"-Befehl nop
 	asm volatile ("nop");
 }
 </code>
-Dies ist der gleiche Teil des Programms nach dem kompilieren. Zwei hexadezimale Nummern links geben den Maschinencode an, und rechts den Befehl mit Operanden in Assembler Sprache.
+Dies ist der gleiche Teil des Programms nach dem Kompilieren. Die beiden Hexadezimalzahlen links geben den Maschinencode an, und rechts befindet sich der Befehl mit den Operanden in Assembler.
-Der Maschinencode und die Assemblersprache sind konform; Assembler ist nur da um den Maschinencode für Menschen lesbarer zu machen. Kompiliert wurde mit der Optimierungsmethode für die Länge des Programms (Parameter -Os).
+Der Maschinencode und die Assemblersprache sind konform; Assembler dient nur dazu, den Maschinencode für Menschen lesbar zu machen. Kompiliert wurde mit der Optimierungsmethode für die Länge des Programms (Parameter -Os).
 <code asm>
-e0     ldi  r24, 0x00   ; r24 loading number 0 to the index
+e0     ldi  r24, 0x00   ; r24 lädt Zahl 0 in den index
-00     nop              ; Empty operation
+00     nop              ; "Empty" Operation
-f 5f     subi r24, 0xFF   ; subtracting 255 form the r24 index, that means adding +1
+f 5f     subi r24, 0xFF   ; subtrahieren von 255 aus dem r24 Index, was bedeutet +1 addieren
-36     cpi  r24, 0x64   ; comparing r24 index with number 100
+36     cpi  r24, 0x64   ; r24 Index mit der Zahl 100 vergleichen
-e1 f7     brne .-8         ; If the comparison was wrong, then transfer 8-baits back
+e1 f7     brne .-8         ; Falls der Vergleich nicht übereinstimmt, 8-Bits zurücktransferieren
 </code>
-In der kompilierten Form kann man sehen, was mit dem Zyklus der C-Sprache passiert und man kann berechnen wie viele Taktfrequenzen benötigt werden, um den Zyklus einer Periode zu beenden. Die Information über die Effekte der Befehle und die Laufzeit kann im AVR Datenblatt gefunden werden. Im gegebenen Beispiel, benötigt es 4 Taktzyklen um 4 Befehle in einer Periode auszuführen, da jeder Befehl nur einen Takt benötigt. Zusätzlich wird ein Takt vor dem Zyklus benötigt um die Befehle zu laden, und einen Takt um den Zyklus zu beenden.
+In der kompilierten Form erkennt man, was mit dem Zyklus der C-Sprache passiert und man kann berechnen wie viele Taktfrequenzen benötigt werden, um den Zyklus einer Periode zu beenden. Die Information über die Wirkung der Befehle und ihre Laufzeit findet man im AVR Datenblatt. Im vorliegenden Beispiel, braucht es 4 Taktzyklen um 4 Befehle in einer Periode auszuführen, da jeder Befehl einen Takt benötigt. Zusätzlich wird ein Takt vor dem Zyklus benötigt, um die Befehle zu laden und ein Takt, um den Zyklus zu beenden.
-Wenn man nun den Arbeitstakt von 14,7456 MHz annimmt, kann man die Verzögerung die von dem Programm verursacht wird berechnen.
+Wenn man nun den Arbeitstakt von 14,7456 MHz annimmt, kann man die vom Programm verursachte Verzögerung berechnen.
 (1 + 100 ⋅ 4 + 1) / 14745600 = 27,26 μs
-Die Verzögerung dieses Beispiel ist in Microsekunden und die Variable nutzt 8-Bit, daher ist der Maschinencode recht einfach. Um eine Pause in Millisekunden zu verursachen, muss man viel größere Nummern zählen, und dann wird der Maschinencode auch länger. Zyklen die ineinander arbeiten können auch genutzt werden, aber mit dieser Methode ist die Verzögerung nicht in linearer Relation mit der Nummer des Zyklus, da mit jedem Level des Zyklus eine kleine zusätzliche Verzögerung verursacht wird.
+Die Verzögerung in diesem Beispiel ist in Mikrosekunden angegeben und die Variable nutzt 8-Bit, daher ist der Maschinencode recht einfach. Um eine Pause in Millisekunden zu verursachen, müssen weitaus größere Nummern gezählt werden, wodurch dann der Maschinencode auch länger wird. Es können ebenfalls Zyklen verwendet werden, die ineinander greifen, jedoch steht dann die Verzögerung nicht in linearer Relation mit der Nummer des Zyklus, da mit jedem Level des Zyklus eine kleine zusätzliche Verzögerung verursacht wird.
-Das Ziel dieser Übung ist es nicht präzise Softwareverzögerungen in Maschinencode zu erstellen, da diese eine sehr aufwendige und genaue Arbeit ist und wir die Funktionen um Verzögerungen zu erzeugen schon in der avr-libc und der Library von HomeLab haben. Diese werden auch im folgenden Beispiel genutzt.
+Das Ziel dieser Übung ist es nicht präzise Softwareverzögerungen in Maschinencode zu erstellen, da diese eine sehr präzise Arbeit ist und die Funktionen zur Erzeugung von Verzögerungen bereits in der avr-libc und der Bibliothek von HomeLab hinterlegt sind. Diese werden auch in den folgenden Beispielen genutzt.
-Wenn man mit Softwareverzögerungen arbeitet, ist es wichtig zu wissen, dass trotz der Einfachheit, eine extrem ineffiziente Methode ist, wenn man den Stromverbrauch betrachtet.
+Bei der Arbeit mit Softwareverzögerungen arbeitet, ist es wichtig zu wissen, dass diese trotz ihrer Einfachheit, eine sehr ineffiziente Methode sind was den den Stromverbrauch betrifft.
-Während jedes Taktes des Microcontrollers der unnötigen Zahlen zählt wird Energie verbraucht. Wenn also Applikationen mit Batterien genutzt werden, ist es nicht sinnvoll lange Softwareverzögerungen zu schreiben. Für diesen Fall sollte man lieber Hardwaretimer nutzen, welche unabhängig arbeiten und den Prozessor aus dem Ruhezustand holen wenn es an der Zeit ist die Arbeit fortzuführen.
+Während jedes Taktes in dem der Mikrocontroller unnötig Zahlen zählt, wird Energie verbraucht. Wenn also batteriebetriebene Anwendungen genutzt werden, ist es nicht sinnvoll lange Softwareverzögerungen zu schreiben. Für diesen Fall sollte man lieber Hardwaretimer nutzen, welche unabhängig arbeiten und den Prozessor aus dem Ruhezustand holen wenn es an der Zeit ist die Arbeit fortzuführen.
 ===== Übung ======
-Der folgende Code eines Programms ist über die Softwareverzögerunsfunktion //sw_delay_ms//, welche einen gegebene Verzögerung in ms mit dem Parameter //count// verursacht. Die Funktionen nutzt die avr-libc Library Funktion //_delay_ms// welche z.T. in Assembler geschrieben ist.
+Der folgende Programmcode beinhaltet die Softwareverzögerunsfunktion //sw_delay_ms//, welche einen gegebene Verzögerung in ms mit dem Parameter //count// verursacht. Die Funktionen nutzt die Funktion der Bibliothek avr-libc //_delay_ms// welche zum Teil in Assembler geschrieben ist.
-Der Grund, warum //_delay_ms// in dieser Übung nicht genutzt wird ist, dass mit //_delay_ms// Probleme auftreten können wenn man lange Verzögerungen nutzt. //sw_delay_ms// erlaubt es aber bis zu 65535ms lange Verzögerungen ohne Komplikationen zu nutzen.
+//_delay_ms// wird in dieser Übung nicht genutzt, da hiermit bei langen Verzögerungen Probleme auftreten können. //sw_delay_ms// erlaubt es aber bis zu 65535ms lange Verzögerungen ohne Komplikationen zu nutzen.
 <code c>
 //
-// Software delay in milliseconds.
+// Softwareverzögerung in Millisekunden.
 //
 void sw_delay_ms(unsigned short count)
 {
-	// Counting the variable of the delay to 0
+	// Zählen der Variable der Verzögerung auf 0
 	while (count-- > 0)
 	{
-		// 1ms delay with a special function.
+		// 1ms Verzögerung mit spezieller Funktion.
 		_delay_ms(1);
 	}
@@ Line 73: / Line 72: @@
 </code>
-Das folgende Programm ist um die gegebenen Funktion zu nutzen, es erzeugt zwei Verzögerungen in der Endlosschleife: 100 ms und 900ms. Während der kürzeren Verzögerung wird LED angeschaltetm und während der längern ausgeschaltet. Das Resultat: die LED blinkt periodisch.
+Das folgende Programm dient dazu, die gegebene Funktion zu nutzen, es erzeugt zwei Verzögerungen in der Endlosschleife: 100 ms und 900 ms. Während der kürzeren Verzögerung wird eine LED eingeschaltet und während der längern ausgeschaltet. Das Resultat: die LED blinkt periodisch.
 <code c>
 //
-// The demonstration program of the software delay of the HomeLab.
+// Das Vorführprogramm des HomeLab für Softwareverzögerungen.
-// The program is blinking a LED for a moment after ~1 second.
+// Es lässt eine LED für ~1 Sekunde aufleuchten.
 //
 #include <homelab/pin.h>
@@ Line 85: / Line 84: @@
 //
-// Determining the pin of the test LED
+// Festlegung des Pins zum Testen der LED
 //
 pin debug_led = PIN(B, 7);
 //
-// Main program
+// Hauptprogramm
 //
 int main(void)
 {
-	// Setting the pin of the LED as output.
+	// Setzt LED Pin als Output.
 	pin_setup_output(debug_led);
-	// Endless loop
+	// Endlosschleife
 	while (true)
 	{
-		// Lighting the LED
+		// Aufleuchten der LED
 		pin_clear(debug_led);
-		// Software delay for 100 ms
+		// Softwareverzögerung für 100 ms
 		sw_delay_ms(100);
-		// Switching off the LED
+		// Ausschalten der LED
 		pin_set(debug_led);
-		// Software delay for 900 milliseconds.
+		// Softwareverzögerung für 900 ms.
 		sw_delay_ms(900);
 	}
@@ Line 115: / Line 114: @@
 </code>
-Auch wenn es scheint, dass die LED jede Sekunde blinkt, dauert es tatsächlich etwas länger, da das ansprechen der LED und die Verzögerungsfunktionen ein paar Taktfrequenzen des Microcontrollers nutzen.
+Auch wenn es so aussieht, als blinke die LED jede Sekunde, dauert es tatsächlich etwas länger, da das ansprechen der LED und die Verzögerungsfunktionen ein paar Taktfrequenzen des Mikrocontrollers benötigen.

de/examples/timer/software_delay.1289347131.txt.gz · Last modified: 2020/07/20 09:00 (external edit)