DESIGN&ELEKTRONIK Tech-Talk Komplexe MCUs beherrschbar machen

Mehr Funktionen auf dem Chip, intelligentere Peripherie und mehr Rechenleistung kennzeichnen den Mikrocontroller-Markt. Dies führt oft zu Verzögerungen und ausufernden Budgets. Im DESIGN&ELEKTRONIK Tech-Talk diskutierten 9 technische Industrie-Experten, wie man der MCU-Komplexität Herr werden kann.

Nachdem sich die Cortex-M-CPUs von ARM als Defacto-Standard herauskristallisiert haben, wollen Halbleiterhersteller sich nicht nur über Hardware (Peripherie, Schaltmatrizen. Speicherarchitekturen etc.), sondern auch über Software differenzieren und »kochen gerne ihr eigenes Süppchen«, letztendlich um trotz des ARM-Standards Austauschbarkeit zu verhindern. Leidtragende sind die Entwickler.

Bestätigt wurde, dass die Hersteller außer der Peripherie kaum mehr dediziertes Know-how in die Hardware einbringen können und aus der Historie heraus dieses Wissen nicht aufgeben wollen. Der größte Knackpunkt für einen Wechsel von Hersteller A zu B liegt in den Spezial-Peripherien, wofür primär die Kundennachfrage verantwortlich sei. Eine SPI wird in 50 % der Anwendungen eben nicht im Standard-Bereich betrieben und die IP so entwickelt, dass sie diese 50 % komplizierten Fälle abdecken kann. Der Leidtragende ist derjenige, der den Standard braucht. Eine SPI kann so z. B. über harte Timing-Anforderungen nie zum Standard werden, wo man dann statt zwei gleich 15 Kontrollregister hat.

Interessant ist die Sicht, dass rund 80 % der Distributionskunden nur einen Core, eine SPI- und eine I2C-Schnittstelle, nicht aber die Spezial-Peripherien der einzelnen Hersteller brauchen.

Als »Bindungsfaktoren« würden daher komplette IDEs und Treiberbibliotheken angeboten, und wenn einmal ein Kunde diese Pakete von einem Hersteller einsetzt, wäre der Aufwand zum Wechsel in eine andere SW-Umgebung eben entsprechend hoch.

Ein bereits heute gebräuchlicher Ansatz zur Komplexitätsreduktion sind Peripheral-Bibiotheken, welche Register abstrahieren. Vorausgesetzt wird jedoch z. B. ein Initialisierungsblock, dessen Parameter größtenteils im RAM abgelegt werden müssen. Der Overhead ist vielen Entwicklern zu groß, sodass sie wieder von vorne anfangen ohne Nutzung der Bibliothek. Die Frage ist jedoch, welchen Sinn macht ein solcher Ansatz, wenn man über das Ziel hinausschießt, weil die Entwickler den Overhead nicht akzeptieren?Hier herrschte die Herstellermeinung vor, dass dies insofern nicht so problematisch sei, weil 80 % der Kunden in Stückzahlen agieren, wo man dann doch bereit sei, den Overhead zu akzeptieren und z. B. eine Speichergröße mehr kaufen. Die 20 % der Kunden, die schon auf Grund hoher Stückzahlen den Overhead nicht akzeptieren, hätten dann in der Regel auch die Ressourcen, ihre eigene Software zu stricken. Auch in der Distribution ist eine zu große Abstraktion nicht akzeptabel, sei es aus Laufzeitgründen, sei es aus Kostengründen (Speichergröße). Kritisiert wurde in diesem Zusammenhang ARMs CMSIS-Initiative, da CMSIS von den großen Herstellern nicht hinreichend in deren Tools integriert würde. CMSIS sei heute vielmehr ein notwendiges Übel, das niemanden befriedige.

Reinhard Keil erklärte für ARM, dass nahezu jeder Hersteller die Komponenten CMSIS-Core in seinen Software-Stack integriert habe. Gleiches gelte für die DSP-Bibliothek. Er stimmte jedoch zu, dass es bei den CMSIS-Treibern Akzeptanzprobleme gab, u. a. weil ARM mit mbed-OS im eigenen Hause einen zweiten unterschiedlichen Ansatz verfolgte. Dort sei aber nunmehr eine Vereinheitlichung in Sicht. Auch der neue Ansatz weg vom Polling zum Transaction-getriebenen Konzept sei sehr wohlwollend aufgenommen worden, zudem habe man jetzt die Embedded-Community eingebunden, die aber zugegebenermaßen etwas träge sei, eingetretene Pfade zu verlassen.

