Commit missing RT basics changes

3 files changed, 369 insertions, 22 deletions

diff --git a/realtime/rt-basics/handout_rt-basics_de.tex b/realtime/rt-basics/handout_rt-basics_de.tex
index 4c391b2..8576b7d 100644
--- a/realtime/rt-basics/handout_rt-basics_de.tex
+++ b/realtime/rt-basics/handout_rt-basics_de.tex
@@ -1,17 +1,173 @@
-\documentclass{article}
+\documentclass{lxarticle}
 \usepackage{german}
 \usepackage[utf8]{inputenc}
+\usepackage{lxheaders}
+\usepackage{lxextras}
 
 \begin{document}
 
-\section*{Titel}
+\section*{Realtime Linux}
 
-\subsection*{Abschnitt1}
+\subsection*{Grundlagen}
 
-Text
+\subsubsection*{Was ist Echteit?}
+Vor der Betrachtung verschiedener Ansätze, Linux echtzeitfähig zu machen, ist es
+notwendig einige grundlegende Begrifflichkeiten zur erläutern:
+\begin{itemize}
+\item Echtzeit:
+Zur Definition eines Echtzeitsystems kann man folgende Aussagen Treffen: Auf
+einem Echtzeitsystem hängt die Korrektheit einer Berechnung nicht nur von deren
+logischen Korrektheit, sondern auch von der Ausführung zum korrekten Zeitpunkt
+ab. Das Nichteinhalten eines bestimmten Zeitrahmens resultiert in einem Fehler.
+\item Latenzzeit: Unter Latenzzeit versteht man den Zeitraum zwischen dem
+Auftreten eines Events und der Reaktion auf dieses Event.
+\item Jitter: Mit Jitter bezeichnet man die Varianz der Latenzzeit.
+\end{itemize}
 
-\subsection*{Abschnitt2}
+\subsubsection*{Anwendungsbereiche}
+Die wohl gängigsten Anwendungsbereiche für Echtzeitsysteme sind die
+Steuerungs- und Automatisierungstechnik, Multimediasysteme und die Luft- und
+Raumfahrttechnik. Ein weiteres interessantes Einsatzgebiet stellt die 
+Finanzdienstleistung dar. Hier geht es insbesondere um die zeitgenaue,
+zuverlässige Abwicklung von Finanztransaktionen über hochverteilte Systeme.
 
