Wie gehen JTAG, Eclipse und Nexus mit Multicore-Hardware um?
Fortsetzung des Artikels von Teil 1
Wie gehen JTAG, Eclipse und Nexus mit Multicore-Hardware um?
Diejenigen, die außer dem Entwickler wahrscheinlich am wenigsten profitieren, sind die Werkzeug- und Verbindungsanbieter. Warum sollten sie davon profitieren, wenn alle ihre Wettbewerber das gleiche Ziel ansteuern und damit Differenzierungsmerkmale verlorengehen? Allerdings verfügen erfolgreiche Werkzeuganbieter über Kernkompetenzen, die ihre Kunden schätzen. Die Werkzeuganbieter wissen auch, dass ihre Erlöse steigen würden, wenn ein breiteres Anwenderspektrum ihre Werkzeuge nutzen könnte. Sie wenden sehr viel Zeit und Geld auf für die Portierung ihrer Produkte auf verschiedene Siliziumplattformen. Diese Zeit und dieses Geld wären viel besser eingesetzt, wenn sie sich auf den Nutzen, den sie Endkunden bieten können, fokussieren, anstatt ständig dieselben Anpassungen für immer wieder neue Prozessoren zu entwickeln.
Was bringen die ganzen Standards den Entwicklern? Vor allem erhalten sie Wahlfreiheit. Das heißt, sie können aus einer Fülle von unterschiedlich teuren, verschieden gestalteten Werkzeugen und Verbindungen wählen. Es bedeutet auch, dass sie ihre Werkzeuge für viele Zielsysteme verwenden können und dass sich eine Verbindung genauso mit ARM-basierten Multicore-Produkten wie mit Mips-, Micro-Blaze- und Intelbasierten Multicore-Systemen herstellen lässt. Sie müssen keine neuen Werkzeuge mehr kaufen, da die verwendeten Debugger vielfältig einsetzbar sind, und können sich deshalb auf die Anwendungsentwicklung konzentrieren.
Jobangebote+ passend zum Thema
Die Rolle von Eclipse beim Multicore-Debugging
Der gegenwärtige Status von Debuggern und Verbindungen für Multicore-Entwickler ist gut und schlecht zugleich. Die Eclipse-Foundation und zahlreiche Unterprojekte machen Fortschritte im Embedded-Bereich. Eclipse bietet eine „Debug Platform“, die Debugger-Anbieter implementieren können, um jedes beliebige System zu debuggen. Das Resultat ist ein einheitliches Erscheinungsbild, gleichgültig ob ein Entwickler Java, ein Perl-Script oder eine Embedded-C/C++-Applikation debuggt. Eclipse wurde so entwickelt, dass es nicht nur mehrere Anwendungen simultan debuggen kann, sondern dies auch mit Hilfe zahlreicher Funktionsmerkmale erleichtert. In Eclipse geben alle „Views“ in einem Frame den momentan gewählten Kontext wieder.
Wenn ein Entwickler einen Thread in der Applikation „Foo“ als momentanen Kontext ausgewählt hat, dann werden alle Variablen-, Expressionund Register-Ansichten aktualisiert, um „Foo“ widerzuspiegeln. Wählt der Entwickler dann einen Thread in Applikation „Bar“, werden diese Fenster aktualisiert, um „Bar“ darzustellen. Kombiniert man dies mit der Tatsache, dass Entwickler mehrere Frame-Instanzen öffnen können, dann hat man den Beginn einer feinen Multicore-Entwicklungsumgebung (und einen guten Grund, um ein Dual-Monitor-System anzufordern).
Eclipse verfügt noch über weitere nützliche Funktionen für Multi-Kontext-Debugging, z.B. „Working Sets“ von Haltepunkten (z.B. setze den Haltepunkt in Datei theDriver.c in Foo, aber nicht in Bar). Das DSDP-Projekt (Device Software Development Platform) forciert beispielsweise den Aufbau einer flexiblen Debug-Hierarchie, die sich besser zur Unterstützung eines typischen Multicore-Szenarios eignet, zum Beispiel: connection device → core(s) → process(es) → thread(s). Zudem erzeugt das DSDP-Projekt eine gemeinsame Infrastruktur für den Anschluss von Remote-Targets und verwendet dann die Services auf ihnen (z.B. Debugging, Profiling, Untersuchen von Zieldateisystemen, Öffnen einer Shell).
- Wie gehen JTAG, Eclipse und Nexus mit Multicore-Hardware um?
- Wie gehen JTAG, Eclipse und Nexus mit Multicore-Hardware um?
- Multicore-geeignete Debugger
- Wie gehen JTAG, Eclipse und Nexus mit Multicore-Hardware um?
- Wie gehen JTAG, Eclipse und Nexus mit Multicore-Hardware um?
