Add support for SVD dimIndex parsing

[zovko]

DimElementGroup support for peripheral, register and field types (without dimName)

New features:

• List type (%s parsing) for DimElementGroup
  • Supported by register and field types. register dim description field dim description
  • %s can be anywhere in string, dimIndex must be defined.
• Array type ([%s] parsing) for DimElement group
  • Supported by peripheral and register peripheral dim description
  • [%s] must be at the end of the string
• List and array type described here

Changed implementation:

• Fields cannot have DimElementGroup array type.
• elements.dim_increment * 8) != size removed. This is not always true, specifically for list types.

Note: This heavily breaks esp examples, rasperrypi seems to still compile.

Partially solves #220

Still to implement:

• dimName, displayName
• CSV parsing for dimIndex

[mattnite]

Looks good to me, just get the fixes that @Grazfather has suggested in. It looks like this changes the generated code for esp which will need updating, when I have time I could try to add that to the PR for you tomorrow.

For the stm32 CI failure all you need to do is run zig build -Dgenerate in the port/stmicro/stm32 directory and commit the changes.

[zovko]

@mattnite The changes do not look good for stm32 now, for example SQR1 is definitely different now. What to do about that specifically? I added the commit here but I believe the stm32 builds will be broken now.

[mattnite]

@zovko apply this patch and it should fix the last CI failure. It looks like the old code was trying its best to make repeated registers into arrays, and so I changed some registers to use [%s] instead of <name>%s to create arrays instead of creating distinct registers.

diff --git a/port/espressif/esp/src/chips/ESP32-C3.svd b/port/espressif/esp/src/chips/ESP32-C3.svd
index ab064fa..ff363b2 100644
--- a/port/espressif/esp/src/chips/ESP32-C3.svd
+++ b/port/espressif/esp/src/chips/ESP32-C3.svd
@@ -11190,7 +11190,7 @@
         <register>
           <dim>26</dim>
           <dimIncrement>0x4</dimIncrement>
-          <name>PIN%s</name>
+          <name>PIN[%s]</name>
           <description>GPIO pin configuration register</description>
           <addressOffset>0x74</addressOffset>
           <size>0x20</size>
@@ -11264,7 +11264,7 @@
         <register>
           <dim>128</dim>
           <dimIncrement>0x4</dimIncrement>
-          <name>FUNC%s_IN_SEL_CFG</name>
+          <name>FUNC_IN_SEL_CFG[%s]</name>
           <description>GPIO input function configuration register</description>
           <addressOffset>0x154</addressOffset>
           <size>0x20</size>
@@ -11295,7 +11295,7 @@
         <register>
           <dim>26</dim>
           <dimIncrement>0x4</dimIncrement>
-          <name>FUNC%s_OUT_SEL_CFG</name>
+          <name>FUNC_OUT_SEL_CFG[%s]</name>
           <description>GPIO output function select register</description>
           <addressOffset>0x554</addressOffset>
           <size>0x20</size>
@@ -12846,7 +12846,7 @@
         <register>
           <dim>8</dim>
           <dimIncrement>0x4</dimIncrement>
-          <name>COMD%s</name>
+          <name>COMD[%s]</name>
           <description>I2C_COMD%s_REG</description>
           <addressOffset>0x58</addressOffset>
           <size>0x20</size>
@@ -15904,7 +15904,7 @@
         <register>
           <dim>22</dim>
           <dimIncrement>0x4</dimIncrement>
-          <name>GPIO%s</name>
+          <name>GPIO[%s]</name>
           <description>IO MUX Configure Register for pad XTAL_32K_P</description>
           <addressOffset>0x4</addressOffset>
           <size>0x20</size>
@@ -36929,4 +36929,4 @@
       </registers>
     </peripheral>
   </peripherals>
-</device>
\ No newline at end of file
+</device>

[zovko]

@mattnite Should that patch even be done? It doesn't sound right to update the vendor SVD with local changes. What would be the reason to change the registers from sequence to array? This can also easily introduce bugs if the dimIncrement is different than register size (not the case for suggested patch though). But regardless, this practice can introduce more bugs in future. For example, the modifications in patch cannot be done for CH%s_RX_CONF0 (in C3 SVD version 18).

I would even advise to update the SVD file itself for C3. Latest version is version 18 (link) while the current SVD file in the repo is version 8. I would rather update the examples than the SVD itself to make the examples compile.

Also, with SVD modification it will also break the direct link to the documentation, for example:
-FUNC%s_IN_SEL_CFG
+FUNC_IN_SEL_CFG[%s]

Documentation can be easily searchable for FUNC0_IN_SEL_CFG, while FUNC_IN_SEL_CFG will not be found.

[mattnite]

Yes it's okay to apply this patch. I want to get this functionality into Regz, and we'll eventually move over to directly fetching those SVD files from that repo.

[zovko]

@mattnite applied the patch to C3 SVD