Jan,

> But that just may easily lock,

Do tell how that might happen, so that I can evade such a situation.

> reduces speed, not my sort of solution.

:-)   You have some solution in which neither program needs to wait for the
other ?   I'm intrigued.

> i2c has many modes, muti-master is one of those.

I wanted to limit the scope a bit (with the Py functioning as /the/ master),
but realized that that doesn't make any difference that I can think of.

> Yes, me using diodes it is just a fail safe protection, you can
> switch I/O direction but that is not safe in case of a software
> fault if your I/O pin is high and the i2c chip does a sda pulldown
> as acknowledgment.

Yep, a glitch and an acknowledgement at the same time might cause that.
What do you think of the chances of the first, and than the chances of both
happening together (mind you, for an I2C device to generate an ACK it first
needs to recognise its own address).

Personally I would be more afraid of me/someone connecting the device the
wrong way - putting vcc on a data/clock pin or just a 5v device with its own
passive pull-ups - and that way blow a pin.

> I leave it in in case of raspi, as new raspis are more expensive than
> diodes.

Absolutily.  But I than rather spend a buck-and-a-half and put an I2C
level-converter in - even when both sides are 3v3.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05