MC2

Zeitkritische Verarbeitung in ISRs; zeitunkritische und lang andauernde im Hauptprogramm-Fluss

Bei Echtzeitsystemen mit mittlerer bis hoher Komplexität

Vorteile:

- bei nur einem Ereignis recht schnell (kein Interrupt-Overhead)
- kaum Race-Probleme (Programmfluss wird nie unterbrochen)
- einfache Erweiterung mit wenig gegenseitiger Beeinflussung (nur zeitlich!)

Nachteile:

- Keine Priorisierung
- Reaktionszeit von Anzahl und Komplexität der Ereignisse abhängig
- Kurzzeitige ereignisse (puls am Eingang) können verloren gehen
- Ereignisse dürfen nicht Blockieren
- Kein Sleep-Mode möglich, da immer gepollt werden muss
- Zwingend mit Statemachine-Ansatz realisiert

Vorteile:

- Resourcensparend (Kein andauerndes pollen, Sleep-Mode möglich)
- Priorisierung möglich

Nachteile:

- evt. nicht alle Inputs interruptfähig
- Latenzzeit etwas höher als bei Polling eines einzelnen Ereignisses
- Prelllen am Input löst mehrere Interrupts aus
- keine Differenzierungsmöglichkeit zwischen dringlicheren und weniger dringlicheren Phasen einer Ereignissbehandlung
- Race-Conditions insbesondere bei priorisiertem "nested interrupt"
- ISR darf nicht blockieren => Nur mit Statemachine-Ansatz lösbar
=> Untauglich wenn viele Ereignisse mit unterschiedlichen Echtzeit-Anforderungen und/oder Verarbeitunsgszeit nahezu gleichzeitig eintreffen.

Die meisten kostenoptimierten "low end" Mikrocontrollersysteme arbeiten so!

Vorteile:

- Schnelle Reaktion auf Ereignisse (sofern alle ISRs kurz sind)
- Keine grossen Anforderungen an Interrupt-Struktur (prellen im Hauptprogramm oder Timer-ISR behandeln

Nachteile:

- Verarbeitung nicht ereignisspezifisch priorisierbar
- Moderate Gefahr von Race-Conditions (bei Entwurfsfehlern)
- Keine komplexe Projekte, da anspruchsvoll und unflexibel

Vorteile:

- Geeignet auch für sehr komplexe Projekte
- „Nebenläufigkeiten“ einfach realisierbar (quasigleichzeitige Abarbeitung)
- Auf Ereignisse bei Bedarf sehr schnell reagieren (ISR + hochpriorisierte Tasks)
- Wenig Anforderungen an Interrupt-Struktur (keine nested ISR benötigt )

Nachteile:

- Der Wechsel zwischen Tasks benötigt Zeit
- Grösserer Speicherressourcenbedarf
- Debugging ev. problematisch (nicht rein sequentiell, stack overflow)
- Shared Ressources sind heikel

 Siehe Bild:

eCos liefert auch einen Bootloader, Treiber, Filesystems, Netzwer/USB-Stacks und Bibliotheken mit.

Lizenzkoste/-bedingungen
Support/Community

Zertifizierung
- SIL 1..4 IEC 61508/IEC61511 (Auto, Medizin)

- CPU-Architektur unsterstützung
- Scheduler: Preemtive und/oder Cooperative Multitasking
- Realtime-Eigenschaften (Taskswitch-Zeit, Latenzzeit)
- Speicherbedarf, Fragmentierung und RT-Eigenschaften beim Allozieren
- Umfang und Kompatibilität  von Treibern und Bibliotheken
 

RTOS:
- Hard-Realtimefähig
- Speicherfragmentierung
- nur einfache Memory Protection
- Ethernet/USB/SPI ... nur eingeschränkt Nutzbar teils ohne RT
- Geeignet für 16..32bit ~50MIPS ohne MMU

GPOS:
- höchstens Soft-RT
- Virtual Memory Mapping (kaum Fragmentierung, komfortabel)
- Vollumfänglicher Speicherschutz
- Ethernet/UART ... Vollumfänglich implementiert
- Geeignet für 32/64bit mit MMU und Cache

eCos
FreeRTOS
SafeRTOS
Linux RT-Preempt Patch
Real VMX
VxWorks
Windows CE
Zephyt OS

- Linux Kernel Patch für RT optimierung
- Co-Kernel approach (OS als Task eines RTOS)
- Multicore-System (Zwei CPU-Cores: 1 Core RTOS + 1 Core GPOS )

Source/Poratable/Compiler/Platform/{Port.c, ...}

Modified GPL License

make ist ein Build-Management-Tool, das Kommandos in Abhängigkeit von Bedingungen ausführt.

Das Makefile enthält Variablen und Rules.

Target: Dependencies
       Commands

Targets und Dependencies können Dateien sein oder ein so gennantes "Phony Target" d.h. von einer anderen Rule abhängig sein. Command mit Tabulator einrücken!

Alle Rules sind im Makefile explizit zu definieren, die Built-in Rules sind nicht bei allen systemen geeignet.

Zuweisung
VAR = ...
Zuweisung (nicht erweiterbare Expansion)
VAR := ...
Ergänzen einer definierten Variable
VAR += ...
Referenzieren (auslesen):
$(VAR)

Hinweis: Exportierte Shell-Variablen werden übernommen

Wildcard Rules ermöglichen allgemeingültige Regeln.
z. Bsp:

%.o: %.c
     gcc -Wall -g -o $@ c $<

Alle .c-Dateien (Dependency: %.c) werden zu .o-Object-Dateien (Target: %.o) kompiliert.
Dazu wird der gcc mit dem Outfile '-o $@' wobei $@ der vollstädige Target-Wert enthällt und dem Infile '$<' welches den Dependency-Wert enthält

$(OBJ) : %.o : %.c

%.o : %.c wird nur für Objektfiles verwendet welche in der Variablen $(OBJ) aufgeführt sind.

.PHONY: clean size ...

SRC = $(OBJ:%.o=%.c)  #Variable SRC wird aufgrund Var. OBJ entsprechend generiert
SOURCES := $(wildcard *.c)  # Liste aller Files *.c im current directory
OBJS := $(patsubst %.c, %.o, $(SOURCES)) # Ergebnis gleich wie Kurzform oben
$(addprefix l,$(LIBS)) # jedem enth. Wort wird 'l' vorangestellt
FILES := $(foreach dir, $(DIRS), $(wildcard $(dir)/*))  # Liste aller Files *.c aus mehr. Dirs

Makefiles verwenden existierende Dependency-Dateien falls sie nicht neuer als das Target sind.
Da Headerfiles nicht kompiliert werden müssen werden Änderungen an ihnen nur festgestellt wenn beim kompilieren Demendency-Files erzeugt werden (gcc -M) und diese mit -include $(wildcard dep/*) im Makefile aufgeführt werden.

Das Makefile im aktuellen Verzeichnis wird aufgerufen und die erste Regel ausgeführt.

Ein bestimmtes Target kann mit 'make target' ausgeführt werden.

Weitere optionale Argumente:
-f <file> Explizite Angabe eines Makefiles  (statt 'Makefile' im current directory)
-C <dir> Vor Ausführung, Wechsel ins Verzeichnis <dir>
-j <n> make interne Parallelverarbeitung  (bei vielen Targets und <n> CPUs)
-p Anzeigen der  „builtin rules“

GNU Debugger (aus GCC Toolchain) mit einem rudimentären CLI.

arm-none-eabi- ist das Toolchain-Prefix und gibt an für welches Zielsystem die toolchain geeignet ist. CPU-Platform: arm; OS: none (Kein OS); eabi = "embedded application binary interface"
 

Beim gdb ist ein Debugger-Backend (gdbserver) vorhanden. Dieser wird auf dem Zielsystem (Cotroller) ausgeführt. Über die Serielle-Schnittstell oder via TCP/IP kann der gdb auf dem Hostsystem (PC/Notebook) das Backend steuern.

Damit der gdbserver auf dem Zielsystem läuft, muss dieses ein POSIX-konformes OS aufweisen.

Anstelle des gdbservers läuft auf dem HOST! das OpenOCD im gdbserver-Mode.
Der gdb verbindet sich via TCP/IP (Port 3333) mit dem OpenOCD, welches die Befehle via USB dem JTAG Programmer übergibt (z.Bsp. FT2232) welcher am uC angeschlossen ist.

OpenOCD stoppen (make killgdbserver)
Programm neu builden
Programm flashen
OpenOCD neustarten

Auf dem Controller läuft kein GPOS

Bei JTAG braucht es keinen Debug-Code auf dem Controller, da JTAG direkt Befehle injizieren kann.

Jeder Task läuft während einer bestimmten Zeit (time slice).
Auf jedem CPU-Core wird ein Task als Running aktiv bearbeitet.
Nach ablauf der Zeit wird der nächste Task aus der Ready-Liste entnommen.
Wird ein Task Suspended oder ruft einen blocking Befehl auf, wird er erst in die Ready-Liste eingefügt wenn die Resume bedingung erfüllt ist.
 

Task synchronisation ohne polling.
Es ist eine Betriebssystem-Funktionalität! (Scheduler-Funktkionalität)