DESIGN&ELEKTRONIK Tech-Talk
Komplexe MCUs beherrschbar machen
Fortsetzung des Artikels von Teil 2
Komplexe MCUs beherrschbar machen - Teil 3
Ein weiterer Diskussionspunkt war Open-Source-Software. Kann oder muss man mehr in Open Source machen, um die Interaktion mit dem Kunden zu verbessern? Könnte man z. B. auf diesem Wege zusammen mit Kunden Schnittstellen voranbringen, um diese dann in Form von APIs bereitzustellen?
ARMs Sicht ist, dass ein Anwender, der jeden Tag mit den bereitgestellten Tools programmieren muss, viel eher Verbesserungspotenzial sieht als der Ingenieur in seinem stillen Kämmerlein, der überlegt, was denn der Kunde gebrauchen könnte. Dies versucht ARM mit dem Community-Aspekt zu erreichen. Dort muss man als Produkthersteller mehr investieren, die Anwender helfen sich gerne gegenseitig, weil sie dieselben Probleme haben. Auch bei machen Herstellern wird der Open-Source-Ansatz gelebt und Anwender-Feedback auf die offenen verfügbaren Treiber in das nächste Release übernommen.
Als Vorzeigebeispiel wurde die herstellerunabhängige Linux-Community genannt, die auch im Industrie-Markt akzeptiert ist. Soweit ist der Embedded-Markt allerdings noch lange nicht. Derzeit fehlt es neben der generellen Akzeptanz vor allen Dingen daran, dass zu wenig Entwickler sich dort engagieren bzw. diese bedienen und benutzen. Solange es dort kein herstellerübergreifendes Vorgehen gibt, wird es wohl bei herstellerspezifischen Communities bleiben, die versuchen, Support so gut es geht für die eigenen Produkte anzubieten – so das ernüchternde Fazit.
Wenn es schon für Hersteller immer komplizierter wird, wie sollen erst Distributoren wie EBV oder Silica damit klarkommen, die zudem x LineCards haben, die von den FAEs unterstützt werden sollen? Wie kann Support überhaupt noch geleistet werden und bis zu welchem Niveau? Droht Herstellern mit zu komplexer Hardware die »Verstopfung« des Distributions-Kanals, weil die Produkte nicht mehr verkauft bzw. supportet werden können?
Einigkeit herrscht zwischen den Distributoren, dass konkrete Empfehlungen primär auf Basis von positiven Erfahrungen in Kundenprojekten ausgesprochen werden und es signifikante Unterschiede nicht nur in der Qualität der Tools, sondern auch in der Support-Organisation der Hersteller gibt. So gibt es Hersteller, bei denen im Fall eines Bugs vier Wochen »von Pontius bis Pilatus gelaufen wird«, ohne eine Antwort zu kriegen, aber auch solche, wo eine Support-Mannschaft beim Hersteller auch etwas von Software versteht und auch mal Code vom Kunden durchgehen kann.
Manches Manual umfasst tausende Seiten und erscheint lieblos geschrieben, was den Zeitaufwand für die Entwickler und FAEs weiter vergrößert. Die Hersteller sehen hier eine datenbankbasierte Dokumentation als Lösung, um eine konsistente Single-Source zu bekommen und die Sprache zu vereinheitlichen. Alleine, um das Triggern eines Interrupts zu beschreiben, gibt es heute mindestens fünf unterschiedliche Möglichkeiten, und jeder Entwickler beschreibt dasselbe Thema etwas anders. Man muss es sich auf der Zunge zergehen lassen: Bei EBV gibt es Kunden, die seit Jahren den gleichen Hersteller einsetzen, weil sie an die Beschreibungen in den Manuals und deren Struktur gewöhnt sind – nicht weil der Chip so toll designt wurde oder die Software so perfekt funktioniert.
Wo bleibt die Lösung bzw. wo steht die Embedded-Softwareentwicklung in drei bis fünf Jahren? Am Ende der Diskussion wurde deutlich, dass in der Branche Uneinigkeit vorherrscht, ob und in welcher Form Standardisierungen in der Entwicklung zu sehen sein werden.
In vielen Branchen wird laut EBV weiter auf Bitebene programmiert werden, es wird weitere Spezialisierungen nach Anwendung auf Hardware- und Software-Seite geben.
Modellbasierte Entwicklungen gibt es schon lange primär bei leistungsfähigen Applikationsprozessoren, ein Hineinwachsen der Methoden in den Embedded-Bereich liegt jedoch in der Sicht von STMicroelectronics noch in ferner Zukunft.
Standardisierung wird laut TI nicht das Allheilmittel sein können, um den wachsenden Kosten zu begegnen, eher applikationsspezifische Bibliotheken oder Codegeneratoren.
Auch Microchip erwartet in n drei bis fünf Jahren keinen Schwenk hin zu komponentenbasierter Entwicklung. Für das Thema IoT brauche man stattdessen sogar ganze Software-Module, die zusammen mit Hardware als Komplettlösungen angeboten werden.
Eine etwas andere Sicht vertritt Renesas: Hier sieht man in den nächsten drei bis fünf Jahren eine deutlich stärkere Nutzung von Software-Komponenten und einen Wandel bei den Kundenanforderungen.
Infineon erwartet ebenfalls standardisierte Komponenten im Bereich der Kommunikation und Schnittstellen, nicht jedoch im Bereich der Regelungstechnik mit harten Echtzeitanforderungen, wo man eher modellbasierte Entwicklungen a la Mathlab erwartet.
NXP glaubt, dass sowohl ein »Synergy 2«, d. h. einen herstellerspezifischen komponentenbasierten Ansatz, als auch ein Open-Source-Ansatz von ARM erfolgreich sein kann – beide müssten sich ja auch nicht zu stark unterscheiden. IoT findet in der Sicht von NXP jedenfalls nicht statt, wenn die Entwicklung nicht deutlich vereinfacht wird. Als eine Möglichkeit, Austauschbarkeit herzustellen, wird die Portierung der heutigen Linux-Welt auf MPUs auf die Mikrocontroller-Welt gesehen. Die Hersteller könnten entsprechende OS-Treiber bereitstellen, um die Hardware aus Anwendersicht zu abstrahieren.
ARM sieht einen klaren Zug zu komponentenbasierter Software-Entwicklung z. B. im Bereich Security (Verschlüsselung, Firmware-Updates, Kommunikation). Wenn einige wenige Anbieter damit anfangen, erwartet ARM, dass der Markt sehr schnell in diese Richtung gehen wird. Bezüglich der standardisierten Kommunikation im Rahmen des IoT ist standardisierte Software sogar die einzige denkbare Lösung, wobei es nicht viele Anbieter für solche Komponenten geben wird, da man sehr viel Geld in den Test wird investieren müssen.
Die Komponenten müssen allerdings kompilierbar bleiben, oft werden einfach die Source-Files in das Projekt reinkopiert und ein Jahr später wissen viele Entwickler nicht mehr, wo diese eigentlich herkommen. ARM hat mit der Lösung CMSIS-Pack einen Standard geschaffen, um genau dies zu verhindern und auch noch Jahre später zu wissen, wo die einzelnen Komponenten herkommen. Auf Basis von Eclipse gibt es auch eine Open-Source-Implementierung. Seitens der Halbleiterhersteller gibt es großes Interesse. Durch diesen Ansatz kann man Fremd-Software leichter integrieren; Voraussetzung ist natürlich immer, dass diese den Qualitätsstandards entspricht und die Schnittstellen passen. ARM prognostiziert, dass in der Embedded-Welt zunehmend Lösungen aus der Linux-Welt zu finden sein werden, mit einem RTOS als Grundvoraussetzung und standardisierten Treibern, um auf Ethernet, DMA oder SPI zuzugreifen. Das Dilemma der Skalierung (z. B. vom M0+ bis zum M7) kann natürlich nur gelöst werden, wenn Komponentenhersteller (Chip-Hersteller und SW-Drittanbieter von Dateisystemen etc.) mitmachen. Hier glaubt ARM auch an einen Bewusstseinswandel und sieht eine zunehmende Offenheit für Standards.
Silica sieht komponentenbasierte Entwicklung in einzelnen Bereichen wie dem IoT, wo nicht jeder Kunde im Detail die eigene Security-Bibliothek bauen kann, weil Zeit, Geld und Expertise fehlen. Umso wichtiger ist der Qualitätsaspekt, den man primär bei kommerziell erhältlichen Komponenten sieht – ein Beispiel ist Renesas Synergy mit Software-Datenblättern und garantierter Qualität. Insofern sei eine gewisse Skepsis gegenüber Open-Source-Projekten angesagt.
Jobangebote+ passend zum Thema
Mühsam nährt sich das Eichhörnchen
Nach zwei Stunden intensiver Diskussion mit MCU-Herstellern, Distributoren und ARM war nur eines klar: Nämlich, dass es kein klares Bild in der Branche gibt, wie die ausufernden Entwicklungsaufwände eingefangen werden können. Komponentenbasierte Entwicklung oder weiterhin Bare-Metal? Modellbasierte Ansätze, wie sie Mathlab schon lange bietet? Ansätze, wie man sie heute auf MPUs auf Linux-Basis kennt? Open-Source ja oder nein? Wie steht es da mit dem großen Thema Software-Qualität?
Viele offene Punkte und keine einheitliche Strategie in der Branche lassen zweifeln, ob in näherer Zukunft große Veränderungen zum Besseren zu erwarten sind. Zu ihrem eigenen Kosten-Dilemma haben allerdings auch die Kunden ihren Beitrag geleistet, nämlich dank der für mich absurden Erwartungshaltung, dass eine Tüte Kartoffelchips oder eine Flasche Bier mehr als ein Euro kosten dürfen, ein Stück High-Tech mit Millionen Transistoren als Herz von embedded Systemen, die ihrerseits für tausende Euros verkauft werden, angeblich aber nur 40 Cent wert sein sollen und man doch bitteschön auch noch die Software dazubekommen soll – kostenlos versteht sich. Jens Kahrweg hat es auf den Punkt gebracht: Dann bekommt man eben Software, wie sie ist. Wer nichts bezahlen will, hat nach meiner Überzeugung auch kein Anrecht auf wie auch immer zu definierende »Qualität«, sondern muss das nehmen, was man ihm gibt – inklusive Bugs und sich widersprechenden Pin-Belegungen und damit nicht integrierbaren Codebeispielen. Ob das angesichts des benötigten Supportaufwandes die Entwicklungskosten drückt, muss jeder Kunde für sich entscheiden.
Renesas geht mit Synergy einen anderen Ansatz: Man liefert den Kunden zwar auch proprietäre, aber geprüfte Software-Qualität, die er über einen höheren MCU-Preis bezahlen muss. Die Branche schaut gespannt darauf, ob sich die Japaner mit diesem Vorstoß durchsetzen können. ARMs Toolchain war noch nie kostenlos und liefert somit schon lange geprüfte Qualität und Support. Ihr Nachteil: Sie hilft den Herstellern nicht wirklich, sich zu differenzieren und vor allen Dingen nicht beim Thema Kundenbindung. Wer keine herstellerspezifische Spezial-Peripherie nutzt, kann heute mit den Keil-Tools NXP nutzen, morgen ST und übermorgen Microchip – eine grauenvolle Vorstellung aus Herstellersicht. Nach meiner Überzeugung wird die Branche trotz aller Differenzierungswünsche an einem Paradigmenwechsel hin zu komponentenbasierter Entwicklung auf Basis eines OS nicht vorbeikommen, spätestens wenn die Vernetzung im Rahmen des IoT ihre Kreise zieht. »Mal kurz« Bare-Metal auf Bit- und Registerebene eine eigene sichere Kommunikation aufbauen, wird die meisten Embedded-Anbieter überfordern, zudem kann man sich über einen Kommunikationsstack genauso wenig differenzieren wie über eine DSP-Multiplikation. Neue CPUs auf Basis der ARMv8-M-Architektur werden hilfreich sein, sichere Systeme zu bauen. Eine weitere Erleichterung dürften hybride SoCs mit Cortex-A- und M-CPUs sein, auf denen die Anwendung auf Linux und »nur« noch die sicherheitskritischen und/oder Echtzeit-Tasks auf der MCU laufen (und zertifiziert werden). Neue Toolchains von ARM und anderen Anbietern werden sich der Herausforderung Multicore-Debugging annehmen, bislang einem großen Hindernis beim Einsatz derartiger Chips.
Zu guter Letzt noch ein Wort zu mbed-OS: Mag ARMs IoT-OS für Hobbyisten und Bastler geeignet sein, so unbrauchbar ist es für einen Industriekunden. Wenn man seitens ARM eine Standardisierung vorantreiben will, gibt es zum CMSIS-Projekt keine Alternative. Mit CMSIS-Pack hat man einen Weg eingeschlagen, der – wenn die Hersteller und Drittanbieter mitmachen – derzeit wohl der erfolgsversprechendste ist, die träge Embedded-Branche auf einen neuen Weg zu führen.
Einig waren sich alle Teilnehmer über eine Sache: Bis ein Paradigmenwechsel weg vom »Ich programmiere jedes Bit selbst« in der Branche durchgängig angekommen sein wird, wird noch viel Wasser Elbe, Rhein und Isar hinunterfließen. Bis dahin wird es für Anwender mit jeder neuen MCU-Generation weiter heißen: Mehr Chip, mehr Seiten (Manual), mehr Entwickler, mehr Mann- und Frautage, mehr Euros.
- Komplexe MCUs beherrschbar machen
- Komplexe MCUs beherrschbar machen - Teil 2
- Komplexe MCUs beherrschbar machen - Teil 3
Lesen Sie mehr zum Thema
