Technische Beeinflussbarkeit der Geschmacksache Kaffee - Benutzerbeiträge [de]

Systemsoftware

2026-04-27T21:39:49Z

Konstantin Rupprecht: Das ToDo Mehrkernnutzung und/oder Multitasking abgeschlossen (100)

<htmltag tagname="img" src="http://vg04.met.vgwort.de/na/4531f1734b324b72b2d7e566cdf639f0" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 
Die Systemsoftware lässt sich nicht ohne die Beachtung der Systemelektronik erstellen.

Für die Systemsoftware wurde ein mehrstufiger Entwicklungsprozess definiert:
# Nutzung einer MCU auf der MicroPython verwendet werden kann. Dies ist durch das STM32F411 nucleo Board der Basiselektronik bzw. durch den Raspberry Pi Pico der Multi-MCU-Elektronik gegeben.
# Auf der MCU werden lediglich die elementaren Grundfunktionen (GPIO schalten und erfassen, Messwert erfassen, PWM Ausgeben, Sollwert ausgeben, etc.) realisiert und über eine MicroPython zu MATLAB® Schnittstelle [41] wird die Funktionalität in einer MATLAB® GUI hergestellt.
# Die Softwareentwicklung startet mit der labortechnischen Espressomaschine und wird auf die weiteren Projekte schrittweise transportiert. Dazu ist die Maschinenelektronik gleich zu halten und es sind die gleichen Anschluss-Pins zu verwenden.
# Nach Abschluss der Testphase der MATLAB® Bedienung wird schrittweise die Betriebssoftware in MicroPython auf der MCU implementiert, so dass am Ende dieses Prozessschrittes die MATLAB®-Verbindung lediglich für weiterführende Datenerfassung und grafische Darstellungen verwendet wird, welche nicht mit dem Display der Maschine möglich ist oder dort nicht dargestellt werden soll.
# Ob eine Portierung des MicroPython-Codes nach Microcontroller C durchgeführt wird, ist derzeit nicht entschieden.

Es wurden mehrere, die Softwareentwicklung vorbereitende FMEAs durchgeführt. Die hierdurch entstandenen Dokumentation befinden sich in der Dokumentationsauflistung. Im weiteren wurde eine Projektarbeit zur Konzeptfindung für die Badienung durchgeführt. Auch die hierdurch entstandenen, teilweise auf die FMEA aufbauenden Dokumente befinden sich in der Dokumentationsliste.

= Projektdokumentationen und Beschreibungen =
* [[:Datei:20210228 Konzept Systemelektronik.pdf|Konzeptbeschreibung Systemelektronik]]
* [[:Datei:20210605 Workflow Embedded Systems.pdf|Workflow Embedded Systems]]
* [[:Datei:20200521 Bericht1 NerminArbi.pdf|Funktionsanalyse Boilerbefüllung, Tassenwärmung, Milchschäumen]]
* [[:Datei:20200518 Bericht halbauto Entkalkung Egger Alexander.pdf|Funktionsanalyse zur halbautomatischen Entkalkung]]
* [[:Datei:20200518 V0 4 Bericht Funktionsanalyse Rückspulung-Spulung Sladoje.pdf|Funktionsanalyse Rückspülung und Spülung]]
* [[:Datei:20200521 Bericht Espresso-Teewasserbezug Urbin.pdf|Funktionsanalyse Espresso und Teewasserbezug]]
* [[:Datei:20200522 Bericht Funktionsanalyse Energieeffizienz Egger Alexander.pdf|Funktionsanalyse Energieeffizienz]]
* [[:Datei:20200521 V2 Bericht Funktionsanalyse Bedienung Sladoje.pdf|Funktionsanalyse Bedienung]]
* [[:Datei:20200525 Bericht Abbildung aller Maschinen Urbin V2.pdf|Funktionsanalyse Abbildung aller Maschinen]]
* [[:Datei:20200609 Bericht Fehleranalyse Entschichtung.pdf|Fehleranalyse Entschichtung]]
* [[:Datei:20200610 Fehleranalyse Dampf Brühgruppe Sladoje.pdf|Fehleranalyse Brühgruppe und Dampfbezug]]
* [[:Datei:20200613 Bericht Fehleranalyse Mischer;Magnetventile V2.pdf|Fehleranalyse Mischer und Magnetventile]]
* [[:Datei:20200611 Bericht3 NerminArbi.pdf|Fehleranalyse Boiler]]
* [[:Datei:20200705 Dichtheitsprüfung.pdf|Dichtheitsprüfung]]
* [[:Datei:20200704 Massnahmen Urbin.pdf|Prüfkonzepte Magnetventile und Mischer]]
* [[:Datei:20200701 Maßnahmenanalyse NerminArbi.pdf|Maßnahmen Boiler]]
* [[:Datei:20200628 Maßnahmen Entschichtung zweiter Stand.pdf|Maßnahmen Entschichtung]]
* [[:Datei:20200627 Maßnahmenkonzept Brühguppe Dampf Sladoje.pdf|Maßnahmen Brühgruppe und Dampf]]
* [[:Datei:20200707_FMEA.xlsx|FMEA Tabelle]]
* [[:Datei:20201207_Bedienkonzept.pptx|PPT Simulation des Bedienkonzeptes]]
* [[:Datei:20210207_Bedienkonzept_Funktionsliste.xlsx|Bedienkonzept Funktionsliste]]
* [[:Datei:20210219_Bedienkonzept_Projektdokumentation.pdf|Bedienkonzept Projektdokumentation]]
* [[:Datei:HMProjektBedienoberflaecheEspresso.zip|MATLAB® GUI]]
* [[Entwicklung Systemsoftware SoSe2022]]
* [[Entwicklung Systemsoftware SoSe2023]]
* [[Mikrocontroller Programmierung in MicroPython WiSe 2025/26]]
* [[Mikrocontroller Programmierung in MicroPython SoSe 2026]]

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Programmcode Programmcode] =
Aktueller Programmcode und Änderungsdokumentation ab Jan 2023

= [http://www.institut-fuer-kaffeetechnologie.de/Intern/index.php?title=Software-Bugs Software-Bugs] =

= ToDo-Liste(n) Systemsoftware =

== Prioritätsangabe ==
Prio 1 - Abarbeitung zeitnah erforderlich 
Prio 2 - Abarbeitung erforderlich 
Prio 3 - Abarbeitung kann warten 
Prio 99 - Abarbeitung erfordert Vorarbeiten 

== Status ==
10 - Erfasst 
30 - in Bearbeitung 
50 - Lösung definiert 
70 - in Umsetzung 
90 - Umsetzung abgeschlossen 
99 - Abbruch per Beschluss (Dokumentation dazu erforderlich) 
100 - Maßnahme bestätigt 

= ToDo-Liste: MCUs - Verlagerung der Regelkreise aus der MATLAB®-GUI auf die Mikrocontroller der Steuerungselektronik =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Startprozedur]] || Konstantin Rupprecht / Loic Aboufiras|| 1 || 30 ||08.05.2026
|-
| [[Kommunikation per UART|UART Kommunikation zwischen den einzelnen MCUs]] || Konstantin Rupprecht|| 1 || 70 ||08.05.2026
|-
| [[Evaluation STM32H7 |Umstellung auf STM32H7]] || Konstantin Rupprecht|| 1 || 10 ||08.05.2026
|-
| [[Mehrkernnutzung und/oder Multitasking]] || Konstantin Rupprecht|| 1 || 100 ||08.05.2026
|-
| [[Integration eines Displays mit Touchfunktion]] || Loic Aboufiras|| 1 || 30 ||08.05.2026
|-
| [[Integration eines Vertikalhebels]] || Loic Aboufiras|| 1 || 30 ||12.06.2026
|-
| [[Maschinensimulator]] || Francis Booth|| 1 || 70 ||08.05.2026
|-
| [[Visualisierung und Interaktion über die MATLAB®-GUI|Wartungs-App]] || Felix Kerner|| 1 || 10 ||08.05.2026
|-
| [[Verlagerung des Füllstandsreglers auf das Basisboard|Verlagerung des Füllstandsreglers]] || Tillmann Haas|| 1 || 30 ||08.05.2026
|-
| [[Verlagerung der Boilerdruckregelung auf die Messplatine|Verlagerung der Boilerdruckregelung]] || Tillmann Haas|| 1 || 30 ||15.05.2026
|-
| [[Verlagerung des Mischtemperaturreglers auf das Basisboard|Verlagerung des Mischtemperaturreglers]] || Tillmann Haas|| 1 || 10 ||10.06.2026
|-
| [[Verlagerung des Durchflussreglers auf das Basisboard|Verlagerung des Durchflussreglers]] || Tillmann Haas|| 1 || 10 ||08.07.2026
|-
| [[Erstellung der Funktionssteuerung - Preinfusion auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Kaffeebezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Wasserbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Dampfbezug auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Spülen auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Erstellung der Funktionssteuerung - Grundreinigung auf dem Basisboard]] || || 2 || 10 ||
|-
| [[Visualisierung und Interaktion über eine WEB-Anwendung]] || || 1 || 10 ||
|}

= ToDo-Liste: Allgemeines =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Sicherheitsfunktionen]] || || 99 || 50 ||
|-
| [[ Übersicht über verbaute Aktorik und Sensorik in Tabellenform]] || || 2 || 90 ||
|-
| [[Stromsparmodus]] || || 99 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: Mechatronische Inbetriebnahme Glasboilermaschine =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Fehlerbehebungen]] || || 1 || 10 ||
|-
| [[Startprozedure]] || || 1 || 10 ||
|-
| [[Tankfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerfüllstandsregelung]] || || 1 || 10 ||
|-
| [[Boilerdruckregelung]] || || 1 || 10 ||
|-
| [[Mischwassertemperaturregelung]] || || 1 || 10 ||
|-
| [[Durchflussregelung]] || || 1 || 10 ||
|-
| [[Kaffeebezug]] || || 2 || 10 ||
|-
| [[Teebezug]] || || 1 || 10 ||
|-
| [[Temperatureinstellung über Vertikalhebel]] || || 1 || 10 ||
|-
| [[Simulation Handhebelmaschine]] || || 1 || 10 ||
|-
| [[Flush/Rückspülreinigung]] || || 1 || 10 ||
|-
| || || || ||
|}

