You are not providing enough data to even begin to compute your raw rate requirements. You have not given the size of data involved with each pixel read from the sensor. Also missing is info related to if the raw pixel rate that you read is sustained through the full read process or if there are dead band times between scan lines (at least for X/Y arrays) wherein the transfer of the last line has a chance to catch up to the time of the next line start. Once you have this you should be able to compute the actual serial bit rate that would be required to permit sustained reading of your sensor in an open ended manner.

You then need to look at what the guaranteed actual throughput of your communications channel to the PC actually is. The FTDI site says that the FIFO<->USB part that you are using is good for "up to 1MByte / sec" if you use the Direct Drivers and "up to 300KByte / sec" if you use the VCP type drivers. Note that these numbers are maximum numbers and not guaranteed data delivery rates. You've not provided clear data regarding to which driver type you are using and whit type of data sink software is being used so it is difficult to suggest further that rate you may actually be able to achieve.

Another thing that you have not communicated is if you have taken any handshaking or throttling controls into account. The FIFOs in the FT245 are only of limited size in bytes. We do not know how many bytes you are assembling for one scan transfer but is very likely larger than the size of the FT245 FIFOs. As such it is not going to be possible to simply force feed data into the FIFOs at a fixed rate that you choose without comprehending some type of handshaking both at the raw FIFO throttle level or at the higher frame control level back from the data sink software you provide at the PC end.

Can this interface be made to work? Sure it can. On one end of the spectrum you could decide to waive some level of image sensor performance and use it as the persistent data source and appropriately let it transfer pixels in a start/stop way in response to handshaked transfer to the PC so as to assure full data delivery. On the other extreme you could add a whole frame memory buffer to your MCU design so that the maximum pasformance of the sensor can be retained by transferring its image data to local memory at the optimal sensor clocking rate. In this latter case the buffer contents would then be sent, also with consideration to the data throttling handshaking that is needed, over to the PC. A framing level error checking scheme could be devised to permit the use of a retry out of the buffer if there were detected errors in the transfer.

Michael Karas