Update platform STM32 to version 10, optimize build

[mathiasvr]

Description

The platformio package framework-arduinoststm32-maple needed for the common_stm32f1 boards is outdated and contains C++ demangling symbols that take up a significant amount of space of the firmware builds.

I have created a platformio supported fork with all the recent updates including removal of the demangling symbols.

Benefits

STM32F103RC based boards can now enable most marlin features within their 256kb limit.

This fix can most likely also be applied to the STM32F103RE based boards, but since they have a 512kb limit it seemed less urgent. Let me know what you think.

[rhapsodyv]

Using the new STM32 env don't solve this space issue?

I'm asking that, because all current efforts are to just abandon maple at all, in favour of stm32duino.

[sjasonsmith]

Is this related to #19427, or is this another space-saving opportunity? I think there was another open issue/feature request regarding this, but I'm having trouble finding it.

Using the new STM32 env don't solve this space issue?

That is our longer-term goal, but until we get there this may be worth considering.

[mathiasvr]

Using the new STM32 env don't solve this space issue?

I'm asking that, because all current efforts are to just abandon maple at all, in favour of stm32duino.

Yes, I agree using stm32duino is preferable and will most likely solve this issue as well.

[mathiasvr]

Is this related to #19427, or is this another space-saving opportunity? I think there was another open issue/feature request regarding this, but I'm having trouble finding it.

I have not looked into the exact fix, but it does not appear to be related.

[sjasonsmith]

I just tried it on the build I'm working with, and it shrunk from 211kB to 181kB. That is a pretty substantial improvement. Yesterday I was having a real issue getting a user config to fit into an RCT6, and this would have helped a lot.

If we move ahead with this, I think I would like to see the following:

1. Apply this to all boards extending common_stm32f1. I'd like these various boards to keep as many things in common as possible, so it seems obvious that we should use it everywhere. This will require a little work to make sure that all STM32F1 environments inherit their "parent" platform_packages, if they already have the line specified.

2. Use a .zip link instead of a .git link. Not all users are configured properly for the .git paths to work. I think it should also reference a specific commit, so that it doesn't change out from under users. I tested with this, for example:
   framework-arduinoststm32-maple@https://github.com/mathiasvr/Arduino_STM32/archive/baa0a8ec805c50daad9481a8d759e9dec1e0e39b.zip

3. Some sanity checking from a couple users that this is working, prior to merging it.

[sjasonsmith]

We should also add a comment describing the reason we are using the framework from a random fork, rather than the official PIO repo.

[sjasonsmith]

This is the other issue I'm thinking of: #19838

This seems a lot more likely to be directly related to this.

[sjasonsmith]

@mathiasvr was this already fixed upstream, it just has not been re-packaged for PlatformIO? If so, perhaps @ivankravets would be kind enough to bundle a new maple version, even though it is no longer the preferred framework.

There is an open issue about this for the ststm32 platform, but there hasn't been any comments on it yet.
platformio/platform-ststm32#446

[mathiasvr]

This is the other issue I'm thinking of: #19838

This seems a lot more likely to be directly related to this.

Yes, I think most of the space savings are based on a similar fix.
Note that several other issues have been fixed in this codebase compared to the on published on platformio.
If you only care about removing demangling symbols, I can create another branch for that.

I will be looking into your remaining comments, thanks.

[mathiasvr]

@mathiasvr was this already fixed upstream, it just has not been re-packaged for PlatformIO? If so, perhaps @ivankravets would be kind enough to bundle a new maple version, even though it is no longer the preferred framework.

There is an open issue about this for the ststm32 platform, but there hasn't been any comments on it yet.
platformio/platform-ststm32#446

Just saw this now, yes this is fixed upstream so it would be great if it could be re-packaged directly.

[kad]

I experimented and using nanospecs in my builds for SKR mini MZ. Using that for a while
ststm32 platform+maple core:
https://github.com/kad/Marlin/blob/anycubic-kad-bugfix-2.0.x-unified/platformio.ini#L1604-L1616
enable nano specs for linker, and patch dtostrf.c:
https://github.com/kad/Marlin/blob/anycubic-kad-bugfix-2.0.x-unified/platformio.ini#L1658-L1666

[mathiasvr]

Updating the platformio package seems like the way to go, but I have updated the PR to address the comments just in case someone wants to test it.

[sjasonsmith]

Updating the platformio package seems like the way to go, but I have updated the PR to address the comments just in case someone wants to test it.

Well, we have no control over actually updating the PIO package. If we want to take advantage of this we will very likely have to point to something unofficial, the only question being where it should live.

[thinkyhead]

Which configurations are showing the most dramatic size reductions? I'm not seeing much difference in my tests so far.

[sjasonsmith]

Which configurations are showing the most dramatic size reductions? I'm not seeing much difference in my tests so far.

I was building STM32F103RE_creality. More or less an example config + leveling, and saw a 30kB reduction.
I had added my own dependency directly to that environment, since it wasn't yet applied everywhere. Perhaps not all of the extends are inheriting this dependency properly.

#
# Creality (STM32F103RET6)
#
[env:STM32F103RET6_creality]
platform        = ${env:STM32F103RE.platform}
extends         = env:STM32F103RE
build_flags     = ${env:STM32F103RE.build_flags} -DTEMP_TIMER_CHAN=4
platform_packages = framework-arduinoststm32-maple@https://github.com/mathiasvr/Arduino_STM32/archive/baa0a8ec805c50daad9481a8d759e9dec1e0e39b.zip
extra_scripts   = ${env:STM32F103RE.extra_scripts}
  pre:buildroot/share/PlatformIO/scripts/random-bin.py
  buildroot/share/PlatformIO/scripts/creality.py
