How to allocate opaque resources in init

[TomCrypto]

Hi, I'm trying out this framework, looks pretty neat but I have a problem. I have an opaque type (it's a compiler-generated generator struct). I'd like to initialize it on startup in the init method and then be able to access it in another interrupt as a normal resource. The problem is I can't put it in a static mut because I cannot name its type.

In my previous code without RTFM I got it working by simply allocating it on the stack (so just in a normal let with inference) in the reset handler. And since the reset handler is never exited from but just goes into a WFI loop (or into idle which never returns), it's perfectly safe to transmute the resulting &'_ mut into a &'static mut. I tried the same thing in RTFM but unfortunately it does drop the init block scope, so this approach does not work.

Currently I am using a boxed trait object as a workaround, but it's very sad that I need to pull in the alloc heap machinery when (1) the compiler knows the object's size and (2) there is a perfectly good place for it in either BSS (if I could name its type) or the reset handler's stack frame (if I can't).

I tried hard to get it working with existential types, unfortunately the resulting code is very obtuse and triggers an ICE on nightly anyway.

Any way to get this working? It feels like there could be a provision added to init to allow preserving at least some part of the stack frame as "effective statics" implemented as let... e.g. couldn't the leading static muts at the top of init be implemented as just let statements that exist in a global stack frame rather than restricting them to being actual statics? (this would be optimal for my case if this were possible and it doesn't seem like it would break anything.. maybe there's some cases where it's unsafe though? any thoughts?)

Thanks

[little-arhat]

Maybe this issue can help you? https://github.com/japaric/cortex-m-rtfm/issues/164

We use existentials in our rtfm app (see, for example, https://github.com/copterust/fcfs-rtfm/blob/master/src/main.rs#L44)

[TomCrypto]

@little-arhat Thanks for the reply, I did see that issue before and it is what prompted me to try out the existential type approach, unfortunately in my case it results in a broken MIR, equate_inputs_and_outputs: MaybeUninit<T> == MaybeUninit<T> failed with NoSolution compiler error on nightly 2019-07-18 and others (it's strange actually, the first build triggers the error and then it builds fine and actually works... but that's not acceptable imho).

EDIT: actually now that I copied your approach exactly it works, but only because the existential type is in a separate module... as soon as I move it into the main.rs next to the #[app] it dies. This is the ICE I'm getting, it appears to be known: rust-lang/rust#60407. Iffy... I'll see if I can make progress with this and let you know though.

[TomCrypto]

Closing because this has been addressed to my satisfaction. It's still a bit iffy but that's not on RTFM.