Eingebettete Betriebssysteme (2022/23)

	Prof. Dr. Andreas Polze
Projektbetreuung	Arne Boockmeyer, Robert Schmid, Lukas Pirl
Termine	mittwochs 09:15 – 10:45 Uhr in K-1.03 donnerstags 13:30 – 15:00 Uhr in HS 2
Modus	standardmäßig in Präsenz, nach Absprache oder Anfrage auch digital im Zoom-Raum 519 817 5573 von Andreas Polze, Passwort: 4711; Kooperation mit EBRH im Zoom-Raum 668 3017 5448, Passwort: 75226074

Da Anwendungen für eingebettete Systeme - einer Kombination aus Hardware, Software & Firmware mit fester Funktionalität bzw. spezialisierten Aufgaben - in sämtlichen Bereichen eingesetzt werden und ein wichtiger Bestandteil des Alltags geworden sind, spielen eingebettete Geräte und Software eine wichtige Rolle für das Funktionieren von Autos, Haushaltsgeräten, medizinischen Geräten und anderen täglich genutzten Dingen.

Im Gegensatz zu einem General-Purpose-Betriebssystem ist ein Betriebssystem für eingebettete Systeme in seiner Funktionalität sehr eingeschränkt - es ist in der Regel auf die fehlerfreie Ausführung einer einzigen Anwendung ausgelegt. Diese einzige Anwendung ist jedoch entscheidend für den zuverlässigen Einsatz des Geräts. Daher muss ein eingebettetes Betriebssystem auch mit eingeschränktem Ressourcen wie Speicher, CPU oder Energie reibungslos funktionieren. Bei der Softwareentwicklung für eingebettete Systeme treten daher viele Aspekte in den Vordergrund, die bei Desktopsystemen nur eine untergeordnete Rolle spielen:

vorhersagbares zeitliches Verhalten & Echtzeit
Verwaltung begrenzter Ressourcen wie CPU und Speicher
Probleme von Echtzeit-Scheduling (Abhängigkeiten, Priority Inversion, Worst Case Execution Time)
Anforderungen an die Speicherverwaltung in einer Echtzeitumgebung
Echtzeit-Kommunikation

In der Veranstaltung werden Entwurfsentscheidungen eingebetteter Betriebssysteme anhand von Beispielszenarien erläutert und ein Einblick in aktuelle Standardisierungsprozesse gegeben.

In der Vorlesung werden Algorithmen zur Verwaltung von Ressourcen wie Speicher, CPU, Netzwerk u.a. vorgestellt, an die durch viele Einschränkungen von eingebetteten Systemen besondere Anforderungen gestellt werden. Aber auch aufkommende Konzepte wie die Konfigurierbarkeit von Betriebssystemen und anwendungsspezifische Betriebssysteme werden vorgestellt.

Die Schwerpunkte der Praktika liegen bei Betriebssystemen für eingebettete Systeme, verteilten Echtzeitsystemen, Echtzeitsteuerung, Firmware-Programmierung und systemnaher App-Programmierung. Die Praktikumsaufgaben werden im Rahmen der Vorlesung erläutert, diskutiert und können durch die Interessen der Teilnehmenden mitgestaltet werden.

Themen

Im Vorlesungsteil werden insbesondere folgende Themen behandelt:

Aufgaben eines Echtzeit-Betriebssystems
- vorhersagbares zeitliches Verhalten (Echtzeit)
- Optimierungskriterien: Fairness, Durchsatz, Antwortverhalten, Vorhersagbarkeit
Verwaltung der Ressource CPU
- Echtzeit-Scheduling: RMS, EDF, LSF
- Task-Modell + periodische/aperiodische Tasks
- Probleme des Echtzeit-Scheduling: Abhängigkeiten, Priority Inversion, Worst Case Execution Time (WCET)
Speicherverwaltung in eingebetteten Systemen
- Protokolle für den konkurrierenden Ressourcenzugriff
Echtzeitkommunikation
- Anforderungen an Echtzeitkommunikation
- Feldbusse (CAN), Time Triggered Protocol, LoRaWAN
verlässliche, vorhersagbare Gruppenkommunikation & Uhrensynchronisation
Echtzeit-Betriebssysteme in Detail
- Speicherverwaltung, Interrupt-Behandlung, Echtzeitfähigkeiten
- Besonderheiten
Programmiersprachen und Programmiermodelle

Projektarbeit

Im Rahmen der Lehrveranstaltung stellen externe Partner ihre Arbeiten im Gebiet der eingebetteten Systeme vor und bieten auch Themen für die Projektarbeit an.

Eigene Projektvorschläge von Teilnehmenden sind selbstverständlich auch möglich. Wer noch keine Idee gefunden hat, kann ja nochmal in die Folien zu den Projektideen gucken. Es ist auch kein Problem, wenn unterschiedliche Gruppen das "gleiche Thema" bearbeiten, da sich üblicherweise genügend Varianten finden lassen, sodass sich die tatsächlichen Themen dann doch unterscheiden. Ansonsten finden wir dann im persönlichen Gespräch sicherlich ein Thema, das gut zu euch passt.

