Eingebettete Betriebssysteme (2021/22)

Prof. Dr. Andreas Polze
Projektbetreuung: Robert Schmid, Lukas Pirl, Daniel Richter
Termine: mittwochs, 11:00-12:30 Uhr, online (Vorlesung); donnerstags, 13:30-15:00 Uhr, online (externe Vorträge oder Projektarbeit)
Die Vorlesung findet ab sofort ausschließlich online statt.
Zoom-Raum: 5198175573 (Raum von Andreas Polze) | pwd: 4711
Zoom-Raum (Backup): https://uni-potsdam.zoom.us/my/eos21 (Raum von Daniel Richter)

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.

Termine

Im Wintersemester 2021/2022 findet eine Vorlesung zum Thema "Eingebettete Betriebssysteme" statt. Der Umfang der Lehrveranstaltung beträgt 4 SWS. In die Bewertung der Vorlesung (6 benotete Leistungspunkte) geht die Note einer mündlichen Prüfung zu 100% ein. Eine erfolgreiche Teilnahme am Praktikum ist Prüfungsvoraussetzung.

Anmeldung für die Mailingliste

Folien "Programming Embedded Systems"
Developing Embedded Software | Cross-Plattform Development | Microcontroler Development Cycle | Embedded System Development | Development Techniques | Emulation & Simulation | Download & Debugging | Building Executable Image Files | Hardware Initialization | Software Architectures | Simple Control Loop, Round Robin, Interrupts | Real-Time Operating System | Priorities | The GNU Compiler Collection

Folien "Intro & Performance Measures"
Introduction & Vocabulary | Task Value Functions | Hard vs. Soft Real-time Systems | Vocabulary | Mission Statement | Performance Measures | Problems of RT Computing | Structure of a Real-time System | Data Rates | Task Classes | Areas of Interest | Misconceptions | Real-time vs. Parallel Computing | Misleading Performance Measures | The Art of Real-Time Programming | RT Systems Engineering | Nothing new? | Guarantees are incomplete? | The Environment | The Ariane 5 Failure | A Space Shuttle Incident | Further Reading

Folien "Performance-Maße für Echtzeitysteme"
Performancemaße für Echtzeitysteme | Darstellung von Zeichen auf dem Bildschirm | Applikation bestimmt Bewertung eines Systems | Vernünftig klingendes Performancemaß kann fehlleiten | Eigenschaften für Performancemaße | Traditionelle Maße | 3-fach redundantes, fehlertolerantes System: TMR + voting | Performability | Beispiel: Landung eines Flugzeuges | Abschätzung von Programmlaufzeit | Quellcodeanalyse | Berücksichtigung von Pipelining | Zweistufige Pipeline | Caches | Virtual Memory

Folien "Case Study"
Purposes of example | Model train setup | Requirements | Requirements form

  1. Slides Dependability by Default (Clemens, Marcel)
  2. Slides Tracking-Technologien (Benedikt, Mark, Rohan)
  3. Slides DRONE - Diy Rotator version ONE (Tobias, Felix, Jan-Eric)
  4. Slides ∿↭〰️ - Radweg-Qualitäts-Messer (Benito, Tim)
  5. Slides YETI - Your Exclusive Tracking Infrastructure (Justus, Philipp, Tobias)
  6. DIY V̶R̶ Motion-Controller (Maximilian, Otto)

Folien "Case Study" | Tafelbild 1
Purposes of example | Model train setup | Requirements | Requirements form | Digital Command Control | DCC documents | DCC electrical standard | DCC communication standard | DCC packet types | Conceptual specification | Basic system commands | Typical control sequence | Message classes | Roles of message classes | Subsystem collaboration diagram | System structure modeling | Major subsystem roles | Classes, roles & class descriptions | Control input sequence diagram | Formatter operate behavior | Panel-active behavior | Setting the speed | Sequence diagram for setspeed command | Controller operate behavior | Refined command classes | Summary

Folien "Scheduling & Task Assignment" | Tafelbild 2 | Tafelbild 3
Scheduling for Real-Time Systems | Task Assignment and Scheduling | Task Dependency Graph | Periodicity | Feasibility of a Schedule | Preemptive vs. non-preemptive Scheduling | Uni-processor Scheduling

Folien "Scheduling & Task Assignment"
Multiprocessor Scheduling | Scheduling Problems | Rate Monotonic Scheduling (RMS) | RMS Schedulability | Discussion of RMS Schedulability | Example for RMS Schedulability | Graphical Representation of RMS-Schedulability | Sporadic Tasks | Transient Overload | Earliest Deadline First (EDF) | EDF Schedulability | Critical Sections | Priority Inheritance Protocol | Priority Ceiling Protocol | Requirements for a RT OS | Further Reading

Folien "Memory Management"
Memory Management for Embedded Systems | Motivation & Background | Segmentation | Segment Table | Paging | Paging Hardware | Virtual Memory | Virtual Memory with Swapping/Paging | Problems of classical approaches used in Embedded Systems | Real Time with Virtual Memory Memory Locking / Pinning | Real-Time Programming with Virtual Memory | Real-Time Memory Management | Memory Mapping | Memory Allocation | Static Memory Allocation | Dynamic Memory Allocation in Embedded Systems | Memory Management with Linked Lists | Implementing malloc() using a static allocation array | Finding Free Blocks Quickly | Free Operation | Memory Management with Bitmaps | Fragmentation | Dynamic Memory Allocation Buddy Systems | Buddy System Algorithm | Allocation in bounded time | Buddy System Deallocation

