[fps-hero]

I think you miss understood the challenge. They are using a 60Msps ADC with a parallel port interface. The challenge is capturing the 600Mbit/s of data and having enough CPU and memory bandwidth to do anything useful with it.

If your microcontroller has a parallel port interface, you would use the clock setup you described. This works, I've done it before, but there was very little CPU left to do anything useful with the data.

It's neat that they used the PIO, its demonstrating how that peripheral fills a niche where you things that might have been impossible without an FPGA, suddenly become doable on a microcontroller.

[05]

Well, parallel port adc capture has nothing to do with PIO either - on STM32 you would just set up DMA on a GPIO port, then capture 16bit data. The real question is what RP2040 is going to do with 120MB/s of data.. and the answer is, it can't process it or send it over (12Mbps aka 1.5MB/s) USB. So, would only work in low duty cycle pulse mode, no streaming.

[zipy124]

It is designed for short captures. You can see the practical applications at: https://un0rick.cc/use_cases .

I can assure you these use cases are hard to achieve with a standard STM32 as someone whos almost finished with their PhD in mid-air ultrasonics.

[kelu124]

Hi, author here. I must say I'm not 100% confident in everything the STM32s do - and the rp2040/rp2350 is an easy one. One of my pieces of work is : continuous acquisition, acquisitions, processing, and writing on a fast storage, which allows for continuous 10MB/s+. All of this can be managed through the 2 cores, and the PIOs.

In short, PIOs are really a game changer, I have dumped a FPGA from the previous iteration to go rp2040.

BUT... solutions like some of PIC32 and their integrated 40Msps ADC are really nice and worth exploring (if I had the time). The positive thing about the pico is that it's so common and tools are so common that it's really a pleasure developping on this device =)