Need help selecting a microcontroller or FPGA

[EggertEnjoyer123]

I would like to interface two 16 bit ADCs at 1 MSPS with a microcontroller for one of my projects. The microcontroller needs to send all the data to a computer at 32 megabits per second through USB or Ethernet, and a computer program will process the data. Which microcontroller should I use? Or is this task too difficult for a microcontroller to do (and I should use an FPGA instead)?

I looked at the STM32H7 series of microcontrollers, which claim to support ethernet. However, one of my friends said that there was no documentation for those and that he couldn't get the ethernet to work on his board.

The ADC I am thinking of using is the MAX11900 which has high SNR and high SFDR.

In my previous iteration of the project, I used a Red Pitaya board, which has a 14 bit ADC and a Xilinx FPGA. The board used Ethernet to transfer all the data to my computer. The ADC has a much higher sampling rate, but worse SNR and SFDR (by about 20 dB). I would like to trade off sampling rate for resolution, and I also want to use a cheaper processor (since I am limited by a school budget).

[PCB.Wiz]

I would like to interface two 16 bit ADCs at 1 MSPS with a microcontroller for one of my projects. The microcontroller needs to send all the data to a computer at 32 megabits per second through USB or Ethernet, and a computer program will process the data. Which microcontroller should I use? Or is this task too difficult for a microcontroller to do (and I should use an FPGA instead)?

You could look at the teensy HS-USB models
https://www.pjrc.com/store/teensy41.html

or, since it looks like your PC side is doing all the processing, you could investigate using HS-USB bridge parts with SPI ability.  eg 2 x CH347 or 1 x FT2232H might work ?
- you could allocate 1 usb channel to each ADC, for simplicity.

It's a bit unclear on the ADC data if they can work like i2s, with a continual stream, but it looks like a /CNVST that is CLK/16 and phased for low noise, might work ?

[dobsonr741]

What is the ADC’s interface to the MCU? An alternative to small MCUs you can use even an older Raspberry Pi, with the Circle bare metal library, no Linux kernel at all. Look at SMI example for fast parallel interfacing.

[bugnate]

As a pure data shoveling exercise I think a STM32H7 (especially the higher clocked ones) could do it paired with USB-HS but you'd need an external HS PHY. I would not recommend using ethernet for this. I'd second the suggestion of looking into the Teensy 4.1 as well. Given your rates, IMO you are in a bit of a grey area as to if you should try to do it all on the MCU vs adding more hardware. In the most bare bones sense you could do it, there is plenty of bandwidth, but one or two extra complications or app requirements and you can get squeezed pretty quickly.

What can get a little difficult is keeping everything in motion while minimizing the sample clock jitter and/or not dropping samples, unless you are used to dealing with such things.

[betocool]

I've used an STM32H7 Nucleo with a custom audio board doing 96 KHz @ 24 bit stereo to a PC, that's about 4.6 Mbps, lower than what you need, but it works using FreeRTOS and stream buffers. Not sure if it would manage 32 Mbps. A Nucleo board is 30 USD or so, and you still need the interface to your ADC. If it's SPI or something like that DMA is your friend.

Mind, LwIP and DMA on the STM32H7 are difficult but not impossible. They introduced an MPU I think (Memory Protection Unit) with the H7 and documentation was a bit lost. Also, my dev kit ran at 400 MHz, I think current H7's can do up to 500 MHz, but in the end I got it working. I ended up using my project as a cheap Audio Analyzer.

Cheers,

Alberto

[PCB.Wiz]

Another transport layer to consider, would be the FX2 based modules / parts.
There are many on aliexpress etc, that have sw support for 24MHz x 8b parallel logic analyser so very modest logic would be needed to do serial to parallel merge.

What size capture bursts do you need, and what triggers the bursts ?

[NorthGuy]

4MB/s is not much for an MCU. The transport is more restrictive. FS USB is not enough, 10BASE-T internet won't be enough neither. Any MCU with HS USB or 100BASE-T ethernet module will be big enough for ADCs. Some may even have built-in ADCs.

