Kommunikation per UART

Armin Rohnen, 28.11.2025 - Grundkonzept des Programmcodes für die UART-Kommunikation

Auf den jeweiligen Platinen werden durch die Bestromung die MCUs gestartet und es werden nacheinander die Dateien "boot.py" und "main.py" abgearbeitet. In "boot.py" befindet sich weiter kein Progammcode, dort werden höchstens Systemeinstellungen vorgenommen. In "main.py" befindet sich die Initialisierung der jeweiligen Platine. Dieses Prgramm muss beendet werden und darf keine Endlosschleife enthalten. Die Steuerung des Ablaufes erfolgt über Interrupt-Service-Routinen (ISR) welche auf definierte Interrupts reagieren und jeweils den zugehörigen Programmcode ausführen.

Abb. 1) Konzept zur Initialisierung der Messwertplatine, (c) Armin Rohnen

Zur weiteren Funktionalität auf der Messwertplatine gehört mindestens die Erstellung des (Grund)Tokens und das erste Senden des Tokens. Wird ein Token empfangen bzw. werden Daten an der UART-Schnittstelle erkannt, erfolgt die Abarbeitung gemäß Abb. 2.

Abb. 2) Programmablauf UART ISR, (c) Armin Rohnen

Die Abarbeitung des UART IRQ erfolgt auf allen Platinen gleich. Der UART.IRQ_RXIDLE ruft als ISR "_uart_rx_handler" auf. Darin wird lediglich geprüft ob wirklich Daten am UART-RX eingegangen sind. Wenn ja, dann werden die Daten aus dem UART-Eingangspuffer ausgelesen und es wird "on_receive" zur weiteren Überprüfung des Tokens aufgerufen.
In "on_receive" wird geprüft ob es sich um den (richtigen) Token handelt und dieser Fehlerfrei übertragen wurde. Danach wird ein "local_receive" aufgerufen. Diese Methode der Klasse wird jeweils lokal mit der individuellen Token-Abarbeitung überschrieben. In der Token-Abarbeitung befindet sich üblich die Anweisung zum Senden des Tokens. Lediglich auf der Messwertplatine erfolgt das Senden des Tokens durch eine weitere ISR.
Die Auslagerung der eigentlichen Verarbeitung des Tokens auf einen lokalen Programmcode entlastet den IRQ, so dass dieser sehr schnell wieder aufgerufen werden kann.

Im "local_receive" der Messwertplatine ist die Überprüfung des ersten gesendeten Tokens enthalten. Ist dieser wieder auf der Messwertplatine eingetroffen, dann wird die Messwerterfassung gestartet und es wird mit der eingestellten Abtastrate des ADC die Alert IRS (Abb. 3) abgearbeitet, welche u.a. zu jedem vollen Messwertesatz einen neuen Token versendet.

Abb. 3) Programmablauf der ADC ISR auf der Messwertplatine, (c) Armin Rohnen

Peter Vogginger, 10.11.2025 - Aufgabenanalyse

Aktuell werden die Messwerte von jeder Platine eigenständig an die MATLAB®-GUI versendet. Diese visualisiert und verarbeitet die Messwerte. Die erforderlichen Stellgrößen werden wiederum auf den Platinen in Abhängigkeit der MATLAB®-GUI eingestellt.

In Zukunft soll die Kommunikation unter den MCUs erfolgen. Die Steuerung soll über die Maschinensteuerung erfolgen. Es wird weiterhin eine MATLAB®-GUI (im folgenden MATLAB®-Wartungsapp genannt) geben, diese dient jedoch lediglich für Wartungs- und Versuchszwecke. Die Aufgabe besteht darin, eine robuste und schnelle Kommunikation aufzubauen und diese anschließend auf allen MCUs zu implementieren.

In die Auflistung der miteinander kommunizierenden Steuergeräte ist ein Touch-Display und optional ein Maschinensimulator mit aufzunehmen. Dadurch ergeben sich fünf Platinen, die im ständigen Austausch miteinander stehen: Messwertplatine, SSR-Platine, Basisplatine, Display-Platine und Maschinensimulator.