= ToDo-Liste: MCUs - Hardwarenahe Software =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[Grundfunktionen der MCU und mehrere MCUs]] || || || 100 ||
|-
| Basisboard: [[Schalten Magnetventile (Labor) STM32-Basisboard]] MATLAB®GUI || || || 100
|-
| Basisboard: [[Pumpenansteuerung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Schrittmotorsteuerungen Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Tastenerkennung Basisboard Multi-MCU]] || || 1 || 10 ||
|-
| Basisboard: [[Füllstandserkennung Basisboard Multi-MCU]] || || || 100 ||
|-
| Basisboard: [[Durchflussmessung Basisnoard Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schalten Magnetventile SSR-Platine Multi-MCU]] || || || 100 ||
|-
| SSR-Platine: [[Schrittmotorsteuerungen SSR-Platine Multi-MCU]] || || || 100 ||
|-
| Messplatine: [[Messdatenerfassung Multi-MCU]] || || || 100 ||
|-
| || || || ||
|}

= ToDo-Liste der Grundlagenprogrammierung - MATLAB®-Funktionen und GUI =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[MATLAB®-GUI Start der App]] || || || ||
|-
| [[MATLAB®-GUI Initialisierung Multi-MCU]] || || || ||
|-
| [[MATLAB®-GUI Schalten Magnetventile]] || || || ||
|-
| [[MATLAB®-GUI Datensicherung]] || || || ||
|-
| [[Messwerte erfassen Multi-MCU]] || || || ||
|-
| [[Pumpenansteuerung Multi-MCU]] || || || ||
|-
| [[Füllstandsregler Multi-MCU]] || || || ||
|-
| [[Regler Boilerdruck Multi-MCU]] || || || ||
|-
| [[Mischregler Multi-MCU]] || || || ||
|-
| [[Durchflussregler Multi-MCU]] || || || ||
|-
| [[Misch-Durchfluss Kaskadenregelung Multi-MCU]] || || || ||
|-
| [[Preinfusion Multi-MCU]] || || || ||
|-
| [[einfacher Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Kaffeebezug Multi-MCU]] || || || ||
|-
| [[Wasserbezug Multi-MCU]] || || || ||
|-
| [[Dampfbezug Multi-MCU]] || || || ||
|-
| [[Spülvorgänge Multi-MCU]] || || || ||
|-
| [[Grundreinigung Multi-MCU]] || || || ||
|-
| [[Tastenbedienung Multi-MCU]] || || || ||
|-
| [[Display Multi-MCU]] || || || ||
|-
| [[Glasboiler Abtropfwanne]] || || || ||
|-
| [[Schrittmotorensteuerung Bypass]] || || || ||
|-
| [[Schrittmotorensteuerung Mischer]] || || || ||
|-
| [[Schrittmotorensteuerung Brühgruppendrossel]] || || || ||
|-
| [[Adaption an Multi-MCU - Neuprogrammierung MATLAB® GUI]] || || || ||
|-
| || || || ||
|-
| || || || ||
|-
| Dokumentation der Software mit STM32-Elektronik. Ein Betrieb dieser wird nicht mehr weiter verfolgt. || || || ||
|-
| [[Messwerte erfassen (Labor)]] || || || ||
|-
| [[Pumpenansteuerung (Labor)]] || || || ||
|-
| [[Füllstandsregler (Labor)]] || || || ||
|-
| [[Regler Boilerdruck (Labor)]] || || || ||
|-
| [[Mischregler (Labor)]] || || || ||
|-
| [[Durchflussregler (Labor)]] || || || ||
|-
| [[einfacher Kaffeebezug (Labor)]] || || || ||
|-
| [[Kaffeebezug (Labor)]] || || || ||
|-
| [[Wasserbezug (Labor)]] || || || ||
|-
| [[Dampfbezug]] || || || ||
|-
| [[Spülvorgänge (Labor)]] || || || ||
|-
| [[Tastenbedienung (Labor)]] || || || ||
|-
| [[Anpassungen für Schrittmotorensteuerung]] || || || ||
|-
| || || || ||
|}

= ToDo-Liste: APP =
{| class="wikitable sortable"
|-
! Arbeitspaket !! Wer !! Prio !! Status !! WV
|-
| [[APP - Konzept]] || || 2 || 10 ||
|-
| [[Messwerte erfassen APP]] || || 99 || 10 ||
|-
| [[Preset / Profilverwaltung]] || || 99 || 10 ||
|-
| || || || ||
|}

Mehrkernnutzung und/oder Multitasking

2026-04-27T21:37:20Z

Konstantin Rupprecht:

=Konstantin Rupprecht, 27.04.2026 Multitasking mittels Uasyncio=
Uasyncio ist eine Implementierung von der asyncio library von C-Python für Microcontroller.
Es wird eingesetzt, um ein ähnliches Ergebnis wie bei Multithreading zu erzielen. Dabei
werden die Aufgaben jedoch nicht parallel ausgeführt, sondern laufen kooperativ ab. Das
erzielt die uasyncio über den sogenannte Event-Loop. Er läuft kontinuierlich in einer Schleife
und verwaltet sämtliche Aufgaben. Dabei stellt eine Aufgabe eine gekapselte Coroutine dar,
also eine Funktion, die ihren eigenen Ausführungszustand speichern kann. Im Gegensatz zu
normalen Funktionen wird ein Task nicht einmal vollständig durchlaufen, sondern kann an
bestimmten Punkten unterbrochen und später fortgesetzt werden. Dadurch ist es möglich,
Aufgaben effizient zu pausieren und später exakt an derselben Stelle weiterzuführen. Der
Wechsel zwischen verschiedenen Aufgaben erfolgt ausschließlich an definierten
Übergabepunkten. Das bedeutet, dass eine Aufgabe aktiv die Kontrolle an den Event-Loop
zurückgeben muss, damit eine andere Aufgabe ausgeführt werden kann. Dieser kontrollierte
Eingriff ermöglich uasyncio die Aufgaben effektiv zu strukturieren und den Programmablauf
damit zu optimieren, ohne das komplexe Synchronisationsmechanismen benötigt werden,
wie es bei Multithreading nötig ist. Gleichzeitig ergibt sich daraus jedoch die Anforderung,
dass Aufgaben so gestaltet sein müssen, dass sie regelmäßig die Kontrolle abgeben
können. Andernfalls kann ein einzelner Task den gesamten Ablauf blockieren. 

Damit uasyncio verwendet werden kann, muss es zunächst im Programm importiert und der
Event-Loop gestartet werden. Dies geschieht durch das Definieren von asynchronen
Funktionen mit „async def“, die anschließend als Tasks eingeplant werden. Der
Einstiegspunkt ist meist eine Haupt-Coroutine, die alle weiteren Aufgaben startet. Der Event
Loop wird dann mit „uasyncio.run()“ initialisiert und ausgeführt, wobei diese Funktion die
Kontrolle übernimmt und alle registrierten Tasks verwaltet. Innerhalb der Coroutinen werden
an geeigneten Stellen „await“-Ausdrücke verwendet, um die Kontrolle gezielt an den Event
Loop zurückzugeben. Ohne einen solchen Start des Event-Loops und das explizite
Einplanen von Tasks würde uasyncio nicht aktiv werden, da es vollständig ereignisgesteuert
arbeitet.

= Peter Vogginger, 15.01.2025 Versuch der Mehrkernnutzung =
Die Mehrkernnutzung wird versuchshalber mit einem zusätzlichen Schrittmotor und der bereits programmierten UART-Kommunikation getestet. Die Schrittmotorsteuerung wird auf den Hauptkern (Core 0) und die Kommunikation auf den 2. Kern (Core 1) verlagert. Diese Aufteilung wird gewählt, da es vermutlich zu einem besserem Motorlauf führt. Dies wird im weiteren Verlauf auch versucht, zu bestätigen. 

Der Versuchsaufbau besteht aus zwei RP2040-Platinen, dem Schrittmotor, sowie dessen Ansteuerung/ Stromversorgung (realisiert auf einer zusätzlichen Platine). Die RP2040-Platinen sind miteinander verkabelt (siehe hierzu Seite [[Kommunikation_per_UART]]). Die Platine mit der Schrittmotorsteuerung ist als Relais in dem Kommunikationsring ausgeführt. Die zweite RP2040 beinhaltet den Code für den ersten Token (Messwert-Platine) und startet die Kommunikation. 

