rust-embedded
Identical enum names
#627 made code much clearer in most of cases, but looks like it breaks on some SVDs which have different fields with identical enum names. cc @luojia65
For example some NXP SVDs (see https://github.com/posborne/cmsis-svd/blob/master/data/NXP/LPC178x_7x.svd) have many enumeraredValues with name ENUM:
Looks like problem is that there are multiple different enums with the same name under one register. I may suggest one of following ideas:
- we generate field name instead if such condition exists, or
- we note that same enumeratedValues name should not exist, and the users should patch their SVD files instead
In enumeratedValues element section of CMSIS-SVD standard 1.3.9, it says:
This information generates an enum in the device header file.
Suggested from quoted notes above, the standard indicates that each enumeratedValues information section should generate one enum structure under device level code description. As most programming language disallows multiple enum structure exist with the same name under one namespace, I may suggest the second idea more as it matches the suggestion in CMSIS-SVD standard.
I see also: 3. use config option to rule where take names from enumeratedValues or field
@burrbull: I discovered this note on descriptions of dimArrayIndex:
User is responsible for uniqueness across description.
Will this help to solve our issue here?
Looks like problem is that there are multiple different enums with the same name under one register. I may suggest one of following ideas:
1. we generate field name instead if such condition exists, or 2. we note that same enumeratedValues name should not exist, and the users should patch their SVD files instead
Can't it be a valid solution that an enum variant with a payload which covers all the values that "map" to the same name is used?
E.g. for the SVD section below, this enum would be generated:
enum RR_INITMOD {
mod_63,
mod_1_63(u8),
}
<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>
....
I was thinking was correct as this bit suggests there is no constraint on the values to map to different names, but for each value there is a name to show:
An enumeratedValue defines a map between an unsigned integer and a string.
In enumeratedValues element section of CMSIS-SVD standard 1.3.9, it says:
This information generates an enum in the device header file.
Suggested from quoted notes above, the standard indicates that each enumeratedValues information section should generate one enum structure under device level code description. As most programming language disallows multiple enum structure exist with the same name under one namespace, I may suggest the second idea more as it matches the suggestion in CMSIS-SVD standard.