Dabei müsst ihr nicht fürchten, dass ihr ganz viele Hardware selbst bauen und löten müsst – für fast alles gibt es auch Entwicklungs-/Dev-/Breakout-Boards, die man einfach zusammenstecken kann. Überlegt mal, welche Hardware für eure Projektidee nützlich wäre (bzw. welche Fähigkeiten sie haben sollte) und recherchiert nach möglichen Bauteilen (z.B. ESP32-Dev-Kit, GPS-Modul, je nach Projektidee) sowie nach Funktionsbestandteilen (z.B. "Wake Up Sources"). Es wäre auch nicht verkehrt, schon einmal zu schauen, wie denn eine Entwicklungsumgebung für die ausgewählte Infrastruktur aussehen würde (IDE, Programmiersprache, Frameworks/Bibliotheken, Bare-Metal vs. Betriebssystem, Debugging, etc.). Dabei solltet ihr immer mit überlegen, wie sich eure Idee in die Themen "eingebettete Systeme", "Echtzeit" und/oder "beschränkte Ressourcen" einordnet. Dazu können sehr gern die vorhandenen Geräte der IoT-Labs/der IoT-Vitrine am Fachgebiet verwendet bzw. auf Anfrage auch neue Hardware angeschafft werden.

Ziel ist nicht, am Ende ein funktionierendes "Produkt" zu entwickeln, sondern auf dem Weg dorthin möglichst viele Erfahrungen mit dem Entwicklungsprozess für eingebettete Systeme zu machen, die Besonderheiten bei der Programmierung eingebetteter Systeme "live" zu erleben und diese Erfahrungen mit den anderen Studierenden zu teilen.

Für uns am interessantesten ist was ihr über die Entwicklung von eingebetteten Systemen gelernt habt und mit welchen Problemen ihr euch herumschlagen müsst. Wir regen an, dass sich die Teilnehmer:innen mit den folgenden Zusammenfassungen der Projekte aus dem Vorjahr auseinandersetzen. Das schärft nicht nur die Wahrnehmung für i. S. d. Veranstaltung interessante Aspekte in Projekten, sondern legt teilweise auch Ratschläge der vorhergehenden Generation Studierenden offen.

YETI - Your Exclusive Tracking Infrastructure (Justus, Philipp, Tobias)

Projektidee: Folien

Hardware:

HELTEC LoRa 32 V2 (ESP mit integriertem Lora)
MPU 6050 (Gyro/Acceleration)
GY-GPS6MV2 (GPS)

Zwischenpräsentation: Folien

Hier ein kurzes Update vom Team YETI - wir sind die mit dem Ruder-Tracker (der jetzt eher ein Tracker mit Schrittzähler ist, weil Rudern gerade nicht so viel Spaß macht ;)). Wir können inzwischen Daten von GPS und Gyro/Accelerometer auslesen, verarbeiten (Schrittfrequenz erkennen) und via LoRa zu unserer BaseStation (ein zweiter LoRa ESP) verschicken. Diese leitet die Daten an einen kleinen Web Server weiter, sodass man diese auf einer einfachen Website ansehen kann.

Wir benutzen die folgende Hardware:

