Der Blätterkatalog benötigt Javascript.
Bitte aktivieren Sie Javascript in Ihren Browser-Einstellungen.
The Blätterkatalog requires Javascript.
Please activate Javascript in your browser settings.
20 Elektronik 20 2024 EmbEddEd-SoftwarE malte Kaiser ist Softwareentwickler bei Ingenics Digital in Gräfelfing bei München mit Fokus auf Firmware-Entwicklung für eingebette Systeme mit Bare-Metalund 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 Literatur [1] Embedded Linux market report overview business research Insights april 2024 www businessresearchinsights com marketreports embeddedlinuxmarket-108687 [2] Nao L Passaro P Gioia Eund Petracca m asymmetric multiprocessing techniques in smart devices application in a drone navigation system 25th International Conference on Software telecommunications and Computer Networks SoftCom 2017 S 1–5 https doi org 10 23919 SoftCom 2017 8115511 [3] technical details of the realtime preemption the Linux foundation wiki https wiki linuxfoundation org realtime documentation technical details start [4] rPmsg messaging Protocol openamP Project documentation https openamp readthedocs io en latest protocol details rpmsg html 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 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 Hardwarespezifischen 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 hs