How to use i2c as slave without directly control the registries

[eisterman]

Is there an official method from this crate to use i2c without directly manipulate the bit of the i2c registries?
And if not, why?

[TeXitoi]

No, because no one has done it yet.

Notably, it lacks an I2C slave embedded trait in embedded hal.

Contribution welcome!

[eisterman]

If there isn't any problem with it I'm glad to implement it

[TeXitoi]

Feel free to propose a first POC and ask for feedbacks. You can also chat with a lot of rust embedded developers on matrix https://github.com/rust-embedded/wg#contact

[eisterman]

I ask to confirm my doubt.
Is the non-blocking master i2c interface currently lacking any method to be used, unlike its blocking counterpart, correct?

[TeXitoi]

I'm not sure to understand. Doesn't the slave interface by definition different because of responding to requests?

[eisterman]

Yes, however, there are two versions of the master, one blocker and one no. However, I noticed that only the blocking version is public (thanks to the embedded_hal traits). I was wondering if this was a lack of the current implementation or had a reason to reflect it in the slave implementation.

In general, I am thinking of managing the slave in a similar way to how the Arduino Wire library does, or through the assignment of two closures, one for sending data and one for receiving data.
In this area, many recommendations are accepted!

[therealprof]

I think you're talking across one another.

Indeed there's no I2C slave traits to be implemented and there's also no custom I2C slave implementation implemented in this crate.

It would be great to have both.

CC rust-embedded/embedded-hal#179

[TheZoq2]

Yes, however, there are two versions of the master, one blocker and one no. However, I noticed that only the blocking version is public (thanks to the embedded_hal traits). I was wondering if this was a lack of the current implementation or had a reason to reflect it in the slave implementation.

Both versions are public, but only blocking i2c uses embedded hal traits, since there is no hal traits for non-blocking i2c. The same is true for slave i2c, so if you do implement it right now, users have to depend on stm32f1xx_hal directly.

The alternative is to add a slave trait to embedded_hal, and then implement it here. That would obviously be more work but is a nicer implementation.

[ost-ing]

Wondering if there was any progress for an I2C slave feature in this crate?

Would a PR be welcome for implementing this as a device specific (ignoring the embedded-hal traits) feature for now?

[burrbull]

Would a PR be welcome for implementing this as a device specific (ignoring the embedded-hal traits) feature for now?

Sure.

[surban]

https://github.com/surban/openemc/blob/master/openemc-firmware/src/i2c_slave.rs

and maybe https://github.com/surban/openemc/blob/master/openemc-firmware/src/i2c_reg_slave.rs

Let me know if this is useful. If so, I will open a PR.

[ost-ing]

https://github.com/surban/openemc/blob/master/openemc-firmware/src/i2c_slave.rs

and maybe https://github.com/surban/openemc/blob/master/openemc-firmware/src/i2c_reg_slave.rs

Let me know if this is useful. If so, I will open a PR.

That's quite helpful, thank you