Fault Tolerant I2C Object?

eldonb46

I have been working with the "jm_i2c" Object; to connect several devices to the Propeller. The Object appears not to observer the NAK status in any useful fault tolerant way.

For example, when a I2C peripherals miss-behaves (or is dead/missing) the object saturates the I2C bus with "wait(id)" output and never gives up. With my LCD Display on the same I2C bus, useful system diagnostic information that could have been displayed is lost, or stuck, in the blizzard.

Has anyone expanded the "jm_i2c" object to be more flexible and fault tolerant?

I have started some successful edits for my use, but because I am a little new to I2C, it would be better if there was a collaborative effort.

I currently have about six devices on a single I2C bus (and maybe more to come). With some I/O locking, I am very pleased how well they all work together, the Prop with multiple COG's manages them all at more than acceptable speeds. Yes, I know, I could have made it easier with additional I2C buses, but that is NOT my goal, I want to save as many I/O pin as possible.

Some of my Prop Projects can be seen at:

http://wa0uwh.blogspot.com/search/label/Propeller

Note: I am new to the Propeller forum, is there a better place/method to "discuss" individual Exchange Objects?


BTW: Thanks "jm", I have learned a lot by reading your I2C Object, again, Thanks.

Regards,
Eldon - WA0UWH

Mike Green

The "Basic_I2C_Driver" provides ACK/NAK status for most of its methods. Remember that this only works for writing. The read methods rely on the write cycles needed to address the device to return ACK/NAK status. The actual read cycles don't return error status.

Tracy Allen

That wait(id) method is basically waiting for the dta line to go back high. If dta is stuck low due to some hardware problem, then the i2c bus is probably toast. You are right to want to escape from that condition so that the program can continue with whatever else it can do sans i2c, maybe debugging using an alternative to the LCD screen.

Maybe add a timeout. Maybe the problem will clear itself. (The BASIC Stamp has a timeout on its i2c commands.) You might modify the code to include setting a status variable so that the program could deal with a particular locked up device by resetting it or something like that. The following modification returns the id of the offending i2c device as a negative number, to an abort handler at a higher level.

repeat idx from 1 to 9 ' try 8 times, timeout if fail
    if idx == 9
      abort(-id)      ' <----- return negative of the device id to abort handler
    start
    ackbit := write(id & $FE)
  until ackbit == ACK

Note that the STOP method in jm_i2c also has provision for clock stretching, and that might also be a sticking point that could also be covered by a reasonable timeout, or comment it out if your system does not use clock stretching.