Lass die LED leuchten in C (PI4)

Unser jetziges Ziel ist es, die fest eingebaute LED des Raspberry Pi zum Blinken zu bringen. Ich werde jeden Schritt erklären, warum er in diesem Projekt so implementiert wurde.

Vorbereitung des Verzeichnisses

Erstelle zunächst ein neues Verzeichnis, z.B. LED, und platziere darin das Makefile und die Datei linker.ld. Erzeuge auch das Verzeichnis include innerhalb von LED, um unsere Header-Dateien zu organisieren.

Programmierung des Startverhaltens des Raspberry Pi

Leider kommen wir nicht ganz an Assembler vorbei. Der erste Code, der Ausgeführt wird, sollte in Assembler geschrieben sein. In der Regel werden dort einige Eigenschaften der CPU definiert, die "nur" in Assembler möglich ist. Bei diesem Beispiel ist das noch nicht nötig, aber wir erstellen diese Datei, damit wir bei späteren Projekten schon vorbereitet sind. Hierzu erstellen wir die Datei "boot.S":

//
// The LED program for RPI4
// 20.02.2025 www.satyria.de
//
// boot.S
//

#include "config.h"

.section .init                // Ensure the linker places this at the beginning of the kernel image
.global _start                // Execution starts here

_start:
  ldr x0, =MEM_KERNEL_STACK
  mov sp, x0                  // init its stack	
  b sysinit

Erklärung:

• #include "config.h": Inkludiert die Konfigurationsdatei, in der wir benötigte Parameter definieren.
• .section .init: Definiert einen Abschnitt, der am Anfang des Kernel-Images platziert wird. Laut Linker-Script ist dies die erste Position im Speicher, die ab der Adresse 0x80000 abgelegt wird. Dies ist auch die Adresse, die der Raspberry Pi bei einem initialen Start als erstes anspringt.
• .global _start: Deklariert _start als global, damit es von allen Programmteilen verwendet werden kann.
• _start:: Label, das den Startpunkt der Ausführung markiert.
• ldr x0, =MEM_KERNEL_STACK: Lädt die Adresse von MEM_KERNEL_STACK in das Register x0, wie es in "config.h" definiert ist.
• mov sp, x0: Initialisiert den Stack-Zeiger "SP".
• b sysinit: Springt zur Funktion "sysinit", die später implementiert wird.

Wenn wir das Programm starten, wird zunächst mit "ldr" (Load Register) das Register "x0" mit dem Wert aus "MEM_KERNEL_STACK" belegt, welcher im Include definiert wurde, und anschließend in den Stack-Zeiger (SP) abgelegt. Mit "b" (Branch, Sprung) springt der Code an das Label "sysinit".

Konfigurationsdatei config.h, eine Header-Datei

Bedeutung und Struktur von Header-Dateien

Unsere "config.h" ist eine Header-Datei. Grundsätzlich werden Header-Dateien in der Programmierung verwendet, um Code zu organisieren und wiederverwendbar zu machen. Hier sind die Hauptgründe erläutert:

• Strukturierung: Header-Dateien helfen dabei, den Code in kleinere, übersichtliche Teile zu gliedern. Funktionen, Variablen und Konstanten, die in mehreren Dateien verwendet werden, können in einer Header-Datei deklariert werden.
• Wiederverwendbarkeit: Einmal geschriebener Code in einer Header-Datei kann in mehreren Programmen oder Dateien verwendet werden, ohne den Code jedes Mal neu schreiben zu müssen.
• Vereinfachung: Durch die Verwendung von Header-Dateien wird der Code übersichtlicher und leichter verständlich. Anstatt alle Funktionen in einer einzigen Datei zu haben, können sie in kleinere, logische Teile aufgeteilt werden.
• Vermeidung von Doppelarbeit: Wenn sich ein Funktionsprototyp oder eine Konstante ändert, muss diese Änderung nur in der Header-Datei vorgenommen werden, anstatt in jeder Datei, die diese verwendet.

Zusammengefasst: Header-Dateien machen den Code übersichtlicher, wiederverwendbarer und leichter zu pflegen.

