WIP - Added backup sram

[usbalbin]

I do not have any experience with the structure of embassy-stm32, its build script, linker script etc. Hopefully at the very least this can serve as something to discuss around for how to actually solve something like this :)

With that said, here is the beginning of my attempt at adding support for the battery backed sram available for several of the stm32 families.

#[repr(C)]
struct MyStruct {
    foo: u32,
}

// This will be run the first time to set the defaults and on struct layout missmatch
let fn_to_setup_defaults = |_reason: ReasonForDataReset| MyStruct { foo: 42 };

// Here we get a mutable reference to the value stored in battery backed ram
let x: &'static mut MyStruct = backup_sram::init::<MyStruct>(p.BACKUP_RAM, fn_to_setup_defaults);

loop {
    x.foo += 1; // These writes will persist resets and loss of vcc
    defmt::info!("I have ran {} iterations since I was programmed/battery was inserted", x.foo);
}

[Dirbaio]

nice! a few tips:

• it'd be better to add the the address+size of the backup sram to stm32-data here, so we can then use it from embassy-stm32 without massive cfg spam. https://github.com/embassy-rs/stm32-data/blob/main/stm32-data-gen/src/memory.rs
• it's simpler to just offer raw byte access. Instead of unsafe trait Storable and checksums I'd just offer the user &mut [u8] (if the hardware allows it, otherwise read/write fns could work), and let the user take care of serialization/checksumming themselves. This way is less opinionated, it allows the user to do more things that wouldn't be possible with this "store struct, load struct" api.

[usbalbin]

it'd be better to add the the address+size of the backup sram to stm32-data here, so we can then use it from embassy-stm32 without massive cfg spam. https://github.com/embassy-rs/stm32-data/blob/main/stm32-data-gen/src/memory.rs

Thanks! Something like this? embassy-rs/stm32-data#671

it's simpler to just offer raw byte access [...]

Fair enough :)

[usbalbin]

Do you want this in this file or should it be in backup_sram.rs?

Also, related question, I think it would be nice to let the user know if the retention was already enabled(SRAM contains data since last run) or if not. I think that would probably be easier if this was done as part of backup_sram::init()?

[usbalbin]

think it would be nice to let the user know if the retention was already enabled

Done using WAS_BKPSRAM_ALREADY_POWERED_BY_BATTERY

[usbalbin]

Am I doing this wrong? The #[cfg(backup_sram)] in embassy-stm32/src/lib.rs does not seem to activate even if I remove the if has_bkpsram check here.

[usbalbin]

I will try to test in the near future.

In the mean time, what do you think of this now?