Make features explicit for stm32h7[45b]3 #241
Merged
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.
Because stmh743 and stmh753 are so similar, it didn't matter that
the h743 feature and/or feature defaults that used h743 were in use
for the h753 SoC. However, as we start to use the IP of the h753 that
does not exist on the h743, i.e. Rng, Hash, and Crypt, the differences
start to matter.
The changes are tedious which reinforces the argument for better
system configuration tools.
I also added a -e option to xtask 'cargo xtask dist [--edges|-e] ...' that
runs 'cargo tree --edges features' before running 'cargo rustc ...'
This allows more visibility into the task dependencies and what features
are enabled on each. This was helpful in tracking down where the line of
features was broken; a top-level toml may have invoked a feature, but a
mid-level toml would have a dependency on a library that would have used
that feature if it had been passed on. Instead, a default feature or no
feature would be used. Most often, the stm32h7 crate would get compiled
two different ways and then get linked into the same task. The global
for the base of the register blocks would then have two instances which
would conflict.