Folien "Memory Management"
Dynamic Memory Allocation Buddy Systems | Buddy System Algorithm | Allocation in bounded time | Buddy System Deallocation | Fixed-size Memory Management Segregated Free Lists | Blocking vs. Non-Blocking Memory Functions | Implementation of a blocking malloc() | Real Time Automatic Garbage Collection | Literature | QNX | Windows CE VirtualAlloc() | RTLinux | Palm OS | Memory Access | Harvard vs. von Neumann | Effects of Caches | Memory Devices Random Access Memory | Timing of a SRAM Chip | Synchronous DRAM | Memory Device Characteristics | Mapping Executable Images to Target Systems | Mapping Executables | Memory Functional Testing | Memory Faults | March Memory Testing | Zero-One Test Pattern | Checkerboard Pattern | Galloping (ping-pong) pattern (GALPAT) | Functional Memory Tests

Technische Informatik II - Maschinenprogrammierungskonzepte | Diskussion Assembler - add-Instruktion | Diskussion Assembler - Funktionsaufrufe

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

    spannende Links:

    Hardware:

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

    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...
  3. Slides ∿↭〰️ - Radweg-Qualitäts-Messer (Benito, Tim)

    Hardware:

    • Accelerometer MPU-6050, MPU-9250, LIS3DH
    • CPU und BoardNodeMCU v3 ESP8266
    • Akku LP-503562
    • Ladeplatine Berrybase CHB-LIP1
    • GPS-Modul GYNEO6MV2
  1. Slides YETI - Your Exclusive Tracking Infrastructure (Justus, Philipp, Tobias)

    Hardware:

    • HELTEC LoRa 32 V2 (ESP mit integriertem Lora)
    • MPU 6050 (Gyro/Acceleration)
    • GY-GPS6MV2 (GPS)
  2. Slides Dependability by Default (Clemens, Marcel)

  3. Slides Tracking-Technologien (Benedikt, Mark, Rohan)

    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:

Folien "Interrupts & Exceptions"
Masking | Interrupt Vectors | Programmable Interrupt Controller | Synchronous Interrupts: Exceptions | Difference hardware / software interrupt | Classes of Exceptions | Interrupts | Traps | Faults | Aborts | Privileged Mode (User-/Kernelmode) | Interrupt Service Handler & Interrupt Service Routines | Interrupt Handling | Interrupt overhead | Interrupt Latency | Sources of Interrupt Latency | Interrupt Nesting | Interrupt Sharing | Scheduling Multiple Devices | Weak (non-preemptive) Priorities | Recurring Interrupts | Global System Priorities | Deferred Service Routine | Deferred Interrupt Routine | Implementing an Interrupt Service Routine | Interrupts in the I/O Subsystem | Interfacing Interrupt- / Exception Handling | eCos | Setting up Exception Handlers | Standard exception vectors supported by most IA32 CPUs | eCos Interrupt Handling | eCos Interrupt Configuration | Windows CE.Net | OAL ISR Handling | Installable ISRs | IST Interrupt Handling (Interrupt Initialization, IST-Interrupt Service Thread) | Windows Ce.Net ISR Latency | Windows Ce.Net IST Latency

Folien "Clock Synchronization"
Motivation | Examples | Time Keeping | Time Measurement | Coordinated Universal Time (UTC) | Skew between computer clocks in a distributed system | Modes of synchronisation | Algorithms for clock synchronisation | Cristian algorithm (1989) | Berkeley algorithm (1989) | Network Time Protocol (1985) | NTP message exchange | Accuracy of NTP | Logical time and logical clocks | Lamport Logical Clocks (1978) | Lamport Timestamps | Vector Clocks | Vector Timestamps | Summary: Clock Synchronization

Folien "Real-Time Communication"
Characteristics of RT Comm | Categories of RT communication | Example: multi hop network | Model for Real-Time Communication | RT Traffic Model | Performance Metrics for RT Comm. | Communications media | Passive star topology | Network topologies | Meshes and toruses | Hypercubes | Embedding a hypercube in a passive star - wavelength allocation | Multistage network | Sending Messages | Media access | Media Access - physical problems | Protocols

Folien "Real-Time Communication"
Protocols | VTCSMA | Operation of VTCSMA | Variations of VTCSMA | VTCSMA Example | Window protocol | Window protocol - algorithm | Window protocol - discussion | Token-based protocols | Operation of timed token protocol | Claim token protocol | Token ring protocol | Operation of token ring protocol | Schedulability Criterion for token ring protocol | Token ring protocol - example | Hierarchical round robin protocol

