Hi list,
While working on an stm32f030 i²C application, it took some time to get
slave mode to work.
As far as I can see from the reference manual from a V1 part
(stm32f101XX et al), the i2c-v1 immediately starts receiving as soon as
its' OAR1 address is matched; however, it may refrain from sending an
ACK if the i2C_CR1 "ACK" bit is not set. Hence, a "i2c_enable_ack()"
function starts slave reception and i2c_disable_ack() stops it.
The i2c-v2 chips have an "OA1EN: Own Address 1 enable" bit to enable or
disable ACKing the slave address. This bit does have a definition in
i2c_common_v2.h (I2C_OAR1_OA1EN_DISABLE and ..._ENABLE), but there is no
"I2C_OAR1(I2C1) |= I2C_OAR1_OA1EN_ENABLE" in the v2 code. This
effectively makes the slave in v2 inoperable.
Judging from the v1 code, a proper way to set this up would be to just
add the "i2c_enable_ack()" and "i2c_disable_ack()" calls to the v2 code,
changing these calls to implement I2C_OAR1(I2C1) |=
I2C_OAR1_OA1EN_ENABLE. Additionally, the documentation states that
several bits "can be written only when OA1EN=0"; I think this should be
reflected in the functions' documentation? (Another way of doing this
would be to add calls to disable OA1EN and re-enable it afterwards,
which sounds like too much overhead to me, but I could be wrong).
Apart from that, a subtle difference between v1 and v2 is then (as far
as I understand from the reference manual), that v2 distinguishes
between call address and bytes received, i.e. there is a separate "NACK
generation" bit in I2C_CR2 to be able to NACK individual bytes received
- but as the I2C API doesn't implement this sort of subtle ACK/NACK
meddling, I think we could leave this out.
Should I write a patch?
Best regards,
Valentijn
_______________________________________________
libopencm3-devel mailing list
libopencm3-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
