WAITING FOR REVIEW: simple and fast way to get i2c clock, tested(for results check the comments)

[hardfau1t]

faster algorithm to find timingr register values, implemented a custom enum for custom timingr value, sdadel is default made as 0, so no need of vddat calculation, and hd:dat, still su:dat need to implement, i will add it soon, took few concept from craigjb:i2ctiming this PR

Needed some test results, i couldn't generate 1 Mhz clock, i dont know whats the problem, tried custom values given in datasheets, reviews are requested and test results

fixes #71

[pftbest]

Which resistor values do you use for testing? The final frequency depends on the rise time which in turn depends on resistor values.

[hardfau1t]

i was connecting it directly to my logic analyzer so didn't pick any resistor, do i need one?

[pftbest]

Yes)

i2c lines are open drain so they can short to the ground but they can't charge back up to 3v without a pull-up resistor.

The lower the resistor value the faster it can charge parasitic capacitance so it will do a faster transition from 0 to 1.

Try 4.7k or 1k pull-up resistors.

[hardfau1t]

i tested with with 2.2k resistor, but didn't worked fork me, currently i dont have cubemx setup do you know timingr register value for 1mhz, i tried for 0x50100103 for 48 mhz as given in datasheet but no use

[pftbest]

For 216 MHz main with 54 MHz pclk1 cube gave me value 0x00200922 and I can measure around 960 kHz with logic analyzer.

For 48 MHz main with 48 MHz pclk1 the value is 0x20000209 and I get the same 960 kHz clock

my resistors are 1k each

[pftbest]

When I tried your value 0x50100103 @ 48MHz I got exactly 1 MHz clock

[hardfau1t]

ok, thank you for the results, its sdadel problem, i had hardcoded it to 4 for testing, i think that was causing problem. now its working for me to

[hardfau1t]

done some calibrations, to get optimal frequencies without being heavy on compute. Here are some results	i2c_clk in mhz	expected scl in khz	practical scl in khz
16	10	9.95
16	100	99.17
16	400	389
16	1000	940
32	10	9.971
32	100	99.8
32	400	393
32	1000	1000
54	10	10.131
54	100	99.767
54	400	412
54	1000	1054

having some problems for 10khz in between frequencies that will be addressed in next commit. if anyone can please confirm this result.

[hardfau1t]

removed get frequency method from mode enum as I couldn't find a way to calculate without i2cclk which is not available in mode enum.

[hardfau1t]

Forgot to mention, i skipped calculation of busch of parameters,

• kept sda always 0, thats what cube mx also does
• since sda is 0, vddat is always less than vddat max so no need to calculate vddat

[hardfau1t]

Is there anything else required, or is this implementation is incorrect? Should i close this PR then?

[hannobraun]

How does this relate to #72? Is it an alternative to it?

[hardfau1t]

72 using some brute force methods to calculate value, which is not required, and some of the calculations done in their was unnecessary.

It is kind of alternative, I tried to run it but was taking some significant cycles

[hannobraun]

Oh, also, this needs a rebase. Might be best to squash the commits while you're at it.

@craigjb, what do you think of merging this instead of #72? More efficient is better, of course, but other than that I'm not really qualified to judge the relative merits of both pull requests (and don't have the time to get qualified right now), so I'm hoping you can just hash this out among yourselves :-)

[hardfau1t]

yeah @craigjb i too think it would be great if you check it once, i skipped some calculations based on some assumptions

[hardfau1t]

please let me know if i am doing anything wrong with git history, i am still learning to how to use git,

[hannobraun]

please let me know if i am doing anything wrong with git history, i am still learning to how to use git,

Hmm, I'm confused by that first commit, "Add F767 to features that support USB.". There's a commit with the same title in master, but it looks completely different. How did that get in there, and what does it do?

[hardfau1t]

I think i missed it while squashing, hold on i will re do it again

[hannobraun]

Looking good now! Thank you, @7h3qu1rkyb1t!

If you or others can confirm that it still works as expected after the rebase, and if no one objects, I'll merge.

[hardfau1t]

i havent checked for all frequencies but i am currently working on a project which uses this PR, i am getting 390 KHz for 400KHz frequency

[hannobraun]

Okay, I'm going to merge this now. If any problems still persist, I'm sure we'll notice at some point :-)

Thank you, @7h3qu1rkyb1t!