attiny-hal: get rid of feature gates by moving mcu specific code into own modules #654
Conversation
This file contains hidden or 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
It's quite hard to add new ATtiny devices to this crate. There are a bunch of feature gates spread across the whole code base. In order to get rid of them, move all mcu specific code into a single file. To keep our current interface and avoid breaking existing user, the mcu specific file defines a module for each periphal which gets reimported by our periphal specific files. No functional change intended. Signed-off-by: Corvin Köhne <[email protected]>
It's quite hard to add new ATtiny devices to this crate. There are a bunch of feature gates spread across the whole code base. In order to get rid of them, move all mcu specific code into a single file. To keep our current interface and avoid breaking existing user, the mcu specific file defines a module for each periphal which gets reimported by our periphal specific files. No functional change intended. Signed-off-by: Corvin Köhne <[email protected]>
It's quite hard to add new ATtiny devices to this crate. There are a bunch of feature gates spread across the whole code base. In order to get rid of them, move all mcu specific code into a single file. To keep our current interface and avoid breaking existing user, the mcu specific file defines a module for each periphal which gets reimported by our periphal specific files. No functional change intended. Signed-off-by: Corvin Köhne <[email protected]>
It's quite hard to add new ATtiny devices to this crate. There are a bunch of feature gates spread across the whole code base. In order to get rid of them, move all mcu specific code into a single file. To keep our current interface and avoid breaking existing user, the mcu specific file defines a module for each periphal which gets reimported by our periphal specific files. No functional change intended. Signed-off-by: Corvin Köhne <[email protected]>
It's quite hard to add new ATtiny devices to this crate. There are a bunch of feature gates spread across the whole code base. In order to get rid of them, move all mcu specific code into a single file. To keep our current interface and avoid breaking existing user, the mcu specific file defines a module for each periphal which gets reimported by our periphal specific files. No functional change intended. Signed-off-by: Corvin Köhne <[email protected]>
It's quite hard to add new ATtiny devices to this crate. There are a bunch of feature gates spread across the whole code base. In order to get rid of them, move all mcu specific code into a single file. To keep our current interface and avoid breaking existing user, the mcu specific file defines a module for each periphal which gets reimported by our periphal specific files. No functional change intended. Signed-off-by: Corvin Köhne <[email protected]>
It's quite hard to add new ATtiny devices to this crate. There are a bunch of feature gates spread across the whole code base. In order to get rid of them, move all mcu specific code into a single file. Macros are exported by the crates root, so we can avoid the feature gates of the pins macro by moving it into our mcu specific files. No functional change intended. Signed-off-by: Corvin Köhne <[email protected]>
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.
It's hard to add new devices to the attiny hal crate because it's heavily feature gated and those gates are spread across the whole code base. So, new devices have to modify a bunch of files and repeatedly add
#[cfg(feature = "<device>"]making the code even less readable. There's already an open issue to make it easier to add new devices [1]. It also links to an attempt splitting the code base into mcu specific modules and making it easier to add new mcus. However, I'm proposing this new PR because it tries to take smaller steps to get into that direction. This PR is only focusing on splitting the crate into mcu specific modules by moving code around. It's intended to keep the API untouched. This should create less friction because we don't have to bump the semver of the crate and don't have to discuss API changes. This makes it hopefully easier to merge.PS: If this approach looks good, I'm going to do the same for the atmega hal crate.
[1] #623
[2] #643