CubeMX I2C stupid UX issue

[TDJ]

Every time I need to configure I2C, which is not often, I have to check the correct rise and fall times for the default 100kHz frequency and doing so I am asking myself a question why the typical 100kHz value is provided by default but rise and fall times are not, when most of the time 1000 and 300ns values are needed and I2C will NOT work with default values 0. Would not it increase user experience if the correct, typical values were provided in addition to the typical clock frequency?

Btw, CubeMX calculated timings are slightly off the I2C specs and conditions defined in ST RM docs. I believe the CubeMX algorithm is incorrect. Therefore I suggest to always enable the 'advanced settings' and allow the user to enter timings manually. Explaining why the calculation algorithm is incorrect is beyond the scope of this post.

[TDJ]

@Pavel A. OK, I think now I see your point.

Do you agree that I2C CubeMX-calculated timings, based on the default best case scenario zero rise/fall times do NOT meet I2C specification timing requirements? If you are not convinced, do the math, check the four conditions specified (e.g.) in RM0456 p. 2683-2685. However, if you are convinced it is OK as it is now, give me an example of auto generated timings based on zero rise/fall times which do meet those requirements.

What I am saying is that it is possible, and desirable, to use default settings which do meet I2C specification requirements most of the time if rise/fall times do not exceeded max allowable 1000/300ns respectively for 100kHz clock and use 1000/300ns (worst case scenario) as default values, rather than zeroes (best case scenario).

Calculations convince me, arguments like "many companies are happy for years" do not.

[Foued_KH]

Hello @TDJ , 

The rise and fall time are setting as default value not as best value, so you can change the rise and fall time respecting the range for both timing.

Could you please share which issues do you have if you set fall and rise time at 0?

Foued