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