I remember seeing ATSAM with HS USB for about $3.

[SiliconWizard]

4MB/s is not much for an MCU. The transport is more restrictive. FS USB is not enough, 10BASE-T internet won't be enough neither. Any MCU with HS USB or 100BASE-T ethernet module will be big enough for ADCs. Some may even have built-in ADCs.

Yep. Either way, it usually means using a MCU in the "higher-end" category (such as Cortex-M7 typically), as the lower-end ones rarely embed either USB HS or 100Base-T Ethernet (at least the latter with reasonable performance.)

For USB HS, the notable exception was the Cypress FX2 - a pretty unimpressive 8051-based MCU with USB HS. Pretty useful though, as the USB controller could be used with the MCU configured as an external FIFO and thus requiring minimal CPU time (but then that would typically be interfaced to another MCU or FPGA.) I think it's still available but inot particularly cheap these days, so I wouldn't recommend it for new developments.

I remember seeing ATSAM with HS USB for about $3.

Would be interested in the reference.
I think for "cheap" MCUs with that kind of peripherals, some of the chinese offering are also candidates (Nuvoton/WCH...)

[NorthGuy]

I remember seeing ATSAM with HS USB for about $3.

Would be interested in the reference.

It was long time ago. Can't remember the exact model. Quick search reveals ATSAM3U1CB-AU.

[peter-h]

DMA will easily handle that data rate, even on the lower arm32 CPUs.

Make sure the SPI (if using SPI) can handle the clock rate; they tend to have primitive divisor options and e.g. on my 168MHz project (32F417) one SPI can do 42MHz and the others only 21 MHz.

The rest of the answer will depend on what (if anything) you want to do with the data on that CPU.

ETH does work but unless you can pick up working code tends to need to a lot of work to get running properly. There is a lot of "mystery code" between (say) LWIP and the low level ETH interface. For your speeds you want a fairly good implementation, interrupt driven tx and rx. In TCP/IP there is an ack for each packet so both up and down speeds need to be fast enough. But for your purpose you could just use UDP, or even just raw packets of some sort (never played with that, and getting the data into a PC might be tricky - low level driver?). But tx-only, as in UDP, speed will be ok because LWIP transmits everything as soon as it has something to send out, and this is fairly typical. The limit will be just the 100mbps.

[betocool]

You still need to be careful with UDP, I found from experience that at higher speeds on a uC it tends to lose packets every now and again.

There is one STM32F7 or STM32H7 with can actually do USB 2.0 High Speed (480Mbps) without an external PHY. Can't remember which model it was, but you'll find it also as a Nucleo board.

Don't ask me how to use it though, I find USB very obscure and difficult. What peter-h says is also true, TCP implementations can be tricky, but at least you're sure that on a Linux or Windows machine you know what's happening.

Cheers,

Alberto

[nctnico]

You still need to be careful with UDP, I found from experience that at higher speeds on a uC it tends to lose packets every now and again.

This is more likely due to network congestion where switches and/or the receiving end are dropping packets.

[NorthGuy]

You still need to be careful with UDP, I found from experience that at higher speeds on a uC it tends to lose packets every now and again.

This is normal for UDP. The packets that cannot be delivered (due to errors or otherwise) get dropped. Also, the order of packets may be reversed. If you want to make it loss-less, you need a protocol on top of UDP which handles re-transmissions and re-ordering. Or use TCP which does all that for you.

[dobsonr741]

If OP’s project is confined into a lab, with a local network under full control, the UDP concern will be tolerable on non-existent. Also assuming the receiving server is dedicated and have proper capacity left for this task.

If the transfer is over the internet to another continent, then even the memory will need to looked at on the MCU to allow larger buffers and TCP tuning.

[asmi]

