Fachbereich 3 - Informatik und Mathematik

Bachelorarbeit

Studiengang Informatik

Eine Plattform für Bare-Metal-Programmierung und die Entwicklung eines Hard-Realtime-Operating-Systems

Christian Manal [email protected] Matrikelnummer 3005022

Gutachter Prof. Dr. Jan Peleska [email protected] Prof. Dr. Rolf Drechsler [email protected]

7. Januar 2019 Eidesstattliche Erklärung

Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig angefertigt, nicht anderweitig zu Prüfungszwecken vorgelegt und keine anderen als die angegebenen Hilfsmittel verwendet habe. Sämtliche wissentlich verwendete Textausschnitte, Zitate oder Inhalte anderer Verfasser wurden ausdrücklich als solche gekennzeichnet.

Bremen, 7. Januar 2019

Christian Manal

i Zusammenfassung

In dieser Arbeit geht es um die Auswahl einer Plattform, die sich für die Bare-Metal- Programmierung im Kontext einer Hochschullehrveranstaltung eignet. Insbesondere soll es möglich sein, zu Lehrzwecken ein minimales Betriebssystem zu entwickeln, das ggf. auch Hard-Realtime-Eigenschaften hat. Zu diesem Zweck wurden verschie- dene Single-Board-Computer (SBC) bzw. System-on-a-Chip (SoC) nach ausgewählten Kriterien bewertet und auf ihre Eignung untersucht.

ii Inhaltsverzeichnis

1. Einleitung 1

2. Grundlagen 2 2.1. Bare-Metal-Programmierung ...... 2 2.2. Hard-Realtime-Operating-System ...... 4 3. Verwandte Arbeiten 6 3.1. Betriebssysteme in der Hochschullehre ...... 6 3.2. Hard-Realtime-Betriebssysteme in der Lehre ...... 7 4. Auswahlprozess 9 4.1. Kriterien ...... 9 4.2. Evaluierte Plattformen ...... 17 4.3. Ergebnis ...... 33 5. Realtime-Eigenschaften 35 5.1. Versuchsaufbau ...... 35 5.2. Auswertung der Ergebnisse ...... 39 5.3. Versuchsfazit ...... 44 6. Fazit und Ausblick 46

Anhänge 48

A. Abbildungsverzeichnis 49

B. Tabellenverzeichnis 50

C. Glossar 51

D. Abkürzungen und Akronyme 53

E. Literaturverzeichnis 55

iii 1. Einleitung

Im Modul Entwicklung von Betriebssystemen (VAK 03-ME-702.02) an der Universität Bremen wurde bisher der Linux-Kernel als Anschauungsobjekt verwendet, um zentra- le Konzepte von Betriebssystemen zu vermitteln. Dabei geht es unter anderem um Inter-Process-Communication (IPC), Nebenläufigkeiten, Scheduling und dergleichen. Da der Linux-Kernel aber an einigen Stellen immer komplexer wird und sich im Laufe eines Jahres der Code stark verändern kann, entstehen Schwierigkeiten für Dozenten, auf dem Laufenden zu bleiben und für die Studierenden, sich durch komplexen Code zu arbeiten, um die relevanten Inhalte herauszufiltern und zu verstehen.

Im Rahmen dieser Arbeit wird deshalb eine Hardwareplattform gesucht, die es ermög- licht, einen schlanken Mikrokernel zu entwickeln, der anstelle von Linux benutzt wer- den kann, um die Kernkonzepte von Betriebssystemen zu vermitteln. Weiterhin soll die Plattform geeignet sein, ein Hard-Realtime-Operating-System (HRTOS) zu entwi- ckeln, um ggf. weiterführende Inhalte im Kontext von Betriebssystemen zu vermitteln oder zu erforschen.

1 2. Grundlagen

2.1. Bare-Metal-Programmierung

Bei Programmierung im herkömmlichen Sinne wird Software für ein oder mehrere Betriebssysteme entwickelt. Die Betriebssysteme stellen dabei abstrakte Application- Programming-Interfaces (APIs) bereit, die unter anderem von Hardware, der unter- liegenden Architektur usw. abstrahieren, sodass sich ein Entwickler beispielsweise nicht darum kümmern muss, welches Dateisystem für die Datenspeicherung genutzt wird oder mit welcher Schnittstelle das unterliegende Speichermedium angeschlos- sen ist. Desweiteren kümmern sich Betriebssysteme um die Verwaltung von Ressour- cen, wie beispielsweise Hauptspeicher und Rechenzeit einzelner Prozesse, sowie di- verse Schutzmechanismen, die verhindern sollen, dass einzelne Prozesse sich gegen- seitig behindern oder unbefugt auf Ressourcen anderer Prozesse zugreifen. Ein solcher Schutzmechanismus ist z.B. das Bereitstellen eines virtuellen Adressraumes. Gleichzei- tig werden aber auch Mechanismen bereitgestellt, die es Prozessen erlauben, gezielt und kontrolliert miteinander zu kommunizieren (auch IPC genannt).

Im Gegensatz dazu entwickelt man bei Bare-Metal-Programmierung ohne ein Be- triebssystem, direkt auf der Hardware, sodass ein Entwickler sich um all diese Dinge selbst kümmern muss. In der Regel kommt diese Art der Programmierung bei Micro- Controller-Units (MCUs) zum Einsatz, da diese meist für gezielte, eingebettete Ein- satzzwecke verwendet werden, die mit möglichst wenigen Ressourcen erfüllt werden sollen um beispielsweise Kosten und Energie zu sparen.

Da man bei Bare-Metal-Programmierung direkt auf der Hardware arbeitet, ist es au- ßerdem sehr wichtig, dass entweder eine fertige Hardware-Abstraction-Layer (HAL) für die Plattform zur Verfügung steht oder zumindest eine ausreichende Dokumen- tation um die benötigte Hardware manuell ansteuern zu können. Letzteres passiert i.d.R. durch das Lesen und Schreiben von in den Adressraum abgebildeten Registern [51, Kap. 5.1.3]. Anzahl, Adresse, Funktion usw. solcher Register, für alle auf einem SBC oder SoC verbauten Komponenten ohne Dokumentation in Erfahrung zu bringen ist fast unmöglich bzw. mit erheblichem Aufwand verbunden.

Eine weitere Eigenschaft von Bare-Metal-Programmierung ist, dass, insbesondere wenn MCUs mit sehr geringen Ressourcen zum Einsatz kommen, häufig in Assembler programmiert wird. Wenn es Compiler mit entsprechenden Backends gibt, kann

2 KAPITEL 2. GRUNDLAGEN 2.1. BARE-METAL-PROGRAMMIERUNG man jedoch auch Hochsprachen, wie z.B. C, benutzen. Bei der Verwendung von Hochsprachen muss jedoch weiterhin darauf geachtet werden, dass es ohne Betriebs- system auch keine Systemaufrufe gibt und somit die meisten (Standard-)Bibliotheken nicht ohne weiteres funktionieren. Weiterhin kann man für einige Funktionen nicht vermeiden, Assembler zu benutzen, wenn es für diese keine allgemeine Umsetzung in der genutzten Hochsprache gibt. Ein Beispiel dafür ist das Wechseln des Prozess- kontextes auf der CPU, da dieser Vorgang stark von der CPU bzw. dessen Architektur abhängt.

Unabhängig davon, ob man in Assembler, C oder einer anderen Sprache program- miert, muss man sich bei der Bare-Metal-Programmierung auch Gedanken um die Bootphase des Systems machen. Joachim Wietzke betrachtet diesen Vorgang im Kontext eingebetteter Systeme in [56, Kap. 6.1]. Bevor ein Programm gestartet werden kann, muss gemäß Wietzke die Hardware initialisiert werden. Das umfasst nicht nur Peripheriegeräte, sondern ggf. auch einen Speicher-Controller, ohne den der Hauptspeicher nicht verfügbar ist. Stack- und Program-Counter müssen gesetzt und Interrupt-Service-Routines (ISRs) definiert werden. Bei Hochsprachen, und insbesondere beim Cross-Kompilieren, muss der Compiler bzw. Linker außerdem wissen, wie der verfügbare Adressraum genutzt werden soll. Hierbei spricht man auch von Startup-Code oder auch einem Bootloader.

Eine weitere Schwierigkeit bei der Bare-Metal-Programmierung ist das Debuggen von Programmen. Häufig entwickelt man sein Bare-Metal-Programm für eine andere Platt- form, als auf der man das Programm schreibt, sodass man seinen Code nicht einfach lokal ausführen und debuggen kann (z.B. mit GNU-Debugger (GDB)). Hinzu kommt, dass man, wie bereits mehrfach erwähnt, sowieso stark von der Hardware abhängig ist, für die man gerade entwickelt. Idealerweise möchte man also gerne direkt auf der Zielhardware debuggen, sodass man keine extra Software zwischenschalten muss.

Zu diesem Zwecke gibt es sogenannte On-Chip-Debugger (OCD), mit dessen Hilfe man einen Debugger direkt mit der Zielhardware verbinden, und so z.B. Haltemarken setzen und Register- und Speicherinhalte inspizieren kann. Eine gängige Schnittstelle hierfür ist beispielsweise Joint Test Action Group (JTAG). Sofern man aber keine Hardware kauft, die einen integrierten Debugger hat, können hier zusätzliche Kosten für die Anschaffung eines kompatiblen externen Debug-Gerätes entstehen.

Zusammenfassend ist Bare-Metal-Programmierung somit deutlich komplexer als her- kömmliche Programmierung und setzt sehr genaues Wissen über die unterliegende Hardware voraus.

3 KAPITEL 2. GRUNDLAGEN 2.2. HARD-REALTIME-OPERATING-SYSTEM

2.2. Hard-Realtime-Operating-System

Shin und Ramanathan [46] bezeichnen Realtime-Systeme als Systeme, die bestimmte Aufgaben zuverlässig innerhalb bestimmter Deadlines erfüllen. Dabei unterscheiden sie zwischen drei Arten von Deadline: hard, firm und soft. Eine Hard-Deadline defi- nieren sie so, dass ein Verpassen dieser katastrophale Folgen hätte, z.B. weil dies zu einem Fehler im unterliegenden System führen würde, durch den im schlimmsten Fall sogar Personen- oder Sachschäden entstehen könnten. Von einer Firm-Deadline reden sie, wenn das zu der Deadline erwartete Ergebnis nach Verpassen dieser nutzlos wird, aber nicht zu einem Fehlerfall führt und schließlich von einer Soft-Deadline, wenn nach dessen Verstreichen die Nützlichkeit des Ergebnisses mit der Zeit abnimmt.

Ein Realtime-Operating-System (RTOS) ist im Allgemeinen somit ein Betriebssystem, das als Softwaregrundlage für Realtime-Systeme dienen kann, da es bestimmte Realtime-Eigenschaften erfüllen kann und ein HRTOS eine Steigerung, die insbeson- dere Hard-Deadlines einhalten kann.

Dabei müssen sowohl wiederkehrende Aufgaben beachtet werden, die regelmäßig zur selben Zeit erfüllt werden müssen, als auch irreguläre Aufgaben, die nur unter bestimmten Bedingungen auftreten und innerhalb eines bestimmten Zeitraums oder zu einer festen Zeit nach Eintreten verarbeitet sein müssen. Im Gegensatz zu vielen Anwendungen ohne Realtime-Eigenschaften muss bei der Entwicklung eines Realtime- Systems also auch stets die unterliegende Hardwareplattform bedacht werden und wieviele Ressourcen diese bereitstellt, damit ein Entwickler entsprechend planen bzw. sicherstellen kann, dass niemals mehr Aufgaben gleichzeitig anfallen, als sie vom System innerhalb ihrer Deadlines abgearbeitet werden können.

Daraus ergibt sich auch die Anforderung, dass möglichst wenige Ressourcen durch Overhead verloren gehen. Dies umfasst laut Wang in [55, Kap. 10.1] insbesondere auch Verarbeitungszeiten für Interrupts, sodass minimale Reaktionszeiten auf externe Eingaben garantiert werden können, sowie möglichst kurze kritischer Bereiche für den Schutz gemeinsam genutzter Datenstrukturen.

Davon ausgehend, dass es für jede Aufgabe einen Prozess gibt und Aufgaben in Teil- aufgaben zerlegt werden können, besteht jeder Prozess aus einem oder mehreren sogenannter Tasks. Neben Interrupt-Verarbeitung und kritischen Bereichen ist nach Wang das Scheduling, also das Verfahren, nach dem entschieden wird, welcher Task wann die CPU erhält, eine weitere kritische Komponente. Für Realtime-Systeme gibt es verschiedene Scheduling-Konzepte, die alle verschiedene Vor- und Nachteile ha- ben.

Ein solches Konzept ist das präemptive Scheduling, bei dem der Scheduler dem der- zeit aktiven Task unter bestimmten Bedingungen aktiv die CPU entzieht. Dies kann beispielsweise am Ende einer ISR oder vor der Rückkehr von einem Systemaufruf passieren. Ein Vorteil an diesem Verfahren ist, dass die Tasks selbst sich nicht dar-

4 KAPITEL 2. GRUNDLAGEN 2.2. HARD-REALTIME-OPERATING-SYSTEM um kümmern müssen, wieviel CPU-Zeit ihnen noch zusteht. Ein großes Problem, was dadurch jedoch enstehen kann, ist, dass Tasks zu ungünstigen Zeitpunkten unterbro- chen werden können, wie z.B. während des Zugriffs auf mit anderen Tasks gemeinsam genutzte Ressourcen. Aus diesem Grund erfordert präemptives Scheduling in der Re- gel zusätzlich Mechanismen zum Schutz kritischer Bereiche, sodass diese entweder nicht unterbrochen werden können, oder andere Tasks diese nicht betreten können, solange ein Task sich noch darin befindet.

Im Gegensatz dazu steht das kooperative Scheduling, bei dem davon ausgegangen wird, dass jeder Task von sich aus die CPU zu einem geeigneten Zeitpunkt abgibt, beispielsweise wenn auf Eingaben gewartet wird. Die oben beschriebene Problematik der kritischen Bereiche kann dadurch nicht auftreten, da ein Task die CPU immer zu einem sicheren Zeitpunkt abgeben kann. Nachteilig ist hingegen, dass Programmier- fehler oder bösartige Task die CPU zu lange oder sogar für immer behalten und damit das ganze System lahmlegen können.

