Endlich einmal ein Feedback zu einem Artikel, mit konkreten Hinweisen aus anderer Sicht. Insbesondere die 5 Varianten der Fehlerbehandlung, die der Kritiker nennt, finden meine Zustimmung. Aber: Insbesondere Punkt 1, 4 und 5 dürfen keine dauerhafte Programmiererentscheidung sein, sondern sollten ohne Quellenänderung je nach Aufrufumgebung einstellbar sein. Beim Test (von embedded Software am PC, insbesondere Unit-Test) Verletzungen mit Exception melden, damit die Fehler überhaupt erst deutlich erkannt werden. Danach die gleiche Software im Zielsystem unter kritischen Echtzeitbedingungen nach 1. behandeln, oder nach 4. wenn ein Fehler nicht ausgeschlossen werden kann. Genau dafür habe ich meine Makros für TRY-CATCH entworfen. Punkt 3 der Kritik, "Mythos Exception Handling kostet Rechenzeit" ist leider kein Mythos sondern gemessener Fakt und auch an sich ganz logisch und folgerichtig, wie ich im Artikel nicht ausführlich genug dargestellt habe. Modernes Exceptionhandling in C++ hat den Zusatzaufwand im Nichtfehlerfall auf fast 0 reduziert. Durchläuft ein Algorithmus ein try-catch ohne Exception, dauert er kaum länger als ohne diesen try-catch-Rahmen. Damit ist Performance gesichert und der obige Mythos tatsächlich ein Mythos, nicht wahr, diesbezüglich. Aber: Dafür dauert das throw um so länger. Und dies geht nicht, wenn eine hochzyklische kritische Echtzeitverarbeitung erfolgt. Damit ist Exceptionhandling mit C++ throw nicht anwendbar in zyklischen Interrupts oder Threads von Regelungen. Aber Exceptionhandling ist wünschenswert. Was macht eine weggelaufene Regelung wegen eines defekten Sensors? Am besten throw, und eine Ersatzhandlung im catch sichert die Funktion. Sind alle Fehlermöglichkeiten einer komplexen Software vorher per Test vorauszusagen? Nein. Man möge nicht wieder unterstellen, ich würde Unit-Test ablehnen. Auch Boeing hat bei 737 MAX sicherlich Unit-Tests durchgeführt. Da man im embedded Bereich die Destructoren eigentlich nicht wirklich braucht bzw. bewusst darauf verzichten kann, ist der longjmp die probate Lösung. Denn er hält die Zeitbedingungen ein und funktioniert genauso. Ich möchte dies nochmals deutlich unterstreichen, in Kenntnis der Argumente von Kritikern. Als letztes eine Bemerkung zu C++ und Java. In C++20 mit "gcc -c -x c++ -std=c++20", aufgerufen unter Cygwin, gcc (GCC) 10.2.0 kann man immer noch fehlerfrei programmieren: ExmplClass* myClass = new ExmplClass(); (myClass+1)->set(456); Die unmittelbar hintereinanderstehenden Statements offenbaren mit dem Hinsehen oder einem Checktool selbstverständlich den Blödsinn dieser Anweisungsfolge. Stehen die Anweisungen jedoch nicht hintereinander und ist der Fehler Folge von Änderungen nicht bis ins letzte durchdacht, und Fehler beim Unittest nicht aufgefallen, dann erzeugen solche Fehler über Seiteneffekte irgendwo anders die Nullpointer oder zerstörte vtbl-Zeiger. Die Ursache sind die in den 1970-ger Jahren gefundenen einfachen Grundlagen in C, die in C++ immer noch möglich sind und verwendet werden. Man hat unter Kenntnis dieser Dinge mit Java in den 1990-gern einen Schnitt gemacht und so etwas gar nicht zugelassen (Pointerarithmetik). Daher ist Java und weitere beliebte Programmiersprachen im PC Bereich sicher und dringend zu empfehlen gegenüber C++. C und besser C++ ist notwendig (wenn man so will ein notwendiges Übel) im embedded Bereich, um direkt und optimal auf die Maschinencodeebene zu kommen. Andere Programmiersprachen haben sich dafür leider nicht etabliert. Es gibt auch für Java für Embedded passende Virtual-Machine-Lösungen, leider nur nicht so bekannt. Diese wären dann für den Teil der Datenverarbeitung (ohne Hardwarezugriffe) die bessere Lösung. Hartmut Schorrig

Hello everyone! If you are familiar with requirements engineering and you are currently looking for a job, the following information might be interesting for you. bolded textLOOKING FOR SOFTWARE AND HARDWARE ENGINEERS, SYSTEMS ENGINNERS AND BATTERY DEVELOPMENT IN THE FIELD OF AUTOMOTIVES.bolded text Since 2008 Schwanke Bros. Executive Search has stood for first class Executive Search service. As a family business with down-to-earth values, our priority is always our clients’ needs, down to the smallest detail. We will do whatever it takes to get the best results, every time. Our clients are well known German companies in both the mechanical and automotive industries. Especially in the automotive industry we have a vast network in the e-mobility sector with OEMs and suppliers where we have searched and placed specialists in software, hardware, battery technology and other jobs. At Working In Germany we offer a unique service to connect international specialists with these companies. You can apply on our website http://workingingermany.de/. If you have any questions, please feel free to contact me via email dab@gebr-schwanke.de Daria Breitkreuz Project Manager

