Hi Luca,
On 12/17/19 9:35 AM, Luca Ceresoli wrote:
On 15/12/19 21:27, Daniel Mack wrote:
The a2b code has to tell the 'master node' the final destination of the payload by programming registers on its primary i2c address, and then forwards the messages to its secondary i2c address. The layout of the messages don't change, and neither do the flags; i2c messages are being sent as i2c messages, except their addresses are changed, a bit like NAT in networking. That procedure is described on page 3-4 of the TRM, "Remote Peripheral I2C Accesses".
The 'real' i2c master that handles the hardware bus is responsible for adding start conditions, and as the messages as such are untouched, I believe it should do the right thing. The code in my xfer functions merely suppresses reprogramming remote addresses by remembering the last one that was used, but that is independent of the start conditions on the wire.
My concern is not about the start condition, it's about the *repeated* start condition.
The first question is whether the A2B chips can do it. What if the host processor sets a slave chip address and then issues two messages separated by a repeated start condition? Will the slave transceiver emit a repeated start condition too?
Ah, alright. Thanks for taking the time to explain. I'll have to do some measurements with a hardware analyzer. Will revisit this then, and either provide an implementation that handles such cases correctly, or a comment to explain that the hardware can't do it.
Best regards, Daniel