Computer on Modules Der Softwaresupport macht letztlich den Unterschied

Autor / Redakteur: Hubert Hafner * / Holger Heller

Diverse COM-Spezifikationen für ARM/SoC-Prozessoren, Module, Carrierboards und Entwicklungskits erleichtern den Entwicklungsstart. Neben dem Formfaktor ist auch der Softwaresupport entscheidend.

Firmen zum Thema

SMARC-Module von Kontron: ein grafikstarkes mit NVIDIA Tegra 3, eine breit skalierbare Reihe mit Freescales i.MX6 Single-, Dual- und Quad-Core-CPUs und ein Ultra-Low-Power-Modul mit TIs Sitara AM3874
SMARC-Module von Kontron: ein grafikstarkes mit NVIDIA Tegra 3, eine breit skalierbare Reihe mit Freescales i.MX6 Single-, Dual- und Quad-Core-CPUs und ein Ultra-Low-Power-Modul mit TIs Sitara AM3874
(Kontron)

Die neuen ARM-Prozessoren, die speziell für die neuen Generationen von Smartphones und Tablets entwickelt wurden, stoßen auch im Embedded-Markt auf eine große Nachfrage. Durch ihre dedizierte, aufgabenoptimierte Auslegung bieten sie eine kompakte Stellfläche und eine niedrige Energieaufnahme.

Allerdings stellt diese dedizierte Auslegung der ARM-SoCs auch eigene Anforderungen an die Applikationsentwicklung. Verschiedene Computer-on-Modules (COMs) von unterschiedlichen Herstellern sollen es dem Kunden ermöglichen, den Prozessor einfacher einzudesignen, als wenn sie ihr dediziertes Design komplett neu aufsetzen müssten.

Bildergalerie
Bildergalerie mit 6 Bildern

Zu unterscheiden sind dabei proprietäre Module von Modulen auf Basis offener Standards. Letztere sind zu bevorzugen, weil um sie herum ein Ökosystem mit einer deutlich höheren Langzeitverfügbarkeit sowie passender Wettbewerb entsteht. Unter den offenen Standards wiederum gibt auf der einen Seite solche, die aus der x86-Welt stammen und quasi umgewidmet wurden.

Auf der anderen Seite gibt es die neue Smart-Mobility-ARChitektur, kurz SMARC: Die erste reinrassige herstellerunabhängige Spezifikation der SGET. Hier ist letztlich der Standard mit klarem Fokus auf die spezifische Prozessortechnologie zu bevorzugen. Denn zu viele untereinander nicht kompatible Optionen verwässern die Durchsetzungskraft eines Standards. Sonderformen, Zwischenlösungen und Zwitterfunktionen sollten deshalb weitestgehend ausgeschlossen sein. Insofern kann die Wahl des Module-Standards durchaus schnell getroffen werden.

Doch nicht nur die Wahl des passenden Formfaktors ist entscheidend. Bei allen Modulen sowie den neuen SMARC-Modulen gibt es bei der Entscheidung zwischen den einzelnen Herstellern noch ein weiteres entscheidendes Kriterium: Den Softwaresupport. Und das hat seinen Grund.

Dedizierte Hardware verlangt dedizierte Software

Aufgrund der diversifizierten Auslegung der ARM-Prozessoren und der damit einhergehenden engen Verknüpfung von Hard- und Software lässt sich ein Standard-OS nicht auf jedwedem ARM-Prozessor integrieren. Meist sind Anpassungen notwendig. Ein Nvidia-Tegra-3-Prozessor basierend auf dem ARM Cortex-A9 verlangt beispielsweise schon einen anderen Softwaresupport als ein Nvidia Tegra 2. Und keine der dafür angepassten OS-Versionen läuft 1:1 auf einem Sitara von Texas Instruments oder Freescale i.MX6. Für jeden ARM-SoC muss vielmehr ein eigenes OS-Image individuell zusammengestellt werden.

Der Grund dafür liegt unter anderem in der individuellen Ausformung eines jeden SoCs, der neben dem General-Purpose-Prozessor weitere individuelle Funktionseinheiten integriert. Der OS-Support muss folglich dediziert auf die jeweiligen ARM-SoC zugeschnitten sein. Noch dedizierter wird es, wenn man ein eigenes Carrierboard mit applikationsspezifischen Interfaces entwickelt – was bei COMs üblich ist.

Anwender wollen auf der anderen Seite jedoch für den Neueinstieg wie auch den Umstieg auf neue oder andere ARM-SoCs einen ähnlichen Komfort, wie sie ihn von den standardisierten x86-COM-Express- und ETX-Modulen kennen. Hier können sie nämlich die Entwicklung direkt auf der Zielplattform starten und müssen sich um das Betriebssystem und die darunterliegenden Softwarefragen vergleichsweise weniger Sorgen machen. Deutlich mehr Aufmerksamkeit ist folglich bei ARM/SoC-Designs geboten. Worauf sollten Kunden, die Computer-on-Modules einsetzen wollen, deshalb achten?

Dedizierte Betriebssystem-Konfiguration

Zuerst einmal zählt für die softwareseitige Applikationsentwicklung natürlich der Betriebssystem-Support: Für ARM-basierte Low-Profile-Applikationen sind in erster Linie schlanke, auf den Bedarf kompilierbare Betriebssysteme mit einem kleinen Speicher-Footprint gefragt. Interessant sind hier vor allem Linux, das auf Linux basierende Android sowie Windows Embedded Compact 7 (ehemals Windows CE). Um die Stärken der ARM-Applikation voll zur Geltung zu bringen, sollten diese OS genau auf die Aufgabenstellung hin optimiert werden.

