Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #31391

I2C bus recovery

From pozz <pozzugno@gmail.com>
Newsgroups comp.arch.embedded
Subject I2C bus recovery
Date 2022-11-08 16:08 +0100
Organization A noiseless patient Spider
Message-ID <tkdre4$3s0fi$1@dont-email.me> (permalink)

Show all headers | View raw


I wanted to implement an I2C bus recovery during initialization. The 
reason is well known in literature[1].

I read the function i2c_generic_recovery[2] of Linux kernel, but I don't 
understand one thing.

The bus recovery is necessary to bring a slave to the end of a byte 
transmission that could be interrupted for some reason.
However the slave could be transmitting 0xFF, so why the above function 
breaks the loop if SDA is detected high?

     [Line 620] /* Break if SDA is high */

Maybe it's better to send 9 clock cycles whatever the level of SDA line.

And what about STOP condition at the end of the 9 clock cycles? Is it 
necessary? It should be (SCL is already high): set SDA low, pause, set 
SDA high.

Do you use this sort of bus recovery?


[1] 
https://www.analog.com/media/en/technical-documentation/application-notes/54305147357414AN686_0.pdf

[2] https://elixir.bootlin.com/linux/v4.5/source/drivers/i2c/i2c-core.c#L604

Back to comp.arch.embedded | Previous | Next — Next in thread | Find similar | Unroll thread


Thread

I2C bus recovery pozz <pozzugno@gmail.com> - 2022-11-08 16:08 +0100
  Re: I2C bus recovery antispam@math.uni.wroc.pl - 2022-11-08 22:08 +0000
    Re: I2C bus recovery pozz <pozzugno@gmail.com> - 2022-11-09 08:32 +0100
      Re: I2C bus recovery Richard Damon <Richard@Damon-Family.org> - 2022-11-10 07:12 -0500
        Re: I2C bus recovery Rick C <gnuarm.deletethisbit@gmail.com> - 2022-11-10 09:06 -0800
        Re: I2C bus recovery pozz <pozzugno@gmail.com> - 2022-11-10 23:39 +0100
      Re: I2C bus recovery antispam@math.uni.wroc.pl - 2022-11-10 17:26 +0000
      Re: I2C bus recovery Michael Schwingen <news-1513678000@discworld.dascon.de> - 2022-11-13 10:52 +0000

csiph-web