Unsere "config.h" ist nun wie folgt beschrieben:

//
// The LED program for RPI4
// 20.02.2025 www.satyria.de
//
// config.h
//

#ifndef _config_h
#define _config_h

#define MEGABYTE          0x100000

#define MEM_KERNEL_START  0x80000          // Startadresse des Hauptprogramms
#define KERNEL_MAX_SIZE   (2 * MEGABYTE)
#define MEM_KERNEL_END    (MEM_KERNEL_START + KERNEL_MAX_SIZE)
#define KERNEL_STACK_SIZE 0x20000
#define MEM_KERNEL_STACK  (MEM_KERNEL_END + KERNEL_STACK_SIZE)

#endif

Erklärung:

• #ifndef _config_h ... #endif: Verhindert, dass die Datei mehrfach inkludiert wird.
• #define: Weist Symbolen konstante Werte zu.
• MEM_KERNEL_STACK: Berechnet den Start des Kernel-Stacks basierend auf der Startadresse des Kernels und seiner maximalen Größe.

In diesem Header wird eine Bedingung abgefragt, ob die Variable _config_h bereits definiert wurde. Genauer gesagt, ob sie noch nicht definiert wurde. #ifndef bedeutet "if not defined", also "wenn nicht definiert". Wenn die Variable noch nicht definiert ist, wird alles verarbeitet, was bis zum #endif steht. Sollte die Variable bereits definiert sein, so wird alles übersprungen, was bis zum #endif steht.

Direkt nach der #ifndef-Anweisung wird die Variable mit #define _config_h definiert und ist damit dem Compiler bekannt.

Warum wird sowas in einem Header abgefragt? Der Compiler mag es überhaupt nicht, wenn Dinge mehrmals festgelegt werden. Sollte diese Header-Datei bereits an einer anderen Stelle aufgerufen worden sein, so überspringt der Compiler diese Festlegungen und es kommt nicht zu Mehrfachdefinitionen.

Funktion sysinit

Als nächstes erstellen wir die Funktion sysinit, die das System initialisiert:

//
// The LED program for RPI4
// 20.02.2025 www.satyria.de
//
// sysinit.S
//

.section .text
.globl sysinit
sysinit:
  b main

Erklärung:

• .section .text: Definiert einen Abschnitt für ausführbaren Code.
• .globl sysinit: Deklariert sysinit als global.
• b main: Springt zur Funktion main.

Hier wird das Label "sysinit" zunächst als global definiert, damit es auch außerhalb der Datei bekannt ist. Im vorhergehenden Code wird darauf verwiesen. Im Gegensatz zum vorhergehenden Code wird hier die Sektion .text verwendet. Diese Sektion definiert ausführbaren Code, der "irgendwo" im Speicher liegt. Die genaue Position wird durch den zuvor geschriebenen Code bestimmt und später vom Linker festgelegt. Der einzige Befehl, der hier steht, ist b main, was bedeutet, dass das Programm einen Sprung (branch) zum Label "main" macht. Später werden wir hier mehr Code einfügen.

Hauptprogramm main

Erstellen wir nun das Hauptprogramm:

//
// The LED program for RPI4
// 20.02.2025 www.satyria.de
//
// kernel.c
//

#include "led.h"
#include "time.h"

int main (void)
{
  while(1)
  {
    LED_off();
    wait(0x1F0000);
    LED_on();
    wait(0x1F0000);
  }
}

Erklärung:

• while(1): Erzeugt eine Endlosschleife, da 1 immer wahr ist.
• LED_off(): Schaltet die LED aus.
• wait(0x1F0000): Ruft die Wartefunktion auf.
• LED_on(): Schaltet die LED ein.

Mit int main (void) erstellen wir das Label, welches von sysinit aufgerufen wird.

Zunächst definieren wir eine Endlosschleife mit while. Alles was nach der geschweiften Klammer steht wird endlos wiederholt, da 1 immer wahr ist.

Der erste Befehl LED_off() Ruft die entsprechende Funktion auf, die wir später noch schreiben werden. Diese Funktion soll dann die fest eingebaute grüne LED am Raspberry Pi 4 ausschalten.

Als nächstes wird die Funktion wait aufgerufen. Diese Funktion erwartet einen Wert, der angibt, wie lange gewartet werden soll, bevor der nächste Befehl ausgeführt wird.

Nachdem wait aufgerufen wurde, wird die Funktion LED_on() aufgerufen, die die grüne LED wieder einschaltet. Danach wird erneut gewartet und das ganze Programm wird unendlich wiederholt.

LED-Steuerungsfunktionen

Auf dem Raspberry Pi 4 können wir auf die GPIO-PINs direkt einwirken, die der Raspberry Pi für die Kommunikation mit der Außenwelt verwendet werden können. Idealerweise ist ein PIN mit einer LED, die auf dem Board verbaut ist, verbunden, so dass wir zunächst auf externe Hardware verzichten können und effektiv ein Ergebnis zu sehen. Unter den Baremetal-Programmieren kommt dies einem “HelloWorld” Programm am nächsten. Damit wir diese LED blinken lassen können, müssen wir auf diese GPIO-Pins zugreifen.

Der Raspberry Pi besitzt einige GPIO, die gerade für Hardware Freunde interessant sind, da diese einfach zu programmieren sind und sich gut mit der Außenwelt verbinden lassen. Auf dem Raspberry Pi 4 gibt es 40 GPIO-Pins, von denen 26 Pins als Ausgang oder Eingang programmiert werden können.

Zusätzlich gibt es noch weitere interne GPIO-Adressen, die auch über die Programmierschnittstelle programmiert werden können. Eine davon ist die grüne LED, die über den Port 42 auf dem Raspberry Pi 4 angesteuert werden kann.

Zunächst müssen wir dem Raspberry mitteilen, was wir vorhaben. Dazu müssen wir dem Register GPFSEL mitteilen, wie er seine Pins verwendet soll. Laut Dokumentation im Kapitel 5 gibt es hierfür fünf GPFSEL Register, die für verschiedene GPIO-Adressen zuständig sind. GPFSEL0 ist für die GPIO-Adressen 0-9, GPFSEL1 für 10-19 usw. zuständig. Da unsere LED über GPIO-Adresse 42 angesprochen wird, müssen wir GPFSEL4 verwenden. Innerhalb des Registers hat jede GPIO-Adresse 3 Bits zur Verfügung um deren Funktion zu definieren oder aber auch abfragen zu können. Diese drei Bits sind wie folgt definiert:

Status des GPIO-Registers

000	PIN ist ein Eingang
001	PIN ist ein Ausgang
100	PIN hat die alternative Funktion 0
101	PIN hat die alternative Funktion 1
110	PIN hat die alternative Funktion 2
111	PIN hat die alternative Funktion 3
011	PIN hat die alternative Funktion 4
010	PIN hat die alternative Funktion 5

Als Status werden nur zwei Zustände fest angegeben. Dies sind die Status, den Pin entweder als Eingang oder als Ausgang zu definieren. Alle anderen Status werden einer alternativen Funktion zugeschrieben. Hierbei bedeutet die alternative Funktion des einen PINs nicht die gleiche Funktion des anderen Bits. Dazu kann in der Dokumentation im Kapitel 5.3 “Alternative Function Assignments” geschaut werden, welche es da gibt. Später, werden wir diese auch verwenden. Da wir nun eine LED ansteuern wollen, müssen wir hier die Funktion “001 - PIN ist ein Ausgang” verwenden. Im Register GPFSEL4 sind die drei Bits 8-6 zuständig für den Pin 42. Also hier müssen wir die Bitfolge “001” eintragen. Eine Möglichkeit wäre, diesen Bitcode einfach direkt reinzuschreiben “0b001000000”, aber da wir etwas in Zukunft blicken verwenden wir eine Funktion, deren wir einfach den GPIO-Pin und die Funktion übergeben.

void SetGPIOFunction(u32 Pin, u32 Function)
{
  u32 GPSEL = GPIO_GPFSEL0;
  while (Pin >= 10)
  {
    Pin = Pin -10;
    GPSEL = GPSEL + 4;
  }
  Pin = Pin *3;
  Function = Function << Pin;
  u32 mask = 0b111 << Pin;
  mask =~mask; //Bitweise negieren

  u32 sel=read32(GPSEL);
  sel=sel&mask;
  sel=sel|Function;
  write32(GPSEL,sel);
}

