DESIGN&ELEKTRONIK TechTalk
MCUs werden immer komplexer, was tun?
Fortsetzung des Artikels von Teil 1
Das sagte Reinhard Keil von ARM
Herr Keil, immer noch wird auf immer komplexeren Mikrocontrol-lern viel Bare Metal programmiert, während auf Cortex-A und Linux als Grundlage das Leben doch deutlich einfacher ist. Was sind die Gründe?
Für Bare-Metal sprechen Kostengründe, ein deterministischer Ansatz oder Sicherheitsaspekte, zum Beispiel wenn man das Risiko eines OS mit Security-Leak ausschließen möchte. Auch potentielle Timing-Probleme oder Ressourcen-Probleme im Kontext eines OS-Einsatzes können ein Grund sein.
Wenn das Thema Kosten sind, verstehe ich das bei Cortex-M3 oder M4. Für den Preis eines Cortex-M7 bekommen Sie ja aber auch schon Cortex-A….
Neben mangelnden Erfahrungen eines MCU-Entwicklers mit Cortex-A ist sicherlich die Interrupt-Antwortzeit ein Argument für den Cortex-M7 genauso wie der externe Speicher, den Sie bei Cortex-A benötigen. Leider können Sie kein Single-Chip-System auf Cortex-A bauen, was sich auch drastisch auf die Anzahl der Pins auswirkt. Das sind riesige Kostentreiber. Spannend sind natürlich Hybrid-Chips wie i.MX mit Cortex-A und Cortex-M, wo das Linux nur auf Demand gestartet wird und das System trotzdem immer »on« sein kann.
Ein Hybrid-Chip macht das Debuggen ja auch nicht einfacher….
Daran arbeiten wir seit zwei Jahren und das Debuggen ist heute nicht mehr das Problem. Aber wir erkennen, dass ein gesamtes System tatsächlich für einen einzelnen Entwickler nicht einfach umzusetzen ist. Wir entwickeln gerade ein Tool für die Resourcenkonfiguration von Multiprozessorsystemen, dann wird es etwas einfacher werden. Größere Firmen mit entsprechenden Software-Abteilungen haben in der Regel Hilfen, um diese Komplexität heute schon zu beherrschen. Das sind aber meistens In-House-Lösungen, die nicht öffentlich nicht verfügbar sind.
Also bleibt es bei vielen Anwendungen bei Cortex-M. Wie kann man den Leuten helfen?
Lösungen wie DAVE von Infineon oder CubeMX von ST Microelectronics können da schon helfen. Nehmen Sie mal Infineons Motor-Control-Software, da geben Sie die Parameter für Ihren Motor ein und bekommen für diesen Motor generierte Software. Wenn Sie natürlich technisch weiter runtergehen müssen, dann sind Sie bei tausendseitigen Handbüchern, da kommen Sie nicht drum herum. Jeder hätte es gerne einfach. Es gibt Grund für Komplexität, nämlich um die unterschiedlichsten Anwendungsbereiche abzudecken inkl. der Spezial-Fälle. In der Masse reichen Software-Komponenten und auf dieser Ebene wird sich viel abspielen in der Zukunft. Nehmen Sie Bluetooth-Radio, der Stack kommt meist vom Halbleiter-Hersteller.
Es gibt ja unendliche Code-Bibliotheken, Codebeispiele »sind wie sie sind«. Ist das eine gute Idee mit Code zu arbeiten den man nicht kennt?
Was freie Software angeht, stimme ich Ihnen zu. Es gibt Perlen, aber in vielen Fällen kann die Nutzung tatsächlich gefährlich sein etwa durch eine halbherzige Integration in ein komplexes Gesamtsystem. Es gibt aber auch von den Halbleiter-Herstellern robuste SW-Pakete wie etwa zertifizierte Wireless-Kommunikationsstacks, die oftmals in die Chips eingepreist sind. Problematisch wird es auch, wenn eine Software-Komponente nicht genau auf den Use-Case passt und Veränderungen am Source-Code vorgenommen werden ohne die Funktion genau zu verstehen.
Ich habe mal versucht, zwei Codebeispiele von einem großen Halbleiterhersteller zusammen zu kompilieren mit dem Ergebnis, dass ich einen Zugriffskonflikt auf einem I/O-Pin hatte. Die Antwort war, dass die Beispiele in zwei unterschiedlichen Abteilungen erstellt wurden, die voneinander nichts wussten…
Das ist leider tatsächlich häufig, denn gerade bei der Pin und Clock-Konfiguration gibt es Herausforderungen. Im I/O-Treiberbereich ist noch die meiste Arbeit zu tun, weil dort ein gewisser Wildwuchs herrscht und einheitliche Konzepte fehlen. Bei komplexerer Software wie einem TCP/IP-Stack haben Sie eine Schnittstelle zur Anwendung und zum Ethernet. Da ist alles ziemlich klar definiert. Wenn Sie aber den Ethernet I/O-Treiber sehen, ist das I/O-Konfigurations-Problem da. Bei CubeMX beispielsweise haben Sie zum Beispiel Tools für das Pin-Out, die Konfiguration wird dann von den Treibern aufgenommen, da ist es deutlich einfacher. Es gibt aber immer noch viel zu tun.
Ist es unter diesen Rahmenbedingungen überhaupt noch denkbar, zum Beispiel Software für eine Industriesteuerung ganz alleine zu entwickeln?
Aus meiner Sicht sind die Zeiten vorbei, Sie werden ohne Einsatz von Fremdsoftware nicht mehr auskommen. Bei einfachen »Kaffeemaschinen« geht es heute vielleicht noch, aber in der Zukunft wird auch diese kommunizieren und dann brauchen Sie einen Kommunikationsstack.
Ein anderes Thema ist Security – welcher Mittelständler beherrscht heute End-to-End-Security?
Das ist sicher verbesserungswürdig, wir haben mit mbed TLS eine Software-Komponente, die bewusst Open-Source ist, auch wegen entsprechenden Exportregulierungen. Ein Verschlüsselungsblock auf der MCU macht zwar die Routinen schneller, aber reicht natürlich nur durch seine reine Existenz nicht aus.
Ist mbed Arms Ansatz, bei IoT-Anwendungen die Komplexität vom Anwender wegzuhalten?
Mbed ist ein Ansatz, die Kommunikation zu vereinfachen, aber viele Ansätze kommen auch von unseren Partnern. Der Fokus von mbed ändert sich auch gerade. Der erste Ansatz war ja, die Cloud-Konnektivität zu vereinfachen. Da haben wir den Time-to-Market verpasst, das gibt es heute in Form von Microsoft Azure, Amazon AWS, IBM Cloud. Dadurch ändert sich der Ansatz von mbed zum Beispielin Richtung Firmware-Update.
Ein weiterer Ansatz aus dem Hause Arm ist CMSIS. Die Akzeptanz war ja anfangs bei Ihren Lizenznehmern limitiert. Wie geht es da weiter?
Ein Vorwurf war ja immer, dass Sie mit CMSIS-Treibern nur die minimalistische Schnittmenge der unterstützen Controller abdecken können, so bei einer SPI. Dies ist aber ein Irrtum. Zum einen können Sie Treiber mit oder ohne DMA konfigurieren um die Transferraten bzw. Ressourcen zu optimieren. Zum anderen gibt es in den CMSIS-Treibern die Funktion »GetCapabilities«, die Sie aufrufen können und zum Beispiel maximal mögliche Taktraten oder einen Vier-Bit-Modus zurückmeldet. Eine Middleware, die diesen Treiber nutzt, kann dann die optimale Betriebsart wählen und so unterschiedliche Features der verschiedensten Chips nutzen.
Wird CMSIS denn mittlerweile von den Herstellern in der Breite in deren Tools unterstützt?
Da haben wir große Fortschritte gemacht. Viele Halbleiterhersteller liefert den Device Support als CMSIS-Pack und zunehmend auch mit Treibern. MCUXpresso von NXP liefert Software in einem dem CMSIS-Pack kompatiblen Format aus, Atmel hat schon vor drei Jahren angefangen, leider mit modifizierten Flash-Algorithmen, so dass wir das Software Pack nicht 1:1 benutzen konnten. Dieser Fehler ist aber mittlerweile korrigiert.
Und wo können Sie bei Atmel oder jetzt korrekterweise Microchip CMSIS-Pack einsetzen?
Sie können beispielsweise die Packs von Atmel im Atmel Studio, bei uns im MDK, bei IAR und Atollic einsetzen. Wir haben ebenfalls eine Open-Source-Komponente CMSIS-Pack-Eclipse, die von Atollic und IAR verwendet wird. Da passen ein paar Feinheiten noch nicht, aber an den Problemen wird gearbeitet und die werden gelöst. Auf unserer Website können Sie feststellen, dass die Zahl der Packs massiv gestiegen ist: Beispiel Analog Devices.
Die großen Halbleiterhersteller tun sich mit der Unterstützung aber immer noch etwas schwer, habe ich den Eindruck….
Diese werden folgen. Davon bin ich zu 100 Prozent überzeugt.
Letztendlich haben Sie sich ja bei CMSIS auf die Kommunikations-Peripherie fokussiert und zum Beispiel A/D-Wandler außen vor gelassen, hat das die Akzeptanz auf Kosten der Vereinfachung erhöht?
Ja sicher, ich kenne den Kommentar, mit CMSIS gehen wir zu weit. Jetzt höre ich aber, es ist akzeptabel. Bei einem A/D-Wandler steckt doch in der Regel schon sehr viel Know-how drin, was auch Chip A von Chip B differenziert. Da täten wir uns mit einer Standardisierung schwer. Bei der Kommunikationsperipherie werden zudem Datenblöcke übertragen, während ein A/D-Wandler ständig von der Software bedient werden muss. Wenn Sie zu viele Schichten dazwischen haben, leidet natürlich die Performance.
Viele Software-Komponenten werden unter Open-Source-Lizenz im Source-Code geliefert. Sind sie also mehr Ideenlieferant als tatsächliche Lösung?
Nehmen Sie unsere CMSIS-DSP-Bibliothek. Wir wissen, dass es Anwendungen gibt, die damit nicht realisierbar sind. An unserer Implementierung kann sich ein Software-Ingenieur Inspirationen holen und dann den Code erweitern oder neu entwickeln mit Domain-Expertise. Wenn Sie aber einen einfachen Filter brauchen, reichen unsere Funktionen vollkommen aus. Gleiches gilt für das zuvor erwähnte Motor-Control mit DAVE von Infineon. Wenn Sie seit 20 Jahren Kernkompetenz in Motor-Control haben, entwickeln Sie vermutlich Ihren eigenen High-Sophisticated-Algorithmus.
Es heißt immer, Standardisierung widerspricht Optimierung. Sie setzten zweifellos auf Standardisierung. Sind Sie der Feind der Optimierung?
Ganz entschieden Nein! Wenn Sie eine standardisierte Schnittstelle haben, haben Sie den Vorteil, dass Sie die darunter liegende Technologie optimieren können, so dass es für den Anwender transparent bleibt und er die nächste Generation dieser Technologie benutzen kann. Und das ohne an der Software die die Schnittstelle nutzt etwas ändern zu müssen.
Ein FAE eines Distributors erklärte mir, dass »Software-Bibliotheken von Herstellern in vielen Fällen ein Abenteuer« darstellen. Was sagen Sie denn dazu?
Da widerspreche ich sicherlich nicht, es gab da eine umfangreiche Lernphase. Allerdings sollten Sie diese Erfahrungen nicht zwangsläufig in die Zukunft projizieren.
Ein anderer Ansatz ist ja Open-Source-Code. Ist das für Hersteller eine reale Option, auf Open-Source-Treiber zu setzen?
Open-Source ist nicht gleich Open-Source. Wir verwenden das, um den Anwendern Freiheiten zu geben, um zum Bespiel zu verhindern, dass unsere Lizenz inkompatibel zu anderen Lizenzen ist, die in einem System drin stecken. Man kann deswegen nicht pauschal sagen, dass Open-Source Software nicht hochwertig wäre. Vielfach wird Open-Source genutzt, um eine Idee zu forcieren und schneller am Markt zu sein, siehe die Exportbeschränkungen für mbed TLS. Oder nehmen Sie den Konnektor für eine Cloud, der auch Open-Source ist. Wenn unsere Open-Source Komponente, die dort integriert ist, ein kommerzielles Produkt wäre, würden wir den Cloud Service einschränken, den die Cloud Konnektor Software könnte nicht mehr frei verteilen werden.
Wie beurteilen Sie Werkzeuge wie MathLab? Wachsen die quantitativ?
Absolut, zum Beispiel im Bereich der ToolBox für komplexe Regelalgorithmen, die erstmal am PC modelliert werden können.
MathLab ist trotzdem nicht einfach einzusetzen. Die Frage ist, ob MathWorks etwas vorhat, die Lösung einfacher, kostengünstiger und einsteigerfreundlicher zu machen. Unsere Zusammenarbeit ist aber gut, und so ist beispielsweise die Anbindung von MathWorks zu unserer CMSIS-DSP-Bibliothek heute viel besser als noch vor einigen Jahren.
Jobangebote+ passend zum Thema
Dipl.-Ing. (FH) Reinhard Keil
studierte von 1980 bis 1985 Elektrotechnik an der Hochschule München, bevor er 1985 die Keil Elektronik GmbH und in den USA die Keil Software Inc. gründete. Er entwickelte in der Folge selbst Produkte wie Keil C51, Keil C166 und µVision. Seit seiner Markteinführung im Jahr 1988 war der Keil C51 der führende ANSI-C-Compiler für die 8051-MCU-Familie und auch heute ist dieser immer noch der De-facto-Standard für 8051-Softwareentwicklung.
Am 27. Oktober 2005 hat Keil seine Firmen im Kontext der zunehmenden Popularität von 32-bit-Mikrocontrollern an ARM Ltd. verkauft, seitdem ist er als Direktor für MCU-Tools für die Strategie der ARM-Mikrocontroller und der Weiterentwicklung der Programmierwerkzeuge verantwortlich.
- MCUs werden immer komplexer, was tun?
- Das sagte Reinhard Keil von ARM
- Das sagte Thomas Bauch von PLS
- Das sagte Stephan Lauterbach von Lauterbach
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
