search

EmbeddedNim / svd2nim

Convert CMSIS ARM SVD files to nim register memory mappings
MIT License
19 stars 2 forks source link

Official SVD from espressif fails to be parsed by svd2nim, but works correctly in svd2rust #4

Closed arkanoid87 closed 1 year ago

arkanoid87 commented 1 year ago

Non sure if this is a problem of svd2nim, or is just espressif stretching the official xml schema outside the original use.

Here an open issue in the official repository talking about these mis-alignment: https://github.com/espressif/svd/issues/27

auxym commented 1 year ago

Seems there are a few things at play.

First, I fixed the crash due to unknown CPU when trying to look up CPU interrupts: https://github.com/EmbeddedNim/svd2nim/commit/511e00c6f977b2f93ddc4132b9d0b5d636fa071e

But it's still failing because the esp32.svd file uses derivedFrom in an enumeratedValues item, which is valid per the SVD spec (https://arm-software.github.io/CMSIS_5/SVD/html/elem_registers.html#elem_enumeratedValues) but not currently implemented by svd2nim (its usage is pretty rare), and doing so will take a bit of work.

arkanoid87 commented 1 year ago

taking for looking at this

these two issues are exactly what schema validator complains about, but actually I'm quite surprised by the derivedFrom one, as it really is valid according to SVD spec.

bad xsd, good html spec?

auxym commented 1 year ago

Good news, you can try the esp32-compat branch, I implemented derivedFrom for enums and it doesn't crash on the esp32.svd file anymore :)

Still not 100% working though, because I also noticed that the SVD contains dimLists/dimArrays (basically repeats) of field elements, which is also not currently implemented. At least svd2nim doesn't crash, it warns about the situation and there's probably stuff missing in the generated code. Warnings like this:

WARNING: Register field INT_RAW.CH%s_TX_END_INT_RAW of peripheral RMT contains dimGroup, not implemented.

You'll also notice that svd2nim generates a lot of warnings like this:

WARNING: Property "access" for register AES.IDLE is undefined. Defaulting to read-write.

To get rid of those, you can simply add a default <access> tag at the <device> level (https://arm-software.github.io/CMSIS_5/SVD/html/elem_device.html). STM32 SVDs seem to have the same issue. The SVD spec requires that access is specified somewhere but they don't bother adding a default for some reason.

auxym commented 1 year ago

I added support for field dimLists. Codegen looks good to me with these changes.

Thanks for reporting and please open another issue if you find other problems with the esp32 SVDs.

arkanoid87 commented 1 year ago

super!

Joebeazelman commented 3 months ago

Has anyone noticed the esp32s3.svd has a "%s" in some of the name fields?

auxym commented 2 months ago

@Joebeazelman yeah that's a feature of the SVD spec called dimElements: https://arm-software.github.io/CMSIS_5/SVD/html/elem_special.html#dimElementGroup_gr

It's used to generate a repeating array of contiguous items (registers), without defining all of them manually, for example PORT1, PORT2, PORT3, or whatever.

It's commonly used and should work well with svd2nim.

Joebeazelman commented 2 months ago

Why did they base SVD on the XML standard only to violate it. The point of XML is to provide a standard representation of data. Once it relies on external metadata, it's no longer XML.

It's just senseless over-engineering. For what purpose, to shave a few bytes at the cost of breaking existing parsers?

BTW, can your parser chew on the SVD and spit out a normalized XML with the dimsElements expanded?