Code Optimization

[vbk22398]

Hi, I am using 3 different STM32MCU's for our various projects, which include STM32F423, STM32L496, STM32F407 etc., I am using HAL Layers for this code in general. Now I need to create HAL Layers for these boards only, and I need to reduce the overheads caused by generic HAL code generated by cube ide. Suggest me some solutions.! what is the efficient and quick way to do this. Register level code is too much time consuming and very error prone and at the same time, I need to balance this for overheads also. Kindly help!

[Andrew Neil]

---

@vbk22398 wrote:

 I need to reduce the overheads caused by generic HAL code generated by cube ide. 

---

What "overheads", exactly, are you seeing?

• Too much code space consumed?
• Too much execution time consumed?
• other?

What compiler optimisation level are you currently using?

[SofLit]

Hello,

---

@vbk22398 wrote:

I need to reduce the overheads caused by generic HAL code generated by cube ide. Suggest me some solutions.! 

---

May be using LL (Low Layer driver)? But not all peripherals have LL driver. Need to check the HAL folder of your product.

From development timing constraint, it will be time consuming.. maybe less than recreating the wheel by performing your own register access ..

[vbk22398]

Yeah it is code space and execution time! 

[TDK]

You can reduce code size by selecting the Release configuration, which will also speed up the code. That's your only option.

HAL should take up a small minority of the FLASH for those chips.

[AScha.3]

Hi,

make a new project, only with clock tree and init for the hardware, you use;

but without USB, FAT etc. , to see, how much space HAL needing. (- without USB stack, fatfs etc.- this is not "HAL")

On a G474 it needs about 3,34 KB (0,65 %) of the 512KB flash ( with -O2).

If you think, this is a waste of memory...write the cpu init yourself - and be happy (or not..) .

+

Debug or Release changes nothing about code size, except you set different optimizer for each.

(Just "release" or "run"  dont start the debugger, after flashing the cpu.)

If you want the smallest code possible, use -Os (size optimized).

And the not used HAL libs anyway are never linked to the program, so no need to think about.

(Except you work on a cpu with 16KB flash - but this is another problem, if 50ct more for the cpu are important.)

[Andrew Neil]

---

@TDK wrote:

That's your only option.

---

There are opportunities to optimise the HAL stuff; eg, consider the HAL_UART_Transmit/Receive_ functions:

At runtime, every single call to HAL_UART_Transmit/Receive_ checks the config to see if it's in 9-bit mode:

https://community.st.com/t5/stm32-mcus-products/stm32-uart-using-interrupt-transmitts-by-byte-or-data-elements/m-p/723323/highlight/true#M261621

If you never use 9-bit mode, you could remove all those tests.

That (among other things) might well give a useful speed-up in UART performance.

On these chips, unlikely to give a significant reduction in code size, though.

@vbk22398 that's why I asked. "What 'overheads', exactly, are you seeing?"

Have you done any analysis to find specifically what bloat and/or bottlenecks you have? Or is this just some general nothing that HAL code must be slow & bloated?

You really need to quantify this first to determine whether the effort is actually worth it.