Unabhängig von präemptivem oder kooperativem Scheduling gibt es weiterhin das Konzept der periodischen und nicht-periodischen Scheduler. Periodische Scheduler vergeben dabei die CPU in festen Intervallen an Tasks. Bei kooperativem Scheduling entsteht dabei das Problem, dass Entwickler geeignete Zeitpunkte innerhalb des Pro- grammflusses finden müssen, zu denen der jeweilige Task die CPU sicher abgeben kann, ohne dabei zu viel oder zu wenig Zeit innerhalb des Intervalls zu verbrauchen. Ersteres würde dazu führen, dass nachfolgende Task später als erwartet die CPU er- halten und dadurch ggf. Deadlines nicht mehr eingehalten werden können, während letzteres die CPU-Zeit bis zum Ende des Intervalls ungenutzt lassen würde.

Insbesondere bei nicht-periodischen Schedulern ist es weiterhin wichtig, dass der Scheduler Mechanismen hat, anhand derer entschieden werden kann, wann ein Task rechenbereit wird. Dies kann beispielsweise durch Ereignis-basierte Warteschlangen realisiert werden. Dabei würden Tasks sich jeweils in Warteschlangen für ein oder mehrere Ereignisse einreihen und sich dann als nicht rechenbereit melden. Sobald das jeweilige Ereignis eintritt, kann der Scheduler einen Task aus der jeweiligen War- teschlange auswählen und ihm die CPU geben.

Im Zusammenhang von Realtime-Systemen weniger relevant, aber dennoch erwäh- nenswert, ist der Begriff der Fairness von Scheduling-Verfahren. Dabei geht es darum, dass CPU-Zeit fair auf Tasks verteilt wird, wobei die genaue Definition von “fair” von diversen Faktoren abhängen kann. Siehe z.B. [5, 54] für Betrachtungen der verschie- denen Definitionen. In Realtime-Systemen spielt dieser Aspekt des Scheduling eine eher untergeordnete Rolle, da Entwickler hier manuell sicherstellen müssen, dass je- der Task ausreichend CPU-Zeit erhält um seine Deadlines einhalten zu können und dies somit nicht direkt dem Scheduling-Verfahren überlässt.

5 3. Verwandte Arbeiten

In diesem Abschnitt wird betrachtet, wie andere Hochschulen das Thema Betriebs- systeme in der Lehre behandeln und eine Abgrenzung zum Thema dieser Arbeit zu schaffen.

Dazu wird zunächst ein Blick darauf geworfen, welche Betriebssysteme im Allgemei- nen in der Hochschullehre verwendet werden. Anschließend wird dargestellt, wie der Spezialfall HRTOS behandelt wird.

3.1. Betriebssysteme in der Hochschullehre

Im Jahr 2005 haben Anderson et al. [4] eine Studie darüber durchgeführt, welche Betriebssysteme am häufigsten in der Hochschullehre in den USA behandelt werden. Wie man an der aus dem Paper übernommenen Tabelle 3.1 sehen kann, kommen da- bei viele speziell für die Lehre entwickelte Betriebssysteme zum Einsatz. Viel häufiger werden Konzepte jedoch nicht durch die direkte Entwicklung an einem Betriebssys- tem vermittelt, sondern indem sie auf einer höheren Ebene veranschaulicht werden, was sich in den Punkten Unix-oriented und Java-based without an OS widerspiegelt.

Tabelle 3.1.: Betriebssysteme in der Lehre an US-Hochschulen. [4] Programming Environment Usage Programming Environment Usage Unix-oriented 27% OS/161 5% Nachos 17% Xinu 4% Linux kernel 14% GeekOS 3% Java-based without an OS 8% JOS 3% Minix 7% Yalnix 3%

Mit der Kategorie Unix-oriented meinen Anderson et al. dabei, dass die jeweiligen Hochschulen Konzepte von Betriebssystemen lehren, indem diese als reguläre Anwen- dung für ein Unix-basiertes Betriebssystem implementiert werden. Java-based without an OS bedeutet prinzipiell dasselbe, nur dass Java als Implementierungssprache ge- wählt wird.

6 KAPITEL 3. VERWANDTE ARBEITEN 3.1. LEHRE

Von den Lehrbetriebssystemen setzen viele auf der MIPS-Architektur auf. OS/161 kommt beispielsweise sogar mit einem eigenen MIPS-Simulator, System/161, um eine einheitliche Entwicklungsumgebung bereitstellen zu können und ein vergleichsweise einfaches Debuggen zu ermöglichen [27]. Andere bauen auf x86 auf oder sind sogar Multi-Plattform, wobei auch hier teilweise Emulation genutzt wird, z.B. via Bochs1 oder QEMU2, da diese Debugging vereinfachen.

Generell beschäftigen sich alle diese Ansätze mit Betriebssystemen im Allgemeinen und weniger oder gar nicht mit Realtime-Eigenschaften. Insbesondere Unix-oriented, Java-based without an OS und die Ansätze, die Emulation bzw. Virtualisierung ver- wenden, sind generell auch nicht für die Betrachtung von Konzepten von Realtime- Systemen geeignet. Die restlichen ließen sich ggf. für Realtime-Systeme adaptieren, aber hier könnte der Aufwand ggf. größer sein, als ein minimales System von Grund auf neu zu entwickeln.

3.2. Hard-Realtime-Betriebssysteme in der Lehre

In der herangezogenen Studie ging es primär um “herkömmliche” auch (general- purpose) Betriebssysteme und eher weniger oder gar nicht um RTOSs. In Ermangelung weiterer Studien zu diesem Thema kann hier nur spekuliert werden, warum das so ist. An der Universität Bremen kommen die Stichworte “Echtzeit” oder “Realtime” im Veranstaltungsverzeichnis beispielsweise bei den Modulen “Hardware- und Algorithmenentwurf für Echtzeitsysteme in der Fahrzeugtechnik”3 des Fachbereichs für Produktionstechnik sowie “Hard- und Softwareentwurf für Echtzeitsysteme”4 des Fachbereichs Physik und Elektrotechnik vor, aber nicht am Fachbereich für Informatik und Mathematik.

Anders ist dies an anderen deutschen Hochschulen. Veranstaltungen im Kontext von Realtime-Systemen werden oder wurden beispielsweise von den Informa- tikfachbereichen der Universität Koblenz5, der Friedrich-Alexander-Universität Erlangen-Nürnberg6, sowie der HU-Berlin7 angeboten.

Daran ist gut zu erkennen, dass die ganze Thematik durch den starken Zusammen- hang von Hard- und Software, schwerpunktmäßig sowohl aus Sicht der Informatik als auch der Elektrotechnik betrachtet werden kann und eine entsprechende Lehr- veranstaltung dementsprechend gut in das Veranstaltungsverzeichnis des Informatik-

1http://bochs.sourceforge.net/ 2https://www.qemu.org/ 3VAK 04-V07-P-ST-1729 im Veranstaltungsverzeichnis der Uni-Bremen. 4VAK 01-04-PBA im Veranstaltungsverzeichnis der Uni-Bremen. 5Veranstaltungsnummer 0432007 https://klips.uni-koblenz.de/, Abruf 2018-12-14 6https://www4.cs.fau.de/Lehre/WS17/V_EZS/, Abruf 2018-12-14 7https://www2.informatik.hu-berlin.de/~richling/emes2003/ , Abruf 2018-12-14

7 KAPITEL 3. VERWANDTE ARBEITEN 3.2. LEHRE fachbereichs der Uni Bremen passen würde.

8 4. Auswahlprozess

Um eine geeignete Plattform zu finden, wurde zunächste eine Liste auf dem Markt erhältlicher SBC bzw. SoC Systemen erstellt. Diese wurden dann anhand der im Fol- genden definierten Kriterien auf ihre Eignung geprüft.

4.1. Kriterien

Bei der Feststellung der Eignung einer Plattform für die Bare-Metal-Programmierung im Rahmen einer Lehrveranstaltung ist ein zentraler Punkt, dass die Studierenden und Dozenten sich nicht mit dem “Drumherum” beschäftigen wollen. Es geht im Wesent- lichen um die Vermittlung von Konzepten und nicht das Erlernen einer bestimmten Programmierplattform. Dies spiegelt sich in vielen der im folgenden aufgestellten Kri- terien wieder. Die Kriterien werden hier in zwei Kategorien eingeteilt: Pflicht und optional. Pflicht- kriterien sind durch ein P und eine Laufnummer gekennzeichnet, optionale Kriterien mit O und einer Laufnummer. Pflichtkriterien müssen zumindest teilweise erfüllt sein (siehe unten), damit die jeweilige Plattform geeignet ist. Optionale Kriterien werden zur Abwägung von Kandidaten herangezogen, die alle Pflichtkriterien gleichermaßen erfüllen. Weiterhin werden jedem Kriterium die Erfüllungsgrade “nicht erfüllt” (kurz nicht) “teilweise erfüllt” (kurz teilweise) und “vollständig erfüllt” (kurz voll) zugeordnet. Un- ter welchen Umständen diese jeweils gelten, wird in der Beschreibung des jeweiligen Kriteriums erläutert.

Dokumentation

Eine der wichtigsten Grundlagen dafür, mit einem unbekannten System zu arbeiten, ist der Grad der Dokumentation. Ohne gute Dokumentation ist es, gerade wenn es um ein Hardware-System geht, fast unmöglich, Bare-Metal-Software für diese zu ent- wickeln. Es muss zumindest eine Beschreibung des Befehlssatzes und der Register vorhanden sein, damit man überhaupt Code für die jeweilige Plattform schreiben kann.

9 KAPITEL 4. AUSWAHLPROZESS 4.1. KRITERIEN

Zusätzlich dazu sind z.B. für einen SBC eine Dokumentation der Platine und der darauf verbauten Peripheriegeräte von hoher Wichtigkeit, um diese nutzen zu können, ohne extremem Aufwand betreiben zu müssen.

Und schließlich möchte man, wenn möglich, nicht direkt via Assembler auf dem Sys- tem entwickeln sondern mit einer Hochsprache, wie z.B. C, für die im Idealfall bereits Bibliotheken vorhanden sind, die das Ansteuern der Hardware vereinfachen. Um das Einlesen und potentiell sehr komplexen Code vermeiden zu können, sollte all dies ebenfalls dokumentiert sein. Gleiches gilt für die Toolchain für das Erzeugen von aus- führbarem Code und ein ggf. bereits von einem Rahmenwerk vorgegebenem Build- System.

Unter diesem Abschnitt ergeben sich dadurch drei Kriterien, die ein System erfüllen sollte:

• Dokumentation der CPU • Dokumentation der Platine • Dokumentation der Entwicklungsumgebung

Die Erfüllungsgrade für all diese Kriterien sind identisch und der Tabelle 4.1 zu ent- nehmen.

Tabelle 4.1.: Erfüllungsgrade für Dokumentationen nicht Eine Dokumentation ist nicht verfügbar. teilweise Eine Dokumentation ist kostenpflichtig verfügbar. voll Eine Dokumentation ist frei verfügbar.

P1 Dokumentation der CPU

Siehe Tabelle 4.1.

P2 Dokumentation der Platine

Siehe Tabelle 4.1.

P3 Dokumentation der Entwicklungsumgebung

Siehe Tabelle 4.1.

10 KAPITEL 4. AUSWAHLPROZESS 4.1. KRITERIEN

Programmieraufwand

Ein weiterer wichtiger Aspekt ist der Aufwand, der betrieben werden muss, um auf der Zielplattform zu entwickeln. Dies ist zum Teil bereits durch die Kriterien der Dokumentation in Abschnitt 4.1 abgedeckt, umfasst aber noch weitere Faktoren.

Wenn es beispielsweise darum geht, häufige Änderungen am Code zu testen, spielt es eine Rolle, wie man diesen auf die Plattform aufspielt und wie lange dies dauert. Muss man beispielsweise jedes Mal eine SD-Karte vom Gerät abziehen, an den eige- nen Rechner anschließen, den Code aufspielen und wieder zurückstecken, ist dies viel mehr Aufwand als wenn man den Code einfach per USB-Kabel oder dergleichen aufspielen kann. Beim direkten Aufspielen wäre es weiterhin wünschenswert, wenn dies direkt aus der Entwicklungsumgebung heraus funktionieren würde.

Weiterhin ist das Bootstrapping von Hardware, je nach dessen Komplexität, i.d.R. keine triviale Aufgabe, weshalb es erforderlich ist, dass es für die Plattform fertigen Initialisierungs-Code gäbe, den man einfach benutzen kann und diesen nicht aufwän- dig anhand der Dokumentation selbst entwickeln muss. Das gleiche gilt für den Zugriff auf Hardwarekomponenten und Peripheriegeräte. Es sollte also ein Rahmenwerk von Code bzw. Bibliotheken vorhanden sein, welches hierfür fertige Implementierungen bereitstellt.

Was auch nicht außer Acht gelassen werden sollte, ist die Möglichkeiten zum De- buggen von Code (siehe auch Abschnitt 2.1). Eine Möglichkeit dies zu vereinfachen wäre, die Zielhardware zu emulieren und hier einen Debugger anzusetzen. Da das Ziel dieser Arbeit jedoch ist, eine Hardwareplattform zu finden, auf der man direkt entwi- ckeln kann, entfällt diese Option. Eine weitere Alternative wäre das Vorhandensein einer Schnittstelle für Textausgaben, sodass man durch diese feststellen kann, wie der Programmzustand zu einem bestimmten Zeitpunkt ist oder bis zu welcher Stelle das Programm kommt, bevor ein Fehler auftritt. Diese Methode ist jedoch alles andere als optimal, da zusätzlicher Code für Textausgaben ggf. die Realtime-Eigenschaften des Programms beeinträchtigen. Die optimale Lösung wäre daher also ein OCD.

Aus diesen Faktoren ergeben sich die folgenden Kriterien.

P4 Aufspielen von Code

Tabelle 4.2.: Erfüllungsgrade für das Aufspielen von Code nicht Code muss auf Wechselmedium (z.B. SD-Karte) gespielt werden. teilweise Code kann mit externem Werkzeug direkt aufgespielt werden. voll Code kann direkt aus Entwicklungsumgebung aufgespielt werden.

11 KAPITEL 4. AUSWAHLPROZESS 4.1. KRITERIEN

P5 Vorhandenes Rahmenwerk

Tabelle 4.3.: Erfüllungsgrade für Rahmenwerk nicht Kein Rahmenwerk vorhanden. teilweise Rahmenwerk ohne Bootstrapping-Code vorhanden. voll Rahmenwerk mit Bootstrapping-Code vorhanden.

P6 Debugging-Mechanismen

Tabelle 4.4.: Erfüllungsgrade für Debugging-Mechanismen nicht Keine Debug-Mechanismen vorhanden. teilweise Debugging nur durch Textausgaben. voll On-Chip-Debugger vorhanden.

Verfügbare Ressourcen

MCUs haben den Vorteil, dass diese meist eine vergleichsweise simple Hardware- Architektur haben, sodass es relativ leicht ist, für diese Bare-Metal-Anwendungen zu entwickeln. Eine Eigenschaft, die dies mit sich bringt, ist jedoch, dass dadurch in vielen Fällen die verfügbaren Ressourcen (z.B. CPU-Takt und Hauptspeicher) stark begrenzt sind. Da die auszuwählende Plattform, wie bereits mehrfach erwähnt, Leh- renden und Lernenden so wenige Hindernisse wie möglich in den Weg stellen sollte, könnte dieser Umstand problematisch werden, wenn diese Optimierungsaufwand be- treiben müssen, um ihren Code unter den gegebenen Einschränkungen zum Laufen zu bekommen. Dabei ist insbesondere der Hauptspeicher wichtig, da Programme gar nicht laufen, wenn nicht genug Speicher vorhanden ist. Eine zu langsame CPU be- deutet dagegen nur, dass die Laufzeit länger wird, was im Kontext der Lehre eher nebensächlich ist.

Ein weiterer Faktor ist verfügbarer Massenspeicher, welcher allerdings eher eine un- tergeordnete Rolle spielt. Zum einen ist Massenspeicher vergleichsweise günstig und somit eigentlich immer größer als der Hauptspeicher, zum anderen wird nicht in al- len Fällen Massenspeicher benötigt, um Code aufzuspielen, da man beispielsweise via JTAG lauffähigen Code direkt in den Hauptspeicher laden kann. Aus diesem Grund werden Massenspeicher und CPU-Takt in Hinsicht auf die Anforderungen an verfüg- bare Ressourcen hier ignoriert.

Vom Dozenten wurde die Vorgabe gemacht, dass mindestens 512MiB Hauptspeicher zur Verfügung stehen sollten, sodass dieser Wert für die volle Erfüllung des Kriteriums angesetzt wird. Da so viel Hauptspeicher aber auch schon mehr als genug für viele

12 KAPITEL 4. AUSWAHLPROZESS 4.1. KRITERIEN gängige Betriebssysteme plus Anwendungen ist, kann für teilweise Erfüllung deut- lich tiefer angesetzt werden, da im Rahmen eines Semesters vermutlich kein System entstehen kann, welches 512MiB voll ausnutzt.

Ein extrem kleines Betriebssystem für eingebettete Realtime-Anwendungen ist z.B. TinyOS, welches im Kern bereits mit etwa 400 Bytes Hauptspeicher auskommt [20]. Ein anderes Beispiel ist das Betriebssystem Contiki, welches für den Einsatz im Inter- net der Dinge gedacht ist, beispielsweise für Sensornetze, und für den Kern und eine Anwendung bereits mit 20KiB Hauptspeicher auskommt [16]. Diese Systeme sind al- lerdings bereits hochgradig optimiert, sodass hier für den Einsatz in der Lehre ein Vielfaches der Speichergröße angesetzt werden sollte.

Aus diesem Grund werden hier 128KiB als Mindestmaß vorausgesetzt.

P7 Ausreichender Hauptspeicher

Tabelle 4.5.: Erfüllungsgrade für Ausreichender Hauptspeicher nicht ≤ 128KiB teilweise ≥ 128KiB voll ≥ 512MiB

Freie Toolchain

Weiterhin wünschenswert wäre es, wenn die eingesetzte Toolchain für Studenten frei nutzbar wäre, sodass zum einen für die Lehrveranstaltung weniger Kosten entstehen (siehe auch Abschnitt 4.1) und zum anderen interessierte Studenten auch nach Ab- schluss einer Lehrveranstaltung weiterhin eigene Projekte umsetzen können. Ein zu- sätzlicher positiver Aspekt einer freien Toolchain ist außerdem, dass man sich nicht abhängig von einem Hersteller macht, der ein proprietäres Produkt einfach einstel- len oder dessen Preise erhöhen könnte. Freie Software wäre im Zweifelsfall auch nach Einstellung der Entwicklung verfügbar.

Daraus ergeben sich die folgenden Kriterien und Erfüllungsgrade.

13 KAPITEL 4. AUSWAHLPROZESS 4.1. KRITERIEN

O1 Quelloffenheit

Tabelle 4.6.: Erfüllungsgrade für Quelloffenheit nicht Vollständig proprietär. teilweise Quellen werden nach Erwerb einer kostenpflichtigen Lizenz bereitgestellt. voll Quellen sind frei verfügbar.

O2 Lizenzkosten

Tabelle 4.7.: Erfüllungsgrade für Lizenzkosten nicht Immer kostenbehaftet. teilweise Kostenfreie Lizenzen für Studenten erhältlich. voll Immer kostenfrei.

Kosten

In Abhängigkeit von den vorherigen kostenbasierten Kriterien sind die Gesamtkosten pro Entwicklungsumgebung nicht zu vernachlässigen. Diese setzen sich zum einen aus den einmaligen Anschaffungskosten zusammen, sowie ggf. aus laufenden Kosten pro Semester.

Solange diese jedoch nicht ins Exorbitante wachsen, liegt die Relevanz hier eher bei dem schon erwähnten Fall, dass interessierte Studenten nach dem Abschluss der Lehr- veranstaltung privat weiterarbeiten möchten. Dieses Kriterium betrachtet die Kosten also sowohl aus Sicht der Universität bzw. des Dozenten, als auch aus Sicht eines engagierten Studenten.

Als Grundlage für die Abschätzung von für Studenten verkraftbare Kosten wird die 21. Sozialerhebung des Deutschen Studentenwerks herangezogen. Demnach haben deutsche Studenten im Jahr 2016 etwa 20€ pro Monat für Lernmittel ausgegeben [33, Bild 4.13], was etwa 120€ pro Semester entspricht. Da dies der kleinste Posten in der im Bericht abgebildeten Auflistung der Ausgaben ist, wird hier angenommen, dass dieser durchaus noch einmal 50% aufgeschlagen werden können, sodass 60€ pro Semester laufende Kosten vertretbar wären. Ideal wären natürlich keine laufenden Kosten. Die Sicht der Universität bzw. des Dozenten fällt hier durch die Aufschlüsse- lung der Erfüllungsgrade nicht ins Gewicht, da hier durchaus höhere laufende Kosten vertretbar sind.

Bei den einmaligen Ausgaben für eine vollständige Entwicklungsumgebung wird hier

14 KAPITEL 4. AUSWAHLPROZESS 4.1. KRITERIEN davon ausgegangen, dass der doppelte Semestersatz von 120€ einmalig vertretbar ist und alles darüber abhängig von der individuellen finanziellen Situation des oder der jeweiligen Studierenden ist. Aus Sicht der Uni bzw. des Dozenten wird hier da- von ausgegangen, dass einmalige Ausgaben von 1.000€ pro Entwicklungsumgebung noch vertretbar sind, wenn davon ausgegangen wird, dass bis zu acht Umgebungen beschafft werden müssen.

Diese Zahl ergibt sich aus den Erfahrungen des Dozenten, der mit bis zu sechs Gruppen pro Veranstaltung rechnet, selbst eine Umgebung benötigt und mindestens eine als Reserve, falls z.B. mehr Teilnehmer als erwartet kommen oder während des Semesters eine Plottform kaputt geht oder dergleichen.

O3 Einmalige Ausgaben pro Entwicklungsumgebung

Tabelle 4.8.: Erfüllungsgrade für Einmalige Ausgaben nicht ≥ 1.000€ teilweise > 240€ voll ≤ 240€

O4 Laufende Kosten pro Semester

Tabelle 4.9.: Erfüllungsgrade für laufende Kosten nicht > 60€ teilweise ≤ 60€ voll kostenlos

Vorgaben des Dozenten

Der Dozent der Veranstaltung hat im Vorfeld zwei Vorgaben gemacht, die eine Platt- form erfüllen muss, damit sie für die Verwendung geeignet ist. Die Voraussetzung von mindestens 512MiB Hauptspeicher wurde bereits in Abschnitt 4.1 behandelt. Die zweite Vorgabe war, dass eine Netzwerkschnittstelle vorhanden ist, sodass auch die Anbindung von Betriebssystemen an Rechnernetze behandelt werden kann.

Es sollte also zumindest möglich sein, eine Netzwerkschnittstelle an die Zielplattform anzuschließen, wenn nicht schon eine ab Werk integriert ist.

15 KAPITEL 4. AUSWAHLPROZESS 4.1. KRITERIEN

O5 Netzwerkschnittstelle vorhanden

Tabelle 4.10.: Erfüllungsgrade für Netzwerkschnittstelle nicht Netzwerkschnittstelle nicht untestützt. teilweise Netzwerkschnittstelle kann nachgerüstet werden. voll Netzwerkschnittstelle integriert.

Zusammenfassung

Die in Tabelle 4.11 nochmal zusammengefassten Auswahlkriterien legen den Fokus auf das Finden einer Plattform, in die man sich mit möglichst geringen Aufwand einar- beiten kann und die bei Interesse auch nach der Lehrveranstaltung von interessierten Studenten privat aufgegriffen werden kann.

Tabelle 4.11.: Auswahlkriterien auf einen Blick Nr. Kriterium P1 Dokumentation der CPU P2 Dokumentation der Platine P3 Dokumentation der Entwicklungsumgebung P4 Aufspielen von Code P5 Vorhandenes Rahmenwerk P6 Debugging-Mechanismen P7 Ausreichender Hauptspeicher O1 Quelloffenheit O2 Lizenzkosten O3 Einmalige Ausgaben pro Entwicklungsumgebung O4 Laufende Kosten pro Semester O5 Netzwerkschnittstelle vorhanden

16 KAPITEL 4. AUSWAHLPROZESS 4.2. EVALUIERTE PLATTFORMEN

4.2. Evaluierte Plattformen

In diesem Abschnitt wird der Evaluationsprozess der vielversprechendsten Plattfor- men beschrieben. Zunächst wurde eine nicht erschöpfende Recherche nach auf dem Markt verfügbaren SBCs mit potentieller Eignung durchgeführt. Die daraus entstan- dene Liste von Kandidaten wird im Folgenden anhand der aufgestellten Kriterien ana- lysiert.

STM32F4-Discovery

Das STM32F4-Discovery-Board ist eine Entwicklungsplatine der Firma STMicroelec- tronics auf Basis einer 32Bit ARM Cortex-M4 MCU. Die Platine kommt mit einer in- tegrierten JTAG-fähigen Schnittstelle zum Flashen und Debuggen, die via USB oder direkt über eine auf der Platine verbauten Pinleiste angesteuert werden kann. Die Plattform bietet 1MiB Flashspeicher und 192KiB Hauptspeicher an. Weiterhin sind auf der Platine unter anderem vier ansteuerbare LEDs und ein Taster verbaut [14].

Diese Plattform wird stellvertretend für die Klasse der auf Mikrocontrollern basierten SBCs untersucht.

Kriterium P1 Dokumentation der CPU

Erfüllungsgrad: voll

Die Dokumentation der verbauten Cortex-M4-CPU ist frei verfügbar [7].

Kriterium P2 Dokumentation der Platine

Erfüllungsgrad: voll

Ein detailiertes Handbuch für die Platine, inklusive Schaltplan, ist frei verfügbar [14].

Kriterium P3 Dokumentation der Entwicklungsumgebung

Erfüllungsgrad: voll

Der Hersteller stellt Handbücher für Soft- und Firmwareentwicklung auf der Platt- form, sowie Software-Pakete mit Bibliotheken und Beispielcode, frei zur Verfügung [23, 22]. Die für ARM-CPUs frei verfügbare GNU-Toolchain [24] basiert auf der

17 KAPITEL 4. AUSWAHLPROZESS 4.2. EVALUIERTE PLATTFORMEN weit verbreiteten GNU-Compiler-Collection (GCC) und ist ebenfalls gut dokumentiert [21] und kann in Verbindung mit freien und wohlbekannten Integrated-Development- Environments (IDEs), wie beispielsweise Eclipse1, verwendet werden.

Kriterium P4 Aufspielen von Code

Erfüllungsgrad: voll

Die Platine hat einen fest verbauten ST-LINK-Adapter (dabei handelt es sich um eine Programmier- und Debug-Schnittstelle), der via USB ansteuerbar ist, und das direkte Aufspielen von Software auf den internen Flashspeicher erlaubt. Vorhandene Plug- ins, wie beispielsweise das “GNU ARM OpenOCD Debugging”-Plugin [32] für Eclipse, erlauben es, dies auch direkt aus der Entwicklungsumgebung zu tun.

Kriterium P5 Vorhandenes Rahmenwerk

Erfüllungsgrad: voll

Auf der Produktwebseite des Herstellers werden Quellen mit Beispielcode, sowie ein Paket für Hardwareabstraktion, zum freien Download bereitgestellt. Insbesondere das STM32CubeF4-Paket stellt hier die ideale Grundlage für die Entwicklung von Bare- Metal-Software dar [49]. Bootstrapping-Code wird generell nicht benötigt, da es kei- ne komplexe Hardware, wie Speichercontroller gibt, die separat initialisiert werden muss.

Kriterium P6 Debugging-Mechanismen

Erfüllungsgrad: voll

Wie bereits weiter oben bei Kriterium P4 erwähnt, kommt die Platine mit einem fest verbauten ST-LINK-Adapter, welcher nicht nur zum Aufspielen von Software dient, sondern auch einen OCD darstellt.

Kriterium P7 Ausreichender Hauptspeicher

Erfüllungsgrad: teilweise

Wie bereits erwähnt, verfügt die Platine über 192KiB Hauptspeicher.

1https://www.eclipse.org/

