Interrupting I2C Lines

[Chet T16]

What would be the "proper" way to disable the data lines from an I2C master (an send my own data instead) while still leaving it on?

Obviously i'd rather not put some switches or relays on them. I'm not sure how to manage it for two way transmission 

[free_electron]

Explain ?
You don;t need to disable. While the other master is idle the SDA and SCl are floating high. You can simply inject your own signal. IF a bus contention occurs the rule is : if you try to send a 1 and you still see a zero on the bus : back off. put your drivers high-impedant and wait for a stop condition. then you can retry.

But, this requires both your code and the masters code to be written according to the spec.

i frequently mulitplex I2C buses using some simple device like a 4052. ( or better : a DG409 )

[Chet T16]

I did forget to mention the salient info, let me explain what i want to do.

In one of the cars the radio and display are separate, the radio controlling the display via I2C and at idle resends the data every second or so.

What i want to do is stop/disconnect the radio signals and send my own data to the display.

Does that make more sense now?

[free_electron]

then the 4053 switch will do fine.

you simply switch around the SDA and SCL.


                  ____________
                 |            |
SDA(radio) ------|12        14|------->> SDA to display
SDA(you)   ------|13          |
SCL(radio) ------|2         15|------->. SCL to display
SCL(You)   ------|1           |
           gnd---|5           |
           gnd---|3           |
           gnd---|6           |
           gnd---|9           |
                 |            |
           .-----|11          |
          |      |            |
 control--+------|10          |
                 |____________|
                 


If you drive control high you can send your stuff to the display. let control low and the radio can talk. CD4053 does the trick...

The only potential problem is that the radio will keep getting ACK failures when it wants to talk to the display.... not sure what the radio's cpu is going to do with that .... you may have to monitor and provide ACK yourself ...

[ivan747]

The only potential problem is that the radio will keep getting ACK failures when it wants to talk to the display.... not sure what the radio's cpu is going to do with that .... you may have to monitor and provide ACK yourself ...

You could try disconnecting the display and seeing what happens to the radio.

[Chet T16]

Thanks for the replies

Yes the radio requires an ACK. If i was to connect 'you' to 'radio' and gave 'you' the same address as the display then it would get its ACK and continue sending?

Also, the bus also uses a MRQ line, if i'm understanding correctly i can still use the 4053 like this?

                         ____________
                 |            |
SDA(radio) ------|12        14|------->> SDA to display
SDA(you)   ------|13          |
SCL(radio) ------|2         15|------->. SCL to display
SCL(You)   ------|1           |
MRQ(radio) ------|5         4 |------->> MRQ to display
MRQ(you) --------|3           |
           gnd---|6           |
                 |            |
                 |            |
          +------|11          |
          +------|9           |
 control--+------|10          |
                 |____________|

[free_electron]

not sure what MRQ line is ... does that display have buttons ?

you will have to make something the 'emulates' the display so the radio thinks it's got it...
rip that display apart and see what the controller is  ( you probably already know. )

in that case you would have to connect such a display controller chip to the unused channel of the radio...

[bfritz]

Be aware that I2C does not have any timeout mechanism.

I have seen a large number of cases where people mux multiple devices on the I2C bus, where a small glitch is generated during the mux event.

A number of times I've seen systems that hang because a transmission in progress is interrupted.  The slave gets hung in a state where it is holding the data line low (It was sending logic 0 at the last clock cycle), and continues to hold the line low, as it is waiting for more clock cycles.  Most masters won't then try to communicate to this device, as they see the bus as busy.  If the master is a dedicated I2C device, this can lead to a hung bus, that can't be cleared except by power down.  If the master is a device you have programmed, you can sometimes work around this by sending the device clock signals until the bus is free, and then transmitting the equivalent of a start followed by a stop.  (In other words, pull the data line low with clock high, and then release the data line.)

Just be sure to look at the signals on both sides of the mux when it is switched (using an oscilloscope), and capture a number of events to make sure you don't generate glitches.  Also try to time the switch so that a communication that is in progress is not interrupted.

[Chet T16]

The MRQ line is described here if you're interested
http://web.archive.org/web/20100929182320/http://www.eelkevisser.nl/fabio.html

Is the slave not just pulling SDA low for the ACK after each byte?

As for the slave hanging, it seems pretty robust. I was physically connecting and disconnecting the lines to it at the weekend and it always managed to pic itself back up again

Maybe sticking three small relays in would be more reliable?

[free_electron]

Be aware that I2C does not have any timeout mechanism.

I have seen a large number of cases where people mux multiple devices on the I2C bus, where a small glitch is generated during the mux event.

that's why i use analog multiplexers built out of pass-gates. ( like the 4053 ) if you have a pull-up on both sides there will be no glitches. Switchover should only be done when the bus is free ( both SDA and SCL high )