DIY open-source ultrasound hardware on the rp2040/rp2350
1–10 of 13 posts
Re: DIY open-source ultrasound hardware on the rp2040/rp2350
#2So... paired with https://coe.gatech.edu/news/2026/04/batteries-not-included-o...
and one has a complete hardware solution?
Re: DIY open-source ultrasound hardware on the rp2040/rp2350
#3So... paired with https://coe.gatech.edu/news/2026/04/batteries-not-included-o... and one has a complete hardware solution?
For what?
Re: DIY open-source ultrasound hardware on the rp2040/rp2350
#4As someone who has never had an opportunity to play with it, I’m fascinated by what people are doing with PIO. In many cases it seems to be a ‘good enough’ FPGA on absurdly cheap hardware.
Re: DIY open-source ultrasound hardware on the rp2040/rp2350
#5Honestly what they're describing can be done on any MCU without PIO - set up clock division/PLL to provide ADC clock, use that same clock for timer source, set up a timer channel to trigger the pulse, set up a timer channel to trigger ADC DMA capture start, start the timer.
Congrats, now you have capture synchronized to pulse start "providing the sub-microsecond timing needed for ultrasound acquisition".
Re: DIY open-source ultrasound hardware on the rp2040/rp2350
#6Honestly what they're describing can be done on any MCU without PIO - set up clock division/PLL to provide ADC clock, use that same clock for timer source, set up a timer channel to trigger the pulse, set up a timer channel to trigger ADC DMA capture start, start the timer. Congrats, now you have capture synchronized to pulse start "providing the sub-microsecond timing needed for ultrasound acquisition".
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.
Re: DIY open-source ultrasound hardware on the rp2040/rp2350
#7Re: DIY open-source ultrasound hardware on the rp2040/rp2350
#8What are the practical applications of this? The things that come to mind when I hear "ultrasound" are medical devices and wall scanners.
That said, it's a cool project, even if it doesn't have a practical use.
Re: DIY open-source ultrasound hardware on the rp2040/rp2350
#9Honestly what they're describing can be done on any MCU without PIO - set up clock division/PLL to provide ADC clock, use that same clock for timer source, set up a timer channel to trigger the pulse, set up a timer channel to trigger ADC DMA capture start, start the timer. Congrats, now you have capture synchronized to pulse start "providing the sub-microsecond timing needed for ultrasound acquisition".
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…
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.
Re: DIY open-source ultrasound hardware on the rp2040/rp2350
#10So... paired with https://coe.gatech.edu/news/2026/04/batteries-not-included-o... and one has a complete hardware solution?
You could just use a standard microphone for that, no need to have something so over-engineered as in the OP.