Skip to content
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

SVD for s32k344 leads to uncompilable output due to many duplicated methods #263

Open
photex opened this issue Mar 14, 2024 · 5 comments
Open

Comments

@photex
Copy link

photex commented Mar 14, 2024

Hi!

I'm new to embedded rust, and I probably just don't understand the cli options to svd2rust and how to get working output.

An example from the SVD I'm using that leads to many duplicated functions:

<field>
<name>RR_INITMOD</name>
<description>Initialization Delay Modulus</description>
<bitOffset>16</bitOffset>
<bitWidth>6</bitWidth>
<access>read-write</access>
<enumeratedValues>
  <enumeratedValue>
    <name>MOD_63</name>
    <description>63 cycles (same as 111111b)</description>
    <value>0</value>
  </enumeratedValue>
  <enumeratedValue>
    <name>MOD_1_63</name>
    <description>1 to 63 cycles</description>
    <value>0x1</value>
  </enumeratedValue>
  <enumeratedValue>
    <name>MOD_1_63</name>
    <description>1 to 63 cycles</description>
    <value>0x2</value>
  </enumeratedValue>
  <enumeratedValue>
    <name>MOD_1_63</name>
    <description>1 to 63 cycles</description>
    <value>0x3</value>
  </enumeratedValue>
  <enumeratedValue>
    <name>MOD_1_63</name>
    <description>1 to 63 cycles</description>
    <value>0x4</value>
  </enumeratedValue>
  <enumeratedValue>
    <name>MOD_1_63</name>
    <description>1 to 63 cycles</description>
    <value>0x5</value>
  </enumeratedValue>
  <enumeratedValue>
    <name>MOD_1_63</name>
    <description>1 to 63 cycles</description>
    <value>0x6</value>
  </enumeratedValue>
  <enumeratedValue>
    <name>MOD_1_63</name>
    <description>1 to 63 cycles</description>
    <value>0x7</value>
  </enumeratedValue>
  <enumeratedValue>
    <name>MOD_1_63</name>
    <description>1 to 63 cycles</description>
    <value>0x8</value>
  </enumeratedValue>
  <enumeratedValue>
    <name>MOD_1_63</name>
    <description>1 to 63 cycles</description>
    <value>0x9</value>
  </enumeratedValue>
</enumeratedValues>

Leads to code like:

#[doc = "Initialization Delay Modulus\n\nValue on reset: 0"]
#[derive(Clone, Copy, Debug, PartialEq, Eq)]
#[repr(u8)]
pub enum RrInitmod {
    #[doc = "0: 63 cycles (same as 111111b)"]
    Mod63 = 0,
    #[doc = "1: 1 to 63 cycles"]
    Mod1_63 = 1,
    #[doc = "2: 1 to 63 cycles"]
    Mod1_63 = 2,
    #[doc = "3: 1 to 63 cycles"]
    Mod1_63 = 3,
    #[doc = "4: 1 to 63 cycles"]
    Mod1_63 = 4,
    #[doc = "5: 1 to 63 cycles"]
    Mod1_63 = 5,
    #[doc = "6: 1 to 63 cycles"]
    Mod1_63 = 6,
    #[doc = "7: 1 to 63 cycles"]
    Mod1_63 = 7,
    #[doc = "8: 1 to 63 cycles"]
    Mod1_63 = 8,
    #[doc = "9: 1 to 63 cycles"]
    Mod1_63 = 9,
}

