Would you advice to use master branch or 1.05 release ?

[belotv]

Hello mean00 and thank you very much for your great work.

Sorry for hijacking the issue page but I could not find any other way to contact you.

I intend to use this firmware on my DSO150. Do you consider the master branch to be stable ? What are the main differences ? Should I go for 1.05 or wait few more weeks instead ? I noticed some changes related to ADC in the last commits.

Kind regards,

Valentin

[mean00]

The master branch is using timers as sample rate instead of duplicating/ dropping samples, which is more accurate.
It is slightly less stable than the last release but the timer changes make nicer/better waveform

My advice would be to :

• start with the latest release to see if it works ok for you without hw mod
• If so , do the rotary encoder mod, it changes completely the responsiveness of the UI. the stock hw is barely usable.
• Test master if it is ok for you, at worse you can go back to last release

I'm using master and only have problems with very high sampling rate (5us/div) where it becomes really unresponsive

The last ADC changes are to make it a standalone module, reusable easily for other projects.

[mean00]

Small warning : master is no longer using a bootloader. That was what was creating crashes at boot sometimes.
So if you go back & forth between release and master, dont forget to put back the bootloader.

[belotv]

Thanks for the info, it is indeed something I have to know.

Do you intend to add digital channels like OpenDSO150 ? It would be a really appreciated feature to debug hardware (at least one on PB13, as you are using PB14 and PB15 for the rotary encoder). We would need to add a zener like 1N5226 + resistor to protect the port and handle 5V logic though.

[mean00]

The main problem is synchronizing the ADC with the digital inputs.
The ADC is basically doing things on its own until it is triggered

it is difficult to use another ADC pin for "digital" signal as they (adc pins) are all used already
It should not be too difficult to make it a 2 analog channels scope, but you'd need to rewire all the buttons
An elegant solution would be to use a I2C/SPI IO board so that you can control plenty of buttons/switches/... with only 2 ..4 pins freeing the other ones . Speed is really not an issue for those.

[belotv]

It would be an elegant solution for sure but it is also quite a complex hardware change. As PA7, PA15, PB12 to 15 are unused (- 2 ports used for the rotary encore fix), it would be really great to have some digital channels.
I understand that syncing with the ADC is quite challenging. One mitigation could be to only provide these digital channels only at "reasonable" timescales.

Also, have you tried run STM32F103 at 128Mhz ? Apparently it works quite well with a PLL of 16, the only drawbacks is that it is not possible to use USB due to the available dividers. It would avoid CPU replacement to GD32F303 and improve ADC performance. USB is not used anyway and even if you want to provide data export, it could be doable through serial port.

http://amitesh-singh.github.io/stm32/2018/06/17/overclocking-blue-pills.html

Just proposing some ideas to get the best out of this scope with limited changes. I think your firmware is far better than the default one or OpenDSO150.

[mean00]

Interesting ideas, the digital ones could be used as triggers also. I'll look into that later on.
Short term wise, I'd like to have a better trigger that what is done today. If it triggers at the beginning / end of the buffer you will not have a complete waveform.

If that makes sense, i can make the change so that the STM32 is optionnally overclocked to 128 Mhz, it's not difficult to do.
On the other hand, will it work reliably ?

BTW, the GD32F3 has other nice things. For example it has hw based sample averaging, so you can get cleaner output by oversampling by a factor of 4 for example. For free.
It also have 256 kB of flash, and is faster than the STM32 at the same clock speed, because it actually copies the flash to its ram so you have zero wait state "flash". It also has a DAC (limited to one pin though). I like that chip a lot.

[belotv]

Regarding overclocking temperature is less than 30 degrees Celsius even at 128Mhz. Nobody complained about stability issue so proposing the option would be really great. Replacing the oscillator some people even ran the CPU at more than 200Mhz replacing the quartz without issues.

Seeems that better GD32F3 is indeed better but I think that supporting the default hardware is better if you want to attract more people around the project :)

[mean00]

you can try this on head:
cmake -DMCU_SPEED=128000000 xxxxxxxxxxxxx
Only 72,96 and 128 Mhz are supported
Seems to work fine as far as the ADC is concerned on mine

[belotv]

Ok, will try once I receive my new ST Link V2 flasher. Just a quick question. Why the spreadsheet indicates use 96Mhz!!!! in yellow ? Is there any issue you noticed with 128Mhz ?

[mean00]

96 Mhz is for the GD32, with USB
128 Mhz is for STM32 without usb