Suchen

Kein Rätselraten mehr

Trace-Visualisierung stützt das Debugging von RTOS-basierter Firmware

Seite: 3/4

Firma zum Thema

Das Debugging RTOS-basierter Systeme

Der Wunsch, das Debugging auf derselben Abstraktionsebene durchzuführen wie die Entwicklung, ist völlig normal, jedoch haben sich die Debugging-Tools auf den RTOS-Trend noch nicht entscheidend weiterentwickelt.

Bildergalerie

Einige Debugger wurden zwar mit so genannten ‚RTOS Awareness‘-Features aufgewertet, die Ihnen beim Debugging das Inspizieren des Status von RTOS-Objekten wie etwa Tasks und Semaphoren ermöglichen. Hierbei handelt es sich jedoch nur um Nachbesserungen an den Quellcode-Debuggern der zweiten Generation, deren Fokus strikt auf dem Quellcode und dem Debugging nach dem Run/Halt/Single-Step-Prinzip liegt.

Ein RTOS-basiertes System mit einem traditionellen Source-Level Debugger zu debuggen, ist vergleichbar mit dem Versuch, einen auf der Assembler-Ebene arbeitenden Debugger bei der C-Programmierung einzusetzen.

Um das Laufzeitverhalten eines RTOS-basierten Systems umfassend zu verstehen, müssen Sie das Echtzeitverhalten auf der RTOS-Ebene beobachten können, wofür ein auf RTOS ausgerichtetes Tracing-Tool benötigt wird.

Dieses operiert als Ergänzung zu traditionellen Debugging-Tools und stellt eine Zeitachse auf der RTOS-Ebene bereit. Ein traditioneller Debugger ähnelt sehr einem Mikroskop, mit dem sich die detaillierte Verarbeitung innerhalb eines Tasks untersuchen lässt. Das Tracing dagegen ist mehr so etwas wie ein Zeitlupenvideo der Echtzeitverarbeitung.

Hardware- versus softwarebasiertes Tracing

Es gibt zwei Arten des Tracings, die jeweils geringfügig unterschiedlichen Zwecken dienen. Das hardwarebasierte Tracing wird vom Prozessor selbst generiert. Es liefert ein detailliertes Verarbeitungs-Trace auf der Quellcode- oder Assembler-Ebene, allerdings mit wenig oder gar keiner RTOS-Orientierung.

Es wird hauptsächlich für die Überdeckungsanalyse und das Debugging besonders kniffliger Probleme verwendet, für die ein maschinennahes Instruction-Tracing benötigt wird.

Beim softwarebasierten Tracing werden dagegen kleine Tracecode-Abschnitte in die Zielsoftware eingefügt, um wichtige Ereignisse im RTOS sowie optional auch im Applikations-Code aufzuzeichnen. Meist muss man den RTOS-Trace-Code aber nicht selbst einfügen, denn viele RTOS-Kernels enthalten an strategischen Punkten bereits Trace-Makros.

Das softwarebasierte Tracing kann deshalb auf jedem Prozessor genutzt werden, beliebige Arten von Software-Ereignissen speichern und jegliche relevanten Daten einschließen. Nachteilig ist der Verarbeitungsaufwand des Tracing-Codes, allerdings verbraucht das RTOS-Tracing auf einer modernen 32-Bit-MCU nur ein paar Prozent der Prozessorzeit, da nur sehr wenige Daten aufgezeichnet werden müssen und die erfassten Ereignisse nicht sehr häufig auftreten.

Hierdurch ist ein kontinuierliches Streamen der Daten über gängige Debug-Schnittstellen oder auch über Interfaces wie USB oder TCP/IP möglich. Die geringe Datenrate lässt ebenfalls das Tracing in einen RAM-Puffer zu.

Schon wenige Kilobyte reichen aus, um ein brauchbares Trace der jüngsten Ereignisse zu bekommen. Somit ist ein Tracing auch außerhalb des Labors möglich – zum Beispiel im Zuge von Feldtests oder an schon im Einsatz befindlichen Systemen.

(ID:44740567)