I2c: simplify trait. #441
Closed
I2c: simplify trait. #441
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
|
I think #440 is not too big and I reviewed that instead. I think we can close this one. Thank you! |
bors bot
added a commit
that referenced
this pull request
Mar 28, 2023
440: I2c: simplify, expand docs, document shared bus usage. r=eldruin a=Dirbaio ~Depends on #441 -- check that one out first.~ This does some simplifications to the trait that I think we should do: - Implement all methods in terms of `transaction`. This way HALs have to implement just that. - Removed byte-wise-iteration methods: `write_iter` and `write_iter_read`. The reason is that they're quite inefficient, especially with DMA implementations. We've already removed these on other traits, so I think we should do as well here. - Removed `transaction_iter`. I don't think it's much useful in practice, because the way iterators work all the yielded `Operation`s must have the same lifetime. This means that, even if the user can generate the `Operation`s on the fly, they can't allocate buffers for these on the fly, all buffers must be pre-allocated. So it's not useful for, say, streaming a large transfer by reusing some small buffer repeatedly. See #367 - Removed useless lifetimes - Standardized buffer names on `read` and `write`, I think they're clearer. It also specifies how i2c bus sharing is supposed to work. This is an alternative to #392 . After the discussions there, I don't think we should split I2C into Bus and Device anymore. For SPI it makes sense, because drivers want to enforce that there's a CS pin (`SpiDevice`) or not (`SpiBus`). This is not the case with I2C, the API is exactly the same in the shared and non-shared case. Drivers shouldn't care which case it is. So all we have to do to "support" bus sharing is docs, This PR does: - Document that it's allowed for implementations to be either shared or not. - Document some guidelines for drivers and HALs on how to best use the traits, expand the examples. Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
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.
Some simplifications I think we should do:
transaction. This way HALs have to implement just that.write_iterandwrite_iter_read. The reason is that they're quite inefficient, especially with DMA implementations. We've already removed these on other traits, so I think we should do as well here.transaction_iter. I don't think it's much useful in practice, because the way iterators work all the yieldedOperations must have the same lifetime. This means that, even if the user can generate theOperations on the fly, they can't allocate buffers for these on the fly, all buffers must be pre-allocated. So it's not useful for, say, streaming a large transfer by reusing some small buffer repeatedly. See I2C transaction_iter should take an iterator of mutable references #367readandwrite, I think they're clearer.