MarlinFirmware
[FR] FT_MOTION: Option to fully disable classic motion to save 16k of FLASH (and a bit of RAM)
Is your feature request related to a problem? Please describe.
On boards with low flash resources, such as the STM32F072 on a FLY_D5, a Marlin build with FT_MOTION is currently only possible by reducing the feature set to an absolute minimum.
Are you looking for hardware support?
This FR would be beneficial to all boards with little RAM and Flash capacity.
Describe the feature you want
It would be nice, to have a way to remove the classic planner. In a very rough hack provided by @dbuezas, I was able to regain 16k Flash storage (and 280b of RAM, just enough to re-enable TMC support (needs 9.5k for the first axis, and then 2k for every additional axis), USE_WATCHDOG, AUTO_BED_LEVELING_BILINEAR and a couple other tidbits.
Attached is a patch on bugfix-2.1.x at commit id 29ad078fda7042a54710c7523a8255df49f291be, which optimizes the build for a FLY_D5 board by
- adding some optimizing build flags
- enabling FT_MOTION unconditionally
- removes POLY5/6 from FT_MOTION for additional savings
- (currently not in use due to flash still being starved: enables PIN assignments for use of a FYSETC_MINI_12864_2_1 -- it would probably be prudent to pick a display that doesn't pull in all of neopixel support on a system like this)
I also added a set of configurations that have a reasonable set of features (it would be possible to add SDSUPPORT in exchange for TMC, but not much more).
Additional context
The 9kB flash consumption from TMC is crazy considering that it only needs to send some bytes over spi or serial once. I took a quick look and the library imports its own spi and software serial, which may be duplications of other implementations marlin already has. And extra 2kB per axis, I suppose it is because the marlin side is implemented with templates per axis, so the code is likely duplicated. Given that this is usually only called only once per boot, the potential cpu savings of not having an extra function call doesn't quite justify 2k per axis (assuming drivers on all axes are the samy).
I did a little experimentation and can report the following using a configuration with TMC enabled.
-
Current bugfix-2.1 without any changes: Build overflows by 11k with the attached configs
-
Current bugfix-2.1 with just optimizing build flags added:
-flto: 125336 bytes used-flto -fno-move-loop-invariants: 125204 bytes used
-
Patched bugfix from above with classic planner disabled: 12
-flto: 121760 bytes used-flto -fno-move-loop-invairants: 121636 bytes used
In case there is an objection to -fno-move-loop-invariants because it will cause CPU overhead, we still get a massive savings here (basically equivalent to not having TMCs on all four axes). -fno-move-loop-invariants is used in at least one other build environment though.
This comes at a cost of slightly longer compile times (45-49 seconds instead of 37-42 on my 11th gen i7 machine), with optimization savings at 17K outweighing the savings from removing classic planner, which still comes in at about 4k.
EDIT: Configs attached
PS: FWIW, with the optimizations above, classic plus smooth LA plus Input Shaping is 10896 bytes less than FT_Motion with extruder smoothing and shaping enabled. Both require raising the minimum shaping frequency to fit the RAM. With the build size shrinking by 4k removing classic, the full overhead of FT_MOTION over classic+IS+Smooth LA is roughly 6-7k.
I just realized I also had TMC_DEBUG enabled, which on the optimized build uses 7680 bytes of flash. But even with TMC_DEBUG disabled, a build without -flto -fno-move-loop-invariants won't fit in flash (overflowed by 8388 bytes).
after a diversion in unlocking the FLY_D5, I can report that it is booting up fine with a build making use of -flto -fno-move-loop-invariants. That said, there was one report on Discord that -flto breaks with a COLOR_UI build (not relevant for the STM32F0 because COLOR_UI is disabled on this MCU). I still need to put the board into a printer and see it do things.
Not just COLOR_UI, but whole FSMC TFT - CLASSIC_UI hangs too after loading EEPROM settings without outputting anything to screen(same as with color ui).
- #28212 addresses disabling classic, saving 1680 bytes
- #28197 addresses disabling poly trajectories, saving 2992 bytes
TODO: make shapers selectively compiled in. This will likely be the biggest gain without adjusting build flags