Embedded-Entwicklung Software-Ökosystem mittels Frameworks erweitern

Anbieter zum Thema

OutSystems

Ein modernes Embedded-System muss schon bei der Entwicklung nicht nur auf dem aktuellsten Stand der Technik stehen, sondern sich angesichts der schnellen Marktentwicklung auch leicht aufrüsten lassen.

Heute stehen Embedded-Entwickler vor ganz anderen Herausforderungen als noch vor fünf oder zehn Jahren. Eine moderne Benutzerschnittstelle besteht oft aus einem Touchscreen mit Farb-Display. Connectivity nutzt eine oder mehrere Varianten an Wireless-Verbindungen: WiFi, Blue- tooth Smart oder Bluetooth Low Energy, oder gar eine mobile 4G-Option. Anwender erwarten, dass Firmware-Updates auf Knopfdruck installiert werden. Security ist besonders wichtig, obwohl die Details, wie diese tatsächlich umgesetzt wird, für die meisten immer noch ziemlich unklar bleiben.

Hinzu kommt die Schnelllebigkeit des globalen Marktes von heute. Die technischen Herausforderungen sind extrem, nicht nur in Bezug auf die Anzahl und Komplexität der Technologien selbst, sondern auch im Hinblick auf die Kosten der benötigten Infrastruktur. Die Zeit und Ausbildung zum Erlernen der erforderlichen Technologien, Werkzeuge und Geräte für die Entwicklung und den Test der Prototypen sowie Zertifizierungen kostet Geld.

Das dringendste Problem aber ist die Markteinführungszeit. Selbst wenn alle technologischen Probleme gelöst sind, Entwickler aber das Marktfenster verpassen und mit dem Produkt als zweites oder drittes auf den Markt kommen, landet selbst ein revolutionäres Produkt nur noch in den hinteren Regalen, als nur noch eine weitere Option in einem bereits gesättigten Markt.

Die Entwicklung muss also mit einer soliden, einfach zugänglichen Plattform beginnen, die aus der richtigen Kombination von Soft- und Hardware sowie Werkzeugen besteht und ein unterstützendes Ecosystem bietet. Auf dem Markt gibt es etliche Plattformen, die die nötigen Komponenten zum Aufbau eines komplexen Embedded Systems bieten. Nur wie wählt man die beste aus?

Elemente einer Embedded-Entwicklungsplattform

Eine vollständig integrierte Plattform besteht aus mehr als nur einer Serie von Mikrocontrollern und einem einfachen Softwarepaket. Eine solide Embedded-Entwicklungsplattform besitzt verschiedene Komponenten, wobei jede einzelne Komponente auf die anderen abgestimmt ist.

• Mikrocontroller: Registersätze und Peripheriezuordnungen müssen miteinander kompatibel und skalierbar sein, um Software-Portabilität nicht nur zwischen bestehenden, sondern auch für künftige MCUs zu gewährleisten.

• Integrierte Software: Eine Software-Plattform, die die wichtigsten erforderlichen Komponenten für gängige Embedded-Anwendungen umfasst und ein Hinzufügen spezieller Komponenten ermöglicht.

• Werkzeuge und Kits: Eine integrierte Entwicklungsumgebung (IDE), die nicht nur auf die MCUs, sondern auch auf die Software-Pakete abgestimmt ist.

• Komplette Lösungen: Demo-Designs von verschiedenen Technologien, die sich für einen schnellen Einstieg in die Produktentwicklung nutzen lassen.

• Online-Zugriff: Zugang nicht nur zu Software, Lösungen und Werkzeugen, sondern auch interaktiver Support, sodass Entwickler bei Bedarf Fragen stellen können, um unmittelbar Antworten zu erhalten.

Obwohl alle Aspekte wichtig sind, konzentriert sich dieser Artikel auf die integrierte Software. Dies ist meist der erste Bereich, der bei der Evaluierung einer Embedded-Entwicklungsplattform zu überprüfen ist.

Wichtige Fragen hinsichtlich Software-Kriterien

Bild 2 fasst die wichtigsten Fragen zusammen, die bei der Auswahl einer entsprechenden Plattform geprüft werden sollten. Jedes dieser Kriterien ist wichtig, um Zeit zu sparen und die Markteinführungszeit zu verkürzen.

• Vollständigkeit: Hier geht es darum, die Zeit zu verkürzen oder einzusparen, die zum Auffinden oder Erstellen benötigter Komponenten erforderlich ist.

• Integration und Qualifizierung: Hier geht es darum die Zeit zu verringern, um die nahtlose Zusammenarbeit der verschiedenen Komponenten der Applikation und eine schnelle Zertifizierung zu erreichen.

• Funktionsumfang und Konfiguration: Lässt sich die Plattform auf anwendungsspezifische Anforderungen anpassen?

• Erweiterungsmöglichkeiten: Kann man neue, speziell für eine Anwendung erforderliche Funktionen einfach integrieren?

• Lizenzierung: Wie lässt es sich vermeiden, ein voll funktionsfähiges Produkt entwickelt zu haben, das sich aufgrund von Lizenzbeschränkungen der Embedded-Firmware nicht verkaufen lässt?

Die Herausforderung eines solchen Softwarepakets besteht darin, dass eine Stärke in einem Bereich eine Schwäche auf einem anderen Gebiet verursachen kann. Integration und Flexibilität sind ein Paradebeispiel. Enge Integration ermöglicht oft einen kleineren Speicherplatzbedarf und Leistungsverbesserungen.

