Software-Entwicklung Software zum Laufen bringen

Bevor ein Mikrocontroller zum Leben erwacht, muss er mit Software gefüttert werden. Doch Software »läuft« nicht einfach, sie muss entwickelt werden. Dazu sind ausgefeilte Werkzeuge nötig. Zum Glück ist Infineon dabei nicht auf sich alleine gestellt. Für die populären -Architekturen gibt es viele Zulieferer, die den Software-Entwickler mit »Stoff« versorgen.

Um Software für Mikrocontroller zu programmieren, sind zunächst die gleichen Entwicklungswerkzeuge nötig wie für PC-Software: Ein Editor für den Quellcode sowie ein Compiler und Linker zum Übersetzen des Quellcodes in maschinenlesbare Befehle. Damit hören die Gemeinsamkeiten aber auch schon auf. Denn PC-Software läuft auf dem gleichen System oder zumindest der gleichen Architektur ab, auf der auch entwickelt wird (Self-Hosted-Entwicklung).

Auf den meisten Mikrocontrollern wäre das nicht möglich, sei es aus dem einfachen Grund, weil keine Anschlüsse für Tastatur und Bildschirm vorhanden sind, oder weil zu wenig Arbeitsspeicher und Rechenleistung vorhanden ist, um in akzeptabler Zeit einen Compiliervorgang durchzuführen.

Deshalb wird Mikrocontroller-Software auf dem PC entwickelt und der fertige Code auf die fremde Architektur des Controllers übertragen (Cross-Entwicklung). Dort muss er ablaufen und - funktioniert dann in der Regel nicht, wie jeder Code, den man zum ersten Mal zum Laufen zu bringen versucht.

Dann stellt sich die Frage: Wie analysiert man diese Fehler und wie kommen Fehlermeldungen auf den Entwicklungs-PC zurück? So einfach dieses Problem ist, es zeigt: Für die Cross-Entwicklung sind mehr Entwicklungsschritte und auch mehr Werkzeuge nötig als bei der Self-Hosted-Entwicklung.

Erschwerend kommt nun noch hinzu, dass in der Welt der Mikrocontroller ein buntes „Multi-Kulti“ herrscht und von einer Standardisierung wie bei x86-Prozessoren nicht die Rede sein kann. Zwar hat sich mit der ARM-Architektur ein gewisser De-facto-Standard herausgebildet, aber hier wirklich von Standard zu sprechen, wäre wohl übertrieben, denn erstens gibt es ARM in verschiedenen Generationen und Core-Varianten (ARM 7/9/11, Cortex-A, -R, -M) und zweitens liegt das Wesen des Mikrocontrollers ja darin, dass bei ihm die Peripherie auf dem Chip integriert ist.

Und so gleicht von den zigtausend Mikrocontrollern auf dem Markt keiner dem anderen. Eher angemessen ist es hier, von weiter verbreiteten und weniger weit verbreiteten Architekturen zu sprechen - denn proprietär ist bei Mikrocontrollern eigentlich alles.

Multitalent Tasking

Eine Tool-Kette, die dennoch alle Infineon-Architekturen unterstützt, ist die von Tasking/Altium. Ob die XC800-Serie mit ihrem 8051-Kern, die 16-bit-Familie XC2000/C166, ARM oder Tricore - für alle bietet Altium eine passende Version an. Für 8 und 16 bit, also XC800 und XC2000/166 hat Tasking eine eigene Entwicklungsumgebung, die sämtliche Teilwerkzeuge (Compiler, Assembler, Linker, Cross-Debugger) unter einer Oberfläche zusammenfasst.

Unter dem Namen „VX-Tools“ gibt es für XC2000/166, ARM und TriCore eine Version, die sich in das Eclipse-Framework mit CDT (C Development Tools) einfügt. Die Tasking-Tools können mit DAvE zusammenarbeiten und unterstützen z.B. auch eine Prüfung des Codes nach dem MISRA-C-Standard, was für Automobil-Projekte wichtig ist.

Keil: ein ganzes Ökosystem

Ebenfalls umfangreiche Unterstützung für Infineon-Architekturen - ausgenommen TriCore - bieten die Tools von Keil. Auch bei Keil gibt es verschiedene Versionen der Entwicklungswerkzeuge für 8, 16 und 32 bit. Als ARM-Tochter und deutsche Niederlassung von ARM bietet Keil folglich umfangreiche Unterstützung für diese Architektur.

Die Schnittstelle zum Anwender bildet bei den Keil-Tools die Entwicklungsumgebung µVision mit Projektmanager, Editor und Debugger. Die gesamte Tool-Kette von Keil heißt MDK (Mikrocontroller Development Kit) und umfasst noch wesentlich mehr als die Entwicklungsumgebung mitsamt Compiler, Assembler, Linker und Debugger (Bild 1).

So kann MDK-ARM mit DAvE3 generierte Projekte einlesen, enthält aber auch selbst Erweiterungen, die dem Ingenieur die Entwicklung nicht-differenzierender Produktmerkmale abnehmen: Dateisystem, USB-Host- und Device-Stack, TCP/IP-Netzwerk, CAN-Interface und eine Bibliothek für das Zeichnen von Benutzeroberflächen sind in der Vollversion enthalten. Mit RTX ist sogar ein schlankes Echtzeit-Betriebssystem dabei, das die Infrastruktur für Multitasking-Software bereitstellt und im Quellcode ausgeliefert wird.

