Add support for programming AVR EEPROM memory if .eeprom section foun…

[cr1901]

…d in ELF file.

Tested locally and working. This is meant to complement a set of crates I'm working on...

[Rahix]

Hi, thanks, this is a very good addition. The only thing I am thinking to change is whether we should provide a commandline parameter to explicitly disable EEPROM writing. I am thinking about use-cases where settings are stored in EEPROM and you want the option to not overwrite them on most uploads (yet still provide the .eeprom section for defaults). What's your take on this?

[cr1901]

What's your take on this?

Sure, I can add a flag to disable EEPROM flashing.

I think most Rust cases using the .eeprom section would want the EEPROM to be reflashed if e.g. cargo triggered a rebuild of the crate(s) providing an .eeprom section. But I can envision use cases where a Rust firmware is provided an .eeprom section as part of an C or asm object file/library, and you don't necessarily want to reflash the EEPROM every time.

[cr1901]

Please do not merge yet, I believe this patch is incorrect/imprecise (It's not .eeprom section name that's special. Rather, I think avrdude is checking the ELF's program headers for data for references to the EEPROM address space).

I'll work on fixing it in the coming days.