Easiest way to collect some data @50MB/s and dump to computer - Page 1
Forum section: electronics / projects

author: c64
author_rank: Frequent Contributor
timestamp: June 12, 2020, 06:43:49 am
content: Everything below is just for testing a prototype, i.e. not needed in production. It means solution can be ugly.I receive some data at ~ 50 MBytes / sec into my FPGA (Cyclone IV E). I want to dump it to the computer. Not necessary in real time. Acceptable solution would be to collect just ~1 sec of data and then send to computer at slower speed.Can you recommend some very easy way to do it? I have no experience with USB or SDRAM. I have USB logic analyzer, 8-bit 24MHz.So far the only idea I have is to dump everything to memory (but 50MB of non-SDRAM is quite expensive) , then transfer to computer at slower speed using:1. Logic analyzer (if it has this feature "dump everything to file")2. LPT port3. Some USB-to-UART thing4. Write to SDCARD - but need to move it between DUT and computer all the timeI guess the proper thing would be to use USB 2.0 which should be good enough for this speed but have no experience with USB

author: ataradov
author_rank: Super Contributor
timestamp: June 12, 2020, 07:04:08 am
content: Cypress CY7C68013 is a high-speed USB to FIFO interface that can do close to 50 MB/s. In theory USB HS can go slightly higher, but in reality I could never get more than around 48-49 MB/s from USB HS. I'm pretty sure this is OS overhead. Windows is slightly worse than Linux in this respect.That Cypress chip will require some programming of 8051 core, but it is pretty trivial, and the task is so common that you will probably be able to find the readily available firmware.There is equivalent chip from FTDI, which may not require programming, but then you will have to deal with FTDI.

author: palpurul
author_rank: Regular Contributor
timestamp: June 12, 2020, 07:24:17 am
content: I believe FT601 can achieve 50MB/s

author: ataradov
author_rank: Super Contributor
timestamp: June 12, 2020, 07:26:15 am
content: It is not about what device can do. They all can in theory. OSes can't handle 50 MB/s. Or at least I could not make them do it with many different USB devices, so I'm pretty sure it is OS limitation.I used libusb on all of them, so it may be libusb thing, but I don't think so.

author: palpurul
author_rank: Regular Contributor
timestamp: June 12, 2020, 07:33:27 am
content: 50 MB/s is pretty decent speed for USB HS. That's about the limit of the interface.

author: ataradov
author_rank: Super Contributor
timestamp: June 12, 2020, 07:40:20 am
content: But you can't actually get exactly 50 MB/s. So if the stream is really a fixed 50 MB/s stream, then USB is out of the question.

author: palpurul
author_rank: Regular Contributor
timestamp: June 12, 2020, 07:42:22 am
content: Quote from: ataradov on June 12, 2020, 07:40:20 amDo you mean you can't sustain 50MB/s speed for a long time?

author: magic
author_rank: Super Contributor
timestamp: June 12, 2020, 08:18:01 am
content: Not even for a short time.In my experience it was even slower, at some 45MB/s. You could use a pair of FX2 to double throughput. This will certainly work, as long as you use USB ports driven by different host controllers.Otherwise you are looking at USB3 (no idea if anything cheap exists) or buffering some fraction of the data on your board. If FX2 can do 45MB/s, you only need to buffer the remaining 5MB of each burst.You don't need to program the 8051 core on the FX2, there are ready firmwares just for that written by others. Your logic analyzer might contain an FX2.LPT or UART - forget it. The fastest USB UART receivers might go to 12Mb/s. You would need to parallel quiet a few.As for other ideas, I wonder how fast are GPIOs on those single board computers like the Pi and others.

