Created a first draft of the I3C trait. #724
Conversation
There are still things missing in order of priority: Common Command Codes Dynamic Address Assignment Interupts Second Master Hot Join
|
Ping @felipebalbi for discussion |
| type Error = T::Error; | ||
| } | ||
|
|
||
| pub trait I3c<S: SpeedMode = Sdr>: ErrorType { |
There was a problem hiding this comment.
Not sure I agree with the Speed mode typestate here. We can switch between DDR and SDR in runtime, right? Will you require folks to consume and recreate the I3C (presumably with helpers into_sdr() and into_ddr())?
There was a problem hiding this comment.
I thought about the controller implementing all supported speeds for the same object. The client can then use the different supported speeds depending on which trait is used to call transaction. In this design the whole transaction has the same speed. The switch from i2c to i3c would happen after the first address byte has been sent and arbitration is over.
There was a problem hiding this comment.
Apparently my idea on how I would implement this didn't work out or I'm missing on how to constrain the types properly. As can be seen in the test. Ideas on another Idea. Different traits for the different speeds could work, but they'd be unwieldy.
This enables us to explicitly specify the point at which High Data Rate is enabled and disabled.
Added documentation with an example about how the trait should be properly used.
2 participants
Idea to close #586
There are still things missing in order of priority, though we could probably close at least the features in additional PRs
Common Command Codes
Dynamic Address Assignment
Interrupts
A lot of documentation
The other two high speed modes
Second Master
Hot Join