For exact data transfer by using FT2232H .
Paul Ham
I`ve got a problem with the FT2232H programming.
=================================================
I`vs send my 18Mbytes data from FPGA to PC via the FT2232H IC.
I set the USB transfer-size to 64KByte by FT_SetUSBParameters().
And I could find that the received 18MBytes was fully transfferd well.
EXCEPT the several data delay like below : (each number is 8bit received
data)
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
....
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
....
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
....
0 1 2 3 4 5 6 7 8 9 10 7 8 9 10 11 12 13 14 15 16
....
17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
....
17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
....
17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
....
Above is just example. Actually, the delay has started at 31744th byte
first.
The starting point didn`t change, but the delay length is changable.
I have no idea how I can make it exactly.
==============================================================================
Has anybody got an idea about this issue?
There is few data for this new released device, FT2232H.
Greeting, Paul
LittleAlex
>
> I have no idea how I can make it exactly.
>
> ==============================================================================
>
> Has anybody got an idea about this issue?
> There is few data for this new released device, FT2232H.
>
> Greeting, Paul
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
11:00 AM local time...
Good Luck,
AL
Paul Ham
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
LittleAlex
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
Allan Herriman
Can you share specific details? I was considering using one of these in
a future project.
Regards,
Allan
Paul Carpenter
allanh...@hotmail.com says...
> On Thu, 28 May 2009 09:18:57 -0700, LittleAlex wrote:
>
> > On May 27, 7:03 pm, "Paul Ham" <hamsd...@gmail.com> wrote:
> >> >On May 27, 1:14 am, "Paul Ham" <hamsd...@gmail.com> wrote:
> >> >> Hello,
> >>
> >> >> I`ve got a problem with the FT2232H programming.
> >>
> >> >> =================================================
> >>
> >> >> I`vs send my 18Mbytes data from FPGA to PC via the FT2232H IC.
> >>
> >> >> I set the USB transfer-size to 64KByte by FT_SetUSBParameters().
> >>
> >> >> And I could find that the received 18MBytes was fully transfferd
> >> >> well.
> >>
> >> >> EXCEPT the several data delay like below : (each number is 8bit
> >> received
> >> >> data)
> >>
> >> >> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
> >> 20
> >> >> ....
> >>
> >> >> Above is just example. Actually, the delay has started at 31744th
> >> >> byte first.
> >> >> The starting point didn't change, but the delay length is
> >> >> changeable.
> >>
> >> >> I have no idea how I can make it exactly.
> >>
> >> >> Has anybody got an idea about this issue? There is few data for this
> >> >> new released device, FT2232H.
> >>
> >> >> Greeting, Paul
> >>
> >> >If I were to guess, I would guess that it's a software/driver issue.
From direct and indirect experience I would agree.
> >> >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
> >> >11:00 AM local time...
....
> >> 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".
>
> Can you share specific details? I was considering using one of these in
> a future project.
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.
--
Paul Carpenter | pa...@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate
Nobody
> 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?
Paul Carpenter
nob...@nowhere.com says...
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.
Robert Adsett
says...
> 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').
That boggles the mind.
Robert
Paul Carpenter
su...@aeolusdevelopment.com says...
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.
Robert Adsett
says...
> In article <MPG.248bc2162...@free.teranews.com>,
> su...@aeolusdevelopment.com says...
> > In article <MPG.248bacaf5...@172.16.0.1>, Paul Carpenter
> > says...
> > > 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').
> >
> > That boggles the mind.
>
> 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
>
>
LittleAlex
> In article <MPG.248c84b0dfc157d2989...@172.16.0.1>, Paul Carpenter
> says...
>
>
>
> > In article <MPG.248bc21626b64ae5989...@free.teranews.com>,
> > s...@aeolusdevelopment.com says...
> > > In article <MPG.248bacaf55663480989...@172.16.0.1>, Paul Carpenter
> > > says...
> > > > 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').
>
> > > That boggles the mind.
>
> > 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
Clifford Heath
> 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.
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.
Paul Carpenter
n...@spam.please.net says...
> Robert Adsett wrote:
> > 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.
>
> The SMB printer protocol allows for downloading the drivers from
> the network computer that has the printer. It's clearly the right
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.
> 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.
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.
> 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.
<sound of eldery relative doing oral motions with ovary products>
Assumptions, assumptions, assumptions.
> Clifford Heath.
Paul Ham
==============================================================================
Many thanks to your concern.
But, actually, I haven`t found a good solution yet.
I have tried like below :
1) Reinstalling a Driver for FTDI device.
I concerned the multiple FT_device, Altera` USB blaster and FT2232H
module.
The result is same.
2) Installing CDM_2.04.14 version driver after eliminating CDM_2.04.16.
The result is same.
3) Changing the Maximum tranfer size from 65536 Bytes to 4096 Byte.
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
Rene
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
Paul Ham
==========================================================================
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.
skiddd
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
Vitamin
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.
Manish
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
On Sep 2, 4:56 pm, "Vitamin" <andrey-vita...@yandex.ru> wrote:
> >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 myFPGA-->FTDIdata 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 forFTDI-->FPGAtransactions. 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
>
> Linus Hernandez, I have some questions to you.
> Why do you use OE# to transfer data fromFPGAtoFTDI?
> Pin OE# used only to transfer data fromFTDItoFPGA.
> And if you have OE# low during your transferring fromFTDItoFPGA, as I
Marco
--
Marco
UCO Lick Observatory
Laboratory for Adaptive Optics
"Manish" <myra...@gmail.com> wrote in message
news:61285ecc-0465-43e1...@q40g2000prh.googlegroups.com...
amess
"AN_130 FT2232H Used In An FT245 Style Synchronous FIFO Mode". In this app.
note they say to enable RTS_CTS flow control in the driver. This fixed the
problem for me. I would not of thought this would be applicable to the high
speed sync-fifo mode, but it fixed it for me. I am currently transferring 1
GB of data in about 1 minute without errors on a machine that is probably 3
to 4 years old.
Good luck!
This chip is pretty nifty assuming the wrinkles can be ironed out.
- amess
---------------------------------------
This message was sent using the comp.arch.embedded web interface on
http://www.EmbeddedRelated.com