author: palpurul
author_rank: Regular Contributor
timestamp: June 12, 2020, 08:33:20 am
content: You are correct about the UART. UART's going to be painfully slow. You gotta go with the parallel interface.FT601 is about 9 dollars, but building a 4-layer PCB + impedance control is going to dominate the cost. Cypress has USB 3 micro's and they start from about 25 $ and they come with BGA packages you also need to build a 4-layer PCB, pay for impedance control, pay for assembly (suppose you can't hand solder bgas?) or you can buy their dev board which is not going to be cheap and can be useless depending on the application.

author: ataradov
author_rank: Super Contributor
timestamp: June 12, 2020, 04:23:42 pm
content: Quote from: palpurul on June 12, 2020, 07:42:22 amI meant that USB HS device can't even peak at 50 MB/s.But if FT601 is USB 3.0, then this is not a problem. But you would need to deal with USB 3.0, so your selection of ports and hardware becomes more limited.

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 12, 2020, 04:46:10 pm
content: Of course an USB-UART solution would likely be the easiest, but don't expect very high speeds. Max speed with FTDI devices (and I don't think you'll get higher with competitors) is something like 3Mbits/s, which will yield something like 300KB/s tops.If you want better throughput, IME a FT232H or FT2232H in parallel mode would be the fastest way to get there.Real-world data: in asynchronous mode ("FT245" mode), you're going to get something like 6-8MB/s max. Simple to interface, may be enough for your needs. In synchronous mode, you're going to realistically get something like 30MB/s max, which is not too shabby. Interfacing in synchronous mode is a bit more involved though, and will usually mean having to deal with an additional clock domain in your FPGA.For even faster speed, USB SS (for instance with FTDI's FT6xx offering) will get you much higher throughput, but if you're looking for an easy solution, the former IMO will be much easier and cheaper. You can find modules/breakout boards for FT232H or FT2232H for pretty cheap, and easy to use. I couldn't find such boards at the moment for FT60x chips, and the official dev boards are more expensive (~$100), and have connectors that may not be easy to interface with depending on your own board (such as FMC.)Of course as someone suggested, you can make your own boards for this, but that's going to be some additional dev time and is going to definitely cost you more than buying dev boards or modules.Yet another option would be to embed some soft ethernet controller in your FPGA and add an external ethernet PHY+connector (you can find ready-made boards with that.) I believe some people here have experience doing this, but it's going to be more involved than the above IMO.

author: ledtester
author_rank: Super Contributor
timestamp: June 12, 2020, 04:54:11 pm
content: See if your logic analyzer is compatible with sigrok:https://sigrok.org/sigrok has command line tools which you can use to capture data directly to a file.

author: Bassman59
author_rank: Super Contributor
timestamp: June 12, 2020, 08:41:44 pm
content: Quote from: ataradov on June 12, 2020, 07:04:08 amThe FTDI parts don't allow you to customize all of the device descriptor, so it can't enumerate as a standard device class such as Audio. That greatly limits its applicability.

author: c64
author_rank: Frequent Contributor
timestamp: June 13, 2020, 03:41:21 am
content: Thanks guys, I think I will abandon my ugly idea from the first post of having a memory "buffer".So it will be all in real time like this: streem of data -> fpga -> some USB 2.0 device -> computerNow just need to choose "some USB device".I did some caclulations and data rate will be not more than 45MB/s. With some simple compression inside FPGA I can make it ~42MB/s if needed.FT232H / FT2232H look very easy to use, but they say maximum speed is 40MB/s, so I think I will go with Cypress FX2 (CY7C68013)Found quite cheap development boardhttps://banggood.com/EZ-USB-FX2LP-CY7C68013A-USB-Core-Board-Development-Board-Logic-Analyzer-p-1183409.htmlso no need to make pcb

author: ataradov
author_rank: Super Contributor
timestamp: June 13, 2020, 03:50:42 am
content: Yep, I have a couple of those boards and they are fine. And getting 45 MB/s should not be a problem at all.Again, the only mildly annoying part about it is the need to program the MCU part. And of course you will have to make some PC software. So it is quite a bit of development effort.

author: c64
author_rank: Frequent Contributor
timestamp: June 13, 2020, 04:13:16 am
content: Quote from: ataradov on June 13, 2020, 03:50:42 amYep. As I understand it's as simple as opening a stream and just reading data from it?

author: ataradov
author_rank: Super Contributor
timestamp: June 13, 2020, 04:17:56 am
content: Quote from: c64 on June 13, 2020, 04:13:16 amIt is quite easy with libusb, but not entirely trivial. There are enough examples though, and I can provide some help too.On windows you would also need to make a fake driver, since windows is stupid. I usually use this toolhttps://zadig.akeo.ie/It creates a nice complete driver package.

author: c64
author_rank: Frequent Contributor
timestamp: June 13, 2020, 04:34:19 am
content: Darn really. Even need to make drivers. FTDI is so much easier

author: ataradov
author_rank: Super Contributor
timestamp: June 13, 2020, 04:37:15 am
content: It is not really "making". You just press a couple buttons in that tool and it makes them for you. It also changes descriptor strings and all that stuff, so your device is recognized by the system and looks all professional.From the actual programming point of view, I don't know what is easier, I have not programmed anything FTDI, but from what I've seen, I prefer libusb.

author: magic
author_rank: Super Contributor
timestamp: June 13, 2020, 04:59:41 am
content: AFAIK for FTDI you can just use a similar libftdi where you open_device(), configure_device() and read_device(), roughly speaking.I wonder if the dual FT2232H would be capable of simultaneously running two streams with its two engines and achieving your throughput target in aggregate.

