Need help selecting a microcontroller or FPGA - Page 1
Forum section: electronics / general

author: EggertEnjoyer123
author_rank: Frequent Contributor
timestamp: September 01, 2023, 04:49:39 am
content: 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).

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 01, 2023, 05:53:44 am
content: Quote from: EggertEnjoyer123 on September 01, 2023, 04:49:39 amYou could look at the teensy HS-USB modelshttps://www.pjrc.com/store/teensy41.htmlor, 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 ?

author: dobsonr741
author_rank: Frequent Contributor
timestamp: September 01, 2023, 11:25:58 pm
content: 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.

author: bugnate
author_rank: Regular Contributor
timestamp: September 02, 2023, 02:16:21 am
content: 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.

author: betocool
author_rank: Regular Contributor
timestamp: September 02, 2023, 01:16:17 pm
content: 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

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 02, 2023, 07:59:32 pm
content: 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 ?

author: NorthGuy
author_rank: Super Contributor
timestamp: September 02, 2023, 10:50:03 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 03, 2023, 03:17:05 am
content: Quote from: NorthGuy on September 02, 2023, 10:50:03 pmYep. 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.Quote from: NorthGuy on September 02, 2023, 10:50:03 pmWould 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...)

author: NorthGuy
author_rank: Super Contributor
timestamp: September 03, 2023, 04:32:10 am
content: Quote from: SiliconWizard on September 03, 2023, 03:17:05 amIt was long time ago. Can't remember the exact model. Quick search reveals ATSAM3U1CB-AU.

author: peter-h
author_rank: Super Contributor
timestamp: September 03, 2023, 07:37:32 am
content: 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.

author: betocool
author_rank: Regular Contributor
timestamp: September 03, 2023, 09:23:40 am
content: 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

author: nctnico
author_rank: Super Contributor
timestamp: September 03, 2023, 09:29:36 am
content: Quote from: betocool on September 03, 2023, 09:23:40 amThis is more likely due to network congestion where switches and/or the receiving end are dropping packets.

author: NorthGuy
author_rank: Super Contributor
timestamp: September 03, 2023, 01:30:38 pm
content: Quote from: betocool on September 03, 2023, 09:23:40 amThis 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.

author: dobsonr741
author_rank: Frequent Contributor
timestamp: September 03, 2023, 02:13:54 pm
content: 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.

author: asmi
author_rank: Super Contributor
timestamp: September 04, 2023, 04:48:03 am
content: Quote from: NorthGuy on September 03, 2023, 01:30:38 pmI'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.

author: EggertEnjoyer123
author_rank: Frequent Contributor
timestamp: September 04, 2023, 07:58:23 am
content: 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).

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 05, 2023, 04:42:05 am
content: Quote from: EggertEnjoyer123 on September 04, 2023, 07:58:23 amMaking 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.htmlwhich 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.

author: EggertEnjoyer123
author_rank: Frequent Contributor
timestamp: May 25, 2024, 07:56:06 am
content: 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.

author: hans
author_rank: Super Contributor
timestamp: May 25, 2024, 08:24:42 am
content: 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 possibleBack 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.

author: Perkele
author_rank: Regular Contributor
timestamp: May 25, 2024, 05:58:13 pm
content: Quote from: hans on May 25, 2024, 08:24:42 amAnother 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 25, 2024, 07:47:09 pm
content: 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.

author: radiolistener
author_rank: Super Contributor
timestamp: May 25, 2024, 09:06:06 pm
content: 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.

author: Perkele
author_rank: Regular Contributor
timestamp: May 26, 2024, 01:46:14 pm
content: Quote from: nctnico on May 25, 2024, 07:47:09 pmQuick & 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.

author: EggertEnjoyer123
author_rank: Frequent Contributor
timestamp: June 05, 2024, 09:47:22 pm
content: Here's my code and CAD files, if anyone wants to take a look:https://github.com/EnPassant123/FMCW_radar_2/tree/mainThe 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.

author: Postal2
author_rank: Frequent Contributor
timestamp: June 06, 2024, 01:20:07 am
content: Quote from: EggertEnjoyer123 on May 25, 2024, 07:56:06 amIs 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?QuoteHow?? 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:QuoteWhy do you use synchronous mode later in text?Quote from: Perkele on May 26, 2024, 01:46:14 pmFX3 is too much money, I recommend FX2LP, very good, runs on Windows 98 perfectly at HS.

author: EggertEnjoyer123
author_rank: Frequent Contributor
timestamp: June 06, 2024, 06:46:54 am
content: Quote from: Postal2 on June 06, 2024, 01:20:07 amI am using the open source libftdi1 library:https://www.intra2net.com/en/developer/libftdi/index.phpI'm fairly sure that the call blocks, which is why I'm running it in another thread in my C code.Quote from: Postal2 on June 06, 2024, 01:20:07 amThat part was copied from the libftdi1 source code. If you couldn't get synchronous mode to work, here's some things to check:1. Make sure SIWU is high. If not, there will be no data sent over.2. There is a bug in the libftdi1 source code. This line has been changed:Code:struct timeval timeout = { (ftdi->usb_read_timeout / 1000), (ftdi->usb_read_timeout % 1000) * 1000};The original code has:Code:struct timeval timeout = { 0, ftdi->usb_read_timeout * 1000};With my FTDI setup, the timeout was 5000, and because the timeval struct can't have values >=1000000 for the microseconds element, the original code wouldn't work. My new code correctly fills in the timeval values. The asynchronous transfers thing is just for libusb (which is a library on the computer side), and it only affects how the computer processes the samples. The FTDI chip is still reading/writing data on a 60MHz clock.

