2021-12-02 01:40 AM
I am currently working on the STM35U5 family using STM32CubeMX, and I see that none of the code generated is using the standard libraries.
Why is that? Should I avoid using standard libraries in my application code ?
Solved! Go to Solution.
2021-12-02 03:38 AM
Which standard libraries do you mean?
Standard libraries were written with the assumption of a large computer and things like file-systems, console I/O. And probably an operator on-hand to get things going again if/when they fail.
Even with a "clever" linker, they use a lot of memory; not so much of a problem on stm32u5, but prohibitive on some of the smaller stm32l0
Unless Stm32CubeMx needs what a specific standard library was written to provide (e.g. string-handling, file I/O) then there's no point having it.
One specific point for embedded system programming, many people do not like dynamic memory allocation (malloc & free; new & delete) and instead prefer to statically allocate every variable that will be needed (except those on the stack). This avoids the risk of running-out-of-memory at run-time, either because of too much instantaneous demand for variables or that memory has become fragmented over the run.
And C string handling needs care to prevent buffer overruns - original K&R C libraries were not written with such risks foremost in the programmers' minds.
As long as you know and understand the risks, you are the skilled engineer best-placed to decide which libraries to use with your code.
Hope this helps,
Danish
2021-12-02 03:38 AM
Which standard libraries do you mean?
Standard libraries were written with the assumption of a large computer and things like file-systems, console I/O. And probably an operator on-hand to get things going again if/when they fail.
Even with a "clever" linker, they use a lot of memory; not so much of a problem on stm32u5, but prohibitive on some of the smaller stm32l0
Unless Stm32CubeMx needs what a specific standard library was written to provide (e.g. string-handling, file I/O) then there's no point having it.
One specific point for embedded system programming, many people do not like dynamic memory allocation (malloc & free; new & delete) and instead prefer to statically allocate every variable that will be needed (except those on the stack). This avoids the risk of running-out-of-memory at run-time, either because of too much instantaneous demand for variables or that memory has become fragmented over the run.
And C string handling needs care to prevent buffer overruns - original K&R C libraries were not written with such risks foremost in the programmers' minds.
As long as you know and understand the risks, you are the skilled engineer best-placed to decide which libraries to use with your code.
Hope this helps,
Danish