I2C bus circuits moonlighting as switch inputs?

[lscw]

I have a dodgy chinese soldering iron/rework station I'm designing a replacement PCB for. It uses a no-name micro (8086?) that connects to an Atmel AT24 EERPROM over I2C but both Clock and Data lines also each go to a 220 ohm resistor and a momentary push-button switch to ground which increments the iron temperature up or down.

I don't intend to replicate this part of the circuit, I'll be using a PIC anyway. But I wonder how this might have been implemented in the software?

[spostma]

I would say that the microcontroller monitors the SDA and SCL lines in its main idle loop,
and handles the low pulling of the SDA and SCL lines by the switches.

As long as the user does not create a valid I2C start, the I2C slave does nothing.

However, if the I2C start happed to be made with the switches, the microcontroller
should _always_ reset the I2C bus prior to sending a command.

I have two clues on resetting the I2C bus reliably (copied from an old I2C.asm source):

;---------------------------------------------------------------------------------------------------
; I2C Bus Error Recovery
;
; Dallas/Maxim Application note 476 "Comparing the I2C Bus to the SMBus" says:
;
; In the I2C bus, if the slave locks up and holds either Clock or Data low, error recovery is impossible.
;
; Very few slave devices actually have the ability to hold Clock. As a result, the most common
; bus error is slave devices that have ended up in a state where Data (the data line) is low.
;
; In the I2C bus, a master accomplishes error recovery by clocking Clock until Data is high
; and then issuing a Start followed by a Stop.
;---------------------------------------------------------------------------------------------------
;
; Try to send 9 clocks followed by a Stop to clear a slave that may be stuck in the middle of a byte.
;

;====================================================================================================
;I2C Bus recovery (from DesignCon 2003 TecForum I2C Bus Overview)
;
; Typical case is when masters fails when doing a read operation in a slave
; SDA line is then non usable anymore because of the “Slave-Transmitter” mode.
;
; Methods to recover the SDA line are:
; – Reset the slave device (assuming the device has a Reset pin)
; – Use a bus recovery sequence to leave the “Slave-Transmitter” mode
;
; Bus recovery sequence is done as following:
; 1 - Send 9 clock pulses on SCL line
; 2 - Ask the master to keep SDA High until the “Slave-Transmitter” releases the SDA line to perform the ACK operation
; 3 - Keeping SDA High during the ACK means that the “Master-Receiver” does not acknowledge the previous byte receive
; 4 - The “Slave-Transmitter” then goes in an idle state
; 5 - The master then sends a STOP command initializing completely the bus.

---

Actually, this I2C bus reset sequence should always be used after detecting
a I2C communication problem to make I2C more robust IMHO.

---

Note that the I2C bus differs from the SM bus in this aspect,
for the SM bus has provisions to avoid a bus lock-up by requiring a low state timeout on every device.

[lscw]

Great, thanks for the info.

However, if the I2C start happed to be made with the switches

I hadn't even considered that possibility. Are automatic bus reset sequences included in most I2C libraries or is it something you have to implement seperately?