Industriecomputer & Betriebssysteme Entwickeln per USB-Stick
Mikrocontroller sind bekannt dafür, Steuerungsapplikationen in der Industrie aufzuwerten. Da sie immer leistungsfähiger und schneller werden, kommen sie in sehr anspruchsvollen Umgebungen
Anbieter zum Thema
Mikrocontroller sind bekannt dafür, Steuerungsapplikationen in der Industrie aufzuwerten. Da sie immer leistungsfähiger und schneller werden, kommen sie in sehr anspruchsvollen Umgebungen wie Fahrzeugen, Mobiltelefonen und sogar in der Raumfahrttechnik zum Einsatz. Da die Betriebsanforderungen an Mikrocontroller steigen, erhöht sich aber auch die Entwicklungs- und Qualifizierungsdauer.
Die Entwicklung eines Embedded-Systems kann wenige Monate oder sogar Jahre in Anspruch nehmen, eine Person oder ein ganzes Team involvieren, zu dem Hardware-, Software- und Systementwickler zählen. Richtige Entscheidungen während der anfänglichen Entwicklungsphase sind entscheidend, um kostspielige Redesigns zu vermeiden. Die vom Entwickler oder Design-Team gewählten Algorithmen, Designs und Mikrocontroller können erheblichen Einfluss auf die Markteinführungsdauer, Leistungsfähigkeit und Kosten des Gesamtprojekts haben.
Zu Beginn eines jeden Projekts muss sich ein Embedded-System-Entwickler, der ein Mikrocontroller-basiertes System entwickelt, zwei Fragen stellen: Welche MCU bietet die Leistungsmerkmale, um das Problem zu lösen und wie hoch sind die Kosten? Zwar sind noch andere Fragen zu klären, wie die Möglichkeit der IP-Wiederverwendung oder das Know-how des Entwicklungsteams – die vorher genannten beiden Fragen stehen bei einem Designprozess aber an erster Stelle.
Während des Auswahlprozesses sollte die Qualität der Entwicklungswerkzeuge nicht vernachlässigt werden. Eine leistungsfähige MCU mit umfangreichen Leistungsmerkmalen kann die Stückliste reduzieren und den Code vereinfachen – geeignete Entwicklungswerkzeuge sorgen aber dafür, Designfehler rechtzeitig zu erkennen, die Verifikationsdauer zu verkürzen und im Feld Download- und Debug-Zugriff zu ermöglichen. Damit ergeben sich geringere Entwicklungskosten und nach der Auslieferung des Produkts eine einfachere Wartung.
Ideale Entwicklungs-Tools sollten vollen Zugriff auf den Mikrocontroller erlauben, gleichzeitig aber nicht intrusiv sein und das Systemverhalten nicht verändern. Sie sollten kosteneffizient, im Feldseinsatz und in der Entwicklungsumgebung einsetzbar sein. Jeglicher Zeitaufwand, der für fehlende Leistungsmerkmale eines Entwicklungs-Tools anfällt, beeinträchtigt die Produktentwicklung. Derzeit sind verschiedene Entwicklungs-Tool-Optionen verfügbar. Jeder Ansatz bietet seine eigenen Leistungsmerkmale und sollte anhand des idealen Endergebnisses berücksichtigt werden.
Entwicklungs-Tool-Optionen
Eines der beliebtesten Entwicklungswerkzeuge ist ein In-Circuit-Emulator (ICE). Dieser besteht aus einem Chip, der die Ziel-MCU im Endsystem ersetzt und über eine Translation-Box (Pod) an den PC angeschlossen ist. Der ICE-Chip enthält Debug-Hardware, die in Standard-MCUs nicht vorhanden ist. In Kombination mit dem Pod steht dem Entwickler somit voller Zugriff auf die Register und den Speicher der MCU zur Verfügung. Außerdem ist damit ein zeilenweises Source-Debugging möglich.
Die In-Circuit-Emulation bietet viele Vorteile und einen Einblick, wie sich die MCU mit echten Signalen und Daten im Zielsystem verhält. Beim Debugging sorgt die ICE jedoch für einige Einschränkungen. Eine davon ist, dass das Debugging nur im Labor bzw. Büro möglich ist. Ein Systementwickler versucht alle möglichen Szenarien während der Entwicklungsarbeit durchzuprobieren. Der wahre Test des Systems geschieht allerdings im Feldbetrieb. Ist das fertige Produkt anstelle einer Debug-fähigen MCU mit einer Standard-MCU im Feldeinsatz, sind die Debugging-Möglichkeiten verloren. Durch Embedded-Systeme wird es schwierig, die Standard-MCU zu entfernen, einen neuen debugfähigen Chip einzulöten und das System wieder mit dem PC zu verbinden. Um Probleme im Feld zu lösen, muss das Endsystem zurück ins Labor gebracht und die Ziel-MCU ersetzt werden, um anschließend ein Debugging durchführen zu können.
Bei ICE-basierten Debugging-Systemen ist auf die zusätzlichen Kosten zu achten. Zusammen mit den Standard-MCUs muss ein Entwickler ICE-fähige MCUs und einen Pod kaufen, was die Projektkosten erheblich erhöht. Ist die ICE-fähige MCU nicht Pin-zu-Pin-kompatibel mit der Standard-MCU muss der Systementwickler ein zweites Board rein zu Entwicklungszwecken anfertigen. Da sich dieses zweite Board vom Endsystem unterscheidet, muss die auf dem Board durchgeführte Verifikation mit dem endgültigen System dupliziert werden.
Am anderen Ende des Entwicklungs-Tool-Spektrums befindet sich der Emulator. Dabei handelt es sich um ein Programm, das auf einem PC läuft und in Software versucht, das Verhalten einer MCU zu reproduzieren. Die Vorteile liegen auf der Hand: durch die Software-basierte Technologie ist keine kundenspezifische Hardware erforderlich. Ein Entwickler kann mit dem Schreiben und Debuggen von Code sofort nach der Auswahl der MCU beginnen – und das selbst außerhalb des Labors bzw. Büros. Die Softwareflexibilität ermöglicht zusätzliche Leistungsmerkmale wie das Festlegen einer unendlichen Anzahl von Breakpoints. Das gründliche Code-Profiling vereinfacht sich, da das Programm den Zustand des Bausteins genau kennt.
Die Qualität eines Emulators hängt direkt davon ab, wie genau das Softwaremodell die eigentliche Hardware repräsentiert. Es ist schwierig, eine Zustandsmaschine zu implementieren, die für das Timing der Hardware verantwortlich ist. Jegliche Designfehler im Emulator oder jegliches MCU-Verhalten, das nicht vom Emulator festgehalten wird, kann zu fehlerhaftem Code führen und ein Redesign erfordern.
Ein Emulator bietet keinen Überblick über die Leistungsfähigkeit des Gesamtsystems. Embedded-Designs enthalten meist analoge und digitale Bauteile – ein softwarebasierter Emulator kann nicht all diese Faktoren berücksichtigen. Nachdem mithilfe eines Emulators ein erheblicher Fortschritt in der Entwicklungsarbeit erzielt wurde, muss ein Entwickler mit dem Testen der eigentlichen Hardware beginnen und eine zweite Methode für Entwicklung und Debugging finden. Die Lösung von Hardware-Problemen im Feld erfordert ebenfalls eine andere Debug-Lösung.
Was ein Entwickler wirklich benötigt
Idealerweise sollten die MCU und die Entwicklungswerkzeuge alle o.g. Leistungsmerkmale ohne Einschränkungen bieten. Anstelle eines zweiten Bausteins, der die Debug-Logik enthält, sollte die Logik Teil einer jeden MCU sein, um ein Debugging direkt auf dem Endsystem durchführen zu können. Jeder ausgelieferte Baustein ließe sich dann auch einfach updaten und debuggen. Debug-Logik auf dem Chip erübrigt die Anschaffung teurer externer Debugging-Hardware. Die einzige Anforderung ist eine Schnittstelle zwischen der MCU und dem PC. Die Timing- und Systemintegrations-Anforderungen eines Emulator spielen dann ebenfalls keine Rolle mehr.
Eine ideale Lösung bietet all diese Leistungsmerkmale mithilfe einer Flash-basierten MCU und einer Debugging-Logik, die vollen, nicht intrusiven Zugriff auf alle Speicher und Register ermöglicht. Eine IDE, die passend zur Core-Logik arbeitet, ermöglicht einen umfassenden Echtzeit-Zugriff auf den Baustein und zahlt sich somit ebenfalls aus. Flash-basierte MCUs bieten den Vorteil, dass sie sowohl in der Entwicklung als auch im Feldeinsatz einfach einem Update unterzogen werden können.
Eine MCU- und Entwicklungs-Tool-Option, die diese Leistungsmerkmale bietet, ist die Familie der Flash-basierten 8051-kompatiblen MCUs von Silicon Laboratories. Das Unternehmen bietet dazu einen ToolStick, ein Evaluierungs-Tool, das einen USB-basierten Debug-Adapter und eine eigene Ziel-MCU in einem USB-Stick enthält. Neben der Verfügbarkeit der Entwicklungs-Tools dient der Stick auch als tragbare Entwicklungsplattform für die Ziel-MCUs. Bild 1 zeigt ein Blockdiagramm eines Zielsystems, das eine Debug-Verbindung enthält, die zur Entwicklung und Programmierung verwendet werden kann.
Silicon Laboratories, Tel. +49(0)7231 589170
Gautam Penumetcha ist Applications Engineer bei Silicon Laboratories in Austin, Texas.
(ID:184226)