STM32CubeIDE Projekt von SW4STM32 importieren

[Werner (Gast)]

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.

.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)
                0x00000000080066c8                fiprintf
                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:

-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:

-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

[pegel (Gast)]

https://stackoverflow.com/questions/39858015/stm32-gcc-arm-none-eabi-gcc-links-printf-even-though-it-is-not-used

Vielleicht hilft das Kleingedruckte ganz unten vor "Your Answer", vom 
Oct 5, 2016 at 11:27

[Werner (Gast)]

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

[pegel (Gast)]

https://stackoverflow.com/questions/5354314/how-can-i-completely-disable-calls-to-assert

[Niklas G. (erlkoenig)]

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:

void __attribute__((noreturn)) __assert_func (const char *file, int line, const char *func, const char *failedexpr)  {
  while (1) __asm__ volatile ("bkpt"); // Breakpoint im Debugger erzwingen
}

Oder du verwendest das C++11 random System, eventuell hat das keine 
Probleme mit assert:
https://en.cppreference.com/w/cpp/numeric/random

[Werner (Gast)]

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