[RFC] "rooting" memory (`&'static mut-` references in `init`) about rtic HOT 4 CLOSED

Not sure what rooting means but effectively you're creating a global shared state but rather than letting it hang freely in the breeze you're attaching it to a context which is nice. There're many use-cases for this and it'd be really great if a sane method was also available in cortex-rt. I fully understand why static mut is unsafe and discouraged in regular applications but in case of MCUs the case is a little different since due to interrupts there's really no single point of control where you could pass the necessary handles from.

The only halfway sane way I can handle this it at the moment is something like this:

pub struct PWMCache {
    bitmask: [u32; 256],
}

pub fn pwmcache() -> &'static mut PWMCache {
    static mut SINGLETON: PWMCache = PWMCache::new();
    unsafe { &mut SINGLETON }
}

That way one can also control access to the data but it would be nice to have a generic way of declaring global resources (also for cortex-m-rt 😉).

from rtic.

Not sure what rooting means

Ah, it's just that in this proposal I suggest placing the data that will never be freed in one of the first stack frames or near the "root" of the call stack. It may not be the best name though.

effectively you're creating a global shared state but rather than letting it hang freely in the breeze you're attaching it to a context which is nice.

That's not the intention of this RFC though. The goal here is being able to safely create &'static mut references -- it doesn't really matter if they are allocated on the stack or on .bss / .data (static variables).

Safe creation of &'static muts opens a new possibility in APIs because &'static mut is very close to owning the value minus worrying about destructors ever running. Also you can store these references in static variables.

The idea of "scoping" static variables or constraining them to certain execution contexts is a core idea of the RTFM framework (it was one of the hard lessons learned between v1 and v2: global visibility is bad).

There're many use-cases for this and it'd be really great if a sane method was also available in cortex-rt.

But the result would be RTFM, no? If you need to share state between execution contexts then you may need to locking -- whether or where locking is required has to be computed from the priorities and that's what RTFM does. If you don't need sharing then you already have interrupt / exception local variables (which effectively add state to your handler) via the interrupt! and exception! macros of the cortex-m-rt device crate. Or is the problem with interrupt local variables due to const eval (const fn)? If that's the case then some runtime initialization like what's proposed here would make sense in cortex-m-rt / svd2rust.

pub fn pwmcache() -> &'static mut PWMCache {

This is still very dangerous. If you ever call pwmcache more than once then you risk running into UB due to mutable aliasing -- the problem may not be so obvious as calling pwmcache twice within a function foo; you'll also run into problems if foo calls pwmcache and, for example, a function bar calls foo twice.

from rtic.

Safe creation of &'static muts opens a new possibility in APIs because &'static mut is very close to owning the value minus worrying about destructors ever running. Also you can store these references in static variables.

Right. ;)

If you need to share state between execution contexts then you may need to locking -- whether or where locking is required has to be computed from the priorities and that's what RTFM does.

No, I don't need any locking; There's exactly one reader and one writer and the storage is a simple array of integral types. The reason I want to share it is that the values are recalculated on much slower cadence (and only after an update of the value they're calculated from) than I need to output them. I could probably use rtfm but that complicates a lot of things without any obvious benefit.

Or is the problem with interrupt local variables due to const eval (const fn)? If that's the case then some runtime initialization like what's proposed here would make sense in cortex-m-rt / svd2rust.

There're many problems I have with that. I find the macros rather unflexible since I can't use them in in my initialisation code, can't do any any conditional (non-constant) initialisation (e.g. a random value) and can't use fancy datatypes e.g. arrays.

This is still very dangerous. If you ever call pwmcache more than once then you risk running into UB due to mutable aliasing -- the problem may not be so obvious as calling pwmcache twice within a function foo; you'll also run into problems if foo calls pwmcache and, for example, a function bar calls foo twice.

I'm afraid I don't understand how that could be a problem since this is really only an abstraction to get rid of the nasty unsafe {}s everywhere in contrast to simply defining a global static mut. The generated code not only looks fine and does exactly what it's supposed to. But if there's a better way to get a fixed chunk of shared RAM I'd be certainly happy to change that. 😉

from rtic.

Closing in favor of #59

from rtic.