Folien "Feldbusse"
Eigenschaften mobiler und eingebetteter Systeme: Feldbusse | Architektur eines Echtzeitsystems | Feldbusse | Beispiel: CAN | Funktion | Protokoll | Arbitrierung | Bitstuffing | Harte Echtze | Fixed Priority Scheduling | Scheduling | Längste Übertragungszeiten | Längste Wartezeit (Queuing Time) | Blocking Time | Längste Queuing Time und Latency | Beispiel | Fehlererkennung | Fehlerbehandlung | Fault Confinement | Beispiel: TTP/A | Protokoll | Fehlerbehandlung | Beispiel: ByteFlight | Ideen | Systemüberblick | Protokoll | Nachrichtenformat

Folien "Ada"
Ada history | Ada - the name | Significant Language Features | Hello World in Ada | Packages - another example | Multitasking in Ada | Tasks - an example | Task types and task objects | Programming with tasks | Ada Rendezvous | Callee may control rendezvous | Guarded select | Select at a glance | Caller may control select | Priorities on task entries | Protected Objects | Support for Interrupts | Package Ada.Interrupts | Priorities | Task Dispatch - Standard Policy | Scheduling Scenario - Preemption | Priority Ceiling Locking | Priority Ceiling Protocol | Entry Queuing Policies | Dynamic Priorities | The Notion of Time | Synchronous Task Control | Asynchronous Task Control | Example: Periodic Task | Example: Interrupt-driven Task | The Ravenscar Profile | Conclusions - Ada for RT Systems

Light Years Ahead | The 1969 Apollo Guidance Computer - The eventful landing

Folien "RT Java"
History | Motivation | Real Time Specification for Java (RTSJ) | RTSJ: Major Specification Features | RTSJ Scheduling | Threads | RealTimeThread | Periodic Threads | Scheduler | Asynchronous Event Handling | AynchEvent Class | Interrupt Handling Example | Time | Timers | Timer Example | Asynchronous Transfer of Control | Asynchronously Interrupted Exception | Memory Management | Scoped Memory | Scoped Memory - Types | ScopedMemory Example | Nested Scoped Memory | Immortal Memory | Budgeted allocation | Assignment restrictions | Memory Area - Classes | Garbage Collection | Real-time garbage collection | Incremental Collector - Tri-Color Marking | Automatic garbage collection in RTSJ | Physical Memory Access | Synchronization | Priority Inversion | Handling Posix-Signals | Realtime Security | Realtime System | RTSJ Implementations | jRate – Overview - Precompilation | JamaicaVM – aicas GmbH | J Consortium | RTJWG View of the Core | The Core Registry | Core Deployment | Distributed RTSJ

Folien "Real-Time Systems with Windows CE"
Definition of a Real-Time System | Requirements for a RT OS | Real-Time Systems with Windows CE | Windows CE Characteristics | Windows CE Modules | Windows CE System Architecture (5.0 & earlier) | Kernel | Scheduling | Threads and Thread Priority | Priority Assignment | Priority Inheritance | Thread Synchronization | CE 6.0 User Processes | CE 6.0 Kernel | Application Programs in CE | Kernel (CE 6.0 & later) | Virtual Memory: Slot Model (CE 5.0 & earlier) | Virtual Memory & Real-Time | Persistent Storage | Memory Setup In CE 6.0 | What is in Memory? | Communications Interface | Graphics, Windowing, and Events Subsystem (GWE) | Graphics Device Interface (GDI) | Device Drivers | Interrupt Handling: IRQs, ISRs, and ISTs | Windows CE Interrupt Architecture - Nested interrupts | Interrupt Architecture | ISR and IST Model | Interrupt Block Diagram | Windows CE: Architectural Remarks | Bounded Interrupt Latency | Validating the Real-time Performance of Windows CE | Performance Tools | Windows CE Has Deterministic Performance! | Getting Real-Time Performance

Folien "RT Linux"
Real-Time Extensions for Linux | RTLinux History | RTLinux Overview | Motivation for a Real-Time Linux | Linux Architecture | RTLinux Architecture | Basic Concept: Interrupt Emulation | Interrupt Emulation: Soft Interrupts | Interrupt Emulation: S_IRET Macro | Interrupt Emulation: Interrupt Handler | RTLinux Modules | Threads | Threads Scheduling | Scheduler Implementations | RTLinux Inter Process Communication | Real-Time FIFOS API | Synchronisation: Mutex | Synchronisation: Semaphores | Physical Memory and I/O Port Access | Interrupt Handling: Soft Interrupts | Interrupt Handling: Hard Interrupts | Timing API | Implementing RTLinux Applications | Higher Striker - Real-Time Linux and Periodic Threads | Installing RTLinux | Real-Time Linux Implementations | Real-Time Application Interface (RTAI) | Typical Performance | FSMLabs RTLinuxPro 2.0 Features | RTLinuxPro FIFOs | RTLinuxPro Example: A Real-Time Thread | RTLinuxPro Example: Main | Low Latency Kernel Patches | CPU-Shielding - Real-Time for SMP

Folien "eCos"
Embedded Configurable Operating System | History | eCos in Space | eCos Overview | An Application using eCos „Hello, World!“

