I have a project where I have to sample a 4 bit bus every 100ns continuously for a data logging application (I need very low sampling jitter as well). I have a uC that can go up to 300MHz so speed isn't an issue, but rather getting data off the uC to a PC is my current challenge.

40Mbit/s pretty much rules out UART or similar, leaving USB and Ethernet as possibilities. Are there any other more quick 'n dirty ways of achieving this speed? Or if not, what is the best way to get started as I have never used Ethernet/USB on a uC design before.

  • \$\begingroup\$ Working with USB device is quite easy, can you tell us which uC and which ide you're using? \$\endgroup\$ – Mudassir Hussain Nov 30 '17 at 17:50
  • \$\begingroup\$ A bigger issue may be the operating system on the PC itself. Unless you have significant buffering on your sampling device, you will run into delays in the PC that will cause you to lose data. For something like this I'd suggest you look into some form if direct memory access interface to the PC. Also "continuously" at 10mega samples per second is A LOT of memory, or disk space. \$\endgroup\$ – Trevor_G Nov 30 '17 at 17:58
  • 1
    \$\begingroup\$ @Trevor: The Ethernet and USB interfaces built into virtually every PC available today are already tuned for performance. There should be no need to worry about the host-side implementation at that level of detail. \$\endgroup\$ – Dave Tweed Nov 30 '17 at 18:01
  • 2
    \$\begingroup\$ depending on the data though it may be better just to get a national instruments or other card that plugs in to pci or pcie to do this logging, it should have no problem with bandwidth, nor storage. just need to find the right card/product for the signal you want to sample. \$\endgroup\$ – old_timer Nov 30 '17 at 18:39
  • 1
    \$\begingroup\$ @MudassirHussain most "easy to use" microcontrollers with USB will only do 12Mbit/sec. There are very few which will do USB HS, and most of those will require an external PHY (e.g. STM32, NXP, etc.). The FX2LP is dirty cheap and can easily do what you want, but requires you to work with its 8051. The FX3 can do 2.5Gbps and uses an ARM7. \$\endgroup\$ – akohlsmith Nov 30 '17 at 20:00

A bigger issue may be the operating system on the PC itself. Unless you have significant buffering on your sampling device, you will run into delays in the PC that will cause you to lose data.

I got full 480Mbps USB bulk throughput between a USB2 micro and a linux PC application written in Python. Not even in C! It uses libusb, which I recommend. libusb allows you to initiate bulk transfers directly, without having to write a driver. It is quite simple to use.

You must use scatter-gather DMA. Good thing is, that should be the default. The idea is that you pass a list of empty buffers to libusb. These are placed into a linked list which is managed by the usb hardware itself. Every time your device sends a packet, the USB chip inside the PC grabs a free buffer from the list and fills it up. Then it periodically fires an interrupt so your app can gather the filled buffers. This process is entirely managed by hardware, it will work even if the CPU is busy, swapping, etc, as long as you give it enough free buffers. The PC's cpu does not bother to process each packet. In fact you can pass large buffers (like 64kB) and the USB hardware will pile up packets into that and ping your app when the buffer is ready for consumption.

With enough buffers, you should not get dropped packets. I didn't, and the thing ran for hours while compiling linux kernels and anything else I could throw at it. Smart DMA chipsets are remarkably smart!

Since the micro runs at 300 MHz I'm assuming it's a beast and it won't have like 1kByte of RAM. You will need to buffer a few frames' worth, so a couple tens kilobytes will be OK. Make sure you setup the embedded USB core with proper DMA, fifo, or scatter gather, whatever your chip uses, but it is important to use the most efficient mode.

If you choose Ethernet, this is basically the same. PC NICs have scatter-gather DMA so just set the socket buffer to "yuuuuge" and let the hardware do its job. You can use UDP, no need for TCP.

However Ethernet will require construction of UDP packets in your firmware which does take a little bit of time. USB2 hardware will slice data into packets for you. But Ethernet is isolated, and allows much longer cable lengths, which might come in handy.

