mikrocontroller.net

Forum: Compiler & IDEs Makefiles auf Linux für STM32


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von C. W. (chefkoch)


Bewertung
0 lesenswert
nicht lesenswert
Hallo *,

kurze Frage: Ich würde gerne die Sourcen von 
https://github.com/ttrftech/NanoVNA compilieren. Normalerweise arbeite 
ich mit VisualGDB und importiere eigentlich keine Projekte. An einen 
Import dieses Projektes ist aus meherern Gründen garn nicht zu Denken. 
Der erste ist das ich keine *.mk Dateien so einbinden kann wie es dieses 
Projekt möchte. Das nächste Problem ist Windows. In zwei der *.mk 
Dateien finden sich Aufrufe der Art

HALCONF := $(strip $(shell cat halconf.h | egrep -e "\#define"))


ifneq ($(findstring HAL_USE_DAC TRUE,$(HALCONF)),)
HALSRC += $(CHIBIOS)/os/hal/src/hal_dac.c
endif
ifneq ($(findstring HAL_USE_EXT TRUE,$(HALCONF)),)
HALSRC += $(CHIBIOS)/os/hal/src/hal_ext.c
endif

womit zur Copmilezeit Abhängigkeiten einfließen und die erste Zeile 
natürlich unter Windows nicht funktioniert.

Ist es evtl. möglich zum Compilieren auf Windowssystemen (ich würde für 
dieses Projekt lieber eine zweite IDE auf Eclipsebasis unter Windows als 
ein Linuxsystem installieren) die Ausgabe von "cat halconf.h | egrep -e" 
in einer Textdatei abzuspeichern und diese als Eingabe für  "HALCONF :=" 
zu benutzen?

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Ich hab das früher mit Cygwin gemacht: Cygwin für die ganzen 
Kommandozeilentools incl. make und als Compiler die normale 
Windows-Installation des arm gcc. Man muss halt schauen daß alle 
Suchpfade richtig gesetzt sind, dann geht das hervorragend, auch mit 
Eclipse. All die Makefiles und Scripte die da zum Einsatz kamen konnte 
ich später unverändert(!) auf Linux weiterverwenden.

Das war zu Windows 7 Zeiten.

Windows 10 hat soweit ich weiß eine native Linux-Kompatibilitätsschicht 
schon eingebaut (oder nachinstallierbar) und damit sollte das genauso 
gehen wie früher Cygwin wenn MS das nicht komplett verbockt hat. Ich 
selbst hab allerdings vorher schon den Ansprung geschafft und Windows 
kann mich jetzt gernhaben, daher kann ich nicht sagen wieviel Gefrickel 
das ist das zum Laufen zu bekommen, sollte aber trotzdem immer noch 
geschätzt 10 mal weniger Stress bereiten die Linux-Schicht zu verwenden 
als zu versuchen seine Makefiles und Scripte an die verkrüppelte 
Windows-Umgebung anzupassen oder gar beides zu unterstützen.

: Bearbeitet durch User
von PittyJ (Gast)


Bewertung
3 lesenswert
nicht lesenswert
Linux-VM und gut ist es.
Dann hat man die guten Tools und braucht sich nicht mit Windows ärgern.

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
Die guten Tools gibt's auch einzeln für Windows:
http://unxutils.sourceforge.net/
In der UnxUpdates.zip sind cat.exe und grep.exe dabei, man muss also 
noch grep.exe nach egrep.exe kopieren.

Vorteil: man kann die Original-Dateien vom ChibiOS verwenden.

Na gut, es sind nicht die allerneuesten Versionen, aber für den Zweck...
$ wine grep --version       
grep (GNU grep) 2.5.1

Copyright 1988, 1992-1999, 2000, 2001 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

