WIP: Homemade 100MS/s portable oscilloscope

[Nolly]

Such an amazing project. I wonder if there is a way to get the cost down by switching the FPGA for some other ASIC like those cheap SDRs which use an old TV Tuner chip if I remember correctly. Maybe some old DSP + a low cost SOC. Obviously ADCs will always be a big expense once you get into the higher speeds.

Thanks! I prefer to spend to few more dollars and to have recent components. The "maximum low cost" version was only the first one. But don't get me wrong, I'm still going for low cost.
 Also, I've done quite a lot already and I don't wish to change completly the platform.

A few years ago I advocated for an open source license "instrument ASIC" which would have been useful for this, as they have become the big driver for the decrease in scope cost in the last year or so. Back then the opinion on the forum was that nobody would be interested so I gave up but in my research I found several examples of custom 10-20GS ADC ASICs contracted by research projects (Like CERN etc.) with a cost <$40.

That ones sounds actually interesting! But that's probably chips that are not produced and/or very difficult to obtain? Plus it's probably very application specific, and you would need to have a really well designed analog front-end and memory bandwith will start to be an issue. For now I'm at 100Msps and next step is 1Gsps "only".

did you consider a Zynq7000? it's basically an Artix7 and a cortex-A9

Yes, I strongly consider it, but for an hypothetic 5th version. The "all in one" SoC version, where the MCU and FPGA merge. But I'm not sure yet how much it will be relevant.
A lot of integration creates an even more hardware dependant solution, even if simplifying the whole system.
At the moment I like to have a clear separation between FPGA and MCU. They communicate with simple SPI and the FPGA acts as a black box. It also means I can easily change the MCU without impacting at all the FPGA side, and vice-versa, thus limiting development impact (it's important as the development team is only me )

[excitedbox]

The goal of my research was to figure out how much it would cost to have an oscilloscope asic designed and open source the license then raise money to get wafers fabbed just like any fabless company. Keysight uses the same ASICs in their high dollar scopes as they do in their lower end professional scopes. They just use more of them. Keysight uses a 65nm node which is just below the maskless lithography limit but by aiming for the ~120nm node size you avoid the costs of having mask made and you can still get to the 5-6GS per ADC performance level which could then be used in a 1-4 chip design depending on the performance you want.

Now that more of these ASICs have been developed by companies like Rigol it is less important but in the end it would have made it possible for companies like Finrisi and Hantek etc to offer low cost hobby scopes at the same price point of the new Rigol scopes while also making them available for cool Open Source/DIY projects.

Based on my conversations with the chip design houses it would have cost around $1m NRE costs + a royalty per chip for licensing their IP. This would have been for an ASIC that has everything needed handle the measurement sides and dump it into DDR memory. Then you still need an ARM SOC to run the interface etc.

[Nolly]

Keysight uses the same ASICs in their high dollar scopes as they do in their lower end professional scopes.

Yes, because it costs a lot to make an ASIC.

Now that more of these ASICs have been developed by companies like Rigol it is less important but in the end it would have made it possible for companies like Finrisi and Hantek etc to offer low cost hobby scopes at the same price point of the new Rigol scopes while also making them available for cool Open Source/DIY projects.

They don't use ASIC probably because they don't have the funds for it. The oscilloscopes they made looks like the one I'm making with steroids, because there have more people so it looks nicer. Making ASIC requires a lot of money and skills they probably don't have atm. And maybe it's a good thing. I'm sure Rigol and stuff spent a LOT of money and time to make thoses chips. What's more interesting, is how they could get profitable out of this. But be sure, these Chinese companies will also make their ASIC (if not already) soon or later.

They just use more of them. Keysight uses a 65nm node which is just below the maskless lithography limit but by aiming for the ~120nm node size you avoid the costs of having mask made and you can still get to the 5-6GS per ADC performance level which could then be used in a 1-4 chip design depending on the performance you want.

Here, I'm not aware of the technology at all. I believe you.

Based on my conversations with the chip design houses it would have cost around $1m NRE costs + a royalty per chip for licensing their IP.

I've read thoses costs before on the internet. I'm still really surprised. With that amount of money in many countries you can dig a petrol rig. No joke.
In the company I worked for, I heard the sum 50k$ for one ASIC. Maybe it's just one prototype, I don't know. But 1 milion kinda seems like a joke.
Anyhow, this price is an absolute no go for the DIY area.

Anyway. Here is an update of my project.

Here I speak about the 3rd version.

It consists of 2 PCB:
-PSU board, 2 layers, which embedds all buttons, switches, and all power supplies (there are 11 voltage rails). Before, there were no power supplies here.
-MCU board, 4 layers, which embeds the STM32, Spartan7, SDRAM, DDR3 and 4 inputs channels.
They connects through a 2x10 1.27mm header connector. Before I used a 50pins FPC connector and cables.
I removed the cable, changed the PSU board dimensions to overlap the MCU board and added an I²C GPIO expander.

I almost finished the second version of the case. I need to add angles on the walls for demolding, adjust a few dimension and it's almost done.
I enlarged the screw inserts to use brass screw inserts.
I will update 3D renders soon, but I want to render them in Blender first. It's more beautiful 
The whole scope is 240x114x26mm. With a 7" screen and buttons. It's thin. About 20mm thinner than the current version.
It embeds a 3S Li-ion battery. The previous version had no battery.
I except about 37Wh, so 5 to 7 hours autonomy. In the future, I might go for a 4S battery (47Wh) as there is space for it (6 to 8 hours).
I lowered the power supply requirements from 24V to 15V. I replaced the 6mm barell power connector by a 3mm one.
It now embeds a Ti BQ24610 for battery managment.
I moved all the power supplies to the HMI (now PSU) board. It leaves more space for the main MCU board for the 4 channels.

Yes, I went for 4 channels at 100Msps. I reorganized the layout. The FPGA doens't change, as I could get all the pins out on 4 layers, including DDR3, by removing some configuration resistors.
I intend to lower the FPGA core frequency from 200 to 100MHz, to lower power dissipation and because of timing closure difficulties.
Atm I have a few nets which have a 100ps negative delay (however it worked even with a 2ns negative delay, lol.)

I modified the trigger input of the scope. Before, it has only one external trigger input on a BNC (I actually never used it).
Now, it has one external trigger input and a trigger output on SMA connectors. (Why SMA? because I lack space).
It will allow to cascade the scopes to get 8 channels or more!
The first scope triggers, and output this triggers to the next scope, which will use his external input trigger to .. triggers.
Of course there will be latency due to cable lenght. It will be sorted out later

The STM32F4 might be replaced by the STM32F7: pinout should be the same, but I need to confirm.
Going from Cortex M4 to M7 should give about 50% more performance. I might lose some flash, now I have 2MB, and I use 1.5 (1M is for graphics only) and the M7 I target has only 1 MB.
But I have workarounds for this.
Main keypoint I also spotted here is the M7 memory cache. I hope it won't break my DMA transfers. I hope all other peripherals will be the same.
I dont want to rewrite all drivers.
Also, I intend to deploy FreeRTOS on this one and add USB and FAT support, in order to make screenshots. Big move!
That's a lot of work, It won't be ready before summer.

On the 4th version I expect to change the whole front end and use a HMCAD**** input ADC.
It will simplifies a lot the front end and allows to sample up to 1Gsps. The FPGA will have to be swithed from Spartan7 to Artix7.
This will happen not before end 2026

[Nolly]

Guys, please have a look at theses 3D images. Blender inside
This is pretty much what the new version is going to look alike.
I have almost finished the routing, solved many issues, and created a new housing.
I of course reused a photo of current prototype to create a realistic screen view.

I intend to have made a custom glass for the screen, 1mm thickness with darkers (painted) areas for the non-screen area.
The battery will be a 3S Li-ion with a standard connector.
I intend to used a glued-plastic-UV-printed-not-sure-yet-thing for the HMI and buttons area.
Body will be resin-3D printed, while being parameters-ready for plastic injection
Buttons will be 3D-printed too







Please say it's cool so I keep posting on this forum 

[mawyatt]

Well we'll certainly say "COOL", very COOL indeed

Best

[pcprogrammer]

Very impressive indeed. FNIRSI can eat its heart out. 

This has the look of a professional scope and not a toy like most of the FNIRSI stuff.

[Conrad Hoffman]

That's a beautiful and remarkable project. It's incredible how far we've come in DIY. For some perspective, scroll down a bit and look at the scope Tatjana van Vark built when she was 14 years old- https://craftsmanshipmuseum.com/artisan/tatjana-van-vark/

[Grandchuck]

WOW!

(picking up pieces of my brain)

[2hda3aw5h@mozmail.com]

I want one! take my money

[uer166]

Let me know if you need a custom glass supplier with low MOQ. I've been using a particular one I found on Alibaba for my personal handheld projects, and they CNC the glass and silk screen it.

[Nolly]

Thanks you for your messages!!

This has the look of a professional scope and not a toy like most of the FNIRSI stuff.

Well I'm still far from FNIRSI products! But not that far..

That's a beautiful and remarkable project. It's incredible how far we've come in DIY. For some perspective, scroll down a bit and look at the scope Tatjana van Vark built when she was 14 years old- https://craftsmanshipmuseum.com/artisan/tatjana-van-vark/

Holy mother. That's another level. Stratospheric. And no internet to help you at that time. It helps keeping head cold!

I want one! take my money

  I'll think about it when I get a stable, full working prototype. But it will probably be more expensive thant the "FNIRSI stuff" for tenth of units. Probably in the 400$ range. I have no idea, I haven't calculated it all. I'm thinking of semi-assembled, semi open-source stuff. Semi-assembled to limit cost and save my manpower on development/manufacturing/shipment, semi open-source because I still wanna keep a direction to my project but give the possibility for anyone to write its own firmware. Maybe provide only binary for FPGA and full C for MCU. Don't know yet, I'm new to this. But after so much pain I'm not yet ready just to "give it"

Let me know if you need a custom glass supplier with low MOQ. I've been using a particular one I found on Alibaba for my personal handheld projects, and they CNC the glass and silk screen it.

That would be nice. I saw many manufacturers on alibaba, none of aliexpress though. I quite use aliexpress often.

Update!
I sent files for PCB manufacturing and assembly of the third version. Always a stressfull moment, mistakes are so easily made. I read back schematics and board hundred of times, but I never felt sure. I added a 1KHz output square signal for probes calibrations.

The major trouble is with the components sourcing. From version to versions, many parts become unavailable. I use LCSC as supplier. They are much cheaper than anyone else, for example the FPGA is less than 15$, the CPU 10$. But when their stock is empty, it's empty. Now, the ADC are unavailable. I will have to order from different chanel and solder them myself. Also, SDRAM and DDR3 got twice more expensive or out of stock. I had to change twice the part. Battery charger is unavailable too. I'll have to hand solder the VQFN-24.

Little side story. On the previous version 2, I by mistake connected a +3.3V of the STM32 (BGA package) to GND on the schema. I did the same mistake with SDRAM on version 1... Anyway, I bought a small 25x25mm radiator with a tiny ventilator to cool the STM32 down because as you expect, it got burning hot. And it worked. Later, I unsolded the BGA, drilled the pads with a 0.3mm hand drill, reballed the BGA and resoldered it by hand. And it worked marvelously.
Hand drill + BGA reballing kit + hot air station : 50$ on aliexpress 

[moffy]

Little side story. On the previous version 2, I by mistake connected a +3.3V of the STM32 (BGA package) to GND on the schema. I did the same mistake with SDRAM on version 1... Anyway, I bought a small 25x25mm radiator with a tiny ventilator to cool the STM32 down because as you expect, it got burning hot. And it worked. Later, I unsolded the BGA, drilled the pads with a 0.3mm hand drill, reballed the BGA and resoldered it by hand. And it worked marvelously.
Hand drill + BGA reballing kit + hot air station : 50$ on aliexpress 

More skill than I have, thanks for the project, very interesting and involved, congrats, hope the new boards go well.

[harerod]

...

I sent files for PCB manufacturing and assembly of the third version. Always a stressfull moment, mistakes are so easily made. I read back schematics and board hundred of times, but I never felt sure.
...

Every board designer has this issue, since it may take production several weeks till you get your first samples back for testing. What helps to minimize mistakes:

- read datasheets and online information
- use your CAD system's tools (electrical rule checks for schematics, design rule checks for PCB)
- let a competent person review your design. I.e although I run a one-man show, I ask a friend and/or the client to review my work
- my most powerful "trick": after layout is complete, wait a couple of days before you review it again, and then go into production. A break between design and review helps to cure my blindness against my own mistakes. I know, often schedules are tight, however, letting the work rest over night, or ideally, over a weekend, doesn't cost much production time. And frankly, what is a couple of days, when you know that a re-spin costs several weeks (ignoring the cost and waste). Know your manufacturers' deadlines, e.g. many PCB manfacturers count it as day one, when the order is placed before, say, 1100AM. So finish a layout, let it rest over night, have look at it again at 0700AM the next morning, build production data, place the order.

[mawyatt]

...

I sent files for PCB manufacturing and assembly of the third version. Always a stressfull moment, mistakes are so easily made. I read back schematics and board hundred of times, but I never felt sure.
...

Every board designer has this issue, since it may take production several weeks till you get your first samples back for testing. What helps to minimize mistakes:

- read datasheets and online information
- use your CAD system's tools (electrical rule checks for schematics, design rule checks for PCB)
- let a competent person review your design. I.e although I run a one-man show, I ask a friend and/or the client to review my work
- my most powerful "trick": after layout is complete, wait a couple of days before you review it again, and then go into production. A break between design and review helps to cure my blindness against my own mistakes. I know, often schedules are tight, however, letting the work rest over night, or ideally, over a weekend, doesn't cost much production time. And frankly, what is a couple of days, when you know that a re-spin costs several weeks (ignoring the cost and waste). Know your manufacturers' deadlines, e.g. many PCB manfacturers count it as day one, when the order is placed before, say, 1100AM. So finish a layout, let it rest over night, have look at it again at 0700AM the next morning, build production data, place the order.

If you talk about "stressful" ask any chip designer. You have multiple millions $ riding on the chip (sometime 10s of millions), an error can not only cost multiple millions but a rerun can take 1/2 year!!

It's interesting that chip designers church attendance dramatically increases after chip design release, even for atheist 

When the chip comes back from fab and doesn't work, you'll find all the chip designers under their desks and pointing at someone else

The most embarrassing moment we had was with a highly complex analog and digital chip. A team of analog designers and digital designers worked on their respective areas, and an overall lead designer oversaw the developments. When the chip came back it didn't completely work, the digital worked and the analog worked but the connections from analog to digital weren't there.

We were called in for the design review with customer, and recommended trying a focused ion beam connection to salvage the chip before the customer pulled the plug. We tried two different ion beam approaches with two different machines, neither worked and the customer pulled the plug.

The lead designer then retired and we convinced management to re-spin the chip with the fixes and use our limited in-house IR&D funds for such. When the chip came back it worked brilliantly which led to it's use in many important applications. In fact it completely outperformed the next generation chip that Motorola produced, which had the development transferred to after our embarrassment and Motorola was the customer "preferred" source anyway. An fascinating story follows this chip development if interested.

Best

[SiliconWizard]

However careful you are, it's unrealistic to get a hardware design 100% right at the very first prototype, whether you're alone or in a full team.
I always count a minimum of 2 iterations.

Just 1 iteration and 100% correct: you were very lucky or the design was trivial. Even so, an edge case or additional feature that was not thought about before testing the prototype almost always crops up.
2 iterations and 100% correct: you are good and did things right.
More than 2 iterations: depends on the complexity. If the design was only moderately involved, you may start questioning your approach or process.

[mawyatt]

However careful you are, it's unrealistic to get a hardware design 100% right at the very first prototype, whether you're alone or in a full team.
I always count a minimum of 2 iterations.

Just 1 iteration and 100% correct: you were very lucky or the design was trivial. Even so, an edge case or additional feature that was not thought about before testing the prototype almost always crops up.
2 iterations and 100% correct: you are good and did things right.
More than 2 iterations: depends on the complexity. If the design was only moderately involved, you may start questioning your approach or process.

That's a source of experience

However in our case, we were expected to nail the chip design 1st pass every time. Our management and customers expected this. Our customers were some of the smartest folks we had ever met, and accepted no-excuses!! There were important "motives" behind this thinking/pressure, beyond just $, which we can't discuss.

We had another mishap, thankfully forgiven by our customer. Another complex mixed signal chip, this time in IBM SiGe BiCMOS. We did the Analogy/RF/Microwave Transceiver design while another company did the digital CPU/Memory/DSP part. Generally this is not a good idea to split the design between different companies but customer insisted as we had limited digital resources available (hiring or bringing in consultants wasn't an option due to the highly "sensitive" nature of the development, and personal "approval" which took years, even for folks already within the company). At the time this was the most complex mixed signal chip ever done on IBMs process. When the chip arrived the Analog/RF/Microwave side worked, but the Digital Side showed overcurrent on all the VDD supply lines. Turns out the VDD protection diodes are put in backwards, effectively shorting VDD. How this passed DRC on the Digital Side is still unknown (probably faked or bypassed due to the pressure to release).

Since this was a quick fix and IBM was seriously interesting in how the mixed signal chip behaved, they put us on a fast track thru the fab and we got the re-spin back in 6 weeks instead of 6 months!! The chip worked and led to many other developments.

Best

[SiliconWizard]

Getting an ASIC right the first time is even more challenging, especially if it's not just purely "digital". (But even if "purely digital", unless it's very simple, even with extensive simulation, you may always miss edge cases.)

I have very rarely seen a 100% correct design on the first run.

Now of course, given the cost of production for an IC, in many cases you'll try to find workarounds for things that don't quite work as expected rather than respin it, or decide to disable a non-working feature entirely, as long as it doesn't cripple the chip too much for its intended use. Not always possible.

[adinsen]

I'm amazed by your project. I also enjoy your notes about the little messups. Thanks for sharing! I hope you'll sell your scope as a kit eventually when you feel it's ready.

[Nolly]

More skill than I have, thanks for the project, very interesting and involved, congrats, hope the new boards go well.

Actually it's more about time spent than skills. It's very manageable if you divide everything in small parts that are not too complicated, but puting everything alltogether takes a lot of time.

- let a competent person review your design. I.e although I run a one-man show, I ask a friend and/or the client to review my work
- my most powerful "trick": after layout is complete, wait a couple of days before you review it again, and then go into production.

Someone's else eye is always gold. Having a break from the design process too. I actually try not to look at the design after production, I'm always afraid to find bugs 

If you talk about "stressful" ask any chip designer. You have multiple millions $ riding on the chip (sometime 10s of millions), an error can not only cost multiple millions but a rerun can take 1/2 year!!

How not to sleep at night! This can waste a full project, however companies involved in theses designs have differents budgets and don't put all their eggs in the same basket..

However careful you are, it's unrealistic to get a hardware design 100% right at the very first prototype, whether you're alone or in a full team.
I always count a minimum of 2 iterations.

It's something people with no experience in profesionnal development don't always understand. Can be hard when doing freelance. They came with huge expectations, low budget and expect everything works straight out.
I actually count 2 to 4 iterations, without previous schema and without major architecture changes. I think it's reasonable expectation.

I'm amazed by your project. I also enjoy your notes about the little messups. Thanks for sharing! I hope you'll sell your scope as a kit eventually when you feel it's ready.

Thanks a lot!

Update
Boards are now in production. Now the only thing to do is to wait.
I have redone the housing entierly, adding draft angles everywhere. I now only need to add some fillets and vents. No idea about the vents area to use, dissipation is about 6 watts and housing is kinda tight. I think I will add many. I got crazy with Freecad! It becomes super slow when project gets complicated. I think I could go to Solidworks next time.
I still need to order custom glass and plastic stickers.
Next update will probably be in a few weeks 

[Nolly]

So, I've received almost all the parts!
And there are a lot:
The PCBs (2xPSU, 2xMCU, 5xdebug), 3D printed parts, the battery, AC adaptor, probes, screw, screw inserts, 3d printed parts, custom screen glass, custom sticker, anti-slipping pads, B-7000 glue, connectors, ribbon cables...
Plus some components which were not mounted or not in stock.
For one prototype, I calculated an unitary cost of about 530$ including shipping.
It's not optimised at all due to low quantities. A coherent sell price would be around 300-400$.

And of course as I was afraid of, there are some mistakes, all on PSU board for now, for example:
- battery 2mm thicker and 1mm longer than expected
- library mistake on power switch
- one wrong resistor value on power-good detection
- screw inserts won't fit (SLA resin don't melt but breaks during inserting.. I didn't know that)
- Internal ST32 pull-ups to weak for I²C
- Forgot an open-drain mosfet for TFT backlight disable
- BMS of battery cuts too low (need to add a battery protection circuit to cut it at low voltage)
- Battery doesn't charge (to be investigated)
- I suspect one PCA9555 burnt due to IO contention (wrong setting) = add series resistors

Nevertheless, I got it all running.

Update from STM32F4 to STM32F746 went pretty smooth. Almost all peripherals are identical.
However, the CortexM7 version r0p1 implemented by ST which has a silicon bug from won't allow step debug when interrupts are striking: the interrupts must be disabled during debug. Quite annoying.
I'm also afraid that the performance improvement from the M4 to the M7 will be too little. I don't seem to notice a huge difference for now.
Spartan7 (no change here) and DDR3 also works like a charm. For now, no issue found (yet!) on the CPU board in a couple of days.

For the first time, I used my current scope (the orange-buttons one) in real situation, to debug the new scope, mainly working on the I²C (see the contention issue on SDA on the picture). Pretty nice tbh.
I really enjoy my "super-zoom" feature once the signal got captured. While capturing at 100MSps and 5ms/div, I can zoom up to 20ns/div after the capture. Some other stuff would need to be improved. Also found a few bugs.

Now, I need to clean the code, fix bugs, get it all properly working.
I'm actually quite impressed by the global result and the look of the scope.

A few photos (more to come):

[Nolly]

Update
Scope is up and working!
4 channels are now working flawlessly. Still some improvements to do on annoying trigger horizontal positionning and zooming, though.

Performance
I was wrong about the Cortex M7 performance.
After activating data cache and instruction cache, things got much better. M7 runs at 216 MHz, SDRAM at 108 MHz.

Graphics
I went from double buffering to triple buffering for the screen. Doing such, I avoid the "60FPS to 30FPS" drop each time the processing takes a little bit to long. Space in external SDRAM is not an issue.
Now, the FPS are much smoother, I'm always about 55-58 FPS, down to 40-45 FPS when using FFT or when one channel is noisy all over the screen. That's without compilation optimisation (without the -Ofast).
Need to solve some frame buffer switching issue, I got some ghost images, probably a race condition to pointer switching.
The heaviest graphic operation is drawing the lines. With 4 channels, 700 pixel screen width, it's 2800 lines every 16.6ms.  I'm using Bresenham's algorithm and I tried everything possible to go faster, (different algorithms, inline functions, playing with cache and burst of Cortex M7...) without success. And every AI suggestions was slower, we can keep our jobs
I'm thinking moving to LVGL for smoother graphics, but I'm afraid to loose a lot of performance.

RTOS
I also move from my super messy big loop to FreeRTOS. First time using. First step going to the middleware world.
I decided to go for it when I wanted to add calibration function working with the screen at the same time. I understood, that I will have to handle different tasks in parallel.
But it was a goal from the start of the project. I'm gonna need it too with USB and FAT.
Well, got it up and working after an afternoon.
I was relunctant to use AI, but here Gemini (the one from google start page) is actually incredible at helping from zero. Without it, it would have been 4-5 days, not half a day.
I'm concerned about the future of internet tbh. However, for deeper logic, he's still out. But for how long?
Well, dealing with parallel tasks is actually awesome. It simplifies things SO MUCH. It's just a bit brain-complicated about data access, task sleep/wakeup, semaphores and stuff.

I'm still getting a 70% CPU time only for graphics...
The way I draw my library is the following:
I use big "canvas" static structures that contains all dots, lines, rectangles, BMP images, texts.
Inside any functions (or task, now) which need graphics, I just add object to this structure. I got several structures, corresponding to different graphics layers.
When the runnning functions end, I call a "draw frame" task, that browses all the structures and copy BMP or text fonts from FLASH to SDRAM frame buffer (using DMA2D and ChromART), draw the lines (Bresenham's algorithm), well doing all this stuff. Note for myself: need to add some semaphore of double buffering here.
Anyways this takes 70% CPU at 60 FPS.
I didn't mention it, but it's all in C. C++ is for later...

Bare-metal
I'm still not using any STM32Cube ready stuff. I include the libraries and write the Cmake myself, to understand it all. I'm still bare-metal, without HAL.
It's to understand how everything is working and linked together.
In the future, I may change tactic.

Hardware
I still got issues with matching oscilloscope probe to attenuation stage input. I got a simulation ruggning on LTspice, calculating everything, RLC of PCB lines, impedance of the cheap oscilloscope probe I'm using, lenght of cable, parasitic capacitance of diodes, relay, photomos... but still, practical results differs a little from simulation (but not so much!)
Actually, with the best setting I could got, I sampled with FPGA a rising time of 20ns, without ringing. Which means about 20-30MHz bandwith, which I expected from start. It's ok for 100Msps.
Well, I ordered a bunch of NP0 picofarad capacitors (like 15, 18, 20, 22, 24...) and will try them out all. At least they are 0603 as input voltage might be high, it's gonna be a bliss to solder!

Also, I got issues with offset OPAMP. I'm using multiplexed DAC from the STM32F7 to generate an analog offset for all the channels before they reach the ADC (this helps to keep the 8-bits resolution, any digital offset would lead to only 7 bits - and I'm not even speaking of ENOB), anyway my fast 180MHz OPAMPs followers were oscillating, probably due to lenght of PCB traces and their capacity. I had the issue from the very first prototype, but then I decided to use an LM324, much slower OPAMP. And it started oscillating even more, very badly, at low freq.
But now, I tried using theses LM324 again, and everything is fine. Analog electronics are a mystery. Anyway, I've got a stable offset voltage.

Sorry for all the un-understandable stuff.
Here is a cute stupid phoro of the scope during calibrating stage.
I also wanted to add a cute image of a cat (which would get more likes than any of this stupid work) but there are already plenty over the internet.



Note1: painting in glossy black is a bad idea,
Note2: I'm still waiting for the custom stickers

[moffy]

I'm using Bresenham's algorithm

It really is ubiquitous, from graphics to CNC, where ever a line needs to be drawn. If you want to optimise it, if you haven't already, check the assembly that the C compiler is generating, register variables in loops can help a lot.
For your application, which is performance critical, stick with C, C++ can have a lot of overhead, extra hidden functions like constructors/destructors etc. C++ makes life easier but at a performance cost and a degree of obfuscation.
I don't think we need to worry about LLMs/AI taking jobs long term, they are finding that the data center cost of replacing a programmer is higher than actually hiring a person.

[Nolly]

I'm using Bresenham's algorithm

check the assembly that the C compiler is generating, register variables in loops can help a lot.

After your message I spent a whole day trying to improve it
The algorithms translates into compares and branch in assembly, there's no counter (if that what you meant) inside the core registers. At least I think.
Nevertheless, the draw line functions calls data from RAM, so I decided trying to improve its reading access speed.
The CortexM7 has ITCM and DTCM memories so I spent a bunch of time moving some critical code and variables in there, also the stack of FreeRtos task calling thoses functions.

I went through some headach setting up linker and startup, setting up MPU to improve the throughput to external sdram, discovered nice bugs dues incoherences cache - ram using DMA functions withing interrupts, playing with all the CortexM7 cache synchronisation CMSIS functions I could find, to only discover at the end that the default linker which didn't have ITCM and DTCM sections decleared already had put thoses data in DTCM in the first place (functions still in flash).
At the end I got no improvement of performance, and putting the draw line functions into ITCM started to work erratically when I touched the menu of my scope.. So I removed it.

After this black magic the only major improvement of performance was made just by using the magic -Ofast flag in the compiler which I usually don't use during debug.
IDLE task went then from 0% to 40%. And anyway when the screen is saturated my draw line fonctions doesn't use Bresenham's but just draw vertical line using DMA2D (which I improved a bit).
Now I have nothing inside DTCM, it looks like this RAM section didn't help in my case
Anyway I learnt a lot thanks to you!
The scope display is still very fluid, > 50FPS.

The calibration procedure now saves results into a block of flash of STM32.
It calibrates only the internal offset for now, then I'll add also external calibration (vertical) for all channels and all calibers. With it I hope to target 1-2% accuracy in voltage measurement.
I'm getting about 85% usage of the 1MB flash and 70% of ram (only static declarations), it's getting tight.

[SiliconWizard]

I'm using Bresenham's algorithm

It really is ubiquitous, from graphics to CNC, where ever a line needs to be drawn

Well, it was. It can still be useful if you run code without a FPU, the FPU is dead slow, or you're implementing it on a FPGA. Otherwise, just computing the next dots on the line using FP is often faster: Bresenham has branching in a tight loop. With FP you can draw a whole segment in a loop without any branching. You just need to determine the right step so that there is full coverage and no missing pixel. You can always test and compare. If you want antialiased, there's Wu's algorithm that does just that efficiently.

After that you of course have RAM access that can become a bottleneck.

I saw in your last post that you were not enabling compiler optimization until recently - unoptimized compiled code is a dead cow.

[moffy]

Just as an illustration of how 'register' can be used for the Bresenham line drawing algorithm. I borrowed the code from: https://www.thecrazyprogrammer.com/2017/01/bresenhams-line-drawing-algorithm-c-c.html
and have used the 'register' keyword to help speed the loop, nothing optimal but by keeping the loop variables in registers you don't have the delay of memory accesses. Just be sure to push and pop the appropriate registers, but the compiler should do that.

Code: [Select]

void drawline(int x0, int y0, int x1, int y1)
{
    register int dx, dy, p, x, y, rx1;

rx1 = x1;
dx  = x1 - x0;
dy  = y1 - y0;

x  = x0;
y  = y0;

p  = 2*dy - dx;

while(x < rx1)
{
if(p >= 0)
{
putpixel(x,y,7);
y++;
p = p + 2*dy - 2*dx;
}
else
{
putpixel(x,y,7);
p = p + 2*dy;
}
x++;
}
}