Diese Funktion lädt zunächst die "Basis"-Adresse für GPIO_GPFSEL0 nach GPSEL. Da jeweils 10 Pins mit jeder Adresse GPIO_GPFSEL verwendet werden, müssen wir zunächst feststellen, welches das richtige Register ist. Wir machen es uns recht einfach, in dem wir einfach eine Schleife generieren, die jeweils die Übergabe der Pin-Nummer prüft, bis diese <= 10 ist. Solange dies nicht ist, wird einfach der Pin um 10 reduziert und die "Basis-Adresse" um 4 erhöht, was dann beim ersten Durchlauf dann auf GPIO_GPFSEL1 zeigt usw...

Da die "Funktion" der Pins jeweils drei Bits hat, multiplizieren wir das Ergebnis des Pins mit drei. Zunächst lesen wir den Inhalt raus und löschen die entsprechenden Bits und setzen dann den Wert aus der Übergabe "Funktion" dort hinein. Somit ist sichergestellt, das andere Pins nicht verändert werden. Diesen Wert schreiben wir dann ins GPIO_GPFSEL-Register.

Kommen wir zur Steuerung der LED:

void LED_on (void)
{
  u32 LED_Pin = 42;
  SetGPIOFunction(LED_Pin,GPIO_output);

  u32 GPSET = GPIO_GPSET0; 
  if (LED_Pin>31)
  {
    GPSET = GPSET + 4;
    LED_Pin = LED_Pin - 32;
  }
  write32(GPSET,1<<LED_Pin);
}

void LED_off (void)
{
  u32 LED_Pin = 42;
  SetGPIOFunction(LED_Pin,GPIO_output);

  u32 GPCLR = GPIO_GPCLR0; 
  if (LED_Pin>31)
  {
    GPCLR = GPCLR + 4;
    LED_Pin = LED_Pin - 32;
  }
  write32(GPCLR,1<<LED_Pin);
}

Wir erstellen zwei Funktionen, eine zum Ausschalten der LED (LED_off) und eine, um die LED anzuschalten. Vom Grunde her sind diese zwei Funktion fast identisch. Zunächst wird der entsprechende PIN (RPI4 -> 42) festgelegt. Dies übergeben wir der Funktion SetGPIOFunction und das es sich hierbei um einen "Output" handelt. Das Register, welches wir hier nun benötigen ist zum anschalten der LED "GPIO_GPSET" und zum Ausschalten "GPIO_GPCLR". Jedes Register kann maximal 32 Pins bedienen, sodass wir zunächst festellen müssen, welches Register das richtige ist. Da wir hier den festen Wert 42 haben, könnten wir auch direkt auf GPIO_GPSET1 und GPIO_GPCLR1 schreiben, aber es soll verdeutlichen, wie wir flexibel auf die Anforderungen eingehen können. Nun können wir einfach das "BIT" an die richtige Position schreiben und die LED geht an oder aus.

Hier nochmal der gesamte Code für "led.c":

//
// The LED program for RPI4
// 20.02.2025 www.satyria.de
//
// led.c
//

#include "base.h"
#include "util.h"
#include "types.h"
#include "led.h"

void LED_on (void)
{
  u32 LED_Pin = 42;
  SetGPIOFunction(LED_Pin,GPIO_output);

  u32 GPSET = GPIO_GPSET0; 
  if (LED_Pin>31)
  {
    GPSET = GPSET + 4;
    LED_Pin = LED_Pin - 32;
  }
  write32(GPSET,1<<LED_Pin);
}

void LED_off (void)
{
  u32 LED_Pin = 42;
  SetGPIOFunction(LED_Pin,GPIO_output);

  u32 GPCLR = GPIO_GPCLR0; 
  if (LED_Pin>31)
  {
    GPCLR = GPCLR + 4;
    LED_Pin = LED_Pin - 32;
  }
  write32(GPCLR,1<<LED_Pin);
}

