Wie im vorangegangenen Beispiel verwenden wir wieder eine Standardanwendung auf einem MPC5554 Demonstration Board. Als Debugwerkzeug wird ein iSYSTEM iC5000 On-Chip Debugger eingesetzt. Wir betrachten das Zeitverhalten über die Nexusschnittstelle mit und ohne Slow Run Modus.
46 Instruktionen e.g. Bibliotheksaufruf für cast Operation: int i; float fRet; i = fRet; |
»Step over« über eine Funktion mit 7038 Instruktionen | |||
Interface |
ohne Slow Run |
mit Slow Run |
ohne Slow Run |
mit Slow Run |
Nexus 3 |
9,87 µs + 171 Kb Tracedatei | 2 s + 171 Kb Tracedatei | 522,7 µs + 190 Kb Tracedatei | 85 s + 190 Kb Tracedatei |
Zeitvergleich mit und ohne Slow Run.
Deutlich wird in diesem Zeitvergleich, woher »Slow Run« seinen Namen hat.
Einschränkungen von Slow Run
Slow Run eignet sich gut zum Trace kleinerer Bereiche der Applikation. Werden Bibliotheksfunktionen aufgerufen (siehe Tabelle oben), kann Slow Run sehr lange dauern, da teilweise viel Code eingefügt wird. Auch die Ausführung einer Funktion braucht im Slow Run Mode Zeit (siehe Tabelle oben Step over-Beispiel). Soll ein Trace einer kompletten Anwendung aufgezeichnet werden, ist es zu empfehlen, die Daten im Slow Run Modus über Nacht zu erfassen.
Eine weitere Einschränkung von Slow Run Modus ist das möglicherweise veränderte Verhalten der Anwendung. Durch die schrittweise Abarbeitung der Applikation kann die Reaktion auf externe Signale z.B. Timer und Interrupts deutlich verspätet oder im schlimmsten Fall gar nicht erfolgen, wenn z.B. ein Interrupt verloren geht.
Kein Ersatz für MCUs mit Traceport
Slow Run Modus ermöglicht das Debuggen und die Analyse des kompletten Programm- und Datenflusses inklusive Profiling und Code Coverage, auch wenn die MCU keinen Traceport zur Verfügung stellt. Slow Run Modus ist kein Ersatz für leistungsfähige MCUs mit Traceport und entsprechende Debugger, aber öffnet jedem Entwickler den Zugang zu den internen Abläufen der kompletten Anwendung, wo ohne Slow Run Modus nur winzig kleine Ausschnitte sichtbar sind.