STM32 based oscilloscope, probe circuit

[inshade]

Hi!

I'm making a microcontroller based oscilloscope (216MHz ARM Cortex-M7 on board) for university project. I'd like to have input resistance ~1Mohm and able to sample signals up to 20MHz (tell me if I'm wrong - I should sample at the frequency at least 40MHz). I have 12-bit ADC, at the Vdd of 3.6V and Vdd - Vref < 1.2 (that's all I could find: https://scr.hu/Apyn27 ).

Based on what I've found I'm trying to make some circuit for oscilloscope probe. I've chosen OPA2604AP since it can handle signal frequencies up to 20MHz. Here's what I've done so far:
https://scr.hu/v1A3jR

Am I going in a proper way? I mean opamps are slow, a bit expensive, but I can manage to get a bit simpler circuit. It's my first project that should handle such high frequencies and I don't know how to deal with it  So will this even work? Or is there a better solution?

[bktemp]

It will not work: The OPA2604 needs at least 9V supply voltage and is designed for audio applications. Unless you have a supply voltage +/-9V or higher available, better use a rail to rail opamp.
The internal ADC can not do 40MS/s, you need an external one. I have not tried it, but it should be possible to read the ADC data at up to 54MS/s into memory using the DCMI.
At 20MHz a simple resistive voltage divider does not work as expected, because together with the opamp input capacitance it will form a low pass filter. This needs to be compensated.

[inshade]

I forgot to mention that opamp will use 12V DC source. I thought about using two ADCs, one delayed half a period to measure at twice the limit, so close to 60 MHz. Could it work? Still you're right about resistors and opamp input. I'll try to figure something about it.

[bktemp]

Even at 12V the OPA2604 is a bad choise: It needs around 3V headroom at its inputs and output, so you need at least -3V and +6.3V if you want 0-3.3V at the output.
Most STM32F7 have 3 2.4MS/s ADCs. If you interleave them you get 7.2MS/s, so you need an external one. Interleaving ADCs at 60MS/s does not make much sense, because you can easily get ADCs with more than 100MS/s.

[inshade]

ADS830 and OPA350PA can do?

And any hints how to compensate input low-pass filter? What I'm trying to do is to extend my measure range, so voltage divider is the simplest thing that came to my mind.

[bktemp]

ADS830 should work. It is quite old, but a nice ADC.
Look at how a typical DSO front end is constructed:
https://www.eevblog.com/forum/blog/eevblog-675-how-to-reverse-engineer-a-rigol-ds1054z/msg534470/#msg534470
There are a few other DSO front end schematics somewhere on this forum.

Finding a suitable opamp can be difficult if you need both accurate DC + AC levels up to many MHz. For 3.3Vpp at 20MHz you need at least 200V/us slew rate.

[free_electron]

university project. , bunch of nutballspecs, blaah about how opamps are slow and expensive , fer about 'high frequencies' ,  and I don't know how to deal with it  So will this even work? Or is there a better solution?

yup. definitely a better solution ... give up.   sorry i can't be more helpful. Reading this there is no hope for humanity. Makes me depressed

[Gyro]

Well out of order free_electron!! 

You put words in your quote that the OP never used - that's NEVER acceptable! 

The guy is trying to learn, his questions, while maybe a little naive at times have been sensible and his wording upbeat - not what you have portrayed in your supposed 'quote'!

That kind or post is just plain destructive - you clearly have nothing useful to contribute and if you really are depressed the you really should seek medical help, it's a serious condition, not take it out on the OP!

[Brutte]

(...) for university project (...)

Please edit your opening post, change that to "I am nine years old" and I am sure you'd find someone willing to help you.

[GEuser]

Onya Gyro well picked up , they say opinions are like arseholes as everyone has one (well almost) , same as that following one Brutte is it a Septic too i wonder , doing a false quote deliberately (the op was not edited) is flat out wrong and a Ar_ehole act , imo of course and yours too ..

[timb]

Well out of order free_electron!! 

I'm angry about quotes! Rarrrrfgh!!1one Rabble Rabble Rabble Rabble Rabble Rabble!

It's clear free_electron's quote isn't verbatim and has been edited for brevity (and humor).

Lighten up.

[Gyro]

Hardly humor 

[rstofer]

Questions I would ask:
1) Can the STM32 output the sample clock at 40 MHz?
2) Can the STM32 DMA channel accept inputs at 40 MHz?
3) Does the DMA channel accept external parallel data as wide as the A/D at 50 MHz?
4) Is there enough RAM attached to the DMA channel to make a reasonable waveform buffer?
5) How do I trigger the beginning of the sample period?
6) How does another DMA channel grab the data and display it or is this just done by the uC code?

There's a reason that scopes use FPGAs or CPLDs for the timing critical portion of the circuit.  I'll concede to 'just guessing' but I don't think the STM32 will have anything to do with data capture.  Not at these data rates and with any reasonable sample depth.  What the STM32 can do is set up the FPGA parameters which, on a school project, won't be much.  The FPGA will clock the A/D and stuff the results into SRAM.  I would try very hard to find 10 nS SRAM because I don't want to implement a DDR controller.  Micron makes some 512 Mbit SRAM but that's not much. 

OTOH, MANY FPGA boards come with a ton of DDR memory and some come with an IP license for the DDR controller.  The Arty from Digilent comes this way with the Vivado Design Suite Voucher:

http://store.digilentinc.com/arty-board-artix-7-fpga-development-board-for-makers-and-hobbyists/



The video leads me to believe that you get enough license certificate with the product to implement the Microblaze FreeRTOS Web Server without having to spend thousands of dollars on the development software.  It would be worth a call.

It's clear that the STM32 can't read the data in a program loop because even if the CPU could do one IO or memory instruction per clock and there were no pipeline breaks, the CPU could still only do 6 instructions per sample.  Often times, on an ARM, IO pins can't work at processor speeds.  This was certainly the case with the ARM 7s.

There seems to be a lot of SRAM on the chip.  Check out how the DMA channel works just to be certain you can grab the parallel output of the A/D converter and stuff the result in SRAM.

Even building this with an FPGA is a monumental project.  Once you capture the waveform on the FPGA, you still have to get it to the STM32.  Or maybe not...  Why not use the Web Server above to display the output on a browser?  Kind of slow but pretty easy to implement (I think...).

You might get some ideas from the Digilent Analog Discovery:

http://store.digilentinc.com/analog-discovery-2-100msps-usb-oscilloscope-logic-analyzer-and-variable-power-supply/

Look through the documentation linked down near the bottom of the page.

Heck of a project!

[bktemp]

There's a reason that scopes use FPGAs or CPLDs for the timing critical portion of the circuit.  I'll concede to 'just guessing' but I don't think the STM32 will have anything to do with data capture.  Not at these data rates and with any reasonable sample depth. 

Larges STM32 have a SDRAM controller. As I've said, I would use the DCMI for capturing the ADC data. It is specified up to 54MS/s at 8/10/12bits per sample. You can use a 8/16/32/64MByte SDRAM, that should be enough sample depth for a decent scope.
According to the datasheet the DCMI transfer size is unlimited in JPEG mode. You need to setupt DCMI + DMA for reading the data into SDRAM. Vsync needs a short pulse for starting the DCMI. When HSync goes high, sampling is started. With some clever logic even pretriggering should be possible: The DCMI is continously sampling the data into SDRAM. When a trigger pulse happens, you need to remember the current DMA address and set HSync low after some time to stop sampling.
I am not saying this is the best way to implement a DSO, but it should be possible without an FPGA if 54MS/s are enough.