Lass die LED leuchten in C (PI4) - Versionsgeschichte

Satyria: /* Erklärung */

2025-03-05T12:37:55Z

Erklärung

Satyria am 5. März 2025 um 12:35 Uhr

2025-03-05T12:35:54Z

← Nächstältere Version		Version vom 5. März 2025, 13:35 Uhr
Zeile 6:		Zeile 6:


	== Programmierung des Startverhaltens des Raspberry Pi ==		== Programmierung des Startverhaltens des Raspberry Pi ('''boot.S''')==
	Leider kommen wir nicht ganz ohne Assembler aus. Der erste Code, der ausgeführt wird, sollte in Assembler geschrieben sein. In der Regel werden einige Eigenschaften der CPU definiert, die nur in Assembler möglich sind. Für dieses Beispiel benötigen wir das noch nicht, aber wir erstellen diese Datei, um für spätere Projekte vorbereitet zu sein. Erstellen Sie die Datei boot.S:		Leider kommen wir nicht ganz ohne Assembler aus. Der erste Code, der ausgeführt wird, sollte in Assembler geschrieben sein. In der Regel werden einige Eigenschaften der CPU definiert, die nur in Assembler möglich sind. Für dieses Beispiel benötigen wir das noch nicht, aber wir erstellen diese Datei, um für spätere Projekte vorbereitet zu sein. Erstellen Sie die Datei boot.S:

Zeile 39:		Zeile 39:
	Wenn das Programm startet, wird zunächst mit ldr (Load Register) das Register x0 mit dem Wert aus MEM_KERNEL_STACK belegt, der in der Include-Datei definiert wurde, und anschließend in den Stack-Zeiger (SP) abgelegt. Mit b (Branch) wird der Code zum Label sysinit verzweigt.		Wenn das Programm startet, wird zunächst mit ldr (Load Register) das Register x0 mit dem Wert aus MEM_KERNEL_STACK belegt, der in der Include-Datei definiert wurde, und anschließend in den Stack-Zeiger (SP) abgelegt. Mit b (Branch) wird der Code zum Label sysinit verzweigt.

	== Konfigurationsdatei config.h (eine Header-Datei) ==		== Konfigurationsdatei '''config.h''' (eine Header-Datei) ==
	=== Bedeutung und Struktur von Header-Dateien ===		=== Bedeutung und Struktur von Header-Dateien ===
	Unsere "'''config.h'''" ist eine Header-Datei. Header-Dateien werden verwendet, um Code zu organisieren und wieder verwendbar zu machen.		Unsere "'''config.h'''" ist eine Header-Datei. Header-Dateien werden verwendet, um Code zu organisieren und wieder verwendbar zu machen.
Zeile 141:		Zeile 141:
	Auf dem Raspberry Pi 4 können wir auf die GPIO-PINs direkt zugreifen, die für die Kommunikation mit der Außenwelt verwendet werden. Da eine PIN mit einer fest eingebauten LED verbunden ist, können wir auf externe Hardware verzichten.		Auf dem Raspberry Pi 4 können wir auf die GPIO-PINs direkt zugreifen, die für die Kommunikation mit der Außenwelt verwendet werden. Da eine PIN mit einer fest eingebauten LED verbunden ist, können wir auf externe Hardware verzichten.

	== Zugriff auf die GPIO-Pins ==		=== Zugriff auf die GPIO-Pins ===
	Der Raspberry Pi 4 hat 40 GPIO-Pins, von denen 26 als Ausgang oder Eingang programmiert werden können. Zusätzlich gibt es interne GPIO-Adressen, die per Programmierschnittstelle programmiert werden können. Eine davon ist die grüne LED, die über den Port 42 angesteuert wird.		Der Raspberry Pi 4 hat 40 GPIO-Pins, von denen 26 als Ausgang oder Eingang programmiert werden können. Zusätzlich gibt es interne GPIO-Adressen, die per Programmierschnittstelle programmiert werden können. Eine davon ist die grüne LED, die über den Port 42 angesteuert wird.

	== Konfiguration des GPIO-Registers ==		==== Konfiguration des GPIO-Registers ====
	Um die LED zu steuern, müssen wir das Register GPFSEL verwenden. Das Register GPFSEL4 ist für GPIO-Adresse 42 zuständig und jede GPIO-Adresse wird durch 3 Bits konfiguriert:		Um die LED zu steuern, müssen wir das Register GPFSEL verwenden. Das Register GPFSEL4 ist für GPIO-Adresse 42 zuständig und jede GPIO-Adresse wird durch 3 Bits konfiguriert:

Zeile 167:		Zeile 167:
	\|}		\|}

	== Funktion zur Konfiguration von GPIO-Pins ==		==== Funktion zur Konfiguration von GPIO-Pins ('''SetGPIOFunction''') ====

	<syntaxhighlight lang="C">		<syntaxhighlight lang="C">