Bei den 8- und 16-bit-Architekturen heißt die Tool- -Suite PK51 bzw. PK166 und das umgebende Software-Ökosystem fällt etwas schlanker aus, aber selbst für 8051 gibt es einen RTX-Kernel. Auch für den Austausch der Debug-Informationen ist gesorgt: Mit dem ULINK2 bietet Keil einen Debug-Adapter an, der an den USB-Anschluss des Entwicklungs-PCs angeschlossen wird und das Zielsystem per JTAG oder über die ARM-Modi Serial Wire Debug (SWD) oder Serial Wire Viewer (SWD) steuert. Gleichzeitig wird über dieses Gerät der Flash-Speicher des Zielsystems programmiert.

Weitergehende Funktionen bietet der Debug-Adapter ULINKpro, der auch einen Befehls-Trace aufzeichnen kann sowie Haltepunkte setzen und Speicherinhalte auslesen kann. Damit lässt sich der komplette Programm-ablauf analysieren.

IAR: universell, aber nur für zwei Infineon-Architekturen

Eine ebenfalls sehr universelle Entwicklungsumgebung ist die IAR Workbench, von der man sagt, sie eigne sich für die meisten Mikrocontroller. Im Fall von Infineon werden aber nur die Architekturen ARM und XC800 unterstützt. Die 8051-Version gibt es in verschiedenen Ausbaustufen, die sich z.B. durch maximal zulässige Codegröße, Unterstützung für Echtzeit-Betriebssysteme und die Anwesenheit des MISRA-C-Checkers unterscheiden. Bei der ARM-Version gibt es zahlreiche Verbindungen zu Partner-Tools wie Hardware-Debuggern oder zu Echtzeit-Betriebssystemen.

Außerdem bietet IAR auch Hardware-Entwicklungswerkzeuge an wie z.B. den JTAG-Debugger J-Link, der die Chip-internen Debug-Funktionen der XMC4000-Bausteine anspricht, oder I-Jet, ein Werkzeug, um Code und Leistungsaufnahme zu korrelieren. Damit kann eine Software so optimiert werden, dass der Controller möglichst wenig Strom aufnimmt bzw. es lassen sich diejenigen Stellen identifizieren, die für besonders hohe Stromaufnahme verantwortlich sind. Die Eclipse-Integra-tion von IAR ist noch relativ neu. Hier gibt es bisher nur ein Technology-Preview-Programm, mit dem C/C++-Compiler, Assembler, Linker und C-Spy-Debugger in Eclipse integriert werden können und dann die entsprechenden GNU-Tools ersetzen.

Wind River und HighTec: Spezialitäten für TriCore

Als singuläre Infineon-Architektur ist TriCore zweifellos exotischer als XMC4000 mit ihrem ARM-Cortex-M4-Kern. So ist für TriCore auch die Auswahl an Tools kleiner. Hier kommen die bereits erwähnten Tasking-VX-Tools (für Eclipse) in Frage oder der Diab-Compiler von Wind River. Diab war früher eine selbstständige Firma, die kurz nach der Jahrtausendwende von Wind River gekauft wurde.

Auch wenn man von Diab sonst nichts mehr hört - die Tools existieren weiterhin und der Diab-Compiler zeichnet sich durch den besonders speicheroptimierten Code aus, den er produziert. Er kann in Wind Rivers Entwicklungsumgebung Workbench eingebunden werden. Außer TriCore unterstützt der Diab-Compiler übrigens so gut wie alle anderen modernen 32-bit-Architekturen.

Eine andere Möglichkeit, Code für TriCore zu erzeugen, ist die TriCore-Entwicklungs- plattform von Hightec EDV-Systeme. Hightec bedient sich des Eclipse-Frameworks und nutzt einen GNU-basierten C/C++-Compiler. Die Entwicklungsplattform erzeugt nach Auswahl eines Mikrocontrollers selbstständig ein Code-Grundgerüst mit den nötigen Initialisierungen und einer Main-Schleife für den Start der Eigenentwicklung oder importiert ein DAvE-Projekt.

Der Compiler kann über Pragma-Anweisungen die verschiedenen Adressierungsmodi der TriCore-Controller nutzen, mit denen die optimale Verteilung von Code und Daten im Speicher und die Laufzeit-Optimierung gesteuert werden kann. Ferner kann der Compiler sich auf die Koexistenz eines AUTOSAR-Betriebssystems von ETAS, Elektrobit oder Vector einstellen.

Diese Betriebssysteme nutzen einige Register exklusiv, die der Compiler dann nicht mit Inhalten des Anwendungscodes belegen darf. Auch die Normen ISO 26262 und IEC 61508 für funktionale Sicherheit unterstützt der Compiler durch Zusammenarbeit mit dem SafeTcore-Paket von Hitex (s.u.). Zur Code-Analyse kann der Hightec-Compiler den Code instrumentieren und eine grafische Übersicht über die Code-Abdeckung erzeugen (Bild 2). Einen eigenen Hardware-Debugger bietet Hightec nicht an - hierfür gibt es wiederum Spezialanbieter.