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 [email protected] > -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to [email protected]