Zeile 189:		Zeile 189:
	}		}
	</syntaxhighlight>		</syntaxhighlight>
	=== Erklärung ===		===== Erklärung =====
	Diese Funktion bestimmt das richtige GPFSEL-Register und setzt die entsprechende Funktion für den Pin. Zunächst wird die Basis-Adresse für GPIO_GPFSEL0 geladen, und durch eine Schleife die richtige Registeradresse und Pin-Position ermittelt. Der Inhalt des Registers wird gelesen, die entsprechenden Bits gelöscht und mit der neuen Funktion überschrieben.		Diese Funktion bestimmt das richtige GPFSEL-Register und setzt die entsprechende Funktion für den Pin. Zunächst wird die Basis-Adresse für GPIO_GPFSEL0 geladen, und durch eine Schleife die richtige Registeradresse und Pin-Position ermittelt. Der Inhalt des Registers wird gelesen, die entsprechenden Bits gelöscht und mit der neuen Funktion überschrieben.

	== Funktionen zur Steuerung der LED ==		=== Funktionen zur Steuerung der LED ('''LED_on''', '''LED_off''') ===

	<syntaxhighlight lang="C">		<syntaxhighlight lang="C">
Zeile 224:		Zeile 224:
	</syntaxhighlight>		</syntaxhighlight>

	=== Erklärung ===		==== Erklärung ====
	Wir erstellen zwei Funktionen, LED_on und LED_off, um die LED ein- und auszuschalten. Beide Funktionen setzen den entsprechenden Pin (42) auf "Output", ermitteln das richtige GPSET oder GPCLR-Register und setzen bzw. löschen das entsprechende Bit, um die LED zu steuern.		Wir erstellen zwei Funktionen, LED_on und LED_off, um die LED ein- und auszuschalten. Beide Funktionen setzen den entsprechenden Pin (42) auf "Output", ermitteln das richtige GPSET oder GPCLR-Register und setzen bzw. löschen das entsprechende Bit, um die LED zu steuern.

	== Basiskonfigurationsdatei base.h ==		== Basiskonfigurationsdatei '''base.h''' ==
	Die Datei '''base.h''' enthält Basisadressen für den Raspberry Pi:		Die Datei '''base.h''' enthält Basisadressen für den Raspberry Pi:

Zeile 288:		Zeile 288:
	Mit '''#define RPI_BASE 0xFE000000''' legen wir die Basisadresse der Peripheriegeräte fest. Dies dient als Grundlage für alle anderen Geräte, die wir verwenden. '''#define GPIO_BASE (RPI_BASE + 0x200000)''' legt die Basisadresse des GPIO fest.		Mit '''#define RPI_BASE 0xFE000000''' legen wir die Basisadresse der Peripheriegeräte fest. Dies dient als Grundlage für alle anderen Geräte, die wir verwenden. '''#define GPIO_BASE (RPI_BASE + 0x200000)''' legt die Basisadresse des GPIO fest.

	== read32 und write32 ==		== '''read32''' und '''write32''' ==
	Diese zwei Funktionen ermöglichen direkten Zugriff auf den Speicher des Raspberry Pi 4. Wir definieren diese Funktionen in Assembler, um einfacher auf die Hardware zugreifen zu können.		Diese zwei Funktionen ermöglichen direkten Zugriff auf den Speicher des Raspberry Pi 4. Wir definieren diese Funktionen in Assembler, um einfacher auf die Hardware zugreifen zu können.

Zeile 316:		Zeile 316:
	</syntaxhighlight>		</syntaxhighlight>

	Speichern Sie die Datei als util.S.		Speichern Sie die Datei als '''util.S'''.

	=== Erklärung ===		=== Erklärung ===
Zeile 380:		Zeile 380:
	* '''Interne und Externe Sichtbarkeit''': Header-Dateien können genutzt werden, um die Sichtbarkeit von Funktionen und Variablen zu steuern. Funktionen, die in einer Header-Datei deklariert sind, sind für alle Quellcodedateien sichtbar, die diese Header-Datei einbinden. Funktionen, die nur in der Quellcodedatei definiert sind, sind dagegen nur in dieser Datei sichtbar (statische Funktionen).		* '''Interne und Externe Sichtbarkeit''': Header-Dateien können genutzt werden, um die Sichtbarkeit von Funktionen und Variablen zu steuern. Funktionen, die in einer Header-Datei deklariert sind, sind für alle Quellcodedateien sichtbar, die diese Header-Datei einbinden. Funktionen, die nur in der Quellcodedatei definiert sind, sind dagegen nur in dieser Datei sichtbar (statische Funktionen).

	In unserem Code fehlen nun noch drei Header-Dateien: led.h, time.h und types.h.		In unserem Code fehlen nun noch drei Header-Dateien: '''led.h''', '''time.h''' und '''types.h'''.

	=== Die led.h ===		=== Die '''led.h''' ===
	<syntaxhighlight lang="C">		<syntaxhighlight lang="C">
	//		//
