search

stm32-rs / stm32f1xx-hal

A Rust embedded-hal HAL impl for the STM32F1 family based on japarics stm32f103xx-hal
Apache License 2.0
565 stars 177 forks source link

How to use i2c as slave without directly control the registries #163

Open eisterman opened 4 years ago

eisterman commented 4 years ago

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 commented 4 years ago

No, because no one has done it yet.

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

Contribution welcome!

eisterman commented 4 years ago

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

TeXitoi commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

eisterman commented 4 years ago

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 commented 4 years ago

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 https://github.com/rust-embedded/embedded-hal/issues/179

TheZoq2 commented 4 years ago

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 commented 1 year ago

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 commented 1 year ago

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

Sure.

surban commented 1 year ago

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 commented 1 year ago

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