author: Postal2
author_rank: Frequent Contributor
timestamp: June 06, 2024, 05:16:42 pm
content: Quote from: EggertEnjoyer123 on June 06, 2024, 06:46:54 amI could. I tried to capture IR remote with synchronous mode and it's absolutely impossible because gaps. You cannot use this mode for continuous streaming from real-time devices like adc. You will see input data correctly, but cannot be decoded because broken timeline.Quote- this mode cannot be used.

author: EggertEnjoyer123
author_rank: Frequent Contributor
timestamp: June 06, 2024, 05:39:09 pm
content: Quote from: Postal2 on June 06, 2024, 05:16:42 pmYou can use it if you use a FPGA to synchronize the ADC output with the 60MHz clock, like I did. Otherwise, if you're just trying to run it constantly at 60MHz it wouldn't work because of dropped packets.The reason why packets are being dropped is because you are operating too close to the 480 Mbps limit (realistically maybe 300 Mbps can be done at best). If you use a FPGA you can get away with a much lower data rate which means no dropped packets.Basically synchronous mode works, but if you try to hold the WR line low to force it to constantly write, it would drop packets because you're running at the theoretical limit for USB ( 60MHz * 8 ). For your application the FT232 is probably not needed, you can just use a microcontroller to time the pulses from the IR sensor, and then report the value back through UART.

author: Postal2
author_rank: Frequent Contributor
timestamp: June 06, 2024, 06:29:24 pm
content: Quote from: EggertEnjoyer123 on June 06, 2024, 05:39:09 pmOh, sorry, I missed the FPGA. FPGA is good when enough buffer in it, it will compensate glitches from ftdi. FX2LP could be more reliable for your purposes, it was bad advice to use ftdi.Quote from: EggertEnjoyer123 on June 06, 2024, 05:39:09 pmMy application is small chunk of other application, where you can work with eMMC via FT232H (even FT232RL) including. You won't be able to find similar therefore my application widely used.

author: EggertEnjoyer123
author_rank: Frequent Contributor
timestamp: June 06, 2024, 11:33:09 pm
content: It would be difficult to just blindly sample at a fixed clock rate using the FX2LP. Because the ADC clock is not synchronous to the FX2LP's clock, a situation where the FX2LP samples at an edge (which causes metastability) could occur. The FPGA is able to fix this issue by sampling the ADC clock at 60 MHz, and then detecting edges, allowing it to figure out when the ADC data being output is valid. The FX2LP, which just blindly samples at 24 MHz, can't do that.Here's an example of what could happen if you just blindly sample the ADC output at 24 MHz. The orange arrows are when the FX2LP samples. The black line is the ADC clock and the green represents the data. When the FX2LP samples on the falling edge of the ADC clock, the data may not have settled yet. In my example this is shown by the FX2LP reading 0x04 instead of 0x00 on the transition (since perhaps the 3rd bit is slower than the other bits). This would lead to bad samples showing up in the data. There is no easy way to detect such a situation too, since reading the clock wouldn't work. At the edge, the value the FX2LP reads is undefined, and it could be either 0 or 1.

author: NorthGuy
author_rank: Super Contributor
timestamp: June 07, 2024, 12:14:23 am
content: Quote from: EggertEnjoyer123 on June 06, 2024, 11:33:09 pmTypically you would bring ADC clock inside FPGA and use it for sampling ADC data. Then you would cross to FTDI clock domain with FIFO or otherwise.

author: EggertEnjoyer123
author_rank: Frequent Contributor
timestamp: June 07, 2024, 12:22:38 am
content: Quote from: NorthGuy on June 07, 2024, 12:14:23 amFIFO is too complicated and consumes too many LUTs probably (I only have 1100). A simple double flop works since 14.4 MHz is slow enough compared to 60 MHz. (The data_valid signal is basically constantly high, so I don't really care about double flopping it)Code:...always @(posedge clkadc) begindata_valid = data_ready;data_buf = datain;endalways @(negedge clkusb) beginclkadc_2 <= clkadc;clkadc_3 <= clkadc_2;if (state == 0 & clkadc_2 == 1 & clkadc_3 == 0 & data_valid) begin...dataout = data_buf;...end...end

author: NorthGuy
author_rank: Super Contributor
timestamp: June 07, 2024, 01:38:12 am
content: Quote from: EggertEnjoyer123 on June 07, 2024, 12:22:38 amIt's a good idea to put data through flip-flops too. Otherwise, the data you're sampling is somewhat later than the clock edge you have detected. Probably not a big deal at these speeds, but still.

author: Postal2
author_rank: Frequent Contributor
timestamp: June 07, 2024, 02:46:07 am
content: Quote from: EggertEnjoyer123 on June 06, 2024, 11:33:09 pmSee datasheet. Is my understanding correct?...Need to reduce sample rate, need to be practical. When using usb HS, need to be oriented to 8MB/sec. It's irrelevant, you can use 100 fpga-chips, but when send raw data you cannot be faster than FX2LP.

author: EggertEnjoyer123
author_rank: Frequent Contributor
timestamp: June 07, 2024, 09:12:23 am
content: Quote from: Postal2 on June 07, 2024, 02:46:07 amThat mode doesn't support 4 channels at 1.2 or 1.8 MSPS. (See page 42).In any case even if I was able to get it to work with the FX2LP, it would be impossible to also run a DAC at the same time with that chip.

author: Postal2
author_rank: Frequent Contributor
timestamp: June 07, 2024, 09:45:24 am
content: Quote from: EggertEnjoyer123 on June 07, 2024, 09:12:23 amI saw. Parallel mode below, synchronisation can be resolved same way.Quote from: EggertEnjoyer123 on June 07, 2024, 09:12:23 amI didn't go deep into the project, I don't understand what job the DAC do. May be simple cheap programmable oscillator can do the job. Control data can be given from FX2LP in that case.