18 KAPITEL 4. AUSWAHLPROZESS 4.2. EVALUIERTE PLATTFORMEN

Kriterium O1 Quelloffenheit

Erfüllungsgrad: voll

Eine vollständig freie und quelloffene Toolchain ist verfügbar [24].

Kriterium O2 Lizenzkosten

Erfüllungsgrad: voll

Außer den Anschaffungskosten für die Hardware fallen keine weiteren Kosten an.

Kriterium O3 Einmalige Ausgaben pro Entwicklungsumgebung

Erfüllungsgrad: voll

Der Preis für eine Platine ist auf der Herstellerwebseite mit 19,90 USD angegeben [50, Teilnummer STM32F407G-DISC1].

Kriterium O4 Laufende Kosten pro Semester

Erfüllungsgrad: voll

Außer den Anschaffungskosten für die Hardware fallen keine weiteren Kosten an.

Kriterium O5 Netzwerkschnittstelle vorhanden

Erfüllungsgrad: teilweise

Die Platine kommt nicht ab Werk mit einer Netzwerkschnittstelle. Sie hat jedoch eine Serial-Peripheral-Interface (SPI)-Schnittstelle, sodass eine Netzwerkschnittstel- le beispielsweise auf Basis des ENC28J60 Ethernet-Controllers der Firma Microchip Technology Inc. [17] nachgerüstet werden kann.

Raspberry Pi

Raspberry Pi ist eine Familie von SBCs die von der britischen Raspberry Pi Foundation entwickelt wurde. Das Ziel dabei war, einen kompakten Computer für 25 USD oder

19 KAPITEL 4. AUSWAHLPROZESS 4.2. EVALUIERTE PLATTFORMEN weniger anzubieten, um jungen und im allgemeinen an Technik interessierten Leuten eine Plattform zu bieten, mit der sie hardwarenahes Programmieren lernen können [45]. Die aktuelle Revision, der Raspberry Pi 3 Model B+ (im Weiteren als Model B+ bezeichnet), kommt mit 1GiB Hauptspeicher und einer 1,5GHz ARM CPU [41].

Kriterium P1 Dokumentation der CPU

Erfüllungsgrad: voll

Das Model B+ basiert auf der ARM Cortex-A53-CPU, dessen Dokumentation frei Ver- fügbar ist [6].

Kriterium P2 Dokumentation der Platine

Erfüllungsgrad: voll

Die Raspberry Pi Foundation bietet Dokumentation für ihre Platinen und die darauf verbauten Peripheriegeräte frei zum Herunterladen auf ihrer Webseite an [42].

Kriterium P3 Dokumentation der Entwicklungsumgebung

Erfüllungsgrad: voll

Es wird keine besondere IDE vorausgesetzt, sodass eine beliebige benutzt werden kann, die die Toolchain des verwendeten Rahmenwerks unterstützt.

Rahmenwerke (siehe weiter unten) sind in C++ und Pascal verfügbar. Für C++ kann die bereits erwähnte ARM GCC-Toolchain verwendet werden, für Pascal eignet sich beispielsweise Free-Pascal [19].

Kriterium P4 Aufspielen von Code

Erfüllungsgrad: nicht

Der Raspberry Pi verfügt über eine JTAG-Schnittstelle, die theoretisch für das Laden von Code direkt in den Hauptspeicher genutzt werden könnte. Leider ist die Hard- wareschnittstelle dafür auf die General Purpose Input/Output (GPIO)-Pins mit geteil- ter Funktionalität gelegt (Siehe GPIO22-GPIO27 in [8, Tabelle 6-31]), sodass zunächst schon einmal ein System gebootet worden sein muss, dass diese richtig konfiguriert und somit ein Henne-Ei-Problem erzeugt. Alternativ kann von SD-Karte gebootet wer- den, was wiederum den Aufwand des hin- und hersteckens mit sich bringt.

20 KAPITEL 4. AUSWAHLPROZESS 4.2. EVALUIERTE PLATTFORMEN

Kriterium P5 Vorhandenes Rahmenwerk

Erfüllungsgrad: voll

Es gibt mindestens zwei Rahmenwerke für die Bare-Metal-Entwicklung auf dem Raspberry Pi. Zum einen das auf C++ basierende Circle [47] und zum anderen das in Pascal entwickelte Ultibo [52].

Kriterium P6 Debugging-Mechanismen

Erfüllungsgrad: voll

Wie bereits oben erwähnt, hat der Raspberry Pi eine ARM-JTAG-Schnittstelle. Dessen Benutzung wird zwar dadurch erschwert, dass diese zunächst durch Software konfi- guriert werden muss, aber wenn dies früh genug im Programmablauf passiert, sollte sie dennoch in den meisten Fällen problemlos nutzbar sein.

Kriterium P7 Ausreichender Hauptspeicher

Erfüllungsgrad: voll

Wie bereits erwähnt, ist das Model B+ mit 1GiB Hauptspeicher ausgestattet [41].

Kriterium O1 Quelloffenheit

Erfüllungsgrad: voll

Die Quellen beider betrachteten Rahmenwerke sind frei verfügbar.

Kriterium O2 Lizenzkosten

Erfüllungsgrad: voll

Außer den Anschaffungskosten für die Hardware fallen keine weiteren Kosten an.

21 KAPITEL 4. AUSWAHLPROZESS 4.2. EVALUIERTE PLATTFORMEN

Kriterium O3 Einmalige Ausgaben pro Entwicklungsumgebung

Erfüllungsgrad: voll

Laut dem Heise.de Preisvergleichsportal, ist das Model B+ ab 33,90€ verfügbar [26].

Für einen JTAG-Debugger, beispielsweise der Flyswatter2 von Tin Can Tools [18] oder der XDS110 von Texas Instruments (TI) [57], kommen noch einmal ca. 90 bis 100 USD dazu.

Insgesamt bewegt sich der Preis somit noch bequem unter den angesetzten 240€.

Kriterium O4 Laufende Kosten pro Semester

Erfüllungsgrad: voll

Außer den Anschaffungskosten für die Hardware fallen keine weiteren Kosten an.

Kriterium O5 Netzwerkschnittstelle vorhanden

Erfüllungsgrad: voll

Das Model B+ kommt ab Werk sowohl mit einer Ethernet- als einer WLAN- Schnittstelle [41].

BeagleBone Black

Ähnlich zum Raspberry Pi ist das BeagleBone Black (BBB) Teil einer Familie von SBCs. Entwickelt von der BeagleBoard.org Foundation in den USA, ist das BBB von der Hardwareausstattung her vergleichbar mit dem Raspberry Pi. Es kommt mit 512MiB Hauptspeicher und einer 1GHz ARM CPU [11, Kap. 4.2].

Die CPU des BBB hat zwar nur einen Kern, allerdings verfügt das System über zwei sogenannte Programmable-Realtime-Units (PRUs). Dabei handelt es sich um Kopro- zessoren mit einem eingeschränkten Befehlssatz, die jeweils mit 200MHz getaktet sind, Zugriff auf Hauptspeicher und Peripheriegeräte haben und dadurch kleinere Aufgaben parallel zur CPU bearbeiten können.

Das BBB wurde aus der Familie der BeagleBoards gewählt, da die Versionen mit mehr bzw. anderer Funktionalität (BeagleBone Blue, BeagleBone Black Wireless) keinen Mehrwert für den Anwendungsfall bieten und teurer sind bzw. im Falle des Pocket- Beagle weniger Anforderungen erfüllen (keine Netzwerkschnittstelle).

22 KAPITEL 4. AUSWAHLPROZESS 4.2. EVALUIERTE PLATTFORMEN

Kriterium P1 Dokumentation der CPU

Erfüllungsgrad: voll

Das BBB basiert auf dem Sitara™ AM335x SoC der Firma Texas Instruments, welches wiederum eine ARM Cortex-A8-CPU verwendet. Für beide sind Dokumentationen frei verfügbar [3, 12].

Kriterium P2 Dokumentation der Platine

Erfüllungsgrad: voll

Das BBB selbst ist in im frei verfügbaren System Reference Manual dokumentiert [11].

Kriterium P3 Dokumentation der Entwicklungsumgebung

Erfüllungsgrad: voll

TI bietet eine auf Eclipse basierende Entwicklungsumgebung namens Code Composer Studio (CCS) an. Da Eclipse selbst weit verbreitet, quelloffen und gut dokumentiert ist, ist dies schon einmal eine gute Basis. Für die Entwicklung auf ARM-CPUs kann entweder die freie GNU-Toolchain verwendet werden [24] oder eine proprietäre aber frei verfügbare und ausführlich dokumentierte Toolchain von TI selbst [10].

Kriterium P4 Aufspielen von Code

Erfüllungsgrad: voll

Das BBB hat eine fest verbaute JTAG-Schnittstelle über die Code direkt in den Spei- cher geladen werden kann. Um diese nutzen zu können, muss man jedoch zunächst eine passende Pinleiste auf die entsprechenden Kontakte auf der Platine auflöten. Au- ßerdem muss ein externer und kompatibler JTAG-Emulator vorhanden sein, um die Schnittstelle nutzen zu können [11, Kap. 7.9]. CCS erlaubt es, Code direkt aus der Entwicklungsumgebung aufzuspielen.

23 KAPITEL 4. AUSWAHLPROZESS 4.2. EVALUIERTE PLATTFORMEN

Kriterium P5 Vorhandenes Rahmenwerk

Erfüllungsgrad: voll

Der Hersteller des unterliegenden AM335x SoC, TI, bietet unter dem Namen Star- terWare kostenlos ein Softwarepaket mit Bibliotheken und Beispielcode für die Bare-Metal-Entwicklung an. Die Entwicklung an der StarterWare-AM335X wurde am 12.07.2013, mit der letzten von TI veröffentlichten Version, eingestellt. Jedoch wird die Software auf der TI Webseite weiterhin als ACTIVE gelistet [48].

Weiterhin haben Freiwillige aus der Opensource-Community die Software unter dem Namen StarterWareFree geforkt und entwickeln diese weiter [35].

Neben ausführlichen Kommentaren an den APIs im Quelltext selbst, werden Starter- Ware und StarterWareFree mit einem Benutzerhandbuch im PDF-Format ausgeliefert.

Die StarterWareFree enthält einen Bootloader, der sich um das Bootstrapping kümmert, wobei dieser nicht benötigt wird, wenn man Code via JTAG aufspielt. In dem Fall kümmert sich CCS um die Hardwareinitialisierung.

Kriterium P6 Debugging-Mechanismen

Erfüllungsgrad: voll

Wie schon weiter oben bei Punkt Kriterium P4 erwähnt, hat das BBB eine JTAG- Schnittstelle, welche es in Kombination mit CCS erlaubt, Code direkt auf dem Chip zu debuggen.

Kriterium P7 Ausreichender Hauptspeicher

Erfüllungsgrad: voll

Das BBB ist mit 512MiB Hauptspeicher ausgestattet [11, Kap. 4.2].

Kriterium O1 Quelloffenheit

Erfüllungsgrad: voll

Da dieser SBC auf einer ARM-CPU basiert, steht auch hier quelloffene Toolchain [24] zur Verfügung. Der Quellcode der bereits genannnte StarterWare bzw. StarterWareFree ist ebenfalls frei verfügbar.

24 KAPITEL 4. AUSWAHLPROZESS 4.2. EVALUIERTE PLATTFORMEN

Kriterium O2 Lizenzkosten

Erfüllungsgrad: voll

Der Hersteller des SoC bietet eine auf Eclipse basierende Entwicklungsumgebung na- mens CCS an. Diese war bis einschließlich Version 6 kostenpflichtig, mit der Veröf- fentlichung der Version 7 hat TI jedoch auf ein kostenloses Lizensmodell umgestellt. Die derzeitig aktuelle Version ist 8 [15].

Kriterium O3 Einmalige Ausgaben pro Entwicklungsumgebung

Erfüllungsgrad: voll

Laut dem Heise.de Preisvergleichsportal, ist das BBB ab 54,09€ verfügbar [25].

Der Einzelpreis der benötigten JTAG-Pinleiste liegt derzeit bei 3,77€ [44].

Ein mit CCS kompatibler JTAG-Emulator XDS110 kostet laut Herstellerwebseite der- zeit 99,00 USD [57].

Kriterium O4 Laufende Kosten pro Semester

Erfüllungsgrad: voll

Außer den Anschaffungskosten für die Hardware fallen keine weiteren Kosten an.

Kriterium O5 Netzwerkschnittstelle vorhanden

Erfüllungsgrad: voll

Das BBB ist ab Werk mit einer Ethernet-Schnittstelle ausgestattet [11, Kap. 4.2]. iMX6 OpenRex

OpenRex ist ein quelloffener SBC der, wie der Raspberry Pi und das BeagleBone Black, eine ARM-CPU verwendet. Es wurde von der FEDEVEL für “Playing, Learning and Hacking” entwickelt [36] und kommt mit einer Vierkern-CPU die mit bis zu 1,2GHz getaktet ist und maximal 4GiB Hauptspeicher [36].

25 KAPITEL 4. AUSWAHLPROZESS 4.2. EVALUIERTE PLATTFORMEN

Kriterium P1 Dokumentation der CPU

Erfüllungsgrad: voll

Die Dokumentationen für die i.MX6Q-CPU [29], sowie die darin verwendeten ARM Cortex-A9-Kerne [13] sind frei verfügbar.

Kriterium P2 Dokumentation der Platine

Erfüllungsgrad: voll

Das Datenblatt des OpenRex ist frei verfügbar [30]. Außerdem ist der Platinenentwurf quelloffen, sodass alle relevanten Dokumente zum Nachbauen kostenlos imDown- loadbereich der Webseite [31] verfügbar sind.

Kriterium P3 Dokumentation der Entwicklungsumgebung

Erfüllungsgrad: voll

Es wird keine besondere IDE vorausgesetzt, sodass eine Beliebige benutzt werden kann, die die Toolchain des verwendeten Rahmenwerks unterstützt.

Als Toolchain eignet sich beispielsweise die schon mehrfach erwähnte ARM GCC- Toolchain.

Kriterium P4 Aufspielen von Code

Erfüllungsgrad: nicht

Im Datenblatt [30] ist keine direkte Schnittstelle zum Aufspielen von Code zu finden und gemäß Kapitel 1.3 kann der SBC nur von externen Speichermedien booten.

