Save about 2K flash space by upgrade gcc to 8.3.1

[smaller09]

/home/jackie/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/8.3.1-2019q3/bin/arm-none-eabi-size -A /tmp/arduino_build_39365/Multiprotocol.ino.elf Sketch uses 116712 bytes (96%) of program storage space. Maximum is 120808 bytes. Global variables use 4240 bytes (20%) of dynamic memory, leaving 16240 bytes for local variables. Maximum is 20480 bytes.

/home/jackie/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-size -A /tmp/arduino_build_454380/Multiprotocol.ino.elf Sketch uses 118916 bytes (98%) of program storage space. Maximum is 120808 bytes. Global variables use 4200 bytes (20%) of dynamic memory, leaving 16280 bytes for local variables. Maximum is 20480 bytes.

[pascallanger]

@benlye Is this something you can look into? I kind of remeber we tried something like this in the past but there was issues but may be it was on something else I'm not sure anymore...

[benlye]

Sure, I can look into it.

I think the main reason we've stuck with the current toolchain is the bad experience from a few years ago when an upstream core change introduced a bug which caused communication glitches and crashed models. Since then we've been very cautious about this kind of change, I guess because it's hard to do large-scale real-world testing.

That said, we should be able to change the compiler without touching the core.

I'll take a look as soon as I can, but I can't commit to a timeframe due to current day-job commitments.

[smaller09]

gcc will complain about duplicate inline. what I have done was just remove that inlines just like https://github.com/rogerclarkmelbourne/Arduino_STM32/pull/551

[benlye]

@smaller09 what made you pick that specific version of the compiler? Also, how did you install it? Did it come with another board/package or did you install it manually?

I'm trying to find a pre-packaged toolchain I can leverage quickly. But it seems like most packages are still using 4.8.3, like we are.

Otherwise, we could switch to the xpack compiler distributions, like STM32 has.

[benlye]

gcc will complain about duplicate inline. what I have done was just remove that inlines just like https://github.com/rogerclarkmelbourne/Arduino_STM32/pull/551

Can you explain how you removed the inlines? If your code is not actually inlining the functions as intended then that may be why your compiled image is smaller...

[smaller09]

STM32F1/system/libmaple/include/libmaple/nvic.h 

@@ -109,14 +109,14 @@ void nvic_sys_reset();
/**
 * Enables interrupts and configurable fault handlers (clear PRIMASK).
 */