-Text
+\subsubsection*{Anforderungen an ein Echtzeitsystem}
+Ein Echtzeitsystem muß in der Lage sein, in einem garantierten Zeitrahmen auf
+ein Ereignis zu reagieren. Es muß also möglich sein, in möglichst kurzer Zeit
+von einer niederprioren Task auf eine hochpriore Task umzuschalten, falls diese
+Rechenzeit benötigt. Das System muß also möglichst ''feingranular''
+unterbrechbar sein.
+Doch allein die Unterbrechbarkeit kann kein deterministisches Zeitverhalten
+garantieren. So kann eine niederpriore Task Resourcen blockieren, die von einer
+hochprioren Task benötigt werden. Wird die niederpriore Task nun unterbrochen,
+kommt es zur ''Prioritätsinversion / priority inversion'', da die hochpriore Task
+auf die Freigabe der Resource wartet, diese aber erst wieder dann freigegeben
+wird, wenn die niederpriore Task wieder Rechenzeit bekommt.
+Gelöst werden kann dieses Problem durch ''prioriy inheritance'' und ''priority ceiling''.
+\begin{itemize}
+\item Prioritätsvererbung / priority inheritance: Hier wird die Priorität der
+niederprioren Task angehoben, um zu erreichen, daß die blockierte Resource
+freigegeben kann.
+\item Prioritätsgrenzen / priority ceiling: Hier wird für jede Resource eine
+Prioritätsgrenze festgelegt. Jede Task, die die Resource belegt, wird auf die
+Prioritätsgrenze der Resource angehoben.
+\end{itemize}
+
+\subsection*{Realtime Linux Varianten}
+\subsubsection*{Historisches zu Echtzeitlinux}
+Im Gegensatz zu traditionellen Echtzeitsystem wurde Linux ursprünglich nicht als
+solches designt. Als General Purpose Operating System wurde Linux auf Fairness
+und Durchsatz optimiert. Linux echtzeitfähig zu machen, bedeutet also, ein
+Standardbetriebssystem um Echtzeitfunktionen bzw. entsprechende Sonderfälle zu
+erweitern. Mit dieser Tatsache lassen sich die zwei technischen Ansätze für
+Realtime Linux erklären.
+\begin{itemize}
+\item Dual Kernel Ansatz: Hier koexistieren ein Echtzeitkernel, der für alle
+zeitkritischen Dinge zuständig ist, und ein Standard Linux Kernel. Dieser Ansatz
+setzt voraus, daß alle externen Events zuerst vom Echtzeitkernel bearbeitet
+werden, bevor Sie an den Linux Kernel weitergereicht werden können. Die
+bekanntesten Vertreter dieser Technik sind RTAI und Xenomai.
+\item In-Kernel Ansatz: Diese Methode macht Linux an sich zu einem
+Echtzeitsystem. Dieser Ansatz wird mit dem Realtime Preemption Patch verfolgt
+und ist die Variante, die von den Linux Entwicklern zur Integration in den
+Hauptzweig von Linux abgenickt wurde.
+\end{itemize}
+
+\subsubsection*{RTAI}
+Das Realtime Application Interface (RTAI) ist eine Entwicklung der Technischen
+Universität Mailand und entstand unter der Schirmherrschaft von Professor Paolo
+Mantegazza. Oberstes Designziel von RTAI ist und war es, die kleinstmöglichen
+Latenzzeiten auf einer gegebenen Hardwareplattform zu erzielen. Dieses
+Designziel bedingt diverse Einschränkungen für RTAI Applikationen. Weiterhin
+wird nur eine recht kleine Anzahl an Zielplattormen unterstützt (derzeit x86,
+x86\_64 und diverse ARM Plattformen).
+\begin{figure}[h]
+\centering
+\includegraphics[height=0.5\textwidth]{images/rtai.png}
+\caption{Technischer Aufbau von RTAI}
+\label{img:rtai}
+\end{figure}
+RTAI ist ein typischer Vertreter des Dual Kernel Ansatzes. Abbildung
+\ref{img:rtai} zeigt die Funktionsweise von RTAI.
+
+\subsubsection*{Xenomai}
+Das Xenomai Projekt wurde im Jahre 2001 gegründet. Im Gegensatz zu RTAI erlaubt
+Xenomai auch Echtzeit im Userpace (RTAI erlaubt dies nur sehr eingeschränkt).
+Die Besonderheit von Xenomai sind die sogenannten Skins, die es vereinfachen sollen,
+Applikationen von proprietären Echtzeitsystemen nach Xenomai zu portieren.
+Xenomai Skins bilden die API dieser Systeme ab. Xenomai unterstützt derzeit
+folgende Architekturen: PowerPC32, PowerPC64, x86, x86\_64, Blackfin, ARM und
+ia64). Die zentralen Begriffe im Designkonzept von Xenomai stellen Xenomai
+Nucleus, die Interrupt Pipeline (IPIPE), Hardware Abstraction Layer (HAL) und
+System Abstraction Layer (SAL) dar.
+IPIPE kann bildlich als virtueller Interruptkontroller betrachtet werden.
+Sie organisiert das System in verschiedenen Domains. Interrupts werden von
+IPIPE entgegengenommen und an die einzelnen Domains verteilt.
+Nucleus beeinhaltet die Xenomai Core Funktionalität. Dieser ist zuständig dafür,
+alle notwendigen Resourcen, die Skins benötigen, um die Funktionalität von
+RTOSsen nachzubilden. Der Hardware Abstraction Layer beinhaltet den Plattform
+und CPU abhängigen Code. Alle darüberliegenden Layer (darunter auch Nucleus)
+bauen darauf auf. HAL ist kombiniert mit dem System Abstraction Layer. Dieser
+soll die darüberliegenden Layer, wie z.B. Nucleus, noch portierbarer machen.
+Abbildung \ref{img:xenomai} zeigt das technische Zusammenspiel der Xenomai
+Komponenten. Abbildung \ref{img:ipipe} zeigt die Funktionsweise von IPIPE.
+\begin{figure}[h]
+\centering
+\includegraphics[height=0.5\textwidth]{images/xenomai.png}
+\caption{Technischer Aufbau von Xenomai}
+\label{img:xenomai}
+\end{figure}
+\begin{figure}[h]
+\centering
+\includegraphics[height=0.5\textwidth]{images/ipipe.png}
+\caption{Technische Funktionsweise von IPIPE}
+\label{img:ipipe}
+\end{figure}
+
+\subsubsection*{Preempt RT}
+Der Realtime Preemption Patch entstand ursprünglich aus Arbeiten von Ingo Molnar
+und Thomas Gleixner. Beide sind bis zum heutigen Zeitpunkt die treibenden Kräfte
+bei der Entwicklung von Preempt RT.
+Im Gegensatz zu RTAI und Xenomai macht Preempt RT den Linux Kernel an sich
+echtzeitfähig. Dies wird im Besonderen durch folgende Mechanismen erreicht:
+\begin{itemize}
+\item Sleeping Spinlocks: Spinlocks werden durch RT Mutexe ersetzt. Raw
+Spinlocks ersetzen die Eigenschaft der ursprünglichen Spinlocks.
+\item Threaded Interrupt Handlers: Interrupt Handler laufen per Default nicht im
+harten Interruptkontext, sondern als Kernelthread.
+\end{itemize}
+Viele Mechanismen, die ursprünglich in Preempt RT entwickelt wurden, haben
+bereits Ihren Weg in den Mainline Linuxzweig gefunden: High Resolution Timer
+(Hochauflösende Timer unabhängig vom Scheduler Tick), Priority Inheritance,
+generisches Interrupthandling für alle Architekturen und mit 2.6.30 nun auch die
+Threaded Interrupt Handler.
+Weiterhin hat sich die Linux Entwicklergemeinde bereits 2006 darauf geeinigt,
+daß Preempt RT in den Linux Kernel integriert wird. Weiterhin bietet der
+Realtime Preempton Patch den großen Vorteil, daß Echtzeitapplikationen als POSIX
+Realtime Applikationen geschrieben werden. Es wird keine spezielle API
+verwendet. Preempt RT Unterstützt eine Vielzahl von Architekturen (PowerPc, x86,
+x86\_64, MIPS, ARM, ...).
+\begin{figure}[h]
+\centering
+\includegraphics[height=0.5\textwidth]{images/preempt_rt.png}
+\caption{Überblick Preempt RT}
+\label{img:preempt_rt}
+\end{figure}
+Wie Abbildung \ref{img:preempt_rt} zeigt, integriert Preempt RT die
+Echtzeitfunktionalität ''natlos'' in den Linux Kernel. Auch die Entwickler
+anderer Projekte haben die Vorzüge von Preempt RT bereits erkannt. Die Roadmap
+für Xenomai 3 sieht Preempt RT Support vor. Dies würde den Einsatz von Xenomai
+Skins auf Preempt RT Kerneln ermgöglichen.
+
+\subsection*{Kontrollfragen}
+
+\begin{enumerate}
+\item Was sind die wichtigsten Anforderungen an ein Echtzeitsystem?
+\item Welche beiden Ansätze gibt es, um Linux echtzeitfähig zu machen?
+\item Was sind die bekanntesten Vertreter für Echtzeitlinux und welchen der oben
+beschriebenen Ansätze verfolgen Sie?
+\item Wird für das Schreiben einer Echtzeitapplikation mit Preempt RT eine
+spezielle API benötigt?
+\end{enumerate}
 
 \end{document}
