LoadSVD: Load SVD from ZIP file instead of pkg_resources #59
Conversation
This changes the logic with `svd_load <VENDOR> <MODEL>` to not search in the pkg_resources of Python module `cmsis_svd.data` but instead search in a ZIP file at `$CMSIS_SVD_ZIPFILE` if that environment variable is defined, otherwise it looks `$XDG_CACHE_HOME/cmdebug/cmsis-svd-data.zip` with `$XDG_CACHE_HOME` falling back to `~/.cache` if not found in the environment. As of 2025-11-09, the `HEAD` of https://github.com/cmsis-svd/cmsis-svd-data is 5.8 GiB in size uncompressed, or 254 MiB when zipped. Personally, I do not perceive any additional latency by having to unzip the chosen SVD file first.
|
Yikes how that repo has grown! It's still a nice feature to have though, so I'd like to find a way to keep it. That doesn't mean I don't also like your approach(es)--in fact personally I prefer yours in my own workflows--but there's something to be said for the convenience of cmsis-svd. Sorry for the delay. Give me a little time to propose a less clunky version of the cmsis-svd fetcher to go with your upgrades. I'd rather not drop the feature only to re-add it. Seem fair? |
|
Yes, sure. Btw: I was under the impression that Could it be that the distribution method for SVD files as python module no longer is a thing anyway? |
|
Hi I'm sorry for the delay and disorder. Just got to this today. I tried something and it seems okay, but I haven't yet incorporated the zip option--honestly I was rushing and kinda forgot what I was aiming for. Candidate is here: https://github.com/bnahill/PyCortexMDebug/tree/new_remote I split the svd_load command, figuring that would be easier on the user than using a different set of args for remote vs local. Plus if the remote one ever breaks then we don't mess with use of local files. svd_load_file does exactly what you expect. Point to an SVD file. svd_load_remote pulls the list of vendors and chips from github--one request per vendor. This list gets cached locally in case the user hits the github API limit, though I'd rather eventually use the cached copy by default unless it's super old. Complete works in getting you to What do you think? |
|
I agree, that is better. It might be nice if the repo to fetch from could be controlled e.g. via environment variable or a configuration file. That would provide a clean way to use an alternative source for SVD files if one has to work with a team regularly on new MCUs with the SVD files not yet available in the upstream cmsis-svd-date repo, one team member could volunteer to maintain a custom repo with all the required SVD files as fall back. |
environment variables. In support of #59.
|
Good idea. I incorporated that into a quick update adding environment variables SVD_API_URL, SVD_BRANCH, and SVD_CACHE_PATH. Seems to work based on a few ad-hoc tests. This does, as far as I know, restrict to github. I also have it default to using a cached index if less than a day old. This should keep API access reasonable. |
2 participants
This changes the logic with
svd_load <VENDOR> <MODEL>to not search in the pkg_resources of Python modulecmsis_svd.databut instead search in a ZIP file at$CMSIS_SVD_ZIPFILEif that environment variable is defined, otherwise it looks$XDG_CACHE_HOME/cmdebug/cmsis-svd-data.zipwith$XDG_CACHE_HOMEfalling back to~/.cacheif not found in the environment.As of 2025-11-09, the
HEADof https://github.com/cmsis-svd/cmsis-svd-data is 5.8 GiB in size uncompressed, or 254 MiB when zipped. Personally, I do not perceive any additional latency by having to unzip the chosen SVD file first.