I2C Start condition bug

[IPGuru]

I know there have been a lot of discussions arround the raspberry pi's problems with I2C, especially when it comes to repeated starts. Most discussions blame the Pi for not handling clock stretching correctly but this is incorrect (or at least not the full story)
I have been doing some tests & have been able to confirm that the PI doese not actualy send a start condition correctly.
A start (or repeated start) condition is defined as a High to low transition on the data line WHILST THE CLOCK LINE IS HIGH.
The Pi is not checking the status of the clock line before pulling data low meaning that the start condition is not recognised by the receiving device.
I proved this quite simply by tying clock to gnd & trying to scan the i2c bus, whilst monitoring the data line on my bitscope. the PI can be seen repeatedly pulling data low each time it checks an address, instead of either waiting indefinetly for the clock to come high or raising an error.

[joan]

Moot. The Linux driver is SMBus based which does not allow infinite clock stretching.

[WiFi]

Definitely ClockStretching doesn't work (correctly) for the Raspis < Pi4!

Therfeore I am using BitBanging Software I2C Routines ( http://www.byvac.com/forum/read.php?4,481 ) instead - which work pretty fine in 99,9% .
But sometimes I am facing a very strange situation: When the Master sends the Start condition SDA low (SCL high) - followed by an SDA high, the Routines immediately at that moment signal me " fprintf(stderr, "bcm2835_i2cbb: Clock line held by slave\n"); " :Data transmission hasn't started yet. I had thought before, that clock stretching is only used during data transmission ...!

I am assuming the root cause, that the time difference between SDA low and SDA high is to small to let the Slave recognize the start condition properly. Can somebody confirm my assumption?

Best Regards from

WiFi