STM32CubeIDE Projekt von SW4STM32 importieren

Werner Gast #7009629
Lesenswert?
• ▲
▼ 
Hallo,

ich habe ein Projekt für den STM32F030 aus der System Workbench for 
STM32 in STM32Ide importiert. Nachdem Erzeugen ist mir aufgefallen dass 
das Binary rund 4k größer ist also vorher mit der alten IDE. Also die 
Mapfiles vergleichen, da ist mir aufgefallen dass nun zahlreiche 
Einträge mit printf enthalten sind, z.B.

1
.text.fprintf  0x00000000080066c8       0x20 c:/st/stm32cubeide_1.7.0/stm32cubeide/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.0.202111181127/tools/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/lib/thumb/v6-m/nofp\libc_nano.a(lib_a-fprintf.o)

2
                0x00000000080066c8                fiprintf

3
                0x00000000080066c8                fprintf


Im alten Mapfile kommt printf kein einziges mal vor. Hat jemand eine 
Idee wie ich der STM32Ide sagen kann dass ich kein printf brauche? Wieso 
schmeißt das der Linker nicht (mehr) raus?

So sehen die Compileraufrufe aus:
1
-mcpu=cortex-m0 -std=c++20 -DNDEBUG -DUSE_HAL_DRIVER -DSTM32F030x8 -c  -Os -ffunction-sections -fdata-sections -fno-exceptions -fno-rtti -fno-threadsafe-statics -fno-use-cxa-atexit -Wall -fstack-usage --specs=nano.specs -mfloat-abi=soft -mthumb


Und er Linker:
1
-mcpu=cortex-m0 -T"LinkerScript.ld" --specs=nosys.specs -Wl,-Map="${BuildArtifactFileBaseName}.map" -Wl,--gc-sections -static --specs=nano.specs -mfloat-abi=soft -mthumb

Werner
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Werner Gast #7010021
Lesenswert?
• ▲
▼ 
Oh ja Vollstreffer!
Tatsächlich habe ich ganz viel mit printf im Mapfile gefunden, dann im 
Listfile nachgesehen wer das einfängt. printf wird von <__assert_func> 
aufgerufen, das wiederum von den Funktionen rand() und srand() die ich 
jeweils verwende. Das Präprozessorsymbol "NDEBUG" zu setzen brachte 
leider keine Abhilfe, vielleicht hat noch jemand eine Idee. Wichtig zu 
erwähnen ist noch dass rand() und srand() jeweils aus C++ Dateien 
aufgerufen werden, aber auch in den C++ Compilereinstellungen ist NDEBUG 
gesetzt.

Werner
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Niklas G. Persönliche Seite #7010094
Lesenswert?
• ▲
▼ 
Werner schrieb:
> printf wird von <__assert_func>
> aufgerufen, das wiederum von den Funktionen rand() und srand() die ich
> jeweils verwende. Das Präprozessorsymbol "NDEBUG" zu setzen brachte
> leider keine Abhilfe

Kein Wunder, diese Funktionen sind ja in der C-Library, welche ja schon 
vorkompiliert ist.

Es scheint als würde eine Debug-Version der Library genutzt. Du kannst 
__assert_func in deinem Code mit einem "Dummy" überschreiben (z.B. 
Endlosschleife), sodass wenigstens die Abhängigkeit zu printf gelöst 
wird:

1
void __attribute__((noreturn)) __assert_func (const char *file, int line, const char *func, const char *failedexpr)  {

2
  while (1) __asm__ volatile ("bkpt"); // Breakpoint im Debugger erzwingen

3
}


Oder du verwendest das C++11 random System, eventuell hat das keine 
Probleme mit assert:
https://en.cppreference.com/w/cpp/numeric/random
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Werner Gast #7011410
Lesenswert?
• ▲
▼ 
Danke Niklas, das hat's gebracht, nun ist printf draußen. Erklärung 
ergibt Sinn. Warum die STM32IDE nun die Debuglibs nimmt bleibt wohl 
offen.
Zur Vervollständigung: Wenn man das von C++ aus machen möchte muß noch 
ein extern "C" drumherum.

Gruß & nochmal Danke
Werner
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren