HAL_RCC_OscConfig function takes too much space

[Erkan Ersoy]

Posted on November 15, 2017 at 11:09

Hello 

After I face some fitting to flash problem I saw my largest function is HAL_RCC_OscConfig.

I thouht a function that writes static variables to registers should be smaller. Am I doing something wrong or is there a setting for it?

I am using GCC 6_2017q2 with System workbench

#program-size #hal #flash #cube-hal

[waclawek.jan]

Posted on November 15, 2017 at 11:15

Cube is aimed at being versatile, which is quite the opposite of optimal. That routine includes setting every oscillator type, even if you don't need it.

Write your own if you want it slimmer.

JW

[AvaTar]

Posted on November 15, 2017 at 12:09

Or, you could try to step up compiler optimization levels.

Levels greater than 0 use to drop code that never gets executed.

But that might bring up other issues ...

[waclawek.jan]

Posted on November 15, 2017 at 13:10

It's in a different file than from where it is called, so only link-time optimization could remove unused code.

JW

[Erkan Ersoy]

Posted on November 15, 2017 at 14:07

I've already set optimization to size (-Os).

[AvaTar]

Posted on November 15, 2017 at 14:08

Not sure what you mean.

The library stuff is supposedly C source, and built with application (not a link library). Or not ?

So, a decent optimizing compiler might throw out unused code.

Not sure how those Cube library sources behave with high optimization settings, removing unwanted code seems safer to me.

However, the HAL_RCC_OscConfig just consumes the largest chunk of the functions shown.

In absolute terms, it seems not that outstanding to me.

I suggest a broader view of allocated ressources.

HAL_RCC_OscConfig clearly consumes more than necessary, but if you are already having trouble right now, there is much more to come.

Projects tend to grow, rather than shrink ...

[Erkan Ersoy]

Posted on November 15, 2017 at 14:11

I enabled 'place the function in their own section '

and 'place the data in their own section ' and it make some difference in code size.

If I face flash overlow again I think I am gonna write my own clock setup code. 

I want to try using Low Layer library also.

[AvaTar]

Posted on November 15, 2017 at 14:11

I don't know the code of this function, but depending on it's implementation and the compiler's capabilities, he might not be able to optimize it out.

You would need to lay your hands on the sources, then.

[waclawek.jan]

Posted on November 15, 2017 at 14:39

Not sure what you mean.

The library stuff is supposedly C source, and built with application (not a link library). Or not ?

HAL_RCC_OscConfig() is one lengthy function, configuring all sorts of oscillators, and the OP might not need that.The compiler can't remove unused parts, as their usage is given by parameters to that function, and it is called from outside the compilation unit (file). Thus, only on link time could the 'unusedness' of certain parts be revealed.

There may be translators out there which perform this seamlessly;gcc needs to be configured for link-time-optimization (LTO). I don't use it and don't know if it went already from experimental to production status.

Also, as a separate problem, HAL_RCC_OscConfig(), in various branches, works on various fields of the same few registers, so if there is genuine need for configuring several clock sources, it is performed in separate steps. As those registers are volatile, that can't be optimized by the compiler (nor linker), but can be optimized by user.

JW

[AvaTar]

Posted on November 15, 2017 at 15:01

HAL_RCC_OscConfig() is one lengthy function, configuring all sorts of oscillators, and the OP might not need that.The compiler can't remove unused parts, as their usage is given by parameters to that function, and it is called from outside the compilation unit (file). Thus, only on link time could the 'unusedness' of certain parts be revealed.

I expected that, the SPL clock setup was similar. An in this case, link time optimization usually has no effect.

However, I avoid looking at Cube code if possible ...