I2Cm容错

我正在使用一个简单主机（PSoC）和从设备的应用程序。
当我向Slave发出R/W命令时，我从I2C API中积累返回值，
然后对这0个（错误）进行评估，例如查找错误，实现错误处理。
如果我断开时钟或数据线，I2CM就被困在I2CM API中，一个名为CcLogStudi2的函数。
因此，净效应是为了降低整个应用程序。
正在使用的代码
无符号CARI2COK＝0；
I2COK =（I2CMYFSENSTART（SLAVADD，I2CMYORD）= 0）？1：0；/ /发送起始位I2COK＝（I2CMYfFrEnter（MeMADR）＝0）？I2COK + 1：I2COK；//发送命令读取TopCube I2COK＝（I2CMYFSENtiFESTARESTART（SLAVADD，I2CMYRADE）= 0）？i2cok + 1：i2cok；/ /发送重复的起始位rxbuf [ 0 ] = i2cm_bread（i2cm_ackslave）；//读低字节rxbuf [ 1 ] = i2cm_bread（i2cm_ackslave）；//读高字节rxbuf [ 2 ] = i2cm_bread（i2cm_ackslave）；//读PEC
代码工作正常，直到我断开时钟或数据线I2C奴隶，或如果失去权力的奴隶
发生。显然这应该算是I2C API实现的缺陷，无法处理
HW故障。我想一个办法将看门狗，但我认为一个好的选择。
这也是Creator的情况吗？
问候，Dana。



     以下为原文
  I am using an application with a simple master (PSOC) and a slave device.
     
    When I issue R/W commands to Slave, I accumulate the return values from the I2C API,
    and then evaluate this for > 0 (errors), eg. looking for an error, to implement error handling.
     
    If I disconnect clock or data line the I2Cm gets stuck in a I2Cm API, a function called clockstretch2.
     
    So net effect is to take down entire application.
     
    Code being used -
     
     unsigned char I2Cok = 0;
   
  I2Cok = ( I2Cm_fSendStart( SLAVADD, I2Cm_WRITE ) == 0 ) ? 1 : 0;   // Send start bit
  I2Cok = ( I2Cm_fWrite( memadr ) == 0 ) ? I2Cok + 1 : I2Cok;                 // Send command to read Tobject
  I2Cok = ( I2Cm_fSendRepeatStart( SLAVADD, I2Cm_READ ) == 0 ) ? I2Cok + 1 : I2Cok; // Send repeat start bit
  rxBuf[ 0 ] = I2Cm_bRead( I2Cm_ACKslave );      // Read low order byte
  rxBuf[ 1 ] = I2Cm_bRead( I2Cm_ACKslave );      // Read high order byte
  rxBuf[ 2 ] = I2Cm_bRead( I2Cm_ACKslave );      // Read PEC
     
    Code works fine, until I disconnect a clock or data line to I2C slave, or if a loss of power to slave
    occured. Clearly this should be considered a defect in I2C API implementation, inability to handle
    a HW failure. I suppose a workaround would be watchdog, but that I think is a poor choice.
     
    Is this also case for Creator ?
     
    Regards, Dana.