Allow writing to the CONTROL register #164
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @adamgreig (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
S-waiting-on-review
|
Hi, thanks for the PR! |
|
Fixed. I should properly test this, though... |
|
Okay, did some manual testing and it seems to work fine |
adamgreig
reviewed
Sep 11, 2019
adamgreig
reviewed
Sep 11, 2019
adamgreig
approved these changes
Sep 13, 2019
bors bot
added a commit
that referenced
this pull request
Sep 13, 2019
164: Allow writing to the CONTROL register r=adamgreig a=jonas-schievink This allows entering unprivileged mode. Part of #58 Co-authored-by: Jonas Schievink <[email protected]>
Build succeeded |
|
Hey! i need the |
|
@kanishkarj Since this is not a breaking change it could be in 0.6.2 |
Closed
adamgreig
pushed a commit
that referenced
this pull request
Jan 12, 2022
224: Allow general exception / interrupt discovery in cortex-m-rt-macros r=korken89 a=mciantyre We propose changes to the `cortex-m-rt-macros` crate that should help us use the macros independent of the `cortex-m-rt` runtime. The changes in this PR should be backwards compatible for all `cortex-m-rt` users, while expanding the utility of the macros beyond the cortex-m-rt repository. In the [Teensy 4 libraries](https://github.com/mciantyre/teensy4-rs) we're developing, we've opted to create our own runtime crate, `teensy4-rt`. We require more support than what's available in `cortex-m-rt` to boot and take advantage of NXP iMXRT106x variants. Specifically, we have a unique start-up process, and a custom memory layout with tightly-couple memory (TCM) regions. As discussed in #164, the `cortex-m-rt` crate does not support custom memory layouts. To address the limitations and provide a faster proof-of-concept, we forked the `cortex-m-rt` crate, focusing on the runtime needs of our specific system. Despite the fork, we strive for compatibility with the `cortex-m-rt` crate. Our eventual goal is to drop the `teensy4-rt` crate, and rely on a future version of the `cortex-m-rt` crate that supports our use-case. Compatibility means supporting the macros; just as the `cortex-m-rt` crate exports the macros, the `teensy4-rt` crate exports the same macros. By requiring that the macros maintain `extern crate cortex_m_rt` declarations, we assume that the `cortex_m_rt` crate is available. However, we don't believe this is a necessary requirement. To take advantage of the `#[interrupt]` and `#[exception]` macros, a set of crates need to export two identifiers: `interrupt`, an enumeration of valid interrupt handlers; and `exception`, an enumeration of exceptions for the Cortex M variant. We have a precedent for this pattern, in that crates generated by `svd2rust` export the enumeration of valid interrupt handlers (provided the correct features are enabled) for discovery by the `#[interrupt]` macros. The PR proposes a similar strategy: export the `Exceptions` enumeration as `exception` (lower case) from the `cortex-m-rt` crate, so that exception variant discovery occurs the same as it does for interrupts. After the rename, and with the removal of `extern crate cortex_m_rt` in the two macros, it doesn't matter where the `exception` or `interrupt` enums are defined. The changes let us define a similar `exception` enumeration in our `teensy4-rt` crate, which may be picked up by the `#[exception]` macro. We've shown this to be a successful strategy in the Teensy 4 Rust libraries, which are based on our fork of the macros crate. We realize that the macros are a feature of the `cortex-m-rt` crate, not a library that others should directly depend on. Ideally, we rally around the `cortex-m-rt` crate, and keep the macros coupled to that implementation. But until we reach that point, having the macros defined without expectations of the `cortex-m-rt` crate lets us bring up new embedded targets faster while maintaining compatibility with the existing ecosystem. Co-authored-by: Ian McIntyre <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This allows entering unprivileged mode.
Part of #58