: Bearbeitet durch User
von W.S. (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
C. W. schrieb:
> An einen
> Import dieses Projektes ist aus meherern Gründen garn nicht zu Denken.
> Der erste ist das ich keine *.mk Dateien so einbinden kann wie es dieses
> Projekt möchte.

Nun ja, schlechte Projekte sind eigentlich typisch für Github. Dort 
findet sich regelmäßig Zeugs, das derart viele externe Referenzen 
enthält, daß man es NUR mit einer einzigen IDE/Toolchain übersetzen 
kann. Portabilität gleich null.

Aber wo kommen bei dir die .mk her? Ich finde dort erstmal nur

NanoVNA-master\NANOVNA_STM32_F072\board.mk

und der ganze .mk Schmonzes kommt von ChibiOS her. Dort gibt's die ja 
reichlichst.

Wahrscheinlich kommst du nicht umhin, lediglich die Quellen .c und .h 
herzunehmen, dazu dann sowas wie board.* zu analysieren und dir einen 
sauberen Ersatz dafür selber zu schreiben. Anschließend geht jedoch das 
Suchen nach all den fehlenden Chibi-OS-Teilen los - alternativ das 
Rausschmeißen des ganzen Chibi-OS aus dem Projekt.

'Frohes Schaffen' kann man da nur sagen. Mit derartigen Projekten machen 
sich die Projekt-Autoren immer wieder selbst ihre Entwicklungen kaputt.

W.S.

von Lernbetty (Gast)


Bewertung
2 lesenswert
nicht lesenswert
W.S. schrieb:
>
> Wahrscheinlich kommst du nicht umhin, lediglich die Quellen .c und .h
> herzunehmen, dazu dann sowas wie board.* zu analysieren und dir einen
> sauberen Ersatz dafür selber zu schreiben. Anschließend geht jedoch das
> Suchen nach all den fehlenden Chibi-OS-Teilen los - alternativ das
> Rausschmeißen des ganzen Chibi-OS aus dem Projekt.
>
> 'Frohes Schaffen' kann man da nur sagen. Mit derartigen Projekten machen
> sich die Projekt-Autoren immer wieder selbst ihre Entwicklungen kaputt.
>
> W.S.

Wieder mal der typische W.S. Stuss.

Der Vorschlag von PittyJ ist deutlich sinnvoller.

von C. W. (chefkoch)


Bewertung
0 lesenswert
nicht lesenswert
Ich werde mal probieren ohne das Chibios auszukommen und stattdessen 
Freertos drunter zu schnallen. Das bedingt zwar das ich alle zukünftigen 
Deltas händisch nachpflegen muss aber dafür bin ich dann in meiner 
Version "zuhause". Spätestens wenn ich mal eine eigene Hardware mit 
besserem HF-Teil und evtl. anderer CPU benutzen will gehen die 
Diskussionen mit Chibios und dessen HAL wieder los.

von Christopher J. (christopher_j23)


Bewertung
1 lesenswert
nicht lesenswert
C. W. schrieb:
> Ich werde mal probieren ohne das Chibios auszukommen und
> stattdessen Freertos drunter zu schnallen.

Das ist von allen möglichen Lösungswegen vermutlich einer der 
schmerzhaftesten.

Du benötigst neben dem RTOS auch noch einen HAL. Ja, natürlich kannst du 
weiterhin den von ChibiOS nehmen aber das löst dann dein Problem nicht.
Du kannst also ruhig das gesamte Projekt neu schreiben. Für das bisschen 
Shell-Script willst du das allen ernstes auf dich nehmen?

Alternativen gibt es genug und einige wurden ja auch schon hier genannt: 
WSL, MSYS2, VM,...

W.S. schrieb:
> Nun ja, schlechte Projekte sind eigentlich typisch für Github. Dort
> findet sich regelmäßig Zeugs, das derart viele externe Referenzen
> enthält, daß man es NUR mit einer einzigen IDE/Toolchain übersetzen
> kann. Portabilität gleich null.

Das ist völliger Käse. ChibiOS lässt sich dank des Makefile-basierten 
Builds auf so ziemlich jedem Betriebssystem (Windows, OS X, Linux, etc.) 
mit so ziemlich jedem Compiler übersetzen (GCC, Keil und IAR werden ab 
Werk unterstützt) und das bei einer sehr großen Auswahl 
unterschiedlicher Prozessorarchitekturen. Diesen Variantenreichtum kann 
man dann entweder über ifdef-Orgien mit dem CPP erschlagen oder man 
macht das eben über ein gescheites Build-System, wie z.B. Make. Ich 
halte letzteres für wesentlich sinnvoller.

von C. W. (chefkoch)


Bewertung
0 lesenswert
nicht lesenswert
De eigentliche Buildvorgang ist nicht das Thema. Auf eirgeneiner 
Linuxmaschine im Netzt kann ich das ganze bauen lassen (der eigene 
Rechner mit VM scheidet wegen der Unfähigkeit der eigenen CPU für VMs 
aus). Viel interessanter wäre welche IDE/Editor in der Lage ist während 
dem Schreiben das alles schon richtig aufzulösen um z.B. mit Rechtsklick 
und einer Auswahl zur entsprechenden Datei zu springen in der z.B. eine 
Funktion definiert wird.

Die sache mit dem cat/grep ließe sich lösen indem ich das einmal manuell 
ausführe und das Ergebnis in einer Datei speicher die ich anstelle des 
Shell-Befehls als Eingabe benutze.

: Bearbeitet durch User
von W.S. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Das ist völliger Käse.

Na klar - und der TO hat hier aus lauter Übermut diesen Thread eröffnet. 
Und das besagte Projekt läßt sich problemlos überall und auf allen 
Toolchains ohne Komplikationen übersetzen.  Und .mk Dateien sind 
ebenfalls allen Programmen bekannt.

Sag mal, geht's noch?

W.S.

von Johannes S. (jojos)


Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> Na klar - und der TO hat hier aus lauter Übermut diesen Thread eröffnet.
> Und das besagte Projekt läßt sich problemlos überall und auf allen
> Toolchains ohne Komplikationen übersetzen.  Und .mk Dateien sind
> ebenfalls allen Programmen bekannt.

Ich bin da bei Christopher. Das Projekt ist offensichtlich komplett 
lauffähig und es gibt Vorraussetzungen wenn man es so nachbauen möchte. 
Will man etwas anderes benutzen, dann muss man selber Hand anlegen. 
Fertig. Das macht das Original in keinster Weise schlechter. Wenn man 
das Buildsystem nicht mag ist das PP.
Es lässt sich vielleicht mit FreeRTOS umsetzen, aber die verwendeten 
Komponenten müssen evtl. auch threadsafe sein. Allerdings wird im 
Linkerscript auch gegen die Newlib Nano gelinkt die nicht threadsafe 
ist.

C. W. schrieb:
> Ist es evtl. möglich zum Compilieren auf Windowssystemen (ich würde für
> dieses Projekt lieber eine zweite IDE auf Eclipsebasis unter Windows als
> ein Linuxsystem installieren)

da gibt es mit
https://osdn.net/projects/chibios/releases/70767
doch schon ein vorkonfiguriertes Eclipse.

von C. W. (chefkoch)


Bewertung
0 lesenswert
nicht lesenswert
Johannes S. schrieb:
> a gibt es mit
> https://osdn.net/projects/chibios/releases/70767
> doch schon ein vorkonfiguriertes Eclipse.

Das hat schon etwas von "Berg zum Propheten kommen".

von C. W. (chefkoch)


Bewertung
0 lesenswert
nicht lesenswert
Also prinzipiell funktioniert der Build mit Chibistudio, aber offenbar 
will ich die dämlichste Kombination benutzen die es gibt. Ich fasse mal 
zusammen:

Build im Chibistudio - geht out of the box
Build unter Linux - geht out of the box


Build im VisualStudio mit VisualGDB - geht nicht out of the box
Segger J-Link im Chibistudio - geht nicht out of the box
Segger Systemview (wenn man mal tiefer einsteigen will) - geht nicht out 
of the box

Ich werde jetzt mal hier und da ein paar kleinere Änderugnen an dem 
Projekt für mich im Chibistudio machen, aber die Endlösung wird es nicht 
werden. Es fühlt sich irgendwie nich gut an und ich habe kein Lust noch 
groß Aufwand für das Werkzeug zu betreiben.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
C. W. schrieb:
> Segger J-Link im Chibistudio - geht nicht out of the box

Das sollte eigentlich gehen da Chibistudio ja auch ein Eclipse mit 
Plugins ist. Eventuell für J-Link noch ein Plugin installiert oder 
angepasst werden.
Aber ich bin auch weg von Eclipse, die Konfiguration da ist zu 
undurchsichtig. Wenn der J-Link da installiert ist muss eine passende 
Lauch Configuration angelegt werden.

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mal ne Frage dazu:

Wozu soll denn eigentlich das Chibi-OS in diesem Falle dienen? Also 
welchen wichtigen und unverzichtbaren Job führt das hier aus? Es ist ja 
im Grunde nur eine relativ geradlinige Anwendung, die da ausgeführt 
werden soll. Ist das Chibi-OS nur deshalb dabei, weil die Erfinder der 
Firmware gern mit einem RTOS programmieren - oder gibt es echte harte 
Gründe?

W.S.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
wer soll dir hier eine Antwort darauf geben? Das solltest du die Autoren 
fragen.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
Mal wieder ein typischer W.S. Post!
Erst Müll texten und dann einen Safe Space wollen, wenn mal leichter 
Gegenwind kommt.

Offensichtlich hast du auch mal wieder keine Ahnung von nichts, aber 
willst mitreden.
Reichts inzwischen nicht mal mehr zur Bedienung einer Suchmaschine 
deiner Wahl?
.mk Dateien sind nichts weiter als Makefiles, nur freundlich für 
Windowsuser wegen der Dateiendung.
Windows erkennt den Dateityp an der Endung und mit .mk kannstes mit 
einem Editor deiner Wahl verknüpfen.
make(.exe) ist die Dateiendung egal und daher läuft das auch so.

In dem Sinne:

W.S. schrieb:
> Sag mal, geht's noch?

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Windows 10 hat soweit ich weiß eine native Linux-Kompatibilitätsschicht
> schon eingebaut (oder nachinstallierbar) und damit sollte das genauso
> gehen wie früher Cygwin wenn MS das nicht komplett verbockt hat.

Leider geht das nicht so schön wie mit CygWin. Die Bash führt keine 
Windows Kommandos aus und die CMD.exe führt keine Linux Kommandos aus.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Bernd K. schrieb:
>> Windows 10 hat soweit ich weiß eine native Linux-Kompatibilitätsschicht
>> schon eingebaut (oder nachinstallierbar) und damit sollte das genauso
>> gehen wie früher Cygwin wenn MS das nicht komplett verbockt hat.
>
> Leider geht das nicht so schön wie mit CygWin. Die Bash führt keine
> Windows Kommandos aus

Was?

Hier (erstbester Google-Fund) 
https://www.howtogeek.com/285082/how-to-run-windows-programs-from-windows-10s-bash-shell/ 
steht sehr wohl daß man von bash aus windows exe starten kann!

Also einfach vorher die richtigen Umgebungsvariablen setzen (zum 
Beispiel $CC oder $PATH) und das Makefile müsste den in Windows 
installierten gcc finden und starten können! Oder etwa nicht?

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> daß man von bash aus windows exe starten kann!

Ok, das scheint neu zu sein. Als ich das damals evaluierte, ging das 
noch nicht.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Ok, das scheint neu zu sein. Als ich das damals evaluierte, ging das
> noch nicht.

Ja, ich glaub das war in der allerersten Version die sie veröffentlicht 
haben. Damals sagte ich noch wenn die das ernsthaft so lassen wollen 
kann mans auch komplett in der Pfeife rauchen. Da haben sie dann 
anschließend noch nachgebessert.

von Max G. (l0wside) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
C. W. schrieb:
> Ich werde jetzt mal hier und da ein paar kleinere Änderugnen an dem
> Projekt für mich im Chibistudio machen, aber die Endlösung wird es nicht
> werden. Es fühlt sich irgendwie nich gut an und ich habe kein Lust noch
> groß Aufwand für das Werkzeug zu betreiben.

Ich entwickle unter ChibiOS und verwende dazu Atollic, allerdings mit 
Makefile-Projekt.
Die automatische Auflösung der C-Namen ist etwas hakelig, da musste ich 
ziemlich von Hand nacharbeiten. Dafür lief der Debugger mehr oder 
weniger out-of-the-box.


Angenehm an ChibiOS finde ich die saubere Integration des HAL. Die Doku 
dagegen krankt an einem chronischen Mangel an Beispielen. Leider.

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
C. W. schrieb:
> Viel interessanter wäre welche IDE/Editor in der Lage ist während dem
> Schreiben das alles schon richtig aufzulösen um z.B. mit Rechtsklick und
> einer Auswahl zur entsprechenden Datei zu springen in der z.B. eine
> Funktion definiert wird.

Das Problem ist, dass deine IDE (egal welche) keine Chance hat alles 
aufzulösen, wenn sie keine Informationen über den Build-Vorgang hat. Das 
ist ja gerade das Ding bei diesen ganzen IDEs: Man gibt explizit jede 
Datei, jeden #define, etc. an und wenn man sein Projekt dann einmal 
gebaut hat, kann der Indexer daraus noch weitere Schlüsse ziehen, womit 
dann Autovervollständigung, Linting, etc. funktionieren. Bei den ganzen 
Eclipse-basierten IDEs funktioniert das dann leidlich gut, selbst bei 
Projekten wie ChibiOS, libopencm3 oder Nuttx, die alle mehrere 
Plattformen (und damit automatisch auch redundanten Code) in einem 
einzigen Repository haben. Wie das genau bei VisualGDB ist kann ich 
nicht sagen, da ich das noch nie benutzt habe.

Was VisualGDB ganz sicher nicht mitbringt sind die erwähnten Unixtools. 
Um die zu bekommen würde ich bei Win10 definitiv WSL installieren. 
Einfacher kann man als Windowsuser wirklich nicht an *nix-Werkzeuge 
kommen. Kannst du aber halten wie du willst.

Zurück zum eigentlichen Problem, dass die IDE den Code nicht zu 100% 
richtig "versteht". Man kann natürlich bei Eclipse (und vermutlich auch 
VisualGDB) jeden einzelnen #define von Hand einfügen aber das ist eine 
ziemliche Sisyphos-Arbeit. Es gibt aber zum Glück die Möglichkeit 
mittels einer "compilation database" alle Compileroptionen, incl. 
#defines, #includes, etc. zu exttahieren. Das klingt erstmal 
kompliziert, ist aber tatsächlich nur eine Textdatei, die JSON enthält 
(compile_commands.json). Mit Hilfe dieser JSON-Datei kann nun eine IDE 
optimal für Autovervollständigung, Linting, etc sorgen. IDEs die das 
unterstützen sind:
- QT Creator mit CompilationDatabaseProjectManager Plugin (mein 
persönlicher Favorit)
- VIM, Atom oder VS Code mit YouCompleteMe Plugin
- VS Code mit C/C++-Tools von MS
- vermutlich noch viele weitere, die ich nicht kenne. Vielleicht sogar 
VS?

Es gibt verschiedene Möglichkeiten an diese JSON-Datei zu kommen. Manche 
Build-Systeme, zum Beispiel CMake können die von sich aus erzeugen. Ist 
das nicht der Fall, zum Beispiel bei Make, gibt es Programme die den 
Build-Prozess belauschen und dadurch die Compileroptionen extrahieren. 
Ich benutze dafür scan-build (https://github.com/rizsotto/scan-build) 
weil das mittels pip sehr einfach zu installieren ist. Dann kann man 
mittels "intercept-build make" seine compilation database erstellen. 
scan-build baut auf "bear" (vom gleichen Autor) auf, um die compilation 
database zu erstellen, was man auch einzeln nutzen kann.
Hier hab ich auf die schnelle eine Seite mit einer guten Übersicht 
gefunden:
https://sarcasm.github.io/notes/dev/compilation-database.html

Ich hoffe mal, dass dich dieser Post nicht erschlägt. Im Grunde ist es 
alles recht einfach, wenn man es einmal verstanden hat.

In diesem Sinne:
> Sag mal, geht's noch?

Ja, geht alles bestens ;)

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Das Problem ist, dass deine IDE (egal welche) keine Chance hat alles
> aufzulösen, wenn sie keine Informationen über den Build-Vorgang hat.

Eclipse kann den Output des Buildvorgangs parsen. Es sieht jedes 
einzelne -I und jedes -D bei jedem Compileraufruf und weiß dann wo die 
Includes zu suchen sind und welche Symbole definiert sind. Wenn man 
diesen Modus in Eclipse aktiviert und dann einmal einen vollständigen 
Build startet konfiguriert sich Eclipse komplett selbst.

So kann man also hervorragend mit Makefile-Projekten arbeiten. Es gibt 
noch ein paar andere IDEs die können das ebenfalls, ich gehe sogar so 
weit daß ich jede C-IDE die das nicht kann als nicht auf dem aktuellen 
Stand der Technik befindlich betrachte und keine Zeit damit verschwende.

Alle meine eigenen Projekte sind IDE-agnostisch und werden mit 
Kommandozeilentools auf der Kommandozeile gebaut. Die IDE (egal welche) 
hat damit automatisch zurechtzukommen (die guten können das) oder sie 
ist für die Tonne.

: Bearbeitet durch User
von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Wenn man diesen Modus in Eclipse aktiviert und dann einmal einen
> vollständigen Build startet konfiguriert sich Eclipse komplett selbst.
> So kann man also hervorragend mit Makefile-Projekten arbeiten.

Ich sagte ja auch, dass man einigermaßen damit arbeiten kann. Leider ist 
Eclipse meiner Erfahrung nach nicht so optimal darin, wenn es um 
Namensauflösungen, etc. geht. Der Linter hat so oft Falschmeldungen 
fabriziert, dass ich ihn meistens einfach abgeschaltet habe aber ymmv.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Leider ist
> Eclipse meiner Erfahrung nach nicht so optimal darin, wenn es um
> Namensauflösungen, etc. geht.

Derartiges ist mir noch nicht aufgefallen, meine Erfahrung ist wenn 
nichts falsch konfiguriert ist und wenn etwas der Compiler findet dann 
findet Eclipse es auch.

Das Problem ist nur es gibt einige Sachen oder Einstellungen mit denen 
Eclipse sich dann wieder selbst sabotieren kann, das bekommt man erst in 
den Griff wenn man ein paar Jahre intensive Erfahrung mit den ganzen 
Zicken gemacht hat die es potentiell machen kann oder immer einen 
Eclipse-Guru in Rufweite hat, das ist auch mein Hauptkritikpunkt seit 
Ewigkeiten, das stecken auch noch ein paar Bugs drin um die sich einfach 
keiner kümmern will oder kann. Dennoch kenne ich leider keine andere 
freie C-IDE die so einen Leistungsumfang (insbesondere Codeverständnis) 
hat wie Eclipse.

So pflege also auch ich eine Haßliebe zu Eclipse seit viele Jahren, 
manchmal könnte auch ich es direkt aus dem Fenster katapultieren aber 
ich finde keinen vollwertigen Ersatz, irgendwas essentielles an das ich 
mich schon zu sehr gewöhnt habe um es ersatzlos aufzugeben fehlt immer.

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
Ich oute mich auch mal als QtCreator-Fan.

Durchaus auch mal ohne das CompilationDatabaseProjectManager Plugin.

Man muß dann eben die .includes und .config-Files parallel zum Makefile 
händisch pflegen. Bei nicht allzu grossen Projekten problemlos möglich 
und im Gegensatz zu Eclipse CDT leicht zu durchschauen, wie alles 
zusammenhängt.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Dennoch kenne ich leider keine andere
> freie C-IDE die so einen Leistungsumfang (insbesondere Codeverständnis)
> hat wie Eclipse.

Markus F. schrieb:
> Ich oute mich auch mal als QtCreator-Fan

Ich habe einen Bruder, der heißt Markus F. Aber wenn der inzwischen mit 
Elektronik bastelt wäre ich sehr überrascht.

Ich stelle mich auch auf deine Seite, oute mich ebenfalls. Für AVR nutze 
ich die Qt Creator IDE so: 
http://stefanfrings.de/avr_tools/index.html#qtcreator (wird bei STM32 
wohl ähnlich gehen).