HELTEC LORA 32 V2 (ESP32 mit integriertem LoRa Transceiver und OLED Display)
MPU6050 (Gyro/Acceleration)
GY-GPS6MV2 (GPS Modul, basiert auf ublox NEO-6M

GPS, Gyro und Display sind via UART und I²C angebunden, wobei sich das GPS Modul mit einem proprietären Protokoll (UBX) von ublox konfigurieren lässt. Wie genau dieses Protokoll und die Konfiguration funktionieren steht aber nicht im Datenblatt, sondern im Interface Manual, was im Übrigen auch einen guten Überblick über die allgemeine Funktionsweise des Moduls gibt.

Bei der I²C Schnittstellen haben wir etwas länger gerätselt, warum wir nicht Bildschirm und MPU6050 gleichzeitig ansteuern konnten. Als Bus-Protokoll sollte es eigentlich möglich sein mehrere Geräte an denselben Bus anzuschließen, wir konnten jedoch nur entweder Display oder MPU nutzen. Der Grund war letztendlich, dass man bei der Initialisierung die I²C-Verbindung mit den entsprechenden Pins als Singleton konfiguriert. Der ESP verfügt aber über 2 Pin-Gruppen für I²C. Über die erste wird standardmäßig der Bildschirm angesteuert, während wir versucht hatten die zweite Gruppe zum Auslesen der MPU zu nutzen. Da das I²C objekt aber als Singleton konzipiert ist, können nicht beide Pin-Gruppen gleichzeitig angesteuert werden. Das anschließen der MPU an die vom Bildschirm genutzten Pins hat das Problem letztendlich gelöst.

Entwicklungsumgebung:

Wir haben uns entschieden von Arduino Studio zur vom ESP-Hersteller bereitgestellten Umgebung ESP-IDF zu wechseln und in VS Code weiter zu entwickeln. Das hat mehr Transparenz und Kontrolle mit sich gebracht. Außerdem ist VS Code der ausgefeiltere und komfortablere Editor.

Um unseren existierenden Code lauffähig zu halten, wollten wir außerdem die von Espressif bereitgestellte Arduino-Library für den ESP32 einbinden. Diese stellt z.B. alle für den Arduino definierten Datentypen und Funktionen bereit. Daneben haben wir die von Espressif bereitgestellten CMake-Funktionen genutzt um unsere Abhängigkeiten in Komponenten auszulagern, welche zwischen unseren 2 Compilation-Targets für FieldDevice und BaseStation geteilt werden. Trotz der guten Unterstützung war die Installation und Konfiguration aller benötigten Tools in den richtigen Versionen recht aufwändig. Wir haben uns daher entschlossen auf den von Espressif bereitgestellten Docker-Container umzusteigen und diesen für uns zu konfigurieren. So können wir nun diesen Container unter Linux in VS Code mit einem Klick starten, das USB-Device durchreichen und wir bekommen eine voll funktionsfähige Entwicklungsumgebung.

Strommessung:

Den Strom haben wir mit dem Labormessgerät im IoT-Lab gemessen. Das haben wir hierzu einfach hinter das Labornetzteil gehängt. Mithilfe der seriellen Schnittstelle und eines entsprechenden USB-Adapters (existiert auch im IoT-Lab) können dann die Messwerte recht einfach aufgezeichnet werden. Wir haben uns dafür ein kleines Python-Skript geschrieben, das die Werte direkt als Graph darstellen kann. Einziges Problem hierbei: man ist an das Lab gebunden. Hier findet das GPS-Modul nur sehr schwer ein Signal und wird deshalb auch nicht in den für uns so interessanten Energiesparmodus wechseln.

Auch in den kommenden Tagen soll der Fokus bei uns vor allem auf Energiesparsamkeit liegen.

Endpräsentation: Folien

Hallo zusammen,

hier möchten wir euch einen kurzen Überblick über unsere Learnings während des Projekts geben:

Express-Lieferung bei Aliexpress:

Bei Elektronik-Bestellungen aus Fernost via Aliexpress/Alibaba/etc. macht es Sinn mal einen Blick auf die verschiedenen Versandoptionen zu werfen. Oft kann man die Lieferung durch einen Aufpreis von 1-2€ um mehrere Wochen beschleunigen. Es kann sich auch lohnen verschiedene Anbieter zu vergleichen. Auch hier gibt es welche, die direkt aus Europa verschicken, was in der Regel deutlich schneller geht.

Programmierumgebung:

ESPs lassen sich wunderbar mit Arduino Studio Programmieren, was schnelle motivierende Erfolgserlebnisse erbringt. Will man aber etwas tiefer in die Materie einsteigen kommt man hier schnell an seine Grenzen. Ein Umstieg auf fortgeschrittene Umgebungen ist aber mit recht viel Aufwand verbunden, da Code zum Teil angepasst werden muss. Es kann also durchaus hilfreich sein, direkt mit anderen Umgebungen (z.B. esp-idf, PlatformIO, CLion) zu starten.

Containerized Development:

Espressif, der Hersteller des ESP32, bietet einen Docker-Devcontainer für VSCode, mit dem sich eine Entwicklungsumgebung nach etwas Konfiguration sehr schnell und gut wiederholbar aufsetzen lässt. Dazu kann sehr bequem die Visual Studio Code Remote - Containers Extension mit einer entsprechenden Konfiguration (z.B. USB Serial-Device in den Container weiterleiten) genutzt werden. Damit lässt sich dann (zumindest unter Linux) einfach der ESP-32 über USB-Anschließen, den Container in VS-Code starten und loslegen. Ganz ohne Installation weiterer Abhängigkeiten oder VS-Code Plugins.

Power Profiler Kit:

Es gibt im IOT-Lab ein Power Profiler Kit, es ist einfach zu bedienen und super um sehr feingranular den Stromverbrauch zu messen. Da man auch Pins mit einer recht hohen Frequenz auslesen kann, eignet es sich auch, um z.B. Kommunikationsprotokolle oder Scheduling zu untersuchen.

Bei der Projektwahl auf die Jahreszeit achten:

Im Winter kann man nur schwer Ruderbewegungen messen und einen Rudertracker nicht im richtigen Einsatz testen. Sowas sollte man bei der Projektwahl berücksichtigen.

Unser Projekt liegt im HPI Gitlab und sollte über den folgenden Link abrufbar sein: https://gitlab.hpi.de/eosbastelkeller/gps_demo

Viele Grüße

Justus, Philipp und Tobias

DRONE - Diy Rotator version ONE (Tobias, Felix, Jan-Eric)

Projektidee: Folien

spannende Links::

Crazyflie (OpenSource Flight Controller als existierendes Projekt, ausgelegt auf STM Microcontroller)
ESP32 Debugging via GDB und Raspi (finden wir sehr hilfreich!)

Hardware::

ESP32 auf NodeMCU
ESC ("Electronic Speed Controller", Motorcontroller)
Motoren
MPU6050 IMU
Akku

Zwischenpräsentation: Folien

Wir arbeiten aktuell mit einem ESP32 als Flugcontroller. Unsere Motoren steuern wir über Electronic Speed Controller die mit der BLHeli 32 Firmware laufen an, indem wir das DSHOT Protokoll mit ihnen sprechen.

Um die Lage der Drohne zu bestimmen verwenden wir eine MPU6050. Hierbei hat uns besonders der integrierte Selbsttest geholfen, um bereits eine defekte MPU auszusortieren, die keine sinnvollen Z-Werte mehr geliefert hat. Die Ausgabe der MPU läuft in einen PID Controller, der dann Korrekturen an den Motorengeschwindigkeiten ausgibt. Bevor der PID Controller aber korrekte Werte ausgibt, muss man diesen aber vorher noch tunen, d.h. die P, I und D Werte für Roll, Pitch und Yaw festlegen.

Die Entwicklung läuft bei uns mittels VS Code und der Platform IO Erweiterung. Gelegentlich hilft da auch das LiveShare Feature um besser zusammen Code zu schreiben. Bei Platform IO ist der Papierkorb, der alle Build Artefakte entfernt, genau neben dem Upload Button, da sollte man eine ruhige Hand haben, da der Build Prozess relativ lange dauert. :) Der Upload geht aber schnell, da gibt es eine Flag im platform.ini.

Um die verbliebene Kapazität der Batterie zu bestimmen messen wir dessen Spannung. Dies geht mittels eines einfachen Messgeräts aus dem Lab. In der Luft ist das ganze jedoch nicht so einfach. Dort schließen wir die Batterie mittels eines Spannungsteilers (unsere Batterien arbeiten zwischen 13.8 und 16.5 Volt) an den ESP32 an und mappen dann die geringeren Spannungswerte (im 1-2 Volt Bereich) auf die eigentlichen. Hier waren einige Messreihen notwendig um dieses Mapping so genau wie möglich hinzukriegen, da sich herausstellte, dass ein 10k Ohm Widerstand nicht exakt 10k Ohm hatte (dafür haben sie eine Toleranzangabe).

