Kapitel 1 - Einleitung (Introduction)

← Startseite · Kursüberblick · 1 Einleitung · → ARM-Architektur Verwandt: Kap. 2 Power Management · Kap. 3 PIO · Glossar Quellen: [Q: EI] ES-01-EI Einleitung.pdf · [Q: ZF §1] Cours_Resume

Inhalt

  1. Mikrocontroller-Markt & ARM
  2. Mikroprozessor vs. Mikrocontroller
  3. Anwendungsfelder
  4. Bausteine eines Mikrocontrollers
  5. Anforderungen (nichtfunktionale Eigenschaften)
  6. Programmierung der Peripherie - Memory-Mapped I/O
  7. Sichtbarkeit von HW-Eigenschaften in C
  8. Compiler-Optimierung & volatile
  9. Prüfungsrelevanz

1. Mikrocontroller-Markt & ARM

  • ARM (Advanced RISC Machines) definiert CPU-Kerne in Cortex-Architekturen, die den MC-Markt dominieren. ARM verkauft IP-Cores (Lizenzen), keine eigenen Chips.
  • Drei Cortex-Familien:
    • Cortex-A = Application (betriebssystembasierte Anwendungen, z. B. Smartphones)
    • Cortex-R = Realtime (Echtzeitanwendungen)
    • Cortex-M = Microcontroller (Nachfolger des ARM7)
  • Verbreitung: > 90 % aller mobilen Geräte enthalten einen ARM-Prozessor; bis 2022 ≈ 230 Mrd. ausgelieferte ARM-Prozessoren.
  • Im Kurs behandelt: ARM7TDMI, Cortex-M0+, Cortex-M3. (Details → ARM-Architektur)

2. Mikroprozessor vs. Mikrocontroller (MP vs. MC)

Mikroprozessor (MP)Mikrocontroller (MC)
Definition„Mikrorechner auf einem Chip" - nur Prozessorbausteine (Steuerwerk, ALU, Register) im ICMP plus integrierte Peripherie (Speicher, Timer, I/O, …) auf einem Chip
Zweckuniverselle Rechenaufgabenzugeschnitten auf spezielle Steuerungs-/Kommunikationsaufgaben
Programmierungvielfältig, OS-basiertoft einmal programmiert, läuft die ganze Lebensdauer
Oft fehlend bei MC-MMU (Memory Management Unit), Virtualisierung (Intel VT/AMD-V), Vektor-/Hyper-Threading-Spezialbefehle
  • System-on-Chip (SoC): Bei komplexen Chips, die (fast) alle Bestandteile eines Systems integrieren.
  • Wechselwirkung mit Umgebung: Ein eingebettetes System braucht Sensoren (messen) und Aktoren (stellen), um mit seiner Umgebung zu interagieren. (Grunddefinition, kommt gern in Multiple-Choice.)

3. Anwendungsfelder

  • Haushalt: Kaffeemaschine, Waschmaschine, Telefon, Staubsauger, Fernseher
  • KFZ: Motormanagement, ABS, ESP/Stabilitätsprogramm, Traktionskontrolle, Fahrassistenten
  • Automatisierung: Steuern/Regeln/Überwachen von Prozessen, Fertigungsanlagen
  • Mobile Devices: Multitouch, GPS, Funkprotokolle, Lage/Beschleunigung, Fingerabdruck
  • IT-Infrastruktur: Festplatten-/RAID-Controller, Netzwerk-Router, Verschlüsselung/Kompression

4. Bausteine eines Mikrocontrollers

Ein MC besteht aus Kern (Core) + On-Chip-Peripherie:

  • Prozessorkern (Core): Steuerwerk, ALU, Register, Bussystem
  • Speicher: RAM + Festwertspeicher (ROM, PROM, EPROM, EEPROM, FLASH) - Größe/Typ unterscheidet oft Untertypen desselben MC
  • Ein-/Ausgabesteuerung (I/O, seriell/parallel, synchron/asynchron)
  • AD-/DA-Wandler (analoge Sensoren/Aktoren; wichtig: Auflösung & Wandlungszeit; AD häufiger als DA)
  • Zähler/Zeitgeber (Timer/Counter) - wichtig für Echtzeit (→ Kap. 5)
  • Unterbrechungssteuerung (Interrupt Controller) (→ Kap. 6)
  • Watchdog - „Wachhund": Programm muss regelmäßig „Lebenszeichen" liefern, sonst Reset (Analogie: Lokführer-Totmanntaste)
  • DMA (Direct Memory Access): direkter Datentransfer Peripherie↔Speicher ohne Prozessorkern → höhere Datenrate, entlastet den Kern; nur in leistungsstärkeren MC
  • Takterzeugung (Oszillator/Quarz), Erweiterungsbus

