Abstraction of I2C interface for discussion - STM32 #76
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
|
Ive been exploring git submodules as a way to make use of Bruce's abstraction without having to burden NT7S's repository with code specific to platforms he might not have access to or care to support. Im offering this up solely for thought or discussion: https://github.com/coburnw/Si5351Linux |
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.
Hi Jason:
Thanks for an excellent Si5351 library. I use it all the time on Arduino/Teensy. I've started doing some projects using the STM32 family and I'd love to be able to keep using your library. I think this should be straight-forward if the I2C interface can be abstracted a bit. This pull request is a request for comment on the general idea.
The IC2Interface class provides the generic interface to the I2C bus. There would be implementations of this interface for different platforms. The default would be Arduino to make sure existing code doesn't break.
I have tested this on an STM32F446 board and it works fine.
Let me know if you'd be open to accepting this general type of change.
73s, Bruce KC1FSZ