CMSIS_5
CMSIS_5 copied to clipboard
The number of `enumeratedValue` elements in the `enumeratedValues` element if the `derivedFrom` attribute is present
PROBLEMS (Validation with XSD grammar) when using the VS Code XML extension: https://marketplace.visualstudio.com/items?itemName=redhat.vscode-xml
SVD File: https://stm32-rs.github.io/stm32-rs/stm32f103.svd.patched
This looks like a bug in the schema. The enumeratedValue
minOccurs should be 0, even if this only true in case the derivedFrom
attribute is specified.
If I understand correctly, XSD does not allow us to specify the relationship between the presence of the derivedFrom
attribute and the number of enumeratedValue
elements.
Do I understand correctly that if the derivedFrom
attribute is missing, then the number of enumeratedValue
elements should be at least one?
[..] XSD does not allow us to specify the relationship [..]
No, not directly. What might work is grouping elements into exclusive groups. But that easily creates new issues/drawbacks.
The schema describes the syntax of a language. The relationship between elements is about semantics.
@JonatanAntoni Could you give an example of how this can be done?
It looks like the feature of reusing enumerated values has not really been used, as it would fail with the current schema. Sorry for the inconvenience. Here is an example of how deriving an enumeratedValues description in a separate field. I am using the ARM_Example.svd included in the ARM.CMSIS.5.9.0.pack in the CMSIS/utilities/ directory. I am reusing the enumeration of the field "EN". To reference the enumeratedValues section, I need to specify the optional name tag in line 115
<enumeratedValues>
<name>EN_enum</name>
For demonstration purposes I am adding a new register description:
<register>
<name>InheritEnum</name>
<description>Control Register</description>
<addressOffset>0xF0</addressOffset>
<size>32</size>
<access>read-write</access>
<resetValue>0x00000000</resetValue>
<resetMask>0xFFFFFFFF</resetMask>
<fields>
<field>
<name>EN</name>
<description>Enable</description>
<bitRange>[0:0]</bitRange>
<access>read-write</access>
<enumeratedValues derivedFrom="TIMER0.CR.EN.EN_enum"/>
</field>
</fields>
</register>
In the above case it would have been smarter to derive the field EN
.
The converter happily converts the above, however the schema requires changes to pass:
a) the derivedFrom
attribute does not support dots .
which are required for referencing a peripheral.register.field.enum
. A new type shall be added to the schema e.g. referenceIdentifierType
b) as suggested above in the enumerationType
the attribute minOccurs=0
nees to be set for the enumeratedValue
element.
As a consequence the schema check no longer detects the case where the element enumeratedValues
which is not derivedFrom
another named enumeratedValues
description, does not contain any enumeratedValue
child elements.
Note that most people are generating the SVD file from some other source and therefore do not make use of deriving field and enumeration descriptions. I would be interested to understand how your use case is different.
@jkrech
Note that most people are generating the SVD file from some other source and therefore do not make use of deriving field and enumeration descriptions. I would be interested to understand how your use case is different.
I'm taking SVD from the project https://github.com/stm32-rs/stm32-rs (more specifically https://stm32-rs.github.io/stm32-rs/) in order to use it in https://marketplace.visualstudio.com/items?itemName=mcu-debug.peripheral-viewer. Sometimes I open SVD in VS Code editor to view and make changes. In VS Code I use the extension https://marketplace.visualstudio.com/items?itemName=redhat.vscode-xml. This extension performs XSD validation, as a result of which many errors are detected (see the very first message).