EEPROM support for STM32 and/or AVR

[asmfreak]

The question is in the title - is there any way to create a persistent storage for rarely-changing, but not compiled items?

[salkinium]

There's nothing in modm implemented, since STM32 only supports EEPROM emulation via programming FLASH and we don't have a Flash abstraction. (Flash abstraction would be very useful for many other things too).

For AVRs you can attribute a variable as EEMEM and then it gets placed in the .eeprom section. IIRC Avrdude does not automatically upload Eeprom though, you have to do that explicitly.
The SCons Avrdude wrapper has EEPROM support, but it's currently not used. Would be nice to just pass an .elf file to this wrapper, and it uploads both Flash and Eeprom via pyelftools introspection.

(The SCons Avrdude wrapper also supports but doesn't expose fuse programming either).

[asmfreak]

What do you mean by FLASH abstraction? Some class, describing flash layout?

[salkinium]

What do you mean by FLASH abstraction? Some class, describing flash layout?

An HAL driver API for writing to Flash, with information from modm-devices about Flash section size and number and firmware size etc. Would be useful for bootloaders etc.

Oh wow, I stand corrected, the STM32L0 have a hardware EEPROM (up to 6kB)!
For the remaining STM32 series: https://www.st.com/en/embedded-software/x-cube-eeprom.html

[asmfreak]

Yeah, I've seen that appnote and was hoping modm has a better solution for this.

[asmfreak]

A better solution, than that appnote, I meant. modm in general tends to have solutions to many problems the better IMO than other HALs.

[salkinium]

A better solution, than that appnote, I meant.

I know, my confused smiley was directed towards the ST code quality ;-P

was hoping modm has a better solution for this.

Yeah, that's what got us into this mess of writing our own HAL… 🥴

[asmfreak]

That flash abstraction class should go both in interfaces AND in platform, if I understand correctly?

[salkinium]

Well… I would let a hypothetical modm:platform:flash driver in modm/src/modm/platform/flash/stm32 implement the modm::BlockDevice interface 😊

At least that's what we currently use for external SPI flash drivers (and heap and file system implementations). So it might not be completely the right abstraction for internal Flash.

[salkinium]

There's also the limitation that you cannot write-while-read the Flash, so you probably have to relocate the writing parts of your flash driver code into executable (!) SRAM, which is something that modm doesn't have a section for yet (.fastcode is not always in SRAM).

[salkinium]

Just FYI, there is a very basic Flash driver for the STM32F4 and STM32G0 now, that implements some functional abtraction for erasing/writing Flash: #417.