Easiest way to collect some data @50MB/s and dump to computer

[magic]

I think dual in it means "dual UART"

No, it can also do dual bus modes IIRC, maybe not every one of them but some. Read the datasheet before dismissing it.
Or use a pair of FT chips on different USB ports

[SuperFungus]

If you are planning on using the FX2, I can recommend the fx2pipe software: https://www.triplespark.net/elec/periph/USB-FX2/software/fx2pipe.html

It's a command line utility which will allow you to ingest data from an FX2 board at pretty much max possible speed.  One of the advantages is it comes with a firmware image and the capability of updating the attached FX2 over USB, so the whole process is transparent.  No need to set up a 8051 development environment, write and debug firmware for the FX2 etc.

[magic]

That's awesome if it works as advertised

[abyrvalg]

Indeed there is a driver written by Cypress themselves (cyusb.sys and newer cyusb3.sys), it has an inf file with some predefined vids/pids. We’ve seen >50MB/s throughput with Cypress’s Screamer test firmware/software and their driver. Inability to achieve >45MB/s with libusb can be a problem of libusb/winusb.
Note that you need to implement some specific mode (16-bit synchronous slave FIFO iirc) to get the maximum. 8-bit modes can’t reach it. I’ve seen FX2-based USB-DVB boxes using a latch to convert 8-bit TS bus to 16-bit to increase the bandwidth.

[magic]

If you are planning on using the FX2, I can recommend the fx2pipe software: https://www.triplespark.net/elec/periph/USB-FX2/software/fx2pipe.html

Any option to make it work with nothing external connected to the chip's bus, like those logic analyzers? I just want to test it, but no results so far...

It also doesn't work with libusb1 + libusb0.1-compat. That was resolved by installing genuine libusb0.1 (version 0.1.12).

Code: [Select]

fx2pipe: wwusb.cc:129: WWUSBDevice::ErrorCode WWUSBDevice::_DoConnect(usb_device*): Assertion `dev_handle_to_dev(udh)==udev' failed.Maybe there are still some issues and it only pretends to work.

[Kjelt]

Can you create an esata interface on your fpga? You could dump it to an ssd.
Or perhaps an 10Gb/s ethernet interface? I can do 600MB/s sustained to my NAS using fiber optical 10Gb/s ethernet.

[NiHaoMike]

Can you create an esata interface on your fpga? You could dump it to an ssd.
Or perhaps an 10Gb/s ethernet interface? I can do 600MB/s sustained to my NAS using fiber optical 10Gb/s ethernet.

10G Ethernet is exotic and overkill. Plain 1G will easily do 100MB/s real world throughput.

[Doctorandus_P]

Cypress CY7C68013 is  FX2. Cypress also has a FX3 version which works with USB3 which will probably be plenty fast. A dusty cabinet in my memory suggests a price of EUR60 for a development board.

Another viable option may be to use one of the many small Linux single board computers.
Boards with 1Gbps Ethernet are less common then with 100Mbps, but there is still enough choice. I have no idea though much effort is required to push that kind of data through the I/O pins of such a board.

As you are already into the FPGA stuff, one of the cards from Mesa might be a viable path. For example: https://store.mesanet.com/index.php?route=product/product&product_id=55 These cards are popular for use with LinuxCNC.

[SuperFungus]

If you are planning on using the FX2, I can recommend the fx2pipe software: https://www.triplespark.net/elec/periph/USB-FX2/software/fx2pipe.html

Any option to make it work with nothing external connected to the chip's bus, like those logic analyzers? I just want to test it, but no results so far...

It also doesn't work with libusb1 + libusb0.1-compat. That was resolved by installing genuine libusb0.1 (version 0.1.12).

Code: [Select]

fx2pipe: wwusb.cc:129: WWUSBDevice::ErrorCode WWUSBDevice::_DoConnect(usb_device*): Assertion `dev_handle_to_dev(udh)==udev' failed.Maybe there are still some issues and it only pretends to work.

Well it's been a few years since I've used it, but I used this hardware with it: https://www.banggood.com/EZ-USB-FX2LP-CY7C68013A-USB-Core-Board-Development-Board-Logic-Analyzer-p-1183409.html?rmmds=search&cur_warehouse=CN  I've also run it on custom hardware, and as far as I can remember the only hardware requirements were the clock and EEPROM (you may be able to get away without the EEPROM if you load into RAM over USB on every connection).

Are you on a Windows or Linux host computer?  I used Linux, and don't recall having any problems building it and getting it to work so that could be another variable.