This is normal for UDP. The packets that cannot be delivered (due to errors or otherwise) get dropped. Also, the order of packets may be reversed. If you want to make it loss-less, you need a protocol on top of UDP which handles re-transmissions and re-ordering. Or use TCP which does all that for you.

I've only ever seen UDP packets arriving out-of-order when connecting through Internet. Never seen this occur in local network environments. Packet losses do occur occasionally, even when sender and receiver are in the same subnet and are only separated by a single switch, which I would think is as ideal of network environment as it gets.

[EggertEnjoyer123]

Looks like I'll have to answer some questions.

I am part of a club at a university, and I'm trying to make an improved radar project. Last year, I made a FMCW radar similar to this person's last year at school: https://hforsten.com/6-ghz-frequency-modulated-radar.html. Most of the differences were in the microwave section (such as the fact that I used 2.4 instead of 6 GHz, among other things). The only things different from a computer processing point of view was that I used 2 ADCs (I used an IQ mixer to try to get a lower noise level), and I used a Red Pitaya board instead of using a MCU. The Red Pitaya board had two 14 bit ADCs and used a Xilinx FPGA, and it was rather convenient to use as a development board. I stole code off Github which would write ADC samples to the DRAM onboard, modified the code to write in a circular fashion instead of writing just once, and then I modified the C code running on the SoC side to stream data over Ethernet to a computer. (I basically implemented a crude circular buffer). The Ethernet went straight from the FPGA to my computer (there was no router or anything in between), and everything was done using TCP (not UDP). The 125 MSPS data from both ADCs was downsampled to 1 MSPS, and my data rate ended up being 32 Mb/s  (16 bits * 1 MSPS * 2). The ZYNQ 7010 supported gigabit ethernet so there was no issues with data rate.

This year I am doing a similar project, but it will be more "official". Basically, the project I did last year was a single person project, and this year I am expanding it so that any interested student (with the right qualifications) can join. I thought it would be a good idea to make a better board to squeeze more performance out of everything. Originally, I was thinking about having people make improved "copies" of my project which they could take home (which would have also meant that we needed to get cheaper parts), but there's also the possibility of going big and making a MIMO based one (which would likely need 4 ADCs or something).

The ADCs need to be read constantly (at 1 Msps). Any jitter will impact performance. After thinking about it for a while, I think I should probably just use an FPGA.

Anyways if you're interested I will post something in the RF section of this forum once I get back to school in October (since all my stuff is there).

[PCB.Wiz]

This year I am doing a similar project, but it will be more "official". Basically, the project I did last year was a single person project, and this year I am expanding it so that any interested student (with the right qualifications) can join. I thought it would be a good idea to make a better board to squeeze more performance out of everything. Originally, I was thinking about having people make improved "copies" of my project which they could take home (which would have also meant that we needed to get cheaper parts), ....

The ADCs need to be read constantly (at 1 Msps). Any jitter will impact performance. After thinking about it for a while, I think I should probably just use an FPGA.

Making something people can take home is a great idea,  and you are right that price then matters a lot.

You could look at modules like these ?
https://www.aliexpress.com/item/1005005789609676.html
which have HS_USB to parallel, with a CLKOUT option, low cost and ready to go.

You then select a Price/performance ADC that can clock-stream into that and see what sample speed it can sustain, and do a simple adaptor board that plugs into the 16b capture board.
 

[EggertEnjoyer123]

Well, it's been almost a year now, but I actually designed and programmed my board. (I don't know if I've ever mentioned it, but it's for my homemade FMCW radar project.)

I ended up choosing the ADAR7251 ADC for my project, as it has the ADC and a LNA/PGA along with filters. It's also sigma delta so aliasing isn't really an issue. The ADC has 4 channels and runs at 1.8 MSPS (It's also 16 bits, so that's 115.2 Mbps). I only need two channels out of 4, but I decided to make the board send all the data over anyways just to make it future proof. The board also has to drive a DAC, which will drive the VCO for the transmitter.