Zeile 417:		Zeile 417:
	Diese Header-Datei definiert die Funktionsaufrufe LED_off, LED_on und SetGPIOFunction. Die Funktionsaufrufe LED_off und LED_on erwarten keine Parameter und geben keine Parameter zurück, was durch das Schlüsselwort void erkennbar ist. SetGPIOFunction erwartet den PIN und die Funktion als u32-Wert.		Diese Header-Datei definiert die Funktionsaufrufe LED_off, LED_on und SetGPIOFunction. Die Funktionsaufrufe LED_off und LED_on erwarten keine Parameter und geben keine Parameter zurück, was durch das Schlüsselwort void erkennbar ist. SetGPIOFunction erwartet den PIN und die Funktion als u32-Wert.

	=== Die time.h ===		=== Die '''time.h''' ===
	<syntaxhighlight lang="C">		<syntaxhighlight lang="C">
	//		//
Zeile 439:		Zeile 439:
	Hier wird der Funktionsaufruf wait definiert. Diese Funktion gibt keinen Wert zurück, erwartet aber einen u32-Wert als Parameter. Der Typ u32 wird im nächsten Header types.h definiert. Deswegen wurde diese Datei inkludiert, damit der Compiler weiß, was u32 bedeutet.		Hier wird der Funktionsaufruf wait definiert. Diese Funktion gibt keinen Wert zurück, erwartet aber einen u32-Wert als Parameter. Der Typ u32 wird im nächsten Header types.h definiert. Deswegen wurde diese Datei inkludiert, damit der Compiler weiß, was u32 bedeutet.

	=== Die types.h ===		=== Die '''types.h''' ===
	<syntaxhighlight lang="C">		<syntaxhighlight lang="C">
	//		//
Zeile 479:		Zeile 479:
	==== Erklärung ====		==== Erklärung ====

	Der Header types.h definiert verschiedene Datentypen und einige Makros, die in einem C-Programm verwendet werden können:		Der Header '''types.h''' definiert verschiedene Datentypen und einige Makros, die in einem C-Programm verwendet werden können:

	Typdefinitionen:		Typdefinitionen:

Satyria am 5. März 2025 um 12:29 Uhr

2025-03-05T12:29:37Z

← Nächstältere Version		Version vom 5. März 2025, 13:29 Uhr
Zeile 370:		Zeile 370:
	for (i = 0; i < zyklen; i++): Erzeugt eine Schleife und zählt i hoch, solange i kleiner als zyklen ist.		for (i = 0; i < zyklen; i++): Erzeugt eine Schleife und zählt i hoch, solange i kleiner als zyklen ist.
	{...}: Leere Schleife zur Verzögerung.		{...}: Leere Schleife zur Verzögerung.
	=== Weitere Header-Dateien ===		== Weitere Header-Dateien ==
	In C werden Funktionen häufig in Header-Dateien (mit der Endung .h) deklariert, bevor sie in den eigentlichen Quellcodedateien (mit der Endung .c) definiert werden. Dies hat mehrere wichtige Gründe:		In C werden Funktionen häufig in Header-Dateien (mit der Endung .h) deklariert, bevor sie in den eigentlichen Quellcodedateien (mit der Endung .c) definiert werden. Dies hat mehrere wichtige Gründe:

Zeile 382:		Zeile 382:
	In unserem Code fehlen nun noch drei Header-Dateien: led.h, time.h und types.h.		In unserem Code fehlen nun noch drei Header-Dateien: led.h, time.h und types.h.

	== Die led.h ==		=== Die led.h ===
	<syntaxhighlight lang="C">		<syntaxhighlight lang="C">
	//		//
Zeile 413:		Zeile 413:
	#endif		#endif
	</syntaxhighlight>		</syntaxhighlight>
	=== Erklärung ===		==== Erklärung ====

	Diese Header-Datei definiert die Funktionsaufrufe LED_off, LED_on und SetGPIOFunction. Die Funktionsaufrufe LED_off und LED_on erwarten keine Parameter und geben keine Parameter zurück, was durch das Schlüsselwort void erkennbar ist. SetGPIOFunction erwartet den PIN und die Funktion als u32-Wert.		Diese Header-Datei definiert die Funktionsaufrufe LED_off, LED_on und SetGPIOFunction. Die Funktionsaufrufe LED_off und LED_on erwarten keine Parameter und geben keine Parameter zurück, was durch das Schlüsselwort void erkennbar ist. SetGPIOFunction erwartet den PIN und die Funktion als u32-Wert.

	== Die time.h ==		=== Die time.h ===
	<syntaxhighlight lang="C">		<syntaxhighlight lang="C">
	//		//