: Bearbeitet durch User
von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Schau Dir mal Qt Creator an, dass eignet sich auch ganz gut für
> Mikrocontroller.

Hat es ein Plugin für J-Link Debugging und hat es ein Plugin um während 
des Debuggens alle Bits in allen Peripherie-Registern namentlich 
anzeigen oder verändern zu können? Dieses Feature ist zu mächtig, das 
will ich nicht aufgeben!

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> Man muß dann eben die .includes und .config-Files parallel zum Makefile
> händisch pflegen.

Das ist ein absolutes No-Go. Ich will die Konfigurationen nicht doppelt 
pflegen. Alle IDEs die nicht in der Lage sind die Konfiguration, die 
Defines und Includepfade aus einem Makefile-Projekt automatisch selbst 
zu ermitteln und automatisch aktuell zu halten scheiden schon in der 
ersten Runde aus.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Stefan ⛄ F. schrieb:
>> Schau Dir mal Qt Creator an, dass eignet sich auch ganz gut für
>> Mikrocontroller.
>
> Hat es ein Plugin für J-Link Debugging und hat es ein Plugin um während
> des Debuggens alle Bits in allen Peripherie-Registern namentlich
> anzeigen oder verändern zu können? Dieses Feature ist zu mächtig, das
> will ich nicht aufgeben!