debug_tool      = jlink
upload_protocol = jlink

[sjasonsmith]

@thinkyhead if you tell me which environment you are building I can try it on my end.

[tpruvot]

you can add that to reduce the size a lot : -DDEBUG_LEVEL=1 -D__FILE__=__func__ -Wno-builtin-macro-redefined
or just -DDEBUG_LEVEL=0

__FILE__ can use the whole path in debug/assert strings

[limestone-xyz]

Hey all, I'm pretty much new to Marlin - so excuse my noob questions :)
I'm using the SKR mini E3 V2 (with an RCT6 chip on it).
I downloaded the 2.x bugfix branch and tried to compile with "auto build marlin" in VScode with the STM32F103RC_btt environment. Unfortunately my rom overflows by around 28kB. Could I benefit from this fix? How would I incorporate it?
Thanks for helping out!

[mathiasvr]

@Gertsch I'm also using the SKR mini E3 V2 and it's been working fine so far. You should be able to check out my branch, but if you are unsure how, I think the easiest is to just add this line to the [STM32F103RC_btt] env:

platform_packages = framework-arduinoststm32-maple@https://github.com/mathiasvr/Arduino_STM32/archive/2020.11.29-dev.zip

@tpruvot This does not seem to change the build size for me, which environment are you using?

[tpruvot]

check platformio.ini, STM32F103RC_fysetc already/still have it... tested on the skr mini, at the time... not recently

its for maple one

STM32F1/system/libmaple/include/libmaple/util.h:91: _fail(__FILE__, __LINE__, #exp); \ STM32F1/system/libmaple/include/libmaple/util.h:101: _fail(__FILE__, __LINE__, #exp); \ STM32F4/cores/maple/libmaple/util.h:96: _fail(__FILE__, __LINE__, #exp); \ STM32F4/cores/maple/libmaple/util.h:106: _fail(__FILE__, __LINE__, #exp); \

[sjasonsmith]

It looks like a new Maple PIO package was just released! I just did a quick test with it to see how sizes changed with the creality board I'm currently building for.

• Version 2.10000 - 202556 bytes
• Version 3.10000 - 171204 bytes
• Version 3.10000 w/ tpruvot's suggestion - 170388 bytes

You can pull this in right now with the following:
platform_packages = framework-arduinoststm32-maple@~3.10000

Once it is in an ststm32 release we should update everything to use the latest and specify the framework for each common STM32 environment to use, rather than relying on old dependencies and defaults.

[tpruvot]

i remember bigger waste before, they have maybe fixed/improved that since...

[mathiasvr]

@sjasonsmith That's great, should I update the PR to use framework-arduinoststm32-maple@~3.10000, or should we wait for the next ststm32 release?

[sjasonsmith]

I just did minimal testing with an SKR Pro (STM32F4). This isn't in a printer so I didn't test a lot of motion, but attached a motor to make sure it isn't completely broken. Temperature reading, BLTouch, SoftwareSerial, and Watchdog all are working.

I didn't really expect any STM32F4 issues, since we updated ststm32 but the underlying STM32Duino package has not changed.

[sjasonsmith]

@thinkyhead I am satisfied with this. I'm not merging it to myself since it is a fairly significant change. I think the only reason to delay it would be if you were planning to tag a release and wanted to defer any risk associated with this to after the release.

[qwewer0]

Ideally we could do a quick test of the the following items:

• Motors move
• Temperature readings update
• TMC connections OK using SoftwareSerial
• Servo output / BLTouch work

SKR Mini E3 v1.2:

• XYZE Motor move - OK
• Bed and Hotend Temperature readings update - OK
• M122 XYZE Connection - OK
• M906 XYZE Current - OK
• BLTouch Self-Test/Deploy/Stow - OK
• M48 Probe Accuracy Test - OK
• XYZ (BLTouch) Homing - OK
• D100 - OK

Size redution: 276516 - 245364 = 31152

[limestone-xyz]

@Gertsch I'm also using the SKR mini E3 V2 and it's been working fine so far. You should be able to check out my branch, but if you are unsure how, I think the easiest is to just add this line to the [STM32F103RC_btt] env:

platform_packages = framework-arduinoststm32-maple@https://github.com/mathiasvr/Arduino_STM32/archive/2020.11.29-dev.zip

@tpruvot This does not seem to change the build size for me, which environment are you using?

worked like a charm, thanks so much!

[mathiasvr]

I have not done any systematic testing, but have been running my almost identical fork on top of Marlin 2.0.7.2 for some time and am now running this bugfix branch on SKR mini E3 V2. Currently printing without issues fwiw.

[Foxies-CSTL]

Ideally we could do a quick test of the the following items:

* Motors move

* Temperature readings update

* TMC connections OK using SoftwareSerial

* Servo output / BLTouch work

I have successfully compiled a new firmware under STM32 HAL with the latest changes from @jason on the platformio.ini.
I recall that I am on a Delta with TMC2209 in single-wire mode, the Neopixel activated with an active WIFI module (ESP12s).
I performed an autocalibration (G33) ok, perform a UBL with a bed at 60 ° C and run a test print to correct my segments between the towers.
Results:
G33 = ok
UBL & Memo mesh = ok
Printing = ok

Here is my feedback,

[sjasonsmith]

@Foxies-CSTL if you feel that board completely works using HAL/STM32, please post a PR to migrate it!
We need to eventually move all boards over, but some have feature gaps. If this board is simple you could go ahead and do it.