diff --git a/realtime/rt-basics/hints_rt-basics_de.tex b/realtime/rt-basics/hints_rt-basics_de.tex
index fd15c6e..11c5c34 100644
--- a/realtime/rt-basics/hints_rt-basics_de.tex
+++ b/realtime/rt-basics/hints_rt-basics_de.tex
@@ -1,17 +1,18 @@
-\documentclass{article}
+\documentclass{lxarticle}
 \usepackage{german}
 \usepackage[utf8]{inputenc}
+\usepackage{lxheaders}
+\usepackage{lxextras}
 
 \begin{document}
 
-\section*{Block \lq Grundlagen Realtime\rq}
+\section*{Block \lq Was ist Linux?\rq}
 
 \subsection*{Lernziele}
 \begin{itemize}
-\item Kennenlernen der verschiedenen Ansätze (RTAI, Xenomai, RT-Preempt)
-\item Kennenlernen der Funktion von RT-Preempt
-\item Verstehen, wie der RT-Preempt-Patch beschafft und angewendet werden kann
-\item Anwendungen, Grenzen, Geschichte von RT-Preempt
+\item Lernziel 1
+\item Lernziel 2
+\item Lernziel 3
 \end{itemize}
 
 \subsection*{Unterrichts-Ablauf}
diff --git a/realtime/rt-basics/pres_rt-basics_de.tex b/realtime/rt-basics/pres_rt-basics_de.tex
index 07db328..c60f8a5 100644
--- a/realtime/rt-basics/pres_rt-basics_de.tex
+++ b/realtime/rt-basics/pres_rt-basics_de.tex
@@ -1,24 +1,214 @@
-\documentclass{article}
+\documentclass{beamer}
+\usetheme{linutronix}
 \usepackage{german}
 \usepackage[utf8]{inputenc}
