Filter out nullptr peripheral instances #54
Merged
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
There are a few peripheral instances that have `NULL` as their base address in the SVD. My guess is that `NULL` is a signal to humans to not use this address. If I remember correctly , the peripherals tagged with `NULL` require indirect access through ANATOP. Until this commit, we've generated those peripheral instances, despite the silly address. However, a runtime check in `NonNull` will panic when the core library is built with debug assertions. Users may hit this panic if they build their firmware with this configuration, then try to acquire the individual peripheral instance or the `Instances` aggregate. The panic in the latter case is inconvenient, especially when the user doesn't care about these instances. This commit removes these `NULL` instances from the public API. I'm keeping the register blocks; pairing `core::mem::offset_of!` with register blocks is useful. For convenience / ease of implementation, I'm doing the filtering down in the codegen step of `raltool`. It would be better to implement this as a standard transform / cleanup step that kept the register block while discarding the instances. We can try this later. I plan to release this breaking change in the 0.5 and 0.6 series. This will affect users who were relying on these incorrect symbols.
mciantyre
force-pushed
the
remove-null-instances
branch
from
86770ee to
9806022
Compare
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.
There are a few peripheral instances that have
NULLas their base address in the SVD. My guess is thatNULLis a signal to humans to not use this address. If I remember correctly , the peripherals tagged withNULLrequire indirect access through ANATOP. Until this commit, we've generated those peripheral instances, despite the silly address.However, a runtime check in
NonNullwill panic when the core library is built with debug assertions. Users may hit this panic if they build their firmware with this configuration, then try to acquire the individual peripheral instance or theInstancesaggregate. The panic in the latter case is inconvenient, especially when the user doesn't care about these instances.This commit removes these
NULLinstances from the public API. I'm keeping the register blocks; pairingcore::mem::offset_of!with register blocks is useful.For convenience / ease of implementation, I'm doing the filtering down in the codegen step of
raltool. It would be better to implement this as a standard transform / cleanup step that kept the register block while discarding the instances. We can try this later.I plan to release this breaking change in the 0.5 and 0.6 series. This will affect users who were relying on these incorrect symbols.