Peripherals as scoped parameters to main

[bergus]

Hello!
When using cortex-m-rtfm, I found it incredibly useful and intuitive that the peripherals from the respective device crate are passed into the init function. It's like taking argc and argv parameters in a main function.
Would it be possible to have the same for #[entry]-attributed functions? The current Peripheral API, introduced in the [RFC] Peripherals as scoped singletons is comparably clumsy. I dislike that global initialisation flag and the panicky unwrapping of the Option, and even in case the optimiser is able to eliminate them (I haven't checked) it would be cleaner code if one could just omit the static mut DEVICE_PERIPHERALS: bool from the device crates. I am hoping for something like

#[entry]
fn main(peripherals: stm32f30x::Peripherals) -> ! {
    // initialization
    loop {
        // application logic
    }
}

I'm not sure whether this is feasible at all (especially regarding the dependency hierarchy between cortext-m-rt and the device crates), where the right place to discuss this is (svd2rust? embedded-wg?) and what needs to be done to make this happen (should this be a RFC?). Please provide some guidance :-)

[korken89]

IMO this is a much cleaner entry point for peripherals. If you'd like to, please create an RFC even if it has been a lot of time since this issue was started. :)

[korken89]

This also gives the idea of a starting "world context" that can be moved, split, and passed around.
Stealing a bit of RTFM syntax would yield:

#[entry(device = my_pac_crate)]
fn main(core: cortex_m::Peripherals, device: my_pac_crate::Peripherals) -> ! {
    // ...
}

or alternatively:

#[entry(device = my_pac_crate)]
fn main(cx: entry::Context) -> ! {
    let core = cx.core;
    let device = cx.device;

    // ...
}

This would also give users the choice to put these in globals if they want, and not be forced to it as they are today,

[perlindgren]

IMHO, we have two levels of abstraction, cortex-m/cortex-m-rt, which provides the low level HW interaction, and we have RTFM as the lowest level user facing API. So there is no need to extend the level of abstraction provided by cortex-m/cortex-m-rt.

RTFM is designed NOT to stand in your way, and does not by itself imply any overhead (rather the opposite, as it provides zero-cost safe resource sharing).

If you want to build/use other abstractions to concurrent programming (generators/async-await etc.) there is nothing stopping you from do that on-top of RTFM. It just adds the clear advantage of keeping the abstractions sound by construction.

Of course all of these crates are moving targets as we progress, and we (The RTFM Team) are very happy to discuss suggestions/improvements facilitating embedded programming in Rust.

[therealprof]

@perlindgren Would you mind keeping RTFM diversion and promotions out of the cortex-m-rt context, please?

[thejpster]

@therealprof, to be fair the OP is talking about how much they liked cortex-m-rtfm, but let's try and stay on-topic.