Echtzeit (Real-Time) - Definition

  • Harte Echtzeit (hard real-time): garantierte Einhaltung der Reaktionszeit.
  • Weiche Echtzeit (soft real-time): nur statistische Garantie (meist eingehalten, aber nicht immer).

5. Anforderungen an Mikrocontroller

Nichtfunktionale Eigenschaften:

  • Kosten: maximale Integration bei minimalen Systemkosten
  • Performance: hohe Verarbeitungsleistung
  • Energieverbrauch: minimal (v. a. batteriebetrieben) → Kap. 2 Power Management
  • Zuverlässigkeit: Langzeitbetrieb in kritischer Umgebung (Temperatur, Feuchte, EMV, Spannungsschwankungen, Strahlung)
  • Wartbarkeit: oft ohne Update-Möglichkeit

Design-Aspekte: Standard-MC (AT91M63200, SAM3X8E - universell) vs. kundenorientierte MC (RP2040 - auf Marktsegment zugeschnitten, hohe Stückzahl).

6. Programmierung der Peripherie - Memory-Mapped I/O

Wie spricht der Kern seine Peripherie an? Zwei Prinzipien:

Memory-Mapped I/O (ARM)Spezielle E/A-Befehle (Intel x86)
Peripherie-Register werden in den Adressraum des Hauptspeichers eingeblendetPeripherie über E/A-Ports, angesprochen mit Spezialbefehlen (IN/OUT)
Steuerung durch normales Lesen/Schreiben an AdressenMOV AX,1 / OUT 20H,AX
Übersicht = Memory Map des MC-

Verwechslungsgefahr (Klausur): Memory-Mapped I/O ≠ DMA. Memory-Mapped I/O = die CPU greift über Adressen auf Register zu. DMA = ein Controller überträgt Daten ohne die CPU. Die Klausur-Falschaussage „DMA nennt man das Prinzip, dass der Prozessor auf Peripherie wie auf Speicher zugreift" beschreibt Memory-Mapped I/O, nicht DMA! (KL20 Aufg. 1.4)

Auszug AT91 Memory Map [Q: EI S. 24]

BausteinBasisadresse
AIC (Interrupt Controller)0xFFFFF000
Watchdog0xFFFF8000
PMC (Power Management)0xFFFF4000
PIO A / B0xFFFEC000 / 0xFFFF0000
TC0 / TC1 (Timer)0xFFFD0000 / 0xFFFD4000
USART0–20xFFFC0000 …

Auszug SAM3X Memory Map (Praktikum) [Q: EI S. 26]

BausteinBasisadresse
PMC0x400E0600
PIOA / PIOB / PIOC / PIOD0x400E0E00 / …1000 / …1200 / …1400
TC0 (Block 0) / TC2 (Block 2)0x40080000 / 0x40088000
USART10x4009C000

7. Sichtbarkeit von HW-Eigenschaften in C

Hardwarenahe Programmierung nutzt gezielt C-Sprachmittel:

  • volatile (dt. flüchtig): Wert kann sich außerhalb des Programmkontexts ändern (durch Hardware, ISR, anderen Thread) → verhindert „Wegoptimieren". Siehe §8.
  • static: globale Variable, aber Sichtbarkeit auf Modulgrenze reduziert.
  • Bitweise Operatoren: & (UND), | (ODER), ~ (Invertieren), ^ (XOR) - bitweise; nicht mit den logischen &&, ||, ! verwechseln!
  • Schiebeoperationen: 1 << 14 setzt eine 1 auf Bit 14; 0x0F000000 >> 24 → 0x0000000F.
  • Alignment: Elemente in struct liegen auf Zugriffsgrenzen.
  • Parameterübergabe: Call by value (Wert) vs. Call by reference (Zeiger/Adresse); der APCS (ARM Procedure Call Standard) regelt die Übergabe per Register/Stack.