-static inline __always_inline void nvic_globalirq_enable() {
+static __always_inline void nvic_globalirq_enable() {
    asm volatile("cpsie i");
}

/**
 * Disable interrupts and configurable fault handlers (set PRIMASK).
 */
-static inline __always_inline void nvic_globalirq_disable() {
+static __always_inline void nvic_globalirq_disable() {
    asm volatile("cpsid i");
}

that's what i have done. there are several .h file has inline follow by __always_inline. that's why gcc complain about.

They are different compiler directives. I would assume that whoever wrote each part of the code would be making a decision whether they want to inline always or only inline when the compiler thinks it's a good idea. I think it's better to respect the original author's decision to force an inline with __always_inline rather than changing them all to optional inlines.

as for the compiler chosen. that was controled by package_multi_4in1_board_index.json.

      {
        "name": "MULTI-Module STM32 Boards",
        "architecture": "STM32F1",
        "version": "1.2.2",
        "category": "Contributed",
        "help": {
          "online": "https://github.com/pascallanger/DIY-Multiprotocol-TX-Module"
        },
        "url": "https://github.com/pascallanger/DIY-Multiprotocol-TX-Module-Boards/raw/master/archives/package_multi_4in1_stm32_board_v1.2.2.tar.gz",
        "archiveFileName": "package_multi_4in1_stm32_board_v1.2.2.tar.gz",
        "checksum": "SHA-256:0fe4a8899438bbc31dc37714acca13968e43d75a47e59143343d83b634d2e47d",
        "size": "7485662",
        "boards": [
          {"name": "Multi X-in-1 STM32F103CB (128KB)"},
          {"name": "Multi X-in-1 STM32F103C8 (64KB)"},
          {"name": "Multi 5-in-1 (Jumper T18 Internal)"}
        ],
        "toolsDependencies": [{
          "packager": "arduino",
          "name": "arm-none-eabi-gcc",
          "version": "8.3.1-2019q3"
        }]
      },

and then you can ln -s another arm-none-eabi-gcc to the right place.

jackie@PC:~/.arduino15/packages/arduino/tools/arm-none-eabi-gcc$ ls
10.2.1-2020q4  4.8.3-2014q1  8.3.1-2019q3

[smaller09]

As for gcc 10.2.1 that xpack does, i had already tested it.

/home/jackie/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/10.2.1-2020q4/bin/arm-none-eabi-size -A /tmp/arduino_build_714821/Multiprotocol.ino.elf
Sketch uses 116928 bytes (96%) of program storage space. Maximum is 120808 bytes.
Global variables use 4208 bytes (20%) of dynamic memory, leaving 16272 bytes for local variables. Maximum is 20480 bytes.

a little bigger than 8.3.1 but also about 2K smaller than 4.8.3

[benlye]

So you manually installed the 8.3.1 compiler and linked it? I was hoping you had installed some other Arduino IDE package that had installed it and I could grab their package file and link the same distribution, but it doesn't matter.

But still, why that specific version, and not the 2019-q4 version, or v9, or something else?

I have a quick 'n dirty Arduino IDE board package working using the xpack 8.3.1 compiler. After making the same inline changes as you it compiles fine. It remains to be seen if it actually works...

[smaller09]

10.2.1 and 8.3.1 are just what I have in the disk now, nothing special. I use 10.2.1 to compile betaflight and deviationtx requires 8.3.1. what I want to states is that gcc 4.8.3 is too old to do jobs good. newer gcc may be a better choose

[benlye]

OK. Need to look at the inline thing in more detail because the compiler generates a lot of warnings about it now.

:\Users\blye\AppData\Local\Arduino15\packages\multi4in1-devel\hardware\STM32F1\1.3.0\system/libmaple/stm32f1/include/series/gpio.h:487:29: warning: always_inline function might not be inlinable [-Wattributes]
 static __always_inline void afio_exti_select(exti_num exti, exti_cfg port) {
                             ^~~~~~~~~~~~~~~~

It seems like there were other fixes made in the Arduino_STM32 core to address them... https://github.com/rogerclarkmelbourne/Arduino_STM32/pull/677 https://github.com/rogerclarkmelbourne/Arduino_STM32/pull/681

But I have the firmware compiling in Git now with this compiler, so I can keep working on it. https://github.com/pascallanger/DIY-Multiprotocol-TX-Module-Boards/actions/runs/627579328

arduino-cli compile --build-property runtime.tools.xpack-arm-none-eabi-gcc-8.3.1-1.4.path=/home/runner/xpack-arm-none-eabi-gcc-8.3.1-1.4 -b multi4in1:stm32f1:multistm32f103cb:debug_option=none /home/runner/work/DIY-Multiprotocol-TX-Module-Boards/DIY-Multiprotocol-TX-Module-Boards/DIY-Multiprotocol-TX-Module/Multiprotocol/Multiprotocol.ino
Sketch uses 114864 bytes (95%) of program storage space. Maximum is 120808 bytes.
Global variables use 4232 bytes (20%) of dynamic memory, leaving 16248 bytes for local variables. Maximum is 20480 bytes.

[smaller09]

Oh. the new framework 1.3.0. I did't have that. currently I can't ascess raw.githubusercontent.com and download.arduino.cc for some reason. hope to help you soon.

[benlye]

Once you can get to it, if you add this as an additional board URL you can install the devel board package. 1.3.0 uses the new gcc compiler

https://raw.githubusercontent.com/pascallanger/DIY-Multiprotocol-TX-Module-Boards/devel/source/package_multi_4in1_board_devel_index.json

The IDE can be confusing because the devel boards have the same names as the non-devel boards so you might want to uninstall the non-devel package first.

I haven't tested on anything other than Windows yet.

[benlye]

Inlining warnings are fixed in v1.3.1, available in the Devel board package.

This change seemingly really forces the functions inline, which appears to be the goal: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module-Boards/pull/48/commits/cf967c0d0a88e8b492faaa3613b0dabd08111830

[benlye]

Flashed FW built with the devel board / gcc 8.3.1 to my TX16S and an IRX 4+ and both seem to work OK with a very quick test with an E010.

[nico0807]

If the goal is to reduce the size of your compiled firmware you may want to try replacing the -Os optimizer option with -Oz, it's a more aggressive size focused optimization. The size may not go down that much but when every byte counts ...

[benlye]

If the goal is to reduce the size of your compiled firmware you may want to try replacing the -Os optimizer option with -Oz, it's a more aggressive size focused optimization. The size may not go down that much but when every byte counts ...

The gcc compiler doesn't like that flag; it seems like it's clang only.

Error while detecting libraries included by C:\Users\blye\AppData\Local\Temp\arduino_build_109931\sketch\Multiprotocol.ino.cpp
Generating function prototypes...
"C:\\Users\\blye\\AppData\\Local\\Arduino15\\packages\\multi4in1-devel\\tools\\xpack-arm-none-eabi-gcc\\8.3.1-1.4/bin/arm-none-eabi-g++" -c -g -Oz -w -DDEBUG_LEVEL=DEBUG_NONE -std=gnu++11 -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_generic_stm32f103c -DVECT_TAB_ADDR=0x8002000 -DERROR_LED_PORT=GPIOB -DERROR_LED_PIN=1 -w -x c++ -E -CC -mcpu=cortex-m3 -DF_CPU=72000000L -DARDUINO=10813 -DARDUINO_MULTI_STM32_WITH_BOOT=131 -DARDUINO_ARCH_STM32F1 -DGENERIC_BOOTLOADER -DMCU_STM32F103CB -mthumb -march=armv7-m -D__STM32F1__ -DMCU_STM32F103CB -mthumb -march=armv7-m -D__STM32F1__ "-IC:\\Users\\blye\\AppData\\Local\\Arduino15\\packages\\multi4in1-devel\\hardware\\STM32F1\\1.3.1\\system/libmaple" "-IC:\\Users\\blye\\AppData\\Local\\Arduino15\\packages\\multi4in1-devel\\hardware\\STM32F1\\1.3.1\\system/libmaple/include" "-IC:\\Users\\blye\\AppData\\Local\\Arduino15\\packages\\multi4in1-devel\\hardware\\STM32F1\\1.3.1\\system/libmaple/stm32f1/include" "-IC:\\Users\\blye\\AppData\\Local\\Arduino15\\packages\\multi4in1-devel\\hardware\\STM32F1\\1.3.1\\system/libmaple/usb/stm32f1" "-IC:\\Users\\blye\\AppData\\Local\\Arduino15\\packages\\multi4in1-devel\\hardware\\STM32F1\\1.3.1\\system/libmaple/usb/usb_lib" "-IC:\\Users\\blye\\AppData\\Local\\Arduino15\\packages\\multi4in1-devel\\hardware\\STM32F1\\1.3.1\\cores\\maple" "-IC:\\Users\\blye\\AppData\\Local\\Arduino15\\packages\\multi4in1-devel\\hardware\\STM32F1\\1.3.1\\variants\\generic_stm32f103c" "C:\\Users\\blye\\AppData\\Local\\Temp\\arduino_build_109931\\sketch\\Multiprotocol.ino.cpp" -o "C:\\Users\\blye\\AppData\\Local\\Temp\\arduino_build_109931\\preproc\\ctags_target_for_gcc_minus_e.cpp" -DARDUINO_LIB_DISCOVERY_PHASE
cc1plus.exe: error: argument to '-O' should be a non-negative integer, 'g', 's' or 'fast'
exit status 1
Error compiling for board Multi X-in-1 STM32F103CB (128KB).

[nico0807]

If the goal is to reduce the size of your compiled firmware you may want to try replacing the -Os optimizer option with -Oz, it's a more aggressive size focused optimization. The size may not go down that much but when every byte counts ...

The gcc compiler doesn't like that flag; it seems like it's clang only.

Error while detecting libraries included by C:\Users\blye\AppData\Local\Temp\arduino_build_109931\sketch\Multiprotocol.ino.cpp
Generating function prototypes...
"C:\\Users\\blye\\AppData\\Local\\Arduino15\\packages\\multi4in1-devel\\tools\\xpack-arm-none-eabi-gcc\\8.3.1-1.4/bin/arm-none-eabi-g++" -c -g -Oz -w -DDEBUG_LEVEL=DEBUG_NONE -std=gnu++11 -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_generic_stm32f103c -DVECT_TAB_ADDR=0x8002000 -DERROR_LED_PORT=GPIOB -DERROR_LED_PIN=1 -w -x c++ -E -CC -mcpu=cortex-m3 -DF_CPU=72000000L -DARDUINO=10813 -DARDUINO_MULTI_STM32_WITH_BOOT=131 -DARDUINO_ARCH_STM32F1 -DGENERIC_BOOTLOADER -DMCU_STM32F103CB -mthumb -march=armv7-m -D__STM32F1__ -DMCU_STM32F103CB -mthumb -march=armv7-m -D__STM32F1__ "-IC:\\Users\\blye\\AppData\\Local\\Arduino15\\packages\\multi4in1-devel\\hardware\\STM32F1\\1.3.1\\system/libmaple" "-IC:\\Users\\blye\\AppData\\Local\\Arduino15\\packages\\multi4in1-devel\\hardware\\STM32F1\\1.3.1\\system/libmaple/include" "-IC:\\Users\\blye\\AppData\\Local\\Arduino15\\packages\\multi4in1-devel\\hardware\\STM32F1\\1.3.1\\system/libmaple/stm32f1/include" "-IC:\\Users\\blye\\AppData\\Local\\Arduino15\\packages\\multi4in1-devel\\hardware\\STM32F1\\1.3.1\\system/libmaple/usb/stm32f1" "-IC:\\Users\\blye\\AppData\\Local\\Arduino15\\packages\\multi4in1-devel\\hardware\\STM32F1\\1.3.1\\system/libmaple/usb/usb_lib" "-IC:\\Users\\blye\\AppData\\Local\\Arduino15\\packages\\multi4in1-devel\\hardware\\STM32F1\\1.3.1\\cores\\maple" "-IC:\\Users\\blye\\AppData\\Local\\Arduino15\\packages\\multi4in1-devel\\hardware\\STM32F1\\1.3.1\\variants\\generic_stm32f103c" "C:\\Users\\blye\\AppData\\Local\\Temp\\arduino_build_109931\\sketch\\Multiprotocol.ino.cpp" -o "C:\\Users\\blye\\AppData\\Local\\Temp\\arduino_build_109931\\preproc\\ctags_target_for_gcc_minus_e.cpp" -DARDUINO_LIB_DISCOVERY_PHASE
cc1plus.exe: error: argument to '-O' should be a non-negative integer, 'g', 's' or 'fast'
exit status 1
Error compiling for board Multi X-in-1 STM32F103CB (128KB).

My bad, I though it was compatible with GCC, sorry for the false hope.

[MikeBland]

Pre-built ARM compilers may be downloaded from here: https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads Using 7.2.1 compiler I found, with 1.3.2.67, a file of size 115812 instead of 118196.

In platform.txt i changed: compiler.path={runtime.tools.arm-none-eabi-gcc.path}/bin/ to: compiler.path=C:/Yagarto/bin/ as I have the compiler installed in C:/Yagarto.

[benlye]

@MikeBland did you try the Devel Multi board package? It will install version 8.3.1 of the compiler straight into Arduino (using a package from xPack) along with the necessary changes to the Multi board files.

I already have the firmware build automation prepped for the change, and GitHub is doing automated builds on the devel branch of the board repo with the new compiler.

In my mind the biggest problem is getting enough test flight time on firmware built with the new toolchain.

Any thoughts on how to proceed?

[MikeBland]

No I didn't. I just used the 7.2.1 compiler I've been using for erskyTx. This worked without needing any other changes. I've also got version 9.3.1 of the compiler available, but haven't tried that yet. I'm happy to use 7.2.1 as I've been using it for a while to build and use erskyTx.

[benlye]

So the question remains, how does this move forward?

I don't have a strong opinion about which version compiler we update to, but life will be significantly easier if we choose a version which has Arduino-compatible xPack distribution as that makes it easy to distribute the board package and have the IDE take care of the installation. These seem to start at v8.3.1-1.4.

If you know of another repository which distributes Arduino-ready compiler packages, I'd also be happy to switch to that instead of xPack. (The packages that come straight from Arm don't work directly with the Arduino IDE board installer and need re-packaging, which is the service that xPack provides.)

EDIT: I suppose the other option is to package whatever version of the compiler we want to settle on ourselves and have it downloaded from the board repo (or some other repo we control). I'm not crazy about that as it seems like redoing work that others have done, but if there's a compelling reason to use a specific version (e.g. 7.2.1), then it's a way forward.

[pascallanger]

Due to COVID I haven't been able to fly anything since monthes. Once I'll be able to fly again I should be able to assess if there is an issue with this new build or not on many different protocols. Right now it looks fine on the bench since I'm using it from March 6th.

[harryjph]

Might be obvious but as I haven't seen it mentioned, I thought I'd bring it up, has anyone tried link time optimization (the -flto flag)?

[OpenUAS]

@smaller09 you wrote:

... what I want to states is that gcc 4.8.3 is too old to do jobs good. newer gcc may be a better choose

There I would kindly disagree. Thousands of multi-modules compiled with v4.8.3 working 100%. Specifically for a RC TX you want a very good reason to switch the compiler to some other version. Yes, size of firmware is quite a good reason, but not good enough IMHO ;)

[benlye]

We did this almost a year ago :-)