Harte Echtzeitanforderungen mit Linux
Latenzen bei der Interprozessorkommunikation mit OpenAMP
Fortsetzung des Artikels von Teil 1
Linux-Userspace-Anwendung
Im Zentrum des Messsystems steht eine Anwendung, die im Linux-Userspace ausgeführt wird. Mit dieser Anwendung werden die Parameter der Messung konfiguriert. Abhängig von den gewählten Parametern wird die entsprechende Firmware für den Coprozessor geladen und gestartet. Anschließend wird von dieser Anwendung aus die Kommunikation mit dem Coprozessor initialisiert und die Latenzmessung gestartet. Dazu greift die Anwendung mittels des Linux Memory Device auf das Timer-Modul zu und konfiguriert es für die Messung.
Nach jedem einzelnen Messdurchlauf in einer Messreihe sammelt die Userspace-Anwendung die Zeitstempel, die an verschiedenen Messpunkten im Kommunikationsablauf erfasst wurden. Falls diese Messpunkte nicht in der Linux-Userspace-Anwendung selbst liegen, sind weitere Mechanismen notwendig für die Aufzeichnung und die Bereitstellung der Zeitstempel. Diese Mechanismen sind im Linux- Kernelmodul und in der Coprozessor-Firmware implementiert.
Linux-Kernelmodul
Das Linux-Kernelmodul ermöglicht die Aufzeichnung von Messpunkten im Linux-Kernel. Aus dem Kernel heraus kann ohne weiteres auf das Timer-Modul zugegriffen und ein Zeitstempel gelesen werden. Das Kernelmodul exportiert eine Funktion zum Aufzeichnen der Zeitstempel. Diese Funktion wird an verschiedenen Stellen in den Treibern, die im Kommunikationsablauf vorkommen, eingefügt. Damit die Messung das Timing des Kommunikationsablaufs nicht beeinflusst, werden die Messwerte erst in einer Datenstruktur im Kernelmodul zwischengespeichert. Nachdem ein Messdurchlauf abgeschlossen ist, kann dann die Userspace-Anwendung die Zeitstempel aus dieser Datenstruktur lesen.
Coprozessor-Firmware
Auf dem Coprozessor wird eine spezielle Firmware ausgeführt, die entweder Daten von der Linux-Umgebung empfängt oder Daten an diese sendet. Der Coprozessor hat wie der Linux-Kernel direkten Zugriff auf das Timer-Modul und kann ohne Umwege Zeitstempel aufzeichnen. Diese Zeitstempel müssen nach jedem Messdurchlauf an die Userspace-Anwendung übertragen werden. Das bedeutet, es müssen Daten zwischen den Umgebungen ausgetauscht werden. Dazu wird an dieser Stelle nicht RPMsg genutzt, da dies schließlich der Kommunikationsweg ist, der analysiert werden soll. Stattdessen wird ein weiterer geteilter Speicherbereich definiert, in dem eine spezielle Datenstruktur liegt. Um Kollisionen zu vermeiden, wird jeder Eintrag dieser Struktur nur von genau einer Umgebung aus geschrieben.
Mithilfe dieser Datenstruktur synchronisieren sich die Coprozessor-Firmware und die Userspace-Anwendung zwischen den jeweiligen Messdurchläufen. Zusätzlich schreibt die Coprozessor-Anwendung ihre aufgezeichneten Zeitstempel in diese Datenstruktur, damit die Userspace-Anwendung sie zu den Zeitstempeln aus der Linux-Umgebung hinzufügen kann. Diese simple Art der Kommunikation funktioniert nur, da die Userspace-Anwendung und Coprozessor-Firmware keine weiteren Aufgaben zu erfüllen haben. Daher können sie permanent diese Datenstruktur auf Änderungen überprüfen. In einer normalen Anwendung wäre dies nicht praktikabel.
Mit dem neu entwickelten Messsystem ist es nun möglich, Latenzen von Abläufen zu messen, die in einer anderen Umgebung und auf einem anderen Prozessor enden, als sie beginnen. Dadurch können die einzelnen Kommunikationsrichtungen unabhängig voneinander analysiert werden. Zusätzlich können mit diesem Messsystem an beliebigen Punkten im Kommunikationsablauf Messungen durchgeführt und dadurch sämtliche Teilprozesse individuell analysiert werden.
Jobangebote+ passend zum Thema
Ergebnisse der Latenzmessung und Analyse der Ursachen
Die Latenzmessungen wurden jeweils für die Übertragungsrichtung von der Linux-Umgebung zur Coprozessor-Umgebung und für die umgekehrte Richtung durchgeführt. Außerdem wurden Messreihen für beide möglichen Userspace-Schnittstellen in der Linux-Umgebung durchgeführt. Bei den Messungen wurden pro Messdurchlauf 496 Bytes an Nutzdaten übertragen. Das ist das Maximum, das mit einer RPMsg-Nachricht möglich ist.
Eine Messreihe umfasst 100 Millionen einzelne Messdurchläufe, um auch seltene Ausreißer mit hoher Wahrscheinlichkeit erfassen zu können. Die Messergebnisse zeigen, dass es einen großen Unterschied zwischen den Kommunikationsrichtungen und Umgebungen gibt (Tabelle 1 und 2). Die Ausreißer in der Coprozessor-Umgebung sind nur gering verglichen mit den durchschnittlichen Latenzen. Dies war zu erwarten, denn die FreeRTOS-Umgebung auf dem Coprozessor arbeitet deterministisch und es gibt nur wenige, seltene Unterbrechungen. Weiterhin sind die Latenzen im Coprozessor unabhängig von der Userspace-Schnittstelle im Linux-Kernel, da letztere keinen Einfluss auf die Abläufe im Coprozessor hat.
Die entscheidende Erkenntnis aus den Latenzmessungen liefern die Unterschiede zwischen den Kommunikationsrichtungen. Die Ausreißer der Latenzen bei der Kommunikation vom Coprozessor zur Linux-Umgebung liegen Größenordnungen über den maximalen Latenzen in der anderen Kommunikationsrichtung.
Liegen die maximalen Latenzen bei der Kommunikation von der Linux-Umgebung zum Coprozessor mit unter 100 μs in derselben Größenordnung wie die durchschnittlichen Latenzen mit 21 μs, so sind die Unterschiede bei der Kommunikation vom Coprozessor zur Linux-Umgebung deutlich größer.
Zwar sind bei der Kommunikation vom Coprozessor zur Linux-Umgebung die durchschnittlichen Latenzen auch in der Größenordnung von 100 μs, aber die Ausreißer reichen bis an 9 ms heran, also fast zwei Größenordnungen über der durchschnittlichen Latenz. Außerdem fällt auf, dass bei der Verwendung des TTY-Geräts die Maximallatenz von der Übergabe der Daten an das TTY-Gerät bis zur Verfügbarkeit der Daten im Linux-Userspace deutlich größer ist als bei der Verwendung des Character-Gerätes. Durch die Wahl des Character-Gerätes lässt sich hier also schon die Größe der Ausreißer reduzieren bzw. durch die Wahl der richtigen Userspace-Schnittstelle lassen sich bereits ein Teil der Latenzausreißer vermeiden.
Die Userspace-Schnittstelle ist jedoch nicht die einzige Quelle der Latenzausreißer. Auch die Verarbeitung im RPMsg-Framework im Linux-Kernel führt zu maximalen Latenzen im Bereich von 8 ms. Folglich eignet sich das RPMsg-Framework im Linux-Kernel in Kombination mit den Hardware-spezifischen Treibern für den IMX9352 nur für Anwendungsfälle, in denen keine kürzeren Kommunikationszeitspannen als mindestens 8 ms eingehalten werden müssen.
Sollten sich die Latenzausreißer hier auf eine eindeutige Ursache zurückführen lassen, so ließe sich diese Erkenntnis nutzen, um die Latenzausreißer zu reduzieren. Auf diese Art könnte die RPMsg-Kommunikation auch für Anwendungsfälle mit strikteren Anforderungen an die maximalen Latenzen genutzt werden.
______________________________________________________________________
OpenAMP – kurze Vorgeschichte zur Latenzmessung
Asymmetrisches Multiprocessing (AMP) bedeutet: Mehrere unterschiedliche Betriebssysteme werden auf einem heterogenen Multiprocessor-SoC betrieben. OpenAMP ist ein Open Source Framework der Arbeitsgruppe Multicore Assocation (MCA), das standardisierte Implementierungen von AMP-Funktionen für Bare-Metal- oder FreeRTOS-Umgebungen zur Verfügung stellt. Es basiert auf dem Remoteproc- und dem RPMsg-Framework (Remote Processor Messaging) im Linux-Kernel. Remoteproc wird genutzt, um von einer Host-Umgebung aus die Firmware für eine Remote-Umgebung zu laden und den Remote-Prozessor zu starten. RPMsg dient zur Kommunikation zwischen verschiedenen Umgebungen in AMP-Systemen.
Asymmetrisches Multiprocessing auf einem i.MX8X mit OpenAMP
Embedded-Anwendungen müssen performant, preiswert, sicher und energieeffizient sein. Deswegen werden immer mehr heterogene Multi-Processor-System-on-Chip (MPSoC) eingesetzt, da sie aus mehreren unterschiedlichen Prozessoren aufgebaut sind, die jeweils für gezielte Anwendungen unabhängig voneinander verwendet werden können und dadurch ein breites Leistungsspektrum von Anwendungsfällen in der Industrie abdecken. Auf den integrierten unterschiedlichen Prozessoren eines heterogenen MPSoC werden unterschiedliche Betriebssysteme eingesetzt: z. B. Linux auf dem Cortex-A35 und ein RTOS oder Bare Metal auf einem Microcontroller wie dem Cortex-M4. Der Einsatz von AMP-Systemen bringt in der Praxis eine Menge Herausforderungen mit sich:
- Die erste Problemgruppe ist die Interprozessorkommunikation und umfasst die Aufteilung des Speichers für die verwendeten Betriebssysteme und das Festlegen des Shared Memorys, der von beiden Prozessoren zum Austausch von Daten genutzt werden soll.
- Die zweite Problemgruppe stellt das Lifecycle-Management dar. Es muss geklärt werden, welcher Prozessor das Starten, Laden und Herunterfahren der Firmware für andere Prozessoren übernimmt. Wichtig ist hierbei, dass der Coprozessor mit unterschiedlichen Firmwares geladen werden kann, ohne andere Prozessoren zum Absturz zu bringen.
2020 wurde bei Ingenics Digital die Entwicklung, Umsetzung und Evaluierung von Asymmetric Multiprocessing anhand OpenAMP auf dem heterogenen MPSoC i.MX8X erarbeitet. Zu der Zeit gab es noch keinen allgemein anerkannten und standardisierten Lösungsansatz für die beiden Problemgruppen, weshalb viele Firmen proprietäre Lösungen entwickelten. In diese Lücke stieß das Projekt mit dem Ziel, einen möglichst allgemeingültigen Ansatz für die Interprozessorkommunikation und das Lifecycle-Management auf AMP-basierten MPSoCs zu finden. Auch hier bot OpenAMP vielversprechende Möglichkeiten zur Vereinfachung von Interprozessorkommunikation und Lifecycle-Management.
Ein geeigneter Entwurf sollte auf den MPSoCs i.MX8X von NXP Semiconductor implementiert werden und auf relevante Eigenschaften wie Latenzzeiten oder Datendurchsatz evaluiert werden. Zur Entwicklung wurde das SoM (System on Module) VAR-SOM-MX8X von Variscite, basierend auf dem MPSoC i.MX8X von NXP, und zusätzlich ebenfalls von Variscite das Development-Board Symphony-Board eingesetzt (Bild). Das OpenAMP-Framework wurde erfolgreich auf den Cortex-M4 portiert und die RemoteProc-Komponente im eingesetzten Linux-Kernel erweitert, um das Lifecycle-Management auf dem Embedded-Linux durchzuführen.
Für die Evaluierung des umgesetzten AMP-Systems wurden auf dem i.MX8X die Anwendungsszenarien »Prozessdatenüberwachung« und »Hardware-in-the-Loop« auf Latenzzeiten und Datendurchsatz gemessen. Die Messergebnisse zeigten hohe Ausreißer bei den Latenzzeiten, deren Ursache im Rahmen des Projekts zunächst nicht ermittelt wurde, da dies nicht das Ziel war. Im Folgeprojekt auf einem i.MX93 wurden dann diese Latenzen genauer untersucht.
Dr. Richard Kölbl, Ingenics Digital
_______________________________________________________________________
Malte Kaiser
ist Softwareentwickler bei Ingenics Digital in Gräfelfing bei München mit Fokus auf Firmware-Entwicklung für eingebette Systeme mit Bare-Metal- und RTOS-Umgebungen sowie Embedded Linux.
Bevor Kaiser begonnen hat, bei Ingenics Digital zu arbeiten, hat er Maschinenbau (Bachelor) und Automatisierungstechnik (Master) an der RWTH Aachen studiert und anschließend ein weiteres Master-Studium in Robotics, Cognition, Intelligence an der TU München abgeschlossen. Dabei hat er vor allem die Bereiche Regelungstechnik, Cyber-Physical-Systems und Echt- zeitsysteme vertieft.
- Latenzen bei der Interprozessorkommunikation mit OpenAMP
- Linux-Userspace-Anwendung
- Literatur
Lesen Sie mehr zum Thema