Die Versuchsdurchführung sieht vor, dass der Schrittmotor permanent drehen soll und bei Beginn der Kommunikation die Drehbewegung des Motors beobachtet wird. Der Programmcode des Motors wurde in Teilen aus einer früheren Projektarbeit entnommen, sowie aus dem
offiziellen MicroPython-Wiki (siehe: https://docs.micropython.org/en/latest/library/rp2.html). Die Kommunikation über UART wird als reines Relais ausgeführt, das heißt der eingehende Token wird kontrolliert und weitergesendet. Dies wurde bereits erfolgreich angewendet. 

Läuft sowohl die Kommunikation, ersichtlich über das Ausgabefenster in THONNY, und dreht der Motor ebenso, ist die Mehrkernnutzung erfolgreich getestet. Im weiteren Verlauf wird das Drehverhalten der Motorwelle mit und ohne parallele Kommunikation beurteilt und verfeinert.
Im ersten Versuch zeigt sich, dass sich die Welle des Motors ohne Mehrkernnutzung nahezu ruckfrei dreht, allerdings in paralleler Ausführung sich ein starkes Rucken einstellt. Um dies zu reduzieren, wird die Motor-Ansteuerung auf die spezialisierte Hardware-Einheit PIO des RP2040 verlegt. Sie ermöglicht es, Ein- und Ausgabesignale sehr präzise und unabhängig von der CPU zu steuern, indem eigene kleine Programme (ASM-Code) direkt in der PIO-Hardware ausgeführt werden. Diese ist fest auf dem RP2040 integriert, es wird nur der Programmcode der Schrittmotorsteuerung angepasst. 

Daraufhin zeigt sich, dass sich mit dieser Art der Motorsteuerung ein weniger ruckeliges Verhalten während der parallel ablaufenden Kommunikation einstellt. Allerdings ist die Drehung der Motorwelle, ohne die Verwendung der Mehrkernnutzung, weniger flüssig. Dies ist hier allerdings nicht entscheidend. 

Ebenso zeigt sich, dass die Verlagerung der Kommunikation auf den Nebenkern nicht zu dem oben erwähnten besseren Motorlauf führt. Ganz im Gegenteil, eine Verlagerung der Motorsteuerung auf den Nebenkern (Core1), wobei zugleich die Kommunikation auf dem Hauptkern (Core0) ausgeführt wird, erweist sich als deutlich besser im Hinblick auf den sofortigen Kommunikationsaufbau, und die Motorbewegung ist weniger ruckelig. 
Link zum bisherigen Programmcode: [[Datei:20260108_Test_Dualcorenutzung.zip]] 

Im weiteren Verlauf wird die Positionierung der Schrittmotorwelle mittels Datenwert im Token
übermittelt und dessen korrekte Anfahrung getestet. Der Schrittmotor hat hierzu die Position 0.

Die Ausarbeitung des Programmcodes ist aufwendig und wird im Folgenden anhand der drei
Ablaufdiagramme (Abb..) vorgestellt.
[[Datei:20260210 Ablaufdiagramm Schrittmotorsteuerung ssr Teil1.png|thumb|300px|gerahmt|zentriert|alternativtext=Ablaufdiagramm der Funktion schrittmotor_steuerung, (c) Peter Vogginger|Ablaufdiagramm der Funktion schrittmotor_steuerung, (c) Peter Vogginger]]

[[Datei:20260210 Ablaufdiagramm Schrittmotorsteuerung ssr Teil2.png|thumb|899px|gerahmt|zentriert|alternativtext=Ablaufdiagramme der Funktionn set_target_steps und motor_run, (c) Peter Vogginger|Ablaufdiagramme der Funktionen set_target_steps und motor_run, (c) Peter Vogginger]]

=== schrittmotor_steuerung ===
Die Funktion schrittmotor_steuerung ist Teil der main.py der SSR-Platine und wird bei jedem Aufruf der lokalen Funktion on_receive_ssr ausgeführt. Somit wird sie bei jedem Eintreffen eines neuen Tokens über die UART-Schnittstelle aufgerufen (http://www.institut-fuer-kaffeetechnologie.de/Wiki/index.php?title=Kommunikation_per_UART). 

Die Aufgaben dieser Funktion sind: 
:• das Auslesen der Zielposition der Motorwelle aus dem Token, 
:• das Schreiben der aktuellen Istposition des Motors in den Token, 
:• sowie der Aufruf der Funktion set_target_steps, sofern erforderlich. 

Die Schrittanzahl wird in Halbschritten angegeben und aus dem Token mithilfe eines Getters
ausgelesen. Hierbei ist zu beachten, dass es sich um einen Integerwert mit Vorzeichen handelt
und somit der Setter entsprechend set_signed_bytes() heißt (http://www.institut-fuer-kaffeetechnologie.de/Wiki/index.php?title=Kommunikation_per_UART Setter und Getter für Bits und Bytes). 

Die Istposition ist die absolute Schrittanzahl vom Zustand 0 (beim Dosierventil ist das der
Zustand „geschlossen“). Die Istposition wird bei jedem Tokenempfang mithilfe eines Setters in
den Token geschrieben und somit fortlaufend aktualisiert. Der Wertebereich des Dosierventils
ist 0…550. Somit wird der Setter set_bytes() verwendet, da keine negativen Werte vorkommen
können. 

Zusätzlich überprüft die Funktion, ob der Motor im Moment dreht. Hierzu dient das Flag
motor_dreht. Dieses Flag wird in den Funktionen set_target_steps und motor_run gesetzt bzw.
zurückgesetzt. Dreht der Motor aktuell, wird kein neuer Positionierbefehl ausgelöst, um den
Bewegungsablauf nicht zu stören. Nur wenn der Motor steht und die Zielposition von der
Istposition abweicht, wird die Funktion set_target_steps erneut aufgerufen.

=== set_target_steps ===
Die Funktion set_target_steps ist Teil der Klasse MOTORSTEUERUNG in der Datei
motorsteuerung.py auf der SSR-Platine. Die Aufgaben dieser Funktion sind: 

:• der Vergleich der vorgegebenen Schrittanzahl mit der Minimal- und der Maximalposition 
:• die Festlegung der Drehrichtung des Motors, sowie 
:• das Setzen und Zurücksetzen des Status-Flags motor_dreht. 

Im ersten Schritt wird überprüft, ob die vorgegebene Schrittanzahl target_steps kleiner als die
minimal mögliche Position (0) ist. Falls dies zutrifft, wird die Schrittanzahl auf die
Minimalposition 0 gesetzt. Anschließend wird geprüft, ob die Schrittanzahl größer als die
Maximalposition des Dosierventils (550) ist. Ist dies der Fall, wird die Schrittanzahl auf die
Maximalposition gesetzt. Die Zielposition ist nun die Schrittanzahl. 

Darauffolgend wird die Zielposition mit der aktuellen Istposition verglichen, um die Drehrichtung
des Motors festzulegen. Ist die Zielposition größer als die Istposition, wird der Motor in positiver
Drehrichtung (= rechtsdrehend bzw. schließend) betreiben, ist sie kleiner, erfolgt die Bewegung
in negativer Drehrichtung (= linksdrehend bzw. öffnend 

Abschließend wird das Flag motor_dreht gesetzt. Dieses dient dazu, dass während einer
laufenden Motorbewegung die Funktion set_target_steps nicht erneut aufgerufen wird. Dadurch
wird eine Störung der Motorbewegung und des Ablaufs verhindert. Die Funktion
motor_steuerung wird weiterhin bei jedem Eintreffen eines neuen Tokens aufgerufen. 

=== motor_run ===
Die Funktion motor_run ist Teil der Klasse MOTORSTEUERUNG in der Datei motorsteuerung.py
auf der SSR-Platine. 

Die Aufgabe dieser Funktion ist die kontinuierliche Ansteuerung des Schrittmotors auf dem
zweiten Prozessorkern (Core 1). 

Die Funktion wird mit dem Aufruf _thread.start_new_thread(motor.motor_run,()) gestartet und
läuft über eine Endlosschleife während der gesamten Einschaltdauer der Platine. Diese Struktur
ist notwendig, um die Mehrkernnutzung des RP2040 zu realisieren und eine gleichzeitige
Motorbewegung sicherzustellen. 

Zu Beginn wird der Index idx der Schrittsequenz auf null gesetzt. Dieser dient als Laufvariable zur
Auswahl des aktuellen Spulenzustandes. 

Anschließend wird innerhalb einer Schleife permanent überprüft, ob das Flag motor_dreht
gesetzt ist. Dieses Flag wird in der Funktion set_target_steps aktiviert, sobald eine neue
Zielposition angefordert wurde.
Ist das Flag gesetzt, wird ein vorgegebenes Schrittmuster ausgegeben. Das Schrittmuster ist
motorabhängig und besteht bei dem verwendeten bipolaren zweiphasigen Schrittmotor aus
acht verschiedenen Spulenzuständen: STEP_SEQ = (0b0100, 0b0101, 0b0001, 0b1001, 0b1000,
0b1010, 0b0010, 0b0110). Die Gesamtheit der Einträge ist die Schrittfrequenz. Hierbei handelt
es sich um die Halbschritt-Sequenz, welche für das Dosierventil vorgesehen ist. 

Die Ausgabe des aktuellen Spulenzustands erfolgt über den Aufruf self.sm.put(self.STEP_SEQ[idx]). Jeder Eintrag der Schrittfrequenz entspricht genau einem
Halbschritt. 

Der Schrittindex wird anschließend durch den Aufruf idx = (idx + self.drehrichtung) % 8
aktualisiert. Abhängig von der Drehrichtung ergibt sich dabei folgender Zusammenhang:

:• Ist die Drehrichtung +1, lautet die Abfolge 0 → 1 → 2 → 3 → 4 → 5 → 6 → 7 → 0 → … 
:• ist die Drehrichtung -1, lautet die Abfolge 0 → 7 → 6 → 5 → 4 → 3 → 2 → 1 → 0 → … 

Durch den Modulo-Operator wird sichergestellt, dass der Index stets im gültigen Bereich der
Schrittfrequenz bleibt. Bei jedem Schleifendurchlauf wird die Variable idx genau einmal
verändert, somit entspricht jeder Schleifendurchlauf exakt einem Motor-Halbschritt. 

Die aktuelle Position wird anschließend mit self.aktuelle_position += self.drehrichtung
aktualisiert. 

Ob die Zielposition erreicht wurde, wird durch den Vergleich self.aktuelle_position ==
self.ziel_position überprüft. Ist dies der Fall, wird das Flag motor_dreht auf False gesetzt,
wodurch die Motorbewegung beendet wird. Die Schleife läuft weiterhin. 

Der Zugriff auf das Flag motor_dreht wird in der Funktion motor_run benötigt, da es die
Motorverstellung aus der Bewegung heraus stoppt. In der Funktion set_target_steps wird
dagegen entschieden, ob der Motor überhaupt drehen soll und das Flag wird entspechend
gesetzt.

= Armin Rohnen, 11.04.2024 =
Grundsätzlich verfügt der ARM-Prozessor der Raspberry Pi Pcio MCU RP2040 über zwei Kerne, die im Gegensatz zu anderen MCUs gleichwertig sein sollen. Die Quellenlage hierzu lässt jedoch eine eindeutige Beurteilung dieser Annahme nicht zu. Eine ggf. verbessernde Quellenlage könnte hierzu neue Ansätze liefern. Für die Verlagerung der Regelkreise auf die MCUs ist zuvor eine Festlegung zu treffen in welcher Form eine Mehrkernnutzung und/oder ein Multitasking implementiert wird.

Damit ist ein Framework für die Systemsteuerung zu definieren. Hierzu sind in der Linksammlung [119] unter Scheduling, Threading und Frameworks einige Libraries aufgelistet.

MicroPython stellt hierzu die Module uasyncio und _thread zur Verfügung. Letzteres verwendet für die Programmausführung den zweiten Prozessorkern. _thread wird allerdings als sehr experimentell bezeichnet. Allerdings lassen sich keine Negativinformation recherchieren.

Mehrkernnutzung und/oder Multitasking

2026-04-27T21:36:39Z

Konstantin Rupprecht:

=Konstantin Rupprecht, 27.04.2026 Multitasking mittels Uasyncio=
Uasyncio ist eine Implementierung von der asyncio library von C-Python für Microcontroller.
Es wird eingesetzt, um ein ähnliches Ergebnis wie bei Multithreading zu erzielen. Dabei
werden die Aufgaben jedoch nicht parallel ausgeführt, sondern laufen kooperativ ab. Das
erzielt die uasyncio über den sogenannte Event-Loop. Er läuft kontinuierlich in einer Schleife
und verwaltet sämtliche Aufgaben. Dabei stellt eine Aufgabe eine gekapselte Coroutine dar,
also eine Funktion, die ihren eigenen Ausführungszustand speichern kann. Im Gegensatz zu
normalen Funktionen wird ein Task nicht einmal vollständig durchlaufen, sondern kann an
bestimmten Punkten unterbrochen und später fortgesetzt werden. Dadurch ist es möglich,
Aufgaben effizient zu pausieren und später exakt an derselben Stelle weiterzuführen. Der
Wechsel zwischen verschiedenen Aufgaben erfolgt ausschließlich an definierten
Übergabepunkten. Das bedeutet, dass eine Aufgabe aktiv die Kontrolle an den Event-Loop
zurückgeben muss, damit eine andere Aufgabe ausgeführt werden kann. Dieser kontrollierte
Eingriff ermöglich uasyncio die Aufgaben effektiv zu strukturieren und den Programmablauf
damit zu optimieren, ohne das komplexe Synchronisationsmechanismen benötigt werden,
wie es bei Multithreading nötig ist. Gleichzeitig ergibt sich daraus jedoch die Anforderung,
dass Aufgaben so gestaltet sein müssen, dass sie regelmäßig die Kontrolle abgeben
können. Andernfalls kann ein einzelner Task den gesamten Ablauf blockieren. 

Damit uasyncio verwendet werden kann, muss es zunächst im Programm importiert und der
Event-Loop gestartet werden. Dies geschieht durch das Definieren von asynchronen
Funktionen mit „async def“, die anschließend als Tasks eingeplant werden. Der
Einstiegspunkt ist meist eine Haupt-Coroutine, die alle weiteren Aufgaben startet. Der Event
Loop wird dann mit „uasyncio.run()“ initialisiert und ausgeführt, wobei diese Funktion die
Kontrolle übernimmt und alle registrierten Tasks verwaltet. Innerhalb der Coroutinen werden
an geeigneten Stellen „await“-Ausdrücke verwendet, um die Kontrolle gezielt an den Event
Loop zurückzugeben. Ohne einen solchen Start des Event-Loops und das explizite
Einplanen von Tasks würde uasyncio nicht aktiv werden, da es vollständig ereignisgesteuert
arbeitet.

= Peter Vogginger, 15.01.2025 Versuch der Mehrkernnutzung =
Die Mehrkernnutzung wird versuchshalber mit einem zusätzlichen Schrittmotor und der bereits programmierten UART-Kommunikation getestet. Die Schrittmotorsteuerung wird auf den Hauptkern (Core 0) und die Kommunikation auf den 2. Kern (Core 1) verlagert. Diese Aufteilung wird gewählt, da es vermutlich zu einem besserem Motorlauf führt. Dies wird im weiteren Verlauf auch versucht, zu bestätigen. 

Der Versuchsaufbau besteht aus zwei RP2040-Platinen, dem Schrittmotor, sowie dessen Ansteuerung/ Stromversorgung (realisiert auf einer zusätzlichen Platine). Die RP2040-Platinen sind miteinander verkabelt (siehe hierzu Seite [[Kommunikation_per_UART]]). Die Platine mit der Schrittmotorsteuerung ist als Relais in dem Kommunikationsring ausgeführt. Die zweite RP2040 beinhaltet den Code für den ersten Token (Messwert-Platine) und startet die Kommunikation. 

Die Versuchsdurchführung sieht vor, dass der Schrittmotor permanent drehen soll und bei Beginn der Kommunikation die Drehbewegung des Motors beobachtet wird. Der Programmcode des Motors wurde in Teilen aus einer früheren Projektarbeit entnommen, sowie aus dem
offiziellen MicroPython-Wiki (siehe: https://docs.micropython.org/en/latest/library/rp2.html). Die Kommunikation über UART wird als reines Relais ausgeführt, das heißt der eingehende Token wird kontrolliert und weitergesendet. Dies wurde bereits erfolgreich angewendet. 

Läuft sowohl die Kommunikation, ersichtlich über das Ausgabefenster in THONNY, und dreht der Motor ebenso, ist die Mehrkernnutzung erfolgreich getestet. Im weiteren Verlauf wird das Drehverhalten der Motorwelle mit und ohne parallele Kommunikation beurteilt und verfeinert.
Im ersten Versuch zeigt sich, dass sich die Welle des Motors ohne Mehrkernnutzung nahezu ruckfrei dreht, allerdings in paralleler Ausführung sich ein starkes Rucken einstellt. Um dies zu reduzieren, wird die Motor-Ansteuerung auf die spezialisierte Hardware-Einheit PIO des RP2040 verlegt. Sie ermöglicht es, Ein- und Ausgabesignale sehr präzise und unabhängig von der CPU zu steuern, indem eigene kleine Programme (ASM-Code) direkt in der PIO-Hardware ausgeführt werden. Diese ist fest auf dem RP2040 integriert, es wird nur der Programmcode der Schrittmotorsteuerung angepasst. 

Daraufhin zeigt sich, dass sich mit dieser Art der Motorsteuerung ein weniger ruckeliges Verhalten während der parallel ablaufenden Kommunikation einstellt. Allerdings ist die Drehung der Motorwelle, ohne die Verwendung der Mehrkernnutzung, weniger flüssig. Dies ist hier allerdings nicht entscheidend. 

Ebenso zeigt sich, dass die Verlagerung der Kommunikation auf den Nebenkern nicht zu dem oben erwähnten besseren Motorlauf führt. Ganz im Gegenteil, eine Verlagerung der Motorsteuerung auf den Nebenkern (Core1), wobei zugleich die Kommunikation auf dem Hauptkern (Core0) ausgeführt wird, erweist sich als deutlich besser im Hinblick auf den sofortigen Kommunikationsaufbau, und die Motorbewegung ist weniger ruckelig. 
Link zum bisherigen Programmcode: [[Datei:20260108_Test_Dualcorenutzung.zip]] 

Im weiteren Verlauf wird die Positionierung der Schrittmotorwelle mittels Datenwert im Token
übermittelt und dessen korrekte Anfahrung getestet. Der Schrittmotor hat hierzu die Position 0.

Die Ausarbeitung des Programmcodes ist aufwendig und wird im Folgenden anhand der drei
Ablaufdiagramme (Abb..) vorgestellt.
[[Datei:20260210 Ablaufdiagramm Schrittmotorsteuerung ssr Teil1.png|thumb|300px|gerahmt|zentriert|alternativtext=Ablaufdiagramm der Funktion schrittmotor_steuerung, (c) Peter Vogginger|Ablaufdiagramm der Funktion schrittmotor_steuerung, (c) Peter Vogginger]]

[[Datei:20260210 Ablaufdiagramm Schrittmotorsteuerung ssr Teil2.png|thumb|899px|gerahmt|zentriert|alternativtext=Ablaufdiagramme der Funktionn set_target_steps und motor_run, (c) Peter Vogginger|Ablaufdiagramme der Funktionen set_target_steps und motor_run, (c) Peter Vogginger]]

=== schrittmotor_steuerung ===
Die Funktion schrittmotor_steuerung ist Teil der main.py der SSR-Platine und wird bei jedem Aufruf der lokalen Funktion on_receive_ssr ausgeführt. Somit wird sie bei jedem Eintreffen eines neuen Tokens über die UART-Schnittstelle aufgerufen (http://www.institut-fuer-kaffeetechnologie.de/Wiki/index.php?title=Kommunikation_per_UART). 

Die Aufgaben dieser Funktion sind: 
:• das Auslesen der Zielposition der Motorwelle aus dem Token, 
:• das Schreiben der aktuellen Istposition des Motors in den Token, 
:• sowie der Aufruf der Funktion set_target_steps, sofern erforderlich. 

Die Schrittanzahl wird in Halbschritten angegeben und aus dem Token mithilfe eines Getters
ausgelesen. Hierbei ist zu beachten, dass es sich um einen Integerwert mit Vorzeichen handelt
und somit der Setter entsprechend set_signed_bytes() heißt (http://www.institut-fuer-kaffeetechnologie.de/Wiki/index.php?title=Kommunikation_per_UART Setter und Getter für Bits und Bytes). 

Die Istposition ist die absolute Schrittanzahl vom Zustand 0 (beim Dosierventil ist das der
Zustand „geschlossen“). Die Istposition wird bei jedem Tokenempfang mithilfe eines Setters in
den Token geschrieben und somit fortlaufend aktualisiert. Der Wertebereich des Dosierventils
ist 0…550. Somit wird der Setter set_bytes() verwendet, da keine negativen Werte vorkommen
können. 

Zusätzlich überprüft die Funktion, ob der Motor im Moment dreht. Hierzu dient das Flag
motor_dreht. Dieses Flag wird in den Funktionen set_target_steps und motor_run gesetzt bzw.
zurückgesetzt. Dreht der Motor aktuell, wird kein neuer Positionierbefehl ausgelöst, um den
Bewegungsablauf nicht zu stören. Nur wenn der Motor steht und die Zielposition von der
Istposition abweicht, wird die Funktion set_target_steps erneut aufgerufen.

=== set_target_steps ===
Die Funktion set_target_steps ist Teil der Klasse MOTORSTEUERUNG in der Datei
motorsteuerung.py auf der SSR-Platine. Die Aufgaben dieser Funktion sind: 

:• der Vergleich der vorgegebenen Schrittanzahl mit der Minimal- und der Maximalposition 
:• die Festlegung der Drehrichtung des Motors, sowie 
:• das Setzen und Zurücksetzen des Status-Flags motor_dreht. 

Im ersten Schritt wird überprüft, ob die vorgegebene Schrittanzahl target_steps kleiner als die
minimal mögliche Position (0) ist. Falls dies zutrifft, wird die Schrittanzahl auf die
Minimalposition 0 gesetzt. Anschließend wird geprüft, ob die Schrittanzahl größer als die
Maximalposition des Dosierventils (550) ist. Ist dies der Fall, wird die Schrittanzahl auf die
Maximalposition gesetzt. Die Zielposition ist nun die Schrittanzahl. 

Darauffolgend wird die Zielposition mit der aktuellen Istposition verglichen, um die Drehrichtung
des Motors festzulegen. Ist die Zielposition größer als die Istposition, wird der Motor in positiver
Drehrichtung (= rechtsdrehend bzw. schließend) betreiben, ist sie kleiner, erfolgt die Bewegung
in negativer Drehrichtung (= linksdrehend bzw. öffnend 

Abschließend wird das Flag motor_dreht gesetzt. Dieses dient dazu, dass während einer
laufenden Motorbewegung die Funktion set_target_steps nicht erneut aufgerufen wird. Dadurch
wird eine Störung der Motorbewegung und des Ablaufs verhindert. Die Funktion
motor_steuerung wird weiterhin bei jedem Eintreffen eines neuen Tokens aufgerufen. 

=== motor_run ===
Die Funktion motor_run ist Teil der Klasse MOTORSTEUERUNG in der Datei motorsteuerung.py
auf der SSR-Platine. 

Die Aufgabe dieser Funktion ist die kontinuierliche Ansteuerung des Schrittmotors auf dem
zweiten Prozessorkern (Core 1). 

Die Funktion wird mit dem Aufruf _thread.start_new_thread(motor.motor_run,()) gestartet und
läuft über eine Endlosschleife während der gesamten Einschaltdauer der Platine. Diese Struktur
ist notwendig, um die Mehrkernnutzung des RP2040 zu realisieren und eine gleichzeitige
Motorbewegung sicherzustellen. 

Zu Beginn wird der Index idx der Schrittsequenz auf null gesetzt. Dieser dient als Laufvariable zur
Auswahl des aktuellen Spulenzustandes. 

Anschließend wird innerhalb einer Schleife permanent überprüft, ob das Flag motor_dreht
gesetzt ist. Dieses Flag wird in der Funktion set_target_steps aktiviert, sobald eine neue
Zielposition angefordert wurde.
Ist das Flag gesetzt, wird ein vorgegebenes Schrittmuster ausgegeben. Das Schrittmuster ist
motorabhängig und besteht bei dem verwendeten bipolaren zweiphasigen Schrittmotor aus
acht verschiedenen Spulenzuständen: STEP_SEQ = (0b0100, 0b0101, 0b0001, 0b1001, 0b1000,
0b1010, 0b0010, 0b0110). Die Gesamtheit der Einträge ist die Schrittfrequenz. Hierbei handelt
es sich um die Halbschritt-Sequenz, welche für das Dosierventil vorgesehen ist. 

Die Ausgabe des aktuellen Spulenzustands erfolgt über den Aufruf self.sm.put(self.STEP_SEQ[idx]). Jeder Eintrag der Schrittfrequenz entspricht genau einem
Halbschritt. 

Der Schrittindex wird anschließend durch den Aufruf idx = (idx + self.drehrichtung) % 8
aktualisiert. Abhängig von der Drehrichtung ergibt sich dabei folgender Zusammenhang:

:• Ist die Drehrichtung +1, lautet die Abfolge 0 → 1 → 2 → 3 → 4 → 5 → 6 → 7 → 0 → … 
:• ist die Drehrichtung -1, lautet die Abfolge 0 → 7 → 6 → 5 → 4 → 3 → 2 → 1 → 0 → … 

Durch den Modulo-Operator wird sichergestellt, dass der Index stets im gültigen Bereich der
Schrittfrequenz bleibt. Bei jedem Schleifendurchlauf wird die Variable idx genau einmal
verändert, somit entspricht jeder Schleifendurchlauf exakt einem Motor-Halbschritt. 

Die aktuelle Position wird anschließend mit self.aktuelle_position += self.drehrichtung
aktualisiert. 

Ob die Zielposition erreicht wurde, wird durch den Vergleich self.aktuelle_position ==
self.ziel_position überprüft. Ist dies der Fall, wird das Flag motor_dreht auf False gesetzt,
wodurch die Motorbewegung beendet wird. Die Schleife läuft weiterhin. 

Der Zugriff auf das Flag motor_dreht wird in der Funktion motor_run benötigt, da es die
Motorverstellung aus der Bewegung heraus stoppt. In der Funktion set_target_steps wird
dagegen entschieden, ob der Motor überhaupt drehen soll und das Flag wird entspechend
gesetzt.

= Armin Rohnen, 11.04.2024 =
Grundsätzlich verfügt der ARM-Prozessor der Raspberry Pi Pcio MCU RP2040 über zwei Kerne, die im Gegensatz zu anderen MCUs gleichwertig sein sollen. Die Quellenlage hierzu lässt jedoch eine eindeutige Beurteilung dieser Annahme nicht zu. Eine ggf. verbessernde Quellenlage könnte hierzu neue Ansätze liefern. Für die Verlagerung der Regelkreise auf die MCUs ist zuvor eine Festlegung zu treffen in welcher Form eine Mehrkernnutzung und/oder ein Multitasking implementiert wird.

Damit ist ein Framework für die Systemsteuerung zu definieren. Hierzu sind in der Linksammlung [119] unter Scheduling, Threading und Frameworks einige Libraries aufgelistet.

MicroPython stellt hierzu die Module uasyncio und _thread zur Verfügung. Letzteres verwendet für die Programmausführung den zweiten Prozessorkern. _thread wird allerdings als sehr experimentell bezeichnet. Allerdings lassen sich keine Negativinformation recherchieren.

Mikrocontroller Programmierung in MicroPython SoSe 2026

2026-04-20T19:18:07Z

Konstantin Rupprecht: /* Leistungsvereinbarung */

<htmltag tagname="img" src="https://vg07.met.vgwort.de/na/3e58d840a91b42ac97ee493cdd085245" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 

= Mikrocontroller Programmierung in MicroPython Sommersemester 2026 =
Für die Projekte zur labortechnischen Espressomaschine (und weiteren Derivaten) ist die Mikrokontroller-Programmierung einer Steuerungselektronik erforderlich.

Die Programmierung der Mikrocontroller erfolgt in MicroPython und die übergeordnete Steuerung ist eine MATLAB®-APP mit einem Prozessschaubild. Die Grundfunktionalität dieses Vorgehensweise ist in der Quellenliste unter [40] (MATLAB® meets MicroPython) beschrieben.

Das Projekt wurde bereits durch eine Projektgruppe bearbeitet und hat einen Projektstand, der jedoch noch nicht die gesamte erforderliche Steuerungsfunktionalität umfasst.

Es wird angestrebt eine Steuerung auf Basis eines Nucleo STM32H743ZI2 zu erstellen. Dies würde die aktuell drei Steuerungsplatinen und Mikrocontroller auf einen reduzieren. Kommunikation wäre dann lediglich zum Displaycontroller erforderlich.

= Aufgabenanalyse =
==UART-Kommunikation==
Es soll eine Stern-Topologie implementiert werden, welche die UART-Kommunikation
zu einem separaten Display-Controller, dem Maschinensimulator und der Wartungs-
App herstellt. Dabei sind Sende- und Empfangs-Token f¨ ur das Display, die Wartungs-App und den Maschinensimulator einzuf¨ uhren. Es gilt dabei, den Umfang und Takt der
neuen Token festzulegen.

==Mehrkernnutzung und/oder Multitasking==

Es gibt bestimmte Vorgänge, welche regelmäßig zur Unterbrechung des Pro-
grammablaufs führen. Es gilt, diese Vorgänge zu identifizieren und umzuleiten,
damit diese den Programmablauf nicht mehr unterbrechen. Die Möglichkeit
der Mehrkernnutzung fällt dabei aus, da der STM32H753ZI nur über einen
M7-Kern verfügt. Dank der Hardware-Unterstützung DMA sowie der Nutzung
der uasyncio-Library besteht die Möglichkeit, die Vorgänge umzuleiten. Somit
können die Unterbrechungen des Programmablaufs reduziert werden.

== Maschinensimulator ==

== Füllstandsregler ==
Die Füllstandsregelung erkennt den Füllstand über eine Kurzschlussdetektion. Liegt kein
Kurzschluss vor, wird dies als zu niedriger Füllstand interpretiert und der Boilerdruckregler
zur Vermeidung von Trockenheizen gesperrt. Beim Erreichen des Sollfüllstands erfolgt eine
gezielte Überfüllung bei reduzierter Pumpenspannung, um ein periodisches Ein- und
Ausschalten der Regelung zu vermeiden. Da die in der MATLAB®-GUI realisierte Boiler Füllstandsregelung aus [114] bereits in einem ersten Stand in MicroPython übertragen
wurde, liegt der Fokus hier auf der Validierung am Maschinensimulator sowie der
Abstimmung mit den Schnittstellenpartnern.

== Boilerdruckregelung ==
Ziel ist es, die bisher in der MATLAB®-GUI realisierte Boilerdruckregelung aus [114], die auf
einem PD-Regler basiert, vollständig zu übertragen, sodass die Regelung unabhängig von der
externen PC-Umgebung arbeitet.

== Mischtemperaturregler ==
Der Mischtemperaturregler nach [114] dient zur Regelung der Kaffee- und
Teewassertemperatur und wird als PID-Regler für das Mischventil umgesetzt. Die Stellgröße
ist dabei die Verstellung des Mischventils. Der Temperatursollwert wird aus dem jeweils
aktiven Rezept vorgegeben. Da die Regelung vom aktuellen Durchfluss abhängt, wird eine
Kaskadenstruktur verwendet. In dieser Struktur arbeitet der Durchflussregler als innerer,
schneller Regelkreis, während der Mischtemperaturregler den äußeren Regelkreis bildet und
die Ergebnisse des inneren Kreises berücksichtigt. Daraus ergibt sich ein besonderes
Augenmerk auf das Testen des Zusammenspiels der beiden Regler anhand des
Maschinensimulators, um das Ziel – die Implementierung dieser Kaskadenregelung auf dem
STM32 – zu erreichen.

== Durchflussregler ==
Ein Durchflussregler, der in MATLAB® gemäß [114] vorliegt, wird als PID-Regler in
MicroPython umgesetzt. Durch die Anpassung der Pumpendrehzahl über einen
Spannungssollwert von 0–5 V kann ein konstanter oder ein profildefinierter Volumenstrom
entsprechend der Sollwertvorgabe realisiert werden. Als innerer Regelkreis liefert er
kontinuierlich Durchflusswerte an den Mischtemperaturregler. Daraus ergibt sich der Fokus
auf der Implementierung und dem Test des Reglers sowie auf der Validierung seines
Zusammenspiels mit dem übergeordneten Mischtemperaturregler im Maschinensimulator,
um die Integration auf dem STM32 sicherzustellen.

== Startprozedur ==

== Display ==

== STM32 ==
Als Haupt-MCU soll ein STM32H753ZI-Controller verwendet werden. Es soll sichergestellt
werden, dass die vorinstallierten Steckerleisten CN7 bis CN10 ausreichend Pins für
Definition der benötigten UART-, ADC-, DAC- und GPIO-Pins aufweisen. 
Die Boilerdruck-, die Wassertemperatur-, die Durchfluss- und die Füllstandsregelung des
Boilers müssen implementiert werden. Es soll ebenfalls eine UART-Kommunikation für ein
Touch-Display, einen Maschinensimulator sowie eine Möglichkeit zum Anschließen einer
Wartungs-App programmiert werden. Um einen geordneten Ablauf der einzelnen
Komponenten bei Inbetriebnahme der Maschine zu gewährleisten, soll eine Startprozedur
programmiert werden

== Wartungs - APP ==
Es müssen der Inhalt des Wartungs-Token definiert werden, ein GUI-Layout erstellt werden, ein Kommunikationsaufbau mit dem Maschinensimulator hergestellt werden, die Darstellung der Messwerte, eine manuelle Startprozedur, das Schalten von Magnetventilen, die Einstellung von Sollwertvorgaben (Boilerdruck, Bezugswassertemperatur, Durchfluss) und manuellen Stellwerten für das PWM-Heizelement, die Pumpenansteuerung und die Stellung des Dosierventils sowie die Messwertspeicherung und das Logging programmiert werden. Die App ist bis zu einem funktionsfähigen Prototypen erforderlich.

= Leistungsvereinbarung =

== Wartungs - APP ==
Die aktuelle MATLAB®-GUI soll in eine komfortable Bedienoberfläche für Wartungs- und Einstellarbeiten überführt werden. Bei aktivierter Wartungs-App sollen sämtliche Tastenfunktionen und die Vertikalhebelfunktion nutzbar sein und zudem alle Aktoren (Magnetventile, Pumpenleistung und Schrittmotorverstellungen) über diese App angesteuert werden können. Des Weiteren soll die bisherige Visualisierung der Messwerte und Schaltzustände erhalten bleiben. Dies allerdings mit einer geringeren Aktualisierungsrate, da vier Aktualisierungen pro Sekunde als ausreichend angesehen werden.

==UART-Kommunikation==
Um die spezifischen Daten von dem STM32H7 auf das Display zu übertragen, sowie
Steuerbefehle des Displays für den STM32H7, wird ein neue UART-Schnittstelle mit Display-Token eingeführt. Ebenfalls wird eine UART-Kommunikation mit entsprechendem Token für
Maschinensimulator und der Wartungs-App implementiert. Dabei soll ein Gateway den
Zugriff für die Wartungs-App integriert werden.

==Multitasking==
Die direkte Hardware-Unterstützung über DMA gestaltet sich schwierig in MicroPython, da
sie von MicroPython automatisch verwendet wird (bspw. bei Buffern) und nur über
Registeraccess direkt ausgeführt werden kann. Daher wird die Nutzung der uasyncio-Library
bevorzugt, welche die Vorgänge, die den Programmablauf verzögern, umleitet. Dadurch soll
das Programm reibungsfreier ablaufen.

==STM32H7==
Die bestehenden Regelkreise, Füllstandsregelung (Boiler und Tanks), Boilerdruckregelung,
Mischtemperaturregelung und Durchflussregelung werden von den drei Microcontroller auf
den STM32H7 verlagert. Ebenfalls erfolgt die Migration der Messwerterfassung aller
verbauten Sensoren auf die neue STM32H7-Plattform. 
Zusätzlich wird eine UART-Kommunikation implementiert, die die Anbindung des Displays,
eines Maschinensimulators sowie für den Zugriff durch eine externe Wartungs-App über
einem Gateway ermöglicht. 
Um einen geordneten Ablauf der einzelnen Komponenten bei Inbetriebnahme der Maschine
zu gewährleisten, wird eine Startprozedur programmiert. 
Die Hardware-Umsetzung wird von LfbA Armin Rohnen übernommen.

= Besprechungsprotokolle und weitere Unterlagen =
* [[:Datei:20260214 Abschlusspraesentation.pdf|Übergabepräsentation Vorgänger]]
* [[:Datei:20260326 Projektstart.pdf|Aktueller Projektstand]]
* [[Projektstart 26.03.2026]]
* [[Projektrücksprache 02.04.2026]]
* [[Projektrücksprache 09.04.2026]]
* [[Projektrücksprache 17.04.2026]]
* [[Projektrücksprache 24.04.2026]]
* [[Projektrücksprache 08.05.2026]]
* [[Projektrücksprache 15.05.2026]]
* [[Projektrücksprache 22.05.2026]]
* [[Projektrücksprache 29.05.2026]]
* [[Projektrücksprache 05.06.2026]]
* [[Projektrücksprache 12.06.2026]]
* [[Projektrücksprache 19.06.2026]]
* [[Projektrücksprache 03.07.2026]]
* [[Projektrücksprache 10.07.2026]]
* [[Projektrücksprache 24.07.2026]]
* [[Abschlusspräsentation 31.07.2026]]

Mikrocontroller Programmierung in MicroPython SoSe 2026

2026-04-20T19:15:23Z

Konstantin Rupprecht: /* Leistungsvereinbarung */

<htmltag tagname="img" src="https://vg07.met.vgwort.de/na/3e58d840a91b42ac97ee493cdd085245" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 

= Mikrocontroller Programmierung in MicroPython Sommersemester 2026 =
Für die Projekte zur labortechnischen Espressomaschine (und weiteren Derivaten) ist die Mikrokontroller-Programmierung einer Steuerungselektronik erforderlich.

Die Programmierung der Mikrocontroller erfolgt in MicroPython und die übergeordnete Steuerung ist eine MATLAB®-APP mit einem Prozessschaubild. Die Grundfunktionalität dieses Vorgehensweise ist in der Quellenliste unter [40] (MATLAB® meets MicroPython) beschrieben.

Das Projekt wurde bereits durch eine Projektgruppe bearbeitet und hat einen Projektstand, der jedoch noch nicht die gesamte erforderliche Steuerungsfunktionalität umfasst.

Es wird angestrebt eine Steuerung auf Basis eines Nucleo STM32H743ZI2 zu erstellen. Dies würde die aktuell drei Steuerungsplatinen und Mikrocontroller auf einen reduzieren. Kommunikation wäre dann lediglich zum Displaycontroller erforderlich.

= Aufgabenanalyse =
==UART-Kommunikation==
Es soll eine Stern-Topologie implementiert werden, welche die UART-Kommunikation
zu einem separaten Display-Controller, dem Maschinensimulator und der Wartungs-
App herstellt. Dabei sind Sende- und Empfangs-Token f¨ ur das Display, die Wartungs-App und den Maschinensimulator einzuf¨ uhren. Es gilt dabei, den Umfang und Takt der
neuen Token festzulegen.

==Mehrkernnutzung und/oder Multitasking==

Es gibt bestimmte Vorgänge, welche regelmäßig zur Unterbrechung des Pro-
grammablaufs führen. Es gilt, diese Vorgänge zu identifizieren und umzuleiten,
damit diese den Programmablauf nicht mehr unterbrechen. Die Möglichkeit
der Mehrkernnutzung fällt dabei aus, da der STM32H753ZI nur über einen
M7-Kern verfügt. Dank der Hardware-Unterstützung DMA sowie der Nutzung
der uasyncio-Library besteht die Möglichkeit, die Vorgänge umzuleiten. Somit
können die Unterbrechungen des Programmablaufs reduziert werden.

== Maschinensimulator ==

== Füllstandsregler ==
Die Füllstandsregelung erkennt den Füllstand über eine Kurzschlussdetektion. Liegt kein
Kurzschluss vor, wird dies als zu niedriger Füllstand interpretiert und der Boilerdruckregler
zur Vermeidung von Trockenheizen gesperrt. Beim Erreichen des Sollfüllstands erfolgt eine
gezielte Überfüllung bei reduzierter Pumpenspannung, um ein periodisches Ein- und
Ausschalten der Regelung zu vermeiden. Da die in der MATLAB®-GUI realisierte Boiler Füllstandsregelung aus [114] bereits in einem ersten Stand in MicroPython übertragen
wurde, liegt der Fokus hier auf der Validierung am Maschinensimulator sowie der
Abstimmung mit den Schnittstellenpartnern.

== Boilerdruckregelung ==
Ziel ist es, die bisher in der MATLAB®-GUI realisierte Boilerdruckregelung aus [114], die auf
einem PD-Regler basiert, vollständig zu übertragen, sodass die Regelung unabhängig von der
externen PC-Umgebung arbeitet.

== Mischtemperaturregler ==
Der Mischtemperaturregler nach [114] dient zur Regelung der Kaffee- und
Teewassertemperatur und wird als PID-Regler für das Mischventil umgesetzt. Die Stellgröße
ist dabei die Verstellung des Mischventils. Der Temperatursollwert wird aus dem jeweils
aktiven Rezept vorgegeben. Da die Regelung vom aktuellen Durchfluss abhängt, wird eine
Kaskadenstruktur verwendet. In dieser Struktur arbeitet der Durchflussregler als innerer,
schneller Regelkreis, während der Mischtemperaturregler den äußeren Regelkreis bildet und
die Ergebnisse des inneren Kreises berücksichtigt. Daraus ergibt sich ein besonderes
Augenmerk auf das Testen des Zusammenspiels der beiden Regler anhand des
Maschinensimulators, um das Ziel – die Implementierung dieser Kaskadenregelung auf dem
STM32 – zu erreichen.

== Durchflussregler ==
Ein Durchflussregler, der in MATLAB® gemäß [114] vorliegt, wird als PID-Regler in
MicroPython umgesetzt. Durch die Anpassung der Pumpendrehzahl über einen
Spannungssollwert von 0–5 V kann ein konstanter oder ein profildefinierter Volumenstrom
entsprechend der Sollwertvorgabe realisiert werden. Als innerer Regelkreis liefert er
kontinuierlich Durchflusswerte an den Mischtemperaturregler. Daraus ergibt sich der Fokus
auf der Implementierung und dem Test des Reglers sowie auf der Validierung seines
Zusammenspiels mit dem übergeordneten Mischtemperaturregler im Maschinensimulator,
um die Integration auf dem STM32 sicherzustellen.

== Startprozedur ==

== Display ==

== STM32 ==
Als Haupt-MCU soll ein STM32H753ZI-Controller verwendet werden. Es soll sichergestellt
werden, dass die vorinstallierten Steckerleisten CN7 bis CN10 ausreichend Pins für
Definition der benötigten UART-, ADC-, DAC- und GPIO-Pins aufweisen. 
Die Boilerdruck-, die Wassertemperatur-, die Durchfluss- und die Füllstandsregelung des
Boilers müssen implementiert werden. Es soll ebenfalls eine UART-Kommunikation für ein
Touch-Display, einen Maschinensimulator sowie eine Möglichkeit zum Anschließen einer
Wartungs-App programmiert werden. Um einen geordneten Ablauf der einzelnen
Komponenten bei Inbetriebnahme der Maschine zu gewährleisten, soll eine Startprozedur
programmiert werden

== Wartungs - APP ==
Es müssen der Inhalt des Wartungs-Token definiert werden, ein GUI-Layout erstellt werden, ein Kommunikationsaufbau mit dem Maschinensimulator hergestellt werden, die Darstellung der Messwerte, eine manuelle Startprozedur, das Schalten von Magnetventilen, die Einstellung von Sollwertvorgaben (Boilerdruck, Bezugswassertemperatur, Durchfluss) und manuellen Stellwerten für das PWM-Heizelement, die Pumpenansteuerung und die Stellung des Dosierventils sowie die Messwertspeicherung und das Logging programmiert werden. Die App ist bis zu einem funktionsfähigen Prototypen erforderlich.

= Leistungsvereinbarung =

== Wartungs - APP ==
Die aktuelle MATLAB®-GUI soll in eine komfortable Bedienoberfläche für Wartungs- und Einstellarbeiten überführt werden. Bei aktivierter Wartungs-App sollen sämtliche Tastenfunktionen und die Vertikalhebelfunktion nutzbar sein und zudem alle Aktoren (Magnetventile, Pumpenleistung und Schrittmotorverstellungen) über diese App angesteuert werden können. Des Weiteren soll die bisherige Visualisierung der Messwerte und Schaltzustände erhalten bleiben. Dies allerdings mit einer geringeren Aktualisierungsrate, da vier Aktualisierungen pro Sekunde als ausreichend angesehen werden.

==STM32H7==
Die bestehenden Regelkreise, Füllstandsregelung (Boiler und Tanks), Boilerdruckregelung,
Mischtemperaturregelung und Durchflussregelung werden von den drei Microcontroller auf
den STM32H7 verlagert. Ebenfalls erfolgt die Migration der Messwerterfassung aller
verbauten Sensoren auf die neue STM32H7-Plattform. 
Zusätzlich wird eine UART-Kommunikation implementiert, die die Anbindung des Displays,
eines Maschinensimulators sowie für den Zugriff durch eine externe Wartungs-App über
einem Gateway ermöglicht. 
Um einen geordneten Ablauf der einzelnen Komponenten bei Inbetriebnahme der Maschine
zu gewährleisten, wird eine Startprozedur programmiert. 
Die Hardware-Umsetzung wird von LfbA Armin Rohnen übernommen.

= Besprechungsprotokolle und weitere Unterlagen =
* [[:Datei:20260214 Abschlusspraesentation.pdf|Übergabepräsentation Vorgänger]]
* [[:Datei:20260326 Projektstart.pdf|Aktueller Projektstand]]
* [[Projektstart 26.03.2026]]
* [[Projektrücksprache 02.04.2026]]
* [[Projektrücksprache 09.04.2026]]
* [[Projektrücksprache 17.04.2026]]
* [[Projektrücksprache 24.04.2026]]
* [[Projektrücksprache 08.05.2026]]
* [[Projektrücksprache 15.05.2026]]
* [[Projektrücksprache 22.05.2026]]
* [[Projektrücksprache 29.05.2026]]
* [[Projektrücksprache 05.06.2026]]
* [[Projektrücksprache 12.06.2026]]
* [[Projektrücksprache 19.06.2026]]
* [[Projektrücksprache 03.07.2026]]
* [[Projektrücksprache 10.07.2026]]
* [[Projektrücksprache 24.07.2026]]
* [[Abschlusspräsentation 31.07.2026]]

Mikrocontroller Programmierung in MicroPython SoSe 2026

2026-04-20T19:12:51Z

Konstantin Rupprecht: /* STM32 */

<htmltag tagname="img" src="https://vg07.met.vgwort.de/na/3e58d840a91b42ac97ee493cdd085245" width="1" height="1" alt=""></htmltag>
[[Datei:Breites Logoband.png|mini|zentriert|hochkant=2.5]] 

= Mikrocontroller Programmierung in MicroPython Sommersemester 2026 =
Für die Projekte zur labortechnischen Espressomaschine (und weiteren Derivaten) ist die Mikrokontroller-Programmierung einer Steuerungselektronik erforderlich.

Die Programmierung der Mikrocontroller erfolgt in MicroPython und die übergeordnete Steuerung ist eine MATLAB®-APP mit einem Prozessschaubild. Die Grundfunktionalität dieses Vorgehensweise ist in der Quellenliste unter [40] (MATLAB® meets MicroPython) beschrieben.

Das Projekt wurde bereits durch eine Projektgruppe bearbeitet und hat einen Projektstand, der jedoch noch nicht die gesamte erforderliche Steuerungsfunktionalität umfasst.

Es wird angestrebt eine Steuerung auf Basis eines Nucleo STM32H743ZI2 zu erstellen. Dies würde die aktuell drei Steuerungsplatinen und Mikrocontroller auf einen reduzieren. Kommunikation wäre dann lediglich zum Displaycontroller erforderlich.

= Aufgabenanalyse =
==UART-Kommunikation==
Es soll eine Stern-Topologie implementiert werden, welche die UART-Kommunikation
zu einem separaten Display-Controller, dem Maschinensimulator und der Wartungs-
App herstellt. Dabei sind Sende- und Empfangs-Token f¨ ur das Display, die Wartungs-App und den Maschinensimulator einzuf¨ uhren. Es gilt dabei, den Umfang und Takt der
neuen Token festzulegen.

==Mehrkernnutzung und/oder Multitasking==

Es gibt bestimmte Vorgänge, welche regelmäßig zur Unterbrechung des Pro-
grammablaufs führen. Es gilt, diese Vorgänge zu identifizieren und umzuleiten,
damit diese den Programmablauf nicht mehr unterbrechen. Die Möglichkeit
der Mehrkernnutzung fällt dabei aus, da der STM32H753ZI nur über einen
M7-Kern verfügt. Dank der Hardware-Unterstützung DMA sowie der Nutzung
der uasyncio-Library besteht die Möglichkeit, die Vorgänge umzuleiten. Somit
können die Unterbrechungen des Programmablaufs reduziert werden.

== Maschinensimulator ==

== Füllstandsregler ==
Die Füllstandsregelung erkennt den Füllstand über eine Kurzschlussdetektion. Liegt kein
Kurzschluss vor, wird dies als zu niedriger Füllstand interpretiert und der Boilerdruckregler
zur Vermeidung von Trockenheizen gesperrt. Beim Erreichen des Sollfüllstands erfolgt eine
gezielte Überfüllung bei reduzierter Pumpenspannung, um ein periodisches Ein- und
Ausschalten der Regelung zu vermeiden. Da die in der MATLAB®-GUI realisierte Boiler Füllstandsregelung aus [114] bereits in einem ersten Stand in MicroPython übertragen
wurde, liegt der Fokus hier auf der Validierung am Maschinensimulator sowie der
Abstimmung mit den Schnittstellenpartnern.

== Boilerdruckregelung ==
Ziel ist es, die bisher in der MATLAB®-GUI realisierte Boilerdruckregelung aus [114], die auf
einem PD-Regler basiert, vollständig zu übertragen, sodass die Regelung unabhängig von der
externen PC-Umgebung arbeitet.

== Mischtemperaturregler ==
Der Mischtemperaturregler nach [114] dient zur Regelung der Kaffee- und
Teewassertemperatur und wird als PID-Regler für das Mischventil umgesetzt. Die Stellgröße
ist dabei die Verstellung des Mischventils. Der Temperatursollwert wird aus dem jeweils
aktiven Rezept vorgegeben. Da die Regelung vom aktuellen Durchfluss abhängt, wird eine
Kaskadenstruktur verwendet. In dieser Struktur arbeitet der Durchflussregler als innerer,
schneller Regelkreis, während der Mischtemperaturregler den äußeren Regelkreis bildet und
die Ergebnisse des inneren Kreises berücksichtigt. Daraus ergibt sich ein besonderes
Augenmerk auf das Testen des Zusammenspiels der beiden Regler anhand des
Maschinensimulators, um das Ziel – die Implementierung dieser Kaskadenregelung auf dem
STM32 – zu erreichen.

== Durchflussregler ==
Ein Durchflussregler, der in MATLAB® gemäß [114] vorliegt, wird als PID-Regler in
MicroPython umgesetzt. Durch die Anpassung der Pumpendrehzahl über einen
Spannungssollwert von 0–5 V kann ein konstanter oder ein profildefinierter Volumenstrom
entsprechend der Sollwertvorgabe realisiert werden. Als innerer Regelkreis liefert er
kontinuierlich Durchflusswerte an den Mischtemperaturregler. Daraus ergibt sich der Fokus
auf der Implementierung und dem Test des Reglers sowie auf der Validierung seines
Zusammenspiels mit dem übergeordneten Mischtemperaturregler im Maschinensimulator,
um die Integration auf dem STM32 sicherzustellen.

== Startprozedur ==

== Display ==

== STM32 ==
Als Haupt-MCU soll ein STM32H753ZI-Controller verwendet werden. Es soll sichergestellt
werden, dass die vorinstallierten Steckerleisten CN7 bis CN10 ausreichend Pins für
Definition der benötigten UART-, ADC-, DAC- und GPIO-Pins aufweisen. 
Die Boilerdruck-, die Wassertemperatur-, die Durchfluss- und die Füllstandsregelung des
Boilers müssen implementiert werden. Es soll ebenfalls eine UART-Kommunikation für ein
Touch-Display, einen Maschinensimulator sowie eine Möglichkeit zum Anschließen einer
Wartungs-App programmiert werden. Um einen geordneten Ablauf der einzelnen
Komponenten bei Inbetriebnahme der Maschine zu gewährleisten, soll eine Startprozedur
programmiert werden

== Wartungs - APP ==
Es müssen der Inhalt des Wartungs-Token definiert werden, ein GUI-Layout erstellt werden, ein Kommunikationsaufbau mit dem Maschinensimulator hergestellt werden, die Darstellung der Messwerte, eine manuelle Startprozedur, das Schalten von Magnetventilen, die Einstellung von Sollwertvorgaben (Boilerdruck, Bezugswassertemperatur, Durchfluss) und manuellen Stellwerten für das PWM-Heizelement, die Pumpenansteuerung und die Stellung des Dosierventils sowie die Messwertspeicherung und das Logging programmiert werden. Die App ist bis zu einem funktionsfähigen Prototypen erforderlich.

= Leistungsvereinbarung =

== Wartungs - APP ==
Die aktuelle MATLAB®-GUI soll in eine komfortable Bedienoberfläche für Wartungs- und Einstellarbeiten überführt werden. Bei aktivierter Wartungs-App sollen sämtliche Tastenfunktionen und die Vertikalhebelfunktion nutzbar sein und zudem alle Aktoren (Magnetventile, Pumpenleistung und Schrittmotorverstellungen) über diese App angesteuert werden können. Des Weiteren soll die bisherige Visualisierung der Messwerte und Schaltzustände erhalten bleiben. Dies allerdings mit einer geringeren Aktualisierungsrate, da vier Aktualisierungen pro Sekunde als ausreichend angesehen werden.

= Besprechungsprotokolle und weitere Unterlagen =
* [[:Datei:20260214 Abschlusspraesentation.pdf|Übergabepräsentation Vorgänger]]
* [[:Datei:20260326 Projektstart.pdf|Aktueller Projektstand]]
* [[Projektstart 26.03.2026]]
* [[Projektrücksprache 02.04.2026]]
* [[Projektrücksprache 09.04.2026]]
* [[Projektrücksprache 17.04.2026]]
* [[Projektrücksprache 24.04.2026]]
* [[Projektrücksprache 08.05.2026]]
* [[Projektrücksprache 15.05.2026]]
* [[Projektrücksprache 22.05.2026]]
* [[Projektrücksprache 29.05.2026]]
* [[Projektrücksprache 05.06.2026]]
* [[Projektrücksprache 12.06.2026]]
* [[Projektrücksprache 19.06.2026]]
* [[Projektrücksprache 03.07.2026]]
* [[Projektrücksprache 10.07.2026]]
* [[Projektrücksprache 24.07.2026]]
* [[Abschlusspräsentation 31.07.2026]]

Mikrocontroller Programmierung in MicroPython SoSe 2026

2026-04-18T00:48:58Z

Konstantin Rupprecht: /* Aufgabenanalyse */

Mikrocontroller Programmierung in MicroPython SoSe 2026

2026-04-18T00:47:39Z

Konstantin Rupprecht: /* Aufgabenanalyse */

Mikrocontroller Programmierung in MicroPython SoSe 2026

2026-04-18T00:42:58Z

Konstantin Rupprecht: /* Aufgabenanalyse */

Mikrocontroller Programmierung in MicroPython SoSe 2026

2026-04-18T00:37:31Z

Konstantin Rupprecht: /* Aufgabenanalyse */

Projektrücksprache 09.04.2026

2026-04-11T12:15:03Z

Konstantin Rupprecht:

=Besprechungsprotokoll-09.04.2026=
Ort: Online via Zoom 
Datum: 09.04.2026 
Teilnehmer: Konstantin Rupprecht, Loic Aboufiras, Francis Booth, Tillmann Haas, Felix Kerner, Armin
Rohnen 
Moderator: LfbA Armin Rohnen/Felix Kerner 
Protokollant: Konstantin Rupprecht

==Top 1) Annahme des Protokolls==
Das Protokoll aus der vorherigen Besprechung wurde nicht von Armin Rohnen anerkannt, da es Ihm
mehrmals in dem falschen Format von dem zuständigen Protokollanten zugesendet wurde. Es ist eine
erneute Sendung mit richtigem Format anzustreben.

==Top 2) Team-Feedback von LfbA Armin Rohnen==
LfbA Rohnen weiste das Team auf eine unzureichende Teamarbeit hin. Er machte deutlich, dass sich
die Teilnehmer mehr absprechen müssen. Es gilt die Aufgaben gemeinsam zu bewältigen.

==Top 3) Intervention von LfbA Armin Rohnen==
Aufgrund der mangelnden Teamarbeit befindet sich das Team nun im zwei-wöchentlichen Rückstand.
Da sich das Team jetzt schon im Rückstand befinde, veranlasste LfbA Rohnen diese Rücksprache als
Intervention. LfbA Rohnen verwies nochmals auf das Merkblatt. Es ist sich in Zukunft stärker an das
Merkblatt zu halten.

==Top 4) Umlegung des Besprechungstermin==
Der vorherige Besprechungstermin vom Donnerstag um 16 Uhr, wurde auf den Freitag um 17 Uhr
gelegt. Es soll den Beteiligten mehr Zeit für die Vorbereitung auf die Rücksprache geben.

==Top 5) Besprechung der Aufgabenanalyse==
LfbA Rohnen nahm den ersten Entwurf der abgegebenen Aufgabenanalyse nicht an, weswegen Herr
Rohnen die ToDo´s für die Aufgabenanalyse mit dem Team besprochen hat.

==Top 6) Hinweis zur Arbeitshaltung==
LfbA Rohnen weiste nochmals auf die Arbeitshaltung der Teilnehmer hin. Er machte deutlich, dass es
so nicht weiter gehen kann und sich die Beteiligten deutlich mehr mit dem Thema auseinander
setzten sollen. Die Teilnehmer bestätigten, dass sie ihre Arbeitshaltung ändern werden.

==Top 7) Roadmap erstellen==
LfbA Rohnen gab in Aufgabe, eine Roadmap für die nächsten drei Wochen zu erstellen. Diese soll bis
zum Freitag, den 10.04.2026 um 20 Uhr bei Herr Rohnen sein. Das Team soll sich damit
auseinandersetzten, wie es in Zukunft weitergehen soll.

==Top 8) Ziel für die nächste Rücksprache==
Es soll eine brauchbare Aufgabenanalyse vorliegen. Aus dieser Aufgabenanalyse soll dann die
Zielvereinbarung für das Projekt erstellt werden.

Projektrücksprache 09.04.2026

2026-04-11T12:12:37Z

Konstantin Rupprecht: Die Seite wurde neu angelegt: „=Besprechungsprotokoll-09.04.2026= Ort: Online via Zoom Datum: 09.04.2026 Teilnehmer: Konstantin Rupprecht, Loic Aboufiras, Francis Booth, Tillmann Haas, Felix Kerner, Armin Rohnen Moderator: LfbA Armin Rohnen/Felix Kerner Protokollant: Konstantin Rupprecht ==Top 1) Annahme des Protokolls== Das Protokoll aus der vorherigen Besprechung wurde nicht von Armin Rohnen anerkannt, da es Ihm mehrmals in dem falschen Format von dem zuständigen Pr…“

=Besprechungsprotokoll-09.04.2026=
Ort: Online via Zoom 
Datum: 09.04.2026 
Teilnehmer: Konstantin Rupprecht, Loic Aboufiras, Francis Booth, Tillmann Haas, Felix Kerner, Armin
Rohnen 
Moderator: LfbA Armin Rohnen/Felix Kerner
Protokollant: Konstantin Rupprecht

==Top 1) Annahme des Protokolls==
Das Protokoll aus der vorherigen Besprechung wurde nicht von Armin Rohnen anerkannt, da es Ihm
mehrmals in dem falschen Format von dem zuständigen Protokollanten zugesendet wurde. Es ist eine
erneute Sendung mit richtigem Format anzustreben.

