DESIGN&ELEKTRONIK TechTalk
MCUs werden immer komplexer, was tun?
Fortsetzung des Artikels von Teil 2
Das sagte Thomas Bauch von PLS
Herr Bauch, ist die Embedded Branche zu konservativ beim Thema Softwareentwicklung?
Thomas Bauch: Zumindest sind die Innovationszyklen hier bei weitem nicht so kurz wie in einigen anderen Bereichen. Fünf bis sechs Jahre nach dem Launch von Windows 3 gab es immer noch Entwicklungen in Assembler. An diesem deutlichen zeitlichen Versatz, der mitunter auch pragmatisch bedingt ist, hat sich bis heute grundsätzlich nichts geändert. Anbieter, die seit sieben bis zehn Jahren höhere abstraktionsbasierende Ansätze wie UML propagieren, sehen wir nach wie vor nur bei bestimmten Sachverhalten.
Sind Entwickler selbst schuld, wenn softwaretechnische Unterstützung wie ein CMSIS nicht genutzt wird?
Bei Bibliotheken muss erst einmal ein Durchdringungseffekt eintreten. Wenn Sie konkret CMSIS ansprechen, trete ich sicher niemandem zu nahe, wenn ich sage, dass die erste Version optimierbar war. Damit konnten sie sicher eine gewisse Komplexität abstra-hieren. Die mittelständische Industrie hätte aber lieber einen Prozessor, der zehn Jahre verfügbar ist, wie es der C166 war. Die Bibliotheken bilden immer nur den kleinsten gemeinsamen Nenner ab. Jegliche Spezialitäten der Hersteller spiegeln sich darin gar nicht oder nur verzögert wieder. Eine Differenzierung ist damit also nicht möglich.
Gibt es auch technische Vorbehalte gegen Bibliotheken?
Das Know-How der mittelständischen Industrie besteht ja nicht darin, Timer zu programmieren oder PWMs zu konfigurieren, sondern etwa in einer mikrogradgenauen Temperaturregelung. Es stellt sich die Frage, ob die sich daraus ergebenen Sachzwänge immer zu den von den Herstellern veröffentlichten Bibliotheken passen.
» Wir sehen immer mehr Debugger in Testumgebungen «
Was Debugger angeht, gibt es Fortschritte?
Ja, wir sehen immer mehr den Einsatz von Debuggern in Testumgebungen und dort einen halbautomatischen Mischbetrieb. Methoden wie Test-driven-Development sind immer mehr im Kommen, fast bei jeder zweiten Anfrage kommt die Frage, ob man den Debugger über Dritttools oder Scripts automatisieren kann. Allerdings ist dies häufiger bei größeren Firmen der Fall als bei kleinen Kunden.
Wie unterscheiden sich die Entwicklungsmethoden von großen und kleinen Firmen generell? Haben Sie da Erfahrungen?
Bei kleinen Firmen mit einer Stückzahl von 100 und Stückpreisen von 1000 oder 10.000 Euro kann ich das nicht mit großen Firmen vergleichen, die Stückzahlen von einer Million produzieren. Beide setzen unter Umständen den gleichen Controller ein. Der eine investiert jedoch in eine lange Produktlebensdauer mit dem Fortschreiben seines Know-Hows im Kontext des Toolings. Bei dem anderen verschwinden die Tooling-Kosten sozusagen im Gesamtprojekt. Dort gibt es dafür aber andere Herausforderungen hinsichtlich der Qualitätssicherung der Software.
Was ist mit MathLab und anderen modellbasierten Werkzeugen?
Sie müssen ja am Ende nicht nur Testen, sondern auch nachweisen, dass Sie getestet haben. Da spielt der Debugger eine zentrale Rolle als Vermittler zwischen den höheren Abstraktionsebenen und der Hardware.
Bei Open-Source-Software gibt es immer das Thema Zertifizierung, wie ist darauf Ihre Sicht?
Theoretisch ist das kein Problem, weil Sie ja bei einer Zertifizierung bestimmte Merkmale testen. Sie haben ja den Quellcode und müssen dann eben selbst testen. Allerdings testen Sie genau einen Schnappschuss. Wenn es 14 Tage später ein Update gibt, ist die Zertifizierung hinfällig. Dazu kommt die Frage der Nutzungsrechte, die eine ganz spezielle Herausforderung ist.
Ist es denkbar einen Cut zu machen, um beispielsweise von proprietärem Code auf ein RTOS zu wechseln?
» Ein Cut ist machbar, aber schwierig «
Eine sehr gute Frage. Ein Cut ist machbar, aber er ist sicher schwierig, weil hierdurch Aufwand generiert wird und die Software als Teil des Gesamtprojektes oft unterschätzt wird...
Wie meinen Sie unterschätzt? Der Controller bekommt die Zahlen doch auf den Tisch!
Ja, hinterher. Tatsache ist, es läuft irgendwie, aber viele Entwickler tun sich schwer zu sagen, ich will jetzt mal meine Softwareentwicklung auf eine neue Stufe heben. Gespräche auf der Embedded World zeigen immer wieder, dass solche Entscheidungen de facto nicht mehr möglich sind. Eigentlich müsste man bei der Produktdefinitionen und dem Produktlebenszyklus auch den Softwarelebenszyklus mit berücksichtigen. Man sollte eben nicht nur das eine Jahr Entwicklung am Anfang sehen, sondern sich auch die Frage stellen, wie kann ich etwaige Erneuerungszyklen mit meinen Investments in Software und Tools optimieren. Diese gesamtheitliche Denkweise ist noch nicht überall weitreichend aus Management-sicht berücksichtigt.
Dann wäre es wohl egal, ob ein RTOS 3000 oder 5000 Euro kostet oder ein Entwickler pro Stunde 190 oder 250 Euro oder auch kein Problem, einen Debugger für einige tausend Euro einsetzen?
Richtig. Investitionen in Software-Technologien sind immer Investitionen in die Zukunft. Über die gesamte Produktlebensdauer aktueller Produkte und auch für zukünftige Produkte kann man sicher mit einer neuen Ausgangsbasis besser fahren, das Problem ist nur, Einsparungen in der Zukunft mit Investitionen in aktuelle Projekte zu rechtfertigen.
Lieber fängt man immer wieder von vorne an, und das bei anteiligen Software-Kosten in einem Projekt von weit über 50 Prozent?
Man schiebt die Softwarekosten von einer Generation in die nächste und fängt immer wieder von vorne an. Das ist oft so, ja.
Wie sehen Sie Renesas Synergy hinsichtlich des Ansatzes als solchen und der Marktakzeptanz?
Ich kann mangels Zahlen dazu nur generell sagen, dass wir feststellen, dass ein vom Hersteller bereitgestelltes Ecosystem die Akzeptanz des Controllers deutlich erhöht. Beispiele hierfür sind DAVE von Infineon oder SPC5-Studio von ST Microelectronics. Die Einstiegsschwelle wird gesenkt. Die Frage ist dann, ob diese Lösung viele Jahre Tragfähigkeit verspricht oder nur eine Einstiegslösung ist, weil zum Beispiel bestimmte Peripherals durch solche Pakete nicht vollständig abgedeckt werden.
» Cut and Paste ist nicht im Sinn des Erfinders «
Dann bleibt Cut and Paste vom Code-Generator?
Richtig, aber das ist ja nicht im Sinn des Erfinders! Man müsste ja eigentlich die Code-Generatoren in dem Framework weiter benutzen, aber die Frameworks sind oft nicht weit genug gedacht, sondern eher bare-metal-behaftet. Die Frage am Ende ist, welche Leistung bekomme ich im Kontext welcher Tool-Entscheidung.
Wie sieht es eigentlich bei diesen Entscheidungsfindungen mit dem Thema Verlässlichkeit aus?
Das ist ein guter Punkt. Wenn Sie sich für einen Weg entscheiden, müssen Sie den ja auch intern verantworten. Nehmen Sie als Beispiel wieder CMSIS. Am Anfang war es nichts als ein großes Versprechen, jetzt nach sieben Jahren ist es etabliert, da können Sie von Verlässlichkeit ausgehen. ARM hat ein Problem erkannt, nämlich dass zig Controller mit unterschiedlicher Peripherie den Entwicklern ein Software-Problem beschehren. Deshalb hat man mit viel Manpower CMSIS aufgesetzt. Eine gute wenn nicht sogar sehr gute Lösung, genauso wie ARMs Beitrag zum GNU-Compiler. .
Die Halbleiterhersteller wollten CMSIS nicht wirklich am Anfang….
Weil mit CMSIS die Differenzierungsmerkmale der einzelnen Hersteller mehr in den Hintergrund rücken. Die Produkte werden ein Stück weit austauschbarer. Für ARM ist es nicht schlimm, wenn die MCUs austauschbar sind (lacht). Aber nach einem zähen Anlauf ist die Akzeptanz jetzt deutlich gestiegen.
Der Cortex-M7 ist ja mehr als komplex seitens der Speicherarchitektur. Wäre es nicht eine bessere Lösung, in diesem Preisgefüge gleich auf einen Cortex-A5/A7 mit Linux zu gehen?
Das ist zu einfach gedacht. Es gibt schon unterschiedliche Einsatzgebiete, wo die Skalierung der Speicher, der Peripherie, der einsetzbaren Betriebssysteme und so weiter eine Rolle spielt. Dazu gibt es auch Anwendungsfälle, wo ich nicht gleich Linux einsetzen muss. Der M7 ist eine schöne Abrundung der M-Familie nach oben mit Speicherschutz- und Sicherheitsmechanismen. Ich denke, der wirkliche Feind des Cortex-M7 sind die Hybrid-Chips mit Cortex-A und –M.
Hybrid-Chips sind ein gutes Stichwort. Wie kann man diese überhaupt debuggen, zum Beispiel bei einem durch Timing bedingten Fehler in der Kommunikation zwischen den beiden Cortex-A und –M?
Die Herausforderung ist natürlich, die Sichtbarkeit seines Codes zu gewährleisten und diese speziellen Strukturmerkmale, zum Beispiel Multicore-Architekturen oder den Cache/TCM des Cortex-M7, überhaupt zu unterstützen. Der Kunde fragt sich, kann ich »all-inclusive« von Hersteller A zu Hersteller B wechseln oder muss ich ein neues Tool-Set einsetzen?
Beim Cortex-M7 hat ja ST Microelectronics zum Beispiel das SRAM komplett anders implementiert als Atmel. Die einfache Message ist, der Kunde muss sich klarmachen, was er von unterschiedlichen Angeboten zu halten hat. Hier gibt es bei den unterschiedlichen Entwicklungspaketen teilweise doch sehr deutliche Differenzierungsmerkmale.
Nicht jeder Embedded-Entwickler ist Linux-Experte, aber Linux ist in der Industrie doch mittlerweile akzeptiert. Ist das auch Ihr Eindruck?
Absolut. Es ist deutlich zu erkennen, dass Linux inzwischen eine fest etablierte Grö-ße ist, primär für Visualisierungszwecke, Mensch-Maschine-Schnittstellen und Inter-net-Dienste. Dafür ist das offenbar sehr kostengünstig. Im Bereich der harten Echtzeit sehen wir Linux nur selten, aber in Einzelfällen auch dort. Es gibt ja auch Firmen, die spezielle Linux-Distributionen für Embedded-Anwendungen herstellen und supporten. Dank IoT wird die Verbreitung von Linux sicher weiter steigen, aber es wird auch zukünftig Anwendungen ohne Linux geben.
Brandneues Produkt zum Thema: Softwareentwicklung für komplexe High-End-SOCs mit UDE 4.10.
PLS' brandneue UDE 4.10 vereinfacht Multicore-Debugging und Systemanalyse in echtzeit- und sicherheitskritischen Anwendungen
Eine Vielzahl komplett neuer und erweiterter Funktionen für das Debugging, den Test und die Systemanalyse von komplexen Multicore-Anwendungen in echtzeit- und sicherheitskritischen Embedded-Systemen bietet die Version 4.10 der Universal Debug Engine (UDE). So wurde für die umfassende Unterstützung neuester Multicore-Systeme wie der AURIX 2G-Familie von Infineon mit bis zu acht programmierbaren Ausführungseinheiten oder dem S32V von NXP mit seinen leistungsfähigen Cortex-A53-Kernen unter anderem das Multicore-Management, welches beispielsweise das synchrone Anhalten und Starten von mehreren, heterogenen Kernen ermöglichst, weiter optimiert. Speziell für Anwender ARM Cortex-basierter SoCs hat PLS zudem seine Befehlssatzunterstützung erweitert. Die neueste Version der UDE erlaubt Anwendern nun, Code in den Ausführungsmodi AArch32 und AArch64 gleichzeitig zu debuggen.
Mit der UDE 4.10 stehen Entwicklern darüber hinaus künftig noch effizientere grafische Visualisierungsmöglichkeiten für die Analyse des Laufzeitverhaltens von Applikationen zur Verfügung. Basierend auf den aufgezeichneten Trace-Daten, lässt sich selbst bei sehr großen auszuwertenden Datenmengen schnell der Programmablauf oder auch die Call-Tiefe über die Zeit darstellen. Durch die grafische Aufbereitung der Abläufe können ohne großen zusätzlichen Aufwand sehr einfach Rückschlüsse beispielsweise zur Lastverteilung oder Synchronisation von auf mehreren Kernen verteilter Software gezogen werden.
Ein weiteres herausragendes neues Leistungsmerkmal der UDE 4.10 ist die Unterstützung von ASAP2-Beschreibungen für Steuergerätesoftware. ASAP2- bzw. A2L-Dateien beschreiben, wie physikalische Größen, Kennlinien und andere Parameter von Steuergeräten auf Programmvariablen, interne Speicherstrukturen und Datentypen abgebildet und umgerechnet werden. Der Anwender kann nun direkt mit Development Tools mit den Steuergeräteparametern arbeiten und diese auch ändern, ohne sich um deren tatsächliche Repräsentation im Speicher des Mikrocontrollers kümmern zu müssen. Selbstverständlich findet dabei auch eine Überprüfung auf erlaubte Werte und Wertebereiche statt. Damit gestalten sich das Debuggen und die Laufzeitanalyse von Steuergerätesoftware sehr viel komfortabler und effizienter als in der Vergangenheit.
Eine deutliche Arbeitserleichterung bietet die UDE 4.10 auch Entwicklern komplexer Timer-Algorithmen für das Bosch Generic Timer Modul (GTM). Wo bisher ausschließlich Assemblercode zum Einsatz kam, können Entwicklung und Debugging in Verbindung mit den entsprechenden Compilern von Tasking oder HighTec ab sofort nun auch auf Basis von C-Quellcode erfolgen.
Speziell für die AURIX 2G-Familie wurden zudem das integrierte FLASH-Programmiermodul der UDE 4.10 und das separat verfügbare FLASH/OTP-Programmierwerkzeug UDE/Memtool um zusätzliche Funktionen für den reibungslosen Support von Software-over-the-Air erweitert. Damit besteht jetzt unter anderem die Möglichkeit, auf dem Baustein die Voraussetzungen für spätere sichere Software-Updates über eine bestehende Internetverbindung zu schaffen.
Ergänzend zur UDE 4.10 stellt PLS für ihr UAD2next, das Allround-Zugangsgerät für State-of-the-Art Debugging und Target-Kommunikation über CAN, außerdem zwei neue Trace-Module vor. Mit dem Modul für parallelen Trace können bei 12 Bit und 125 MHz DDR Trace-Daten mit bis zu 250 MBit/s übertragen werden. Das zweite Modul unterstützt serielle auf dem AURORA-Protokoll basierende Trace-Interfaces und überträgt die vom Target erzeugten Trace-Daten über zwei Lanes mit einer Transfergeschwindigkeit von bis zu 1,25 GBit/s. Beide Module können einfach in den robusten Erweiterungs-Slot an der Frontseite des UAD2next eingesteckt werden.
Jobangebote+ passend zum Thema
- 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
