[ECOS] Request for comments onCYG_I2C_BITBANG_SCL_LOW_SDA_INPUT patch

Morten Leikvoll leikvoll@cyviz.com
Mon Mar 13 16:05:00 GMT 2006


----- Original Message ----- 
From: "Bart Veer" <bartv@ecoscentric.com>
To: <leikvoll@cyviz.com>
Cc: <oyvind.harboe@zylin.com>; <ecos-discuss@ecos.sourceware.org>
Sent: Friday, March 10, 2006 6:38 PM
Subject: Re: [ECOS] Request for comments onCYG_I2C_BITBANG_SCL_LOW_SDA_INPUT 
patch

....
> Replacing SCL_LOW_SDA_INPUT with SCL_LOW followed by SDA_INPUT is not
> safe. The processor may be interrupted between SCL_LOW and SDA_INPUT,
> so there could be a long delay between these two operations and the
> I2C device may start driving the bus at that time. Instead
> SCL_LOW_SDA_INPUT should be an atomic operation, with the banger
> function potentially having to disable interrupts for a few cycles. Of
> course a conflict can only happen on poorly designed hardware, and on
> sensible hardware there is no need to disable interrupts.

This is not a problem if the I2c IO is implemented correctly. It does not 
matter if both the slave and master pulls SDA low at the same time. This is 
acceptable. Letting SDA change while CLK is falling is not..
If one device is pulling low, there can only be a problem if the other 
device is pulling high at the same time, wich a proper implemented device 
"never" do. In case they do, make sure you can pull harder, and wait for 
ringing to stop before sensing ;p

....

> There is probably scope for improving the documentation for the
> bit-banging code, especially more information on how the banger
> function should work in various circumstances. I'll take another look
> at the docs when I get a chance. However I don't see any need to
> change the generic bit-banging code for this issue, any problems
> should be addressed at the platform level.


Our next issue with this driver involves potential problems synchronizing to 
hot plugging devices wich has been interrupted in the middle of a SDA_low 
cycle and when plugged back the SDA is still low. In this case, a start 
condition can not be generated. The I2cStart phase need to check if the SDA 
is high before attempting to do a start condition. If not, it must cycle the 
clock (for max 9 cycles) until SDA goes high. If its not doing so after 9 
cycles, we can assume there is a short circuit or faulty IO. In the end, we 
may also need to verify changes in SCL too.

Morten Leikvoll


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss



More information about the Ecos-discuss mailing list