Keine Ahnung, ich habe mit Qt Creator noch keine Mikrocontroller 
debuggt. Das scheint zumindest vorgesehen zu sein:
https://doc.qt.io/qtcreator/creator-developing-baremetal.html
https://electronics.stackexchange.com/questions/212018/debugging-an-arm-stm32-microcontroller-using-qt-creator

: Bearbeitet durch User
von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Das ist ein absolutes No-Go.

"Muß" war hier falsch gewählt. "Kann" wäre richtig gewesen. Mit dem 
Plugin geht's ja auch so.

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Hat es ein Plugin für J-Link Debugging

Es gibt kein dediziertes J-Link Plugin, sondern lediglich ein "Bare 
Metal"-Plugin. Damit kann man auch mit OpenOCD debuggen. Ob der J-Link 
GDB-Server explizit unterstützt wird weiß ich nicht genau.

Bernd K. schrieb:
> hat es ein Plugin um während des Debuggens alle Bits in allen
> Peripherie-Registern namentlich anzeigen oder verändern zu können?

Das gibt es so leider nicht. Wenn man mit -g3 kompiliert, kann man aber 
mit dem GDB auch Makros auflösen, d.h. man kann sich z.B. den Wert von 
TIM1->CNT anzeigen lassen. Das geht sogar von der Konsole aus. Leider 
ist das sehr friemelig, wenn man z.B. ein Statusregister ausliest, weil 
da eine Dezimalzahl nicht gerade aussagekräftig ist. Das ist aus meiner 
Sicht die größte Schwachstelle von QT Creator (neben dem nicht so tollen 
VIM-Modus).