Dies ist zunächst einmal mit Implementierungsaufwand verbunden. Das Betriebssystem sollte nämlich ausschließlich die Bibliotheken und Funktionsblöcke beinhalten, die für die Applikation auch benötigt werden. Alles andere kann entfallen, um den Speicherbedarf möglichst gering zu halten und die Performance zu optimieren.

Viele OEMs werden deshalb dankbar sein, wenn sie diese Aufgabe an einen externen Dienstleister auslagern können. Schließlich müssen sich OEM verstärkt auf die eigenen Kernkompetenzen konzentrieren, um die Forderungen nach immer kürzeren Markteinführungszeiten erfüllen zu können. So ist die dedizierte OS-Konfiguration ein gutes Aufgabenfeld für den Hardwarelieferanten. Dafür gibt es mehrere Gründe, die im erforderlichen dedizierten Zuschnitt des OS und Bootloaders begründet liegen.

Dedizierte Betriebssystem-Anpassung nötig

Damit man nämlich überhaupt an den Punkt kommen kann, das Betriebssystem auf die dedizierten Applikationsanforderungen „einzudampfen“, muss es für die gewählte ARM-Plattform erst einmal lauffähig gemacht werden. Und hier sind bei Modulen auch immer das Carrierboard und seine dedizierten Interfaces von Bedeutung. In der generischen x86-Welt beispielsweise ist für nahezu jede Hardware ein passender Treiber bereits verfügbar und häufig auch schon im Betriebssystem integriert.

Bei der ARM-Technologie ist es jedoch nicht so, dass man die Treiber einfach herunterladen und dazu installieren kann. Je nach Betriebssystem kann es nämlich bis hin zu spezifischen Kernel-Konfigurationen reichen, um die individuellen Features ansprechen zu können. Dies ist zwar auch bei x86er Systemen je nach Lösung gefragt, ist aber eher die Ausnahme denn die Regel.

Modulspezifisches OS direkt vom Hersteller

Durch Standards wie die SMARC-Module, die für alle ARM-SoCs ein einheitliches standardisiertes Schnittstellenangebot über den Konnektor definieren, wird für OEMs jedoch zumindest sichergestellt, dass alle vom jeweiligen Modul ausgeführten I/Os unterstützt werden. Und genau in diesem Punkt unterscheiden sich offene Standards also signifikant von proprietären Modulfamilien.

Ein durchaus relevanter Unterschied. Denn ein Modul-Standard kann auch I/Os als Mindestanforderung unterstützen, die ein ARM-SoC von Haus aus nicht mitbringt. Beispiele hierfür sind bei SMARC-Modulen mit i.MX6-Freescale-Prozessor ein optionaler PCI Express Hub, um die PCI Express Lane des Prozessors auf drei zu erweitern oder der auf Nvidia-Tegra-3-SMARC-Modulen integrierte Gigabit Ethernet Controller.

Insofern sind auf einem Modul neben dem ARM-SoC auch weitere Komponenten enthalten, die ebenfalls Treibersupport benötigen. Man könnte also auch sagen, dass OEMs damit ein Module-BSP benötigen und nicht nur ein Prozessor-BSP. Darüber hinaus gilt es, in der eigentlichen Applikation aber auch noch weitere wichtige Peripheriekomponenten einzubinden: Hier ist der Support für verschiedene LVDS-Panels oder für verbreitete WiFi-Devices zu nennen. Einige dieser Komponenten müssen zudem auch schon im Bootloader verankert werden, der den Betriebssystem-Kernel lädt.

Neues Terrain: Bootloader statt BIOS

Damit kommt auch dem Bootloader bei ARM-basierten Designs ebenfalls eine entscheidende Rolle zu. Wo x86-Technologie auf ein BIOS setzt, erfolgt bei ARM-Prozessoren die Initialisierung einzelner Komponenten – wie beispielsweise RAM, (Flash-)Speichermedien und Displays sowie kundenspezifisches I/O – über einen Bootloader.

Das beschleunigt zwar den Bootvorgang, dürfte für viele OEMs aber unbekanntes Terrain sein – vor allem wenn man eigene Erweiterungen hinzufügen möchte. Die glänzende Seite der Medaille ist allerdings eine höhere Flexibilität und Anpassungsfreiheit – vorausgesetzt man kann mit dem Bootloader umgehen.

Softwareservices direkt vom Hersteller

Damit haben hardwarenahe Softwareservices unterhalb der eigentlichen Applikation deutlich höhere Bedeutung als bei x86-Designs. Deshalb ist es ideal, wenn Kunden diese Softwareservices als Building-Blocks direkt vom Hardwarehersteller beziehen können. So haben sie einen zentralen Ansprechpartner und müssen sich nicht mit unterschiedlichen Stellen koordinieren, was häufig zeitaufwändig ist und in der Praxis auch zu Missverständnissen führen kann.

In diesem Zuge sollten Kunden darauf achten, dass der Embedded-Hersteller den Softwaresupport seinerseits nicht auslagert, sondern selbst inhouse ausführt. Das ist deutlich effizienter, da die gesamte Expertise für das Module bzw. das Motherboard, OS und Treiber an einer Stelle konzentriert ist, was Synergieeffekte voll ausnutzt und damit höchste Effizienz und Qualität sicherstellt.

Firmen wie Kontron bieten den Softwaresupport größtenteils inhouse an. Das Unternehmen hat mehr als 1000 Entwicklungsingenieure weltweit. Mehr als zwei Drittel arbeiten davon in der Softwareentwicklung. Damit kann Kontron seine SMARC-Module als applikationsfertige Plattformen mit einem hohen Support-Level anbieten.

* Hubert Hafner ist Produkt Marketing Manager Computer-on-Modules bei Kontron.

(ID:37541330)