Edit: I just tried this myself and see the libusb issue.  It looks like (for performance reasons) fx2pipe wants to queue multiple URB's, and needs a Linux file descriptor to do this since libusb0.1 would only send one at a time.  Because libusb considers this file descriptor private data, fx2pipe had to get the file descriptor by kind of "breaking into" libusb's api and taking an offset into an opaque data structure libusb provides.  In later versions, this offset is no longer correct, which is why it doesn't work with newer versions of libusb. 

It's a real shame, the software worked really well when I used it years ago.  The transparent firmware upload made it super simple to set up, flexible, and fast.  I sent an email to the author to get his thoughts on what it would take to fix.  Some cursory research makes me think that libusb v1.0 or greater's async modes would allow the same URB queuing, but through the stable API.

[magic]

Yes, I have resolved this problem by installing libusb0.1 and verifying that usb_device_handle has the same layout as encoded in wwusb.c, but it still didn't do anything

Code: [Select]

fx2pipe -I -ifclk=30 -8
Firmware config: 0x12 0x83 0xe0 0x0c 0x12
IO loop running...
Downloading firmware [builtin]...
Submitting max. 16 URBs to fill pipeline... 16 submitted
# got bored waiting and killed it
^Creap_rv=-1, errno=Interrupted system call
OOPS: ProcessEvents: ec=4
IO loop exited
Cancelled 16 pending URBs (npending=16), reaping... done reaping (16): npending=0
fx2pipe: 0 bytes in 3.358s (avg 0 kb/s)
I ran it on a similar breakout board with just the chip, crystal and EEPROM. It should be functional because I used it with sigrok in the past.
I assume EEPROM content is irrelevant, because fx2pipe loads its own FW onto the chip on every run.

[ataradov]

You need to check how the interface is actually configured. The useful mode for FIFO is with external clock, so if you don't supply the clock, it won't do anything.

[magic]

That's the thing, I was asking if fx2pipe (and its firmware) can be given any options to set the chip up so that it simply records data without looking at external clock or anything, like sigrok does. I also tried without any options, 0 bytes received again. Also output, nothing happened either.

[SuperFungus]

I was using it with a synchronous interface and supplied  a clock.

Have you tried any of the internal ifclk options described in the help? https://www.triplespark.net/elec/periph/USB-FX2/software/fx2pipe.html

[Harvs]

I've tried fx2pipe quickly this evening with a "saleae" clone board. 

Same result, no data transfered, regardless of option (tried all the internal clock options and "async" option.)

However in the troubleshooting section, it links to another page:
https://www.triplespark.net/elec/periph/USB-FX2/software/io_examples.html

In the benchmark example (which I'm guessing is what the -I option is all about), there's a few pins that must be tied high and low for it to work. This may be worth looking at, I haven't had the chance to do it.

[SuperFungus]

That link looks promising, I'm willing to bet that is the issue.

Obviously my memory of how this all works is a little fuzzy.  At the time I had recently read the FX2 datasheet and app notes and had a much better sense for what needed to be done to drive the FIFO's in the FX2...

[Harvs]

I had a look at the board I have under the microscope and those pins aren't hooked up.  Because I have the QFN package it's probably not worth the trouble for me to go any further.

Still be interesting to see how c64 goes.

[c64]

Still be interesting to see how c64 goes.

I think I buy both ftdi and fx2 and try them both, starting with ftdi. If I get clone ftdi chip, will I be screwed by the drivers? Or was it only problems with UART driver?

[c64]

I've tried fx2pipe quickly this evening with a "saleae" clone board. 

I actually have one of these. Never tried it though. If I can find it, I look at my pins

[SiliconWizard]

Still be interesting to see how c64 goes.

I think I buy both ftdi and fx2 and try them both, starting with ftdi. If I get clone ftdi chip, will I be screwed by the drivers? Or was it only problems with UART driver?

If you use an FTDI chip, you're not going to use it in UART mode (as we said earlier, it would yield a very low throughput, something you didn't want.)
(The drivers have little to do with the actual mode: you can use either the VCP - serial emulation - or FTD2XX drivers when using the FTDI chip in parallel mode, although if you are going to use a synchronous parallel mode, you can only use FTD2XX drivers AFAIK.)

That driver question aside, as long as you use an FT232H or FT2232H chip, you shouldn't worry about clones - those chips were never cloned AFAIK. Only the cheap, specialized USB to UART converter ICs with no parallel mode were cloned AFAIK (like the FT232R and derivatives.)

