Skip to content

Comments

Created a first draft of the I3C trait.#724

Draft
Tremoneck wants to merge 5 commits intorust-embedded:masterfrom
Tremoneck:i3c
Draft

Created a first draft of the I3C trait.#724
Tremoneck wants to merge 5 commits intorust-embedded:masterfrom
Tremoneck:i3c

Conversation

@Tremoneck
Copy link

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

There are still things missing in order of priority:
Common Command Codes
Dynamic Address Assignment
Interupts
Second Master
Hot Join
@Tremoneck
Copy link
Author

Ping @felipebalbi for discussion

type Error = T::Error;
}

pub trait I3c<S: SpeedMode = Sdr>: ErrorType {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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())?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it'll be hard to come up with something sensible. But I think a single trait that lets you do a transaction and the transaction knows if it's supposed to be I2c, I3cSdr or I3cDdr would be simpler. Then, anything implementing I3c gets an I2c implementation for free by calling I3c methods with all transactions set to I2c.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My idea behin the typestates was to ensure that a user is never able to combine a slave and controller, where the speed is not suported by both.

Adrian Geipert added 4 commits January 29, 2026 17:28
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.
@Tremoneck Tremoneck requested a review from felipebalbi January 29, 2026 17:49
@MabezDev
Copy link
Member

Please follow https://github.com/rust-embedded/embedded-hal/blob/master/docs/how-to-add-a-new-trait.md before undrafting this for review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Create an I3C Trait

3 participants