==Top 2) Team-Feedback von LfbA Armin Rohnen==
LfbA Rohnen weiste das Team auf eine unzureichende Teamarbeit hin. Er machte deutlich, dass sich
die Teilnehmer mehr absprechen müssen. Es gilt die Aufgaben gemeinsam zu bewältigen.

==Top 3) Intervention von LfbA Armin Rohnen==
Aufgrund der mangelnden Teamarbeit befindet sich das Team nun im zwei-wöchentlichen Rückstand.
Da sich das Team jetzt schon im Rückstand befinde, veranlasste LfbA Rohnen diese Rücksprache als
Intervention. LfbA Rohnen verwies nochmals auf das Merkblatt. Es ist sich in Zukunft stärker an das
Merkblatt zu halten.

==Top 4) Umlegung des Besprechungstermin==
Der vorherige Besprechungstermin vom Donnerstag um 16 Uhr, wurde auf den Freitag um 17 Uhr
gelegt. Es soll den Beteiligten mehr Zeit für die Vorbereitung auf die Rücksprache geben.

==Top 5) Besprechung der Aufgabenanalyse==
LfbA Rohnen nahm den ersten Entwurf der abgegebenen Aufgabenanalyse nicht an, weswegen Herr
Rohnen die ToDo´s für die Aufgabenanalyse mit dem Team besprochen hat.

==Top 6) Hinweis zur Arbeitshaltung==
LfbA Rohnen weiste nochmals auf die Arbeitshaltung der Teilnehmer hin. Er machte deutlich, dass es
so nicht weiter gehen kann und sich die Beteiligten deutlich mehr mit dem Thema auseinander
setzten sollen. Die Teilnehmer bestätigten, dass sie ihre Arbeitshaltung ändern werden.

==Top 7) Roadmap erstellen==
LfbA Rohnen gab in Aufgabe, eine Roadmap für die nächsten drei Wochen zu erstellen. Diese soll bis
zum Freitag, den 10.04.2026 um 20 Uhr bei Herr Rohnen sein. Das Team soll sich damit
auseinandersetzten, wie es in Zukunft weitergehen soll.

==Top 8) Ziel für die nächste Rücksprache==
Es soll eine brauchbare Aufgabenanalyse vorliegen. Aus dieser Aufgabenanalyse soll dann die
Zielvereinbarung für das Projekt erstellt werden.