void SetGPIOFunction(u32 Pin, u32 Function)
{
  u32 GPSEL = GPIO_GPFSEL0;
  while (Pin >= 10)
  {
    Pin = Pin -10;
    GPSEL = GPSEL + 4;
  }
  Pin = Pin *3;
  Function = Function << Pin;
  u32 mask = 0b111 << Pin;
  mask =~mask; //Bitweise negieren

  u32 sel=read32(GPSEL);
  sel=sel&mask;
  sel=sel|Function;
  write32(GPSEL,sel);
}

Basiskonfigurationsdatei base.h

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

//
// The LED program for RPI4
// 20.02.2025 www.satyria.de
//
// base.h
//

#ifndef _base_h
#define _base_h

#define RPI_BASE 0xFE000000

// General Purpose I/O (GPIO)                 
#define GPIO_BASE RPI_BASE + 0x200000               
#define GPIO_GPFSEL0                    GPIO_BASE + 0x00 // GPIO Function Select 0        
#define GPIO_GPFSEL1                    GPIO_BASE + 0x04 // GPIO Function Select 1        
#define GPIO_GPFSEL2                    GPIO_BASE + 0x08 // GPIO Function Select 2        
#define GPIO_GPFSEL3                    GPIO_BASE + 0x0c // GPIO Function Select 3        
#define GPIO_GPFSEL4                    GPIO_BASE + 0x10 // GPIO Function Select 4        
#define GPIO_GPFSEL5                    GPIO_BASE + 0x14 // GPIO Function Select 5        
#define GPIO_GPSET0                     GPIO_BASE + 0x1c // GPIO Pin Output Set 0       
#define GPIO_GPSET1                     GPIO_BASE + 0x20 // GPIO Pin Output Set 1       
#define GPIO_GPCLR0                     GPIO_BASE + 0x28 // GPIO Pin Output Clear 0       
#define GPIO_GPCLR1                     GPIO_BASE + 0x2c // GPIO Pin Output Clear 1       
#define GPIO_GPLEV0                     GPIO_BASE + 0x34 // GPIO Pin Level 0        
#define GPIO_GPLEV1                     GPIO_BASE + 0x38 // GPIO Pin Level 1        
#define GPIO_GPEDS0                     GPIO_BASE + 0x40 // GPIO Pin Event Detect Status 0      
#define GPIO_GPEDS1                     GPIO_BASE + 0x44 // GPIO Pin Event Detect Status 1      
#define GPIO_GPREN0                     GPIO_BASE + 0x4c // GPIO Pin Rising Edge Detect Enable 0     
#define GPIO_GPREN1                     GPIO_BASE + 0x50 // GPIO Pin Rising Edge Detect Enable 1     
#define GPIO_GPFEN0                     GPIO_BASE + 0x58 // GPIO Pin Falling Edge Detect Enable 0     
#define GPIO_GPFEN1                     GPIO_BASE + 0x5c // GPIO Pin Falling Edge Detect Enable 1     
#define GPIO_GPHEN0                     GPIO_BASE + 0x64 // GPIO Pin High Detect Enable 0      
#define GPIO_GPHEN1                     GPIO_BASE + 0x68 // GPIO Pin High Detect Enable 1      
#define GPIO_GPLEN0                     GPIO_BASE + 0x70 // GPIO Pin Low Detect Enable 0      
#define GPIO_GPLEN1                     GPIO_BASE + 0x74 // GPIO Pin Low Detect Enable 1      
#define GPIO_GPAREN0                    GPIO_BASE + 0x7c // GPIO Pin Async. Rising Edge Detect 0     
#define GPIO_GPAREN1                    GPIO_BASE + 0x80 // GPIO Pin Async. Rising Edge Detect 1     
#define GPIO_GPAFEN0                    GPIO_BASE + 0x88 // GPIO Pin Async. Falling Edge Detect 0     
#define GPIO_GPAFEN1                    GPIO_BASE + 0x8c // GPIO Pin Async. Falling Edge Detect 1     
#define GPIO_GPIO_PUP_PDN_CNTRL_REG0    GPIO_BASE + 0xe4 // GPIO Pull-up / Pull-down Register 0      
#define GPIO_GPIO_PUP_PDN_CNTRL_REG1    GPIO_BASE + 0xe8 // GPIO Pull-up / Pull-down Register 1      
#define GPIO_GPIO_PUP_PDN_CNTRL_REG2    GPIO_BASE + 0xec // GPIO Pull-up / Pull-down Register 2      
#define GPIO_GPIO_PUP_PDN_CNTRL_REG3    GPIO_BASE + 0xf0 // GPIO Pull-up / Pull-down Register 3      
// Information from BCM2835 ARM Peropherals                 
#define GPIO_GPPUD                      GPIO_BASE + 0x94 // GPIO Pin Pull-up/down Enable        
#define GPIO_GPPUDCLK0                  GPIO_BASE + 0x98 // GPIO Pin Pull-up/down Enable Clock 0      
#define GPIO_GPPUDCLK1                  GPIO_BASE + 0x9c // GPIO Pin Pull-up/down Enable Clock 1      