Zur Fehleranalyse und Erprobung sollen weiterhin alle Messwerte in der Kommunikation enthalten sein, um die MATLAB®-Wartungsapp an die Display-Platine anschließen zu können und mittels Logging alle Daten darauf zu visualisieren. Angelehnt an das 1984 von IBM eingeführte Token Ring Network soll eine „im Kreis laufende“ Kommunikation aufgebaut werden.

Hardware-Aufbau

Die Verbindungen werden hardwareseitig durch den UART der MCUs hergestellt. Die UART Sendeleitung Tx einer MCU wird mit der Empfangsleitung Rx der nächsten MCU verbunden. Dies wird von Platine zu Platine in der Reihenfolge: Messwertplatine -> Basisplatine -> SSR-Platine -> Display-Platine -> Messwertplatine durchgeführt. Damit ergibt sich ein geschlossener Ring. Optional kann nach der Displayplatine noch der Maschinensimulator eingeschleift werden.

Messwerte

Es gibt einen definierten Token. Jede Platine erneuert ihren Anteil des Tokens und entnimmt dem Token die benötigten Informationen (Messwerte). Was zuvor die MATLAB®-GUI durchgeführt hat, übernehmen nun die einzelnen Platinen. Dadurch ergibt sich unter den Platinen eine Aufgabenverteilung. Tabelle 1 zeigt eine Auflistung der Daten, die in den Datensatz des Tokens aufgenommen werden sollen. Jede nummerierte Position erhält einen Platz, je nach Bedarf an Größe. Der Token wird als Bytearray ausgeführt.

Token

Anzahl

Die Anzahl der im Kreis laufenden Tokens soll sich auf einen beschränken. Dieser wird erstmalig von der Messwertplatine erzeugt und anschließend „im Kreis“ gesendet, wobei jede MCU nur den für sie relevanten Teil liest bzw. auch umschreibt. Die Abtastrate des ADC (analog digital converter) gibt die Taktrate des Tokens vor. Durch die Wahl der ADC-Abtastrate wird daher die Kommunikationsgeschwindigkeit (Token/s) beeinflusst. Dieser ist der Flaschenhals und es ist eine langsame Steigerung der Taktrate vorzusehen, um mögliche Auswirkungen und Probleme in der Übertragung festzustellen.

Struktur

Am Anfang befindet sich ein Startzeichen, um die Art des Tokens (Standard-, Start- oder Paniktoken; siehe unten), festzulegen. Anschließend folgt ein Datensatz und danach eine Prüfsumme. Der Datensatz ist so auszuführen, dass dieser einfach erweitert werden kann, um Erweiterungen zu ermöglichen (z.B. 2. Brühgruppeneinheit). Im Weiteren ist der Token möglichst kurz auszuführen. Der Token soll über eine einheitliche Länge verfügen. Der Token wird als bytearray angelegt und auch so empfangen. (dateneingang = bytearray(readIn(UART))) Datensatz: Jedem Messwert wird ein Bereich von 2 Byte als fester Platz im Token zugewiesen.

Prüfsumme

Um die fehlerfreie Übertragung eines Tokens zu bestätigen, wird aus dem Datenblock des Tokens eine Prüfsumme gebildet und diese ans Ende des Tokens angehängt. Das verwendete Verfahren ist CRC-32.

Standardtoken

Es ist erkennbar über das Startzeichen am Anfang und wird genutzt für den regelmäßigen Datenaustausch zwischen den MCUs. Starttoken: Es ist erkennbar über das Startzeichen am Anfang. Hierbei wird beim Einschalten der Espressomaschine die Betriebsbereitschaft der gesamten Kommunikation geprüft. Sowohl ob die Hardwareverbindung intakt ist als auch ob alle MCUs empfangen und senden können. Es gilt zu klären, welche MCU dies aussendet.

Paniktoken

Es ist erkennbar über das Startzeichen am Anfang. Dies ist die Realisierung eines Not-Halts. Es sollen alle Prozesse augenblicklich gestoppt werden.

Fehlererkennung

Wird das Token nicht innerhalb einer definierten Zeitspanne wieder am Empfang einer MCU erkannt, festgelegt über einen timer-Funktion, soll am Display eine Fehlermeldung ausgegeben werden. Erkennt eine Platine einen Fehler (aufgrund Timeout), werden Magnetventile geschlossen (stromlos geschaltet), die Heizungen und die Pumpen werden abgeschaltet, der Wert des Dosierventils Kaltwasser wird gespeichert. Es ist ein Fehlerspeicher im Grundkonzept vorgesehen.

