OpenServo.com

[mpthompson]

If we allow a stop/start condition how does one distinguish the read of the checksum status and just a normal read? Remember, multiple masters could cause such a transaction sequence or the CMD_CHECKED_TXN may have been aborted and followed by a read transaction.

I think that using restarts is the standard way that I2C based protocols typically handling writing some data and then reading some data in an atomic manner. The twi_address does persist across multiple transactions, but I would like to avoid any other instances of persistant data.

-Mike

[andylippitt]

It's very likely I'm missing something about the way multi-master works (I've never tried to actually implement it), but as I read it, a repeated start is not any more protected from a competing master than a stop/start. A master can jump in any time both lines are high (someone correct me here if I'm wrong). And I'm not asking that anything other than twi_address be preserved, instead suggesting that the twi_address be set to the status register after a checked write so that a subsequent read will pull the status. In the servo code, we don't distinguish a checksum status read from a normal read.

If by aborted, you mean that the servo detected an inconsistency, then twi_address is pointed at a failure code. If by aborted you mean that data was lost at some random point in the transaction, as long as the CMD_CHECKED_TXN was read correctly, nothing gets committed and the end result of twi_address is still that status code. If the CMD was misinterpreted then twi_address is left in an undetermined state, which is why I was suggesting originally that the success/failure codes be something other than the commonly found 0x00 and 0x01. At this point, I don't know what better we can hope for.

I'm only expecting twi_address to be persisted across the transactions. I'm less concerned now about the stop/start vs. repeated start than I was before we determined that a repstart was possible through our drivers, but the current implementation in the servo is indifferent to these options.

If someone can say that a repeated start somehow ensures dominance of the initiating master, then I'm in agreement.

[mpthompson]

Andy, you may be ahead of me and correct about a repeated start no being any more protected from a competing master than a stop/start. However, I would think that a competing master wouldn't be able to attempt to compete the bus until after it saw a stop condition, but I don't know for certain. Obviously this is something we should learn more about.

-Mike

[andylippitt]

page 14 seems to indicate that you are correct that a repeated start continues the busy bus state.

As we chatted about though, I don't think this changes our slave implementation as long as we are supporting the repeated start, additionally supporting a full stop/start and maintaining only the twi_address as state across these separate transactions shouldn't impair a multi-master environment that does choose to correctly repstart between the checked-write/read-status calls.