C++17 IDE für STM32

Hmmh. Assembler gehört zum Debuggen schon sehr stark dazu.

Die IAR Embedded Workbench für Arm unterstützt in den neuesten Versionen 
C++17. Ist aber ein kommerzielles Tool, bei dem nur eine auf 32kB 
limitierte Version kostenlos ist.

Dafür bekommt man einen recht leistungsfähigen Debugger (ordentliche 
Probe vorausgesetzt) inklusive Simulator.

Redest du da nur vom Compiler oder wirklich von der von der 
Code-Completion?

Mich wundert es etwas, dass die nicht generell den neusten GCC 
einsetzen. Der GCC9.1 hat ja nun schon Anfänge von C++20.

Bzgl Eclipse und C++17 ist hier nochmal ein schöner Artikel:
https://www.eclipse.org/community/eclipse_newsletter/2017/april/article5.php

...aus 2017. Aber da haben es welche eingesehen, dass es beim 
Fortschritt von C++ (alle 3 Jahre eine neue Version) mit Eigenbauten 
nicht weitergehen kann.
Wenn Codan tot ist, ist das ja gut. Aber ich hätte da gehofft, dass man 
in 2 Jahren  schon irgendwie auf Clang umgestiegen ist. hmmmh.

VS Code, cpp mode, language/debug server, jlink zum debuggen. Cmake oder 
Makefile zum bauen!

Vincent H. schrieb:
> Mw E. schrieb:
>> VSCode wollt ich auch mal ausprobieren, aber als ich las, dass das in
>> JavaScript geschrieben ist dachte ich:
>> NEIN! einfach NEIN!
>
> Die Befürchtung hatte ich erst auch aber was MS da auf Electron Basis
> gezimmert hat ist richtig flott und fühlt sich immer responsive an.

VSCode ist in TypeScript geschrieben, nicht JavaScript. Am Ende kommt 
JavaScript raus, ja, aber man hat mit TypeScript viel mehr 
Möglichkeiten.

Zustimmen kann ich aber, es ist verdammt flott, hatte noch nie Probleme 
damit. Warum man es nicht nutzen möchte, nur weil es auf einer 
bestimmten Programmiersprache basiert, will mir nicht in den Kopf.

ja, aber noch nicht sehr ausgiebig. Wenn man ein unterstütztes Board hat 
ist alles sehr einfach, es muss nicht wie VSCode PlugIns zusammengesucht 
werden und es ist fertig konfiguriert.
Bezüglich Fehler- und Warnmeldungen hat sich der ARM Compiler etwas 
anders verhalten als der gcc, aber das war schnell zu korrigieren.
Leider werden im Moment noch nicht viele Boards vom Debugger unterstützt 
und auch für das ältere mbed2 ist es nicht gemacht. Aber gerade da wäre 
es interessant, der ARM compiler erzeugt für die Cortex-M0 wesentlich 
kompakteren Code.

Mit der Einstellung bist du leider in den 80ern stehen geblieben.

Mw E. schrieb:
> Bei dem anti JS rant da oben fühlen sich wohl ein paar JS Kiddies
> gekränkt.
> Für Argumente bin ich ja immer zu haben, aber ich sehe keine pro JS als
> Desktopprogrammiersprache.

Ich sehe js mittlerweile auch als gefährlich an. Das liegt aber nicht an 
js selbst sondern an dem was daraus gemacht wird. Mal nur ein Beispiel. 
Man nehme eine aktuelle nodejs Version und will damit ein paar Byte über 
UART austauschen. Also mal schnell: "npm install serialport" getippt. 
Geht ja so einfach. Leider landen dann sofort 616 Dateien in 133 
Verzeichnissen auf der Platte die ab sofort zum Projekt gehören. Das 
wird von den node-Jüngern dann so einfach unkommentiert hingenommen. Mir 
wird davon schlecht.
Eine kleine App unter cordova für iOS und Android bringt es auf 1965 
Dateien in 822 Verzeichnissen mit Code aus allen Herren Ländern dessen 
Abhängigkeiten niemand verifiziert. Glaubt denn wirklich jemand, dass da 
noch einer durchsteigt und dass das in 2 Jahren auch noch läuft? Wie 
will man da verhindern dass beim automatischen Zusammenschaufeln von 
Code aus tausenden Projekten nicht doch irgendwann mal ein faules Ei 
darunter ist?
Schöne neue Welt.

Mw E. schrieb:
> aber ich sehe keine pro JS als Desktopprogrammiersprache

Viele Programmierer können es, damit wird die Entwicklung billiger. Mit 
welcher Sprache sonst kann man so komfortabel (und damit billig) Web 
Apps, Smartphone Apps, Server Backends und Desktop Apps schreiben?

Es gibt eine Riesen Menge an Tools und Bibliotheken, was die Entwicklung 
weiter vereinfacht & verbilligt. Oder würdest du lieber extra zahlen für 
eine IDE die in deiner Lieblingssprache geschrieben ist...? Was 
interessiert dich die Sprache einer Anwendung, die du nicht selbst 
modifizieren musst? Einfach nicht nach schauen und benutzen. Ich kann 
dir verraten dass im Backend mancher Web Apps sogar noch Fortran 
werkelt...

