Export FmcSdramConfiguration and FmcSdramTiming structs #2
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.
This allows implementing
SdramChip
outside of this crate.This is useful when implementing a new device. Projects depending on this crate would not have to depend on a fork while waiting for a PR to be merged with the new device.
It would also make it much easier implementing a new device when depending on a HAL crate. In my case I was depending on
stm32h7xx-hal
(which depends onstm32-fmc
) as well as depending on a local version ofstm32-fmc
with a new device implementation. This caused the issue described here: rust-lang/rust#22750. Not being able to implementSdramChip
outside of the crate would force me to maintain forks of bothstm32-fmc
as well asstm32h7xx-hal
until 1)stm32-fmc
merges a PR, and 2)stm32h7xx-hal
would adopt the new release.I'm not sure if the structs were ever meant to be exposed, but I think having some way to implement the
SdramChip
trait outside of this crate would be really helpful.