Folien "Embedded OS Standards"
Embedded Operating System Standards | OSEK/VDX Standard | OSEK/VDX Overview | System philosophy | OSEK/VDX Special support for automotive requirements | Conformance Classes | Basic Task State Model | Extended Task State Model | Conformance Classes Minimum requirements | OSEK Scheduling | Scheduling Policies | Processing levels of the OSEK operating system | OSEK Interrupt Processing | Event mechanism | Synchronization of preemptable extended tasks | Resource Management | OSEK Priority Ceiling Protocol with extensions for interrupt levels | OSEK Priority Ceiling | Hook Routines | OSEK System Start-up | API service restrictions | OSEK/VDX COM | OSEK/VDX COM Hardware Abstraction | OSEK COM : Periodic Transmission | OSEK Implementation Language | OIL Examples | OIL and Application Code | OSEKtime Overview | OSEKtime Architecture | OSEKtime Task Model | Time-Triggered Scheduling | Processing Levels | PURE Operating System Family | OSEK/PURE System Architecture | PURE nucleus building blocks | Configuration Building Blocks | PURE Nucleus Family Tree | PURE OSEK Extension

Slides Dependability by Default (Clemens, Marcel)

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

Slides Tracking-Technologien (Benedikt, Mark, Rohan)

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

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

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

Themen - Vorlesung

Im Vorlesungsteil werden 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

Folgend finden sich Unterlagen zu den Vorlesungen, die laufend ergänzt werden. Zur vertiefenden Lektüre finden sich auch Verweise auf Inhalte, die über das in der Vorlesung gezeigte Material hinausgehen.

Buch "Computers as Components"

Folien "Programming Embedded Systems"
Developing Embedded Software | Cross-Plattform Development | Microcontroler Development Cycle | Embedded System Development | Development Techniques | Emulation & Simulation | Download & Debugging | Building Executable Image Files | Hardware Initialization | Software Architectures | Simple Control Loop, Round Robin, Interrupts | Real-Time Operating System | Priorities | The GNU Compiler Collection

Folien "Embedded System Design"
Embedding a computer | Examples | Early history | Microprocessor varieties | Application examples | Automotive embedded systems | BMW 850i brake and stability control system | Characteristics of embedded systems | Functional complexity | Real-time operation | Non-functional requirements | Design teams | Why use microprocessors? | The performance paradox | Power | Platforms | The physics of software | What does “performance” mean? | Characterizing performance | Challenges in embedded system design | Design methodologies | Design goals | Levels of abstraction | Top-down vs. bottom-up | Stepwise refinement | Requirements | Functional vs. nonfunctional requirements | Our requirements form | Example: GPS moving map requirements | Specification | Architecture design | GPS moving map block diagram | GPS moving map hardware architecture | GPS moving map software architecture | Designing hardware and software components | System integration | Summary

Folien "Case Study"
Purposes of example | Model train setup | Requirements | Requirements form | Digital Command Control | DCC documents | DCC electrical standard | DCC communication standard | DCC packet types | Conceptual specification | Basic system commands | Typical control sequence | Message classes | Roles of message classes | Subsystem collaboration diagram | System structure modeling | Major subsystem roles | Classes, roles & class descriptions | Control input sequence diagram | Formatter operate behavior | Panel-active behavior | Setting the speed | Sequence diagram for setspeed command | Controller operate behavior | Refined command classes | Summary

Folien "Embedded Lifecycle"

Warum halte ich heute diesen Vortrag? | Disclaimer | Produktlebenszyklus - Entwicklungs-Phase 0: Bevor es losgeht | Zertifizierungen | Hardwareplanung first, Software second | Realistische Zahlen für Projekte | Eval Board | SOM – System on a Module | Kundenanforderungen | Produktlebenszyklus - Entwicklungs-Phase 1: Zu wenig Prototypen | Software-Stack Typische Architektur | Architekturen “Der Klassiker” | Von der Hardware bis zum eigenen Code | Produktlebenszyklus - Entwicklungs-Phase 2: Kunde sieht Produkt zum 1. Mal | Alles ändert sich | Entwicklungsalltag | Entwicklungsalltag OS: Yocto Project | Produktlebenszyklus Entwicklungs-Phase 3: Start of Production SOP | SOP naht – Die Stunde der Performanceprobleme | Erfahrung: 5 Jahre Performance Consulting | Die Klassiker | Das Werkzeug #1: Linux Perf & Flamegraphs | Sonstige Alltägliche Werkzeuge | Produktlebenszyklus - Entwicklungs-Phase 4: Erste Hardware Beim Endkunden | Ängste | Gerät wird zum “Brick” | Strategien gegen Bricks | Updates | Crashes im Feld | Verschiedenes | Security: Das ‘S’ in IOT steht für Sicherheit | Datum und Zeit | Lizenzen | End Of Life

Tools: Der Star - Hotspot, Für Memory - Heaptrack, Qt auf dem Gerät debuggen - Gammaray

Folien "Einführung in die sicherheitskritische SW-Entwicklung" & "Segregation von Anwendungen"
Einführung in die sicherheitskritische SW Entwicklung | Einführung Object Controller | Phasen | Beispiel | SIL x | Organisatorische Massnahmen | V-Modell | Segregation von Anwendungen | Wann ist es erforderlich Anwendungen zu segregieren? | Hardware basierte Segregation | Software basierte Segregation | Beispiel aus der Luftfahrt