Zeile 435:		Zeile 435:
	#endif		#endif
	</syntaxhighlight>		</syntaxhighlight>
	=== Erklärung ===		==== Erklärung ====

	Hier wird der Funktionsaufruf wait definiert. Diese Funktion gibt keinen Wert zurück, erwartet aber einen u32-Wert als Parameter. Der Typ u32 wird im nächsten Header types.h definiert. Deswegen wurde diese Datei inkludiert, damit der Compiler weiß, was u32 bedeutet.		Hier wird der Funktionsaufruf wait definiert. Diese Funktion gibt keinen Wert zurück, erwartet aber einen u32-Wert als Parameter. Der Typ u32 wird im nächsten Header types.h definiert. Deswegen wurde diese Datei inkludiert, damit der Compiler weiß, was u32 bedeutet.

	== Die types.h ==		=== Die types.h ===
	<syntaxhighlight lang="C">		<syntaxhighlight lang="C">
	//		//
Zeile 477:		Zeile 477:
	#endif		#endif
	</syntaxhighlight>		</syntaxhighlight>
	=== Erklärung ===		==== Erklärung ====

	Der Header types.h definiert verschiedene Datentypen und einige Makros, die in einem C-Programm verwendet werden können:		Der Header types.h definiert verschiedene Datentypen und einige Makros, die in einem C-Programm verwendet werden können:

Satyria: /* Weitere Header-Dateien */

2025-03-05T12:28:10Z

Weitere Header-Dateien

