i2c: Reimplement with new HAL API design #155
Merged
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.
Pull off the same design that the USART module is using now in the I2C HAL as well. The key points are:
avr-hal-generic
defines the user facing API type (e.g.I2c<>
orUsart<>
). This type implementsembedded-hal
traits and provides all API which we want to expose.I2cOps
(orUsartOps
). This trait is "consumed" by theI2c<>
type to access the peripheral.raw_
and are not meant to be used directly by the user.impl_i2c_twi!{}
in this case.I2cOps
trait nor the peripheral type (it comes fromavr-device
), we run into the "orphan rule". To "fix" this, theI2cOps
trait andI2c<>
type have a type-parameter calledH
which is substituted by a local type from e.g.atmega-hal
.Cc: @explicite