Update stm32f1-maple.ini - 256k boards

[classicrocker883]

Description

Revert back to [email protected] [email protected] (bump version) for some env:

According to my tests of the various toolchain-gccarmnoneeabi versions, 1.903 gives the smallest size in the end.

I get a workflow error
with platform_packages = tool-stm32duino, toolchain-...
Simply moving this to next line fixes that.
the comma causes the issue.

• plus for 256k chips (RC), the newer toolchains adds ~2000 bytes.

Requirements

Benefits

lessen size for boards with chips that have limited capacity.

Configurations

Related Issues

[thinkyhead]

Is it possible that only the base toolchain build flags changed between toolchain versions, or is there just a newer version of gcc? I'll take a look at that before committing to the older toolchain.

[classicrocker883]

i tried the different toolchain versions and its not the same. here is something to consider
platformio/platform-ststm32#492

actually, in this test here are my results:

1.100301.220327
RAM:   [====      ]  37.0% (used 18176 bytes from 49152 bytes)
Flash: [========= ]  86.7% (used 227156 bytes from 262144 bytes)

1.90201.191206
RAM:   [====      ]  37.0% (used 18192 bytes from 49152 bytes)
Flash: [========  ]  81.2% (used 212820 bytes from 262144 bytes)

1.70201.0
RAM:   [====      ]  37.1% (used 18224 bytes from 49152 bytes)
Flash: [========  ]  84.7% (used 222140 bytes from 262144 bytes)

[thinkyhead]

As long as the RAM and Flash usage are not in danger of exceeding the space on the board, we shouldn't sweat the size differences too much. We are looking to produce best performance and efficiency and that's not specifically dependent on the size. Loop unrolling will expand the size of the binary but can be a good optimization when space allows.

We're mainly concerned about conserving space when it comes to 128K and smaller boards in the base Marlin build so that these boards are not left behind with the next update. We haven't the same worries with boards 256K and larger, so I would not favor going back to an earlier compiler version unless we know there are bugs in the newer compiler, and that we cannot get some binary size optimizations (where we care more about that) by adding a build flag.

That said, 14K is a large difference between 10.3.1 and 9.2.1, so it would be a good idea to find out what parts of the code are being increased more than others and see if those areas can be compressed a bit with some build flags or pragma sections.

The last comment on that PlatformIO issue refers to a build error with Marlin, where it cannot find the compiler with version reference @~1.90201.0, and changing that to @<1.80000.0 almost worked. I assume that's the relevant part, since the rest of the issue refers to MBED circa 2001, though it also mentions other parts of STSTM32 being best-compiled with toolchain @<1.80000.0.

For our purposes, apart from best performance and efficiency and avoiding buggy versions of GCC, we also want to make sure Marlin builds with PlatformIO and works around any glitches in PlatformIO or in certain packaged versions of ststm32. If we can use the newer toolchain with presumed improvements, we should aim for that in spite of build size.

[classicrocker883]

The last comment on that PlatformIO issue refers to a build error with Marlin, where it cannot find the compiler with version reference @~1.90201.0, and changing that to @<1.80000.0 almost worked.

actually the full version is @1.90201.191206, and in my recent tests, @1.90301.200702 gives even a smaller build (without effecting RAM size)