Token Definition

Tabelle 1: Tokeninhalt

Platine	Byte-Nr	Bits / Bit-Nr.	Beschreibung	Wertebereich	Anmerkung
Messplatine	0,1	16 Bit	Leitwert	0,2 - 20 S/cm	16 Bit im Token dort wo diese Messwerte verarbeitet werden, werden sie mittels Kennlinie umgerechnet. Die csv-Datei der Kennlinie befindet sich auf der jeweiligen Platine. Der Tassenwärmer existiert nur 1x je Machine
	2,3	16 Bit	Boilerdruck	0,5 - 4,5 V / 0 - 4 bar
	4,5	16 Bit	Brühgruppendruck (1. BG)	0,5 - 4,5 / 0 - 12 bar
	6,7	16 Bit	Brühgruppendruck (2. BG)	0,5 - 4,5 / 0 - 12 bar
	8,9	16 Bit	Wassereingangstemperatur (ersatzweise Leitungsdruck)
	10,11	16 Bit	Boiler-NTC (1. BG)	Kennlinie
	12,13	16 Bit	Boiler-NTC (2. BG)	Kennlinie
	14,15	16 Bit	Tassenwärmer-NTC	Kennlinie
	16,17	16 Bit	Mischtemperatur-NTC (1. BG)	Kennlinie
	18,19	16 Bit	Mischtemperatur-NTC (2. BG)	Kennlinie
	20,21	16 Bit	Brühgruppen-NTC (1. BG)	Kennlinie
	22,23	16 Bit	Brühgruppen-NTC (2. BG)	Kennlinie
	24,25	16 Bit	Boilerheizung (Soll, 1. BG)	8 Hz PWM 0 - 100 %
	26,27	16 Bit	Boilerheizung (Soll, 2. BG)	8 Hz PWM 0 - 100 %
	28,29	16 Bit	Tassenwärmerheizung (Soll)	8 Hz PWM 0 - 100 %
SSR-Platine	30,31	16 Bit	Position Schrittmotor Dosierventil 1. BG	0 - 550
	32,33	16 Bit	Position Schrittmotor Dosierventil 2. BG	0 - 550
Basisplatine	34,35	16 Bit	Verstellwert Schrittmotor Dosierventil 1. BG	Integer mit Vorzeichen
	36,37	16 Bit	Verstellwert Schrittmotor Dosierventil 2. BG	Integer mit Vorzeichen
		16 Bit	Pumpensollwert 1. BG	0 - 4096	entspricht 0 - 5000 mV bzw. 0 - 5000 U/min
		16 Bit	Pumpensollwert 2. BG	0 - 4096	entspricht 0 - 5000 mV bzw. 0 - 5000 U/min
		8 Bit	Durchflussrate 1. BG	0 - 25 ml/s	Integerwert in 1/10 ml/s, damit Wertebereich 0 - 250
		16 Bit	Durchflusscounts 1. BG	0 - 65535	je Count 1/39,9 ml, Überlauf muss unterbunden werden
		8 Bit	Durchflussrate 2. BG	0 - 25 ml/s	Integerwert in 1/10 ml/s, damit Wertebereich 0 - 250
		16 Bit	Durchflusscounts 2. BG	0 - 65535	je Count 1/39,9 ml, Überlauf muss unterbunden werden
	38		Füllstandsbyte		Füllstände werden von den Füllstandsreglern auf der Basisplatine verarbeitet Füllstand Abtropfschale True verhindert Pumpenansteuerung Füllstand Boiler False verhindert Pumpenansteuerung
		0	Füllstand Boiler 1. BG	0/1
		1	Füllstand Boiler 2. BG	0/1
		2	Füllstand Tank Minimum	0/1
		3	Füllstand Tank Maximum	0/1
		4	Füllstand Abtropfschale	0/1
		5		0/1
		6		0/1
		7		0/1
	39		Magnetventile Byte 1		Magnetventile Y101 bis Y113 gehören zur 1. BG Y113 ist der Dampfhahn Y214 bis Y222 gehören zur 2. BG
		0	Y101	0/1
		1	Y102	0/1
		2	Y103	0/1
		3	Y104	0/1
		4	Y105	0/1
		5	Y106	0/1
		6	Y107	0/1
		7	Y108	0/1
	40		Magnetventil Byte 2
		0	Y109	0/1
		1	Y110	0/1
		2	Y111	0/1
		3	Y112	0/1
		4	Y113	0/1
		5	Y214	0/1
		6	Y215	0/1
		7	Y216	0/1
	41		Magnetventil Byte 3
		0	Y217	0/1
		1	Y218	0/1
		2	Y219	0/1
		3	Y220	0/1
		4	Y221	0/1
		5	Y222	0/1
		6		0/1
		7		0/1