Folien "Performance Measures"
Introduction & Vocabulary | Task Value Functions | Hard vs. Soft Real-time Systems | Vocabulary | Mission Statement | Performance Measures | Problems of RT Computing | Structure of a Real-time System | Data Rates | Task Classes | Areas of Interest | Misconceptions | Real-time vs. Parallel Computing | Misleading Performance Measures | The Art of Real-Time Programming | RT Systems Engineering | Nothing new? | Guarantees are incomplete? | The Environment | The Ariane 5 Failure | A Space Shuttle Incident | Further Reading

Folien "Performance-Maße für Echtzeitysteme"
Performancemaße für Echtzeitysteme | Darstellung von Zeichen auf dem Bildschirm | Applikation bestimmt Bewertung eines Systems | Vernünftig klingendes Performancemaß kann fehlleiten | Eigenschaften für Performancemaße | Traditionelle Maße | 3-fach redundantes, fehlertolerantes System: TMR + voting | Performability | Beispiel: Landung eines Flugzeuges | Abschätzung von Programmlaufzeit | Quellcodeanalyse | Berücksichtigung von Pipelining | Zweistufige Pipeline | Caches | Virtual Memory

What really happened on Mars
The Mars Pathfinder mission was widely proclaimed as “flawless” in the early days after its July 4th, 1997 landing on the Martian surface. Successes included its unconventional “landing” — bouncing onto the Martian surface surrounded by airbags, deploying the Sojourner rover, and gathering and transmitting voluminous data back to Earth, including the panoramic pictures that were such a hit on the Web. But a few days into the mission, not long after Pathfinder started gathering meteorological data, the spacecraft began experiencing system resets. The press reported these failures in terms such as “software glitches” and “the computer was trying to do too many things at once”. Read What really happened on Mars? Also, be sure to read this follow-up message from Glenn Reeves of JPL, who led the software team for the Mars Pathfinder spacecraft.

Folien "Scheduling & Task Assignment"
Scheduling for Real-Time Systems | Task Assignment and Scheduling | Task Dependency Graph | Periodicity | Feasibility of a Schedule | Preemptive vs. non-preemptive Scheduling | Uni-processor Scheduling | Multiprocessor Scheduling | Scheduling Problems | Rate Monotonic Scheduling (RMS) | RMS Schedulability | Discussion of RMS Schedulability | Example for RMS Schedulability | Graphical Representation of RMS-Schedulability | Sporadic Tasks | Transient Overload | Earliest Deadline First (EDF) | EDF Schedulability | Critical Sections | Priority Inheritance Protocol | Priority Ceiling Protocol | Requirements for a RT OS | Further Reading

Folien "Scheduling for Real-time Systems"
scheduling for real-time systems | terminology | periodic, sporadic, aperiodic | motivation | scheduling | offline vs. online | static vs. dynamic priorities | preemptive vs. non-preemptive | optimization problems - task dependency graph | uniprocessor scheduling | rate-monotonic scheduling (RMS) | earliest deadline first (EDF) | shortcomings | multiple task versions | IRIS tasks | multiprocessor scheduling | utilization balancing | next fit | myopic | focused addressing and bidding | with precedence | challenges | priority inversion | priority inheritance protocol | priority ceiling protocol

Folien "Memory Management"
Memory Management for Embedded Systems | Motivation & Background | Segmentation | Segment Table | Paging | Paging Hardware | Virtual Memory | Virtual Memory with Swapping/Paging | Problems of classical approaches used in Embedded Systems | Real Time with Virtual Memory Memory Locking / Pinning | Real-Time Programming with Virtual Memory | Real-Time Memory Management | Memory Mapping | Memory Allocation | Static Memory Allocation | Dynamic Memory Allocation in Embedded Systems | Memory Management with Linked Lists | Implementing malloc() using a static allocation array | Finding Free Blocks Quickly | Free Operation | Memory Management with Bitmaps | Fragmentation | Dynamic Memory Allocation Buddy Systems | Buddy System Algorithm | Allocation in bounded time | Buddy System Deallocation | Fixed-size Memory Management Segregated Free Lists | Blocking vs. Non-Blocking Memory Functions | Implementation of a blocking malloc() | Real Time Automatic Garbage Collection | Literature | QNX | Windows CE VirtualAlloc() | RTLinux | Palm OS | Memory Access | Harvard vs. von Neumann | Effects of Caches | Memory Devices Random Access Memory | Timing of a SRAM Chip | Synchronous DRAM | Memory Device Characteristics | Mapping Executable Images to Target Systems | Mapping Executables | Memory Functional Testing | Memory Faults | March Memory Testing | Zero-One Test Pattern | Checkerboard Pattern | Galloping (ping-pong) pattern (GALPAT) | Functional Memory Tests