[jkostb]

I strongly recommend the FT600 or FT601. I have build a board consisting of spartan 7 FPGA (Xilinx) and the FT601. The FT601 was used to transfer data from AD converters to the PC. Actually the PCB also contained an USB hub from TI. We easily reached data rates > 250 Mbytes/s. So the 50 Mbytes/s, which you are referring to, is peanuts with the FT600/601.  You only need to pay special attention to the board layout of the USB 3 superspeed TX/RX pairs, because it is controlled impedance (90 Ohm+/10%). Most PCB manufacturers can advise you about track width/gap if you supply the PCB stackup.

[magic]

However in the troubleshooting section, it links to another page:
https://www.triplespark.net/elec/periph/USB-FX2/software/io_examples.html

In the benchmark example (which I'm guessing is what the -I option is all about), there's a few pins that must be tied high and low for it to work. This may be worth looking at, I haven't had the chance to do it.

It's alive

Code: [Select]

fx2pipe -I
Firmware config: 0x12 0xc3 0xe0 0x0d 0x12
IO loop running...
Downloading firmware [builtin]...
Submitting max. 16 URBs to fill pipeline... 16 submitted
fx2pipe: 239845376 bytes in 6.516s (avg 35946 kb/s, curr 35888 kb/s)
The benchmark page is about another firmware, but fx2pipe also uses the slave FIFO mode which requires a bunch of pins to be strapped right before it transfers any data. The asynchronous option would require external clock, synchronous with internal 48MHz clock appears to be the default.

     Connect to HIGH (3.3V): PA2/SLOE, PA5/FIFOADR1, RDY0/SLRD
     Connect to LOW (GND): PA4/FIFOADR0, RDY1/SLWR

The pins seem to be Hi-Z so no cheating, all have to be connected with cables.

Oddly, I get two different speeds slightly less than 30MB/s with -ifclk=30 -8 on two different machines. That doesn't look encouraging

[SuperFungus]

Oddly, I get two different speeds slightly less than 30MB/s with -ifclk=30 -8 on two different machines. That doesn't look encouraging

How much slightly lower?  I wonder if the ifclock is not running at exactly 30MHz or if fx2pipe is averaging out a one time setup at the beginning.  When I used it years ago, we made a pattern generator to test all the different options with, because we wanted to make sure we weren't going to drop data ever.  We never had any problems.

[magic]

Something like 29300/29150 avg after a few seconds of running continuously when the readings mostly stabilized. I didn't test any further.

Wall clocks of both systems are synced to NTP so I doubt it's measurement error, unless fx2pipe's throughput meter is buggy.

[magic]

Okay, part of the problem turned out to be fx2pipe counting kB as 1024 while the FX2 runs at exactly 30MHz. The 29300kB/s machine actually is correct:

Code: [Select]

$ LD_LIBRARY_PATH=../libusb-0.1.12/.libs/ ./fx2pipe/fx2pipe -ifclk=30 -8 -n=300000000 -0
Firmware config: 0x12 0x83 0xe0 0x0c 0x12
IO loop running...
Downloading firmware [builtin]...
Submitting max. 16 URBs to fill pipeline... 16 submitted
fx2pipe: 293044224 bytes in 9.768s (avg 29297 kb/s, curr 29259 kb/s)URB (just reaped) status=-75 (Unknown error -75), cancelled=0
HMM: URB(18311): blen=8704/8960, status=-75, error count=0, cancelled=0
IO loop exited
fx2pipe: 299991040 bytes in 10.000s (avg 29296 kb/s)
The other one reports times randomly longer by 50~300ms. Clearly something is wrong with that box.

[Harvs]

Super cool, thanks for posting it gave me the enthusiasm to wire those pins up under the microscope.

For reference, because I'm using a saleae clone, the usb vid/pid needs to be added.

Code: [Select]

./fx2pipe -d=0925:3881 -8 n=300000000 -0
Firmware config: 0x12 0xc3 0xe0 0x0c 0x12
IO loop running...
Downloading firmware [builtin]...
Submitting max. 16 URBs to fill pipeline... 16 submitted
fx2pipe: 297517056 bytes in 7.265s (avg 39992 kb/s, curr 39777 kb/s)URB (just reaped) status=-75 (Unknown error -75), cancelled=0
HMM: URB(18311): blen=0/8960, status=-75, error count=0, cancelled=0
IO loop exited
fx2pipe: 299991040 bytes in 7.325s (avg 39995 kb/s)