Make I²C initialisation (Wire.begin()) not slow

[matthijskooijman]

I'm running the Wire library on a G030 and noticed that initialization is super slow (Wire.begin() takes 800ms).

Digging into the code, I found i2c_computeTiming() that contains 5 (!) nested forloops and essentially seems to just bruteforce all possible timing combinations or something like that.

Note that I tested on an older version of the Wire library, but looking at the history of that file, I do not think this was fixed in the meanwhile.

Describe the solution you'd like

It seems like it should be possible to be smarter and also a lot faster about this.

[fpistm]

Hi @matthijskooijman
Yes it is slow mainly on small device and it is mentioned in the Wiki:
https://github.com/stm32duino/wiki/wiki/Custom-definitions#i2c-timing
Simply define the I2C timing to avoid call this function as explained in the Wiki.
https://github.com/stm32duino/wiki/wiki/Custom-definitions#example-for-a-stm32f0xx-using-hsi-clock-as-i2c-clock-source-in-varianth

[matthijskooijman]

Ah, thanks for that link, had not seen it. Predefining the timings (I just copied them from the datasheet now) indeed makes startup fast (down to 500μs from 800ms), thanks.

However, a downside of this is that the configuration hardcodes other factors, in particular the input clock and filter configuration, while the dynamic calculation takes those into account (making this a bit fragile - if you decide to change the AHB clock speed in the variant, it's easy to forget to update the I²C timing defines).

So I still suspect that the calculation could be made a lot smarter, by analyzing the equations and doing more direct calculation of values rather than simply trying them all. It doesn't help that this configuration is quite complex (seems overly complex to me, but I guess it's based on I²C timing constraints rather than a simple 50% duty cycle fixed clock, and also needs to support clock stretching.

One simple improvement that I think can be made is to calculate PRESC/SCLH/SCLL first in a 3-level loop and then calculate SCLDEL/SDADEL afterwards. AFAICS the PRESC/SCL/SLL decision and error amount does not depend on the delays at all, so I think that can be done separately? OTOH, I guess there's a chance that you'd end up with a super accurate SCL clock, but then cannot find any valid delay configuration for that prescaler maybe?

Anyway, I'll roll with hardcoded settings for now, and maybe revisit this sometime in the future...

[fpistm]

Yes it is complex as we have more unknown values than equations. So need to compute all possible value.
This is based on the HAL specifications which provide this method. In a general way the AHB value should not change but it is possible.