♻️ Simpler flexible SERIAL_ECHO

[thinkyhead]

The multi-level macros in serial.h add some convenience and have been used to allow for local optimizations that have at times significantly reduced the size of the Marlin binary. But preprocessor macros are a strange breed and an acquired taste and there are now more modern ways to accomplish the same goal. So let's use good old template meta-programming with type specialization instead!

This PR makes the following improvements:

• Use templates to make SERIAL_ECHO more flexible.
• Add wrapper types and apply template specialization for float-with-precision types.
• Remove redundant serial echo macros and functions.

Code size on AVR is a bit larger with these changes, but that might be solvable.

[EvilGremlin]

How much larger? For real world build with some fancies.

[thinkyhead]

How much larger? For real world build with some fancies.

For the default config the build size increases by 94 bytes. For a full-featured build the size increases by 924 bytes. With debug leveling feature added a full featured build increases by 774 bytes.

 mftest -tmega -n3 -y

Ideally the template-based code should produce a binary that is nearly identical to the build that uses macros, and smaller would be even better. If you have any ideas about how to make these templates more optimized for size, please share those ideas here and in the Discord. Many moons ago I made a lot of changes to the serial.h header refining the SERIAL_ECHO family of macros which reduced the build size significantly, so I'm all for taking a deep dive and figuring out some tricks to get the build size down to a minimum by the template approach.

Of course, it is not possible to remove the SERIAL_ECHOPGM macros without creating a huge inconvenience requiring all serial strings to be wrapped in F() throughout the codebase, something on the order of 6000 strings. In fact most of the macros in Marlin fulfill a necessary function that cannot be readily supplanted by templates. But wherever possible, I'm happy to get rid of macros and use templates, knowing that our most prolific contributors are universally averse to the study, mastery, and application of preprocessor macros but are well-versed and fluent in the use of templates.

[RV-from-be]

Just a simple reflection and personal observation. Since some time now, the base code with equal functionality has continued to grow in size. Here 94 bytes, another time 48 etc... If we look at the 3D printing market, manufacturers are orienting their hardware development for Klipper. Large motherboards with lots of Flash Memory are not suitable for entry-level and mid-range printers. Manufacturers most often equip them with motherboards with 256 kb of Flash Memory, the useful and usable quantity of which is reduced by bootloaders. Producing "aesthetic" code to the detriment of pragmatism to ultimately bring nothing in terms of functionality and on the contrary sometimes oblige the user to limit the choice of functionalities, is not an advance but a setback which will lead some to go under Klipper.

[EvilGremlin]

Your Klipper argument contradicts itself...

[RV-from-be]

Your Klipper argument contradicts itself...

@EvilGremlin Oh yes and in what ???? Klipper doesn't need a printer motherboard with an astronomical amount of Flash Memory. The binary flashed on the motherboard in a Klipper environment is just the communication gateway between the MCU (often an Rpi or a CM4 or even a CB1) and the printer's motherboard. Klipper is on the MCU, not the MB.

[thinkyhead]

@RV-from-be — No one is more concerned than me about keeping the size of the code small for AVR, and as I mentioned earlier: I have made many changes in the past which reduced the build size, and I am endeavoring to make sure that this PR does not increase the build size. I am glad to know that others also share my concerns.

[EvilGremlin]

@RV-from-be It takes literally 1000 times more RAM to run klipper, among other things. Beefier MCU for marlin will be always cheaper than any klpper solution.

[thinkyhead]

Producing "aesthetic" code to the detriment of pragmatism to ultimately bring nothing in terms of functionality and on the contrary sometimes oblige the user to limit the choice of functionalities, is not an advance but a setback which will lead some to go under Klipper.

@RV-from-be — Careful not to give away my game! It is partly my aim to demonstrate to those who have lately insisted that we strip out macros for aesthetic reasons that this comes with trade-offs in size and optimal efficiency and does not really do much to reduce complexity, attract new developers, or cause current contributors to become better or more motivated at solving reported issues.

Most of these suggestions seem to come from developers with a more "academic" background who have been taught the maxim that "simpler is better." I come from a background of assembly and machine code on systems with less resources, and I prefer a "non-pedantic" code style over "clean coding" or other principles that focus on code aesthetics rather than concision and efficiency, and which do very little to actually help the compiler do optimizations. I do take the concerns of our most skilled, broadly-experienced, and active developers seriously, but the person who must deal with this codebase all day every day is myself, and I do believe that I have reasonably high standards where it counts.

There is a lot of stuff which can be done to "improve" this codebase, but it is not primarily the low-hanging aesthetic stuff that the critics have been pointing at. Rather, it is the things which populate my longstanding TODO list, which I have written and spoken about at length in many interviews and forums, and which apparently only I have the resources, skills, and will to address. Although I have to play multiple roles in maintaining and managing the project while also building tools and doing a lot of this deep coding, we will get there and we will maintain decent parity with alternatives like Klipper which are themselves plateauing.

[EvilGremlin]

Some gradual bloating is inevietble though. i.e. better thermal and buffer protections and superior, more compicated motion algorythms (compensation is name of the game in FDM). Or optimize for faster execution where it actually matters. Some things are purely for cosmetic and convenience, but if it leads to better scalability - why not? Sticking to AVR is nice, but let's not stick too hard. These chips will get only more and more expensive with no performance increase whatsoever.

[thinkyhead]

These chips will get only more and more expensive with no performance increase whatsoever.

Be that as it may, there are many thousands of machines out there which have an AVR mainboard, and there are many types of projects that are not 3D printers which can benefit from the "wealth of knowledge" and resources embodied in the Marlin codebase. Wherever possible I have attempted to keep the base build size of Marlin small, and it still remains under 64KB.

As for this PR, I am not going to be satisified until you and I have applied our coding skills to figure out and solve the size increase. We are wasting our considerable intelligence by only discussing things at a theoretical level and not getting down to solving this very interesting problem.

[plampix]

When I build with my configs, size increase just before and after 2ef71c6 is more than 5kB. That could be an issue on quite a lot of boards. Git bisect lied to me.