Haben also die Embedded-Entwickler auch ein Stück selbst Schuld an ihrem Dilemma, weil sie immer alles im Detail verstehen wollen über die Spezial-Periphals hinaus? Würde es nicht reichen, z. B. für eine IP-Kommunikation zu wissen: Da ist ein TCP/IP-Socket, der sich mit dem Netzwerk verbindet, egal über welches Medium? Warum muss immer alles selbst bis ins letzte Bit programmiert werden?

Die Antwort hierzu lautete »Ja«. Gerade im sicherheitsrelevanten Embedded-Bereich würden Entwickler heute eher zu wenig als zu viel Details verstehen – es kam die Frage auf, wer denn mit einem Autobremssystem fahren möchte, wo die Software mit einer IDE aus Codebeispielen »zusammengeklickt« worden sei?

Auch im Bereich Motor-Control gibt es kaum Kunden, die einen Black-Box-Ansatz wünschen, obwohl es ja Ansätze mit höheren Abstraktionsebenen (»Motor an und dreh‘ Dich«) und z. T. selbstlernenden Verfahren gibt. Es geht dabei nicht nur darum, dass der Kunde selbst optimieren will, oft fehlt es schlichtweg am Vertrauen, weil von diesen Kernfunktionen die Qualität seines Gerätes abhängt. Ein Zertifizierungsprozess mit Open-Source-Treibern ist für die meisten Hersteller undenkbar.

Während einige Hersteller TI-Motor-Control-Lösungen wie InstaSPIN haben, die dem Kunden idealerweise das Schreiben jedes Codes ersparen sollen, sehen andere Hersteller wie Infineon diesen Ansatz skeptisch: Man habe zwar auch Apps, mit denen man per Mausklicks in fünf Minuten einen Motor zum Drehen bringen könnte, aber in dem Moment, wo ein Kunde eine spezielle Funktionalität brauche, müsse man wieder ganz tief ins Manual eintauchen. Motor-Control-Tools seien, auch wenn sie einen schönen Einstieg ermöglichen, nicht der Weisheit letzter Schluss, wenn es darum geht, Produkte in Serie zu bringen.

Ein weiterer Knackpunkt: Der Kunde selbst hat oft selbst viel mehr Know-how hat als der Chip-Hersteller oder ein externer Lieferant, über das er sich am Markt differenziert. Wie soll dies mit vorgefertigten Lösungen der Hersteller funktionieren?

Einigkeit herrschte darüber, dass es aus Anwendersicht sicherlich wünschenswert wäre, wenn CMSIS eine »höhere Ebene« erreichen würde, d. h., bestimmte Treiber voraussetzen könnte. Beispiel: UART, egal ob es sich um einen IP-Block aus dem Jahr 2000 oder einen high-sophisticated Kommunikationsbaustein handelt. Heute ist das nicht der Fall; die Frage ist, warum nicht?

Offensichtlich ist der Markt bis heute immer noch nicht bereit, diese komplexeren Software-Strukturen anzunehmen. Allerdings würde die Offenheit zunehmen, sich anders zu orientieren., wenn man entsprechende Vorteile aufzeigt, Hier müssen die Hersteller entsprechende Aufklärungsarbeit leisten, egal ob CMSIS von ARM oder proprietäre Lösungen wie Synergy von Renesas.

Wie schon erwähnt, gibt es im Hause ARM ja »nebenbei« noch das alte, nicht-event-getriebene mbed-Treiberkonzept, das im Kontext von IoT z. B. um Security-Funktionalität erweitert wird. Wäre es nicht hilfreicher, diese Anforderungen z. B. hinsichtlich Security in CMSIS zu implementieren? Wie soll ein Anwender mit unterschiedlichen Konzepten klarkommen?

Die Teilnehmer beim DESIGN&ELEKTRONIK Tech-Talk:

FirmaTeilnehmerRolle
NXPPia HueschManager Customer Application Support 
Atmel/MicrochipJens KahrwegDirector Field Applications EMEA
SilicaKlaus StephanSenior Field Application Engineer
EBVFritz Kurt Field Application Engineer
InfineonAndreas JansenPrincipal Engineer
ST MicroelectronicsCarsten SbickPrincipal Engineer 
ARMReinhard KeilGeschäftsführer ARM Deutschland GmbH
RenesasAndreas ErlebachSenior Engineer
TITobias LeisgangSystems Engineering Manager