Startseite > Halbleiter > Mikrocontroller > Komplexe MCUs beherrschbar machen

DESIGN&ELEKTRONIK Tech-Talk

Komplexe MCUs beherrschbar machen

17. Oktober 2016, 9:38 Uhr | Frank Riemenschneider

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Komplexe MCUs beherrschbar machen - Teil 2

An mbed wurde seitens der Hersteller kein gutes Haar gelassen: Der Open-Source-Ansatz hat bei vielen Kunden zu Skepsis geführt, Wissen weiterzugeben. Daneben habe der generelle High-Level-Ansatz auch Befürchtungen ausgelöst, dass die abstrahierte Software leicht nachgebaut werden könne. Dazu widerspreche die damit einhergehende Standardisierung einer Optimierung, weshalb sich mbed im Industrie-Bereich auch nicht durchsetzt; konkret gäbe es bis heute kein einziges Industrie-Projekt unter Einsatz von mbed. Ein weiterer Nachteil ist die mangelnde Skalierbarkeit, was die Kunden wieder zu den Entwicklungsumgebungen der einzelnen Hersteller bringe.

Sind die Entwicklungsumgebungen der Hersteller somit ein notwendiges Übel, an dem man quasi mangels Alternativen nicht vorbeikommt, oder gibt es auch Entwickler, die damit wunschlos glücklich sind?

Hier schieden sich die Geister. Nicht nur die Distributionsvertreter erklärten, dass sich die Hersteller-Tools in der Qualität der Die selbst als auch die der Treiber und Codebeispiele unterscheiden. Auch wenn fast überall der ICC-Compiler eingesetzt wird und die Möglichkeit besteht, kommerzielle Tools wie Keil oder IAR einzubinden, gibt es, was die Treiber angeht, unterschiedliche Ansätze. Renesas mit Synergy erklärt sich für das Gesamt-SW-Paket verantwortlich, andere Hersteller arbeiten mit unterschiedlichen Qualitätsniveaus innerhalb der angebotenen Software. Als Rechtfertigung wurde ein bemerkenswerter Satz in die Runde geworfen: Die Entwicklungsumgebungen seien ja auch kostenlos, und dann sei die Qualität eben so, wie sie ist. Daher gebe es viele Kunden, die erst mal auf der Hersteller-IDE etwas ausprobieren und dann auf Profi-Tools wechseln.

Nahezu jeder Hersteller wirbt mit hunderten Codebeispielen zum Download. Tra-gischerweise werden diese oft für Demo-Hardware entwickelt, Schnittstellen sind nicht sauber gedeckelt und erzeugen Hardware-Konflikte. Warum kann man nicht Beispiele erzeugen, die sich auch problemlos zusammencompilieren/linken lassen?

Tatsächlich wurden die Software-Bibliotheken der Hersteller in vielen Fällen zum Abenteuer erklärt. Wenn etwas ohne Probleme durchlaufe, sei dies eher die Ausnahme als die Regel. Bei den großen Herstellern wolle jede Division ihre Kompetenz einbringen und irgendwann muss alles zusammengeführt werden – und dann knirscht es. Auch die Revisionskontrolle sei nicht einfach für den Kunden. Nachdem es 15 Jahre bei Cypress nicht funktioniert habe, gäbe es jetzt aber auch ein Positivbeispiel: Für PSoC gibt es mittlerweile ein schlüssiges und funktionierendes Konzept.

Wenn man Cortex-M0+ bis M4, zumindest was das Speichersubsystem angeht, noch irgendwie programmieren kann, hat dieses mit Einführung des Cortex-M7 nochmals an Komplexität zugelegt: TCM, Caches, Flash und SRAM auf einem Chip überfordern offenbar sogar die Halbleiterhersteller selbst, für die es schwierig ist, ihre eigene Architektur effizient zu programmieren. Wie soll man das erst vom Entwickler erwarten?

Tatsächlich wurde bestätigt, dass spätestens bei Anbindung eines externen Speichers an einen M7-Controller die Sache sehr komplex wird und die Alarmglocken schrillen. Eine Alternative könnte der Wechsel auf die MPU-Schiene sein: Da eine M7-MCU im Preisbereich von 5 bis 10 Euro liegt und auf der anderen Seite Applikationsprozessoren mit Cortex-A5, -A7 oder A9 schon für 5 Dollar erhältlich sind, die seitens der Rechenleistung um Faktor 2 bis 4 höher liegen als der M7, könne dies eine sehr gute Alternative sein. Der Hardware-Entwicklungsaufwand sei nicht größer, wenn man einen externen Speicher verwende. ARM wurde dafür kritisiert, dass man im Gegensatz zu IAR bisher keine durchgängige Entwicklungsumgebung für Cortex-M und Cortex-A anbieten könne. Die Distribution kritisierte auch NXP dafür, dass man bei Cortex-A die Bare-Metal-Programmierer nicht abhole und immer gleich auf Linux setze. Dies mache Microchip mit den ehemaligen Atmel-Cortex-A-Prozessoren deutlich besser.

Wo Licht ist, gibt es auch Schatten: Ein Knackpunkt sei, dass es in der Cortex-A-Schiene nicht so viele Embedded-Entwicklungsansätze wie bei Cortex-M gibt, wo in der Regel mit einem RTOS gearbeitet wird. Für einen Entwickler, der aus der Mikrocontroller-Schiene käme, sei es fast unmöglich, einfach mal in den Bereich Linux oder Android zu wechseln. Daher täten sich auch Kunden schwer, die eigentlich ein Cortex-A-System einsetzen könnten, da eben nicht jeder Embedded-Entwickler ein Linux-Experte sei.

ARM sieht das natürlich anders: Mit dem MDK 5.2. wird der gleiche Ansatz wie in der MCU-Entwicklung bereitgestellt, sodass sich damit Cortex-A5-Derivate von Microchip oder i.MX-Prozessoren von NXP programmieren lassen. Man könne z. B. für sicherheits¬kritische Anwendungen Multi-Prozessor-Ansätze einsetzen, wo der sicherheitskritische Code klein gehalten werden kann und den nicht sicherheitsrelevanten Code auf einen anderen Prozessor auslagern kann, wo man dann nicht diese stringenten Tests durchführen muss und damit die Entwicklungskosten reduziert.