g++ statt gcc

[sonstimmerc (Gast)]

Guten Morgen,

ich versuche gerade den g++ statt den gcc zu benutzen.
Kompilieren kann ich das Project weiterhin, flashen ebenso.
Auf dem stm32 läuft es aber dann einfach nicht an.

Ist möglicherweise mein Makefile falsch? Mit dem gcc und den CFLAGS 
läuft es einwandfrei.

Die Flags kommen von: https://www.mikrocontroller.net/articles/ARM_GCC

Beste Grüße.

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

sonstimmerc schrieb:
> Ist möglicherweise mein Makefile falsch? Mit dem gcc und den CFLAGS
> läuft es einwandfrei.

Hast Du mal einen Debugger ran gehalten? Wahrscheinlich liegt das 
Problem im Startup-Code. Die meisten IC-Hersteller liefern Startup-Code, 
der nicht so ganz gut mit C++ um kann (z.B. keine globalen Objekte 
initialisiert).

[Dr. Sommer (Gast)]

Zeig mal deine .bin Datei.

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Was auch sein kann, ist dass Du Deine Interrupt handler nicht mit extern 
"C" deklariert hast und der Linker sie deshalb nicht in die Vector table 
eingetragen hat.

[sonstimmerc (Gast)]

Hier ist die .bin im Anhang.
Debugged habe ich noch nicht, mich aber auch noch gar nicht mit dem 
Thema beschäftigt.

[Dr. Sommer (Gast)]

Der ISR-Vektor sieht ok aus. Dein initialier Stack Pointer zeigt aber in 
den CCM, wird der in deinem Startupcode aktiviert? Wenn nicht, stürzt 
der Controller beim Sprung in die main() ab. Zeig mal dein ganzes 
Projekt, inklusive .elf Datei.

[Drimer M. (qinomo)]

Hey danke dir!
Wie konntest du das anhand der .bin feststellen?

Das Projekt habe ich mal in den Anhang gepackt.

[Dr. Sommer (Gast)]

Äh vergiss das mit dem CCM, ich hab mich vertan.
Das

#define USE_FULL_ASSERT    1

bringt gar nix, das muss in die stm32f4xx_conf.h .

Aber sonst seh ich grad kein Problem. Benutze mal den Debugger um 
festzustellen wo es stecken bleibt.

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Die HA-Library arbeitet auch mit callbacks, bei denen die Library C 
binding erwartet. An Deiner Stelle würde ich die C-Files von ST mit 
einem C compiler übersetzen und nur echte C++ sourcen dann mit dem C++ 
compiler.

[Vincent H. (vinci)]

Torsten R. schrieb:
> Was auch sein kann, ist dass Du Deine Interrupt handler nicht mit extern
> "C" deklariert hast und der Linker sie deshalb nicht in die Vector table
> eingetragen hat.


Das kann nicht nur sein, das ist so. Ein C++ Compiler muss laut Standard 
als C++ deklarierte Funktionen name-mangeln. Ohne also via "extern C" 
ein linkbares Interface zu erzeugen werden sämtliche Interrupts 
vermutlich schlichtweg wegoptimiert und die leeren .weak 
Implementierungen aus dem Startup-Code herangezogen.

Soll heißen keine einzige von deinen Delay Funktionen usw. wird mehr 
funktionieren... Geschweigedenn von dem HAL-internen Zeug.

[Dr. Sommer (Gast)]

Torsten R. schrieb:
> Die HA-Library arbeitet auch mit callbacks, bei denen die Library
> C
> binding erwartet.
Wenn der "g++" aber eine .c Datei sieht, kompiliert er die als "C". Es 
tritt hier also kein Problem auf. Dennoch würde ich die .c Dateien 
lieber mit "gcc" kompilieren...

[Rolf M. (rmagnus)]

Dr. Sommer schrieb:
> Wenn der "g++" aber eine .c Datei sieht, kompiliert er die als "C".

Nein. Nur gcc sucht sich aus dem Dateinamen den Typ. g++ übersetzt es 
immer als C++, wenn man nicht explizit mit -x was anders angibt.

Vincent H. schrieb:
> Ein C++ Compiler muss laut Standard als C++ deklarierte Funktionen name-
> mangeln.

Hast du mal ein Zitat von der Stelle, die name-mangling vorschreibt? Mir 
wäre sowas nicht bekannt.

[Tiiiim (Gast)]

>Das kann nicht nur sein, das ist so. Ein C++ Compiler muss laut Standard
>als C++ deklarierte Funktionen name-mangeln. Ohne also via "extern C"
>ein linkbares Interface zu erzeugen werden sämtliche Interrupts
>vermutlich schlichtweg wegoptimiert und die leeren .weak
>Implementierungen aus dem Startup-Code herangezogen.

Ich stehe vor einem ähnlichen Problem (nutze auch die STLib). Wohin 
genau kommt das extern C?

[The D. (thedaz)]

Tiiiim schrieb:
>>Das kann nicht nur sein, das ist so. Ein C++ Compiler muss laut Standard
>>als C++ deklarierte Funktionen name-mangeln. Ohne also via "extern C"
>>ein linkbares Interface zu erzeugen werden sämtliche Interrupts
>>vermutlich schlichtweg wegoptimiert und die leeren .weak
>>Implementierungen aus dem Startup-Code herangezogen.
>
> Ich stehe vor einem ähnlichen Problem (nutze auch die STLib). Wohin
> genau kommt das extern C?

Vor den return type des function headers bzw vor ein Blockklammerpaar.

[Dieter Gräf (Gast)]

Schau mal in diesen Startup code . Mbed ist c++.
https://github.com/mbedmicro/mbed/blob/master/hal/targets/cmsis/TARGET_STM/TARGET_STM32F4/TARGET_MTS_MDOT_F411RE/TOOLCHAIN_GCC_ARM/startup_stm32f411xe.S

m.f.G.
Dieter Gräf

[Tiiiim (Gast)]

Danke.

Es reicht also aus den startup-part zu ersetzen? Sonst muss nichts 
geändert werden (abgesehen vom makefile)?

[g++iscool (Gast)]

Startup + extern "C" { ... } um alle .c Dateien (stlib, etc.).

[Kaj (Gast)]

// my_c_file.c/my_c_file.h

#ifdef __cplusplus
extern "C" {
#endif


// place your c-code here



#ifdef __cplusplus
}
#endif