For exact data transfer by using FT2232H .

If I were to guess, I would guess that it's a software/driver issue.

Poking around in the 2232 driver, I found occasions when it was confused about "ready" and "not ready", and why the two should be treated differently.

Tech support is in Scotland, and you need to get your call in before

Good Luck, AL

received

==============================================================================

-------------------------------------------------------------------------

Thanks ALEX,

Actually, I cannot fully understand the meaning of "ready" & "not ready"

So I really need to hear from you some advice about using FT2232H.

But, how can I connect you, to Tech Support ?

Please let me know.

Many thanks Paul

I do not work for FTDI. I used to work with FTDI parts, but not any more.

My advice about using the FT2232H is "don't".

Good luck with that, AL

==============================================================================

-------------------------------------------------------------------------

Can you share specific details? I was considering using one of these in a future project.

Regards, Allan

.....

From direct and indirect experience I would agree.

....

I have directly and indirectly worked with FTDI devices and with USB devices, I would recommend the following -

a) The major issue is not the hardware, but drivers, how easy it is to communicate from required host systems.

TRIAL the DRIVER in various configurations on MULTIPLE systems, as often this is a problem.

CHECK what happens with MULTIPLE devices on ONE system.

CHECK if the USB driver installs various process/services that are ALWAYS running even if not being used.

b) Prototype the transfer system and stress test this.

Check what happens at HIGHER data rates than you will require

Check what happens when data is bursty, or worst still application delays occur on the host.

One customer had to do continuous checks on FIFO data streams to get around FTDI buffer glitches, due to inexact sizing problems from a continuous data stream.

c) Software removal/version control

Check that removal/upgrade of any driver is done CLEANLY (many leave nasty bits on OS assume you never uninstall)

Does the API, library, driver provide methods of CORRECTLY reading version numbers?

FTDI (and others) fail on both points. So it is possible to get buffer OVERRUN problems you CANNOT PREVENT, causing crashes.

Why is this important? Basically you cannot always 100% GUARANTEE that no one will not add another version of the driver in a few months time because another product use the same driver.

Basically various people in engineering departments of several manufacturers, do NOT believe these are an issue they are more concerned with 'go-faster stripes'.

Don't even get me going on USB printers that insist on reinstalling the driver just because the SAME printer was plugged into a different USB connector on the SAME hub.

Isn't this last one just a case of the vendor being too cheap to buy a USB device ID?

No it is a case of not being bothered to put into 'cheap' printers, serial numbers for the driver to recognise the same printer. I am talking about a lot of the BIG brand USB printers, (or even the supposed networked ones that have to be connected by USB to each computer in turn before they can be 'networked').

They are more interested in making each model use different consumables than making its software do useful functions. The software will often do lots of marketing things.

That boggles the mind.

Robert

Not as uncommon a practice as you might think, even scanners had problems

Started as SCSI Then went parallel port drive So software emulator of parallel to SCSI to talk SCSI driver

Then went USB, many early USB drivers were USB -> parallel emulator parallel emulator -> SCSI emulator SCSI emulator -> SCSI driver

Don't forget sofwtare and CPU cycles are cheap in these people's minds.

Interface emulation doesn't surprise me. Many of us relay on serial port emulation over USB after all. I'm just surprised at a network printer implementation that requires lugging a printer around to multiple machines before it can be networked. It's hard to believe something that misbegotten made it out of the development lab.

Robert

The misbegottten thing that made it out of the development lab is called "Windows". Thank the boys and girls in Redmond for this SNAFU.

By plugging the USB cable to the printer, DLL's are copied from some secret on-disk archive to a place where they can be found, and now the printer will work over the network.

AL

The SMB printer protocol allows for downloading the drivers from the network computer that has the printer. It's clearly the right solution, but didn't work in your case. Perhaps some security settings disallow downloading drivers from the LAN? You'd have to ask your corporate network folk, because this stuff works right most of the time for most people... and I believe there are good reasons why it should fail to work in some other cases. Keep in mind that drivers have complete control of the jolly green giant.