temp schrieb:
> Leider landen dann sofort 616 Dateien in 133 Verzeichnissen auf der
> Platte die ab sofort zum Projekt gehören. Das wird von den node-Jüngern
> dann so einfach unkommentiert hingenommen. Mir wird davon schlecht

Dir wird von Dateien schlecht? Dann schau besser mal nicht in die 
Verzeichnisse z.B. vom GCC oder den üblichen C Libraries wie HAL oder 
SPL, oder dem unsäglichen TI PDK Monstrum. Was man in modernen Sprachen 
wie JS in 3 Zeilen macht braucht in C 100, das sorgt allein schon für 
geringe Code Density...

https://www.st.com/en/development-tools/stm32cubeide.html
Hab ich allerdings noch nicht getestet und bzgl. C++17 hab ich auch nix 
gefunden.

und zum Vergleich mit Java: hat hier schonmal jemande versucht 
durchzusteigen wie die Eclipse Erweiterungen funktionieren? Da sind 
erstmal zig Verwaltungsdateien, der Code liegt irgendwo kompiliert vor. 
Bei VS Code sind die Erweiterungen natürlich auch in JS/TS, da kann man 
bei Bedarf sogar mit VSCode direkt rein debuggen und Sachen 
korrigieren/ändern.
Das Persistenzformat der Einstellungen in .cproject bei Eclipse ist 
eklig und obwohl fast jeder µC Hersteller eine Eclipse Variante anbietet 
sind die Projekte in keiner Weise kompatibel. Bei VSCode ist alles gut 
lesbar in JSON gespeichert und leicht per Code zu bearbeiten.
Eclipse ist ein extrem gewachsener Moloch, das kann sehr sehr viel aber 
die Realisierung ist viel zu kompliziert.
Ich habe Kollegen die wollen von C++ nichts mehr wissen und machen alles 
nur noch in JS/TS. Neulinge von der Uni zaubern in wenigen Wochen Sachen 
da hätten die C++ Leute ein Jahr und länger dran gesessen.

Dr. Sommer schrieb:
> Dir wird von Dateien schlecht? Dann schau besser mal nicht in die
> Verzeichnisse z.B. vom GCC

Wie war das doch gleich mit Äpfeln und Birnen? Der GCC ist ein Projekt 
in sich. Sicher kein kleines aber von einer Community in sich gepflegt. 
Da wird nicht wie beim npm alles erst zusammengetragen. Und ja mir wird 
vor dem Wildwuchs schlecht.

> oder den üblichen C Libraries wie HAL oder
> SPL, oder dem unsäglichen TI PDK Monstrum.

Meine Meinung darüber habe ich auch schon oft geäußert. Selber schuld 
wer das verwendet.

> Was man in modernen Sprachen
> wie JS in 3 Zeilen macht braucht in C 100, das sorgt allein schon für
> geringe Code Density...

aber nicht wenn für diese 3 Zeilen 20 verschiedene Module mit ein paar 
100 Dateien nötig sind, die zusammenhanglos von irgendwo her ins Projekt 
installiert werden. Das ist leider bei python genauso wie bei nodejs die 
Regel.

Johannes S. schrieb:
> Ich habe Kollegen die wollen von C++ nichts mehr wissen und machen alles
> nur noch in JS/TS. Neulinge von der Uni zaubern in wenigen Wochen Sachen
> da hätten die C++ Leute ein Jahr und länger dran gesessen.

Zaubern ist hier wirklich das Schlüsselwort. Nichts dagegen wenn man 
sich für ein paar schnelle Sachen für den schnellen Weg entscheidet. 
Trotzdem kommt am Ende nur ein Müllhaufen aus wenig eigenem und viel 
fremden Code raus der eventuell heute funktioniert, aber keiner weiß wie 
und warum.
Wie gesagt ich habe nichts gegen js. Wir embedden die V8 selbst in 
eigenen Produkten. Auch nodejs an sich will ich nicht schlecht machen. 
Aber die Art und Wiese wie es am Ende zu fertigen Applikationen kommt 
und wie die Codebestandteile zusammengetragen werden ist einfach nur 
krank.

temp schrieb:
> Sicher kein kleines aber von einer Community in sich gepflegt.

Nur dass der GCC alleine eben nicht zu gebrauchen ist. Da kommen dann 
noch binutils und diverse andere Bibliotheken wie newlib zu.

temp schrieb:
> Da wird nicht wie beim npm alles erst zusammengetragen.

Nur weil ARM das freundlicherweise alles in ein großes ZIP packt. Wären 
das einzelne Pakete in einem Paketmanager à la npm könnte man die auch 
einzeln aktualisieren - schön wär's!

