This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Request for comments onCYG_I2C_BITBANG_SCL_LOW_SDA_INPUT patch
----- 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