StdPeriph Library code overhead

ivan239955_stm1_stmicro_com · ‎2010-07-07

Posted on July 07, 2010 at 21:54

swhite2 · ‎2011-05-17

Posted on May 17, 2011 at 13:57

This is a ''how long is a piece of string'' question.

Generally you can expect the library to generate more code than direct accesses but you have to weigh that against readability and development time. That's a judgment call only you can make.

It just so happens I updated to v3.3.0 of the library today and have been looking at the code size. Here's the linker info for a (Release vs Debug) medium-density library build.

STM32F10x_StdPeriph_Driver_md_rel.a: [3]

core_cm3.o 16

misc.o 148

startup_stm32f10x_md.o 356

stm32f10x_adc.o 328

stm32f10x_bkp.o 64

stm32f10x_crc.o 44

stm32f10x_dbgmcu.o 48

stm32f10x_dma.o 352

stm32f10x_exti.o 174

stm32f10x_flash.o 786

stm32f10x_gpio.o 392

stm32f10x_iwdg.o 56

stm32f10x_pwr.o 44

stm32f10x_rcc.o 660 14 20

stm32f10x_rtc.o 198

stm32f10x_spi.o 118

stm32f10x_tim.o 1 270

stm32f10x_usart.o 306

-------------------------------------------------

Total: 5 360 14 20

Note that the since the linker only includes what it needs the above sizes are not for all functions just the ones I used. That said it gives you an idea.

Andrew Neil · ‎2011-05-17

Posted on May 17, 2011 at 13:57

''I don't want to inspect a compiled code in assembler as I don't know it.''

But, if this really matters to you, that is exactly what you need to do!

On the other hand, if you just want a general idea, then you can just look at the source code.

Probably the best approach is to start by using the library for ease/speed of development:

if this gives you no problems of size or performance, then you have no worries!
if you do end up with problems, then you need to look at your application as a whole - there's no point micro-managing the peripherals if the real bloat and/or bottlenecks are in your own code!

From: dolezal.ivan

Posted: Wednesday, July 07, 2010 9:54 PM

Subject: StdPeriph Library code overhead

Does anybody know how much is, in general, STM Standard Peripheral Library V3.x code overhead in comparison with a direct access to STM32 registers?

I don't want to inspect a compiled code in assembler as I don't know it.

There are 2 parts of code: inside functions and function calls.

I suppose that the library functions could not be set explicitly as INLINE due to 'assert_param' mechanism.

What influence has optimization settings in IAR's EWARM V5.x?

damh · ‎2011-05-17

Posted on May 17, 2011 at 13:57

Every function call and return consumes 5 cycles (10 cycles overhead per call => 1,25µs at 8MHz).

Most functions like GPIO_Init are designed for extrem dumb users. This function has an overhead factor aroud 200 (one call can cost around 50µs at 8MHz).

Conclusion:

The library is usable to test features. In many cases you have to read the manuals anyway, because the documentation of the library is too vague and does NOT even mention the contraints of functions.

It is not adequat to fast and efficient programs.

A good combination for us is at the moment:

1. write the initialisation with the stm library

2. dump the configuration

3. write the initialisation in assembler writing back the dumpped values (2-3 stores of 32 bit values per GPIO instead of 400 cycles per call to GPIO_Init (worst case 6400 cycles ;) ))

ivan239955_stm1_stmicro_com · ‎2011-05-17

Posted on May 17, 2011 at 13:57

Thank you, damh, for valuable information.

Peripheral handling consists of setting various registers with appropriate values which I can also do in C, I suppose.

I made decision to let doing an initialization by the library functions but to use direct register access in critical sections like interrupt handlers.

So for GPIO I use macros like that:

#define SETPIN(port,pin) (port->BSRR = pin)