#endif

In diesem Header wurden alle Funktionen (Adressen), die GPIO betreffen, definiert.

Vorab: Dieser Header wird im Verlauf unseres Kurses kontinuierlich erweitert. Zurzeit benötigen wir jedoch nur die Daten für unsere LED.

Mit RPI_BASE = 0xFE000000 legen wir die Basisadresse der Peripheriegeräte fest. Diese dient als Grundlage für alle anderen Geräte, die wir verwenden.

Diese Datei wird später in Abschnitte für jedes einzelne Gerät unterteilt. Derzeit verwenden wir jedoch nur das GPIO.

Mit GPIO_BASE RPI_BASE + 0x200000 wird die Basisadresse des GPIO festgelegt.

read32 und write32

Wir haben hier zwei Funktionen verwendet, die direkt mit dem Speicher des Raspberry Pi 4 arbeiten können. Am einfachsten ist es, wenn wir diese zwei Funktionen in Assembler definieren, da wir hier viel einfacher auf die Hardware zugreifen können.

//
// The LED program for RPI4
// 20.02.2025 www.satyria.de
//
// util.S
//

.globl write32
write32:
  stp x29, x30, [sp, -16]!
  mov x29, sp
  str w1,[x0]
  ldp x29, x30, [sp], 16
  ret

.globl read32
read32:
  stp x29, x30, [sp, -16]!
  mov x29, sp
  ldr w0,[x0]
  ldp x29, x30, [sp], 16
  ret

Wir speichern es als util.S ab.

Bei "write32" ist die Zeile str w1,[x0] (store) relevant. Dies schreibt den zweiten Wert an die Adresse des ersten Wertes, welches der Funktion übergeben wird. Alle anderen Zeilen sind für das korrekte Funktionieren mit C relevant, hat aber als solches für uns zunächst keine Bedeutung. Bei "read32" ist die Zeile ldr w0,[x0] (load) relevant. Hier wird der übergeben Wert als Adresse interpretiert und der Wert, der dort abgelegt ist, der Funktion zurückgegeben.

Damit "C" weiß, welche Werte hier erwartet werden, müssen wir noch in einer Header-Datei festlegen, was wir erwarten:

//
// The LED program for RPI4
// 20.02.2025 www.satyria.de
//
// util.h
//

#ifndef _ms_util_h
#define _ms_util_h

#include "types.h"

void write32(u32 a, u32 b);
u32 read32(u32 a);

#endif

Wartefunktion wait

Zuletzt erstellen wir die Datei time.c für die Wartefunktion:

//
// time.c
//

#include "types.h"

void wait(u32 zyklen) 
{
    volatile u32 i;
    for (i = 0; i < zyklen; i++) 
    {
        // Leere Schleife zur Verzögerung
    }
}

Erklärung:

• volatile u32 i: Erzeugt die Variable "i". Durch volatile wird bei einer Optimierung des Codes die Schleife nicht optimiert!
• for (i = 0; i < zyklen; i++): Dies erzeugt eine Schleife und zählt "i" hoch, solange i kleiner als zyklen ist.
• {...]: Hier wird eine leere Schleife generiert.

write32 und read32

Um ein Systemregister zu lesen oder auch dort hineinzuschreiben, benötigen wir noch zwei Funktionen, die wir write32 und read32 nennen. Da es um eine direkte Adressierung im Speicher geht, verwenden wir einfach einen Assemblercode:

//util.s

.globl write32
write32:
	stp x29, x30, [sp, -16]!
	mov x29, sp
	str w1,[x0]
	ldp x29, x30, [sp], 16
	ret

   
.globl read32
read32:
	stp x29, x30, [sp, -16]!
	mov x29, sp
    ldr w0,[x0]
	ldp x29, x30, [sp], 16
	ret

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:

• 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 dass der Code dupliziert werden muss.

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

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

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

Die led.h

// led.h

#ifndef _ms_led_h
#define _ms_led_h

void LED_off(void);
void LED_on(void);

#endif

Diese Header-Datei definiert die Funktionsaufrufe LED_off und LED_on. Beide Funktionsaufrufe erwarten keinen Parameter und geben keine Parameter zurück. Dies ist durch das Schlüsselwort void erkennbar.

Die time.h

//time.h

#ifndef _ms_time_h
#define _ms_time_h

#include "types.h"

void wait(u32 zyklen);

#endif

Hier wird der Funktionsaufruf wait definiert. Diese Funktion gibt keinen Wert zurück, aber erwartet von uns einen u32-Wert. u32 wird in dem nächsten Header "types.h" definiert. Deswegen wurde diese diesem Header inkludiert, damit der Compiler weiß, was u32 bedeutet.

Die types.h

// types.h

#ifndef _ms_types_h
#define _ms_types_h

typedef unsigned char		u8;
typedef unsigned short		u16;
typedef unsigned int		u32;

typedef signed char		s8;
typedef signed short		s16;
typedef signed int		s32;

typedef unsigned long		u64;
typedef signed long		s64;

typedef long			intptr;
typedef unsigned long		uintptr;

typedef unsigned long		size_t;
typedef long			ssize_t;

typedef char		boolean;

#define	ALIGN(n)	__attribute__((aligned (n)))

#define FALSE		0
#define TRUE		1

#endif

Der Header types.h definiert verschiedene Datentypen und einige Makros, die in einem C-Programm verwendet werden können. Hier ist eine allgemeine Beschreibung dessen, was in diesem Header passiert:

Typdefinitionen:

• Es werden neue Datentypen mit typedef erstellt, um die Standardtypen in C klarer und konsistenter zu benennen.
  • Unsigned Types:
    • u8: ein Alias für unsigned char (8-Bit).
    • u16: ein Alias für unsigned short (16-Bit).
    • u32: ein Alias für unsigned int (32-Bit).
    • u64: ein Alias für unsigned long (64-Bit).
  • Signed Types:
    • s8: ein Alias für signed char (8-Bit).
    • s16: ein Alias für signed short (16-Bit).
    • s32: ein Alias für signed int (32-Bit).
    • s64: ein Alias für signed long (64-Bit).
  • Pointer Types:
    • 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.
  • Size Types:
    • 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.

Boolean Type:

• Es wird ein neuer Typ boolean als Alias für char definiert.

typedef char boolean;

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.

#define ALIGN(n) __attribute__((aligned (n)))

Boolean Values:

• Zwei Makros FALSE und TRUE werden definiert, um die Werte 0 und 1 darzustellen.

#define FALSE 0
#define TRUE 1

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

Wechsle in das Verzeichnis LED und kompiliere das Programm mit dem Befehl make. Wenn alles erfolgreich war, erhältst du eine Datei kernel_2712.img, die auf eine SD-Karte kopiert und im Raspberry Pi verwendet wird. Schalte den Raspberry Pi ein, und die LED sollte blinken.

Du kannst den Source-Code als ZIP-Datei mit folgenden Link downloaden: https://www.satyria.de/arm/sources/RPI4/C/2.zip

---

< Zurück (Unser erstes Programm in C (PI4))

< Hauptseite >

Weiter (Fehlerbehandlung in C (PI4)) >