Folien "Memory Management in Embedded Operating Systems" | Demo-Quellen
Motivation | Classical Memory Management Techniques | Virtual Memory, Memory Management Unit | Segmentation | Paging | Memory Management and Real Time Programming | Problems in Real Time Systems | Avoid Memory Management | Memory Locking | Real Time Java | Real Time Java Memory Classes | Memory Mapping | Dynamic Memory Allocation | Static vs. Dynamic Allocation | Bitmaps | Linked Lists | Linked Lists: Allocation Strategies | Buddy System | Buddy System: Example | Segregated Free Lists | Blocking and Non-blocking memory functions | Real Time Garbage Collection | Examples: Memory Management in selected Real Time Systems - QNX, Windows CE, Windows 10 (IoT) with RTX, Real Time Linux, | almOS, FreeRTOS, embOS | Memory Access | Harvard vs. von Neumann Architecture | Caches | Memory Types | Functional Tests

Folien "Interrupts & Exceptions"
Masking | Interrupt Vectors | Programmable Interrupt Controller | Synchronous Interrupts: Exceptions | Difference hardware / software interrupt | Classes of Exceptions | Interrupts | Traps | Faults | Aborts | Privileged Mode (User-/Kernelmode) | Interrupt Service Handler & Interrupt Service Routines | Interrupt Handling | Interrupt overhead | Interrupt Latency | Sources of Interrupt Latency | Interrupt Nesting | Interrupt Sharing | Scheduling Multiple Devices | Weak (non-preemptive) Priorities | Recurring Interrupts | Global System Priorities | Deferred Service Routine | Deferred Interrupt Routine | Implementing an Interrupt Service Routine | Interrupts in the I/O Subsystem | Interfacing Interrupt- / Exception Handling | eCos | Setting up Exception Handlers | Standard exception vectors supported by most IA32 CPUs | eCos Interrupt Handling | eCos Interrupt Configuration | Windows CE.Net | OAL ISR Handling | Installable ISRs | IST Interrupt Handling (Interrupt Initialization, IST-Interrupt Service Thread) | Windows Ce.Net ISR Latency | Windows Ce.Net IST Latency

Folien "Real-Time Communication"
Characteristics of RT Comm | Categories of RT communication | Example: multi hop network | Model for Real-Time Communication | RT Traffic Model | Performance Metrics for RT Comm. | Communications media | Passive star topology | Network topologies | Meshes and toruses | Hypercubes | Embedding a hypercube in a passive star - wavelength allocation | Multistage network | Sending Messages | Media access | Media Access - physical problems | Protocols | VTCSMA | Operation of VTCSMA | Variations of VTCSMA | VTCSMA Example | Window protocol | Window protocol - algorithm | Window protocol - discussion | Token-based protocols | Operation of timed token protocol | Claim token protocol | Token ring protocol | Operation of token ring protocol | Schedulability Criterion for token ring protocol | Token ring protocol - example | Hierarchical round robin protocol

Folien "Echtzeitkommunikation"
Echtzeitkommunikation | Merkmale | Kategorien | Echtzeitkommunikation – Modell | Datenverkehrsmodell | Performance-Metriken für Echtzeitkommunikation | Übertragungsmedien | Passive Sterntopologie | Netzwerktopologien | Netz- und Ringtopologien | Hyperwürfel | Multistage Netzwerk | Nachrichtenvermittlung | Medien-/Kanalzugriff | Medien-/Kanalzugriff – physikalische Probleme | Protokolle | VTCSMA | VTCSMA Beispiel | 802.5 – Token Ring | Token Aufbau | Access Control - Priorität | ZigBee | Feldbusse | Feldbus-Standards (Auswahl) | Echtzeit Ethernet

Folien "Feldbusse"
Eigenschaften mobiler und eingebetteter Systeme: Feldbusse | Architektur eines Echtzeitsystems | Feldbusse | Beispiel: CAN | Funktion | Protokoll | Arbitrierung | Bitstuffing | Harte Echtze | Fixed Priority Scheduling | Scheduling | Längste Übertragungszeiten | Längste Wartezeit (Queuing Time) | Blocking Time | Längste Queuing Time und Latency | Beispiel | Fehlererkennung | Fehlerbehandlung | Fault Confinement | Beispiel: TTP/A | Protokoll | Fehlerbehandlung | Beispiel: ByteFlight | Ideen | Systemüberblick | Protokoll | Nachrichtenformat

Folien "Clock Synchronization"
Motivation | Examples | Time Keeping | Time Measurement | Coordinated Universal Time (UTC) | Skew between computer clocks in a distributed system | Modes of synchronisation | Algorithms for clock synchronisation | Cristian algorithm (1989) | Berkeley algorithm (1989) | Network Time Protocol (1985) | NTP message exchange | Accuracy of NTP | Logical time and logical clocks | Lamport Logical Clocks (1978) | Lamport Timestamps | Vector Clocks | Vector Timestamps | Summary: Clock Synchronization

IoT-Betriebssysteme: FreeRTOS, Contiki & Cooja, RIOT

