Shrinking Marlin 2.0 – How to reduce firmware size for 8 bit boards and still use a BLTouch and the filament sensor!

In this guide, I talk about how I got Marlin firmware 2.0 shrinked down to fit on the original Ender 3 mainboard while still supporting a BLTouch and a filament sensor at the same time.

Hello, my name is Daniel, welcome to the CrossLink channel. Our mission is to help 1 million people getting more successful with 3d printing and if you're here for the first time, subscribe and enable bell notifications so you don't miss anything.

In the last couple of videos, I've implemented several changes to my Ender 3 starting with a filament sensor and now a BLTouch and for the individual change, it wasn't that kind of hard to build a firmware that fits on the original mainboard but when it came to enabling both features at the same time, it got a little harder.

You can use this guide for any occurrence where you run into issues with Marlin firmware being too large. I've done this using the latest release version 2.0.6, just for your reference.

I've also uploaded the source and configuration files used in this video to the crosslink firmware factory exclusively for my Patrons. Link is in the description. But if you're not a patron yet, you can just follow this guide to the end.

So let's briefly look at what I enabled that made the firmware become too large in the first place.

In Configuration.h, I've enabled the BLTOUCH option with bilinear auto bed leveling according to my latest guide, which by itself already makes the firmware too large if you don't optimize it.

And then I also enabled FILAMENT RUNOUT SENSOR and NOZZLE PARK FEATURE together with ADVANCED PAUSE FEATURE in Configuration_adv.h.

That's basically everything I enabled on top of the Ender 3 default configuration for having the BLTouch and Filament runout sensor and of course the filament change function alongside with the usual other small changes to configure them correctly. If you're interested I've already made these other videos about configuring those features in detail.

Long story short, this combination of features built with the melzi_optiboot environment that you might already have used in the past or maybe the sanguino1284p, is way too large to fit on the mainboard.

In general, since Marlin 2.0.6 you can use the melzi_optimized environment instead, which has some additional parameters for the build process that make the firmware about 5% smaller without loosing any functionality.

How is that possible - simply said - the compiler is forced to spend more time to figure out how to optimize the code so it gets a result that uses less space. Since normally size isn't an issue nowadays, this optimization is skipped for a faster build time.

This is going to help but it's by far not enough to fit the firmware, so we have to make quite a few changes in the configuration files an top so let's quickly summarize the changes I made.

In Configuration.h from top down

I've disabled - means - commented out

STRING_CONFIG_H_AUTHOR

SHOW_CUSTOM_BOOTSCREEN

and CUSTOM_STATUS_SCREEN_IMAGE

I've enabled DISABLE_M503

I've disabled EEPROM_CHITCHAT

and - I've enabled SLIM_LCD_MENUS

So let's stop here for a second for some explanation.

The DISABLE_M503 option will save a significant amount of space - but with the caveat that you lose the M503 command, which reports back your current EEPROM values.

Disabling EEPROM_CHITCHAT means there won't be any confirmation anymore when doing firmware commands. This might have consequences if you have external software using these messages like some plugins in Octoprint for EEPROM management for example. Same applies for M503.

SLIM_LCD_MENUS will reduce the LCD menus to the ones really needed. Some menu items that are normally seldom used will be removed, so check if you miss something, you might have to use GCODE commands instead to use these functions then.

Next - let's look at what I changed in Configuration_adv.h

I've disabled AUTO_TEMP

I've enabled SDCARD_READONLY

enabled NO_VOLUMETRICS

and enabled NO_WORKSPACE_OFFSETS

So you see, you're making some compromises here, AUTO_TEMP, I normally don't use that feature, so I won't miss it.

SDCARD_READONLY, that's actually a good compromise. I normally just print from the SD card but I don't see any use case where I would want to write something to it. One feature that would require writing to the SD card however would be the power loss recovery.

NO VOLUMETRICS will only impact you if you use the M200 command for volumetric instead of linear extrusion. That M200 command is going to be gone.

Finally NO WORKSPACE OFFSETS, this disables the M206 and M428 commands, which are used for setting the home position on the fly using GCODE commands. Actually, I never used that.

If you find that your prints are not centered to the bed anymore after all of this, you might have to adjust the bed center using the BED_CENTER_AT_0_0 option.

So while these were all the changes I made to the configuration files, the firmware was still too large - by 158 bytes. But I didn't want to disable anything else, I wanted to keep all the features - so what did I do to make it work?

Well, there is rescue, again in the compiler settings. Thanks to an article by thborges, that's also linked in the description, that talks about optimizing compiler flags for marlin, I've discovered that there is two even more aggressive options we can add.

So I had to change that in the platformio.ini, in the melzi_optimized section and add those two addtional parameters at the end of the build_flags setting.

And the big surprise is - with this change, the build succeeds and there's actually some headroom left - about 1300 bytes.

Probably you could now try to enable stuff that we disabled but the point is, it's always good to have some space left.

I've seen people struggle with firmware being at 99.9% of the available memory and then they got blank screens, random reboots, overwritten bootloaders - all these kind of things. I would say, it's good to stay away from that a little bit for sanity.

Was there any kind of issues doing prints with these settings? So far I didn't realize any negative effect on my print results, I'm interested what your experiences are.

So, I hope you liked this video - put your questions and thoughts in the comment section.

I've also linked two other interesting videos here - and I see you in the next one. Bye!

Liked it? Take a second to support Daniel Kreuzhofer on Patreon!
Scroll Up