author: ataradov
author_rank: Super Contributor
timestamp: June 13, 2020, 05:07:32 am
content: Well, after all the enumeration and device search libusb is the same. Usually for higher performance you submit multiple transfer requests and the library calls a callback function when the request is fulfilled. In the callback after processing the data you can re-submit the same request. This way you always have some pending requests, so no wasted bandwidth.

author: c64
author_rank: Frequent Contributor
timestamp: June 13, 2020, 05:08:44 am
content: Quote from: magic on June 13, 2020, 04:59:41 amThis is how understand as well from this documenthttps://www.ftdichip.com/Support/Documents/AppNotes/AN_130_FT2232H_Used_In_FT245%20Synchronous%20FIFO%20Mode.pdfNo need to write firmware or generate drivers with some third party toolQuote from: magic on June 13, 2020, 04:59:41 amI think dual in it means "dual UART"

author: ataradov
author_rank: Super Contributor
timestamp: June 13, 2020, 05:11:52 am
content: You don't have to use that tool. You can write INI file yourself if you want to. That's just how windows is, you need a "driver", even if it is just a dummy.FTDI obviously provides their own driver, but you still have to install that. There is not a whole lot of difference.

author: c64
author_rank: Frequent Contributor
timestamp: June 13, 2020, 05:39:29 am
content: Quote from: ataradov on June 13, 2020, 05:11:52 amAh, so driver itself is already written by Sypress, you only write (or generate) inf file?

author: ataradov
author_rank: Super Contributor
timestamp: June 13, 2020, 05:42:52 am
content: Quote from: c64 on June 13, 2020, 05:39:29 amNot exactly. Cypress chip is just a bare chip, it does nothing without firmware, so Cypress can't make that driver.The actual driver is written by libusb team, or by Microsoft (if you use WinUSB driver). And all that tool does is generate INF file and put all the relevant driver files into a single folder. You mostly don't need it for one-off project. But if you were to give that device to someone else, this folder would be "the drivers" for your device.And yes, you can write your own INF file if you want. But the tool is nice and easy to use. It will automatically pick up your device VID/PID and all that stuff. It saves a lot of time trying to install and uninstall half baked hand written INF files.Also starting from Win10 you can make stuff work with WinUSB driver without manual installation. I don't remember the details, but I think windows automatically installs WinUSB driver if your device responds to a specific string descriptor with some predefined GUID-like string.

author: magic
author_rank: Super Contributor
timestamp: June 13, 2020, 07:57:42 am
content: Quote from: c64 on June 13, 2020, 05:08:44 amNo, 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

author: SuperFungus
author_rank: Contributor
timestamp: June 14, 2020, 09:23:41 am
content: If you are planning on using the FX2, I can recommend the fx2pipe software:https://www.triplespark.net/elec/periph/USB-FX2/software/fx2pipe.htmlIt'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.

author: magic
author_rank: Super Contributor
timestamp: June 14, 2020, 01:00:58 pm
content: That's awesome if it works as advertised

author: abyrvalg
author_rank: Frequent Contributor
timestamp: June 14, 2020, 09:37:12 pm
content: 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.

author: magic
author_rank: Super Contributor
timestamp: June 14, 2020, 10:41:41 pm
content: Quote from: SuperFungus on June 14, 2020, 09:23:41 amAny 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: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.

author: Kjelt
author_rank: Super Contributor
timestamp: June 14, 2020, 10:51:46 pm
content: 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.

author: NiHaoMike
author_rank: Super Contributor
timestamp: June 14, 2020, 11:16:24 pm
content: Quote from: Kjelt on June 14, 2020, 10:51:46 pm10G Ethernet is exotic and overkill. Plain 1G will easily do 100MB/s real world throughput.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: June 15, 2020, 01:39:09 am
content: 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=55These cards are popular for use with LinuxCNC.

author: SuperFungus
author_rank: Contributor
timestamp: June 15, 2020, 01:54:30 am
content: Quote from: magic on June 14, 2020, 10:41:41 pmWell 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=CNI'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, andfast. 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.

author: magic
author_rank: Super Contributor
timestamp: June 15, 2020, 06:28:42 am
content: 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 anythingCode:fx2pipe -I -ifclk=30 -8Firmware config: 0x12 0x83 0xe0 0x0c 0x12IO loop running...Downloading firmware ...Submitting max. 16 URBs to fill pipeline... 16 submitted# got bored waiting and killed it^Creap_rv=-1, errno=Interrupted system callOOPS: ProcessEvents: ec=4IO loop exitedCancelled 16 pending URBs (npending=16), reaping... done reaping (16): npending=0fx2pipe: 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.

author: ataradov
author_rank: Super Contributor
timestamp: June 15, 2020, 06:31:06 am
content: 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.

author: magic
author_rank: Super Contributor
timestamp: June 15, 2020, 06:32:59 am
content: 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.