Kriterium P5 Vorhandenes Rahmenwerk

Erfüllungsgrad: nicht

In der Vergangenheit gab es ein kostenloses Software-Development-Kit (SDK) welches jedoch inzwischen nicht mehr verfügbar ist [28]. Inwieweit dieses dokumentiert war ist unbekannt und eine Alternative konnte nicht gefunden werden.

26 KAPITEL 4. AUSWAHLPROZESS 4.2. EVALUIERTE PLATTFORMEN

Kriterium P6 Debugging-Mechanismen

Erfüllungsgrad: teilweise

Das Datenblatt [30] beschreibt eine serielle Schnittstelle zum Debuggen, aber keinen OCD.

Kriterium P7 Ausreichender Hauptspeicher

Erfüllungsgrad: voll

Gemäß [30, Kap. 1.5] hat die kleinstmögliche Konfiguration des OpenRex 512MiB Hauptspeicher.

Kriterium O1 Quelloffenheit

Erfüllungsgrad: nicht

Wie bereits bei Kriterium P5 oben erwähnt, wird das vormals verfügbare Rahmen- werk nicht mehr angeboten und augenscheinlich ist auch kein Fork verfügbar.

Kriterium O2 Lizenzkosten

Erfüllungsgrad: voll

Außer den Anschaffungskosten für die Hardware fallen keine weiteren Kosten an.

Kriterium O3 Einmalige Ausgaben pro Entwicklungsumgebung

Erfüllungsgrad: voll

Der Preis für eine Platine mit Minimalausstattung ist auf der Herstellerwebseite mit 199,00 USD angegeben [53, Teilnummer iMX6-SBC-132111011], bei einer Stückzahl von eins bis neun.

Da das OpenRex keine OCD-Schnittstelle hat, muss hier auch kein separater Debugger beschafft werden, wodurch sich der Preis noch innerhalb der veranschlagten 240€ bewegt.

27 KAPITEL 4. AUSWAHLPROZESS 4.2. EVALUIERTE PLATTFORMEN

Kriterium O4 Laufende Kosten pro Semester

Erfüllungsgrad: voll

Außer den Anschaffungskosten für die Hardware fallen keine weiteren Kosten an.

Kriterium O5 Netzwerkschnittstelle vorhanden

Erfüllungsgrad: voll

Das OpenRex kommt ab Werk mit einer Ethernet-Schnittstelle [30, Kap. 1.5].

ODROID

ODROID der Firma Hardkernel co., Ltd. ist ebenfalls eine Familie von SBCs die auf ARM-CPUs aufbauen. Manche Modelle, wie beispielsweise das ODROID-XU4, basie- ren jedoch auf proprietären SoC-Plattformen, dessen Dokumentation nur unter ei- ner Non-Disclosure-Agreement (NDA) mit dem Hersteller eingesehen werden können. Diese Modelle werden in dieser Evaluation von vornherein ausgeschlossen. Hier wird exemplarisch das ODROID-C2 betrachtet (im Weiteren auch kurz als C2 bezeichnet).

Kriterium P1 Dokumentation der CPU

Erfüllungsgrad: voll

Die Dokumentationen des dem C2 verbauten Amlogic S905-SoC [43] und der darin verwendeten ARM Cortex-A53-Kerne [6] stehen frei zum Download verfügbar.

Kriterium P2 Dokumentation der Platine

Erfüllungsgrad: voll

Auf der Herstellerwebseite stehen Dokumentationen der Platine, bis hin zu vollstän- digen Schaltplänen, frei zum Download bereit [43].

28 KAPITEL 4. AUSWAHLPROZESS 4.2. EVALUIERTE PLATTFORMEN

Kriterium P3 Dokumentation der Entwicklungsumgebung

Erfüllungsgrad: voll

Es wird keine besondere IDE vorausgesetzt, sodass eine beliebige benutzt werden kann, die die Toolchain des verwendeten Rahmenwerks unterstützt.

Als Toolchain eignet sich beispielsweise die schon mehrfach erwähnte ARM GCC- Toolchain.

Kriterium P4 Aufspielen von Code

Erfüllungsgrad: nicht

Ähnlich wie beim Raspberry Pi, hat das ODROID-C2 zwar eine JTAG-Schnittstelle, aber die nötigen Pins sind auf GPIO-Pins mit mehreren Funktionen aufgelegt [43, Kap. 46].

Kriterium P5 Vorhandenes Rahmenwerk

Erfüllungsgrad: nicht

Es konnte kein Rahmenwerk für Bare-Metal-Programmierung auf der ODROID- Plattform gefunden werden.

Kriterium P6 Debugging-Mechanismen

Erfüllungsgrad: voll

Genau wie beim Pi kann hier einfach früh genug im Code die JTAG-Schnittstelle entsprechend konfiguriert werden, um sie für das Debuggen nutzbar zu machen.

Kriterium P7 Ausreichender Hauptspeicher

Erfüllungsgrad: voll

Gemäß Produktwebseite des Herstellers verfügt das C2 über 2GiB Hauptspeicher [34].

29 KAPITEL 4. AUSWAHLPROZESS 4.2. EVALUIERTE PLATTFORMEN

Kriterium O1 Quelloffenheit

Erfüllungsgrad: nicht

Kein Rahmenwerk vorhanden.

Kriterium O2 Lizenzkosten

Erfüllungsgrad: voll

Außer den Anschaffungskosten für die Hardware fallen keine weiteren Kosten an.

Kriterium O3 Einmalige Ausgaben pro Entwicklungsumgebung

Erfüllungsgrad: voll

Der Hersteller des ODROID-C2 bietet dieses für 46,00 USD auf seiner Webseite an [34].

Zusätzlich würden nochmal ca. 90 USD für einen JTAG-Debugger anfallen.

Kriterium O4 Laufende Kosten pro Semester

Erfüllungsgrad: voll

Außer den Anschaffungskosten für die Hardware fallen keine weiteren Kosten an.

Kriterium O5 Netzwerkschnittstelle vorhanden

Erfüllungsgrad: voll

Das verwendete S905-SoC hat eine integrierte Ethernet-Schnittstelle [43, Kap. 3.7].

Pine64

Das Pine64, entwickelt von der gleichnamigen Firma, wurde als Konkurrent zum Raspberry Pi entworfen [39] und hat eine entsprechend vergleichbare Ausstattung.

30 KAPITEL 4. AUSWAHLPROZESS 4.2. EVALUIERTE PLATTFORMEN

Kriterium P1 Dokumentation der CPU

Erfüllungsgrad: voll

Das Pine64-Board basiert auf dem Allwinner A64 SoC der Firma Allwinner Techno- logy [1], welches mit vier ARM Cortex-A53-Kernen [6] ausgestattet ist. Für beide sind ausführliche Datenblätter frei herunterladbar. Für das Allwinner A64 SoC gibt es außerdem ein Benutzerhandbuch [2], welches weiterführende Informationen zu Registerbelegungen, Schnittstellen zu Peripheriegeräten und dergleichen enthält.

Kriterium P2 Dokumentation der Platine

Erfüllungsgrad: voll

Schaltpläne, Pinbelegungen und dergleichen sind frei auf der Herstellerwebseite [40, Abschn. 5] verfügbar.

Kriterium P3 Dokumentation der Entwicklungsumgebung

Erfüllungsgrad: voll

Es wird keine besondere IDE vorausgesetzt, sodass eine beliebige benutzt werden kann, die die Toolchain des verwendeten Rahmenwerks unterstützt.

Als Toolchain eignet sich beispielsweise die schon mehrfach erwähnte ARM GCC- Toolchain.

Kriterium P4 Aufspielen von Code

Erfüllungsgrad: nicht

Gemäß dem Schaltplan (siehe PINE A64 512MB Rev B Board Schematic in [40, Abschn. 5]) sind zwar JTAG-Pins vorhanden, jedoch auf die Kontakte des SD- Kartenlesers gelegt. Dies deutet darauf hin, dass die Kontakte der JTAG-Schnittstelle, wie auch beim Raspberry Pi, mehrfach belegt und dadurch nicht direkt nutzbar sind. Da das System keinen internen Massenspeicher hat und durch die Mehrfachbelegung die Nutzung von JTAG und SD-Karten sich gegenseitig ausschließen, müsste zum Aufspielen von Code eine SD-Karte verwendet werden.

31 KAPITEL 4. AUSWAHLPROZESS 4.2. EVALUIERTE PLATTFORMEN

Kriterium P5 Vorhandenes Rahmenwerk

Erfüllungsgrad: nicht

Es konnte kein Rahmenwerk für Bare-Metal-Programmierung auf der Pine64- Plattform gefunden werden.

Kriterium P6 Debugging-Mechanismen

Erfüllungsgrad: teilweise

Wie beim Kriterium P4 bereits beschrieben, ist die JTAG-Schnittstelle effektiv nicht nutzbar, sodass im besten Fall Textausgaben wie serieller Schnittstelle zum Debuggen genutzt werden können.

Kriterium P7 Ausreichender Hauptspeicher

Erfüllungsgrad: voll

Das Pine64 kommt in mehreren Varianten, von denen bereits die kleinste (PINE A64 512MB Rev B) 512MiB Hauptspeicher aufweist [40, Abschn. 3.3].

Kriterium O1 Quelloffenheit

Erfüllungsgrad: nicht

Es konnte kein Rahmenwerk gefunden werden.

Kriterium O2 Lizenzkosten

Erfüllungsgrad: voll

Außer den Anschaffungskosten für die Hardware fallen keine weiteren Kosten an.

32 KAPITEL 4. AUSWAHLPROZESS 4.3. ERGEBNIS

Kriterium O3 Einmalige Ausgaben pro Entwicklungsumgebung

Erfüllungsgrad: voll

Die 512MiB-Variante des Pine64 ist auf der Herstellerwebseite mit einem Preis von 15 USD gelistet [38].

Da die JTAG-Schnittstelle effektiv nicht genutzt werden kann, fallen keine weiteren Kosten für einen Debugger an.

Kriterium O4 Laufende Kosten pro Semester

Erfüllungsgrad: voll

Außer den Anschaffungskosten für die Hardware fallen keine weiteren Kosten an.

Kriterium O5 Netzwerkschnittstelle vorhanden

Erfüllungsgrad: voll

Die Platine kommt ab Werk mit einer Ethernet- sowie einer WLAN-Schnittstelle [40, Abschn. 4.3].

4.3. Ergebnis

An der Tabelle 4.12 erkennt man bereits auf den ersten Blick, dass das BBB die ein- zige Plattform ist, die alle Kriterien voll erfüllt und somit augenscheinlich der beste Kandidat ist. Das liegt bei den größeren SBCs zumeist daran, dass diese offenbar vor allem für die Entwicklung auf Basis von Linux oder einem anderen etablierten Be- triebssystem gedacht sind. Dadurch sind dann entweder keine Rahmenwerke vorhan- den, wie bei OpenRex, ODROID und Pin64, oder es wird davon ausgegangen, dass von einem regulären Massenspeicher gebootet wird und die Software auf dem Gerät entwickelt wird, wie beim Raspberry Pi. Im Gegensatz dazu wären einige MCUs, wie das STM32F4-Discovery, prinzipiell sehr gut geeignet, jedoch stellen diese nicht die angeforderten Ressourcen zur Verfügung.

Es ist auch auffällig, dass einige der angesetzten Kriterien keinen Einfluss auf dieAus- wahl hatten, da keine Kandidaten gefunden wurden, die diese nicht erfüllen. Beispiels- weise wurde bei der Recherche keine Plattform gefunden, bei der laufende Kosten für Lizenzen oder dergleichen entstehen. Ob dies daran liegt, dass es solche Systeme nicht

33 KAPITEL 4. AUSWAHLPROZESS 4.3. ERGEBNIS

Tabelle 4.12.: Erfüllungsgrade der Kriterien auf einen Blick

Kriterium STM32F4 Raspberry Pi BBB OpenRex ODROID Pine64 P1 ✓ ✓ ✓ ✓ ✓ ✓ P2 ✓ ✓ ✓ ✓ ✓ ✓ P3 ✓ ✓ ✓ ✓ ✓ ✓ P4 ✓ - ✓ - - - P5 ✓ ✓ ✓ - - - P6 ✓ ✓ ✓ • ✓ • P7 • ✓ ✓ ✓ ✓ ✓ O1 ✓ ✓ ✓ - - - O2 ✓ ✓ ✓ ✓ ✓ ✓ O3 ✓ ✓ ✓ ✓ ✓ ✓ O4 ✓ ✓ ✓ ✓ ✓ ✓ O5 • ✓ ✓ ✓ ✓ ✓ Legende: ✓: voll • : teilweise - : nicht gibt, oder diese einfach beispielsweise durch schlecht gewählte Suchkriterien nicht aufgefunden wurden, kann an dieser Stelle nicht mit Sicherheit gesagt werden.

Den Kriterien entsprechend, wurde eine Entwicklungsumgebung auf Basis des BBB beschafft und im Folgenden auf seine Realtime-Eigenschaften untersucht. Sollten die- se nicht ausreichend gegeben sein, wird ggf. eine der weniger geeigneten Plattformen in Betracht gezogen und ebenfalls getestet.

34 5. Realtime-Eigenschaften

In diesem Abschnitt werden die Realtime-Eigenschaften der ausgewählten Plattform betrachtet. Dazu wurde ein Versuchsaufbau entworfen, bei dem durch verschiedene Scheduling-Techniken der Pegel eines GPIO-Pins in Intervallen verändert wird und die so entstehende Wellenform untersucht werden kann. Das Ziel dabei war, zu ermit- teln, ob bzw. wie weit die gemessenen Intervalle zwischen den Flanken auf dem Aus- gangssignal mit den von der Software angesetzten Intervallen abweichen und dadurch Rückschlüsse auf dessen Eignung für Realtime-Anwendungen führen zu können.

5.1. Versuchsaufbau

Um die Eignung für Realtime-Anwendungen zu testen, wurde zwei als Bare-Metal- Anwendung implementierte Scheduler mit dem auf dem BBB vorinstallierten Linux- System verglichen. Dabei wurde jeweils ein GPIO-Pin für die Ausgabe konfiguriert, dessen Zustand in regelmäßigen Abständen invertiert wurde. Ziel war es, eine mög- lichst gleichmäßige und stabile Wellenform zu erzeugen. Die einzuhaltenden Dead- lines sind in diesem Fall die Zeitpunkte, zu denen auf dem Ausgabepin eine Messflanke erwartet wird.

