Hello, I have this project to do in two months and I will appreciate any help I can get. I am using the FT2232D FTDI chip as the processor to convert USB signals to I2C, The aim is to read data from an EEPROM (24C64). The attached file shows exaclty what I want to design. I need to add a real current source on the SDa and SCL lines and I am using a PNP transistor...BCV62C instead of pull up resistors.

do I need two transistors? how do I connect this?

Thank you very much in advance

 

In order to do I2C you're going to need something besides the FTDI chip. The non-USB side interface of the FTDI chip will talk to a UART, FIFO, or SPI port on some microprocessor, and the microprocessor will talk to the the I2C device. I don't know where you got the idea you could do it without one.

 

Well, reading through the FT2232D data sheet, I was made to understand that the Multi-Protocol Synchronous Serial Engine (MPSSE) makes it possible to use a single FTDI chip for communiction...but taking your advice, what μc would you recommend (cost effective) to handle the serial to I2C interface?

Thank you very much

 

I also got this information from the FTDI site....

Overview

This example project for the FT2232 demonstrates how to use the device's Multi-Protocol Synchronous Serial Engine (MPSSE) to make a USB to I2C bus interface. The executable application and full project code (in Delphi) are provided.


Requirements

This project is designed to run on Windows 2000 or Windows XP and requires FTDI's D2XX drivers to be installed.

Download the project documentation and schematic in PDF format by clicking here.

Download the Delphi source code for the application by clicking here.

Please advise...

Thank you very much

 

Well, reading through the FT2232D data sheet, I was made to understand that the Multi-Protocol Synchronous Serial Engine (MPSSE) makes it possible to use a single FTDI chip for communiction...but taking your advice, what μc would you recommend (cost effective) to handle the serial to I2C interface?

Thank you very much

I guess I believed the datasheet that you provided which allowed for UART, SPI, and parallel FIFO. None of those interfaces would be directly useable with an I2C peripheral. If they have some additional magic that allows them to do I2C then go for it. It just wasn't obvious from the initial information that you provided.

Also, I am unfamiliar with Delphi. So there is another thing to learn.

 

yeah...I believe using just that chip will b sufficient. I am not going to use delphi as that was a project done by soeone who decided to use delphi...I can pretty much do quite a bit of the project, the major problem im having is using transistors instead of pull up resistors on the SDA and SCL lines.

 

Have you attached the right file? I can't find any mention of SDA or SCL on your attachment.

 

Have you attached the right file? I can't find any mention of SDA or SCL on your attachment.

Follow the link in post #4. It is different than the link in post #1

 

yeah...I believe using just that chip will b sufficient. I am not going to use delphi as that was a project done by soeone who decided to use delphi...I can pretty much do quite a bit of the project, the major problem im having is using transistors instead of pull up resistors on the SDA and SCL lines.

I'm just curious about why you think you should use transistors in place of pullup resistors. Are you driving incredibly long lines with boatloads of capacitance or something?

 

The MP SSE code in the chip is used to bit-bang many things, including JTAG interfaces to microprocessors, etc as a debug/programming probe. It should still work to implement I2C as well, though how fast it ultimately can go may be limited by the USB channel speed, but perhaps high speed (1.0+ MHz) I2C bit rates could be achieved with it.

You should use pullups on the I2C lines - download the I2C spec from the NXP website for info on max capacitive loading .vs. clock rate, etc. and appropriate pullups or series resistance for use in high capacitance applications.

 

I'm just curious about why you think you should use transistors in place of pullup resistors. Are you driving incredibly long lines with boatloads of capacitance or something?

Well, I need to include a real current source of 3mA on the SDA and SCL, thats why I want to use transistors instead, prefareably PNP. I am sure there are other ways to do this but I figured this would be the most convenient.

Thank you again

 

The MP SSE code in the chip is used to bit-bang many things, including JTAG interfaces to microprocessors, etc as a debug/programming probe. It should still work to implement I2C as well, though how fast it ultimately can go may be limited by the USB channel speed, but perhaps high speed (1.0+ MHz) I2C bit rates could be achieved with it.

You should use pullups on the I2C lines - download the I2C spec from the NXP website for info on max capacitive loading .vs. clock rate, etc. and appropriate pullups or series resistance for use in high capacitance applications.

Yeah..I know I can and dats the easiest way..but, cuz Im trying to ensure a steady state current on both lines, I have to use a real current source.

Thanks for your input and I look foward to hearing from you.

 

Have you attached the right file? I can't find any mention of SDA or SCL on your attachment.

The attachment I put in #1 was just to give an overview of what im trying to do and how to achieve it.....I2C bus was not used in that project but mine will use it.

 

like as per my knowledge we must use pullups for i2c lines.

 

Well, I need to include a real current source of 3mA on the SDA and SCL, thats why I want to use transistors instead, prefareably PNP. I am sure there are other ways to do this but I figured this would be the most convenient.

Thank you again

OK let me be more precise. Why do you think you need to have an active current source on SDA and SCL? The I2C devices don't require such a thing. What do you hope to achieve?

 

I guess I am also confused as to why you'd want steady current sources tied to these lines. One of them is supposed to be basically open collector (and pullup). If you've a constant current source on both lines, you may have a situation in which a slave device is fighting against the current source (and lose). Bus arbitration might also suffer.

The only time I've used transistors (mosfets) on the I2C lines was to isolate a branch of the I2C bus, or to do voltage conversion from 3V to 5V and 5V to 3V devices.

 

And the sad part is the some beknighted soul will give him a "circuit", and he will implement it, and it won't work the way he expects it to, and he'll be back asking us to explain why his circuit won't do what he wants it to do. "Just you wait 'enery 'iggins -- just you wait."

 

I do understand that you guys are the experts in this field and I can say I know nothing..but I eager to learn... If I am lucky enough to get a circuit to implement, I will still have analyze it to make sure I understand it because I will have to write a report explaining in great details what we( u guys and myself) have done. I do appreciate the help I am getting from you guys and I do not intend to discourage any of you by my inexperience.

I believe I was adviced to use transistors because we also need to achieve faster rise times due to the fact that data will be read from a given number of eeproms in a day.

 

I am looking at MOSFETS also to see if i can implement that.

 

I do understand that you guys are the experts in this field and I can say I know nothing..but I eager to learn... If I am lucky enough to get a circuit to implement, I will still have analyze it to make sure I understand it because I will have to write a report explaining in great details what we( u guys and myself) have done. I do appreciate the help I am getting from you guys and I do not intend to discourage any of you by my inexperience.

I believe I was adviced to use transistors because we also need to achieve faster rise times due to the fact that data will be read from a given number of eeproms in a day.

Rise time and fall time of the set of waveforms required to read an EPROM will be a small fraction of the total time. I would estimate on the order 1-3%. The fundamental limitation of I2C is that the frequency of SCL may not exceed 400 kHz. For short traces and light capacitive loading there is nothing you will be able to do with rise and fall times that will allow you to improve the throughput. Try rounding up some datasheets or better yet go to the Philips (now NXP) website for a copy of the I2C specification. I don't think there will be much of a payoff from pursuing this line of inquiry.