+\usepackage{pgf}
+\usepackage{graphicx}
+\usepackage{lxextras}
+
+\title{Block \lq Realtime Linux\rq}
+\institute{Linutronix GmbH}
 
 \begin{document}
 
-\section*{Block \lq Was ist Linux?\rq}
+\maketitle
+
+
+% ----- Slide ------------------
+\begin{frame}
+\frametitle{Was ist Echtzeit?}
+\begin{itemize}
+\item Korrektheit bedeutet auch Ausführung zum korrekten Zeitpunkt
+\item Nicht Einhalten des korrekten Zeitrahmens führt zu einem Fehler
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{Echtzeit ''anschaulich''}
+\begin{overprint}
+\onslide<1>
+\begin{alertblock}{Wir erinnern uns}
+Nicht Einhalten des korrekten Zeitrahmens führt zu einem Fehler!
+\end{alertblock}
+\onslide<2>
+\begin{figure}[h]
+\centering
+\includegraphics[height=0.5\textwidth]{images/nuclear.png}
+\end{figure}
+\end{overprint} 
+\end{frame}
+
+\begin{frame}
+\frametitle{Anwendungsbereiche}
+\begin{itemize}
+\item Steuerungs- / Automatisierungstechnik
+\item Multimediasysteme
+\item Luft- und Raumfahrttechnik
+\item Finanzdienstleistung
+\item ...
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{Anforderungen}
+\begin{itemize}
+\item Deterministisches Zeitverhalten
+\item Unterbrechbarkeit
+\item Priority Inheritance / Priority Ceiling
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{Priority Inversion}
+\begin{figure}[h]
+\centering
+\includegraphics[width=0.8\textwidth]{images/prio_inv.png}
+\end{figure}
+\end{frame}
+
+\begin{frame}
+\frametitle{Linux und Echtzeit}
+\begin{figure}[h]
+\centering
+\includegraphics[height=0.5\textwidth]{images/gpos_vs_rt.png}
+\end{figure}
+\end{frame}
 
-\subsection*{Lernziele}
+\begin{frame}
+\frametitle{Ansätze}
 \begin{itemize}
-\item Lernziel 1
-\item Lernziel 2
-\item Lernziel 3
+\item Dual-Kernel
+\item In-Kernel / Single Kernel
 \end{itemize}
+\end{frame}
 
-\subsection*{Unterrichts-Ablauf}
+\begin{frame}
+\frametitle{Dual-Kernel}
+\begin{figure}[h]
+\centering
+\includegraphics[height=0.5\textwidth]{images/dual_kernel.png}
+\end{figure}
+\end{frame}
 