Displayplatine	42,43	16	Bezugswassertemperatur 1. BG	30 - 98 °C	Integerwert in 1/10 °C, damit Wertebereich 300 bis 980
	44,45	16	Bezugswassertemperatur 2. BG	30 - 98 °C	Integerwert in 1/10 °C, damit Wertebereich 300 bis 980
	46,47	16	Bezugsmenge 1. BG	20 - 300 g bzw. ml	Integerwert in 1/10 ml, damit Wertebereich 200 bis 3000
	48,49	16	Bezugsmenge 2. BG	20 - 300 g bzw. ml	Integerwert in 1/10 ml, damit Wertebereich 200 bis 3000
	50,51	16	Bezugszeit 1. BG	0 - 120 Sekunden	Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
	52,53	16	Bezugszeit 2. BG	0 - 120 Sekunden	Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
	54,55	16	Preinfusionszeit 1. BG	0 - 120 Sekunden	Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
	56,57	16	Preinfusionszeit 2. BG	0 - 120 Sekunden	Integerwert in 1/10 Sekunde, damit Wertebereich 0 bis 1200
	58	8	Abschalttemperatur Entschichtung	90 - 98 °C	Integerwert in °C
	59	8	Grenztemperatur	135 - 150 °C	Integerwert in °C
	60	8	Sollwert Boilerdruck	1100 - 1500 mbar	Integerwert in 10 mbar, damit Wertebereich 110 bis 150
	61	8	Stellung Vertikalhebel	0 - 180 Grad	Integerwert
	62		Maschinenstatus Byte 1
		0	Mischerstatus 1. BG	0/1	True = Mischtemperatur erreicht
		1	Mischerstatus 2. BG	0/1	True = Mischtemperatur erreicht
		2	Entschichtung	0/1	True = Entschichtung aktiv
		3	Handhebelmodus	0/1	True = aktiv
		4	Rezepteingabe	0/1	True = aktiv
		5	Wartungsmodus	0/1	True = aktiv
		6	Schrittmotor Dosierventil Flag	0/1	True = Schrittmotor für Dosierventil Kaltwasser hat ursprüngliche Position erreicht (Teil der Initialisierung)
		7		0/1
	63		Maschinenstatus Byte 2
		0	Kaffeebezug 1. BG	0/1
		1	Kaffeebezug 1. BG	0/1
		2	Teewasserbezug	0/1
		3	Dampfbezug	0/1	Bewirkt 200 mbar Reduzierung Sollwert Boilerdruck
		4		0/1
		5	Aufheizen	0/1	True = Aufheizphase, False = Betriebsbereit
		6	Systemstart	0/1	True = Systemstart
		7	Sicherheitsfunktion	0/1	True = Sicherheitsfunktion aktiv

Peter Vogginger,19.10.2025 - NUCLEO_H743ZI2

Kommunikation als Token-Ring oder in Stern-Topologie

Der Wechsel der Kommunikation von dem geplanten Token-Ring-Verfahren, hin zur Stern-Topologie erfordert 3 serielle Schnittstellen. Dies ist mit der aktuellen Konstellation, 4 MCUs (Basisplatine, SSR-Platine, Messplatine und Displayplatine) mit jeweils einem Raspberry Pi Pico RP2040, nicht möglich. An einem RP2040 stehen 2 serielle Schnittstellen zur Verfügung.

Der Wechsel hin zu einem größeren Board, dem NUCLEO-H743ZI2 MCU-Board mit einer STM32H7 MCU. Der Wechsel würde Vorteile bieten:  