Also Ethernet will not crash a PC. Messing with USB when your experimental USB device is buggy can do funky stuff to your PC. Your OS' drivers have only been tested on USB devices that work. So when your micro hangs between some phases of the USB transaction, notably enumeration, or sends bogus data causing the driver stack to suddenly feel an urgent need to allocate -1 bytes of memory, you can expect the PC to go "WUT?" and have to press the Windows key (ie, reset button). I use a junk laptop with no data on it.

If you worry about UDP losing packets... I left it running for a 24 hours, with two dollar store 10 meter cables and a dollar store extender in the middle, no lost packets at 100Mbps full duplex.

Hm well that was a bit of an infodump, but it should work fine. I'd be more worried about how your micro is going to sync the acquisition, don't expect to fire an interrupt every 100ns... you will need hardware and DMA for this. If you use 4 bits, you could hack the quad SPI port maybe? Or if it map a DMA port to pins...

Another solution would be a Cypress FX2LP EZ-USB micro. It has a hardware FIFO, so if you give it a clock, on every cycle it will grab 8 bits from its data pins and send this to the PC via USB2 bulk transfer. All in hardware. You need to write about a page of C code for firmware, to say hello to the PC, enumerate, and connect the hardware FIFO to the USB endpoint. You get 8 bits instead of 4 though... hey thats 4 free bits!

Anyway. Realistically, one of these should do the job.

  • \$\begingroup\$ +1 Nice answer, It is good to make the user aware of what is involved with the whole picture before he spends considerable time and money developing the hardware and software at his end. Which was the point I was trying to make before I got deleted... sigh \$\endgroup\$ – Trevor_G Nov 30 '17 at 20:02
  • 1
    \$\begingroup\$ Yes I agree. What saves the PC is the scatter gather DMA engine on the USB chipset. Even if the CPU is stuck doing something else it will keep transferring. FX2LP is likely to be the simplest. It took me like a day to get it to work with libusb, and I had never done any USB before... it's a simple chip. \$\endgroup\$ – peufeu Nov 30 '17 at 20:05
  • \$\begingroup\$ I was doing a bit more digging on the TMS320 series uC's and apparently their USB's cant handle the speeds i need. Seeing how id have to write this from scratch and because time is of the essence (grant proposal coming up), is the cyperess chip a good way to go? also, i have used the salee logic analyzer, but it doenst stream constantly, rather, it buffers, dumps and goes again and this is somewhere i cant afford to lose packets. \$\endgroup\$ – Jason Yang Nov 30 '17 at 21:30
  • 1
    \$\begingroup\$ I am sorry, but you can't get "full 480Mbps" throughput on USB 2.0 no matter what. USB has frame overhead (SOF-EOP1-EOP2), protocol overhead (IN-ACK, bit-stuffing don't let system to schedule more than 11 bulk buffers per microframe, conservatively 10), and there is a system overhead for managing TRBs. Plus overhead of file system. Best one can do is about 45MBps, or 360Mbps. \$\endgroup\$ – Ale..chenski Nov 30 '17 at 23:16
  • 1
    \$\begingroup\$ @AliChen - of course, like "100Mbps" ethernet also includes overhead and results in about 10MB/s give or take, USB 480Mbps includes overhead... as for net bandwidth around 45 MB/s sounds right. Plenty for OP's needs. I was emphasizing that even a crap proof of concept PC app written in python has no trouble with the bandwidth, since that seemed to be a major doubt for OP. Modern hardware is amazing. As for file system overhead there would be none, since this is not a mass storage device... \$\endgroup\$ – peufeu Dec 1 '17 at 0:03

Your effective sustained data rate is 5 Mbytes/s. This rate should be pretty easy to handle by any USB 2.0 FIFO chip, Cypress or FTDI. USB 2.0 can sustain 35-40 Mbytes/s one way. I believe both companies offer examples of data acquisition systems based on their architectures, with free drivers for PC side. Most so-called "PC scopes" and "PC logic analyzers" are built around these USB-FIFO chips.

All you need to ensure at least a simple ping-pong buffering on your side, pack two 4bit nibble into a byte, that's it.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.