@admin Die Sachverhalte in Abbildung 7 und 8 (dynamische vs. statische Verschaltung) sind nicht so leicht zu verstehen. Vielleicht könnte der Autor in einem zukünftigen Artikel darauf mit einem geeigneten Beispiel mal etwas näher eingehen. Vielen Dank.

@wolfgang-schlicker Sorry aber was für ein bullshit: Hat die Frau Riederer von Java oder von JavaScript gesprochen? Alles was ich lese ist JAVA und das ist doch wohl ein Unterschied?

Für mich war der Artikel Neuwert! Ich bin bestens vertraut mit MSVC und GCC (MinGW auf Windows), bin irgendwo über Clang gestolpert ("was ist das"), LLVM war mir bisher kein Begriff. Ist aber absolut wichtig. Mehr zu LLVM steht in https://de.wikipedia.org/wiki/LLVM Ich habe mich früher schon gefragt, ob es einen zweckdienliche Verbindung der Java-Technologie mit Bytecode und JIT und C/++ geben sollte: Mit LLVM ist diese da. Frage: Bei klassichem Compilieren/Linken gibt es das Problem: Lange ungenutzte Routine in einem Objfile, der Objfile wird aber wegen einer anderen Routine vom Linker eingezogen, Speicherverschwendung, tut weh auf embedded small footprint Plattformen (unrelevant für PC-Programme). Die LLVM-Technologie könnte aber in der Lage sein zu erkennen was tatsächlich gebraucht wird auch unterhalb des Schnitts in "Übersetzungseinheiten". Das bedeutet für die Quelltextgestaltung (in C/++) dann man nicht mehr darauf achten braucht, bestimmte Dinge eben nicht in ein C-File zu schreiben. Es wäre dann vollkommen egal. Auch könnte die Entscheidung wann inline vollkommen der Compiler-Optimierung (nach Laufzeit oder Codegröße, ggf. auch eine max. Codegröße als Limit angebbar) überlassen werden. Hinweis: inlines sind laufzeitoptimal aber ggf. speicherintensiver, aber solange der kleine Embedded Speicher reicht, sind inlines besser. Weitere Frage: Wie sieht es mit der automatischen Parallelisierbarkeit aus (Multicore-Aufteilung).

Die Überschrift ist leider nicht prägnant denn das eigentliche Thema ist ja das "PIL" Prozessor in the Loop. Aber meine Anmerkung beziehen sich auf den Begriff HIL - Hardware in the Loop. Der Begriff ist leider auch nicht prägnant, die Frage ist "welche Hardware". In der Domäne des Autors ist die äußere Umgebung die Hardware, bestehend aus den Sensoren usw. im Fahrzeug. Ich kenne den Begriff aus dem Anlagenbau, und da ist es die Steuerungshardware, die bei HIL gemeint ist, also genau das, was der Autor als "PIL" bezeichnet. Bei Automatisierungsgeräten ist das natürlich nicht nur der Prozessor, sondern halt die gesamten Schaltschränke. Ich habe daher eine Weile gebraucht und musste erst den Abschnitt genau lesen, um zu verstehen, was das HIL-Setup sein soll. Etwas, was es so im Anlagenbau nicht gibt. Nun kann es sein, dass Sprachgebrauch selbst in benachbarten Gebieten verschieden ist, was aber bei Wissenschaftssprache nicht sein sollte. Also muss man Begriffe schärfen. Daher gefällt mir der Begriff PIL durchaus, den "Prozessor" ist konkreter als "Hardware" - wenn den nun der Begriff PIL für die Tatsache "Schaltschränke in the Loop" auch akzeptierbar wäre. Ich will dies mal als Diskussion in den Raum stellen, denn immerhin bestehen Schaltschränke aus Boards, die innen immer Prozessoren haben. Der Ansatz, den Prozessor verlangsamt laufen zu lassen weil die äußere Umgebung per Software langsam simuliert wird (für die Fahrzeuganwendung also die Umgebungsnachbildungen, was die Sensoren erfassen), ist interessant und wichtig. Ich kenne es so, dass der Prozessor oder Schaltschrank in the Loop in Echtzeit läuft und das deshalb Aufwändungen getrieben werden, dass die Umgebung, die man nicht real haben kann (Anlage ist groß und mechanisch), möglichst in Realtime simuliert wird. Mit schnellen Prozessoren, Abtastzeiten bis 3 µs oder FPGA usw. (bin gedanklich bei Stromrichterhardware). Der Ansatz ist aber interessant. Es kommt darauf an, die Algorithmen im Target zu testen, man hat aber noch nicht die Environment-Realtime. Daher muss der Prozessor meist warten. Auch hat der Prozessor eben noch nicht alle Peripheriebaugruppen angeschlossen und wird daher über den Debugger versorgt. Das ist lesens- und denkenswert. Ich wünsche mir mehr Anmerkungen zu Artikeln, denn auch wir Leser müssen miteinander reden und diskutieren.