[Fixes #17] Update SVDs from master and regenerate with svd2rust 0.24.1

[michalfita]

I've bumped up rust2svd locally and regenerated all PACs, this time from the master branch of https://github.com/posborne/cmsis-svd/ repository, as cmsis-svd/cmsis-svd#154 have been merged recently.

[tmplt]

I've been thinking how we are handling PACs at the moment. Is it possible to remove all generated code and dynamically svd2rust them when needed via some build.rs? Would every PAC need a build.rs?

Getting rid of these 50k files would be for the better.

I don't think this will be the last PAC bump. I have some SVD discrepancy bugs filed at Microchip.

[michalfita]

This idea is worth consideration. It would help if svd2rust can be used as library crate (dev-dependency). Same applies to form.

Need to do some research. Yes, each crate would need it's own build.rs, but probably we can either minimize differences between them or generate them automatically.

One of problems to tackle is how to run svd2rust only once per version, as it generates the full crate and do not check whether recreation is required.

[michalfita]

OK, I think we have some answers:
rust-embedded/svd2rust#392

[michalfita]

Problem 2: how to deliver right SVD with the crate to the user without invoking more less curl to run extra download?

[tmplt]

how to deliver right SVD with the crate to the user without invoking more less curl to run extra download?

I do not like the idea of downloading remote assets, unless sha265-summed, in the worst case. Either we continue the cmsis-svd approach or just vendor the SVDs in the repo. Or have I misunderstood the problem?

[michalfita]

I don't like either.

I've done some research already - the problem to solve before publishing each PAC crate is to put the right SVD in the directory, where build.rs can find it, but at the same time we need to have link to right one in the submodule so anyone wishing to use the repository clone can still use it. I had script to do the publishing somewhere, but I can't find it, so I'll have to write new one. (If rust-lang/cargo#6817 did what it says on the tin, it wouldn't be issue then.)

Now, what I started is MVP for one PAC, where build.rs can run svd2rust as library to generate the code from SVD on the fly, form it (can be used as library either, however that's undocumented). I may end up with PR to svd2rust as the generation process produces build.rs that conflicts with mine and expects device.x to ready to include!() at the time build.rs is executed. It would require function to create submodule to use in build.rs and pass device.x to it. So far things looks pretty straightforward, but it's a lot of code to make to address all intermediate needs of the process.

In the mean time I'd merge this one, so we progress toward next release and tackle the security issue found by dependabot (PR #22 more about this), because getting there with user side generation will take some time. I need to figure out some CI to validate these crates.

[tmplt]

Sounds good.

As for the regeneration, the crate versions have not been bumped. But instead of bumping it to 0.24.1, bump it to 0.24.0 so that we can repurpose the PATCH semver field for SVD changes also, either from us or Microchip. That is: SVD patch or svd2rust PATCH bump -> bump PAC crates' PATCH. MINOR continues to track svd2rust's MINOR.

[michalfita]

🤔 Is it something what other maintainers do?

[tmplt]

I don't understand the question.

[michalfita]

🤔 Is it something what other maintainers do?

I don't understand the question.

Question was in other words, whether other PAC maintainers keep only minor version from svd2rust and start from 0 on patch version?

I've done some updates readying these for next release.

[tmplt]

Question was in other words, whether other PAC maintainers keep only minor version from svd2rust and start from 0 on patch version?

I've seen PACs that mirror the full svd2rust version, but none that co-opt the PATCH field like this.

[tmplt]

This branch is now deprecated and can be closed. Refer to #24.

[michalfita]

@tmplt I'm closing this as I don't have time to work on this now. Let's focus on getting your stuff merged and I'll do my work on PACs from there.