Folien "Real-Time Systems with Windows CE"
Definition of a Real-Time System | Requirements for a RT OS | Real-Time Systems with Windows CE | Windows CE Characteristics | Windows CE Modules | Windows CE System Architecture (5.0 & earlier) | Kernel | Scheduling | Threads and Thread Priority | Priority Assignment | Priority Inheritance | Thread Synchronization | CE 6.0 User Processes | CE 6.0 Kernel | Application Programs in CE | Kernel (CE 6.0 & later) | Virtual Memory: Slot Model (CE 5.0 & earlier) | Virtual Memory & Real-Time | Persistent Storage | Memory Setup In CE 6.0 | What is in Memory? | Communications Interface | Graphics, Windowing, and Events Subsystem (GWE) | Graphics Device Interface (GDI) | Device Drivers | Interrupt Handling: IRQs, ISRs, and ISTs | Windows CE Interrupt Architecture - Nested interrupts | Interrupt Architecture | ISR and IST Model | Interrupt Block Diagram | Windows CE: Architectural Remarks | Bounded Interrupt Latency | Validating the Real-time Performance of Windows CE | Performance Tools | Windows CE Has Deterministic Performance! | Getting Real-Time Performance

Folien "RT Linux"
Real-Time Extensions for Linux | RTLinux History | RTLinux Overview | Motivation for a Real-Time Linux | Linux Architecture | RTLinux Architecture | Basic Concept: Interrupt Emulation | Interrupt Emulation: Soft Interrupts | Interrupt Emulation: S_IRET Macro | Interrupt Emulation: Interrupt Handler | RTLinux Modules | Threads | Threads Scheduling | Scheduler Implementations | RTLinux Inter Process Communication | Real-Time FIFOS API | Synchronisation: Mutex | Synchronisation: Semaphores | Physical Memory and I/O Port Access | Interrupt Handling: Soft Interrupts | Interrupt Handling: Hard Interrupts | Timing API | Implementing RTLinux Applications | Higher Striker - Real-Time Linux and Periodic Threads | Installing RTLinux | Real-Time Linux Implementations | Real-Time Application Interface (RTAI) | Typical Performance | FSMLabs RTLinuxPro 2.0 Features | RTLinuxPro FIFOs | RTLinuxPro Example: A Real-Time Thread | RTLinuxPro Example: Main | Low Latency Kernel Patches | CPU-Shielding - Real-Time for SMP

Folien "Embedded OS Standards"
Embedded Operating System Standards | OSEK/VDX Standard | OSEK/VDX Overview | System philosophy | OSEK/VDX Special support for automotive requirements | Conformance Classes | Basic Task State Model | Extended Task State Model | Conformance Classes Minimum requirements | OSEK Scheduling | Scheduling Policies | Processing levels of the OSEK operating system | OSEK Interrupt Processing | Event mechanism | Synchronization of preemptable extended tasks | Resource Management | OSEK Priority Ceiling Protocol with extensions for interrupt levels | OSEK Priority Ceiling | Hook Routines | OSEK System Start-up | API service restrictions | OSEK/VDX COM | OSEK/VDX COM Hardware Abstraction | OSEK COM : Periodic Transmission | OSEK Implementation Language | OIL Examples | OIL and Application Code | OSEKtime Overview | OSEKtime Architecture | OSEKtime Task Model | Time-Triggered Scheduling | Processing Levels | PURE Operating System Family | OSEK/PURE System Architecture | PURE nucleus building blocks | Configuration Building Blocks | PURE Nucleus Family Tree | PURE OSEK Extension | μITRON | ITRON Specification - History | Design Principles of the ITRON Specification | Adaptation in the μITRON Specification | μITRON Kernel Functions | Major Fields where ITRONspecification kernels are applied | Function levels of ITRON | μITRON System Configuration | eCos μITRON compatibility layers | POSIX | POSIX Real-Time Extensions | Real-Time Signals | POSIX : Real-Time Application Environment Profiles

Folien "eCos"
Embedded Configurable Operating System | History | eCos in Space | eCos Overview | An Application using eCos „Hello, World!“ | eCos Overview | Real-time Kernel Features | eCos License | Supported Processor Architectures | Configurability | Configuration Options | Compile-time Configuration | Graphical Configuration Tool | Selective Linking | Component Repository | Component Definition Language (CDL) | Packages | Templates | eCos Library Build Procedure | Application Build Procedure Size with Full eCos feature set | Hardware Abstraction Layer | HAL Modules | eCos Kernel | Interrupts and Exceptions (Summary) | eCos Interrupt Handling | Virtual Vectors | Virtual Vectors in eCos | The Scheduler | Multilevel Queue Scheduler | Bitmap Scheduler | Lottery Scheduler | Threads | Synchronization Mechanism | Other eCos Architecture Components | RedBoot ROM Monitor | RedBoot’s capabilities | Debug Environment | eCos Tests

Folien "RIOT-OS"
Internet of Things: Which OS? | The Internet of Things (IoT) | IoT: The operating system question | RIOT: The friendly IoT operating system | RIOT in a nutshell | RIOT: Positioning | RIOT: Fact sheet | RIOT: IoT development made easy | RIOT already runs on a wide range of IoT hardware | RIOT: Built to connect | Minimized Hardware-Dependent Code | RIOT APIs | RIOT user and developer evolution | RIOT Origins | RIOT stats | Join the RIOT | Potential Projects

