Mehrkernnutzung und/oder Multitasking - Versionsgeschichte

Konstantin Rupprecht am 27. April 2026 um 21:37 Uhr

2026-04-27T21:37:20Z

← Nächstältere Version		Version vom 27. April 2026, 23:37 Uhr
Zeile 1:		Zeile 1:
	=Konstantin Rupprecht, 27.04.2026<br>Multitasking mittels Uasyncio=		=Konstantin Rupprecht, 27.04.2026<br> Multitasking mittels Uasyncio=
	Uasyncio ist eine Implementierung von der asyncio library von C-Python für Microcontroller.		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		Es wird eingesetzt, um ein ähnliches Ergebnis wie bei Multithreading zu erzielen. Dabei

Konstantin Rupprecht am 27. April 2026 um 21:36 Uhr

2026-04-27T21:36:39Z

← Nächstältere Version		Version vom 27. April 2026, 23:36 Uhr
Zeile 1:		Zeile 1:
			=Konstantin Rupprecht, 27.04.2026<br>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.<br>

			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<br>Versuch der Mehrkernnutzung =		= Peter Vogginger, 15.01.2025<br>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.<br>		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.<br>

Peter Vogginger: /* Peter Vogginger, 15.01.2025Versuch der Mehrkernnutzung */

2026-02-13T16:29:52Z

Peter Vogginger, 15.01.2025Versuch der Mehrkernnutzung

Änderungen zeigen

Peter Vogginger am 15. Januar 2026 um 13:06 Uhr

2026-01-15T13:06:49Z

← Nächstältere Version		Version vom 15. Januar 2026, 15:06 Uhr
Zeile 11:		Zeile 11:
	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.<br>		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.<br>

	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.		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.<br>
	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. Es gilt, die Übersetzung des Getriebes im Schrittmotor zu beachten. Bisher fehlt noch der Programmcode.		Link zum bisherigen Programmcode: [[Datei:20260108_Test_Dualcorenutzung.zip]]<br>

			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. Es gilt, die Übersetzung des Getriebes im Schrittmotor zu beachten. Bisher fehlt hierzu noch der Programmcode.

	= Armin Rohnen, 11.04.2024 =		= Armin Rohnen, 11.04.2024 =

Peter Vogginger am 15. Januar 2026 um 12:58 Uhr

2026-01-15T12:58:48Z

← Nächstältere Version		Version vom 15. Januar 2026, 14:58 Uhr
Zeile 1:		Zeile 1:
			= Peter Vogginger, 15.01.2025<br>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.<br>

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

			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 ist frei im Netz erhältlich (Stichwort Stepper Code). 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. (Siehe hierzu Seite [[Kommunikation_per_UART]]).<br>

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

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

			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.
			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. Es gilt, die Übersetzung des Getriebes im Schrittmotor zu beachten. Bisher fehlt noch der Programmcode.

	= Armin Rohnen, 11.04.2024 =		= 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.		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.

Armin Rohnen: Die Seite wurde neu angelegt: „= 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 Mehrker…“

2024-04-11T12:41:46Z

Die Seite wurde neu angelegt: „= 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 Mehrker…“

Neue Seite

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