von Max G. (l0wside) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Eclipse kann den Output des Buildvorgangs parsen. Es sieht jedes
> einzelne -I und jedes -D bei jedem Compileraufruf und weiß dann wo die
> Includes zu suchen sind und welche Symbole definiert sind. Wenn man
> diesen Modus in Eclipse aktiviert und dann einmal einen vollständigen
> Build startet konfiguriert sich Eclipse komplett selbst.

Wo ist dieser magische Schalter? Der würde mir einen Haufen graue Haare 
ersparen.

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
Max G. schrieb:
> Wo ist dieser magische Schalter? Der würde mir einen Haufen graue Haare
> ersparen.

Da schließe ich mich mal an. Den habe ich bisher auch noch nicht 
gefunden.

von Bernd K. (prof7bit)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Max G. schrieb:

> Wo ist dieser magische Schalter? Der würde mir einen Haufen graue Haare
> ersparen.

Da die Defaulteinstellung für cross-compiler unbrauchbar ist (regexp 
greift nicht) ist diese ganze Funktionalität in Embedded-Kreisen eher 
unbekannt. Es muss die Einstellung "Compiler Command Pattern" angepasst 
werden und sobald das geschehen ist fängt es auf magische Weise an zu 
funktionieren!

Die Ergebnisse kann man dann im Tab "Entries" auf der selben 
Einstellungsseite sehen nachdem ein vollständiger Build mal 
durchgelaufen ist. Die ganzen Sachen die man auf der Seite "Paths and 
Symbols" manuell eingetragen hat sollte man dann wieder alle entfernen.

--

Wichtig: Wenn man ein existierendes Makefileprojekt erneut importiert 
(zum Beispiel auf nem anderen Arbeitsplatz, "import existing project 
into workspace") dann muss man diese Einstellung erneut kontrollieren 
denn beim Importvorgang mach Eclipse diese Einstellung kaputt (seit 
Jahren schon gemeldeter Bug, passiert leider nichts). Die schnellste 
Methode nach dem Import ist: Frisch importiertes Projekt wieder 
schließen, git reset --hard, Projekt wieder öffnen. Das passiert nur 
beim Import, man muß es nur einmal machen, deshalb hält sich der Ärger 
in Grenzen, aber man muß halt nur darüber Bescheid wissen.

: Bearbeitet durch User
von Max G. (l0wside) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Da die Defaulteinstellung für cross-compiler unbrauchbar ist (regexp
> greift nicht) ist diese ganze Funktionalität in Embedded-Kreisen eher
> unbekannt. Es muss die Einstellung "Compiler Command Pattern" angepasst
> werden und sobald das geschehen ist fängt es auf magische Weise an zu
> funktionieren!

Eben getestet. Sollten wir uns mal begegnen, bin ich dir mindestens ein 
Bier schuldig. Seriously. Das war der beste Tipp seit langem. Danke!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.