#[doc = "Field `RR_INITMOD` writer - Initialization Delay Modulus"]
pub type RrInitmodW<'a, REG> = crate::FieldWriter<'a, REG, 6, RrInitmod>;
impl<'a, REG> RrInitmodW<'a, REG>
where
    REG: crate::Writable + crate::RegisterSpec,
    REG::Ux: From<u8>,
{
    #[doc = "63 cycles (same as 111111b)"]
    #[inline(always)]
    pub fn mod_63(self) -> &'a mut crate::W<REG> {
        self.variant(RrInitmod::Mod63)
    }
    #[doc = "1 to 63 cycles"]
    #[inline(always)]
    pub fn mod_1_63(self) -> &'a mut crate::W<REG> {
        self.variant(RrInitmod::Mod1_63)
    }
    #[doc = "1 to 63 cycles"]
    #[inline(always)]
    pub fn mod_1_63(self) -> &'a mut crate::W<REG> {
        self.variant(RrInitmod::Mod1_63)
    }
    #[doc = "1 to 63 cycles"]
    #[inline(always)]
    pub fn mod_1_63(self) -> &'a mut crate::W<REG> {
        self.variant(RrInitmod::Mod1_63)
    }
    #[doc = "1 to 63 cycles"]
    #[inline(always)]
    pub fn mod_1_63(self) -> &'a mut crate::W<REG> {
        self.variant(RrInitmod::Mod1_63)
    }
    #[doc = "1 to 63 cycles"]
    #[inline(always)]
    pub fn mod_1_63(self) -> &'a mut crate::W<REG> {
        self.variant(RrInitmod::Mod1_63)
    }
    #[doc = "1 to 63 cycles"]
    #[inline(always)]
    pub fn mod_1_63(self) -> &'a mut crate::W<REG> {
        self.variant(RrInitmod::Mod1_63)
    }
    #[doc = "1 to 63 cycles"]
    #[inline(always)]
    pub fn mod_1_63(self) -> &'a mut crate::W<REG> {
        self.variant(RrInitmod::Mod1_63)
    }
    #[doc = "1 to 63 cycles"]
    #[inline(always)]
    pub fn mod_1_63(self) -> &'a mut crate::W<REG> {
        self.variant(RrInitmod::Mod1_63)
    }
    #[doc = "1 to 63 cycles"]
    #[inline(always)]
    pub fn mod_1_63(self) -> &'a mut crate::W<REG> {
        self.variant(RrInitmod::Mod1_63)
    }
}

This is one example of many in the generated output. Am I holding this wrong? There isn't any output from svd2rust to indicate that I might be doing something wrong.

Here is the command I'm running:
svd2rust -i S32K344_M7.svd -o src --target cortex-m -s --atomics --keep-list

@burrbull
Copy link
Member

Broken SVD leads to broken code. As expected.

@photex
Copy link
Author

photex commented Mar 14, 2024

Ah OK, so the SVD needs to be edited in this case?

The biggest offender is this pattern:

<field>
              <name>LK2</name>
              <description>Lock</description>
              <bitOffset>29</bitOffset>
              <bitWidth>2</bitWidth>
              <access>read-write</access>
              <enumeratedValues>
                <enumeratedValue>
                  <name>ENTIRE</name>
                  <description>Both words can be written to</description>
                  <value>0</value>
                </enumeratedValue>
                <enumeratedValue>
                  <name>ENTIRE</name>
                  <description>Both words can be written to</description>
                  <value>0x1</value>
                </enumeratedValue>
                <enumeratedValue>
                  <name>DXACP</name>
                  <description>Domain d can update only its associated DdACP field-all other fields are read-only</description>
                  <value>0x2</value>
                </enumeratedValue>
                <enumeratedValue>
                  <name>LOCKED</name>
                  <description>Locks (both words are read-only)</description>
                  <value>0x3</value>
                </enumeratedValue>
              </enumeratedValues>
            </field>

This is in hundreds of places in the file. :(

@burrbull
Copy link
Member

In one enumeratedValues different values must have different names.
I can't say what exactly is wrong without comparing with reference manual.

As I understand in both examples there are ranges of values leading to same behavior.
First example is hard to fix.
In second you can replace it with:

              <enumeratedValues>
                <enumeratedValue>
                  <name>ENTIRE</name>
                  <description>Both words can be written to</description>
                  <isDefault>true</isDefault>
                </enumeratedValue>
                <enumeratedValue>
                  <name>DXACP</name>
                  <description>Domain d can update only its associated DdACP field-all other fields are read-only</description>
                  <value>0x2</value>
                </enumeratedValue>
                <enumeratedValue>
                  <name>LOCKED</name>
                  <description>Locks (both words are read-only)</description>
                  <value>0x3</value>
                </enumeratedValue>
              </enumeratedValues>

as ENTIRE covers all values that not considered by other enumeratedValue.

@photex
Copy link
Author

photex commented Mar 14, 2024

Thanks for explaining. I think it's worth closing this issue, unless there is a reason to discuss a way for svd2rust to catch these cases and report warnings?

@burrbull
Copy link
Member

It is better to catch this in svd parser.

@burrbull burrbull transferred this issue from rust-embedded/svd2rust Mar 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants