TI中文支持网
如图是使用逻辑分析仪采集到的EV2400读取BQ40Z80EVM板的smbus时序图，为什么第一个应答可以很快立马即有，而第二个应答（红框）却要等很久才有应答，第三、四、五个应答之后为什么要等一段时间才进行下一个字节的读取，最后一个stop也是一样为什么等一段时间才stop？？？
Star Xu：
正在查阅，请稍后
v one：
回复 Star Xu:
嗯？
Star Xu：
回复 v one:
第一个字节是电量计的地址, 我想是指应答，是由气压表的I2C引擎产生的，不需要FW的介入。所以这是没有延迟的。
第二个字节 是交易指令, 电量计的I2C引擎需要发起一个中断，等待FW获取和解释并决定下一步做什么。在仪表的FW能够做出任何决定之前，仪表的I2C引擎将I2C的SCLK压下。当气压表中的FW认为这是一个有效的命令时，气压表将确认该命令，此时，气压表释放SCLK信号，此时会在SCLK上看到一个上升沿。与此同时，gauge也会拉下SDATA。当主机(EV2400)看到这个时，把它当作应答，拉下SCLK，开始下一帧，重复开始模式。由于检查和验证命令通常需要更长的时间，所以您将看到确认I2C地址字节的等待时间比前一个更长。
第三字节表示这是读操作,SDATA 上的以下字节由电量计以主机生成的 SCLK 信号速率发送（EV2400），以下字节的确认位由 EV2400 生成，因为这只是读取 8 位帧，不需要验证，确认位仅由主机端的 I2C 引擎给出，在此方案中也不需要 FW 干预。因此，确认位不会延迟。
但EV2400中的MCU需要将I2C引擎接收的字节放到缓冲器中，以便FW读取和处理，EV2400将可以在完成此操作后读取下一个字节，EV2400将拉下SCLK，直到FW获取I2C引擎中的字节。这就是为什么您看到 EV2400 等待下一个字节读取一段时间，直到此事务结束。
v one：
回复 Star Xu:
你这段是哪里翻译过来的吗？明显不通，把原文链接发我一下。
Star Xu：
回复 v one:
The first byte is the address of the gas gauge, the reply, which I think refers to acknowledge, is generated by the I2C engine of the gas gauge, no FW intervention is required. So there is not delay for this.
The following byte is the command of the transaction, the I2C engine of the gas gauge needs to raise an interrupt and await the FW to fetch and interpret and decide what to do next. before the FW in the gauge can make any decision, the I2C engine of the gauge pulls down the SCLK of I2C. When FW in the gas gauge think this is a valid command, the gauge would acknowledge the command, at this moment, the gas gauge release the SCLK signal, you will see a rising edge on SCLK at this moment. meanwhile, gauge also pulls down SDATA. when host(EV2400) see this, it takes it as acknowledge, and pulls down the SCLK so as to start next frame which starts with Repeat Start pattern. As it always takes longer time for the FW in the gauge to check and validate the command, you will see the wait time longer than the previous one to acknowledge the I2C address byte.
The 3rd byte indicates this is read operation, the following bytes on the SDATA are sent by the gauge at the rate of the SCLK signal generated by host(EV2400), the acknowledge bits of the following bytes are generated by EV2400, as this is only read the 8 bit frame, not validation is needed, the acknowledge bit is just given by the I2C engine at host side, FW intervention is not needed as well under this scenario. so there is not delay for acknowledge bit.
But MCU in EV2400 needs to put the byte received by I2C engine to the buffer for the FW to read and process, the EV2400 will be able to read next byte after this is done, EV2400 would pull down the SCLK until the byte in the I2C engine is fetched by the FW. This is why you see the EV2400 wait for a while for the next byte read until the end of this transaction.