Um die Wahrscheinlichkeit von Messfehlern zu reduzieren, wurden zwei unterschied- liche Messgeräte verwendet. Ein Logic Analyzer und ein Oszilloskop.

Kooperativer periodischer Bare-Metal-Scheduler

Die erste Implementierung setzt im Kern auf einen kooperativen, periodischen Scheduler, der als Bare-Metal-Programm implementiert wurde. Der Scheduler macht keine Kontextwechsel für die auszuführenden Tasks, sondern führt einfach nur C-Funktionen aus. Eventuell benötigte persistente Kontextdaten für die jeweiligen Tasks müssen von diesen, beispielsweise in globalen Variablen, selbst verwaltet wer- den. Im in Abbildung 5.2 zu sehenden Beispiel wird der Task-Kontext als void-Zeiger übergeben, der beliebige Datenstrukturen enthalten kann. In diesem Fall ist dies ein Zeiger auf den von allen Tasks gemeinsam genutzten Zustand des Ausgabepins.

35 KAPITEL 5. REALTIME-EIGENSCHAFTEN 5.1. VERSUCHSAUFBAU

20ms

Major-Frame

Minor-Frame 1 Minor-Frame 2 Minor-Frame 3 Minor-Frame 4

5ms

Abbildung 5.1.: Frame-basierter Scheduler

1 void gpioTask(void **context) { 2 gpio_toggle_state_t *c = (gpio_toggle_state_t *)(*context); 3 c->state = !c->pin_state; 4 gpio_pin_write(pin, c->pin_state); 5 }

Abbildung 5.2.: Testcode für kooperativen Scheduler

Für die periodische Ausführung von Tasks arbeitet der Scheduler dabei nach einem so- genannten Frame-basierten Modell. Dabei wird ein festes Basisintervall festgelegt, der sogenannte Major-Frame, der gleichteilig in sogenannte Minor-Frames zerlegt wird. Ein Minor-Frame stellt dabei die kürzeste Zeiteinheit dar, für die ein Task die CPU erhalten kann und der Major-Frame die längste Zeit, die ein Task warten muss, bis er wieder die CPU erhält. Soll ein Task länger laufen, als ein Minor-Frame, können mehrere Minor-Frames für einen Task alloziert werden. Soll ein Task in kürzeren Inter- vallen laufen, als der Major-Frame lang ist, so kann dieser nicht direkt hintereinander liegende Minor-Frames zugeteilt werden. Bei einem oder mehreren zusammenhängen- den Minor-Frames, die demselben Task zugeordnet sind, redet man auch von einer Partition.

Für den Versuchsaufbau wurde eine Major-Frame-Länge von 20ms gewählt, welcher wiederum auf vier Minor-Frames aufgeteilt wurde (veranschaulicht in Abbildung 5.1).

Für die Zeitmessung wird ein DMTimer des BBB verwendet [3, Kap. 20], welcher mit 15 2 Hz ein 32Bit-Register inkrementiert. Somit entsprechen 20ms genau 656 Zeitgeber- Impulsen, sodass jeder Minor-Frame genau 164 Impulse lang ist. Hier ist es wichtig, dass die Länge des Major-Frames genau durch die Anzahl der Minor-Frames teilbar ist, da die Minor-Frames ansonsten nicht dieselbe Länge haben, was die Messergebnisse verfälschen würde.

Es werden vier Partitionen zu je einem Minor-Frame Länge definiert. Jeder Partiti- on ist jeweils ein Task zugeordnet, der den Zustand des Ausgabepins invertiert. Im Idealfall sollte somit alle 5ms eine Flanke zu messen sein.

36 KAPITEL 5. REALTIME-EIGENSCHAFTEN 5.1. VERSUCHSAUFBAU

Präemptiver periodischer Bare-Metal-Scheduler

Dieser Versuchsaufbau erweitert den oben beschrieben Frame-basierten Scheduler um echte Kontextwechsel und Präemption durch periodische Interrupts, basierend auf demselben DMTimer wie oben. Insbesondere hat jeder Task in dieser Implemen- tierung seinen eigenen Stack, sodass zu dem Task gehörige Daten nicht mehr in globa- len Datenstrukturen oder dergleichen verwaltet werden müssen. Gemeinsam genutzte Datenstrukturen, wie in diesem Fall die Variable, die den aktuellen Zustand des Aus- gabepins enthält, müssen hier jedoch auf anderem Wege zugänglich gemacht werden. In diesem Fall wurde einfach eine globale Variable genutzt.

Die Partitionierung bleibt identisch, jedoch wird in jeder Partition anstatt ei- nes einzelnen Tasks ein weiterer Scheduler eingesetzt. Dies ist angelehnt an den Luftfahrt-Standart ARINC 653, der es erlaubt, mehrere sicherheitskritische Realtime-Anwendungen auf derselben Hardware zu betreiben, sofern die für diese bereitgestellten Ressourcen so partitioniert sind, dass sie sich nicht gegenseitig beeinflussen können.

Die inneren Scheduler sind dabei Instanzen eines auf statischen Prioritäten basierten kooperativen nicht-periodischen Schedulers. Dieser bietet Funktionen zum Erstellen von Warteschlangen für beliebig definierbare Ereignisse, eine Zeit-basierte Warte- schlange, sowie Nachrichten-basierte Warteschlangen für IPC. Diese sind dabei für jede Scheduler-Instanz ebenfalls instanziiert, sodass es keine Wechselwirkungen zwi- schen Partitionen gibt. Um auf Ereignisse wartende Tasks aufzuwecken, läuft in jeder Partition ein Verwaltungs-Task mit der niedrigsten Priorität, der somit immer dann aktiv wird, wenn alle anderen Tasks schlafen.

Innerhalb jeder Partition hat der jeweilige Task zum Umschalten des Ausgabepins im- mer allein die höchste Priorität. Um gewährleisten zu können, dass diese Tasks genau einmal pro Partition rechenbereit werden, hat der Scheduler einen internen Zähler für die Anzahl der durchlaufenen Major-Frames und eine Ereigniswarteschlange, mit der ein Task sich bis zur nächsten Inkrementierung des Zählers und somit bis zum nächsten Major-Frame schlafen legen kann.

In Abbildung 5.3 ist der ausgeführte Code zu sehen. Das Array currentPartition->cndArray ist dabei eine Liste von vordefinierten Ereignissen, auf die ein Task warten kann. Das erste Element ist in diesem Fall ein Zeiger auf eine Funktion, die prüft, ob der nächste Zyklus begonnen hat. waitCondition() ist eine Funktion des Schedulers, die den Task schlafen legt, bis die übergebene Funktion 1 zurückgibt.

Hier ist zu beachten, dass beim Wechseln der Partition durch den präemtiven äußeren Scheduler zum jeweils zuletzt aktiven Task der nächsten Partition gewechselt wird. Das hat zur Folge, dass der innere Scheduler der jeweiligen Partition nicht direkt zu Beginn der Partition aktiv wird, sondern erst wenn der noch aktive Task die CPU

37 KAPITEL 5. REALTIME-EIGENSCHAFTEN 5.1. VERSUCHSAUFBAU

1 void gpioTask(void){ 2 while (1) { 3 pin_state = !pin_state; 4 gpio_pin_write(pin, pin_state); 5 waitCondition(currentPartition->cndArray[0]); 6 } 7 }

Abbildung 5.3.: Testcode für präemtiven Scheduler

abgibt. Dadurch kann nicht garantiert werden, dass der Task zum Umschalten des Aus- gabepins sofort zu Beginn der Partition die CPU erhält. Der Vorteil daran ist, dass in diesem Modell keine Mechanismen für das Schützen kritischer Bereiche bereitgestellt werden müssen, was den Implementierungsaufwand gering hält. Ein weiterer Faktor für den Implementierungsaufwand ist hier, dass der generische Interrupt-Handler im verwendeten Rahmenwerk angepasst werden musste, um überhaupt Kontextwechsel aus einer Interrupt heraus zu erlauben, und dies die einfachste Variante darstellt.

Linux

Als Vergleich zu den Bare-Metal-Varianten wurde ein Testkandidat auf Basis des auf dem BBB vorinstallierten Linux-Systems entwickelt. Um die Vergleichbarkeit zu ge- währleisten, wurden die GPIO-Pins hierzu direkt über die jeweiligen in den Speicher abgebildeten Register angesteuert (mithilfe einer entsprechenden C-Bibliothek [9]), anstatt die im Linux-Kernel integrierten Treiber zu verwenden. Dies erlaubt es Over- head zu vermeiden, der beispielsweise durch das Absteigen durch die Abstraktions- schichten des virtuellen Dateisystems entsteht und so die Messergebnisse verfälschen könnte. Der unterliegende Scheduler ist dabei der Completely-Fair-Scheduler (CFS) [37] des Linux-Kernels.

Der CFS ist nicht für Realtime-Anwendungen ausgelegt und stellt stattdessen Fair- ness in den Vordergrund. Dementsprechend wird bei diesem Test nicht erwartet, dass Deadlines zuverlässig eingehalten werden können. Stattdessen soll dieser Test als Vergleich zu den anderen dienen, um beispielsweise Eigenarten der Hardware aufzuzeigen. Da der CFS gut verstanden und schon lange in Benutzung ist, ist es un- wahrscheinlich, dass Eigenartigkeiten bei den Messungen auf Implementierungsfehler zurückzuführen sind, wenn sie bei allen drei Modellen auftreten.

Der relevante Ausschnitt aus der Implementierung ist in Abbildung 5.4 zu sehen.

38 KAPITEL 5. REALTIME-EIGENSCHAFTEN 5.2. AUSWERTUNG DER ERGEBNISSE

1 unsigned int pin_state = 0; 2 while (1) { 3 if (pin_state) { 4 pin_high(8, 7); 5 } else { 6 pin_low(8, 7); 7 } 8 pin_state = !pin_state; 9 usleep(5000); 10 }

Abbildung 5.4.: Test-Code für Linux

5.2. Auswertung der Ergebnisse

Mit den oben beschriebenen Versuchsaufbauten wurden jeweils mehrere Messungen durchgeführt. Wie bereits erwähnt, wurden zwei unterschiedliche Messmethoden ein- gesetzt, um die Wahrscheinlichkeit von Messfehlern zu reduzieren. Zum einen wurde ein digitales Oszilloskop verwendet und auf Video aufgezeichnet, zum anderen wurde ein Logic Analyzer mit einer Sample-Rate von 20µs eingesetzt, dessen Messungen in Comma-Separated-Values (CSV) abgespeichert und ausgewertet werden können.

Bei den Punktdiagrammen, die für die Abbildung der vom Logic Analyzer erfassten Messwerte verwendet werden, ist die rote Linie jeweils das arithmetische Mittel und die blaue Linie der Median. Gemessen wurden die Intervalle zwischen Flanken, was bei einer gleichmäßigen Frequenz einer Halbschwingung entspricht. Es wurden über einen Zeitraum von mehreren Minuten jeweils zehn Messungen zu zufälligen Zeit- punkten durchgeführt und die Ergebnisse aneinandergereiht. Parallel dazu wurde das Oszilloskop beobachtet und per Video aufgezeichnet.

Kooperativer periodischer Bare-Metal-Scheduler

Dieser Scheduler erzeugt seine Flanken gemäß beider Messgeräte mit sehr genauen Abständen. Über einen Messzeitraum von 10 Minuten konnten auf dem Oszilloskop keine größeren Ausreißer der Wellenform beobachtet werden (siehe Abbildung 5.5 für eine exemplarische Darstellung) und auch mehrere, in Abbildung 5.6 zusammen- gefasste, Messungen mit dem Logic Analyzer konnten nur geringe Abweichungen der Intervalle zwischen Messflanken erkennen.

Wenn nach dem Invertieren des Ausgabepins weitere Aktionen oder Berechnungen ausgeführt werden, hat dies keinen Einfluss auf die Messergebnisse, sofern diese vor Ablauf der Partition terminieren.

39 KAPITEL 5. REALTIME-EIGENSCHAFTEN 5.2. AUSWERTUNG DER ERGEBNISSE

Abbildung 5.5.: Oszilloskopmessungen - Kooperativer Scheduler

5.1

5 ms

4.9

10 20 30 40 50 60 70 80 90 100 110 Nr. Messung

Abbildung 5.6.: Logic-Analyzer-Messungen - Kooperativer Scheduler

40 KAPITEL 5. REALTIME-EIGENSCHAFTEN 5.2. AUSWERTUNG DER ERGEBNISSE

5.1

5 ms

4.9

10 20 30 40 50 60 70 80 90 100 110 Nr. Messung

Abbildung 5.7.: Logic-Analyzer-Messungen - Präemptiver Scheduler

Präemptiver periodischer Bare-Metal-Scheduler

Wenn in jeder Partition kein anderer Task läuft, außer dem erforderlichen Verwaltungs-Task und dem Task zum Umschalten des Ausgabepins, dann kann man an den in Abbildung 5.7 gezeigten Messergebnissen erkennen, dass es zum einen mehr Jitter als beim rein kooperativen Scheduler gibt und zum anderen Median und arithmetisches Mittel erkennbar über der 5ms-Marke liegen. Dies ist dadurch zu erklären, dass die Partitionen mit hoher Wahrscheinlichkeit im jeweili- gen Verwaltungs-Tasks unterbrochen wurden und dieser erst von sich aus die CPU abgeben muss, bevor der Task zum Umschalten des Ausgabepins dran kommt.

Dieses Verhalten ändert sich grundsätzlich nicht durch das Einreihen weiterer, nieder- priorer Tasks in den jeweiligen Partitionen. Es verändern sich nur die Abweichungen, abhängig davon, in welchen Abständen diese Tasks die CPU abgeben.

Linux

Es wurden zwei Vergleichsmessungen mit Linux durchgeführt. Zum einen mit dem System das unter möglichst geringer Last steht, also auf dem nur die Prozesse lau- fen, die vom System selbst gestartet wurden, sowie einer über eine SSH-Verbindung gestartete Shell und das Testprogramm. Bei der zweiten Messung wurde das System mithilfe der Software stress1 unter Last gesetzt.

