Large compiled application size, is this normal?

[Scott Dev]

Posted on February 18, 2017 at 08:47

Hi

  I am just a beginner in the STM32, I have been designing for 8bit Freescale parts for years. I am using ST's Nuleo64 STM32L07 processor.

 Using STM32CubeMX I designed a very simple application that simply captures the system timer, GPIO interupt for the push button. I simply wrote some code (just for me getting used to the system) using Keil V5. I simply use the system timer interupt to blink the LED, pressing the button changes the speed of the LED . Within Cubemx I also selected RTC,LPUART but done nothing with the code yet. After building the application and ran it I noticed that the size of the code is 6420, and ram 1176. To me this seams a lot for what it does, I am used of having more tighter code. The application uses HAL library, does this put a large overhead to the size of code and ram used? And am I better stripping out some of the code that CubeMX creates?

Thanks

Scott

[Tesla DeLorean]

Posted on February 18, 2017 at 14:02

One potential issue is the USART code might be pulling in the floating point math library.

[Scott Dev]

Posted on February 18, 2017 at 17:30

Why would the floating point library be pulled in for the USART? All it does is transmit and receives bytes of data , no floating point calculations being caried out.

Scott

[S.Ma]

Posted on February 18, 2017 at 18:18

Clive already reported this part in December. It is a piece of code used to calculate the bitrate fractional divider from SYSCLK. Want to confirm it? Generate the MAP file from the linker project option and check if a float ansi lib has been pulled in the memory space. Easy check.

[AvaTar]

Posted on February 18, 2017 at 19:23

I don't use Cube, for good reasons - like this. But I can imagine that it foolishly uses floating point constants in peprocessor definitions.

An experienced developer should know that. (To be clear, I mean ST's Cube developers ...)

[Tesla DeLorean]

Posted on February 18, 2017 at 22:45

No I think there is purposeful casting of the maths related to the clock speed vs baud rate so it doesn't exceed scope. I would have done this with integer maths. All maths on the Cortex-M0 tends to be more library dependent given the core lacking key features. The incremental costs once you've got some base libraries pulled in is going to be more manageable.

The .MAP file should provide some understanding about where the bytes are getting eaten.

[AVI-crak]

Posted on February 19, 2017 at 11:39

Use of standard functions (printf type) - pulls for itself a code from the libraries hidden for the user which are a part of ID (Keil V5).

It is a part of standard functions of the SI language, but their implementation for all occasions. Bonuses aren't disconnected.

Option of the small size of a code - own functions of a data output.

In addition: study documentation on the chip - it is the first stage.

[Scott Dev]

Posted on February 19, 2017 at 12:16

Thanks for the reply. I will look at Clive's posts, I am also new to this forum. I am moving away from a Freescale processor, and just getting used to the whole system. Still working out whether its better to use CubeMX or not.

Scott

[Scott Dev]

Posted on February 19, 2017 at 12:19

Thanks for your reply. I am new to the ST system, and still working my way around it, and have been wondering if it is better using Cube or not. I am thinking that if it does things like that , then I will not bother. But it is a good tool to get used to the processor. I am an experiance developer (over 20 years), but just getting into the ST .

Scott

[Scott Dev]

Posted on February 19, 2017 at 12:26

In the past I have always written my own code instead of printf etc. on other proecssors, as found it to be too much of a big overhead. For my applications, creating a few buffers for sending and recieving data within interupts is all I need (along with house keeping), and doesnt make much of a dent in program size.

Scott