• weniger Elektronik in der Peripherie
• ADCs ausreichend am Board
• DACs ausreichend am Board
• 8 serielle Schnittstellen
• viel mehr nutzbare PINs

Die Vielzahl an Anschlüssen bietet die Möglichkeit, von aktuell 3 Platinen (und 3 MCUs) auf 1 Platine mit einem MCU-Board zu reduzieren.

Allerdings bietet diese Umstellung nicht nur Vorteile.

Nachteilig wäre, dass bei jedem MicroPython Update ein eigenes Derivat erstellt werden müsste, da default die ADC auf 12-Bit Auflösung in MicroPython definiert sind. Aktuell existiert ein Derivat mit 16-Bit ADC Konfiguration (NUCLEO_H743ZI2_v1-27-0_ADC_16BIT.hex), dies basiert auf der MicroPython Version v1-27-0.

Allerdings ist die Verfügbarkeit von NUCLEO-Boards immer zeitweise nicht gegeben. Diesbezüglich wäre ein Platinenlayout inkl. den Bauelementen für MCU und der direkten Peripherie erforderlich. Was aber erst nach der Inbetriebnahme der beiden Prototypen-Maschinen sinnvoll erscheint. Die Kosten dieser externen Entwicklung werden auf 50 t€ bis 100 t€ geschätzt.

Aufgrund der aktuellen Situation wird bis auf Weiteres die Verwendung von Raspberry Pi Pico verfolgt.

Armin Rohnen, 16.10.2025

Im Zuge der Analyse für die zweite Auflage von MATLAB® meets MicroPython ist das Thema der UART-Kommunikation tiefer betrachtet worden.

Die Kommunikation ist mit Sorgfalt zu programmieren. Durch Lesen und Schreiben auf die UART-Schnittstelle kann die MCU blockiert und dauerhaft an der Ausführung anderer Programmteile gehindert werden. Die Problematik ist in Abschnitt 3.13 der 2. Auflage MATLAB® meets MicroPython beschrieben.

Armin Rohnen, 11.04.2024

Armin Rohnen, Kommunikationskonzept mit Token

Seitens des Platinenlayouts für die Steuerungselektronik wurden die jeweiligen PINs der ersten UARTSchnittstelle für die spätere Inter-Kommunikation der Steuerung herausgelegt. Die Raspberry Pi Pico MCU verfügt über einen jeweils 32 Byte großen Eingangs- bzw. Ausgangspuffer für die UART-Schnittstelle. Dieser soll genutzt werden um die Kommunikation zu ermöglichen. Die jeweilige Kommunikation selbst wird dadurch auf diese 32 Byte begrenzt. Hardwareseitig ist es Denkbar, dass je MCU zwei weitere PINs für die Kommunikation verwendet werden. Lediglich auf der SSR-Platine ist dazu ein Eingriff ins Platinenlayout erforderlich. Dieser kann bei einem Prototypen handwerklich durchgeführt werden. Die zwei zusätzlichen PINs für die Kommunikation (GP04, GP05 auf der Basisplatine, GP03, GP04 auf der SSR-Platine, GP06, GP07 auf der Messplatine) fungieren als eingehender und ausgehender Interrupt, so dass die Kommunikation als ISR programmiert werden kann.

Angelehnt an das 1984 von IBM eingeführte Token Ring Network soll eine „im Kreis laufende“ Kommunikation aufgebaut werden. Ausgehend von der Messplatine wird ein Token über die einzelnen Platinen durchgereicht (Abbildung). Unter Berücksichtigung der Kommunikationsregeln können so eine beliebige Anzahl an Steuerungsplatinen in den Kommunikationsring eingebunden werden. Allerdings sollte dabei die Reihenfolge beachtet werden.

