On 01/14/12 04:38, cheffner wrote:
>
> Matt wrote
>> I set SDA as an input in order to read
>> the (N)ACK from the slave but the FT4232 does not stop driving the SDA
>> line until half way through the clock cycle...
>
> AFAIK, this is expected behavior. When in three-phase clock mode, the FTDI
> chip will hold the data pin high (assuming that the transmitted data bit was
> a 1 of course) until after the clock line has gone low in order to ensure
> that data is available on the falling edge of the clock. The same thing is
> done on the rising edge, obviously.
It may be expected behaviour but it can cause undefined behaviour on the
i2c bus.
> If I understand the problem correctly, your I2C slave device is attempting
> to drive the data line low before the clock has fully transitioned to a low
> state. If this is the case, then I would say that you would have this
> problem no matter what the FTDI chip did (if anything, the FTDI chip
> attempting to keep the data line high would possibly prevent other chips on
> the bus from seeing a start condition).
No. The clock has transitioned to a low state but the FTDI chip drives
the data line high after this has happened (ie because the 3-phase clock
has been enabled). This results in bus contention, ie the slave driving
it low after it has seen the falling clock edge and the FTDI device
continuing to drive it high. You should look at the Philips i2c spec for
the defined behaviour.
> As for clock stretching, no, I am not aware of a command or explicit support
> for clock stretching (someone correct me if I am wrong here...). You could
> always send one bit/byte at a time through MPSSE and check the clock
> manually before each transmission, but that is essentially bit banging like
> you are doing now.
Agreed. I don't think that MPSSE mode can be used to implement i2c
correctly at all. Using the MPSSE mode i2c implementation I had (in
which I experimented with and without using the 3-phase clock), some
devices were consistently happy with the timings, where as others were
not and others would drive a NACK onto the bus for no obvious reason
(I've got a lot of peripherals on the bus). Using an EEPROM to test with
is not a defining attribute of having a working i2c system. EEPROMS are
designed to be very loose around the edges. It's a fairly well known
fact. According to my scope, the i2c bus transactions with my MPSSE i2c
implementation looked fine (albeit with crazy delays caused by the FTDI
device read function). However, what the scope couldn't tell me was the
effect of MPSSE mode driving SCL and SDA low /and/ high was on the
slave. Each slave device has a hw state machine which may have been
thrown off because of the 'step' when using the 3-phase clocking mode or
the master not supporting clock stretching etc etc.
I know there are some very lazy i2c implementations out there and some
are probably fraught with on-the-edge timings. If they are using an FTDI
device in MPSSE mode then I imagine this would explain things...
-- Matt
>
>
> --
> View this message in context:
> http://libftdi.141977.n3.nabble.com/Driving-open-collector-in-mpsse-mode-i2c-woes-tp3647284p3658349.html
> Sent from the libFTDI mailing list archive at Nabble.com.
>
> --
> libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
> To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
>
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