When you plug the printer in directly, Windows detects it and installs from a local .CAB archive file, which might not be the most recent driver; that is presumed to be more likely to come from the network hosting the device... when that install works.

Clifford Heath.

Network printer and networked (shared) printer are two different entities. True networked printers have drivers installed (ny one means or anorther on every accessing system and talk DIRECT to printer.

Shared or pseudo networked printers running from server queues (using the network as long line printer cable and doubling network traffic) are different and require different setup.

Neither method works for some manufacturers who have a network printer with USB and network ports. The action of loading bloatware for the driver insists that EACH computer be connected via USB BEFORE loading the driver, because they have not thought out network driver installs. Good network printer drivers ask first if this is a network printer and search/request its name/port/server/ip address FIRST.

Which has nothing to do with original point made, you are assuming all 'network' printers only exist on LARGE corporate networks, I know many cases of small outfits with less than 5 systems and 2 network printers. Not a single server in sight or on site!

In my small setup of nearly 8 systems, we have two network printers one mono laser and one colour laser.

Assumptions, assumptions, assumptions.

... ==============================================================================

Many thanks to your concern.

But, actually, I haven`t found a good solution yet.

I have tried like below :

The result is same.

The result is same.

The result is same.

I fall into Chaos during 2 weeks!

If anyone has same experience, please tell me about your tips!

Thanks

Paul Ham

Are You sure Your FPGA-desing is OK? Your talking the FT2232 all the time but couldn't it be that the flaw is not in that ic?

Yours sincerely, Rene

==============================================================================

CDM_2.04.16.

==========================================================================

I appreciate you about good advice.

Prior to suspecting the FT2232 ic, I have checked my FPGA design several times

Data overrap was found quite randomly and rarely.

My verilog coding is very simple.

When triggering by switch, it starts sending 8bit data to FT2232 ic.

The data has linear valuefrom 0 to 127 .

And the total data amount is 18MBytes.

I have found that the data overrap error happened quite randomly

and by a few amount ! (under the 1Kbytes of 18MBytes)

==========================================================================

What should I try ?

Please give your tips. Thanks.

Paul

I made my verilog coding quite regularily.

So there`s no doubt on the side of data sending.

I am working with FT2232H as well.

My setup is a FT2232HQ mini module + an Actel Igloo nano Dev Board.

In my case I limited my FPGA --> FTDI data into 512 Byte Chunks because I have seen under my Logic Analyzer that TXE# will ALWAYS go HIGH after the 512th byte is sent. After I send the 512th byte, I toggle both OE# and WR# HIGH on the next Rising CLOCK, then I wait for the TXE# to go LOW

again before sending my next 512 bytes...

When starting the WRITE transaction, I always toggle the OE# first and then

toggle the WR# on the next rising clock.

When stopping the WRITE transaction, I toggle both OE# and WR# on the same clock.

With this configuration, I was able to transfer GBs of data with no error.

The 512 Byte Limitation is also true for FTDI --> FPGA transactions. The RXF#

also toggles itself HIGH after the 512th byte ;o(

Too much for the 4KB RX and TX buffers written on their Datasheets... Maybe it is a misprint as it is actually only 4Kbits hehehehe..

B.R. Linus Hernandez

LOW

Linus Hernandez, I have some questions to you. Why do you use OE# to transfer data from FPGA to FTDI? Pin OE# used only to transfer data from FTDI to FPGA. And if you have OE# low during your transferring from FTDI to FPGA, as I understood, your data conflict with data from FTDI.

And another question, what speed do you achieved using 512 Byte Chunks in trasferring FPGA --> FTDI?

Thank you.

Hello, Has anyone achieved USB 2.0 transfer speeds (480 Mbps) for FTDI 2232H

- FPGA interface using the Synchronous FIFO mode. OR this 480 Mbps always remains the Theoretical Max and we get somewhere around 240 Mbps ?

Thanks, Manish