Die Messplatine sendet über UART am Ende jedes gültigen Messwertsatzes einen oder mehrere Token an die Basisplatine. In den Token befinden sich die aktuellen Messwerte und alle anderen „im Kreis laufende“ Daten. Beim ersten Senden werden hier u.u. 0-Werte verwendet, bis dass der erste Token wieder bei der Messplatine angekommen ist. Ggf. unterbricht die Messplatine auch das Senden des Token bzw. der ersten Token-Serie, bis zum ersten Eintreffen eines Tokens. Die Messplatine ist damit der Taktgeber der Kommunikation. Konkret erfolgt dies in Abhängigkeit der Abtastrate des AD-Wandlers.Wenn ein Token versendet ist, wechselt die Messplatine den Logikzustand des ausgehenden Interrupt-PINs. Bevor der nächste Token versendet wird, wird wieder der Ausgangslogikzustand des Interrupt-PINs hergestellt. Sobald die Messplatine auch einen Token empfangen hat wird auch der PWM-Stellwert für das Boilerheizelement (aus Regler Boilerdruck) und für den Tassenwärmer im Token übermittelt.

Von der Messplatine erhält die Basisplatine den Token. Die UART-Schnittstelle wird ausgelesen, wenn am eingehenden Interrupt-PIN der Logikzustand wechselt. Die Basisplatine tauscht im Token die Daten für die eigenen Messwerte, die Schaltzustände der Tasten, die Schaltzustände der Magnetventile usw. aus und sendet den Token an die SSR-Platine weiter. Ist der Token versendet, wechselt die Basisplatine den Logikzustand des ausgehenden Interrupt-PINs und arbeitet in gleicher Logik weiter wie die Messplatine.

Die SSR-Platine bekommt von der Basisplatine den Token durchgereicht. Die SSR-Platine wertet den Token lediglich aus, nimmt keine Veränderungen darin vor und reicht diesen dann weiter. Nach der SSR-Platine kann eine Display-Platine nachgeschaltet werden. Diese wertet die Informationen im Token aus und visualisiert diese bzw. stellt die Informationen über WLAN zur Verfügung. Im Falle eines Touch-Displays werden die Bytes für die Schaltzustände der Tasten ausgetauscht. Abschließend erhält die Messplatine wieder den Token und übernimmt die relevanten Informationen daraus in den neu zu sendenden Token.

Anstelle des eingehenden und ausgehenden Interrupt-PINs kann u.u. auch die MicroPython-Funktionalität uart.irq verwendet werden. Diese ruft eine ISR auf, sobald Daten im EIngangspuffer der UART-Schnittstelle eingegangen sind.

Das Konzept ist auszugestalten und der bzw. die Token sind exakt zu definieren. Dabei ist auch zu definieren (und zu erproben) wie die dann übergeordnete MATLAB®-GUI die Daten für die Visualisierung erhält. Der einzelne Token darf aufgrund der Limitierung durch den UART-Puffer des Raspberry Pi Picos 32 Byte nicht überschreiten. Als maximale Datenrate sind 115200 Baud möglich, was unter Berücksichtigung von START / STOP-Bits und Paritätsbit eine maximale Kommunikationsrate von 11520 Byte je Sekunde ergibt. Damit wären 360 jeweils 32 Byte lange Token in der Kommunikation möglich. Nach aktuellem Stand der Recherchen überschreitet die Datenmenge für die Kommunikation die 32 Byte Grenze, so dass mit mehreren Token gearbeitet werden muss. Jeder Token weist im ersten Byte eine Token-Nr auf, so dass der Token zweifelsfrei identifiziert werden kann. Alle Token müssen die gleiche Länge in Bytes aufweisen. Für zukünftige Erweiterungen sind Leer-Bytes in den Token vorhanden. Jeder der 4 Token muss die gleiche Länge in Bytes aufweisen.

Getaktet wird die Kommunikation durch die Datenerfassung der Messplatine. Aufgrund der jeweils ungültigen ersten Wandlung eines Messkanals ist eine maximale Abtastrate von 430 Messwerten je Sekunde aufgeteilt auf acht Messkanäle, was ca. 53 Datensätze je Sekunde ergibt. Bei einer Abtastrate von 475 SPS ergeben sich 30 gültige Messdatensätze je Sekunde.Wird nach jedem zweiten gültigen Messkanal ein 27 Byte langer Token von der Messplatine gesendet, dann ergibt dies eine Inter-Kommunikation zwischen den MCUs von 120 Token bzw. 3240 Byte je Sekunde, was unter der als Maximum angesehenen Datenrate liegt. Selbst bei einer Verlängerung der Token auf 32 Byte würde lediglich 1/3 des theoretisch möglichen Datentransfers durchgeführt.