DESIGN&ELEKTRONIK TechTalk
MCUs werden immer komplexer, was tun?
Fortsetzung des Artikels von Teil 3
Das sagte Stephan Lauterbach von Lauterbach
Herr Lauterbach, auch an Sie die Frage: Wie kann die Halbleiter- und Tool-Industrie den Anwendern helfen, der immer komplexeren Hardware Herr zu werden?
Stefan Lauterbach: Der Anwender muss sich auf die oberen Schichten konzentrieren können, wo er sich mit seiner Anwendung wirklich differenzieren kann.
Es macht ja keinen Sinn, wenn er einen Bootloader programmiert, den zehntausend Andere auch schon entwickelt haben. Die Halbleiterhersteller liefern deshalb ja auch immer mehr Software-Komponenten dazu, mit Renesas Synergy als gutem Beispiel.
Synergy ist ein gutes Stichwort. Wie beurteilen Sie diesen Ansatz?
Sehen Sie, im Bereich der komplexen SoCs im Mobilfunkbereich, gegen die ein Cortex-M-Controller – wenn ich das so sagen darf – pillepalle ist, ist das ja schon lange üblich, dass der Halbleiterhersteller die Software liefert und der Kunde nur noch seine eigene Oberfläche darüberlegt.
Wichtig ist, dass alles funktioniert, wie und warum es funktioniert, ist einem Handyhersteller egal, warum sollte er jedes Bit selbst dreimal umdrehen wollen?
In die Richtung geht es mit Synergy nun auch bei den MCUs und es ist sicher ein Weg, komplexe Chips beherrschbar zu machen.
Gilt das umso mehr für Multicore-Architekturen?
Absolut. Wenn Sie außer Cortex-M3 beispielsweise noch DSP und Low-Power-Controller auf einem Chip haben, kann die ohnehin fast niemand mehr programmieren. Dann wird es für den Kunden uferlos.
Dann hat es Sinn, wenn der Halbleiterhersteller das DSP-Package macht, was für 99 % aller Kunden ausreicht.
» Aus der Historie gibt es sicher optimierbare Codebeispiele «
Auf der anderen Seite gibt es bei kostenloser Software, wie sie viele Halbleiterhersteller liefern, immer wiederdie Qualitätsfrage….
Ich kann mir vorstellen, dass sich das bald ändert. Aus der Historie gibt es sicher Code-Beispiele, die optimierbar sind, da haben Sie Recht. Klar ist auch, wenn es in Richtung Test, Zertifizierung und so weiter geht, muss man über Kosten nachdenken.
ichtig ist auch, dass der Code im Source vorliegt, damit man Bugs fixen, den Code weiterentwickeln und auch noch dann pflegen kann, wenn der Halbleiterhersteller zum Beispiel sagt, er habe daran kein Interesse mehr, weil er schon mit der nächsten Chip-Generation unterwegs ist. Eine Black-Box mit irgendeinem Binärcode ist sicher kritisch.
Ein FAE eines großen Distributors hat mir erzählt, Software-Bibliotheken von Chip-Herstellern seien oft ein Abenteuer. Dagegen klingt Ihre Prognose ja sehr optimistisch…
Was tatsächlich oft nicht funktioniert ist, wenn unterschiedliche Codes aus unterschiedlichen Abteilungen einfach mal zusammencompiliert werdenen. Ganz ohne eigenen Aufwand geht es dann doch nicht (lacht). Wie gesagt, vorliegende Sourcen sind ein Muss.
ARM hat bekanntlich CMSIS entwickelt, um die Entwicklung zu vereinfachen, wie beurteilen Sie diesen Ansatz und wie sehen Sie die Adaption im Markt?
Der Ansatz ist richtig, der Kunde kann nach einem Baukastenprinzip aussuchen, was er verwenden will und was nicht. Was die Marktakzeptanz angeht, habe ich keine Informationen.
» Ein SoC wie i.MX wird von einer Person nicht mehr verstanden «
Ihre Zielmärkte sind ja komplexe SoCs wie i.MX von NXP, wo man unzählige Cores, Schaltmatrizen und weitere IP-Blöcke wie GPUs, Image-Prozessoren, Hardware-Beschleuniger für Verschlüsselung et cetera findet und Unmengen an Daten hin und her geschaufelt werden. Wie kann man einen solchen Chip noch zielgerichtet debuggen?
» Das sind so unterschiedliche Welten, die kann man kaum noch überblicken «
Ein solches SoC wird von einer Person nicht mehr verstanden. Wie schon angedeutet, nutzen die Kunden mit Ausnahme des Anwendungsprozessors fast ausschließlich vorgefertigte Software-Packages, wobei sich mehrere Personen dann jeweils auf einen Bereich konzentrieren.
Der Datenaustausch der Subsysteme geschieht über geteilten Speicher, ansonsten kommen die sich kaum mehr in die Wege. Das sind so unterschiedliche Welten, die kann man in der Gesamtheit kaum noch überblicken.
Wenn man zum Beispiel feststellt, dass falsche Bilddaten ausgegeben werden, schaut man als erstes, ob diese schon falsch vom ISP in den Speicher geschrieben wurden. In diesem Fall »darf« der Kollege, der sich mit dem ISP auskennt, suchen, warum dieser die Daten falsch berechnet hat.
Ich stelle mir immer vor, ein ABS-System im Auto wird in einer IDE aus unterschiedlichen Software-Blöcken zusammengeklickt, wie soll ich da Vertrauen haben?
In der Lieferkette gibt es ja beliebig Software von Zuliefern, deren Zulieferer wieder Teile von anderen Zuliefern bekommen. Sie können dann eine Abteilung aufmachen, die sich mit den Sourcen beschäftigt, diese in Gänze pflegt und da im besten Fall durchsteigt.
Oft geht es auch nach Gefühl, sieht der Source vertrauenswürdig aus vom Stil oder habe ich das Gefühl, der Programmierer weiß nicht wirklich, was er tut?
» ARMv8-R sehe ich im Bereich Safety als Fortschritt an «
Wie schätzen Sie die neue ARMv8-R-Architektur denn ein, löst die mit Hardware-Virtualisierung wirklich alle Probleme?
Das ist schon hilfreich, bisher hatten sich die Halbleiterhersteller da ja immer etwas selbst zusammengebaut, etwa eigene Lock-Step- oder CRC-Lösungen, jetzt steckt das im Kern der Architektur drin. Ja, im Bereich Safety und auch Powertrain sehe ich das schon als Fortschritt an.
Die Embedded-Community scheint teilweise etwas zögerlich, neue Wege zu gehen. Sehen Sie da einen Grund für die ausufernden Software-Entwicklungskosten?
Neu muss nicht immer gleich besser sein, besonders bei sicherheitsrelevanten Anwendungen verstehe ich, wenn man dir bewährten Pfade und Methoden nur widerwillig verlässt.
Es ist eben ein Unterschied, ob Ihr iPhone alle halbe Stunde einmal abstürzt oder Sie gegen einen Baum fahren.
Die Software-Abstraktion hat heute ja oft ihre Grenzen, wenn es darum geht, spezifische Features eines Chips auszunutzen. Wie kann man sich dann überhaupt noch differenzieren?
CMSIS hat ja entsprechende Mechanismen, um auch Funktionen zu unterstützen, die über den Minimalkonsens hinausgehen. Andere Lösungen haben dies nicht, was im Einzelfall dann tatsächlich wieder zu Bare-Metal-Programmierung führt.
Bei ARM ist dies im eigenen Ecosystem aber nur noch bedingt ein Problem, da vieles auch außerhalb des Cores de facto durchstandardisiert wurde.
Warum tun sich so viele Embedded-Entwickler schwer, Linux auf Cortex-A-SoCs laufen zu lassen und sich damit das Leben zu vereinfachen?
» Es gibt Leute, die auf Cortex-A ein RTOS laufen lassen «
Overhead ist schon da, ebenso wie bei den Packages von den Herstellern. Da ist eben ein großes Softwarepaket, bei dem ich auch davon abhängig bin, dass dieses durch Dritte gepflegt wird und auch die nächste Version auf meiner Hardware läuft. Tut sie das nicht, stehe ich erstmal auf dem Schlauch.
Ist eine Sicherheitslücke drin, hänge ich davon ab, dass der Netzwerk-Stack vom Linux gefixt wird. Ich habe eben nur einen geringen Einfluss und keine Kontrolle über den Code.
Es gibt übrigens auch Leute, die auf Cortex-A ein kleines RTOS laufen lassen, wenn sie nur die Rechenleistung brauchen. Aber das ist eher selten der Fall.
Wäre nicht symmetrisches Multiprozessing mit Virtualisierung auch mal ein Ansatz, die Entwicklung zu vereinfachen?
Das wird ja schon seit Jahren diskutiert, aber ich sehe nicht den großen Durchbruch. Statt Applikationsprozessor plus DSP und noch ein Core für WLAN könnte ich ja auch vier symmetrische CPUs nehmen und virtualisieren, aber natürlich nicht so energieeffizient wie mit speziellen IP-Blöcken.
Dazu kommt, dass die Blöcke wie schon erwähnt weitestgehend unabhängig arbeiten, das heißt kommt in einem Corner-Case doch mal ein Fehler hoch, ist zumindest nicht das ganze System auf dem Chip betroffen.
Vermutlich spielt auch Geld eine Rolle?
Klar, so ein komplettes Redesign auf ein virtualisiertes SMP-System kostet Geld. Die Autoindustrie ist mehr oder weniger gezwungen, Funktionen zu konsolidieren, weil sie nicht mehr weiß, wo sie die ganzen Steuergeräte unterbringen soll.
Es gibt Halbleiterhersteller, deren modellbasierte Softwareentwicklungen noch in weiter Zukunft liegen. Warum ist das eigentlich so?
Mathlab gibt es ja schon lange, die Frage ist, warum das auf einmal jetzt explodieren sollte. Dafür müsste es ja Gründe dafür geben, und die sehe ich nicht.
Jobangebote+ passend zum Thema
Dipl.-Ing. Stephan Lauterbach
studierte Elektrotechnik an der technischen Universität München, bevor er 1982 in die von seinem Bruder Lothar im Jahr 1979 gegründete Firma Lauterbach Datentechnik eintrat. Heute ist er Geschäftsführer der Lauterbach GmbH, wie die Firma nach ihrer Umbenennung offiziell heißt.
Nachdem bereits Niederlassungen in den »üblichen Verdächtigen« Ländern und Regionen (USA, China, Japan, Frankreich, Italien, England) aufgebaut wurden, eröffnete Lauterbach 2014 eine weitere Niederlassung in Tunesien.
Im Jahr 2009 erfolgte der Umzug in den neuen Firmenhaupsitz in Höhenkirchen-Siegertsbrunn bei München, der sich vollständig im Eigentum der Lauterbach befindet.
- 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
