Register spec & traits #464
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
rust-highfive
added
S-waiting-on-review
|
Looks good in first view. One question. Have you tested this for result firmware size? In release and debug mode. |
Merged
Edit: wow nope. My test setup was not properly pulling in the modified build. I thought it seemed suspicious how identical it was. Will reevaluate. |
|
arduino uno blink example
|
|
After
|
burrbull
approved these changes
Aug 7, 2020
bors bot
added a commit
that referenced
this pull request
Aug 8, 2020
465: Accessor newtypes r=therealprof a=couchand Part 2 of #463, builds on #464. - Wraps register reader/writer and field readers in newtype wrappers, which significantly improves the documentation output. Again there's some minor potential for breaking changes: - If users named the complete type of the previous type alias, it would break. It seems more likely that they would use the alias, which will silently upgrade to a reference to the newtype. r? @burrbull Co-authored-by: Andrew Dona-Couch <hi@andrewcou.ch>
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.
Part 1 of #463.
Reg, making the register spec the sole authority on the shape of the register (but not its address).One thing that's changed since the previous PR, this renames the spec struct so that it won't cause a conflict on NXP, Freescale, and possibly other architectures. I've gone with
register::REGISTER_SPECsince that seems reasonably clear and I can't think of how it would cause a conflict (but I'm ready to be proven wrong since I've tried several ideas only to be stymied by various architectures' oddball register naming patterns).I'd prefer the spec to be in the parent module, but I can't come up with a way to do that which guarantees that the generated code will be free from naming conflicts. This seems good enough, plus it maintains the rule that when we make up a name it belongs in the child mod (except for
RegisterBlock).There is potential for breaking changes here, though the impact seems pretty minimal. Specifically:
mod generic, their usage would break. Writing code referring to those traits was previously pretty awkward (see Register trait improvements #463), and this PR makes such usage much more ergonomic, so it would seem to be a net benefit.#[docs(hidden)]spec struct the reference would break. I don't see why they would have done so.r? @burrbull