EEVblog® Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: Nolly on February 03, 2026, 11:23:51 am
-
Hi there.
Welcome to my Work In Progress thread.
This first post is regularly updated, for more details on development go to the last page of the thread
This is the current design (version 3), it has has 4 channels and samples at 100Ms/s (without interleaving).
The core uses a STM32F746 at 216 MHz with 8MB of 32-bits SDRAM, a Spartan 7 and 128MB of 16-bits DDR3.
[attachimg=4 width=600] [attachimg=5 width=572]
Global features:
Inputs: 4 analog channel, 1Mohms, 20-25pF (T.B.D) + 1 external trigger (50 Ohms, 3.3-5V input)
Output: 1 trigger output (50 Ohms, 3.3V output), to chain 2 scopes
Sampling: 100 Msps (200 Msps T.B.D) on all 4 channels, not interleaved, 8 bits resolution
Bandwidth: 20 Mhz (40-50 MHz T.B.D), limited by analog antialiasing filter
Memory depth: 16,7 millions samples per channel (up to 835ms acquisition time)
Vertical: 20mV/DIV to 5V/DIV inputs, x1 and x10 probes modes
Coupling: DC, AC, GND
Horizontal: 20ns/DIV to 50ms/DIV
- 20ns/DIV to 2ms/DIV : 100MSps sampling
- 5ms/DIV to 50ms/DIV : 10MSps sampling (100Mhz internal + min/max decimation filter)
Mega zoom: zoom-in and zoom-out capacity:
- capture at 2ms/DIV, zoom up to 20ns/DIV after capture
- capture at 50ms/DIV, zoom up to 200ns/DIV after capture
- Slow and Fast browse of the captured samples
Measurements: min, max, peak-to-peak, average, RMS, signal frequency, 512 points FFT, horizontal and vertical cursors
Math: A+B, A-B, A*B (T.B.D)
Trigger: rising and falling edges, internal (CH1 – CH4) or external, trigger output
Calibration: for each individual channel and each individual caliber:
- automatic (vertical internal offset)
- manual (vertical channel precision) an external precision voltage source and multimeter are needed
Vertical precision after calibration: <1%
Connectivity: USB, firmare update, screenshot capture (T.B.D)
Date and time: Internal RTC (T.B.D)
Autonomy: about 5 hours, integrated 3000mAh 12V Li-ion battery
Power input: DC 15V-1A, 7W consumption (15W while charging).
Screen: TFT TN 7” 800x480 60Hz 16bits colors. Average of 45-60 FPS under nominal conditions.
HMI: Rotary encoders and quiet push buttons
Dimensions: 240x115x30mm
Programming: 20pins 1.27 connector + ribbon cable + custom PCB for SWD and JTAG (STM32/ Spartan7)
Development history:
In late 2024 I decided to make my own oscilloscope. For fun and to learn. Old dream. This is how looked like the previous version (please don’t judge the orange buttons):
[attachimg=1 width=500]
I have a electronics engineering masters degree and a 10+ years experience background in a multinational corporation. Having changing lifestyle and stopped working for a while, I used this free time to start this project.
It was made using KiCad, FreeCAD, JLCPCB and 3D resin printing. 7” screen. It samples at 100MS/s (10MS/s with decimation filter on larger timebases), embeds a Spartan7 coupled with DDR3, a 180MHz STM32 with TFT interface and SDRAM for video memory. It runs bare metal without any OS, not even using HAL drivers from ST (part of the challenge) and if the drivers are clean the scope logic part is a little messy. I wrote the graphic library myself and use all the DMA I could. Runs smooth 20 to 60 FPS.
It has all basic function a scope could have. It has run / single capture trigger (save up to 128 millions samples), 20ns/div to 20ms/div, different vertical calibers, FFT, vertical and horizontal cursors, possibility to navigate the stored samples in single capture mode, basic measurements. Work still need to be done to integer USB (save screenshots), auto calibration and some bootloader stuff for FW upgrade, but I’m kinda slow at wrinting code. Also a new PCB version is needed with some corrected issues.
It was my first time using FPGA at all and doing such a complex project. First time with DDR routing, with BGA, TFT display etc. It took long, very, very long hours until late. I got quite happy when I went from zero HDL knowledge to a working DDR3 at 400MHz. Also I started from absolute scratch. I don’t even have an oscilloscope myself and didn’t use any.
However I started to spend much less time on it because I’m not sure where this will lead me to, will I gain any benefit from all this work. Does it worth it. At first it was to learn new skills for employability, but I’m not sure I wanna work for a company again. In the other hand, it is now a nice prototype, and it would be stupid to drop all this work. But from a prototype to a final product the step is huge. Another drawback is that it’s also getting complicated on the financial point of view.
Anyway, I though it could be nice to share a bit. Here is what it looks like from the inside.
[attachimg=2 width=500]
-
Super nice job, that's a real accomplishment to be proud of :-+
-
Great work!
-
The orange buttons are amazing, don't doubt yourself, that's awesome.
What's the ADC?
> In the other hand, it is now a nice prototype, and it would be stupid to drop all this work.
Are you of the viewpoint that your time so far is wasted unless you make a perfect product, manufacture, stock, sell and support it? That's silly, that kind of thinking will leave you permanently unsatisfied because there will always be a bit more you can do. 1GS/s, 2GS/s, multiple screen sizes, packaging, better updatable firmware, USB interface streaming, ...
What you have made is impressive and will continue to be impressive for a long time, and you have a working prototype to show off & use. A scope in the hand is worth two in the dreams.
-
Great work!
If you don't end up making it a product, would you publish your design?
From the second picture, it looks like the ADCs are two AD9283.
-
yep really good work there, love the orange buttons, it gives some character loll :-+ :-+ :-+
your 4th iteration and up could interest many people here, you could even sell some kits, surely it could compete with others on the market ?
-
Very impressive project.
I'd love to read more about the project and the development process.
-
I'd love to read more about the project and the development process.
Me too, and you could sell the story of its development to an electronics mag. People will find it inspiring.
-
Amazing job, a dream of mine as well. and the fact you did it bare metal is just the cherry on the top.
even though, I am not a professional at all.
I suggest to sell it as a product if you can make it affordable and less time consuming.
Or sell it as a teachable course (someone suggested on electronics mags).
At first it was to learn new skills for employability, but I’m not sure I wanna work for a company again
why not? you seem to have very professional skills that any job will take you.
-
Looks nice. What about the amplitude frequency response?
-
That’s a seriously impressive project for something done in your free time - great job!. The board layout is really neat and the UI looks great. You definitely shouldn’t abandon it, although I get that turning this into a product is a huge effort and expense, and with the amount of low-cost oscilloscope competition in this space it would be very hard to reach a competitive price point.
-
First thanks a lot for your encouragement. I didn't except so many replies!
It means a lot since I haven't disclose any of this until now and got zero feedback so far.
I'll try to reply to each of you in one message.
ADC are AD9283 indeed, 100Mhz version. It's a very simple 8 bits parallel, quite old ADC, but good to start with. It's driven by the FPGA.
In the first hardware version there were no FPGA and I used the STM32 with DMA on one Port (all 16 bits) and a complex setup of timers. However storing both samples and graphics on external SDRAM I couldn't get higher than 2MS/s.
Analog chain should sustain at least 20MHz. I haven't tested it fully yet. Max amplitude is +/-40Vpp with x1 probe.
You are correct! It's always possible to do better, add new features and it's hard to know where to stop. Also going to production alone for such product is an insane amount of work.
It involve many testing (functionnal, EMC, environment), debug, more FW functions, certification, making expensive plastic molds, setting a supply chain, packaging, distributors, support and continuous engineering..
I am not sure yet what I will do with this. I will probably no go for to a product for the reason above. The FW alone is gonna be a one man year job.
I actually have no idea what I will do with this. :D
I thought about releasing it as development/learning platform, and/or as open hardware.
Maybe some kickstarter.
The 4th iteration is indeed the most interesting!
If you are interested, I will write more about the development process from the very start.
But I must warn, that I am quite a slow poster :)
At first it was to learn new skills for employability, but I’m not sure I wanna work for a company again
why not? you seem to have very professional skills that any job will take you.
Thanks! It's just that I would prefer to work for myself than for a boss :)
-
Impressive design.
If you are doing a hw revision, my suggestion would be to improve the time base, so it can give good precision frequency counter display almost for free.
100MHz tcxo are not so common, but you can use a very common & low cost 26MHz tcxo with Si5351/MS5351/MS5352 pll to derive your 12MHz &100MHz
Addit: I forgot the spartan 7 has a decent PLL, so you could feed in a TCXO and derive the 100MHz from that.
(Clipped sine could go via 2GU04 + RC)
-
I'm quite impressed just by the looks of this. I've seen a whole lot of "diy" level scopes, and I rarely see any scope which has a decent front end. Gabotronics has collected a lot of links to DIY level scopes (40+ or so).
I wonder what the BOM cost of this is, and what it would cost as a final product... But still, Sample rate and bit depth is nothing special for these modern times. As a real product it would have to compete with the handhelds from Owon and Hantek or the Zeewei. That would put it in the EUR 150 to EUR 200 range, and then you're still an uknown / new brand name.
To be successful as a real product, it needs something that sets it apart from these other products. The most logical option would be a connector that makes it possible to add multiple of these scopes together into a modular system. Scopes with more then 4 channels are quite rare and expensive. A way to stack and synchronize a bunch of these scopes will make it interesting to a different marketing segment.
And apart from just more channels of the same, a higher resolution ADC would also be nice. Or even a version with no ADC at all, but buffer for as a Logic Analyzer instead. Yokogawa SL1000 for example has a modular system with a bunch of different modules. Or go fully modular such as with the PXI modules.
Adding Ethernet with full SCPI control would also be a nice addition. I also like the idea of having a manual control panel with both buttons and rotary encoders, but using the bigger and higher resolution of a PC monitor for the graphical output.
PXI is outside of the reach of any normal hobbyist, and I guess there are quite a lot of people which would like it, but are scared away by the cost of a PCI rack too.
My dream is an Open Source rack system with a similar setup (but lower performance) then a PXI rack. But it's difficult to get something started to a point it has become a usable product and attracts interest from others. And such a product requires quite a lot of software development, and this puts it beyond the reach of a single person.
-
Feature request from a vector artist if you go commercial some day. RGB input in XY mode with variable persistence. In other words, Color Vectorscope. Or even two color "z" input would be an improvement, simulating the dual phosphor tubes that were a fantastic but short lived Fad in the 60s and 70s.
Very Cool Project.
Steve
-
Very impressive work. Don't know that I would recommend trying to make a product out of this as an oscilloscope, but there are probably niche markets that would do well enough. Some that strike me as possibilities (some are variants of thoughts above).
1. Kit for hobby types. Not competing on performance, or directly on price but attracting those who want to know a bit about the innards of their tools and want the "built it myself" cred. Might be tough to partition this so there was electronic assembly, but there is mechanical assembly and possibly calibration.
2. Development platform for those who want more or unique features. This would mean opening up the all or a major portion of the code.
3. Farm it out for local production for countries that make it hard to import this type of gear. Think pyramid marketing.
4. Customize it for specific applications. HVAC diagnosis and repair. Automotive repair. Audio. And a myriad of others. This would get you out of direct competition with an already fairly crowded market.
If you decide to get back into selling your design skills, either in the corporate world or as a consultant this project makes a pretty good calling card.
-
I actually have no idea what I will do with this. :D
.....
Thanks! It's just that I would prefer to work for myself than for a boss :)
I think I know what you can do (or at least consider), if you want.
In 1992 we (I with my brother) have made DSM-51 = Dydaktyczny System Mikroprocesorowy (Didactic Microprocessor System) destined to learn/teach 8051 assembler programming.
I have found two links at some schools showing it:
https://zs3ostrowiec.pl/komputeryzacja2.htm (https://zs3ostrowiec.pl/komputeryzacja2.htm)
http://zsp3zamosc.internetdsl.pl/index.php?option=com_content&view=article&id=87&Itemid=48&limitstart=5 (http://zsp3zamosc.internetdsl.pl/index.php?option=com_content&view=article&id=87&Itemid=48&limitstart=5)
Those times many schools in Poland didn't had money to buy even a simplest IBM-XT computers (hard to explain socialistic economy - as academic teacher I earned $13 per month (not a mistake) and IBM-XT without HDD price was $600 (with 20M HDD $800)). Because of this our system (using 2 lines display) allowed to write assembly program (you were selecting everything from menu) and then run it in full speed or step by step. For those who had IBM (with time there were more and more) I have written 8051 assembler and simple environment allowing for debugging (step by step with presenting all registers state after step) programs written in assembler code running in our system (code was not simulated at PC but really run in DSM-51).
Our system was practically the only one schools were using here. Our main concern when designing it was to make it as much 'idiot-proof' as possible (it is important in schools).
In 2006 we had got big government order for many of them. On this occasion, we handed over the distribution of our system to another company that normally deals in measuring equipment. Few years later this company asked as if 'by chance' we may be have something other to be offered for schools because from their contacts with schools they see that the opinion about our system is that if you wrap shit in paper and sign it as offered by us, schools will buy it without asking any questions.
I planned to make 'Analog Education System' having simple few voltage supplies, sine and square generators, multimeter and very simple oscilloscope on board. Everything controlled by program at PC.
The system should have in its center a area for circuit under test and there should be many such circuit samples.
Even our DSM-51 is much simpler device than typical PC, but because it is not mass production and have features not replaceable by other devices can have the price like PC.
Friends working at university asked if we can make such system for more modern microcontrollers. The reason - they tried to use typical starter boards (much cheaper), but they with contact with students lasted a year or two while from our systems bought 15 years ago 0 was broken.
Busy with other things, we didn't found time to make it (modern processor systems or analog education system) and will not find it, I know.
What do you think of making (really good = 'idiot proof' !!) Analog Education System and fight for the education market?
-
.....
What do you think of making (really good = 'idiot proof' !!) Analog Education System and fight for the education market?
The early Analog Discovery "Systems" might be considered for the educational market.
Best
-
UI looks impressive!
-
Thanks!
It already integrates a frequency meter. I got quite a decent precision, which I limited to 3 digits.
I haven't tested above 1MHz though. The 100MHz crystal costs 0.4$. With PLL I create a 200MHz internal clock for the DDR3 IP from AMD all all the logic, but might go down with 100MHz due to power consumption and difficulties to close all the timings.
About 250-300$ per prototype (very small quantities) including shipping and VAT. It would need to get about 3 times cheaper to be competitive.
I actually though about cascading scopes. But you would need a bigger screen, it's a different product.
I noticed portable scopes with decent screen size are rare. They have tactile screens or some non-rotating buttons. This is where I would go. Oranges rotating buttons :) Also most equipement are huge. Really, their depth is huge. I would go for compactness.
The PXI modules are as you say out of reach. Even Ethernet is complicated. Actually each time you add an interface, or an idea, you need code behind, tests, maybe a software on host side. Better to have a fully tested, easy to use limited range of features than a bunch of mess.
No idea what is a color vectorscope, but it looks beautiful on google images :)
Kit for hobby or open hardware platform would be the go, I guess. For a specific application, you need lot of knowledge about that specific field usage, which I haven't.
PGPG, targetting state owned companies or universities or whoever has huge budget and buyers which has no clue what they are bying is always a good idea (for the seller). Very often they overpaid without comparing anything because of established rules and buying channels. In that case, it's the company your are taking about which will take the huge margin. Project is still interesting though, but at the moment to far from mine.
It's like a compact station for learning and development.
I might be good to target development, not learning. Developping hardare quicky get messy (cables and instruments everywhere, breadboards..) and expensive.
I spent some time on the UI because I like beautiful things, and because they must be beautiful and easy to use. ;D
But I said that I will talk about about the development process, so here it starts! I describe the first version.
[attachimg=1 width=500]
I wanted the first version to be dirt cheap, and without FPGA, just to get to start with. All the design is based on that. I didn’t use any devboard and made the PCB straight.
It is made of 2 PCBS: the CPU one (4 layers) and the HMI one (2 layers). They connects through PFC 50 pins connector and cable. I wanted to learn Altium but for now I decided to stay with Kicad: Altium is costly and heavy.
PCBs were made at JLCPCB. Their PCB got more expensive above 100x100mm, so I stick to this size. I used 0.3mm vias, maximum number of “basic” components they have in stock, only top assembly, thru-holes I soldered myself. I used many chineses/asian components (DC-DC, OPA, passives, connectors…). Disclaimer: they all work but lack documentation and I’m not sure about their testing.
I designed the case using FreeCad, and get it resin 3D-printed also by JLCPCB, with the case background being resin-transparent because it’s stylish. I have no mechanical background but I read about plastic injection and tried to respect all the basic rules that are used for plastic molding, like draft angles, demolding directions, wall thickness… even if I only get it printed for good practice. I printed the buttons, some platic holder for them, and used another silicon-ready-button-stuff from Aliexpress (similar stuff is inside your TV remote) as press buttons. I tested the final assembly exporting STEP files from Kicad into Freecad.
I got the screen from Aliexpress. I had no idea about TFT screen (protocols, voltage, pinouts). I decided to use a TFT 800x480 with 50pins RGB888 FPC connector I found for cheap. I didn’t want to use any ready module. So the screen has no BRAM, no voltage generator, nothing. I did create all the transistors polarisation voltages (15V, 10V, 4V, -7V) and their sequencing.
I used a STM32F429 as MCU because it integrates a TFT controller with the possibility to use external SDRAM. I had never used any of theses before. I chose the 208pins LQFP and litterally used almost all pins. Like I had only 6 GPIO left. TFT is using full RGB888 protocol (8 wires per color) plus the pixel clock, sync and other controls: 33 wires. SDRAM is routed full 32bits: 56 wires. 26 wires from the HMI board. 17 wires to the ADC. About 20 wires for front-end control…
The scope always must samples at maximum frequency to respect Nyquist. It is problematic for slow timebases: it create a lot of samples. Internal SDRAM memory is not enough, so external SDRAM is used. I knew from start that I will got problems sharing SDRAM for graphic memory and samples. I just wanted to know, how bad will it be. I expected 10MS/s, I got less.
There are basically two modes of operation for the scope:
The autostop mode, and the continuous mode.
The autostop mode captures a fixed quantity of samples. It is the “run” mode from user point of view. The quantity of samples depends on the horizontal resolution (seconds/div). When the samples are captured, they are processed and put on screen. Then repeat.
The continuous mode captures continuously. It is the “trigger single” mode. It starts capturing when the user press the “start” button and wait for a trigger event. Onces it get a triggerd, it captures a fixed amout of samples after this event, having also in memory what happened before this event. This mode uses a circular buffer.
To make thoses modes work, I used a bunch of STM32 timers linked between themselves. They control the DMA transfer, from GPIO port (all 16 bits of data where on a single GPIO port) directly to the external SDRAM. The circular buffer is created using interrupts, to change the DMA destination addresses accordingly when the memory is getting full.
As it is not possible to control when the TFT DMA controller also access the memory, it causes bottleneck: even with SDRAM at 96MHz (STM32 overclocked) I couldn’t sample faster than 2MS/s. But it’s maybe also the DMA system bottleneck. I don’t know.
The trigger is analog: the output an external comparator (one input being driven by the STM32 DAC and the other by any of the 2 inputs channels) is used as a trigger input of for the timers: when a trigger is detected, the number of the sample (trigger info) actually being written into the SDRAM is stored. It helps to know when a trigger happened.
The analog input stage is composed of selectable attenuators, buffer, amplifiers, use analog multiplexers, and additionner for the vertical position. Well it’s quite messy actually. I had some troubles with probe compensation, buffer saturations and ADC saturation. They are getting corrected on the 2nd and 3rd version but I still have trouble with AC input mode, due to offset currents and high impedance. However, For later versions I might simplify all that thing drastically with PGA or similar. It substantially increases the cost, though.
Well that’ it for today. Here a photo of the first version. Later I’ll speak about starting this up and the problems I got. There were many, I let you find some of them on the photo… :-BROKE
-
Nolly, thanks for sharing!
-
PCBs were made at JLCPCB. Their PCB got more expensive above 100x100mm, so I stick to this size.
So you noticed that too. :-+
I like JLCPCB and they are still the cheapest even when the PCB is above the 100x100mm. My experience is limited to 2 layers without assembly though.
As an option for a new version of your scope you could look into Allwinner MCU's. They are reasonably cheap. A bunch of the cheap Chinese scopes both portable and desktop are created around the F1C100s, which is an older ARM architecture but still delivers reasonable performance. A beefier one is the R11, but for my next project I'm going with the T113-S4 (T113M4020DC0). It has a dual core ARM-A7 running at up to 1GHz, a Risc-V core running at up to 900MHz and a HiFi4 DSP core plus 256MB DDR3 memory at up to 800MHz. There is no datasheet for it, but there is for the T113-S3 which is the smaller version with only the dual core ARM-A7 and the HiFi4 DSP and 128MB DDR3.
There is a linux variant available for it that allows for easy use of things like networking and USB host.
-
Yes I’m aware of these AllWinner chips. They are quite interesting, cheap, with integrated DDR. Unfortunatelly working with chineses chips without datasheet is a no go. They are for chinese market. Also, I’m not familiar at all yet with all that linux stuff and don’t need it for now.
I want to control and understand everything, this is why I’m going little step by little. I need to understand everything and to make sure things are optimised. Now, I will need to add FreeRTOS, a fat system, and bootloader. I don’t need a more powerfull chip for that. Later, I’ll probably go for the STM32H7. Routing DDR3 is also part of the learning process.
They price increase above 100x100 but its not that critical when you go to 0.2mm holes, ENIG, and SMT assembly. It’s just a few dollars.
So here continues a little the story about the first version.
So I got the 2 boards (on photo) routed on kicad, and sent to assembly. The enclosure too. No issues with the enclosure, except with the screws. I will be using metallics inserts for the next version.
I received the boards rapidly. No issues with assembly. Now the boards are on my table, and all I have is a power supply and a multimeter. How to check for short-circuits? Connect a few seconds, finger on each component. Bingo. The SDRAM got super hot very quickly. I interverted a VCC and GND pin. So I had to cut the pin on the board.
Then, randomly:
-3.3V didn’t work. The behavior of on EN pin was not clearly specified in the datasheet. Forgot all pull-ups on open-drain outputs of LM339. Forgot the decoupligg caps on VCAP pins of STM32. Wrong VDD and Vref for the ADC. Inverted EN signal on 74HCT4051 multiplexers. Inverted pins for relays command. Some OPAs oscillating. Some AOP on analog path saturating too early. Attenuation network lacked tuning options. Mirrored FPC connector. And so on.
I finally made all the hardware work as expected. Then a long route of firmware started. I wanted to understand how all the flow works, so I started a project a simple C/C++ and without CubeMX, but on CubeIDE. I used a cheap probe with ODB2 server for debug. Played with cmake, the linker files for the external SDRAM. Wrote all the low-level drivers at register level without HAL. Made the TFT work. Then showed a BMP on it. Then started to build a simple graphics library. Then made the SDRAM work. Set up all the timers, speak with the ADC. Little by little, I made it work, optimizing step by step. Until the last photo. It still had many flaws, imprecision, but was usable to watch signals. I pushed it all to the maximum of optimisation, using all DMA I could (also DMA2D for graphics). Even pushed the 180MHz STM32 to 240MHz. Got only 2MSps, at 30/60FPS.
[attachimg=2 width=350] [attachimg=3 width=625] [attachimg=4 width=195]
Time to add an FPGA!
Now I will write about the current version with FPGA.
First, I corrected all the hardware issue (also creating a few new, of course). This version was supposed to work both with FPGA and MCU talking to the ADC, so the ADC bus is shared between STM32 and FPGA. Later on, once FPGA validated, I removed all the code from the MCU, as it was too complicated to maintain, and now it’s working only with the FPGA.
I really had no idea where to start with FPGA. But after a few days of search, I decided to go for Spartan7 because it uses Vivado and not some old software. It also supports DDR3. It was time to go for BGA as well. I also replaced the STM32 and SDRAM with BGA variant. I went down to 0.2/0.35 vias, 0.1 tracks. Everything still on 4 layers. For DDR3, I first used Vivado MIG IP wizard to understand the pin assigment. I also double-checked the schematics with some other boards (Narvi s7 from Numato Labs and CMOD s7 from Digilent).
For the DD3 routing, I followed all recommendations I could found everywhere, expecially from AMD. First, I put the chip reasonably as close as possible to the FPGA, facing the FPGA bank used for DDR3. Then, I optimized the pinout with Vivado so that lines crosses together the less possible. All signals are routed on external layers only. Each bank on its layer. Trace are 0.12mm, they have 2 to 3 width separation to avoid crosstalk. They are all rounted withing a <12ps propagation delay and <2ps for the differential pairs. All lines less than 25mm. 56 ohms impedance single ended, 105 ohms differential (I used JLCPCB stackup information). As I used only one package and frequency is only 400MHz, I use no termination resistor. Plus, I didn’t have space for this.
Everything else on the board had minor changes. Here is the global system hardware architecture:
[attachimg=1 align=left width=800]
-
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.
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.
-
did you consider a Zynq7000? it's basically an Artix7 and a cortex-A9
-
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 ;D)
-
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.
-
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 ;D
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 :)
-
Guys, please have a look at theses 3D images. Blender inside :D
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
[attachimg=1 width=700]
[attachimg=2 width=700]
[attachimg=3 width=700]
Please say it's cool so I keep posting on this forum :D
-
Well we'll certainly say "COOL", very COOL indeed :clap:
Best
-
Very impressive indeed. FNIRSI can eat its heart out. :-DD
This has the look of a professional scope and not a toy like most of the FNIRSI stuff.
-
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/
-
WOW!
(picking up pieces of my brain)
-
I want one! take my money ;D
-
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.
-
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 ;D
;D 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 :palm::-DD
-
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 :palm::-DD
More skill than I have, thanks for the project, very interesting and involved, congrats, hope the new boards go well.
-
...
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.
-
...
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 :phew:
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 :o
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
-
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.
-
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
-
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.
-
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.
-
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 ;D
-
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):
[attachimg=1 align=left width=300] [attachimg=2 align=left width=488]
-
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.
[attachimg=1 width=500]
Note1: painting in glossy black is a bad idea,
Note2: I'm still waiting for the custom stickers
-
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. :)
-
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 :-DD
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 :palm: 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.
-
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.
-
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 (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.
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++;
}
}
-
Just as an illustration of how 'register' can be used for the Bresenham line drawing algorithm.
I tried it, no improve. The CortexM7 is fast enought, bottleneck is on SDRAM access :)
I saw in your last post that you were not enabling compiler optimization until recently - unoptimized compiled code is a dead cow.
I do not enable it when I debug. It hides some variables and steps over the code and makes it difficult. When debug is over, I enable it of course.
I actually rewrote some huge parts of the code, corrected some (many) bugs and did some optimisations especially on the global state machine.
I spent a lot of time fixing all thoses bugs, especially in the stop mode, when you shuffle the already captured samples (stored in FPGA DDR3) and change timebase, probe, other stuff.. Everything need to be adapted, trace height, offsets, horizontal placement etc.
All the samples data are now in nanoseconds and millivolts, which abstracts the ADC and samples index to read from FPGA. It helps a lot.
Keeping data integrity between tasks switches, interrupts, DMA accesses and FSYNC of the screen was also no joke.
I also added the sinc interpolation for the lower timebases using CMSIS library. After coutlesses hardfaults, it works like a charm.
However, it doesn't improves that much the trace quality. Gonna have to tries different settings. But with a 10ns sampling period and a 15/20ns rise time on the scope, I doubt I can go any better.
I also finalized the calibration functions, having received a DC power supply which allows the manual calibration to be made.
That cheap power supply is a chinese DC-DC one and is incredibly noisy. It causes troubles for calibrating the smallest calibers. I'm gonna have to build my own voltage references box.
However, I could get a precision up to 0.2% for the well calibrated channels. That's awesome given I use only 234 of the 8 bits of the A/D (margin is kept for input chain errors).
It means, that I can't do any better as theses 0.2% which correspond to half a bit.
The PSU board heats quite a lot, I will have to change the inductors. FPGA also heats seriously. 200MHz everythwere is too high, but atm it's not a priority to rewrite the code for a lower frequency.
On one CPU board (out of two) when I touch the SDRAM the screen flickers. :D interesting. Also flickers the first 5 seconds after cold power-up. Probably a poor solder during manufacturing.
How hard is it to get something working 100%...
Now the scope works at 60 FPS almost all the time, even with FFT and 4 traces, with IDLE task still having some time to being.. idle.
It powers-up in less than a second.
That's a banger 8)
i'm gonna have to make a video sometimes.
Seriously thinking about making all this stuff open source when it's mature. Not for free at least given the huge time spent and so the hardware could be produced and bought.
No idea where to start and how to advertise. I'm not good a this.
Gonna need people to test it too.
Hardware must be rock solid, firmware can also be updated!
-
Update!
Note: new photos on first page + current specs.
I've been fixing countless bugs, cleaning the code and worked on the hardware.
Found why screen was sometimes flickering: A10 adress was accidentally removed from schematics. ???
The battery charges, 2 resistors were inverted.
Last version (4) is on the rails earlier than expected.
But it is too much work to go for 1GS/s using HMCAD (1GS/s on 1 channel, 250MS/s on 4 channels) so I made a compromise: 200MS/s on 4 channels.
HMCAD involves switching to Artix-7, redesing of analog stage and I prefer to stabilize current version. Also I don't like that HMCAD interleaves the channels.
Let's call it the 3.1 version, and I may stop here.
Aside correcting some issues I added new functionnalities:
PSU board:
- USB-C charging (using power delivery) replacing barrel connector
- That new USB is also routed to the CPU board for slave connection in addition to the other USB-A (STM32F7 has 2 USB OTG)
- Added battery deep-decharge protection, to disconnect the battery from BQ24610 and system under 3V per cell (reconnects at charger plug)
- Removed the hardware TFT power-on/off supply rail sequencing, will be done by firmware. Too messy by hardware.
- Added monitoring of power supply voltage in addition to battery voltage
- Corrected the TFT backlight enable command
- Remplaced the +5V inductor to dissipate less
- Added a correct battery connector
CPU board:
- Rerouted all analog inputs, high-impedance trace lenght divided by two, all caps and resistors in bottom
- Smallest vias are now 0.3/0.45 instead of 0.2/0.45 (that was a big reroute job) with 2.5H betwwen high-speed traces
- All fast traces around STM32 (SDRAM, LTDC, QSPI..) now respects 2.5H between themseves almost everywhere
- Added a passive 4th order tchebyshev anti-aliasing filter before ADC's
- Added a QPSI FLASH for STM32 (extended storage for code execution or data)
- Improved the trace vertical position schematic using dual feedback amp to prevent loop instability and oscillations
- Improved trig in and trig out traces impedance adaptation and protection
- Added two LDO's for analog supplies to reduce the noise induced by the -3.3V, added mosfets to fast cut/enable analog power when not sampling
- Doubled ADC quantity per channel (thanks to the space freed up by the new routing): now sampling at 200MS/s with a second shifted clock
- Replaced the FPGA from XC7S15 to XC7S25 to get more GPIOs for the new ADC's, also hopping for better timing closure
Note on firmware update:
Architecture will allow to programm both STM32 and FPGA using USB.
I though adding provision for touch screen control. But I have a custom glass, and I don't know how to add capacitive touch function to it.
It looks like all the current capacitive glasses I can found have default dimensions which won't fit in my design.
Will take a break and come back to schematics later.
Created a by me a coffee page. Goal: at least 5$
Here is the global architecture and the routing mess of CPU board!
[attachimg=1 width=683] [attachimg=2 width=600]
-
This thing continues to impress.
I'm always delighted to see the latest iteration.