author: SuperFungus
author_rank: Contributor
timestamp: June 15, 2020, 08:19:54 am
content: 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

author: Harvs
author_rank: Super Contributor
timestamp: June 15, 2020, 11:25:55 am
content: 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.htmlIn 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.

author: SuperFungus
author_rank: Contributor
timestamp: June 15, 2020, 03:16:14 pm
content: 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...

author: Harvs
author_rank: Super Contributor
timestamp: June 15, 2020, 09:48:24 pm
content: 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.

author: c64
author_rank: Frequent Contributor
timestamp: June 16, 2020, 09:12:08 am
content: Quote from: Harvs on June 15, 2020, 09:48:24 pmI 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?

author: c64
author_rank: Frequent Contributor
timestamp: June 16, 2020, 09:14:27 am
content: Quote from: Harvs on June 15, 2020, 11:25:55 amI actually have one of these. Never tried it though. If I can find it, I look at my pins

author: SiliconWizard
author_rank: Super Contributor
timestamp: June 16, 2020, 04:17:02 pm
content: Quote from: c64 on June 16, 2020, 09:12:08 amIf 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.)

author: jkostb
author_rank: Regular Contributor
timestamp: June 16, 2020, 07:36:59 pm
content: 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.

author: magic
author_rank: Super Contributor
timestamp: June 17, 2020, 12:55:10 pm
content: Quote from: Harvs on June 15, 2020, 11:25:55 amIt's aliveCode:fx2pipe -IFirmware config: 0x12 0xc3 0xe0 0x0d 0x12IO loop running...Downloading firmware ...Submitting max. 16 URBs to fill pipeline... 16 submittedfx2pipe: 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.QuoteThe 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

author: SuperFungus
author_rank: Contributor
timestamp: June 18, 2020, 07:57:08 am
content: Quote from: magic on June 17, 2020, 12:55:10 pmHow much slightly lower? I wonder if the ifclock is not running atexactly30MHz 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.

author: magic
author_rank: Super Contributor
timestamp: June 18, 2020, 08:29:02 am
content: 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.

author: magic
author_rank: Super Contributor
timestamp: June 18, 2020, 09:04:56 am
content: 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:$ LD_LIBRARY_PATH=../libusb-0.1.12/.libs/ ./fx2pipe/fx2pipe -ifclk=30 -8 -n=300000000 -0Firmware config: 0x12 0x83 0xe0 0x0c 0x12IO loop running...Downloading firmware ...Submitting max. 16 URBs to fill pipeline... 16 submittedfx2pipe: 293044224 bytes in 9.768s (avg 29297 kb/s, curr 29259 kb/s)URB (just reaped) status=-75 (Unknown error -75), cancelled=0HMM: URB(18311): blen=8704/8960, status=-75, error count=0, cancelled=0IO loop exitedfx2pipe: 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.

author: Harvs
author_rank: Super Contributor
timestamp: June 23, 2020, 07:50:30 am
content: 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:./fx2pipe -d=0925:3881 -8 n=300000000 -0Firmware config: 0x12 0xc3 0xe0 0x0c 0x12IO loop running...Downloading firmware ...Submitting max. 16 URBs to fill pipeline... 16 submittedfx2pipe: 297517056 bytes in 7.265s (avg 39992 kb/s, curr 39777 kb/s)URB (just reaped) status=-75 (Unknown error -75), cancelled=0HMM: URB(18311): blen=0/8960, status=-75, error count=0, cancelled=0IO loop exitedfx2pipe: 299991040 bytes in 7.325s (avg 39995 kb/s)

author: magic
author_rank: Super Contributor
timestamp: June 23, 2020, 08:27:02 am
content: Note that it has some problems with reading the final few bytes. It completely failed when I set buffer size to 15000. It seems that only some particular buffer sizes result in successful transfer, powers of two or whatever.

author: c64
author_rank: Frequent Contributor
timestamp: July 18, 2020, 05:07:29 am
content: Quote from: ataradov on June 13, 2020, 03:50:42 amCan you measure the distance between the headers on the board? I already ordered it but it still didn't arrive.

author: ataradov
author_rank: Super Contributor
timestamp: July 18, 2020, 05:16:06 am
content: It is 1" between the inner rows.

author: hamster_nz
author_rank: Super Contributor
timestamp: July 18, 2020, 08:28:58 am
content: If this is just a hack consider a Gigabit Ethernrt PHY, spewing UDP packets Add a sequence number in the header to detect lost packets.If you can use a dev board that already has this for you it should be easy

author: c64
author_rank: Frequent Contributor
timestamp: July 19, 2020, 04:57:25 am
content: I don't have only have Gigabit ethernet or USB 3, so looks like USB 2 is the only option