-
Notifications
You must be signed in to change notification settings - Fork 151
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
First pass at implementing derivedFrom. #190
Conversation
Hey @nsabovic, sorry there hasn't been any response yet. I'll try to review and test this over the next few days, and also follow rust-embedded/svd#49 to see if anything happens there. Thanks for contributing! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to do the job, except for the (totally forgivable) rust newbie mistake with the semicolons I mentioned inline.
With that fixed, its generating code like this for me with the atsamd21 svd:
impl Deref for SERCOM4 {
type Target = sercom0::RegisterBlock;
fn deref(&self) -> &sercom0::RegisterBlock {
unsafe { &*SERCOM4::ptr() }
}
}
src/generate/peripheral.rs
Outdated
// an error in that case | ||
(Ident::new(&*base.to_sanitized_snake_case()), true) | ||
let base = if derive_regs { | ||
Ident::new(&*p_derivedfrom.unwrap().name.to_sanitized_snake_case()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to remove the ;
from the end of the line here and in the else branch below because they're causing base
to have the type ()
rather than the Ident
type that you're constructing here, and that causes things to explode because the generated code comes out like this:
impl Deref for SERCOM4 {
type Target = ( ) :: RegisterBlock ;
...
``
@nsabovic are you planning to do something similar for registers? |
FWIW, I'd vote for inlining the helper from rust-embedded/svd#49 into this PR and it will be easier to land and integrate just a single PR; PR dependencies are a PITA :)
|
Over in rust-embedded/svd#50 I've added parsing out the That resolves the bad sizing issue that @kevinmehall mentioned in #181 (comment). Actually, I think all three of those points have now been addressed and we just need to review, clean things up and land them. |
@wez thanks for catching that 👍 Registers, clusters and fields can all derive from others, would be nice to make a more general solution. My chip's SVD (SAM D10) doesn't have ...but it does have |
...which were preventing the correct mod being generated for derived registers.
Ping from triage: This need to be review. Also merge/rebase is needed. |
Ping from triage: @nsabovic could you rebase your changes? |
bors try |
tryBuild failed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like a few things need to be fixed after rebase (sorry @nsabovic!)
@@ -76,10 +76,10 @@ pub fn render(
}
// erc: *E*ither *R*egister or *C*luster
- let ercs = p.registers.as_ref().map(|x| x.as_ref()).unwrap_or(&[][..]);
+ let ercs: Vec<Either<Register, Cluster>> = p.registers.as_ref().map(|x| x.as_ref()).unwrap_or(&[][..]);
let registers: &[&Register] = &util::only_registers(&ercs)[..];
- let clusters = util::only_clusters(ercs);
+ let clusters = util::only_clusters(&ercs);
// No `struct RegisterBlock` can be generated
if registers.is_empty() && clusters.is_empty() {
@@ -90,7 +90,7 @@ pub fn render(
// Push any register or cluster blocks into the output
let mut mod_items = vec![];
- mod_items.push(register_or_cluster_block(ercs, defaults, None, nightly)?);
+ mod_items.push(register_or_cluster_block(&ercs, defaults, None, nightly)?);
// Push all cluster related information into the peripheral module
for c in &clusters {
all_peripherals.iter().find(|x| x.name == *s) | ||
}); | ||
|
||
let p_merged = p_derivedfrom.map(|x| p_original.derive_from(x)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
where does the Peripheral::derive_from(&mut self, p: Peripheral)
method come from? (this might have got disappeared during rebase..?)
@nsabovic Sorry for the long delay. Are you still interested in working on this? If so would you mind bringing the PR into a working state? |
#256 is the successor to this PR |
I am not really set up to look at this right now. If you need it urgently, I'm not the best bet. |
Trying to fix #181, this is the first pass at implementing derivedFrom. These also the very first lines I've ever written in Rust, so be gentle.
This patch requires rust-embedded/svd#49.
With this patch, I get a bit further in generating the peripherals for SAM D10.