|
Anzeige
|
g++ statt gcc
Gast
#4595628
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. 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).
Gast
#4595653
Zeig mal deine .bin Datei. 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.
Gast
#4595663
Hier ist die .bin im Anhang. Debugged habe ich noch nicht, mich aber auch noch gar nicht mit dem Thema beschäftigt.
Gast
#4595669
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. Hey danke dir! Wie konntest du das anhand der .bin feststellen? Das Projekt habe ich mal in den Anhang gepackt.
Gast
#4595711
Äh vergiss das mit dem CCM, ich hab mich vertan. Das
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. 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. 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.
Gast
#4596519
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... 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.
Gast
#4612594
>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? 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.
Gast
#4612640
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
Gast
#4612832
Danke. Es reicht also aus den startup-part zu ersetzen? Sonst muss nichts geändert werden (abgesehen vom makefile)?
Gast
#4613897
Startup + extern "C" { ... } um alle .c Dateien (stlib, etc.).
Gast
#4613904
Antwort schreiben |
Anzeige
|