Wenn die Komponenten aber eng integriert sind, kann es extrem schwierig oder sogar unmöglich sein, den Code für anwendungsspezifische Anforderungen zu modifizieren. Dies gilt besonders dann, wenn die Modifikation aufgrund einer Hardware-Veränderung erforderlich wird. Oft kommen diese Änderungen erst spät in der Entwicklungsphase, was noch schlimmer ist. Der Prototyping-Prozess kann mit einer Komponente erfolgen, welche gegebenenfalls aufgrund von Anforderungsänderungen, Kostensenkungen, Vorlaufzeiten oder sogar Verfügbarkeit wegen Produktalterung ausgetauscht werden muss. Dies kann zu drastischen Veränderungen auf der Systemebene führen.

Die Änderung einer wichtigen Hardwarekomponente, zum Beispiel eines WiFi-Moduls, ist im Hinblick auf Zertifizierungstermine eine herausfordernde Aufgabe. Wie schützen sich Entwickler von Embedded-Software oder Projektmanager in dieser Situation vor Terminverschiebungen und Budgetüberschreitungen?

Schnelle Implementierung oder Austausch von Funktionen

Entscheidend für die Flexibilität ist die Auswahl einer Plattform, die Frameworks für Ecosystem-Technologien nutzt. Ein gängiger Zusatz ist heute WiFi, das einem System die Möglichkeit verleiht, sich mit der Außenwelt zu verbinden und mit ihr zu kommunizieren. WiFi-Module und Chipsets entwickeln sich aber schnell weiter.

Für ein Modul, das zu Beginn der Anwendungsentwicklung womöglich hochmodern war, gibt es zwischenzeitlich womöglich ein kostengünstigeres Pendant, oder es wurde sogar vollständig durch eine neue Technologie ersetzt. Ist die Treibersoftware für das Modul eng mit dem Anwendungscode verbunden, so lässt es sich eventuell nur schwer ersetzen, und falls doch, dann nur mit unzumutbar viel Zeitaufwand.

Wenn dieser Code auch noch mit der Plattform selbst verbunden ist, dann wäre ein Austausch sogar unmöglich. Hier kommen Software-Frameworks ins Spiel.

Ein Software-Framework definiert die Funktionsschnittstelle zwischen der Technologie und dem Rest der Plattform. Abbildung 3 zeigt die Architektur des WiFi-Frameworks im Renesas Synergy Softwarepaket (SSP). Es nutzt bewährte, integrierte Lösungen von Express Logic für die Kernfunktionen:

• ThreadX: Ein modernes Echtzeit-Betriebssystem mit aktuell mehr als 5,4 Milliarden Installationen.

• NetX und NetX Duo: TCP-IP Netzwerk-Stack mit Unterstützung für IPv4 und IPv6

• USBX: USB Host und Device Stacks mit einer breiten Auswahl an Client- und Funktions-Treibern.

• FileX: Ein professionelles FAT-Dateisystem.

• GUIX: Eine GUI-Lösung mit einem WYSIWYG Desktop-Designwerkzeug sowie einem Code-Generator.

Das WiFi-Framework nutzt diese und andere Komponenten des SSP. Das NSAL (Network Stack Abstraction Layer) bietet eine Schnittstelle zu den NetX oder NetX Duo Ethernet-Stacks, zusammen mit einer API für Konfigurierung und Bereitstellung. Ein Treiber für ein spezifisches WiFi-Modul muss einfach nur die Services bereitstellen, die für diese Layers benötigt werden. Der WiFi Modul-Treiber nutzt dagegen die vom SSP definierten HAL-(Hardware Abstraction Layer)- und BSP-(Board Support Package)-Dienste. Da diese beiden Schnittstellen stabil sind, lässt sich ein einziger Treiber ohne anwendungsspezifische Anpassungen über mehrere Anwendungen nutzen.

Da der Anwendungs-Layer nicht direkt mit dem WiFi-Modul verbunden ist, führt ein Austausch des WiFi-Moduls zu keinerlei Codeänderungen auf Applikationsebene. Existiert ein Treiber für das neue WiFi-Modul, lässt sich das Projekt sofort mit dem Synergy Konfigurationswerkzeug verändern. Dazu ist lediglich folgende Vorgehensweise erforderlich: die Projektkonfigurations-Datei im Konfigurationswerkzeug öffnen; den Reiter „Threads“ anwählen; den Thread suchen, der das WiFi-Modul nutzt; und den aktuellen WiFi-Modul-Treiber in der „Stacks“-Tabelle löschen. Anschließend fügt man das neue WiFi-Modul hinzu und konfiguriert es über das „Properties“-Fenster. Dann nur noch auf „Generate Project Content” klicken und das Projekt nutzt ab sofort das neue WiFi-Modul. Entwickler müssen weder den Anwendungscode durchsuchen und Artefakte des alten WiFi-Moduls finden und entfernen, noch damit kämpfen, die Unterschiede zwischen den Modulen zu kompensieren.

Dieser Beitrag ist ursprünglich auf unserem Schwesterportal Elektronikpraxis.de erschienen.

* Kim Dinsmore ist Senior Engineer MCU/MPU Solution Marketing und Synergy Software Marketing bei Renesas Electronics Europe.

(ID:44415892)