Tipp Nr. 6: Soft- und Hardware-Know-how sind gleich wichtig
Bei der Entwicklung einer komplexen Embedded-Applikation sind nicht nur reine Hard- oder Software-Spezialisten gefragt. Mindestens ein Entwickler aus dem Team sollte sich darüber hinaus sehr gut mit hardwarenaher Software auskennen und entsprechende Kenntnisse über On-Chip-Diagnosemöglichkeiten mitbringen. Mit diesem Wissen kann er das gesamte Team bei der effizienten Anwendung des Debuggers unterstützen. Wenn verfügbar, empfiehlt es sich außerdem, mindestens ein Evaluation-Board zum Erlernen der Architektur zu beschaffen.
Tipp Nr. 7: Bedenken Sie die komplette Laufzeit der Applikation
»Manch ein Entwickler scheint nach wie vor dem Motto zu folgen ‚Aus den Augen, aus dem Sinn’«, fährt Riessland fort. »Wenn eine Embedded-Applikation, etwa ein Steuergerät, den Entwicklertisch verlässt, folgen noch Produktion und der Einsatz im Feld. Nur wird leider mitunter vergessen, dass zur Programmierung des On-Chip-Flashs - fast ausnahmslos Bestandteil jedes SoC - ebenso wie zum Softwareupdate oder zur Diagnose im Feld die Debug-Schnittstelle benötigt wird. Diese ‚Vergesslichkeit’ kann im Zweifelsfall richtig teuer werden.« Beispielsweise sei für die Produktion der Baugruppe dann ein Nadeladapter notwendig und Softwareupdates könnten nur direkt beim Hersteller durchgeführt werden. Deshalb empfiehlt sich nach Riesslands Ansicht generell der Einsatz von Tools, die den gesamten Lebenszyklus abdecken, vom Debugger für die Entwicklung, über Produktions- bzw. Service-Flasher bis zum Diagnosetool im Feld.
Tipp Nr. 8: Monitorbasiertes Debuggen - Schnee von gestern?
Für Heiko Riessland steht außer Frage, dass monitorbasiertes Debuggen immer noch ein aktuelles Thema ist: »Auch im Zeitalter der standardisierten Debug- und Trace-Schnittstellen gibt es noch Anwendungsbereiche für monitorbasierte Debugging-Lösungen. Die populärste ist sicherlich der gdb-Server beim Linux-Applikations-Debugging. Aber auch im hardwarenahen Bereich gibt es Anwendungen, bei denen an einem fertigen Gerät eine dedizierte Schnittstelle nach außen nicht zur Verfügung gestellt werden kann und das Debuggen z.B. über den CAN-Bus realisiert werden muss. Das ist z.B. dann der Fall, wenn Baugruppen zum Schutz vor Umwelteinflüssen gekapselt sind und nur die für den Betrieb notwendigen Anschlüsse mit Spezialsteckverbindern realisiert sind. Deshalb sollte man bei Neuanschaffungen darauf achten, dass das Tool auch diese Arten von Debugging entsprechend unterstützt.«
Tipp Nr. 9: Synchronisation von Multicore-SoCs
Immer mehr moderne SoC enthalten zwei oder mehr Mikrocontroller-Cores. Besonderes Augenmerk ist hier auf On-Chip-Synchronisationsmöglichkeiten zu legen. Fast jede externe Synchronisation führt zu einem zeitlichen Versatz, zum Beispiel beim gemeinsamen Starten und Stoppen der Cores. Der verwendete Debugger sollte auch hinsichtlich Aufbau und Bedienkonzept das Debuggen mehrerer Cores unterstützen, ohne mehrere Instanzen starten zu müssen.
Tipp Nr. 10: Achten Sie auf den Architektur-Support
Zu guter Letzt spielt neben den reinen Leistungsparametern auch das gesamte Umfeld der Mikrocontroller-Architektur wie Programmierbeispiele für komplexe Peripherals, Application Notes, Code-Generierungs-Tools, Anwenderforen, gute Kenntnis der Architektur bei den Tool-Anbietern etc. ein wichtige Rolle. Zugegeben, Letzteres ist schwer messbar. Bieten die Tools jedoch eine Unterstützung Architektur-spezifischer Features an, ist dies in der Regel ein verlässlicher Hinweis darauf, dass beim jeweiligen Tool-Anbieter entsprechend tiefes System-Know-how vorhanden ist und eine intensive Zusammenarbeit mit den jeweiligen MCU-Herstellern besteht.
Heiko Rießland auf dem Entwicklerforum »Embedded-System-Entwicklung« am 5.-6. Juli 2011 in Ludwigsburg einen Vortrag zum Thema "Der Debugger als Werkzeug für Test und Qualitätsssicherung" halten. Details finden Sie unter folgendem Link: http://www.embedded-entwicklerforum.de/programm/tag-2.html?program_id=4837