Skip to content

Add Sharing Data with Interrupts #8

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Mar 8, 2019
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 40 additions & 3 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,13 +26,50 @@ And don't forget to check our [Awesome Embedded Rust][aer] list! The thing you a

* Useful Links
* [Contributing Guide]
* [Item Template](https://github.com/rust-embedded/not-yet-awesome-embedded-rust#not-yet-awesome-item-template)
* [Item Template](#not-yet-awesome-item-template)
* Not Yet Awesome List
* [nothing yet...](#)
* [Sharing Data With Interrupts](#sharing-data-with-interrupts)

# The List

Nothing here yet...
## Sharing Data With Interrupts

### Background

Currently, it is not convenient to share data with an interrupt using safe Rust. Because interrupt handlers are functions that take no arguments, all data consumed by interrupts must either be local `static` variables, or global `static` variables.

Global variables are not great in Rust, because:

* All mutable access must be `unsafe`
* Not all data can be initialized in a `const` context, so it's often necessary to use an `Option<T>`
* Global variables aren't typically idiomatic Rust.

Tools like [cortex-m-rtfm] achieve this in a zero cost fashion by using a Domain Specific Language to automatically provide safe access to shared resources between tasks and interrupts, however these tools can not be used by applications not using RTFM, or by libraries such as HAL or BSP crates.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe also mention atomics? Or it could go in the patterns book. Atomics in statics are fine if you scope them; you can use them in libraries as well. For example

// crate: my-hal-impl

mod timer {
    // not global
    static DONE: AtomicBool = AtomicBool::new(false);

    impl Timer {
        fn wait(&mut self, cycles: u32) {
            DONE.store(false, Ordering::Relaxed);

            // set a timeout

            while !DONE.load(Ordering::Relaxed) {
                asm::wfi();
            }
        }
    }

    #[interrupt]
    fn TIM2() {
        // clear interrupt flag

        DONE.store(true, Ordering::Relaxed);
    }
}

Copy link
Member

@japaric japaric Mar 7, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Also I would change "tools like ..." to "frameworks like ..." (in the text))

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe also mention atomics?

Or you could reword the request to say "share non-atomic data ..."

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Also I would change "tools like ..." to "frameworks like ..." (in the text))

I actually went back and forth on that exact naming difference! Thanks for the deciding factor.

Maybe also mention atomics? Or it could go in the patterns book. Atomics in statics are fine if you scope them; you can use them in libraries as well.

I'll add a bit about this, once there is a section about atomics in the patterns book, I'd be happy to link it here as well.

I think we will need to make a folder of "detailed requests" sooner than later - I'd like to keep the README from becoming 10k-100k lines long, so at some point we should probably move each NYA item to it's own MD file, and just have a title and 1 paragraph summary (and a link to the child MD) on the main readme.


**Useful Links**

* [wg#294] - An Embedded-WG issue discussing this topic
* [bare-metal#15] - One proposed solution hiding the un-idiomatic syntax

[wg#294]: https://github.com/rust-embedded/wg/issues/294
[bare-metal#15]: https://github.com/japaric/bare-metal/pull/15
[cortex-m-rtfm]: https://github.com/japaric/cortex-m-rtfm

### Success Criteria

Ideally, we would be able to support all of the following use cases:

1. Sharing a variable between the main thread and only one interrupt handler
2. Sharing a variable between the main thread and one or more interrupt handlers
3. Moving a variable from the main thread to one interrupt handler

We should be able to serve the three use cases listed above, while:

* Using only safe Rust (at least as a user of the library)
* Add only minimal overhead, if not "zero cost"

<!-- TODO: Uncomment when there is work in progress -->
<!-- ### Work in progress -->

# Not Yet Awesome Item Template

Expand Down