Add raltool to replace imxrtral.py #29
Merged
Conversation
This file contains 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
git-subtree-dir: raltool git-subtree-split: 73b33d9
Child commits apply the patches that turn it into raltool. This merge tracks to a commit on the chiptool master branch. Merge commit '0ceb38148dd666895640afd1fc4e6ae265f7676c' as 'raltool'
Using stable.
The BitSize newtype helped with refactoring, and could be removed if deemed too noisy. After this commit, the size of a set of fields is based on the size of the register. Before this commit, the registers for an MIMXRT PWM peripheral were all incorrectly u32s. After this commit, I observed that code generated for an MIMXRT PWM peripheral used u16 throughout. It still might use u8 for individual fields, but that doesn't affect the MMIO register interactions. Only tested by extracting peripherals, then generating blocks based on the YAML output; haven't tested a full SVD -> PAC transform, but I would expect that to work.
Combine lets us consolidate enums, fieldsets, and blocks across devices. Given multiple IRs, combine figures out the various versions of these IR elements, then creates a new IR that shares as much as it can. The heuristics for combining these IR elements is encoded in the combine module.
When a block is used across multiple peripheral instances, remove any number suffix.
Remove the strong types, favoring a RAL-like pattern for accessing register fields and enums. This is achieved by nesting the render calls during codegen.
I plan to subtree this project directly into imxrt-ral. That project's CI will cover this build.
If you discard type information, it's nice to have a way to re-acquire the N associated with a peripheral. This commit introduces the `number` functions for that purpose. This can let users create thin drivers just around a register block static reference, and only acquire the number at runtime. Document this new function as an advanced usage, along with one other (unrelated) usage pattern.
Hide the `steal()` method; it's only available for RTIC. Users should call their own `instance()` methods.
18 tasks
|
One notable A follow-on PR re-generates the RAL using |
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 PR adds
raltoolto the repository.raltoolis a fork ofchiptool, which is a fork ofsvd2rust. The tool emits animxrtral.py-compatible register access layer, allowing us to replaceimxrtral.py.This PR does not yet use
raltool. A dependent PR will removeimxrtral.py, re-generate the RAL withraltool, and add support for the 1176 multi-core MCUs.Why
I found that
raltoolcould help us with issues noted in #26:imxrtral.pydoesn't handle that complexity.The
chiptoolintermediate representation made it easy to handle issue 1. The IR also made it easier to implement a new "combine" phase that consolidates peripherals across devices. The combine phase and thechiptooltransforms let us solve 2 without patching SVDs to meet our project's needs.In regards to 3: the RAL generated by
raltoolhas no notion of resource management. This is similar tochiptool's original codegen but dissimilar to the originalimxrtral.pycodegen. You'll see this when studying RAL code and documentation in the next PR. We can explore resource management separately / later.Quick testing shows that
raltool-generated crates build faster thansvd2rust- andchiptool-generated crates. The README has my measurements.Upstreaming
imxrt-rs/imxrt-hal#121 proposed upstreaming the RAL codegen to
chiptool. Unless people are eager to use and maintain the RAL backend withinchiptool, I'd prefer to develop RAL codegen ideas here and propose them once they're tested. I'd also like time to think about separating the IR and transformers from the codegen so that codegen modules could be developed independently.Nevetheless, I kept upstreaming in mind. Use
git subtreeto separate patches for contributions, and to bring in any upstreamchiptoolcommits.