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.