Wie man an Abbildung 5.8 und Abbildung 5.10 erkennen kann, erzeugt der Linux- Scheduler ohne Last Flanken in sehr präzisen Abständen, mit Ausreißern die nur geringfügig über denen des periodischen Schedulers liegen. Allerdings ist auch zu erkennen, dass es eine mehr oder weniger konstante Abweichung von etwa 0.86ms 1https://people.seas.harvard.edu/~apw/stress/

41 KAPITEL 5. REALTIME-EIGENSCHAFTEN 5.2. AUSWERTUNG DER ERGEBNISSE

5.1

5 ms

4.9

10 20 30 40 50 60 70 80 90 100 110 Nr. Messung

Abbildung 5.8.: Logic-Analyzer-Messungen - Linux - Idle

6

5.5

5 ms

4.5

4 10 20 30 40 50 60 70 80 90 100 Nr. Messung

Abbildung 5.9.: Logic-Analyzer-Messungen - Linux - Unter Last vom angesetzten 5ms-Intervall gibt. Dies ist vermutlich dadurch zu erklären, dass das Scheduling-Subsystem des Linux-Kernels vergleichsweise komplex ist und dadurch mehr Overhead entsteht, bevor ein rechenbereit gewordener Prozess tatsächlich die CPU erhält.

Große Abweichungen vom erwarteten 5ms-Intervall entstehen erst, wenn das System unter Last steht (siehe Abbildung 5.9 und Abbildung 5.11). Dabei ist auch aufgefallen, dass die schlimmsten Ausreißer mit dem Logic Analyzer nur schwer oder gar nicht erfasst werden können. Da der Logic Analyzer nur nach dem Auftreten einer Flan- ke, bzw. eines konfigurierbaren Flanken-Musters auf den Messleitungen, eine feste Anzahl Samples macht, können extreme Ausreißer, wie in Abbildung 5.12 zu sehen sind, nur mit Glück erfasst werden, wenn diese kurz nach der auslösenden Flanke passieren.

42 KAPITEL 5. REALTIME-EIGENSCHAFTEN 5.2. AUSWERTUNG DER ERGEBNISSE

Abbildung 5.10.: Oszilloskopmessungen - Linux - Idle

Abbildung 5.11.: Oszilloskopmessungen - Linux - Unter Last (1)

43 KAPITEL 5. REALTIME-EIGENSCHAFTEN 5.3. VERSUCHSFAZIT

Abbildung 5.12.: Oszilloskopmessungen - Linux - Unter Last (2)

5.3. Versuchsfazit

Wie erwartet, sind die Bare-Metal-Varianten im Allgemeinen zuverlässiger beim Ein- halten von Deadlines als der Linux-CFS. Überraschenderweise ist der CFS trotzdem relativ genau, sofern keine anderen Prozesse aktiv sind, aber sobald das System un- ter Last steht, kann das Einhalten von Deadlines, wie erwartet, nicht mehr garantiert werden.

Zwischen den beiden getesteten Bare-Metal-Varianten kann man sehr schön den Trade-Off zwischen Flexibilität und dem präziseren Einhalten von Deadlines erken- nen, der auch schon im Grundlagenkapitel aufgefasst wurde. Durch den Einsatz der inneren Scheduler verliert man Genauigkeit, jedoch kann man durch gute Planung der in den einzelnen Partitionen laufenden Tasks trotzdem sinnvolle Genauigkeiten einhalten. Ob dies ausreichend für die jeweilige Anwendung ist, kommt natürlich auf die jeweiligen Umstände und Anforderungen an.

Bei allen Testdurchläufen war immer ein gewisser Jitter zu erkennen. Dies ist mög- licherweise durch Wechselwirkungen innerhalb der Hardware zu erklären. Beispiels- weise werden die GPIO-Pins intern mit einem Takt von 200MHz aktualisiert (siehe L4_PER_CLK in [3, S. 1225]), sodass hier eine Varianz von 5ns entstehen kann. Weitere solcher Effekte könnten aufeinander aufbauen und so die gemessenen Abweichungen erklären, mit Sicherheit kann dies jedoch an dieser Stelle nicht gesagt werden.

44 KAPITEL 5. REALTIME-EIGENSCHAFTEN 5.3. VERSUCHSFAZIT

Insgesamt konnte gezeigt werden, dass das BBB sich durchaus für die Entwicklung von Realtime-Anwendungen eignet, sofern der scheinbar immer vorhandene Jitter nicht zu groß für den jeweiligen Anwendungsfall ist. Für den Einsatz in einer Lehrveransta- lung, bei der es primär um die Vermittlung der unterliegenden Konzepte geht, sollte dies der Fall sein.

45 6. Fazit und Ausblick

Ziel der Arbeit war es, eine Plattform zu finden, auf der im Rahmen einer Lehrver- anstaltung mit vertretbarem Aufwand Bare-Metal- und insbesondere auch Realtime- Anwendungen implementiert werde können.

Bei der Auswahl der infrage kommenden Kandidaten wurde dabei schnell klar, dass auf dem Markt verfügbare SBCs hauptsächlich für die Entwicklung von eingebetteten Anwendungen auf Basis etablierter Betriebssysteme, wie beispielsweise Linux, ausge- legt sind. Für die Bare-Metal-Programmierung relevante Aspekte wurden bei diesen Plattformen gar nicht oder eher hintergründig bedacht. Wären die Anforderungen an die verfügbaren Ressourcen weniger streng gewesen, wären tatsächlich auf Mikrocon- trollern basierte Plattform am besten geeignet, da diese generell für hardwarenahe Programmierung ausgelegt sind und Betriebssysteme wie Linux gar nicht auf diesen laufen.

Eine Annahme, die schon bei der Aufstellung der Kriterien stark durchscheint, war, dass es kommerzielle Plattformen mit zugehörigen Entwicklungsumgebungen für die- sen Zweck gibt. Überraschenderweise wurde bei der Recherche keine solche Platt- form gefunden. Ob dies an schlechten Suchkriterien oder anderen Gründen liegt ist leider an dieser Stelle nicht klar. Da insbesondere die Entwicklung von Hard-Realtime- Anwendungen immer sehr stark mit der verfügbaren Hardware zusammenhängt, wä- re beispielsweise denkbar, dass solche Systeme zusammen meist mit spezialisierter Hardware entwickelt werden, sodass eine allgemeine Entwicklungsumgebung, mit Hardware, Rahmenwerk usw., nicht sinnvoll umsetzbar ist.

Erfreulicherweise konnte dennoch ein größerer SBC gefunden werden, welcher den Anforderungen entspricht. Im Vergleich mit anderen für Linux ausgelegte Plattfor- men ist das BBB relativ ressourcenschwach, aber für den Anwendungszweck mehr als ausreichend. Was nicht gefordert war, aber vielleicht dennoch wünschenswert gewe- sen wäre, war eine Mehrkern-CPU, die das BBB leider nicht aufweist. Dies hätte es ermöglicht in einer späteren Iteration oder weiterführenden Version der geplanten Lehrveranstaltung auch Aspekte echter Parallelität und den zugehörigen Problemati- ken zu behandeln.

Die durchgeführten Messungen haben zudem gezeigt, dass das BBB nicht nur generell für Bare-Metal-Programmierung geeignet ist, sondern auch für Realtime- Anwendungen. Trotz eines scheinbar inhärenten Jitter, zumindest bei der Ausgabe

46 KAPITEL 6. FAZIT UND AUSBLICK via GPIO, können Deadlines im Millisekundenbereich zuverlässig eingehalten werden.

Weiterführende Arbeiten könnten darauf hinarbeiten, Grundlagen für die geplante Lehrveranstaltung zu schaffen, beispielsweise indem ein sehr minimales Realtime- System geschaffen wird, auf dem dann weiter aufgebaut werden kann. Ein weiterer denkbarer Ansatz wäre, die auf dem BBB verbauten PRUs darauf zu untersuchen, inwiefern diese sich dazu nutzen ließen, Konzepte von Mehrkernsystemen im Kontext einer Lehrveranstaltung zu betrachten ggf. in Verbindung mit der Suche nach einer alternativen Plattform, die eine echte Mehrkern-CPU aufweist.

47 Anhänge

48 A. Abbildungsverzeichnis

5.1. Frame-basierter Scheduler ...... 36

5.2. Testcode für kooperativen Scheduler ...... 36

5.3. Testcode für präemtiven Scheduler ...... 38

5.4. Test-Code für Linux ...... 39

5.5. Oszilloskopmessungen - Kooperativer Scheduler ...... 40

5.6. Logic-Analyzer-Messungen - Kooperativer Scheduler ...... 40

5.7. Logic-Analyzer-Messungen - Präemptiver Scheduler ...... 41

5.8. Logic-Analyzer-Messungen - Linux - Idle ...... 42

5.9. Logic-Analyzer-Messungen - Linux - Unter Last ...... 42

5.10.Oszilloskopmessungen - Linux - Idle ...... 43

5.11.Oszilloskopmessungen - Linux - Unter Last (1) ...... 43

5.12.Oszilloskopmessungen - Linux - Unter Last (2) ...... 44

49 B. Tabellenverzeichnis

3.1. Betriebssysteme in der Lehre an US-Hochschulen. [4] ...... 6

4.1. Erfüllungsgrade für Dokumentationen ...... 10

4.2. Erfüllungsgrade für das Aufspielen von Code ...... 11

4.3. Erfüllungsgrade für Rahmenwerk ...... 12

4.4. Erfüllungsgrade für Debugging-Mechanismen ...... 12

4.5. Erfüllungsgrade für Ausreichender Hauptspeicher ...... 13

4.6. Erfüllungsgrade für Quelloffenheit ...... 14

4.7. Erfüllungsgrade für Lizenzkosten ...... 14

4.8. Erfüllungsgrade für Einmalige Ausgaben ...... 15

4.9. Erfüllungsgrade für laufende Kosten ...... 15

4.10.Erfüllungsgrade für Netzwerkschnittstelle ...... 16

4.11.Auswahlkriterien auf einen Blick ...... 16

4.12.Erfüllungsgrade der Kriterien auf einen Blick ...... 34

50 C. Glossar

Compiler-Backend Das Backend eines Compilers ist zuständig für das Generieren von Code. Im Gegensatz zum Backend stehen das Frontend, welches eine Hochspra- che parst und meist in ein internes Zwischenformat umwandelt und das Midd- leend, welches unter anderem Optimierungen an diesem Zwischenformat vor- nimmt. 2

Cross-Compiler Ein Cross-Compiler ist ein Compiler, der unter einer Architektur läuft (z.B. x86) aber Programmcode für eine andere Architektur übersetzt (z.B. ARM). 3 embedded-MultiMediaCard Ein Standard für eingebetten Massenspeicher. Standar- tisiert durch die JEDEC Solid State Technology Association unter der Nummer JESD84-B51. 53

Jitter Als Jitter bezeichnet man zeitliche Abweichungen vom erwarteten periodi- schen Auftreten eines Ereignisses, wie beispielsweise einer Messflanke. 41, 44– 46

Kontext Als den Kontext eines Tasks oder Prozesses bezeichnet man die Informatio- nen, die für dessen Ausführung benötigt werden. Auf der untersten Ebene um- fasst dies beispielsweise benutzerdefinierbare Register, den Program-Counter, die Rücksprungadresse der aktuellen Prozedur, den Stack-Pointer usw. 3, 35, 37, 38

Memory-Management-Unit Eine Prozessorkomponente die virtuelle auf physikali- sche Speicheradressen abbildet. 53

Micro-Controller-Unit Ein Single-Board-Computer auf Basis eines Mikrocontrollers. 2, 53

Single-Board-Computer Ein Kleincomputer, bei dem sich alle Komponenten, inklusi- ve verschiedener Peripheriegeräte und Schnittstellen, auf einer einzigen Platine befinden. ii, 54

51 Glossar Glossar

System-on-a-Chip Ein Kleincomputer, bei dem diverse Komponenten und Periphe- riegeräte auf einem Chip integriert sind. ii, 54

Systemaufruf Im Englischen auch System-Call genannt, sind dies Funktionen, die vom Betriebssystem bereitgestellt werden um auf von diesem verwaltete Ressourcen zuzugreifen. Beispiele hierfür sind open(), close(), read() und write() für den Zugriff auf Dateien unter Linux. 3, 4

Toolchain Als Toolchain im Kontext der Softwareentwicklung bezeichnet man eine Sammlung von Werkzeugen, die für diese benötigt werden. Also z.B. Compiler, Linker, Debugger, etc. 10, 13, 17, 19, 20, 23, 24, 26, 29, 31

52 D. Abkürzungen und Akronyme

API Application-Programming-Interface 2, 24

BBB BeagleBone Black 22–25, 33–36, 38, 45–47

CCS Code Composer Studio 23–25

CFS Completely-Fair-Scheduler 38, 44

CSV Comma-Separated-Values 39 eMMC embedded-MultiMediaCard 53, Glossar: embedded-MultiMediaCard

GCC GNU-Compiler-Collection 18, 20, 26, 29, 31

GDB GNU-Debugger 3

GPIO General Purpose Input/Output 20, 29, 35, 38, 44, 47

HAL Hardware-Abstraction-Layer 2

HRTOS Hard-Realtime-Operating-System 1, 4, 6

IDE Integrated-Development-Environment 18, 20, 26, 29, 31

IPC Inter-Process-Communication 1, 2, 37

ISR Interrupt-Service-Routine 3, 4

JTAG Joint Test Action Group 3, 17, 23

MCU Micro-Controller-Unit 2, 12, 17, 33, 53, Glossar: Micro-Controller-Unit

MMU Memory-Management-Unit 53, Glossar: Memory-Management-Unit

NDA Non-Disclosure-Agreement 28

53 Abkürzungen und Akronyme Abkürzungen und Akronyme

OCD On-Chip-Debugger 3, 11, 18, 27

PRU Programmable-Realtime-Unit 22, 47

RTOS Realtime-Operating-System 4, 7

SBC Single-Board-Computer ii, 2, 9, 10, 17, 19, 22, 24–26, 28, 33, 46, 54, Glossar: Single-Board-Computer

SDK Software-Development-Kit 26

SoC System-on-a-Chip ii, 2, 9, 23–25, 28, 30, 31, 54, Glossar: System-on-a-Chip

SPI Serial-Peripheral-Interface 19

TI Texas Instruments 22–25

54 E. Literaturverzeichnis

