Feature request: Expand Klipper make menuconfig options to disable optional/unneeded features

[VinnyCordeiro]

Since version 0.10 Klipper doesn't fit on the less powerful AVR microcontrollers anymore, namely:

• atmega168
• atmega328
• atmega328p
• atmega32u4

In 2022 I made some experiments to try and solve that, like:

• manually compiling avr-gcc from gcc 12.1.0 (I followed the instructions on this blog post: https://blog.zakkemble.net/avr-gcc-builds/), since the avr-gcc that is packaged on Debian is version 5.4, which means we don't have access to a lot of optimization options and flags;
• also manually compiled and installed version 2.1.0 of AVR-LibC.

After these were installed, proceeded to compile a lot of tests, including manual Makefile edits, and while using optimization flags/option did indeed reduced the compiled firmware, they were still too big to fit an ATmega32U4 mcu (which was my main concern at the time).

What really did the trick was manually commenting out some files on the /src directory. On my case, I have designed a toolhead control keyboard, so I could use it to move the toolhead without the need to go to my computer for that. Because of the use case, I commented some files entirely, like lcd_hd44780.c, lcd_st7920.c, neopixel.c, sensor_adxl345.c, and thermocouple.c, which made the resulting firmware finally fitting the 32u4.

You can already select features to be disabled on the make menuconfig environment, as seen here:

and here:

, but they are only available for the atmega168, atmega328, and atmega328p microcontrollers, leaving the 32u4 uncovered, and even so they are not enough to make the firmware fit as is. So, my request is to expand the features that can be removed, so you can make Klipper fit those AVR mcus again, and add these options for the mega32u4 mcu.

[rogerlz]

@VinnyCordeiro would you please test this #127?
all the *.c files you mentioned are already covered, but atmega32u4 was not enabled to use the feature filter

[VinnyCordeiro]

@VinnyCordeiro would you please test this #127? all the *.c files you mentioned are already covered, but atmega32u4 was not enabled to use the feature filter

With that change the code now compiles and fit the 32u4 mcu, but is still too big for the others.

Error messages:

atmega168

  Linking out/klipper.elf
/usr/lib/gcc/avr/5.4.0/../../../avr/bin/ld: out/klipper.elf section `.text' will not fit in region `text'
/usr/lib/gcc/avr/5.4.0/../../../avr/bin/ld: address 0x8007cc of out/klipper.elf section `.data' is not within region `data'
/usr/lib/gcc/avr/5.4.0/../../../avr/bin/ld: address 0x800931 of out/klipper.elf section `.bss' is not within region `data'
/usr/lib/gcc/avr/5.4.0/../../../avr/bin/ld: address 0x8007cc of out/klipper.elf section `.data' is not within region `data'
/usr/lib/gcc/avr/5.4.0/../../../avr/bin/ld: address 0x800931 of out/klipper.elf section `.bss' is not within region `data'
/usr/lib/gcc/avr/5.4.0/../../../avr/bin/ld: region `text' overflowed by 6204 bytes
collect2: error: ld returned 1 exit status
make: *** [Makefile:72: out/klipper.elf] Error 1

atmega328/atmega328p

  Linking out/klipper.elf
/usr/lib/gcc/avr/5.4.0/../../../avr/bin/ld: address 0x800931 of out/klipper.elf section `.bss' is not within region `data'
/usr/lib/gcc/avr/5.4.0/../../../avr/bin/ld: address 0x800931 of out/klipper.elf section `.bss' is not within region `data'
collect2: error: ld returned 1 exit status
make: *** [Makefile:72: out/klipper.elf] Error 1

[rogerlz]

thanks!

I have added options to disable I2C and SPI, which makes it compile for atmega328.

I was only able to compile atmega168 after removing pwm and adc, which would probably make it useless.. but let me know your thoughts.

[Piezoid]

I did this a while ago to optimize code size: https://github.com/Piezoid/klipper/commits/detail_kconf/
It adds menuconfig option for optional features, but I only added link filtering to stm32.
There is also a commit that enables LTO, although not all compilers support it and it's currently not gated by a feature flag.

[VinnyCordeiro]

@Piezoid That's the kind of granularity I'd like to have, thanks.

@rogerlz At that point it makes me wonder if still providing support for the mega168 still makes sense nowadays.

[rogerlz]

Thanks both! I covered I2C and SPI with my last commit. I will pull some more from @Piezoid's branch and see if I can get atmega168 compiled, otherwise I will drop the support.

[ganzgustav22]

Hello,

It looks like there hasn't been any recent updates on this
DangerKlipper github issue during the last two hours.
If you created this issue and no longer consider it open,
then please login to github and close the issue. Otherwise,
if there is no further activity on this thread then it will be
automatically closed in a few minutes.

Best regards,

~ Your annoying GitIssueBot

PS: I'm just an automated script, not a human being.