Move PAM generation to build time, optimizing download size #157
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@Rahix just a reminder about this. |
Also, now we use the Rust version of svdtools. The atmega328p example was corrected to svd2rust new naming onvetion, too.
It was a separate crate previously, but that made its compilation completely independent from the actual PAC crate. The user can still use that directory as a template, they'll just need to rename `Cargo.toml.example` into place. The changed steps for that and to test the example are documented in `examples/atmega328p/README.md`. The target used was updated from rustc, as well, and hoisted up as a default for the whole crate. This allows to more easily build the library/example for quick testing.
This updates our `interrupt` macro, adapting it from a newer iteration of `cortex-m-rt`'s. In particular, this makes generation of the sibling `vector` module unneeded, since the check of whether the named interrupt exists is done via checking a newly exported `Interrupt` enum in the PAC (we use the path `::avr_device::Interrupt`, which does not require avr_device to be imported in the caller's scope). There is one downside, though: we can't enable more than one MCU feature, because that causes duplicate items. As such, docs.rs now only builds for the `atmega328p`.
This replaces the AoT processing we did to generate the Rust modules locally. It generates them on the fly at build-time, and only for the selected MCU. The process is mostly the same, just automated. Some things became unnecessary though, such as the `modrs.patch`. `form` is no longer run, in order to minimize the number of files and directories, but rustfmt is, so that the user can read the source from generated documentation pages. The patches were updated to not have the `_svd` key, since that's now handled by the build script. Those that ended up empty were removed.
|
Is there still interest in this PR? Not to rush, but I'd like to know, since if there's not or not yet, I'll hold off on fixing CI. It's failing because this automated approach doesn't need the Makefile, and the current CI code expects it to be there. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Although from the titles alone it may seem unrelated to the issue, the original goal was to fix #59. The approach taken, as suggested in that thread, is to generate the Peripheral Access Modules (PAMs) after the user has downloaded the package, in an automated fashion. So, instead of shipping the modules generated "by hand" (with semi-automation actually, but still), we ship the ATDF sources from which they are generated. When running build either in the crate root or as a dependency, the
build.rsscript outputs a module for the selected MCU into a known path. The generation steps are described in the README.The result of this is that the packaged
.cratefile does become much smaller, just short of 5 times (4.875...). Compilation time increases, of course, in particular as a fault of the build script. This could be improved by using the executable versions of svd2rust, svdtools and atdf2svd, but that would greatly reduce reproducibility. rustfmt is used via the executable, since it does not provide a library API, but in that case it should be fine, since anyone with a toolchain capable of compiling to AVR probably also has access to rustfmt.The commit changing the example from a crate to an actual Cargo example, while technically not necessary, makes testing the use of the crate as a dependency more convenient.
For a reference of crate size, see #59 (comment).