On a sunny day (Sat, 23 Nov 2019 18:30:38 +0100) it happened "R.Wieser"
 wrote in :

>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

If you already think you know everything why ask?
How many i2c projects did you design  / write code for BTW?

--- SoupGate-Win32 v1.05