Folien "The ARM processor"
ARM - A short History | ARM Products | RISC vs. CISC | The ARM Architecture | ARM Instruction Pipeline | Registers ARM7 | Load and Store Architecture | Current Processor Status Register (CPSR) | ARM Data Processing Instruction | Instruction Mnemonics | Conditional Execution | Condition Codes | Conditional Execution: Example | Data processing instructions | Addressing Modes - Offset Addressing | Addressing Modes - Pre-Index Addressing | Addressing Modes - Post-Index Addressing | Load and Store Multiple Operands | Status register transfer instructions | Arithmetic and Logic Instructions | Branch instructions | Branching and Subroutines | Subroutines - Example | The frame pointer | I/O Operations | Thumb Mode | How to change to Thumb mode and back | Thumb Mode vs. ARM Mode | Useful tools for targetting ARM | GNU Assembler | GNU ARM Assembler Example | Assembler Directives | Elf-Format Sections | Debugging Lego NXT | The Lego NXT-Platform | The Atmel AT91SAM7S256 | AT91SAM7S256 Memory Controller (MC) | Interrupts and Exceptions | Execution Modes and Registers | ARM Bootloader | Lego EV3

Folien "What is Ada?"
This is not yet another Ada tutorial | Ada origins and history | Ada overview | Some Ada concepts | Ada runtime systems | Ravenscar | SPARK Appendix | A personal journey with Ada | Getting started with Ada | Projects of interest for Railergy

Folien "Ada"
Ada history | Ada - the name | Significant Language Features | Hello World in Ada | Packages - another example | Multitasking in Ada | Tasks - an example | Task types and task objects | Programming with tasks | Ada Rendezvous | Callee may control rendezvous | Guarded select | Select at a glance | Caller may control select | Priorities on task entries | Protected Objects | Support for Interrupts | Package Ada.Interrupts | Priorities | Task Dispatch - Standard Policy | Scheduling Scenario - Preemption | Priority Ceiling Locking | Priority Ceiling Protocol | Entry Queuing Policies | Dynamic Priorities | The Notion of Time | Synchronous Task Control | Asynchronous Task Control | Example: Periodic Task | Example: Interrupt-driven Task | The Ravenscar Profile | Conclusions - Ada for RT Systems

Folien "Speicherprogrammierbare Steuerungen"
Motivation | Früher… | Einsatz | Aufbau | Verfügbare Arten | ABB AC500 PM595 | Siemens SIMATIC S7 | Fischertechnik + Beckhoff | Ansprechen einzelner Kontakte | Kommunikation | Programmierung | Programmabarbeitung | Eingabeprachen IEC 1131-1/3 | Anweisungsliste AWL | Kontaktplan KOP | Funktionsbausteinsprache FBS | Strukturierter Text ST | Ablaufsprache AS | Programmorganisation | Übertragbarkeit | Wann welche Sprache? | Heizungssteuerung mit SPS

Folien "RT Java"
History | Motivation | Real Time Specification for Java (RTSJ) | RTSJ: Major Specification Features | RTSJ Scheduling | Threads | RealTimeThread | Periodic Threads | Scheduler | Asynchronous Event Handling | AynchEvent Class | Interrupt Handling Example | Time | Timers | Timer Example | Asynchronous Transfer of Control | Asynchronously Interrupted Exception | Memory Management | Scoped Memory | Scoped Memory - Types | ScopedMemory Example | Nested Scoped Memory | Immortal Memory | Budgeted allocation | Assignment restrictions | Memory Area - Classes | Garbage Collection | Real-time garbage collection | Incremental Collector - Tri-Color Marking | Automatic garbage collection in RTSJ | Physical Memory Access | Synchronization | Priority Inversion | Handling Posix-Signals | Realtime Security | Realtime System | RTSJ Implementations | jRate – Overview - Precompilation | JamaicaVM – aicas GmbH | J Consortium | RTJWG View of the Core | The Core Registry | Core Deployment | Distributed RTSJ

Themen - 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.

Projektidee Slides

Hardware:

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

Zwischenpräsentation Slides

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 Slides

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

Projektidee Slides

spannende Links:

Hardware:

Zwischenpräsentation Slides

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 Slides

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

Projektidee Slides

Hardware:

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

Zwischenpräsentation Slides

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 Slides

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

Projektidee Slides

Zwischenpräsentation Slides

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 Slides

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

Projektidee Slides

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 Slides

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 Slides

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

Zwischenpräsentation Slides

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

Kick-Off-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:

  1. Projektidee (Geht bitte davon aus, dass eure Projektidee nicht [mehr] allen bekannt ist.)
  2. Was wurde bisher gemacht? (Hardware vs. Software)
  3. Hello World (Es wäre total toll, auch den Quellcode und Details zu Frameworks & APIs, IDE, etc. zu sehen.)
  4. Erste Ergebnisse (Es ist immer eine gute Idee, unterschiedliche Dinge zu vergleichen [Hardware, Algorithmen, Energie-Modi, Protokolle, …] bzw. Sachen zu messen [Energieverbrauch, Speicher, Zeitverhalten].)
  5. Welche (ungeplanten) Probleme gab es und wie wurden sie gelöst?
  6. 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 (Kick-Off-, Zwischenstands- und End-Präsentation; Konsultationen).

Termine für die mündliche Prüfung können unter https://osm.hpi.de/termin/eos-exam/ gebucht werden.

  • 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).