search

espressif / svd

SVD files for Espressif devices
Apache License 2.0
55 stars 2 forks source link

Base peripherals have address 0 #10

Closed aykevl closed 3 years ago

aykevl commented 3 years ago

I noticed that some peripherals are listed as having address 0. For example, there is:

I'm assuming this is because the first one (UART) is just the base peripheral. However, this looks a bit weird in the generated Go code: there are now 3 UARTs (one of which most certainly won't work).

I can see where this is coming from: there is one base UART, and UART0 and UART1 inherit from it. This makes sense. Unfortunately, there doesn't appear to be a way in the CMSIS-SVD specification to indicate a peripheral is purely there to be inherited from. One way to work around it is to skip peripherals with address 0, but there do exist devices with a peripheral at address 0 (for whatever reason): for example, the LOCKBIT peripheral in some Microchip chips (such as ATSAME70J19).

One solution in the SVD file would be to use UART0 (and similar base peripherals: TIMG0 and UHCI0) as the base peripheral and inherit UART1 from it. I believe this is how most chip vendors do it. On the other hand, it's not too big of an issue for me so I'm fine with it as-is (although it looks a bit odd).

jessebraham commented 3 years ago

Thanks for opening this issue. You are correct, this is not quite right. I had noticed this issue generating the Peripheral Access Crates in Rust as well.

I am just working on some other projects currently, but when I get a chance to come back to this I will rework it to derive from the first peripheral, eg.) UART0/TIMG0/etc.

jessebraham commented 3 years ago

This has been corrected in 34573780a570d86770f80bc78fb1cdada484e99f.

aykevl commented 3 years ago

Thank you! I think these SVD files are now ready from my POV, so I've submitted them here: https://github.com/posborne/cmsis-svd/pull/133 (this makes using them in TinyGo a lot easier).

igrr commented 3 years ago

@jessebraham should we keep updating the version in the SVD file each time we make some improvements? I see both old and new files have <version>1.0</version>. If the files are copied to other repositories, I'm afraid it will be quite hard to figure out if the SVD file in the particular repository is "latest" or needs to be updated. Shall we perhaps add the git tag of regdesc and regdesc-data to the version string, or have some other way of bumping the version each time we update the SVD?

aykevl commented 3 years ago

That could certainly be useful, because this repository will certainly not be the only place where these SVD files live. A git has would be an improvement, but an actual version number would be even better (because then it's possible to see which file is the latest, not just whether they are at the same version).