System-Software und Entwicklungs-Tools Zwischen Vielfalt und Standardisierung

Um die Architektur der ARM-Cores hat sich ein blühendes "Ecosystem" aus Chip-, Betriebssystem- und Tool-Herstellern entwickelt. In blühenden Landschaften gedeiht aber auch der Wildwuchs. ARM muss daher versuchen, das Gleichgewicht zu wahren. Und das, obwohl Reinhard Keil, Director of MCU Tools bei ARM, auch selbst im Geschäft für Tools und Betriebssysteme mitmischt.

Herr Keil, eine Schwierigkeit, mit der sämtliche Mikrocontroller-Architekturen zu kämpfen haben, ist der Aufwand bei der Portierung von Software. Könnte Android hier eine Vereinfachung bringen?

Reinhard Keil: Android ist eine Linux-Variante, die für Cortex-A-basierende Produkte verwendet wird. Die Gründung von Linaro hat zum Ziel, einheitliche Open-Source-Komponenten zu erstellen. Dabei haben sich ARM, Freescale, IBM, Samsung, ST-Ericsson und Texas Instruments mit dem Ziel zusammengeschlossen, die Entwicklung von Linux-basierenden Geräten zu vereinfachen.

Was tut ARM, um die Standardisierung von Software voranzutreiben?

Bei Cortex-M haben wir 2008 begonnen, den Cortex Microcontroller Software Interface Standard (CMSIS) zu etablieren. CMSIS wird heute von allen Halbleiter-Herstellern verwendet, um einen einheitlichen Peripherie-Basis-Layer für Mikrocontroller zu erstellen. Wir werden CMSIS zusammen mit der Tool- und Halbleiter-Industrie erweitern, um mehr standardisierte Funktionalität auch für Produkte anzubieten, die auf Cortex-M-Prozessoren basieren.

Wird es bei den vielen Chip-Varianten und Peripherie-Spezialitäten überhaupt jemals möglich sein, Standard-Software für ARM-Prozessoren zu schreiben?

Wir sind sicher, dass wir sowohl mit Linaro als auch mit CMSIS auf dem richtigen Weg sind. Software-Entwicklung wird für unsere Kunden damit zunehmend einfacher werden. Allerdings werden wir keinen einheitlichen ARM-Controller definieren, da wir sonst einen wichtigen Vorteil verlieren. Unsere Halbleiter-Partner sollen sich gerade in der Peripherie-Funktionalität unterscheiden und so das Einsatzgebiet der ARM-Prozessoren erweitern.

Die unterschiedliche Peripherie macht es zusammen mit weitreichenden Produkt-Anforderungen erforderlich, spezialisierte Software zu erstellen. Allerdings können jetzt einheitliche Software-Standards verwendet werden, die Einarbeitung und langfristige Software-Wartung minimieren.

Betrachten Sie die Vielfalt an Embedded-Betriebssystemen als eine Bereicherung für den Markt und die Kunden oder muss man hier eher von Wildwuchs sprechen, der Kunden verunsichert und einer Plattform-Standardisierung entgegensteht?

Von ARM-Seite sehen wir ein klares Partnerschaftsmodell, aber erlauben Sie mir folgenden persönlichen Kommentar: Vor allem bei Betriebssystemen für Mikrocontroller sehe ich eine Produkt-Vielfalt, die langfristig so nicht überleben wird. Ich vergleiche den MCU-Markt immer wieder mit dem "PC-Markt" vor 30 Jahren. Auch dort war vor Einführung von DOS - und später Windows - zunächst ein Wildwuchs bei Betriebsystemen zu beobachten. Heute ist ein einheitlicher Prozessor-Standard mit nur wenigen Betriebssystemen kennzeichnend für den PC-Markt. Langfristig werden sich auch für Cortex-M-Mikrocontroller Betriebssystem-Standards etablieren, so wie das heute schon mit Windows- und Linux-Varianten bei Cortex-A-Applikationsprozessoren der Fall ist.

So mancher Hardware-Hersteller (Intel, RIM) kauft sich sein eigenes Betriebssystem. Wäre das auch für ARM eine Idee?

Wie gesagt, wir setzen hier auf Partnerschaften. Unsere Lösungen sind Linaro und CMSIS, die wir kontinuierlich mit Partnern erweitern werden.

Im Open-Source-Bereich gibt es heute eine ganze Reihe kostenloser Tools, allen voran gcc und gdb. Und offenbar klappt die Arbeit mit diesen Werkzeugen ja auch ganz gut. Sind diese Werkzeuge eine Gefahr für kommerzielle Tool-Anbieter?

Die Halbleiter-Hersteller und deren Kunden fordern heute ein umfangreiches Angebot von Tools; dazu zählen auch kostenlose Open-Source-Lösungen. Damit wird gerade der Einstieg in die ARM-Architektur erleichtert, und letztlich vergrößert sich dadurch wieder der Markt für professionelle, kommerzielle Tools.

Beschränkt sich die Aufgabe kommerzieller Tool-Anbieter auf den Support und darauf, Tools mit höherem Bedienkomfort anzubieten?

Das sind sicherlich wesentliche Faktoren für den Erfolg von Tools. Es geht darum, die Produktivität zu erhöhen und das Entwicklungsrisiko zu minimieren. Wichtig sind aber auch eine klare und verständliche Dokumentation, ein leistungsfähiger Debugger mit Trace-Funktionalität, Service-Leistung zur Software-Zertifizierung und schnelle Reaktion auf Markt-Erfordernisse.