Endpräsentation: Folien

Hallo zusammen,

bezüglich der Learnings in unserem DRONE-Projekt/Ratschläge an kommende Teams würden wir gerne noch folgendes sagen:

Es ist sinnvoll, sich bereits im Voraus zu überlegen, auf welchem Abstraktionslevel man sich in dem Kurs bewegen will. Wenn man sich nämlich z.B. in erster Linie genauer ansehen will, wie diverse Low-Level-Operationen funktionieren, sollte man sich eher ein Projekt mit kleinem Scope aussuchen, während man bei einem umfangreicheren Projekt wie etwa unserem halt einfach davon ausgehen muss, auf einem vorhandenen Framework aufzusetzen und sich somit mit einigen Problemen der Embedded-Entwicklung wie z.B. Scheduling nicht explizit selbst auseinander zu setzen.

Außerdem haben wir gelernt, dass im Embedded-Bereich die Entwicklung einfach etwas länger dauern kann, als man im Voraus abgeschätzt hat, weil die Build-Upload-Schleife einfach Zeit frisst und Debugging sich schwierig gestalten kann. Das sollte man im Voraus einplanen (je nachdem, wie viel Vorerfahrung in der Gruppe bereits besteht), damit man dann am Ende nicht enttäuscht ist, wenn die Ergebnisse vielleicht nicht ganz so umfangreich ausfallen, wie man es am Anfang geplant hatte.

Schließlich haben wir festgestellt, dass es Sinn machen kann, im Zweifel auch mal das für die Entwicklung sehr komfortable IOT-Lab zu verlassen. Der Platz für Tests mit unserer Drone war dort zwar grundsätzlich ausreichend, aber wir mussten schon immer aufpassen, dass wir nicht versehentlich etwas beschädigen. Daher ist auch der Arbeitsschutz ein nicht zu vernachlässigender Teil unseres Projekts gewesen, dem wir auch immer (mehr oder minder ;)) erfolgreich Rechnung getragen haben.

Ansonsten würden wir gerne noch einmal auf die Learnings verweisen, die wir bereits in der Abschlusspräsentation angesprochen haben (siehe insbesondere Folien 32 und 33).

Viele Grüße,

Felix, Jan-Eric und Tobias

∿↭〰️ - Radweg-Qualitäts-Messer (Benito, Tim)

Projektidee: Folien

Hardware:

Accelerometer MPU-6050, MPU-9250, LIS3DH
CPU und BoardNodeMCU v3 ESP8266
Akku LP-503562
Ladeplatine Berrybase CHB-LIP1
GPS-Modul GYNEO6MV2

Zwischenpräsentation: Folien

Benito und ich binden aktuell die MPU6050 und den Neo6m zusammen an den ESP8266. Beide Chips laufen einzeln schon gut, aber die Interaktion müssen wir noch coden. Glücklicherweise verbinden wir die Chips ohnehin über verschiedene Pins, sollte also HW technisch kein Problem werden. Das Parsen vom NMEA Protokoll vom GPS zickt aktuell noch ein bisschen, ansonsten kommen wir mit I2C für die MPU und mit UBX für den NEO6m gut zurecht.

Drei Learnings, die wir hatten sind

Wenn man zu faul ist, stundenlang auf GPS Lock zu warten, sollte man auf eine größere Antenne upgraden
Handy GPS ist nur so schnell locked, weil die Satellitenbahnen dafür aus dem Internet gezogen werden. Embedded Chips können das nicht. Manche Antennen haben aber einen Akku, um die ohne Internet geholten Infos vorgehalten werden können
Nur weil ein Feature-Datenblatt behauptet, dass es einen Digital Motion Processor gibt, heißt das nicht, dass der auch Dokumentiert ist. Die HW und Firmware dafür ist schon da, aber wir können sie nicht ansteuern. Aber wenn man findig ist, bemerkt man vielleicht in der URL die Zahl 1: "MPU-6000-Register-Map1.pdf" und ersetzt sie einfach mal durch ne 2 und siehe da: Mehr Register. Fehlen immer noch ein paar leider, aber vielleicht finden wir da noch mehr

Wir arbeiten aktuell mit platformIO, als VS Code Extension. Der Prozess war ziemlich einfach, Extension dazufügen, richtigen Chip auswählen und los. Detected sogar automatisch welchen USB Port man benutzt.

Zu Strom haben wir noch keine großen Learnings, benutzt haben wir das Lab-Netzteil und einen zwischen schaltbaren USB Strommesser. Das ging gut (lockere Krokodilklemmen waren das größte Problem), aber leider will unser Chip aktuell noch nicht in den low power modus wechseln.

Endpräsentation: Folien

Hallo zusammen,

zu den unserer Meinung nach wichtigsten Dingen, die kommende Gruppen vor Projektstart wissen sollten, gehört, dass der gesamte Build-and-Run-Zyklus bei der Hardwareentwicklung kaum mit der Softwareentwicklung zu vergleichen ist. Während man bei Software höchstens unter einer schlechten Internetverbindung leidet, muss Hardware physisch geliefert werden. Zusätzlich kann diese bei der Herstellung kaputt sein oder beim Basteln schnell kaputt gehen, was ein Ersetzen des Bauteils zur Folge hat. Es sollte daher unbedingt genug Reserve gekauft werden (im Optimalfall mehr als man am Anfang erwarten würde). Es ist ärgerlich wenn sich die Arbeit verzögert, nur weil man auf ein Bauteil wartet.