The data comes out of the ADC at 14.4 MHz (through a parallel 8 bit interface). It is processed (by eliminating all samples that occur outside of the sweep) and synchronized to the 60 MHz clock from the FT232H by a cheapo $5 FPGA (Lattice ICE5LP1K-SG48). My code fits in under 800 LUTs (it currently doesn't pass timing in worst case so I still need to fix it, but it works in real life). During the dead time in between sweeps, the FPGA checks the FT232H for any data that is in the receive buffer, which may contain commands from the PC (such as adjusting gain or sweep parameters). Because the ADC needs to be initialized, the SPI driver for the ADC runs on the 60 MHz clock from the USB (since that is always there). The SPI driver for the DAC runs off a PLL based on the 14.4 MHz clock from the ADC chip (the maximum SPI frequency is 20 MHz for the DAC, and 14.4 * 4/3 is close enough to 20). This was done to ensure that the sweep is synchronized to the ADC, so sampling happens at the exact same parts of each sweep.

On the software side, the Linux libftdi library was used. The ftdi_readstream function (with some modifications) was used to read the data streaming from the board. 115.2 Mbps is slow enough that everything can be read with no errors or skipped packets. My code then collects the samples and does a 2D FFT to calculate the range and velocity of targets. Currently, I'm feeding in a pure sine wave, so there should only be one dot on the screen.

(For those of you who are into analog circuits, I used a differential amplifier using MMBTH10 transistors to convert the single ended signal to differential. There's a high pass filter to do -20dB/decade equalization, and further equalization can be done inside the chip using filters to get to -40dB/dec. The DAC output is around 800kHz, and is filtered using a 50kHz low pass filter to eliminate all the steps).

Here's some pictures of my project. Source code and design files will be published once I iron all of the bugs out (or give up). I also need to add VCO nonlinearity correction into my FPGA firmware.

[hans]

Nice project!

Doing the RF stuff is one thing, but then also designing all the embedded electronics and DSP code is another.

Reading the sweep requirements, I think going for a FPGA is a solid choice. Getting that precise timing on MCUs isn't impossible but it can be a bit fiddly to get most/all of it configured in hardware, without influence from software processing time that can vary a lot.

Pity I didn't spot this topic earlier, but anyhow: a long time ago (12+ years), I made my own power oscilloscope for low current devices. It samples a 16-bit ADC at 500ksps (or thereabouts, ADC runs free clock at 550ksps or so). The MCU transfers the samples with SPI & DMA & timer trigger to memory. Those are packetized and sent to a PC via UDP over 100M ethernet. This was all done on a STM32F407 chip. So it certainly is very possible

Back then I had too much time/energy on my hands (read: I was learning), so I wrote the RTOS kernel and networking stack myself. That allowed me to use a zero-copy architecture for the buffered data streams: in other words, the DMA engine was sampling directly into the buffer of an UDP frame. The ethernet driver from ST was not too difficult, but I limited myself to UDP as TCP seemed a complete mess to implement.

I did a CPU time measurement and it was in the order of 10% when shoving 500ksps around with 168MHz CPU clock. Extrapolate that to 2MSPS and it would still leave well over 60% of CPU time for house keeping.
The one problem with UDP is the potential for data loss on network congestion. I had implemented some protocol that could request retransmission of lost old frames (those were dumped in external SRAM for a long buffer time). The request mechanism was done out of order and thus it was far easier to implement on the transmit side (the receive side had to do the heavy lifting). I did occasionally see some drops on my home network, so I'm glad I implemented it.

But honestly I would have preferred to use USB instead. In my experience using that data logger always has been a fuss for desktop use. The idea was I could also use it in automated setups controlled from servers, but that project never happened.

[Perkele]

Back then I had too much time/energy on my hands (read: I was learning), so I wrote the RTOS kernel and networking stack myself. That allowed me to use a zero-copy architecture for the buffered data streams: in other words, the DMA engine was sampling directly into the buffer of an UDP frame. The ethernet driver from ST was not too difficult, but I limited myself to UDP as TCP seemed a complete mess to implement.

I did a CPU time measurement and it was in the order of 10% when shoving 500ksps around with 168MHz CPU clock. Extrapolate that to 2MSPS and it would still leave well over 60% of CPU time for house keeping.
The one problem with UDP is the potential for data loss on network congestion. I had implemented some protocol that could request retransmission of lost old frames (those were dumped in external SRAM for a long buffer time). The request mechanism was done out of order and thus it was far easier to implement on the transmit side (the receive side had to do the heavy lifting). I did occasionally see some drops on my home network, so I'm glad I implemented it.

But honestly I would have preferred to use USB instead. In my experience using that data logger always has been a fuss for desktop use. The idea was I could also use it in automated setups controlled from servers, but that project never happened.

Another alternative to USB on STM32 chips is raw Ethernet transfer.
To avoid issues with consumer-grade network equipment randomly dropping packets, connect the board directly to computer with a network cable.
You'll need a crossover cable if the board's PHY does not support polarity sensing.
Biggest downside is the need to write your own software that works with raw ETH sockets.

[nctnico]

I don't see why using raw ethernet packets is any better compared to using UDP. Implementing raw ethernet packets is the same amount of work and UDP can be handled using any software library which can deal with sending / receiving UDP packets. So in the end UDP is easier at the computer side.

[radiolistener]

1 MS/s can be handled with fast MCU or raspberry pi, but if you're planning to increase sample rate and add CIC+FIR filter for decimation after frequency shift, there is a sense to implement it on FPGA.

I'm using Cyclone 4 and Cyclone 10 LP to handle 16 bit ADC running at 100 MHz.

[Perkele]

I don't see why using raw ethernet packets is any better compared to using UDP. Implementing raw ethernet packets is the same amount of work and UDP can be handled using any software library which can deal with sending / receiving UDP packets. So in the end UDP is easier at the computer side.

Quick & dirty testing or prototyping. There's no need to implement a full networking stack on MCU side.
On sub-100MHz STM32 MCUs I could not get their USB stack implementation to push data reliably at speeds over 10Mbit/s with USB FS.
SPI chip that I used was streaming data at around 14-16Mbit/s.
On receiving side I also did not need any kind of networking stack, but in most of cases I did connect it to a PC.

These days I'm kicking around some Cypress FX3 boards, so I'm not using this approach any more.

[EggertEnjoyer123]

Here's my code and CAD files, if anyone wants to take a look:
https://github.com/EnPassant123/FMCW_radar_2/tree/main

The code is still very buggy, I think I broke some stuff like being able to configuring the ADC over USB. It also does not pass timing (mainly because I can't figure out how to do false paths in the IceCube2 software). I have a few false paths where a register is updated too slowly (for example, calculating the next value for the DAC). However, the register value isn't used until 20 clock cycles later, so it should actually be fine.

[Postal2]

The ftdi_readstream function (with some modifications) was used to read the data streaming from the board.

Is it a blocking call with 100% cpu-load, as ftdi like to do? Is it "libftdi library" communicate with driver directly (I need) or use dll from ftdi as superstructure?

Adapted from fastftdi.c - A minimal FTDI FT232H interface for which supports bit-bang mode, but focuses on very high-performance support for synchronous FIFO mode

How?? I totally failed to use synchronous FIFO mode from ftdi! It's interrupted stream when reload command! I succeded with asynchronous for non-interrupted receive.
...
EggertEnjoyer123, in your file -
https://github.com/EnPassant123/FMCW_radar_2/blob/main/c/ftdi_stream_modified.c
- written clear:

Use asynchronous transfers in libusb-1.0 for high-performance streaming of data from a device interface back to the PC.

Why do you use synchronous mode later in text?

These days I'm kicking around some Cypress FX3 boards,

FX3 is too much money, I recommend FX2LP, very good, runs on Windows 98 perfectly at HS.