rust-embedded / rust-embedded/cortex-m

Peripherals as scoped parameters to main

Open
#403 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
1k
Forks
202
Avg merge
6d 2h
Merged PRs (30d)
2

Description

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 :-)

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the #[entry] handling in cortex-m-rt and the svd2rust Peripheral API linked in the issue, then review RFC 157. Determine whether scoped peripherals can cross the dependency boundary between cortex-m-rt and device crates without the current global initialization flag. Done would be a decided design or RFC path, with the required changes and ownership identified.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
embedded-iot
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.