Des Weiteren lohnt es sich wirklich Datenblätter aufmerksam zu lesen, bevor man mit Trial-and-Error anfängt. Die meisten Datenblätter sind fantastische Informationsquellen, wenn man sich nicht von der Informationsflut erschlagen lässt. Das spart Frustration bei der Benutzung und verhindert, dass man das Bauteil aus Versehen beschädigt.

Sicherlich kein "Geheimtipp", aber man kann es nicht oft genug betonen: Wenn ihr Messhardware zur Verfügung habt, dann nutzt diese so früh wie möglich. Man wundert sich schnell warum ein Chip nicht antwortet…oft liegt es aber doch daran, dass Steckkontakte fehlerhaft oder einfach Kabel kaputt sind. Mit einem Voltmeter sollte man also jederzeit als erstes einfach kurz gegenchecken, dass Verbindungen tatsächlich geschlossen sind und die gewünschten Spannungen am Bauteil anliegen, wenn es zu ungewolltem Verhalten kommt. Ein Oszilloskop erleichtert hier die Arbeit noch weiter, da man sich sogar die Signale an digitalen (oder analogen) Leitungen anschauen kann.

Gefühlt hätte man auch noch sehr viel mehr auf Prozess fokussieren können, indem man z.B. das Projekt nicht so Pi mal Daumen spezifiziert, sondern vorab direkt ne feste Spec hat und dann versucht, den "Real World" Entwicklungsprozess nachzuvollziehen. Also erst Requirements, dann Spezifikation, dann Architektur und erst ganz am Ende echte HW Komponenten. Das haben wir zwar auch irgendwie gemacht, aber eben relativ durcheinander, und es wär sicher ne Erfahrung gewesen, direkt ab Anfang auf HW-Kosten zu optimieren und dann mit der Software irgendwie hinkommen zu müssen.

Hier das Repo mit unserem Code: https://gitlab.hpi.de/tim.garrels/EOS

Viele Grüße

Benito und Tim

Dependability by Default (Clemens, Marcel)

Projektidee: Folien

Zwischenpräsentation: Folien

Wir haben uns inzwischen darauf fokussiert, eine Runtime für asynchrone Tasks zu bauen, die auch Deadlines und andere Verlässlichkeitsfunktionen wie partielle Ergebnisse und Heuristiken unterstützt.

Als Beispiel dafür arbeiten wir an einem STM32F401RE-Microcontroller mit einem DS18B20-Temperatursensor, der über das OneWire-Protokoll kommuniziert. Das ist insofern das perfekte Beispiel für uns, dass OneWire in der Praxis manchmal Probleme mit der Verbindung hat, weil Prüfsummen der Pakete nicht stimmen.

Ein großes Learning für uns war, Datenblätter genau zu lesen - anfangs hatten wir übersehen, dass OneWire am Datenpin noch über einen Widerstand mit der Spannung verbunden werden muss, sodass wir passende Widerstände noch besorgen mussten. Außerdem hat sich das Rust-Typsystem als sehr hilfreich erwiesen, wenn die Dokumentation oder Beispielcode fehlen. Da beispielsweise verschiedene Pins eigene Datentypen haben und nicht nur mit ihrer Nummer angesprochen werden, kann man sich häufig aus Funktionssignaturen zusammenreimen, welche Pins oder Peripheriegeräte wofür genutzt werden können und wie man sie richtig initialisiert.

Als Entwicklungsumgebung setzen wir auf Visual Studio Code mit der rust-analyzer-Erweiterung. Für die Embedded-Entwicklung brauchen wir dabei keine spezifische Konfiguration, wir haben zusätzlich nur ein Makefile, das mit dem objcopy-Tool das von Rust erzeugte Binary in das korrekte Format für unsere STM32-Microcontroller umwandelt. Diese geben sich am PC als USB-Speicher aus, sodass wir die kompilierten Programme nur darauf ziehen müssen und uns nicht mit externen Programmern oder spezialisierten IDEs wie PlatformIO auseinandersetzen mussten.

Endpräsentation: Folien

Hallo zusammen!

Projekten in den nächsten Jahren würden Clemens und ich folgende Learnings und Tipps mitgeben:

Falls ihr an n > 3 Teilprojekten arbeitet, packt ruhig erstmal alles in ein Repo. Es ist weniger mentaler Overhead, wenn man nicht überlegen muss, wo nochmal ein Code-Schnipsel lag. Im Zweifel kann man Funktionalität später auch noch auslagern.
Nehmt euch das Zwischen-Feedback zu Herzen, zumindest falls euch Empfehlungen hinsichtlich der Wichtigkeit von bestimmten Aspekten des Projekts gegeben werden.
Fangt früh genug damit an, die Kurve von "viele neue Dinge ausprobieren" zu "Dinge aufräumen und abrunden" zu kriegen.
Falls es sich um ein Forschungsprojekt handelt, habt auf jeden Fall eine konkrete Anwendung parat, an der ihr verschiedene Ansätze ausprobiert. Das erdet abstrake Einblicke nochmal in der Wirklichkeit.

Weitere Learnings gibt es noch in den Folien der Endpräsentation. Der Code von der Dependability-Bibliothek befindet sich auf https://github.com/MarcelGarus/dependability, das konkrete Anwendungsbeispiel auf https://github.com/ctiedt/temperature-example.

Euch noch eine schöne Woche!

Clemens und Marcel

Tracking-Technologien (Benedikt, Mark, Rohan)

Projektidee: Folien

Hardware:

Arduino Nano (&Uno)
ESP32-WROOM-32
Wisol WSSFM10RC1 Sigfox Module
Neo6M GPS Modul
HM10 ZS-040 BLE module
SIM800L
Netzclub Simkarte

Nützliche Links:

Zwischenpräsentation: Folien

Wir sind aktuell dabei unsere Module fertig einzubinden und den Energieverbrauch zu messen. Grundsätzlich haben wir es jetzt geschafft die verschiedenen Lokalisierungsverfahren zu implementieren (GPS, Wifi Triangulierung) und sind jetzt noch dran die Kommunikation mit einem Backend fertig zumachen:

Sigfox: Wir haben uns hier ein Devboard besorgt mit dem Daten von einem Microcontroller ins Sigfox Netwerk schicken können und kommunizieren mit unserem Modulen, über UART(Serielle Kommunikation) und AT-Kommands , was mit Libraries für unsere Microcontroller out of the box funktioniert hat.

Learning: Statt selber zu versuchen an einem 1x1cm Chip rumzulöten, kann es sich lohnen einfach das Devboard zu bestellen und man hat am ende weniger Kosten und Aufwand.

GSM: Hier wollen wir uns mal die Kommunikation per SMS und GPRS mit einem MQTT-Broker anschauen. Wir sind gerade noch dabei eine neue SIM-Karte zu organisieren und wollen dann mal vergleichen wie der Stromverbrauch zum senden des Standorts ist und wie das GSM Modul im Sleepmode abschneidet. Die Schwierigkeit aktuell ist hier noch, dass wir über die verfügbaren AT-Commands recht schwer rausfinden / debuggen können, warum genau die Übertragung nicht funktioniert.

Entwickelt haben wir aktuell hauptsächlich direkt in der Arduino IDE oder in VS-Code. Mit beidem hatten wir bisher wenig Schwierigkeiten und für unsere Zwecke war es total ausreichend, da unsere Code-base nicht allzu komplex ist.

Wie gesagt, sind wir außerdem recht viel mit dem Thema Energiemessen beschäftigt: Wir hatten es hierzu erst über das Oszilloskop versucht, indem wir an einem zusätzlichen Widerstand die Spannung messen und uns dann den Strom ausrechnen. Allerdings hatten wir hier keinen Widerstand der niedrig genug wäre, sodass er unsere Schaltung nicht beinflusst hätte.

