search

rogerclarkmelbourne / Arduino_STM32

Arduino STM32. Hardware files to support STM32 boards, on Arduino IDE 1.8.x including LeafLabs Maple and other generic STM32F103 boards
Other
2.52k stars 1.26k forks source link

[question] I've updated the toolchain. Better program sizes. Anyone interested? #786

Closed danieltr3s closed 3 years ago

danieltr3s commented 4 years ago

Hello everyone,

I've modified the platform.txt and boards.txt files in order to use the xpack gcc 9 toolchain ( xpack-arm-none-eabi-gcc-9.2.1-1.1 the one that STM32 Cores uses) which uses a more recent compiler and has a lot of new features like the Newlib Nano (nano.specs) and LTO support. On my projects, the new toolchain produces reduces the program sizes in more than 50% on average. If I select the Newlib Nano this goes down further 35%! Of course this depends on the size of your code, so results will vary. I was running out of program memory on my BluePill and now I only use 37%!

Is anyone interested in this? I can push my changes if you guys want.

image image

@ddrown , I use your Package Link to install the stm32duino boards (libmaple) on Arduino IDE. Are you interested in updating your repo with the new toolchain?

ddrown commented 4 years ago

The build process will automatically pick up changes to platform.txt and boards.txt in this repo.

I'll need to update the gcc version that it links to, which is pretty simple to do.

rogerclarkmelbourne commented 4 years ago

@ddrown OK. Thanks

GitMoDu commented 4 years ago

and LTO support

Considering LTO support was mostly dropped in the current core, I'd say this alone is a welcome feature, if it as painless as you make it seem.

rogerclarkmelbourne commented 4 years ago

The problem with LTO is that it causes various libraries to not work correctly and rarely seems to give any reduction in code size.

So adding it back in as an option that anyone could enable, without understanding the consequences will probably cause a lot of support requests.

If anyone personally wants that feature they could look at the code and manually enable it themselves.

danieltr3s commented 4 years ago

and LTO support

Considering LTO support was mostly dropped in the current core, I'd say this alone is a welcome feature, if it as painless as you make it seem.

The toolchain supports LTO but I have not had any luck with it though. I'm quite satisfied with the improvements on the compiler and runtime alone. It seems to me that the LTO hardly will yield any good results... I agree with @rogerclarkmelbourne .

danieltr3s commented 4 years ago

I've created a Pull request with this modifications. Left the LTO options disabled for F1s. F4s had the option active so I didn't touch that.

stevstrong commented 3 years ago

The problem with LTO is that it causes various libraries to not work correctly and rarely seems to give any reduction in code size.

So adding it back in as an option that anyone could enable, without understanding the consequences will probably cause a lot of support requests.

If anyone personally wants that feature they could look at the code and manually enable it themselves.