Mehrkernnutzung und/oder Multitasking

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

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

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.