Wir sind deswegen dazu übergegangen das Agilent Multimeter zu nutzen, was nach anfänglichen Schwierigkeiten jetzt einmal eingestellt ist und zuverlässig Ergebnisse liefert. Wer damit leben kann "nur" maximal 55 Samples (je nach Anzahl Nachkommastellen) pro Sekunde zu bekommen, dem können wir empfehlen über die RS-232 Schnittstelle und den RS232-USB Adapter den wir besorgt haben zu messen. An eurem PC könnte ihr dann einfach mit cat oder screen vom seriellen Port auslesen. Wichtig ist nur, dass ihr an eurem Rechner die richtigen Einstellungen für die Serielle Kommunikation habt. Das Manual von dem Multimeter war hier recht nervig, weil "STRG+F" in einem schlecht gescannten Dokument nicht funktioniert :(

Deswegen hier die RS-232 Einstellungen die das Multimeter nutzt:

Baud Rate und Parität können am Multimeter verändet werden (Siehe Dokumentation Seite 92ff)
- Aktuell eingestellt haben wir 9600 Baud (max Wert) und 8 Databits ohne Parität
1 Startbit
2 (!) Stopbits
Es wird außerdem ein Hardware Handshake im Protokoll genutzt

Und falls ihr nach einer Woche ins Lab kommt, wieder messen wollt und aufeinmal dass Multimeter nur Error ohne Ende ausgibt, haben sich sehr wahrscheinlich nur die Einstellungen an eurem PC für das Serielle Device geändert.

Endpräsentation: Folien

Hallo Zusammen!

Hier ein kleiner Überblick des finalen Stands unseres Projekts "Tracking Technologien" und einige Tipps für embedded Projekte.

Bestellt möglichst schnell benötigte Hardware und geht davon aus, dass ein Ersatzteil oft nicht reichen wird
- Einiges an Hardware kommt kaputt an und einiges geht schnell mal kaputt...
Wenn ihr Hardware bestellt stellt entweder sicher, dass es Original-Produkte sind oder rechnet zumindest damit dass sie sich nicht verhalten werden wie erwartet
Macht euch zu beginn des Projekts Gedanken darüber was beschränkende Ressourcen sein werden. Oft gibt es spezielle Hardware, mit der ihr deutlich bessere Werte rausholen könnt (Zum Beispiel ESPs oder Arduinos die out-of-the-box deutlich weniger Strom verbrauchen)
Am Anfang des Projekts oder bei kleinen Projekten kann es ausreichend sein einfach die Arduino IDE zu nutzen, wenn alles gut läuft, könnt ihr in 2min euer erstes Programm auf dem Microcontroller laufen haben und müsst euch keine zusätzlichen Gedanken machen.
Wenn ihr Strom messen wollt:
- Die Nutzung des Oszilloskop dafür ist eher nicht empfehlenswert. Empfehlenswert ist der Einsatz des Oszilloskops eher, wenn ihr Daten erwartet aber nichts ankommt...
- Spart euch die Arbeit es mit dem Oszilloskop oder dem Agilent Multimeter zu probieren, sondern nutzt direkt das neue Nordic Power Profiler Kit

Zum Schluss noch der Link zum Github Repository -> https://github.com/rohansaw/EOS-Tracking-Resources

Viele Grüße

Das Tracking-Technologien Team

DIY V̶R̶ Motion-Controller (Maximilian, Otto)

Zwischenpräsentation: Folien

Hardware:

ESP32-C3 (Controller)
BMI160 (6DOF sensors, multiple)
TCA9548A (I2C multiplexer)
18650 LiPo Battery
a generic USB-C battery management module for 18650 cells
Analog inputs: a Joystick, push buttons
Resistors, different XH254 cables, perfboard, breadboards...

Zunächst wollen wir anfangen mit Learnings allgemeiner Natur:

TL;DR Benutzt platform.io für Arduino.

Die von uns genutzte Arduino CMake Toolchain sieht von außen vielversprechend aus und funktioniert im Großen und Ganzen ziemlich gut, aber an kleinen Details hadert man doch recht viel. Beispielsweise integriert sie das Logging Framework ESPLOG aus ESP-IDF, jedoch funktioniert die Konfiguration der Verbosity-Level zumindest bei einer etwas komplizierteren Projektstruktur wie bei uns (mehrere static library targets, ein executable) nicht so einfach, wie die angebotenen CMake-Konfigurationsparameter ("BoardOptions") suggerieren. Hinzu kommt, dass man beim Ändern der CMakeLists.txt's häufiger mal das CMake Projekt komplett frisch generieren muss, weil sich irgendwas festgefahren hat und CMake nur noch unverständliche Fehler wirft. Der aktuelle Master Commit der Toolchain (ca. Mitte 2020, also schon länger nicht mehr angerührt) kommt zudem mit den aktuellen Versionen der Arduino Board Definitions für die ESP32s gar nicht zurecht, da mussten wir erst auf einen manuellen Fix, der in einem PR steckt ausweichen. Wenn wir mal wieder was mit Arduino machen, werden wir vermutlich mal Platform.io ausprobieren, damit scheinen ja auch einige von euch anderen Gruppen ganz gute Erfahrungen gemacht zu haben. Vielleicht hätte man auch ausprobieren können, wie gut die ESP-IDF sich schlagen würde und ob dessen Bluetooth-Stack Implementierung einfacher zu nutzen gewesen wäre.

TL;DR Modularisiert eure Firmware.

Auch wenn es uns die Toolchain wie eben beschrieben nicht immer leicht gemacht hat, hat es sich gelohnt, die Firmware in einzelne Module, welche grob Blöcke von Funktionalitäten rund um das Projekt abbilden, aufzuspalten. Das hat uns ermöglicht, leicht simple Executable-Targets bzw. Sketches zu bauen, welche die entsprechende Funktion isolieren und so leicht testbar machen. Der Vorteil hierbei ist neben schnellerem Compile-Flash-Test Zyklen auch mehr Komfort beim (System.println-)Debugging.

TL;DR Vertraut niemals blind StackOverflow Antworten.

An einer Stelle wollten wir Float32 Werte unter Verlust komprimieren, so dass sie in 16 Bit passen und wir später weniger Daten pro Update Paket übertragen müssen. Dazu fanden wir einen vielversprechenden Stackoverflow Schnipsel, der jedoch, wie sich später herausstellte nur für einen sehr eingeschränkten Wertebereich anständig funktionierte und darüberhinaus zu häufigen unerklärlichen Sprüngen auf 1.0 führte. Einfache 2 Zeilen selbstgeschriebener Code, die unseren Float im Wertebereich -1.0 bis 1.0 linear auf einen Wert zwischen 0 und 2^16-1 abbilden, verrichteten dann den Fehler ohne Probleme.

TL;DR Günstiges Modul --> im Zweifel schlecht dokumentiert.

Für unseren Controller haben wir uns für einen sehr neuen Chip (2021 vorgestellt) entschiedenen, den ESP32-C3. Für diesen existieren zwar offizielle Development-Kits des Herstellers, diese waren aber leider Ende letzten Jahres nicht bei Mouser (oder einem vergleichbaren, seriösen Händler) verfügbar. Deshalb haben wir auf ein Modul eines chinesischen Händlers zurückgegriffen, welches darüberhinaus auch nur knapp die Hälfte gekostet hat. Letztendlich hat es seinen Dienst getan, jedoch ließ die Dokumentation stark zu wünschen übrig. Beispielsweise sollte I2C auf den meisten Pins funktionieren, (die Ausgänge des Hardware-I2C Moduls im ESP32 lassen sich nach Wahl auf fast alle Pins legen), jedoch haben wir nur nach sehr viel Herumprobierens und -messens eine Kombination von Pins gefunden, auf denen dann die Kommunikation gelang. Fehler mit anderen Pins war häufig ein falscher Logic-Level (z.B. nur 2V statt 3.3V), den wir uns aus der uns vorliegenden Dokumentation nicht erklären konnten.

TL;DR low-level cross-platform Bluetooth-Stack libraries kaum verbreitet und gar nicht so portabel.

Wir hatten von Anfang an vor low-level Treiber für den Controller zu schreiben, d.h. in C(++) bzw. Rust. Jedoch stellte sich heraus, dass die meisten cross-plattform Bluetooth-Bibliotheken eher in Python oder anderen high-level Sprachen verfügbar waren. Qt Bluetooth konnten wir in unserer Toolchain nicht zum Laufen bekommen und haben schlussendlich die relativ unbekannte Rust Library btleplug (mit eher speziellem Ursprung) nutzen müssen. Dies war auch der Grund, warum wir für das Projekt Rust gelernt haben (auch wenn wir davor schon motiviert waren, diese Sprache mal auszuprobieren). Während der cross-platform Entwicklung mussten wir feststellen, dass das Verhalten zwischen Windows, Linux und Mac nicht konsistent war und zum Teil weitere Calls benötigte um dasselbe Verhalten herbeizuführen.

Final Note: Wir wussten von Anfang an, dass wir einen etwas zu großen Feature-Scope für das Projekt gewählt hatten. Dies hat sich am Ende auch bestätigt :) Dennoch war dies für uns eine willkommene Ausrede, verschiedene Dinge auszuprobieren und daran Erfahrungen zu sammeln.

