I2C Manager Driver for multiple slaves

[Vipul Rahane <vi...@runtime.io>]

Hello,

This has come up more than once and just wanted to hash out a design for the I2C manager driver. Having more than one slave is quite common and the slowest slave pulls the clock low prohibiting the master from starting another transaction on the bus.

What we would like to have is :

1. Using the bus while we are waiting for responses from a slave (I assume this would be a case of clock stretching by the slave)
2. Clock timeout on I2C Bus
3. Read back register writes or Verified register writes
    - Multiple register writes will not be supported in this

What do people think about the above features in the I2C Manager and also how to deal with it ? I have some knowledge of I2C and based on that I can think of some kind of solution for 2. and 3.. 1 however seems to be a bit complicated since the nature of I2C is such that it locks up the bus for any future transactions until the slave makes the clock high. Does anybody have any possible solutions for this problem ? 

Hoping to get answers from the community and get this feature written soon.

Regards,
Vipul Rahane

Re: I2C Manager Driver for multiple slaves

[Greg Stein <gs...@gmail.com>]

On Fri, Feb 16, 2018 at 4:28 PM, Sterling Hughes <
sterling.hughes.public@gmail.com> wrote:
>...

> There was some thought that this could be simplified to just be a set of
> requests and responses that get enqueued and dequeued to the I2C bus which
> would be sent in order.  I’m not sure if I2C has the concept of events that
> need to happen within a transaction to a single device, or tight timing
> between them.  I was interested in what others though as well.
>

It does have transactional stuff, in the form of "repeated start". A Master
device gets to define what the bus will do across multiple operations. This
is particularly useful in terms of "Set X as the Register I want to read.
... Now Read that register." ... without a transaction, another actor could
alter the Register-to-read, so the latter operation would read the wrong
thing.

And yes, this actually happens in practice[1].

Cheers,
-g

[1]
http://prng.blogspot.com/2014/10/raspberry-pi-and-lack-of-i2c-repeated.html

Re: I2C Manager Driver for multiple slaves

[Sterling Hughes <st...@gmail.com>]

Hi,

I also think it would be useful to have some sort of concept of 
“access” to the I2C bus, that is if a I2C transaction is in 
progress, you can ask for the bus, and wait for the lock on a queue, and 
then get posted an event when the lock has been acquired so that you can 
use the bus.  This way your task can continue to do other processing in 
the background while the I2C bus is occupied.

There was some thought that this could be simplified to just be a set of 
requests and responses that get enqueued and dequeued to the I2C bus 
which would be sent in order.  I’m not sure if I2C has the concept of 
events that need to happen within a transaction to a single device, or 
tight timing between them.  I was interested in what others though as 
well.

Best,

Sterling

On 16 Feb 2018, at 14:21, Vipul Rahane wrote:

> Hello,
>
> This has come up more than once and just wanted to hash out a design 
> for the I2C manager driver. Having more than one slave is quite common 
> and the slowest slave pulls the clock low prohibiting the master from 
> starting another transaction on the bus.
>
> What we would like to have is :
>
> 1. Using the bus while we are waiting for responses from a slave (I 
> assume this would be a case of clock stretching by the slave)
> 2. Clock timeout on I2C Bus
> 3. Read back register writes or Verified register writes
>     - Multiple register writes will not be supported in this
>
> What do people think about the above features in the I2C Manager and 
> also how to deal with it ? I have some knowledge of I2C and based on 
> that I can think of some kind of solution for 2. and 3.. 1 however 
> seems to be a bit complicated since the nature of I2C is such that it 
> locks up the bus for any future transactions until the slave makes the 
> clock high. Does anybody have any possible solutions for this problem 
> ?
>
> Hoping to get answers from the community and get this feature written 
> soon.
>
> Regards,
> Vipul Rahane

Re: I2C Manager Driver for multiple slaves

[Greg Stein <gs...@gmail.com>]

On Fri, Feb 16, 2018 at 4:21 PM, Vipul Rahane <vi...@runtime.io> wrote:

> Hello,
>
> This has come up more than once and just wanted to hash out a design for
> the I2C manager driver. Having more than one slave is quite common and the
> slowest slave pulls the clock low prohibiting the master from starting
> another transaction on the bus.
>
> What we would like to have is :
>
> 1. Using the bus while we are waiting for responses from a slave (I assume
> this would be a case of clock stretching by the slave)
>

If a slave is clock-stretching, there is nothing you can do. The bus can't
just magically be used with other nodes.

In fact, if a slave is holding SCL LOW to stretch, then the whole bus is
screwed IF/until that slave releases SCL. If it *never* does ... heh.
Whoops. ... I ran into this once. There is just no way to say "dude. let up
on the SCL." ... I had to reset my entire I2C network.

So... not sure what you're thinking here.

Cheers,
-g