Startseite > Embedded > Entwicklungstools > Anforderungen an Entwicklungs-Tools steigen

Embedded-Software

Anforderungen an Entwicklungs-Tools steigen

4. April 2013, 10:40 Uhr | von Heiko Riessland

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Verschiedene TRACE-Methoden

Generell zeichnen sich bei der Verwendung der genannten Emulation Devices für Trace zwei unterschiedliche Methoden für unterschiedliche Problemstellungen ab. Zum einen lässt sich die aus vielen hundert Registern bestehende integrierte Logik zum Aufspüren von Fehlern nutzen. Folgendes noch relativ einfache Problem ist damit im Gegensatz zu früher leicht zu lösen: Eine globale Variable, die ausgehend vom Quelltext von drei Funktionen der Applikation aus beschrieben wird, ändert sich sporadisch derartig, dass dies vom Wert oder vom Zeitpunkt her nicht von diesen drei Funktionen aus erfolgt sein kann. Mit Hilfe der Trigger- und Trace-Logik der Emulation-Devices lassen sich in diesem Fall alle Schreibzugriffe auf diese Variable aufzeichnen, die NICHT von diesen Funktionen ausgehen. Dies kann auch über einen längeren Zeitraum hinweg erfolgen, wobei das System nach einem solchen Zugriff für eine Auswertung natürlich gestoppt werden kann. Für einen effektiven Einsatz der Emulation Devices bedarf es allerdings spezieller Tools, die in der Lage sind, die mehreren hundert Register der Trigger- und Filterlogik auf einer höheren Abstraktionsebene zu konfigurieren. So erlaubt der Universal Emulation Configurator (UEC) von PLS beispielsweise die schematische Definition von Trace- und Messaufgaben auf Basis eines State-Machine-Modells mit Signalen, States und Aktionen. Dieser Ansatz erlaubt ein komfortables Arbeiten auch bei komplexen Fehlerbedingungen.

Bei der zweiten Trace-Methode wird eine große Menge über den AURORA Gigabit-Traceport (AGBT) ausgegebener Daten statistisch ausgewertet und für das System-Level-Debugging – etwa für eine Code Coverage Analyse oder ein Performance-Profiling - genutzt. Voraussetzung dafür ist ein Entwicklungstool mit ausgeklügeltem Trace-Framework, das nicht nur große Datenmengen verschiedener Cores und Quellen verarbeiten kann, sondern auch umfangreiche grafische Darstellungsmöglichkeiten für die effektive Auswertung der Daten bietet.

Debuggen unter Feldbedingungen

Eine weitere Herausforderung für die Hersteller von Entwicklungstools für komplexe SoCs ist, dass in der Evaluierungsphase einer neuen Applikation leider meist viel zu wenig darüber nachgedacht wird, was mit der embedded-Applikation passiert, wenn sie erst einmal den Labortisch verlassen hat. Sowohl im automotiven als auch im industriellen Umfeld ist häufig auch ein Debuggen unter Feldbedingungen notwendig.

Für einen reibungslosen Debug-Ablauf sind einige grundsätzliche Dinge zu beachten. Um einen ausreichenden Abstand zum verwendeten PC zu ermöglichen, ist oft nahe an den Debug-Schnittstellen eine Signalkonditionierung und -Vorverarbeitung nötig, wobei man unbedingt zwischen den Target-Steckverbindern bzw. -Adaptern und der eigentlichen Probe unterscheiden sollte. Um über die übliche und für den Labortisch meist ausreichende Leitungslänge von 20 bis 25 cm hinaus zu kommen, gibt es verschiedene Möglichkeiten. Mit den speziellen JTAG-Extendern von PLS beispielsweise, bei denen dicht am Target eine Umsetzung in differentielle Signale erfolgt, ist eine Leitungslänge von bis zu zwei Metern zur Probe möglich, bei den über PCI-Express angekoppelten Debug-Pods des UAD3+ sogar bis zu fünf Meter. In Verbindung mit einer Ethernet-Anbindung der Probe ist damit ein Debuggen direkt im Fahrzeug oder unter industriellen Feldbedingungen möglich. Um eine mobile Einspeisung im Feld zu ermöglichen, sollte zudem ein weiter Eingangsspannungsbereich für die Versorgung der Probe vorhanden sein.

Eine weitere nicht zu unterschätzende Herausforderung vor allem bei Steuerungen für Elektromotoren oder Umrichter stellen Potentialunterschiede zwischen der Steuerungselektronik und hochspannungsführenden Teilen dar. Für die zu verarbeitenden Signale müssen die Eingänge der Debug-Probe möglichst empfindlich sein, gleichzeitig sollten sie aber robust gegen Überspannungen sein. Hier bieten sich Adapter mit induktiver Isolierung an, die ausreichende Geschwindigkeit und Spannungsfestigkeit mit einer aufgrund ihrer geringen Abmessungen weitgehenden Unempfindlichkeit gegenüber magnetischen Feldern kombinieren. Solche Adapter sind in Kombination mit den Universal Access Devices 2pro (UAD2pro) und UAD3+ inzwischen für zahlreiche Debug-Schnittstellen verfügbar.

Fakt ist, dass heutzutage an Entwicklungssysteme zum Testen und Debuggen von Embedded-Software viel höhere Ansprüche gestellt werden als noch vor wenigen Jahren. Nicht nur die enorm gestiegene Komplexität der SoCs, sondern auch der Umstand, dass Entwicklungstools immer häufiger außerhalb definierter Laborbedingungen zum Einsatz kommen, stellt ganz neue Anforderungen an die Hard- und Softwarekomponenten. Wer an falscher Stelle spart, zahlt deshalb über den gesamten Lebenszyklus eines embedded-Produkts hinweg möglicherweise einen hohen Preis.

Zum Autor:

Heiko Riessland ist Produktmanager bei PLS Programmierbare Logik & Systeme