Increase I2C stability at 400KHz.

[ghent360]

I was testing u8g library with an SSD1306 i2c display.
For some reason I2C communication receives NAK on the device address byte after a while at 400KHz. It transfers maybe 100 bytes or so, then the device responds with a NAK and everything stops. It works fine at 100KHz.

I moved the GPIO initialization before the I2C device clock setup and it magically works all the time. Can't quite figure out why, but it does not seem to hurt.

[fpistm]

Hi @ghent360,
right, I Can't quite figure out why also.
As it is done only one time, at the Wire.Begin().
Maybe the u8g library called several time the Begin ?

One possible improvement could be to change
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
to
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;

[ghent360]

Hi Frederic, I wrote the driver for the u8g lib and I call i2c_init_custom directly. I'll try your suggestion tonight. I only have a logic analyzer and not a very accurate one, so I can't quite measure the precise signal difference. In both cases the signal analyzer captures the start condition and the first byte - timing seems similar. ~V

…

On Mon, Jul 30, 2018 at 2:49 AM, Frederic Pillon ***@***.***> wrote: Hi @ghent360 <https://github.com/ghent360>, right, I Can't quite figure out why also. As it is done only one time, at the Wire.Begin(). Maybe the u8g library called several time the Begin ? One possible improvement could be to change GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH; to GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH; — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#288 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHxY1gdliPX8jraEIX1MiXRnf2bftvriks5uLtaugaJpZM4VmAH9> .

[fpistm]

I think #305 should solve this issue.