← Nächstältere Version		Version vom 5. März 2025, 13:28 Uhr
Zeile 373:		Zeile 373:
	In C werden Funktionen häufig in Header-Dateien (mit der Endung .h) deklariert, bevor sie in den eigentlichen Quellcodedateien (mit der Endung .c) definiert werden. Dies hat mehrere wichtige Gründe:		In C werden Funktionen häufig in Header-Dateien (mit der Endung .h) deklariert, bevor sie in den eigentlichen Quellcodedateien (mit der Endung .c) definiert werden. Dies hat mehrere wichtige Gründe:

	* Modularität und Wiederverwendbarkeit: Header-Dateien ermöglichen es, den Code in verschiedene Module zu unterteilen. Dadurch können Funktionen und Datenstrukturen in mehreren Quellcodedateien wiederverwendet werden, ohne den Code duplizieren zu müssen.		* '''Modularität und Wiederverwendbarkeit''': Header-Dateien ermöglichen es, den Code in verschiedene Module zu unterteilen. Dadurch können Funktionen und Datenstrukturen in mehreren Quellcodedateien wiederverwendet werden, ohne den Code duplizieren zu müssen.
	* Trennung von Deklaration und Definition: Die Deklaration einer Funktion in einer Header-Datei informiert den Compiler über die Existenz und das Interface der Funktion (Name, Rückgabewert, Parameter), ohne den vollständigen Funktionscode zur Verfügung zu stellen. Die Definition, die den eigentlichen Code enthält, befindet sich in der entsprechenden .c-Datei. Dies unterstützt das Prinzip der Informationsverbergung (Encapsulation), indem es die Implementierungsdetails von der Schnittstelle trennt.		* '''Trennung von Deklaration und Definition''': Die Deklaration einer Funktion in einer Header-Datei informiert den Compiler über die Existenz und das Interface der Funktion (Name, Rückgabewert, Parameter), ohne den vollständigen Funktionscode zur Verfügung zu stellen. Die Definition, die den eigentlichen Code enthält, befindet sich in der entsprechenden .c-Datei. Dies unterstützt das Prinzip der Informationsverbergung (Encapsulation), indem es die Implementierungsdetails von der Schnittstelle trennt.
	* Vermeidung von Mehrfachdeklarationen: Durch das Einfügen der Header-Datei in mehrere Quellcodedateien (#include "header.h") wird sichergestellt, dass alle Quellcodedateien die gleichen Funktionsdeklarationen verwenden. Dies verhindert Fehler durch inkonsistente Deklarationen.		* '''Vermeidung von Mehrfachdeklarationen''': Durch das Einfügen der Header-Datei in mehrere Quellcodedateien (#include "header.h") wird sichergestellt, dass alle Quellcodedateien die gleichen Funktionsdeklarationen verwenden. Dies verhindert Fehler durch inkonsistente Deklarationen.
	* Erleichterung der Wartung: Änderungen an der Funktionsdeklaration (z.B. Änderung der Parameter) müssen nur in der Header-Datei vorgenommen werden. Alle Quellcodedateien, die diese Header-Datei einbinden, verwenden automatisch die aktualisierte Deklaration.		* '''Erleichterung der Wartung''': Änderungen an der Funktionsdeklaration (z.B. Änderung der Parameter) müssen nur in der Header-Datei vorgenommen werden. Alle Quellcodedateien, die diese Header-Datei einbinden, verwenden automatisch die aktualisierte Deklaration.
	* Kompilierung und Linken: Während des Kompilierens überprüft der Compiler die Header-Dateien, um sicherzustellen, dass die Funktionsaufrufe korrekt sind. Beim Linken werden dann die tatsächlichen Funktionsdefinitionen aus den Quellcodedateien zusammengeführt. Dies ermöglicht es auch, große Projekte effizient zu kompilieren, indem nur die geänderten Dateien neu kompiliert werden müssen, während die unveränderten Dateien aus der letzten Kompilierung wiederverwendet werden können.		* '''Kompilierung und Linken''': Während des Kompilierens überprüft der Compiler die Header-Dateien, um sicherzustellen, dass die Funktionsaufrufe korrekt sind. Beim Linken werden dann die tatsächlichen Funktionsdefinitionen aus den Quellcodedateien zusammengeführt. Dies ermöglicht es auch, große Projekte effizient zu kompilieren, indem nur die geänderten Dateien neu kompiliert werden müssen, während die unveränderten Dateien aus der letzten Kompilierung wiederverwendet werden können.
	* Interne und Externe Sichtbarkeit: Header-Dateien können genutzt werden, um die Sichtbarkeit von Funktionen und Variablen zu steuern. Funktionen, die in einer Header-Datei deklariert sind, sind für alle Quellcodedateien sichtbar, die diese Header-Datei einbinden. Funktionen, die nur in der Quellcodedatei definiert sind, sind dagegen nur in dieser Datei sichtbar (statische Funktionen).		* '''Interne und Externe Sichtbarkeit''': Header-Dateien können genutzt werden, um die Sichtbarkeit von Funktionen und Variablen zu steuern. Funktionen, die in einer Header-Datei deklariert sind, sind für alle Quellcodedateien sichtbar, die diese Header-Datei einbinden. Funktionen, die nur in der Quellcodedatei definiert sind, sind dagegen nur in dieser Datei sichtbar (statische Funktionen).

	In unserem Code fehlen nun noch drei Header-Dateien: led.h, time.h und types.h.		In unserem Code fehlen nun noch drei Header-Dateien: led.h, time.h und types.h.

Satyria: /* Erklärung */

2025-03-05T12:26:31Z

Erklärung

← Nächstältere Version		Version vom 5. März 2025, 13:26 Uhr
Zeile 416:		Zeile 416:
	Diese Header-Datei definiert die Funktionsaufrufe LED_off, LED_on und SetGPIOFunction. Die Funktionsaufrufe LED_off und LED_on erwarten keine Parameter und geben keine Parameter zurück, was durch das Schlüsselwort void erkennbar ist. SetGPIOFunction erwartet den PIN und die Funktion als u32-Wert.		Diese Header-Datei definiert die Funktionsaufrufe LED_off, LED_on und SetGPIOFunction. Die Funktionsaufrufe LED_off und LED_on erwarten keine Parameter und geben keine Parameter zurück, was durch das Schlüsselwort void erkennbar ist. SetGPIOFunction erwartet den PIN und die Funktion als u32-Wert.

	Die time.h		== Die time.h ==
	<syntaxhighlight lang="C">		<syntaxhighlight lang="C">
	//		//
Zeile 434:		Zeile 434:
	#endif		#endif
	</syntaxhighlight>		</syntaxhighlight>
	Erklärung:		=== Erklärung ===

	Hier wird der Funktionsaufruf wait definiert. Diese Funktion gibt keinen Wert zurück, erwartet aber einen u32-Wert als Parameter. Der Typ u32 wird im nächsten Header types.h definiert. Deswegen wurde diese Datei inkludiert, damit der Compiler weiß, was u32 bedeutet.		Hier wird der Funktionsaufruf wait definiert. Diese Funktion gibt keinen Wert zurück, erwartet aber einen u32-Wert als Parameter. Der Typ u32 wird im nächsten Header types.h definiert. Deswegen wurde diese Datei inkludiert, damit der Compiler weiß, was u32 bedeutet.

	Die types.h		== Die types.h ==
	<syntaxhighlight lang="C">		<syntaxhighlight lang="C">
	//		//
Zeile 476:		Zeile 476:
	#endif		#endif
	</syntaxhighlight>		</syntaxhighlight>
	Erklärung:		=== Erklärung ===

	Der Header types.h definiert verschiedene Datentypen und einige Makros, die in einem C-Programm verwendet werden können:		Der Header types.h definiert verschiedene Datentypen und einige Makros, die in einem C-Programm verwendet werden können:
Zeile 506:		Zeile 506:
	Zusammengefasst definiert dieser Header eine Reihe von neuen Typen und Makros, die die Lesbarkeit und Portabilität des Codes verbessern, indem sie standardisierte Namen und Werte bereitstellen.		Zusammengefasst definiert dieser Header eine Reihe von neuen Typen und Makros, die die Lesbarkeit und Portabilität des Codes verbessern, indem sie standardisierte Namen und Werte bereitstellen.

	Kompilieren und Ausführen		== Kompilieren und Ausführen ==

	Wechseln Sie in das Verzeichnis LED und kompilieren Sie das Programm mit dem Befehl make. Wenn alles erfolgreich war, erhalten Sie eine Datei kernel8.img, die auf eine SD-Karte kopiert und im Raspberry Pi verwendet wird. Schalten Sie den Raspberry Pi ein, und die LED sollte blinken.		Wechseln Sie in das Verzeichnis LED und kompilieren Sie das Programm mit dem Befehl make. Wenn alles erfolgreich war, erhalten Sie eine Datei kernel8.img, die auf eine SD-Karte kopiert und im Raspberry Pi verwendet wird. Schalten Sie den Raspberry Pi ein, und die LED sollte blinken.

Satyria am 5. März 2025 um 12:24 Uhr

2025-03-05T12:24:49Z

Änderungen zeigen

Satyria: /* Erklärung */

2025-03-05T12:22:07Z

Erklärung

← Nächstältere Version		Version vom 5. März 2025, 13:22 Uhr
Zeile 417:		Zeile 417:

	Die time.h		Die time.h
			<syntaxhighlight lang="C">
	//		//
	// The LED program for RPI4		// The LED program for RPI4
Zeile 432:		Zeile 433:

	#endif		#endif
			</syntaxhighlight>
	Erklärung:		Erklärung:

Zeile 438:		Zeile 439:

	Die types.h		Die types.h
			<syntaxhighlight lang="C">
	//		//
	// The LED program for RPI4		// The LED program for RPI4
Zeile 473:		Zeile 475:

	#endif		#endif
			</syntaxhighlight>
	Erklärung:		Erklärung:

Satyria: /* Wartefunktion wait */

2025-03-05T12:19:47Z

Wartefunktion wait

← Nächstältere Version		Version vom 5. März 2025, 13:19 Uhr
Zeile 344:		Zeile 344:

	== Wartefunktion '''wait'''==		== Wartefunktion '''wait'''==
	~~Wartefunktion wait~~
	Zuletzt erstellen wir die Datei time.c für die Wartefunktion:		Zuletzt erstellen wir die Datei time.c für die Wartefunktion:

	C		<syntaxhighlight lang="C">
	~~Copy code~~
	//		//
	// The LED program for RPI4		// The LED program for RPI4
Zeile 366:		Zeile 365:
	}		}
	}		}
	Erklärung:		</syntaxhighlight>
			=== Erklärung ===
	volatile u32 i: Erzeugt die Variable i. Durch volatile wird die Schleife bei der Code-Optimierung nicht optimiert.		volatile u32 i: Erzeugt die Variable i. Durch volatile wird die Schleife bei der Code-Optimierung nicht optimiert.
	for (i = 0; i < zyklen; i++): Erzeugt eine Schleife und zählt i hoch, solange i kleiner als zyklen ist.		for (i = 0; i < zyklen; i++): Erzeugt eine Schleife und zählt i hoch, solange i kleiner als zyklen ist.
	{...}: Leere Schleife zur Verzögerung.		{...}: Leere Schleife zur Verzögerung.
	Weitere Header-Dateien		=== Weitere Header-Dateien ===
	In C werden Funktionen häufig in Header-Dateien (mit der Endung .h) deklariert, bevor sie in den eigentlichen Quellcodedateien (mit der Endung .c) definiert werden. Dies hat mehrere wichtige Gründe:		In C werden Funktionen häufig in Header-Dateien (mit der Endung .h) deklariert, bevor sie in den eigentlichen Quellcodedateien (mit der Endung .c) definiert werden. Dies hat mehrere wichtige Gründe:

	Modularität und Wiederverwendbarkeit: Header-Dateien ermöglichen es, den Code in verschiedene Module zu unterteilen. Dadurch können Funktionen und Datenstrukturen in mehreren Quellcodedateien wiederverwendet werden, ohne den Code duplizieren zu müssen.		* Modularität und Wiederverwendbarkeit: Header-Dateien ermöglichen es, den Code in verschiedene Module zu unterteilen. Dadurch können Funktionen und Datenstrukturen in mehreren Quellcodedateien wiederverwendet werden, ohne den Code duplizieren zu müssen.
	Trennung von Deklaration und Definition: Die Deklaration einer Funktion in einer Header-Datei informiert den Compiler über die Existenz und das Interface der Funktion (Name, Rückgabewert, Parameter), ohne den vollständigen Funktionscode zur Verfügung zu stellen. Die Definition, die den eigentlichen Code enthält, befindet sich in der entsprechenden .c-Datei. Dies unterstützt das Prinzip der Informationsverbergung (Encapsulation), indem es die Implementierungsdetails von der Schnittstelle trennt.		* Trennung von Deklaration und Definition: Die Deklaration einer Funktion in einer Header-Datei informiert den Compiler über die Existenz und das Interface der Funktion (Name, Rückgabewert, Parameter), ohne den vollständigen Funktionscode zur Verfügung zu stellen. Die Definition, die den eigentlichen Code enthält, befindet sich in der entsprechenden .c-Datei. Dies unterstützt das Prinzip der Informationsverbergung (Encapsulation), indem es die Implementierungsdetails von der Schnittstelle trennt.
	Vermeidung von Mehrfachdeklarationen: Durch das Einfügen der Header-Datei in mehrere Quellcodedateien (#include "header.h") wird sichergestellt, dass alle Quellcodedateien die gleichen Funktionsdeklarationen verwenden. Dies verhindert Fehler durch inkonsistente Deklarationen.		* Vermeidung von Mehrfachdeklarationen: Durch das Einfügen der Header-Datei in mehrere Quellcodedateien (#include "header.h") wird sichergestellt, dass alle Quellcodedateien die gleichen Funktionsdeklarationen verwenden. Dies verhindert Fehler durch inkonsistente Deklarationen.
	Erleichterung der Wartung: Änderungen an der Funktionsdeklaration (z.B. Änderung der Parameter) müssen nur in der Header-Datei vorgenommen werden. Alle Quellcodedateien, die diese Header-Datei einbinden, verwenden automatisch die aktualisierte Deklaration.		* Erleichterung der Wartung: Änderungen an der Funktionsdeklaration (z.B. Änderung der Parameter) müssen nur in der Header-Datei vorgenommen werden. Alle Quellcodedateien, die diese Header-Datei einbinden, verwenden automatisch die aktualisierte Deklaration.
	Kompilierung und Linken: Während des Kompilierens überprüft der Compiler die Header-Dateien, um sicherzustellen, dass die Funktionsaufrufe korrekt sind. Beim Linken werden dann die tatsächlichen Funktionsdefinitionen aus den Quellcodedateien zusammengeführt. Dies ermöglicht es auch, große Projekte effizient zu kompilieren, indem nur die geänderten Dateien neu kompiliert werden müssen, während die unveränderten Dateien aus der letzten Kompilierung wiederverwendet werden können.		* Kompilierung und Linken: Während des Kompilierens überprüft der Compiler die Header-Dateien, um sicherzustellen, dass die Funktionsaufrufe korrekt sind. Beim Linken werden dann die tatsächlichen Funktionsdefinitionen aus den Quellcodedateien zusammengeführt. Dies ermöglicht es auch, große Projekte effizient zu kompilieren, indem nur die geänderten Dateien neu kompiliert werden müssen, während die unveränderten Dateien aus der letzten Kompilierung wiederverwendet werden können.
	Interne und Externe Sichtbarkeit: Header-Dateien können genutzt werden, um die Sichtbarkeit von Funktionen und Variablen zu steuern. Funktionen, die in einer Header-Datei deklariert sind, sind für alle Quellcodedateien sichtbar, die diese Header-Datei einbinden. Funktionen, die nur in der Quellcodedatei definiert sind, sind dagegen nur in dieser Datei sichtbar (statische Funktionen).		* Interne und Externe Sichtbarkeit: Header-Dateien können genutzt werden, um die Sichtbarkeit von Funktionen und Variablen zu steuern. Funktionen, die in einer Header-Datei deklariert sind, sind für alle Quellcodedateien sichtbar, die diese Header-Datei einbinden. Funktionen, die nur in der Quellcodedatei definiert sind, sind dagegen nur in dieser Datei sichtbar (statische Funktionen).
	In unserem Code fehlen nun noch drei Header-Dateien: led.h, time.h und types.h.		In unserem Code fehlen nun noch drei Header-Dateien: led.h, time.h und types.h.

	~~Hier ist der überarbeitete Text, angepasst für einen Tutor:~~		== Die led.h ==
			<syntaxhighlight lang="C">
	Die led.h
	//		//
	// The LED program for RPI4		// The LED program for RPI4
Zeile 412:		Zeile 411:

	#endif		#endif
			</syntaxhighlight>
	Erklärung:		=== Erklärung ===

	Diese Header-Datei definiert die Funktionsaufrufe LED_off, LED_on und SetGPIOFunction. Die Funktionsaufrufe LED_off und LED_on erwarten keine Parameter und geben keine Parameter zurück, was durch das Schlüsselwort void erkennbar ist. SetGPIOFunction erwartet den PIN und die Funktion als u32-Wert.		Diese Header-Datei definiert die Funktionsaufrufe LED_off, LED_on und SetGPIOFunction. Die Funktionsaufrufe LED_off und LED_on erwarten keine Parameter und geben keine Parameter zurück, was durch das Schlüsselwort void erkennbar ist. SetGPIOFunction erwartet den PIN und die Funktion als u32-Wert.
Zeile 510:		Zeile 509:

	Sie können den Source-Code als ZIP-Datei mit folgendem Link herunterladen: https://www.satyria.de/arm/sources/RPI4/C/2.zip		Sie können den Source-Code als ZIP-Datei mit folgendem Link herunterladen: https://www.satyria.de/arm/sources/RPI4/C/2.zip

	~~Änderungen und Erläuterungen:~~
	~~Klarere Strukturierung: Der Text wurde in klare Abschnitte unterteilt, um die Lesbarkeit zu verbessern.~~
	~~Erklärungen konkretisiert: Erklärungen zu Funktionen und Anweisungen wurden detaillierter und präziser formuliert.~~
	~~Code-Beispiele angepasst: Zusätzliche Kommentare und korrekte Formatierung wurden hinzugefügt, um die Bedeutung der Codezeilen klarer darzustellen.~~
	~~Formatierung verbessert: Formatierungen, wie die Verwendung von Codeblöcken, wurden verbessert, um visuelle Klarheit in der Unterscheidung von Code und Erklärungen zu schaffen.~~
	~~Kommentare überarbeitet: Kommentare im Code wurden verbessert, um die Bedeutung einzelner Anweisungen klarer darzustellen.~~
	~~Zusätzliche Erklärungen: Weitere Erklärungen wurden hinzugefügt, um die Bedeutung einiger Makros und Typen klarer darzustellen.~~

	~~Diese Änderungen sollen den Text klarer, besser strukturiert und für einen Tutor nutzbarer machen.~~

	== Weitere Header-Dateien ==		== Weitere Header-Dateien ==

Satyria: /* Wartefunktion wait */

2025-03-05T12:13:40Z

Wartefunktion wait

Änderungen zeigen

Satyria am 5. März 2025 um 12:06 Uhr

2025-03-05T12:06:51Z

Änderungen zeigen

← Nächstältere Version		Version vom 5. März 2025, 13:37 Uhr
Zeile 481:		Zeile 481:
	Der Header '''types.h''' definiert verschiedene Datentypen und einige Makros, die in einem C-Programm verwendet werden können:		Der Header '''types.h''' definiert verschiedene Datentypen und einige Makros, die in einem C-Programm verwendet werden können:

	Typdefinitionen:		* Typdefinitionen:
	Unsigned Types:		** Unsigned Types:
	u8: ein Alias für unsigned char (8-Bit)		*** u8: ein Alias für unsigned char (8-Bit)
	u16: ein Alias für unsigned short (16-Bit)		*** u16: ein Alias für unsigned short (16-Bit)
	u32: ein Alias für unsigned int (32-Bit)		*** u32: ein Alias für unsigned int (32-Bit)
	u64: ein Alias für unsigned long (64-Bit)		*** u64: ein Alias für unsigned long (64-Bit)
	Signed Types:		** Signed Types:
	s8: ein Alias für signed char (8-Bit)		*** s8: ein Alias für signed char (8-Bit)
	s16: ein Alias für signed short (16-Bit)		*** s16: ein Alias für signed short (16-Bit)
	s32: ein Alias für signed int (32-Bit)		*** s32: ein Alias für signed int (32-Bit)
	s64: ein Alias für signed long (64-Bit)		*** s64: ein Alias für signed long (64-Bit)
	Pointer Types:		** Pointer Types:
	intptr: ein Alias für long, um einen Integer zu speichern, der groß genug ist, um einen Zeiger zu halten		*** intptr: ein Alias für long, um einen Integer zu speichern, der groß genug ist, um einen Zeiger zu halten
	uintptr: ein Alias für unsigned long, für einen unsigned Integer, der groß genug ist, um einen Zeiger zu halten		*** uintptr: ein Alias für unsigned long, für einen unsigned Integer, der groß genug ist, um einen Zeiger zu halten
	Size Types:		** Size Types:
	size_t: ein Alias für unsigned long, typischerweise verwendet für die Größe von Objekten		*** size_t: ein Alias für unsigned long, typischerweise verwendet für die Größe von Objekten
	ssize_t: ein Alias für long, typischerweise verwendet für signierte Größenangaben		*** ssize_t: ein Alias für long, typischerweise verwendet für signierte Größenangaben
	Boolean Type:		** Boolean Type:
	Ein neuer Typ boolean als Alias für char		*** Ein neuer Typ boolean als Alias für char
	Makros für Alignment:		* Makros für Alignment:
	ALIGN(n): ein Makro, das das GCC-spezifische __attribute__((aligned(n))) verwendet, um die Ausrichtung eines Datentyps auf n Bytes zu erzwingen		** ALIGN(n): ein Makro, das das GCC-spezifische __attribute__((aligned(n))) verwendet, um die Ausrichtung eines Datentyps auf n Bytes zu erzwingen
	Boolean Values:		* Boolean Values:
	FALSE und TRUE werden als 0 und 1 definiert		** FALSE und TRUE werden als 0 und 1 definiert

	Zusammengefasst definiert dieser Header eine Reihe von neuen Typen und Makros, die die Lesbarkeit und Portabilität des Codes verbessern, indem sie standardisierte Namen und Werte bereitstellen.		Zusammengefasst definiert dieser Header eine Reihe von neuen Typen und Makros, die die Lesbarkeit und Portabilität des Codes verbessern, indem sie standardisierte Namen und Werte bereitstellen.