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.
30 Elektronik 10 2020 Embedded-Systeme ten wie Tasks oder Semaphoren untersuchen können Das reicht jedoch nicht aus Ein RTOS-Debugging-Tool muss vielmehr das Konzept Zeit verstehen damit es Ereignisse korrelieren kann Außerdem muss es den Entwicklern die Möglichkeit geben das Echtzeitverhalten einer Anwendung zu beobachten Das verlangt nach RTOS-Tracing was bedeutet dass die Softwareereignisse im Laufzeitcode im RTOS-Kernel und optional auch im Anwendungscode für die Hostseitige Analyse aufgezeichnet werden Eine gutes Visualisieren ist entscheidend zum Verstehen von RTOS-Traces Viele Embedded-Systeme legen zudem ein zyklisches Verhalten an den Tag sodass ein Trace größtenteils aus Wiederholungen des normalen Ablaufmusters besteht Interessant sind meist die Anomalien die jedoch in einem Rohdatenstrom möglicherweise schwer zu erkennen sind Bei einer grafischen Darstellung dagegen treten die Anomalien klar hervor Ein Debugging-Tool das die Ereignisse und Datenstrukturen eines RTOS versteht kann aus einem Trace außerdem weit mehr Informationen extrahieren als lediglich den grundlegenden Verarbeitungsablauf Zum Beispiel besteht die Möglichkeit zum Erstellen eines Abhängigkeitsdiagramms aus dem die Interaktionen zwischen Tasks Interrupt-Service-Routinen und RTOSObjekten wie etwa Semaphoren und Message Queues hervorgehen Sehen heiSSt verstehen Die primäre Aufgabe eines SoftwareTracing-Tools besteht im Erfassen von Ereignissen im Zielsystem Hier reicht die Skala von Schedulingund RTOS-Aufrufen bis zu Timer-Ticks und anwendungsspezifischen Log-Nachrichten Man braucht jedoch lediglich einen kurzen Blick auf ein typisches Event Log Bild 1 zu werfen um zu erkennen dass es zwar sinnvoll sein mag ein solches Textdokument ist jedoch nicht auf die großen Datenmengen skalierbar die beim SoftwareTracing entstehen Das gezeigte Beispiel bezieht sich auf eine Ausführungszeit von lediglich etwa 2 ms Ein RTOSTrace das sich über mehrere Minuten erstreckt kann dagegen Millionen von Ereignissen enthalten Das Auffinden eines Fehlers in einem umfangreichen Text-Log gleicht der sprichwörtlichen Suche nach der Stecknadel im Heuhaufen und der Entwickler weiß dabei nicht einmal wie die Nadel aussieht nach der er eigentlich sucht Um die nächste Ebene zu erreichen also zu verstehen welches Verhalten beabsichtigt ist und welches nicht sind Entwickler auf geeignete Tools zum Visualisieren der Daten angewiesen Besser lassen sich große Mengen an RTOS-Trace-Daten mit einer grafischen Trace-Ansicht in der Art eines GanttDiagramms Balkenplan darstellen Bild2 Die Trace-Daten erscheinen dabei entlang einer interaktiven Zeitleiste Entwickler können somit in einer niedrigen Zoomstufe den Überblick über umfangreiche Trace-Daten gewinnen und abnormale Muster identifizieren anschließend den Zoomfaktor erhöhen um Einzelheiten sichtbar zu machen Eine grafische Trace-Darstellung muss sich nicht auf das Ausführen der RTOS-Tasks beschränken sondern kann auch Programmierschnittstellenaufrufe Log-Nachrichten der Anwendung und andere Ereignisse einschließen wie das folgende Beispiel zeigt Bugs aufdecken mit graphischen Mitteln Eine Herausforderung mit der die Entwickler von Embedded-Systemen häufig zu tun haben ist die Tatsache dass die Zielsysteme häufig in ihrer CPULeistung und ihrem Speicherplatz beschränkt sind Hier kann ein CPUAuslastungsdiagramm wie es nachfolgend gezeigt ist hilfreich sein Es gibt an wieviel Prozessorzeit die einzelnen Tasks und Interrupt-Serviceroutinen beanspruchen Anhand dieser Informationen lässt sich schnell erkennen an welchen Stellen die Auslastung über eine längere Zeitspanne nahezu 100 Prozent beträgt was wahrscheinlich zu einem verzögerten Ausführen von Tasks führt Außerdem lässt sich erkennen wieviel CPU-Zeit für neue Features verfügbar ist ohne die Hardware aufzurüsten Bild 3 Um auf den Debugging-Aspekt des Tracings zurückzukommen wird eine durchgegangene Task die mehr CPUZeit als vorgesehen beansprucht in einem CPU-Auslastungsdiagramm deutlich auszumachen sein Gleiches gilt für Tasks die das ineffiziente Busy Waiting nutzen Es vergeudet nämlich CPU-Zeit die sonst für andere Tasks verfügbar wäre und ist ein häufig begangener Verstoß gegen die Regeln für gutes RTOSbasiertes Design Mit dem Verfolgen von API-Aufrufen erfasst man tatsächlich Abhängigkeiten zwischen den Tasks und kann sie Bild 4 Das Kommunikationsflussoder Abhängigkeitsdiagramm ist ein geeigneter Ausgangspunkt für viele Debugging-Sitzungen denn es bietet gleichsam aus der Vogelperspektive einen Blick auf die Architektur der Anwendung woraufhin Entwickler jedes Objekt im Diagramm mit einem Doppelklick genauer unter die Lupe nehmen können Bild Percepio