-Hinweise zur Präsentation, Zeitplanung, etc.
+\begin{frame}
+\frametitle{Single-Kernel}
+\begin{figure}[h]
+\centering
+\includegraphics[height=0.5\textwidth]{images/single_kernel.png}
+\end{figure}
+\end{frame}
+
+\begin{frame}
+\frametitle{RTAI}
+\begin{itemize}
+\item Prof. Paolo Mantegazza, Universität Mailand
+\item Dual-Kernel Ansatz
+\item Echtzeit im Kernelspace
+\item Userspace Echtzeittasks nur eingeschränkt möglich
+\item Oberstes Designziel: Möglichst niedrige Latenzzeiten
+\item Unterstützte Plattformen: x86, x86\_64, einige ARM Plattformen
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{RTAI}
+\begin{figure}[h]
+\centering
+\includegraphics[height=0.5\textwidth]{images/rtai.png}
+\end{figure}
+\end{frame}
+
+\begin{frame}
+\frametitle{Xenomai}
+\begin{itemize}
+\item Gegründet 2001
+\item Echtzeit im Userpace
+\item Skins bilden API verschiedenster RTOSse nach
+\item Dual-Kernel Ansatz
+\item Unterstützte Plattformen: x86, x86\_64, PowerPC, ARM, ia64
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{Xenomai}
+\begin{figure}[h]
+\centering
+\includegraphics[height=0.5\textwidth]{images/xenomai.png}
+\end{figure}
+\end{frame}
+
+\begin{frame}
+\frametitle{Xenomai / IPIPE}
+\begin{figure}[h]
+\centering
+\includegraphics[height=0.5\textwidth]{images/ipipe.png}
+\end{figure}
+\end{frame}
+
+\begin{frame}
+\frametitle{Drum prüfe, wer sich ewig bindet...}
+\begin{overprint}
+\onslide<1>
+\begin{figure}[h]
+\centering
+\includegraphics[width=0.8\textwidth]{images/mar01.png}
+\end{figure}
+\onslide<2>
+\begin{figure}[h]
+\centering
+\includegraphics[height=0.5\textwidth]{images/mar02.png}
+\end{figure}
+\onslide<3>
+\begin{figure}[h]
+\centering
+\includegraphics[height=0.5\textwidth]{images/mar03.png}
+\end{figure}
+\end{overprint}
+\end{frame}
+
+\begin{frame}
+\frametitle{Preempt RT}
+\begin{itemize}
+\item Thomas Gleixner, Ingo Molnar
+\item In-Kernel Ansatz
+\item Große Entwicklergemeinde
+\item Viele Funktionen bereits nach ''Mainline'' Linux übernommen
+\item POSIX Realtime
+\item Hohe Akzeptanz, vollständige Integration in Linux 2006 beschlossen
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{Preempt RT und Mainline}
+\textit{''Controlling a laser with Linux is crazy, but everyone in this room is
+crazy in his own way. So if you want to use Linux to control an an industrial
+welding laser, I have no problem with your using Preempt RT''} - Linus Torvalds
+auf dem Kernel Summit 2006
+\end{frame}
+
+\begin{frame}
+\frametitle{Wie macht Preempt RT Linux echtzeitfähig?}
+\begin{overprint}
+\onslide<1>
+\begin{alertblock}{Wir erinnern uns...}
+Unterbrechbarkeit ist eine zentrale Anforderung an ein Echtzeitsystem
+\end{alertblock}
+\onslide<2>
+\begin{itemize}
+\item Locking Primitiven: Spinlocks werden durch RT Mutexe ersetzt, die schlafen
+können. Raw Spinlocks ersetzen die ursprüngliche Spinlock
+\item Interrupt Handler laufen per default in einem Kernelthread
+\end{itemize}
+\end{overprint}
+\end{frame}
 
-\subsection*{Übungen bei vorhandener Hardware}
+\begin{frame}
+\frametitle{Preempt RT}
+\begin{figure}[h]
+\centering
+\includegraphics[height=0.5\textwidth]{images/preempt_rt.png}
+\end{figure}
+\end{frame}
 
-Hinweise zu Übungen, Zeitlimit dazu.
 
 \end{document}