Trice Code Size Optimization

Contents

You can compile the complete src/*.c library instead of maintaining a list of individual files. With unused-section removal enabled, only the library functions and data needed by your application remain in the final executable or firmware image. Configuration already excludes many disabled features during preprocessing; the linker removes the remaining unreferenced sections. Compiling every source can still take longer than compiling a selected subset.

The PC example scripts enable this explicitly: -ffunction-sections -fdata-sections separates functions and data, then -Wl,--gc-sections removes unused sections with GCC/Clang on Linux and MinGW on Windows. On macOS they use -Wl,-dead_strip instead. For MSVC, use /Gy /Gw and /OPT:REF. Embedded examples use the corresponding section-removal settings in their build configuration. The minimal demos omit these optional flags to keep their build commands simple. Without these settings, compiling src/*.c alone does not guarantee that unused code disappears.

Search project and generated header directories first, then src, then src/default_conf last. The last directory supplies a fallback SEGGER_RTT_Conf.h, so PC demos need no additional RTT header or J-Link installation. A project-specific RTT header takes precedence and remains appropriate for boards that need different buffer sizes or locking. If RTT is enabled, Trice inherits the selected SEGGER buffer sizes and channel counts automatically; explicit TRICE_* overrides must still agree with them. See Trice over RTT.

1. Code Optimization -o3 or -oz (if supported)

For debugging it could be helpful to switch off code optimization what increases the code size. A good choice is -o1. See also TRICE_STACK_BUFFER could cause stack overflow with -o0 optimization.

2. Compiler Independent Setting (a bit outdated)

Maybe the following is a bit unhandy but it decreases the code amount, build time and the image size.

When having lots of program memory simply let all values be 1. With specific linker optimization unused functions can get stripped out automatically.

It is possible to #define TRICE_SINGLE_MAX_SIZE 12 for example in triceConfig.h. This automaticaly disables all Trice messages with payloads > 8 bytes (Trice size is 4 bytes).

3. Linker Option –split-sections (if supported)

In ARM-MDK uVision Project -> Options -> C/C++ -> "One EFL section for each function" allows good optimization and getting rid of unused code without additional linker optimization. This leads to a faster build process and is fine for most cases. It allows excluding unused functions.

4. Linker Optimization -flto (if supported)

4.1. ARMCC Compiler v5 Linker Feedback

4.3. GCC

With GCC use the -flto CLI switch directly.

4.4. LLVM ARM Clang

This compiler is much faster and creates the smallest images. Right now it uses the GCC libs and linker.

4.5. Other IDE´s and compilers

Please check the manuals and create a pull request or simply let me know.

5. Legacy STM32F030 Example Project - Different Build Sizes

5.1. ARMCC compiler v5

Compiler Linker Result Comment
o0   Code=46942 RO-data=266 RW-data=176 ZI-data=4896 very big
o1   Code=22582 RO-data=258 RW-data=168 ZI-data=4896  
o3   Code=21646 RO-data=258 RW-data=168 ZI-data=4896  
o0 split sections Code= 7880 RO-data=268 RW-data=156 ZI-data=4892 for debugging
o1 split sections Code= 5404 RO-data=260 RW-data=148 ZI-data=4892 for debugging
o3 split sections Code= 4996 RO-data=260 RW-data=148 ZI-data=4892 good balance
o0 flto Code= 8150 RO-data=266 RW-data=176 ZI-data=4896 builds slower
o1 flto Code= 5210 RO-data=258 RW-data=148 ZI-data=4892 builds slower
o3 flto Code= 4818 RO-data=258 RW-data=148 ZI-data=4892 builds slower, smallest image

(back to top)