Die Modularisierung, die wir eben schon angesprochen haben, hat sich tatsächlich auch beim Prototypen basteln wiedergefunden: ziemlich unabhängig haben wir Controller (Sensoren, Knöpfe, Controller) sowie Stromversorgung (Akku, battery protection & charging circuit, Spannungsregler) gebaut und getestet und erst ganz am Schluss zusammengesteckt.

Schließlich haben wir nun unseren Controller hinsichtlich der Akkulaufzeit auch nochmal einem Langzeittest unterzogen: im nicht verbundenen Idle-Modus mit Bluetooth-Advertising lief der Controller ca. 41 Stunden.

Unser Multi-Repository (enthält Firmware, Treiber und Software-Designdokumenation in Form von Schaubildern ist jetzt auch auf öffentlich gestellt. Wir würden uns darüber freuen, wenn das Projekt hiermit noch nicht zu Ende ist. Vielleicht finden wir bald Zeit weiter an Software und Hardware unseres Controllers zu arbeiten. Unabhängig davon sind natürlich all unsere Resultate als Open-Source veröffentlicht, so dass weitere Hacks daraus entstehen können.

Viele Grüße vom Team DIY Controller

Otto und Maximilian

Auftakt-Präsentation

Pro Gruppe sollte in ca. fünf bis zehn Minuten folgendes gezeigt werden:

Was ist eure Idee (Konzepte & Technologien, Hardware vs. Software) und wie werden die Themen "Eingebettete Systeme" sowie "Echtzeit" und/oder "beschränkte Ressourcen" tangiert?
Welche verschiedenen Wege gibt es, das Problem zu lösen, und welche bestehenden/verwandten Lösungen gibt es bereits? Wie könnt ihr die Schwierigkeit bei Bedarf verringern oder erhöhen?
Was habt ihr bereits recherchiert bzw. ausprobiert?
Wie sieht eure Hardware-Wunschliste aus?

Zwischenstandspräsentation

Was habt ihr über die Entwicklung von eingebetteten Systemen gelernt und mit welchen Problemen müsst ihr euch herumschlagen? Folgende Sachen solltet ihr in max. 20 Minuten zeigen:

Projektidee (Geht bitte davon aus, dass eure Projektidee nicht [mehr] allen bekannt ist.)
Was wurde bisher gemacht? (Hardware vs. Software)
Hello World (Es wäre total toll, auch den Quellcode und Details zu Frameworks & APIs, IDE, etc. zu sehen.)
Erste Ergebnisse (Es ist immer eine gute Idee, unterschiedliche Dinge zu vergleichen [Hardware, Algorithmen, Energie-Modi, Protokolle, …] bzw. Sachen zu messen [Energieverbrauch, Speicher, Zeitverhalten].)
Welche (ungeplanten) Probleme gab es und wie wurden sie gelöst?
Wie sieht der aktuelle Zeitplan aus (zu schnell, zu langsam, evtl. Backup-Lösungen)?

Endpräsentation

Zeitlich wäre es schön, wenn jede Gruppe max. 20 Minuten Präsentation und 10 Minuten für Diskussionen einplant – insgesamt also max. 30 Minuten pro Gruppe.

Wichtig für uns ist, dass ihr zeigt, was ihr alles gelernt habt. Daher würde sich anbieten, auf beispielsweise auf folgende Fragen einzugehen:

Was war eure Projektidee (geht bitte davon aus, dass eure Projektidee nicht [mehr] allen bekannt ist) und was habt ihr letztendlich alles umsetzen können?
Mit welcher Embedded-Hardware und welchen Protokollen habt ihr euch beschäftigt?
Mit welcher Entwicklungsumgebung (ggf. mit welchen Erweiterungen) habt ihr entwickelt? Wie gut funktionierte die Installation und anschließende Arbeit damit?
Welche Frameworks & APIs habt ihr verwendet? Wie sieht der Quellcode aus, um ein konkretes Problem zu lösen?
Habt ihr irgendwelche "Geheimtipps" (z.B. schwer auffindbare Dokumentation) oder Das-hätte-ich-gern-vorher-gewusst-Learnings?
Welche (ungeplanten) Probleme gab es und wie wurden sie gelöst?
Wie ist das Zeitverhalten? Wie hoch ist der Ressourcenverbrauch (CPU, Speicher, etc.)?
(Falls ihr Strom gemessen habt:) Welche Mess-Hardware habt ihr verwendet? Wie einfach war das bzw. gab es Tricks, um die Messungen praktikabel durchzuführen?

Leistungserfassung

Die Endnote wird in einer abschließenden mündlichen Prüfung ermittelt. Voraussetzung für die Zulassung zur Prüfung ist die regelmäßige Lösung der Aufgaben im Praktikum (Auftakt-, Zwischenstands- und End-Präsentation; Konsultationen).

Die Prüfungsdauer beträgt 30 Minuten (Einzelprüfung).
Es steht euch frei, in den ersten fünf Minuten selbst über ein beliebiges, lehrveranstaltungsbezogenes Thema zu referieren (ohne Hilfsmittel, d.h. keine Notizen) – beispielsweise über eure Projektarbeit. Vielleicht gibt es noch 1-2 Anschlussfragen zur Projektarbeit.
In den restlichen 25 Minuten widmen wir uns dann Fragen aus allen in der Vorlesung behandelten Themenbereichen (die nicht unbedingt eine Verbindung zur Projektarbeit haben müssen).

Eingebettete Betriebssysteme (2022/23)

Themen

Termine

Projektarbeit

Auftakt-Präsentation

Zwischenstandspräsentation

Endpräsentation

Leistungserfassung