temp schrieb:
> aber nicht wenn für diese 3 Zeilen 20 verschiedene Module mit ein paar
> 100 Dateien nötig sind, die zusammenhanglos von irgendwo her ins Projekt
> installiert werden.

Die meisten Programmierer haben zum Glück keine Modul-Allergie. Ich 
find's super einfach ein paar Pakete zu importieren und komplexe 
Aufgaben im Nu umzusetzen. Im Embedded-Bereich ist diese Mentalität auch 
vorhanden, aber kurioserweise disjunkt von textbasierter Programmierung: 
Das Hauptargument von Simulink und Konsorten ist es, dass es bereits 
viele Komponenten wie PID-Regler oder Verzögerungsglieder usw. 
integriert hat - das grafische Zusammenklicken selbiger kommt erst an 2. 
Stelle. Wie schön es wäre, in C(++) entsprechende Module kombinieren zu 
können! Aber die wären dann wieder in vielen Dateien abgelegt...

temp schrieb:
> Trotzdem kommt am Ende nur ein Müllhaufen aus wenig eigenem und viel
> fremden Code raus der eventuell heute funktioniert, aber keiner weiß wie
> und warum.

Es weiß auch kein einzelner Mensch wie ein Computer oder der 
Linux-Kernel funktioniert. Code, der sich auf fremde Komponenten stützt, 
ist noch lange kein "Müllhaufen". Das ist absolut gang und gäbe - jedes 
Rad für jedes Projekt in jeder Firma neu zu erfinden ist ziemlich irre! 
Nur Embedded-C-Programmierer haben da irgendwie Probleme mit.

Dr. Sommer schrieb:
> Es weiß auch kein einzelner Mensch wie ein Computer oder der
> Linux-Kernel funktioniert. Code, der sich auf fremde Komponenten stützt,
> ist noch lange kein "Müllhaufen". Das ist absolut gang und gäbe - jedes
> Rad für jedes Projekt in jeder Firma neu zu erfinden ist ziemlich irre!
> Nur Embedded-C-Programmierer haben da irgendwie Probleme mit.

Im Fall von nodejs aber schon. Bei einer normalen 
Applikationsentwicklung verwendet man natürlich Libs da wo es angebracht 
ist. Und versteht auch nicht den gesamten Code. Soweit so gut. Trotzdem 
nimmt man eine bestimmte Version dieser Lib, die auch nicht immer die 
neueste sein muss, und hat unter Kontrolle welche Bestandteile man in 
welcher Version benutzt und woher sie kommen. Man kann auch gezielt 
Updates einzelner Bestandteile machen und behält auch die Kontrolle.
Um beim Beispiel mit nodejs zu bleiben. Ein "npm install serialport" 
installiert aber Unmengen von modulen unbekannter Versionsstände auf die 
man damit keinen Einfluss hat. Mache ich das gleiche in 2 Wochen oder 
Jahren oder nur auf einer anderen Maschine landet nie der gleiche Code 
auf der Platte. Und keiner hat eine Übersicht darüber oder kann es 
beeinflussen.

Das dich das nicht interessiert ist mir klar. Der Satz sagt alles:
Dr. Sommer schrieb:
> Einfach nicht nach schauen und benutzen.

Dr. Sommer schrieb:
> Die meisten Programmierer haben zum Glück keine Modul-Allergie.

Das habe ich auch nicht. Jedenfalls solange ich die Kontrolle darüber 
habe welche Module und in welchen Versionen. Wenn dich das nicht 
interessiert ist es grob Fahrlässig und ich bin froh dass du nicht auf 
Flugzeuge oder der gleichen los gelassen wirst.

Das Thema der vielen verteilten Komponenten kommt aber aus der massiv 
eingesetzten OpenSource Software. Da gibt es nicht den einen der alles 
am Stück liefert, es hat sich ein Sammelsurium an guten Komponenten 
etabliert und die werden von verschiedenen Leuten gepflegt. Den Software 
Dinosaurieren wie MS und Co. war das auch nicht recht, die hätten die 
Fäden lieber selber alle in der Hand und möchten nur das Interface, 
nicht aber die Implementierung liefern. Viele Programmierer wollen das 
aber nicht und dieses Geflecht an Komponenten hat sich entwickelt. Bei 
JS Anwendungen ist aber ein einfach durchschauberes System der 
Paketverwaltung dahinter und Pakete sind üblicherweise alle als 
Quellcode vorhanden. Das es teilweise viel ist kommt auch von dem 
Komfort den diese bieten. Ein einfaches OS API hat im Hintergrund 
üblicherweise auch viele verzahnte Komponenten. Ein OS unabhängiges 
Paket muss nun vieles wieder neu erfinden wenn es sich nicht auf 
Features eines OS verlassen will. Und das funktioniert bei NodeJS auch 
erstaunlich gut, selbst grosse Dinger wie NodeRed laufen unter Windows 
genauso wie auf dem RPi.
Und Alternativ muss man ja nicht grosse Frameworks benutzen, gerade mit 
NodeJS hat man eine gute Basis für einfache eigene Anwendungen.