Clear EEPROM when uploading new code/burning bootloader

[K4ktus123]

This is more like an enhancement request than an issue.
I noticed that when I upload new code or burn new bootloader, EEPROM contents remain unchanged. Could clearing the EEPROM be added as an option in tools menu?

[SpenceKonde]

What I do for this is have a tools submenu to control the EESAVE fuse. Take a look at my cores to see how you can stitch together the bits if you have multiple submenus controlling an option in the same fuse.
Note that this change would require doing "burn bootloader" to set the changes on a board once @MCUdude adds it (which he really ought to do - it's not hard to see use cases where clearing EEPROM or saving EEPROM would be highly desirable.
Note that the preceeding only applies to programming via ISP - if programming via bootloader, the EEPROM contents are always retained. You can't fit a bootloader that can write the EEPROM into 512b (though, now that I think about it, one might be able to fit code that simply erases it all any time any sketch is uploaded - I'm pretty sure nobody has ever bothered to try cramming that into optiboot. I don't know off hand how close to 512b the version of Optiboot minicore uses is - nor do I have a particular interest in going down that rabbit hole.

[K4ktus123]

I do indeed mean uploading with ISP.
@SpenceKonde Your ATTiny core is exactly where I got that idea from. I have a project where having EEPROM retained when uploading modified code is really painful to deal with. I thought it would be nice to have an option to erase it in MiniCore as well.

[SpenceKonde]

What makes it awkward is that these are organized with a submenu to choose bootloader - and then he'd have an EEPROM save menu that was meaningless if bootloader is used - but a few words to say that would fit in the menu.

OFC, if the bootloader could be made to clear eeprom, you could just use that version if clear EEPROM was selected - but there's only enough space left for 12 instruction words... so I don't think EEPROM clearing optiboot is possible!

[SpenceKonde]

Huh! Note that the smallest boot sector on 64k+ parts is 1024b not 512, so on those, they could not only add an ersatz !EESAVE function, there would be room for EEPROM write, and you could probably even make ersatz !EESAVE detect whether the fuse is set and follow it so you wouldn't need two binaries! But that all depends on someone both capable of that work (I mean, it's not that hard, since EEPROM write is already available with a define - it'd just be the EEPROM clearing... but you need to be comfortable in the absence of any arduino training wheels). Making a working build environment in windows is a pain (heh, I should probably zip up the hideous monstrosity of a build environment that I use and share it). Actually, I'll bet I make the build environment much cleaner... with a little ingenuity I could even make it grab the latest toolchain installed via board manager and use that, so it wouldn't have to drag along 35mb+ of baggage... maybe next time I am about to embark on a bootloader modification campaign!