Hardwarebausteine als struct deklarieren

Ein „gemappter" Baustein wird als zusammengesetzter Datentyp (struct) beschrieben, seine Basisadresse als Konstante:

// Registertyp: 32 Bit breit, volatile
typedef volatile unsigned int register32;

// Struktur = Register-Map des Bausteins
typedef struct {
    register32 REGISTER0;   // Offset 0
    register32 REGISTER1;   // Offset 4
} structBaustein;

// Basisadresse als Konstante (Cast auf struct-Zeiger)
#define baustein_basisadresse ((structBaustein*) 0x00FF0000)

structBaustein *bausteinA = baustein_basisadresse;
bausteinA->REGISTER0 = 0;

// Einzelnes Bit setzen, ohne andere zu verändern:
#define BAUSTEIN_LED1 (1 << 12)
bausteinA->REGISTER0 |= BAUSTEIN_LED1;   // Kurzform
  • Registerfelder (Vektor): mehrere gleichartige Register als Array: register32 VECTOR[4]; - Zugriff baustein1->VECTOR[VEC_TIMER1] = 0;
  • Board Support Package (BSP): liefert Adressen, Register-Structs, Bit-Konstanten, Verdrahtungs-Konstanten, Startupcode (läuft vor main()) und Hilfsfunktionen für ein Board.

Cast-Operator ist notwendig, nicht „zu vermeiden": Die direkte Zuweisung einer Adresse an einen Zeiger braucht einen Cast. Klausur-Falschaussage: „Casting von Zeigern führt zu Fehlern und sollte unbedingt vermieden werden" → falsch, es ist gängige und nötige Praxis. (KL20 Aufg. 1.3)

8. Compiler-Optimierung & volatile

Optimierung erfolgt rein auf Quelltextbasis - der Compiler „sieht" nur den Programmablauf des Kerns, nicht externe HW-Einflüsse. Deshalb bei hardwarenaher Programmierung vorsichtig optimieren.

GCC-Optimierungsstufen (-O)

StufeBedeutung
-O0keine Optimierung; schnell kompiliert, perfekt zum Debuggen (stabiles Zeilen-Mapping); größer/langsamer
-OgDebugging mit sinnvollen Optimierungen
-O1leichte Optimierung (Dead-Code-Elimination, Peephole), meist risikolos
-O2Standard für Releases; gute Balance Speed/Größe/Stabilität (Inlining, CSE, Code-Motion)
-O3aggressiv (mehr Inlining, Loop-Unrolling, Vektorisierung); längere Kompilierzeit, evtl. größere Binaries
-Oskleine Codegröße (wichtig bei Flash-Budget)
-Ofastwie -O3 + -ffast-math (lockert IEEE-Regeln)
  • Weitere Hebel: -flto (Link-Time-Optimization), -mcpu=... -mfpu=... (Ziel-CPU/FPU angeben).

Warum volatile nötig ist

static volatile int status = 0;
void poll_status(void) { while (status == 0) ; }   // wartet auf HW

Ohne volatile dürfte der Compiler status einmal lesen und die Schleife durch eine Endlosschleife ersetzen („wegoptimieren"). Mit volatile wird bei jedem Zugriff der tatsächliche HW-Wert gelesen und bei Zuweisung sofort geschrieben. Typische Anwendung: Speicherstellen für Interrupt-Handler und Peripherie-Register.

Prüfungsrelevanz

  • Multiple-Choice-Klassiker: MC vs. MP, SoC, „braucht Sensoren+Aktoren", Speichertypen, DMA-Definition (Abgrenzung zu Memory-Mapped I/O!), volatile, struct-Mapping, Cast nötig.
  • volatile erklären (was, warum, Beispiel) ist ein wiederkehrender Kurzfragen-Kandidat.
  • Memory-Mapped I/O vs. Port-I/O verstehen.
  • Bitoperationen (|=, 1<<n) tauchen indirekt in den PIO-/Timer-Codeaufgaben auf (→ Kap. 3, Kap. 5).

Typische Fehler: DMA mit Memory-Mapped I/O verwechseln · logische vs. bitweise Operatoren · glauben, -O3 sei immer besser (bei HW-Code gefährlich ohne volatile).

← Startseite · → ARM-Architektur