-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Open
Description
What do you think about adding some nice API for accessing the battery backed RAM found in, for example, the stm32h5 series?
I suppose we could always offer some simple API with read/write methods.
However, do you think it would be possible to figure out how to achieve something like this in a safe way?
enum ReasonForDataReset {
/// This is the first time we run or the first time after battery power was lost
BackupRamDisabled,
/// The struct layout does not seem to match
///
/// `all_bytes` may be used to try to recover if the firmware was updated on purpose
StructureMissmatch{ all_bytes: &mut[u8] }
}
...
#[repr(C)]
struct MyStruct {
foo: u32,
bar: MyEnum, // <-- Not all bit patterns are valid for this type
}
// 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 = BackupRam::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);
}
How do we ensure
- The user uses the same type with the same layout every time
- Would it be possible to create a checksum for the types layout and run fn_to_setup_defaults on missmatch or something?
- The type does not contain pointers/references out of the battery backed memory
- Create a trait for types that are safe to store?
- Large structures does not overflow the stack in fn_to_setup_defaults.
- Ensure the compiler does not think it is reading uninitialized garbage.
Metadata
Metadata
Assignees
Labels
No labels