Update Freescale/NXP files about cmsis-svd

[posborne]

Thanks @therealprof; I think putting things into the NXP directly would be fine. Hopefully they don't mess with us again by move it over to QCOM or something.

The kernel gets around this some by binning in to, e.g., mach-imx but I think we stick with manufacturer name.

[therealprof]

I've just recently released a Rust crate based on the new MKW41Z SVD files here: https://github.com/therealprof/mkw41z . The repository also contains the SVD file.

The changes for this chip are not too drastic, they added a few missing peripherals, adjusted some to make now reserved values really reserved, fixed plenty of typos in the comments and added the (previously absent) standard Cortex-M peripherals like SysTick.

It should rather easy to quickly glance over the changes and flag any major changes.

It'll be more work to download each SDK individually and pull the SVD file, I haven't found a concentrated source for them yet.

[therealprof]

I guess I haven't realised how many SVD descriptions there are now; quite a lot more than already checked in and retrieving them by individually requesting them from the SDK builder as quite tedious... Guess I'll have to limit myself to the ones I care about or maybe the ones that are available on FRDM boards.

Question is: What to do with the ones for which no SDK exists?

[jnohlgard]

@therealprof I discovered that NXP has begun providing pre-configured mcuxpresso packs for the Keil uVision pack installer, these files can be downloaded manually and unzipped without the Keil IDE as well.

I have no automated tools for it, nor have I tried to find for any, but the starting URL is http://www.keil.com/pack/index.idx (an XML file). The index then links to a number of pdsc files which contain some metadata, but the real package is located at the same URL as the pdsc, but with the version added as a suffix and the file extension changed to .pack.
For example, the pack belonging to the pdsc line

<pdsc url="http://mcuxpresso.nxp.com/cmsis_pack/repo/" name="NXP.MKL27Z4_DFP.pdsc" version="10.0.1" />

can be found at http://mcuxpresso.nxp.com/cmsis_pack/repo/NXP.MKL27Z4_DFP.10.0.1.pack
The .pack file is a normal .zip archive and can be extracted with the regular unzip tools.

Not all their MCUs seem to have been packaged for this new scheme yet, but the more recent devices from the larger families are available (KL, K22, etc). For the rest, the older Keil packages are available as family packages as well from the same index file, e.g.

<pdsc url="http://www.keil.com/pack/" name="Keil.Kinetis_K60_DFP.pdsc" version="1.5.0" />

The packages are pretty big if you are only looking for an SVD file, but at least they are downloadable this way...

Edit:
Oh, and the older Keil provided packages are usually a bit behind on any updates to the SVD or C header...

[therealprof]

@gebart Great stuff, thanks. I'll check it out.

[lkolbly]

Okay, so I wrote a script which scraped that site and extracted (most of) the SVD files. (I can post it if you want)

I was able to extract 3,447 different SVD files, some of which were already in the repository, so the end result is about 2,600 SVD files in the repo, taking up 6.2GB of disk space (on master, the data/ folder takes up about 1.1GB of space). You can see it here.

GitHub is refusing to make a PR for the whole thing. @posborne should I split it up and submit individual PRs (for different companies, or sub-PRs for companies where needed)? I feel like a 6.2GB pip package is pretty big. Anyone in particular is only going to want a single one.

Personally, I only care about NXP/LPC804.svd. But I figured might as well grab them all.

I'm working in Rust, so an alternative approach I've considered was creating 2,600 Rust crates, one for each device (possibly hosted on my own custom registry). Something similar could be done here - the SVD parsing library could be split into its own thing, and individual pip packages could be maintained for each device (again, possibly on a custom registry to avoid spamming pypi). And then the raw SVD files could just be hosted either in this giant github repo or in a web portal or something. Thoughts?

[therealprof]

@lkolbly Check out what https://github.com/stm32-rs/stm32-rs is doing. That seems like the sanest approach one could possibly take.

[lkolbly]

@therealprof Cool! It looks like someone's even got something similar going on for LPC chips, so I'll go look at that. Thanks!