keil uvision vs stm32 cube output file size

[kgavionics]

Hello
I usally, use keil uvsion for my stm32 projects and I wanted to try stm32 cube, so I build the same project with the same compiler and level of optimization (-O1), but I was surprised that the stm32cube binary output file is almost 3 times bigger than the keil uvision ! Is there something I'm missing ?
TIA

[DavidAlfa]

Try 0s. Are you sure Keil uses O1?
What's the true bin files sizes?

[nctnico]

Check the map file. Likely it is the size of the libraries and not the code itself.

[kgavionics]

Try 0s. What optimization is applied in Keil?

Same thing

[kgavionics]

Check the map file. Likely it is the size of the libraries and not the code itself.

Is there any settings in Cube to show the actual code size?

[SiliconWizard]

Considering that the compiler used by Keil (from the hints in your µVision console output) is 'V6.19' and placed in a directory called 'ARMCLANG', your assertion that this is the same compiler is pretty dubious.
I'm not a Keil user, but I would have doubts here. The compiler used by STM32Cube is just a recent version of GCC.
So, first thought is that it is *probably* not the same compiler, and thus comparing optimization levels and resulting code size does not make a lot of sense.
Of course, if someone can convince me that this is actually the same compiler in both cases (and in particular that what Keil calls 'ARMCLANG' is actually GCC), you can ignore this point. Although I have personally no recollection of a 6.19 version of GCC, so...

Beyond the compiler, another possible factor is the linker stage - it is possible for instance that Keil's linker discard unsused code, while the GCC/ld options in STM32Cube do not do that.

[tru]

Erm, I think you have that backwards, STM32Cube (GCC) produced the smaller size.  Typically, the sections text (program code) and data (initialized variables) occupy flash:

STM32Cube (GCC) text + data:
3964 + 92 = 4056 bytes

ARMCLANG code + RO-data
6822 + 630 = 7452 bytes

[kgavionics]

Considering that the compiler used by Keil (from the hints in your µVision console output) is 'V6.19' and placed in a directory called 'ARMCLANG', your assertion that this is the same compiler is pretty dubious.
I'm not a Keil user, but I would have doubts here. The compiler used by STM32Cube is just a recent version of GCC.
So, first thought is that it is *probably* not the same compiler, and thus comparing optimization levels and resulting code size does not make a lot of sense.
Of course, if someone can convince me that this is actually the same compiler in both cases (and in particular that what Keil calls 'ARMCLANG' is actually GCC), you can ignore this point. Although I have personally no recollection of a 6.19 version of GCC, so...

Beyond the compiler, another possible factor is the linker stage - it is possible for instance that Keil's linker discard unsused code, while the GCC/ld options in STM32Cube do not do that.

I assumed that both compiler are the same, because both have   "arm-none-eabi" in the output window, but I think you are right Keil uses ARMCC and STM32 is using GCC.

[Tation]

Since 1.5 or 2 years ago, Keil only uses the ARMCLANG compiler (compiler 6 in arm parlance, which is based on clang). Before that, Keil offered both ARMCLANG and ARMCC (compiler 5 in arm lingo, based on gcc). ARMCC in now deprecated.

I'm still confused about the screen capture of the Cube. The .text and .data sections reported, are for the whole app or only for the snprintf module? On the same screenshot, the used Flash is 16.88 KB, much bigger than .text+.data. I do know that the Keil reported sizes are for the whole app.

In my experience, ARMCLANG uses to do a better job generating smaller executables than ARMCC. In fact I spent some weeks (about 2 years ago) porting many in-house programs to ARMCLANG because of that. In turn, my experience using gcc with arm always resulted in bigger Flash consumption, although my experience with gcc on arm is not big.

[SiliconWizard]

Erm, I think you have that backwards, STM32Cube (GCC) produced the smaller size.  Typically, the sections text (program code) and data (initialized variables) occupy flash:

STM32Cube (GCC) text + data:
3964 + 92 = 4056 bytes

ARMCLANG code + RO-data
6822 + 630 = 7452 bytes

Indeed, I had just considered what the OP said about the size, but from the compiler outputs, it looks like ARMCLANG produces smaller code. But what got the OP confused is that STM32Cube still shows 16.88KB Flash "used" (in the bottom right pane) while the code size GCC produces is actually smaller. Indeed it should only take about 4KB in Flash (code + data section). I don't know where the remaining 12KB come from. If anyone's more familiar with STM32Cube. Maybe it includes some custom bootloader?

[kgavionics]

Erm, I think you have that backwards, STM32Cube (GCC) produced the smaller size.  Typically, the sections text (program code) and data (initialized variables) occupy flash:

STM32Cube (GCC) text + data:
3964 + 92 = 4056 bytes

ARMCLANG code + RO-data
6822 + 630 = 7452 bytes

Indeed, I had just considered what the OP said about the size, but from the compiler outputs, it looks like ARMCLANG produces smaller code. But what got the OP confused is that STM32Cube still shows 16.88KB Flash "used" (in the bottom right pane) while the code size GCC produces is actually smaller. Indeed it should only take about 4KB in Flash (code + data section). I don't know where the remaining 12KB come from. If anyone's more familiar with STM32Cube. Maybe it includes some custom bootloader?

what I did, I removed the project and started from the scratch and now the size text size matches the build analyzer output (see screenshot below…)

[DavidAlfa]

Ahh the classic cubeide bug.
Sometimes the build tab doesn't refresh, you must right click over the project->Refresh, or clock build 1-2 more times.