[1] Allwinner A64 Datasheet. Rev. 1.1. Allwinner Technology Co. Ltd. 2015-06-26. url: http://files.pine64.org/doc/datasheet/pine64/A64_Datasheet_V1. 1.pdf (besucht am 2018-11-28). [2] Allwinner A64 User Manual. Rev. 1.0. Allwinner Technology Co. Ltd. 2015-04-30. url: http : / / files . pine64 . org / doc / datasheet / pine64 / Allwinner_A64_User_Manual_V1.0.pdf (besucht am 2018-11-28). [3] AM335x and AMIC110 Sitara™ Processors Technical Reference Manual. SPRUH73P. Rev. P. Texas Instruments. 2017-3. url: http : / / www . ti . com/lit/ug/spruh73p/spruh73p.pdf (besucht am 2018-08-14). [4] Charles L. Anderson und Minh Nguyen. “A Survey of Contemporary Instructio- nal Operating Systems for Use in Undergraduate Courses”. In: J. Comput. Sci. Coll. 21.1 (2005-10), S. 183–190. issn: 1937-4771. url: http://dl.acm.org/ citation.cfm?id=1088791.1088822 (besucht am 2018-12-21). [5] K. R. Apt, N. Francez und S. Katz. “Appraising Fairness in Distributed Langua- ges”. In: Proceedings of the 14th ACM SIGACT-SIGPLAN Symposium on Princi- ples of Programming Languages. POPL ’87. Munich, West Germany: ACM, 1987, S. 189–198. isbn: 0-89791-215-2. doi: 10.1145/41625.416421. [6] ARM® Cortex®-A53 MPCore Processor - Technical Reference Manual. ARM DDI 0500G. Rev. r0p4. ARM. 2016-02-08. url: https : / / developer . arm . com / docs/ddi0500/g (besucht am 2018-08-15). [7] ARM® Cortex®-M4 Processor - Technical Reference Manual. ARM 100166_0001_00_en. Rev. r0p1. ARM. 2015-02-23. url: http://infocenter.arm.com/help/index. jsp?topic=/com.arm.doc.100166_0001_00_en/index.html (besucht am 2018-08-15). [8] BCM2835 ARM Peripherals. Broadcom Corporation. 2012. url: https://www. raspberrypi.org/app/uploads/2012/02/BCM2835- ARM- Peripherals.pdf (besucht am 2018-11-05). [9] Meng-Lun Cai. BBBIOlib. Github. url: https://github.com/VegetableAvenger/ BBBIOlib (besucht am 2018-10-15).

1http://dx.doi.org/10.1145/41625.41642

55 ANHANG E. LITERATURVERZEICHNIS

[10] Code Generation Tools for TI processors and microcontrollers. Webseite. Texas In- struments. url: https://www.ti.com/tools-software/compilers/download. html (besucht am 2018-11-05). [11] Gerald Coley und Jason Kridner. BeagleBone Black System Reference Manual. Hrsg. von Robert P J Day. Revision C.x (on-line wiki edition). BeagleBoard.org Foundation. 2017-10. url: https://github.com/beagleboard/beaglebone- black/wiki/System-Reference-Manual (besucht am 2018-08-14). [12] Cortex™-A8 Technical Reference Manual. ARM DDI 0344K. Rev. r3p2. ARM. 2010-05-07. url: http://infocenter.arm.com/help/index.jsp?topic= /com.arm.doc.ddi0344k/index.html (besucht am 2018-08-15). [13] Cortex™-A9 Technical Reference Manual. ARM 100511_0401_10_en. Rev. r4p1. ARM. 2016-02-11. url: http : / / infocenter . arm . com / help / index . jsp ? topic=/com.arm.doc.ddi0388e/index.html (besucht am 2018-08-15). [14] Discovery kit with STM32F407VG MCU User Manual. UM1472. Rev. 6. STMi- croelectronics. 2017-5. url: http://www.st.com/en/evaluation- tools/ stm32f4discovery.html (besucht am 2018-08-14). [15] Download CCS. Webseite. Texas Instruments. url: http://processors.wiki. ti.com/index.php?title=Download_CCS%5C&oldid=235706 (besucht am 2018-10-15). [16] A. Dunkels, B. Gronvall und T. Voigt. “Contiki - a lightweight and flexible operating system for tiny networked sensors”. In: 29th Annual IEEE International Conference on Local Computer Networks. 2004-11, S. 455–462. doi: 10.1109/ LCN.2004.382. [17] ENC28J60 Data Sheet. DS39662A. Microchip Technology Inc. 2014. url: http: //ww1.microchip.com/downloads/en/DeviceDoc/39662a.pdf (besucht am 2018-08-22). [18] Flyswatter2. Webseite. Tin Can Tools. url: https://www.tincantools.com/ product/flyswatter2/ (besucht am 2018-12-19). [19] free pascal. Webseite. Free Pascal team. url: https://www.freepascal.org/ (besucht am 2018-12-05). [20] David Gay, Philip Levis, Robert von Behren u. a. “The nesC Language: A Holistic Approach to Networked Embedded Systems”. In: SIGPLAN Not. 38.5 (2003-05), S. 1–11. issn: 0362-1340. doi: 10.1145/780822.7811333. [21] GCC, the GNU Compiler Collection. Webseite. Free Software Foundation, Inc. url: https://www.gnu.org/software/gcc/ (besucht am 2018-11-05). [22] Getting started with software and firmware environments for the STM32F4DISCOVERY Kit. UM1467. Rev. 1. STMicroelectronics. 2011-09. url: https://www.st.com/ en/evaluation-tools/stm32f4discovery.html (besucht am 2018-08-15). 2http://dx.doi.org/10.1109/LCN.2004.38 3http://dx.doi.org/10.1145/780822.781133

56 ANHANG E. LITERATURVERZEICHNIS

[23] Getting started with STM32 MCU Discovery Kits software development tools. UM2052. Rev. 1. STMicroelectronics. 2016-05. url: https://www.st.com/ en/evaluation-tools/stm32f4discovery.html (besucht am 2018-08-15). [24] GNU Arm Embedded Toolchain. Webseite. ARM. url: https://developer.arm. com/open-source/gnu-toolchain/gnu-rm (besucht am 2018-08-22). [25] Heise.de Preisvergleich - BeagleBone Black Rev. C. Webseite. Heise.de. url: https : / / www . heise . de / preisvergleich / beaglebone - black - rev - c - a1388416.html (besucht am 2018-12-11). [26] Heise.de Preisvergleich - Raspberry Pi 3 Modell B+. Webseite. Heise.de. url: https : / / www . heise . de / preisvergleich / raspberry - pi - 3 - modell - b - a1785657.html (besucht am 2018-08-22). [27] David A. Holland, Ada T. Lim und Margo I. Seltzer. “A New Instructional Ope- rating System”. In: SIGCSE Bull. 34.1 (2002-02), S. 111–115. issn: 0097-8418. doi: 10.1145/563517.5633834. [28] i.MX 6 Series of Applications Processors. IMX6SRSFS. Rev. 16. NXP. 2018. url: https://www.nxp.com/docs/en/fact-sheet/IMX6SRSFS.pdf (besucht am 2018-08-15). [29] i.MX 6Dual/6Quad Applications Processor Reference Manual. IMX6DQRM. Rev. 5. NXP. 2018-06. url: https : / / www . nxp . com / products / processors - and - microcontrollers / applications - processors / i . mx - applications - processors / i . mx - 6 - processors / i . mx - 6quad - processors - high - performance-3d-graphics-hd-video-arm-cortex-a9-core:i.MX6Q?%5C& tab=Documentation_Tab (besucht am 2018-08-15). [30] iMX6 OpenRex Single Board Computer Datasheet. Rev. 1.1. VOIPAC TECHNOLO- GIES. 2017-04-6. url: http://www.imx6rex.com/wp-content/uploads/2017/ 04/iMX6_OpenRex_SBC_datasheet.pdf (besucht am 2018-11-09). [31] iMX6 Rex Open Source - Download. Webseite. (erfordert Registrierung). FEDE- VEL. url: https://www.imx6rex.com/downloads/ (besucht am 2018-12-11). [32] Liviu Ionescu. The OpenOCD debugging Eclipse plug-in. Webseite. url: https: //gnu-mcu-eclipse.github.io/debug/openocd/ (besucht am 2018-12-10). [33] Elke Middendorff, Beate Apolinarski, Karsten Becker u.a. Die wirtschaftliche und soziale Lage der Studierenden in Deutschland 2016. 21. Sozialerhebung des Deut- schen Studentenwerks durchgeführt vom Deutschen Zentrum für Hochschul- und Wissenschaftsforschung. Berlin: Bundesministerium für Bildung und Forschung (BMBF), 2017. url: http://www.sozialerhebung.de/archiv/soz_21_haupt (besucht am 2018-12-20). [34] ODROID-C2. Webseite. Hardkernel co., Ltd. url: https://www.hardkernel. com/main/products/prdt_info.php?g_code=G145457216438%5C&tab_idx=1 (besucht am 2018-11-09). 4http://dx.doi.org/10.1145/563517.563383

57 ANHANG E. LITERATURVERZEICHNIS

[35] openapcjim. StarterWareFree for AM335X. SourceForge. url: https : / / sourceforge.net/projects/starterwarefree/ (besucht am 2018-08-22). [36] OpenRex – Open Source Hardware Project. Webseite. FEDEVEL. url: http:// www.imx6rex.com/open-rex/ (besucht am 2018-08-15). [37] Chandandeep Singh Pabla. “Completely Fair Scheduler”. In: Linux J. 2009.184 (2009-08). issn: 1075-3583. url: http://dl.acm.org/citation.cfm?id= 1594371.1594375 (besucht am 2018-12-21). [38] PINE A64 512MB BOARD. Webseite. Pine64. url: https://www.pine64.org/ ?product=pine-a64-board (besucht am 2018-12-11). [39] PINE A64, First $15 64-Bit Single Board Super Computer. Webseite. PINE64 Inc. url: https://www.kickstarter.com/projects/pine64/pine-a64-first-15- 64-bit-single-board-super-comput (besucht am 2018-12-10). [40] PINE A64 Main Page. Webseite. Pine64. url: http://wiki.pine64.org/index. php/PINE_A64_Main_Page (besucht am 2018-12-11). [41] Raspberry Pi 3 Model B+. Product Brief. Raspberry Pi Foundation. url: https: //static.raspberrypi.org/files/product-briefs/Raspberry-Pi-Model- Bplus-Product-Brief.pdf (besucht am 2018-08-14). [42] RASPBERRY PI HARDWARE. Webseite. Raspberry Pi Foundation. url: https: //www.raspberrypi.org/documentation/hardware/raspberrypi/README.md (besucht am 2018-08-22). [43] S905 Datasheet. Rev. 1.1.4. Amlogic, Inc. 2016-06-06. url: https : / / www . hardkernel.com/main/products/prdt_info.php?g_code=G145457216438% 5C&tab_idx=2 (besucht am 2018-08-15). [44] Samtec Inc. FTR-110-03-G-D-06. Webseite. Digi-Key Electronics. url: https: //www.digikey.de/product- detail/en/samtec- inc/FTR- 110- 03- G- D- 06/SAM8790-ND/2651173 (besucht am 2018-12-11). [45] Charles Severance. “Eben Upton: Raspberry Pi”. In: Computer 46.10 (2013-10), S. 14–16. issn: 0018-9162. doi: 10.1109/MC.2013.3495. [46] Kang G Shin und Parameswaran Ramanathan. “Real-time computing: A new discipline of computer science and engineering”. In: Proceedings of the IEEE 82.1 (1994), S. 6–24. url: https : / / kabru . eecs . umich . edu / papers / publications/1994/ramanathan-shin-ieee-proceedings.pdf (besucht am 2018-08-14). [47] Rene Stange, Matheus Eduardo, Stephan Mühlstrasser u. a. circle - A C++ bare metal environment for Raspberry Pi with USB. Github. url: https://github.com/ rsta2/circle (besucht am 2018-11-28).

5http://dx.doi.org/10.1109/MC.2013.349

58 ANHANG E. LITERATURVERZEICHNIS

[48] StarterWare for ARM® based TI Sitara Processors. Webseite. Texas Instru- ments. url: http://www.ti.com/tool/STARTERWARE- SITARA (besucht am 2018-08-22). [49] STM32CubeF4 Data Brief. DocID025729. Rev. 5. STMicroelectronics. 2017-12. url: https : / / www . st . com / content / st _ com / en / products / embedded - software/mcus-embedded-software/stm32-embedded-software/stm32cube- mcu-packages/stm32cubef4.html (besucht am 2018-10-15). [50] STM32F4DISCOVERY. Webseite. STMicroelectronics. url: https://www.st. com/en/evaluation-tools/stm32f4discovery.html#samplebuy-scroll (be- sucht am 2018-12-10). [51] Andrew S. Tanenbaum und Herbert Bos. Modern Operating Systems (4th Edition). Pearson, 2014. isbn: 013359162X. [52] Ultibo. Webseite. Ultibo. url: https://ultibo.org/ (besucht am 2018-11-28). [53] VOIPAC Webshop. Webseite. VOIPAC TECHNOLOGIES. url: https : / / www . voipac.com/#category3 (besucht am 2018-12-11). [54] Hagen Völzer, Daniele Varacca und Ekkart Kindler. “Defining Fairness”. In: CONCUR 2005 – Concurrency Theory. Hrsg. von Martín Abadi und Luca de Alfaro. Berlin, Heidelberg: Springer Berlin Heidelberg, 2005, S. 458–472. isbn: 978-3-540-31934-4. [55] K.C. Wang. Embedded and Real-Time Operating Systems. Springer International Publishing, 2017. doi: 10.1007/978-3-319-51517-56. [56] Joachim Wietzke. Embedded Technologies: vom Treiber bis zur Grafik-Anbindung. SpringerLink, Bücher. 1 Online-Ressource (xxvi, 321 Seiten). Berlin: Springer Berlin Heidelberg, 2012. isbn: 1280793481, 9783642239960, 9781280793486, 9781280793486. [57] XDS110 JTAG Debug Probe. Webseite. Texas Instruments. url: http://www.ti. com/tool/TMDSEMU110-U (besucht am 2018-12-11).

6http://dx.doi.org/10.1007/978-3-319-51517-5

59