Going back to electronic after a 20 years break

I have 2 DSO 150, one coming from the early models and one recent. The first models were sensitive to power supply voltage (calibration was changing depending on the power voltage) and to noise. This has been fixed on later revisions. The problems  come mostly  from the analog board power supply. There are some talks about it on the   Jyetech forum Let's see what we can do. The old power suppy looks like this : So the input is sent to ICL7660 inverter and the output is used 'as is", without much filtering except the 2x100uf caps. More annoying VBIAS which is used to shift the input to the middle of the ADC range is also derived from the unfiltered power supply (V+) through a 3v Zener. That raises 2 issues : Not very immune to mid/high frequency noise, i.e. if you use a DC/DC converter for example. Noise will go to the OpAMP power rails AND to VBIAS. VBIAS is not a very good ref voltage. It will change a bit if V+ changes and if temperature chan...

Debugging multi threaded program can be a real pain if you don't have thread support in the debugger. In my case, i'm debugging the STM32DUINO_DSO firmware which have ~ 4 threads running on top of FreeRTOS 10.2 I usually use my blackmagic, but it seems having it support FreeRTOS is not coming soon. So back to stlink v2 (cheap ebay clone) and openocd The openOcd version provided by ubuntu is recent enough, good. 1. openOcd configuration file Let's create a new profile for the bluepill, just activating FreeRTOS support.     cd /usr/share/openocd     cp  scripts/target/ stm32f1x.cfg   scripts/target/bluepill.cfg   sudo vi  scripts/target/bluepill.cfg There is only one line to change to activate freeRTOS support Look for $_TARGETNAME configure and add " -rtos FreeRTOS " just after configure i.e. line 47 becomes  $_TARGETNAME configure -rtos FreeRTOS -work-area-phys 0x20000000 -work-area-size $_WORKAREASIZE -work-area-bac...

The default toolchain when using stm32duino / RogerClark is the SAM one available in the arduino repository. It is a bit old : gcc 4.8.3 2014 Let's build the DSO project with some toolchains, and see the effect on the flash size consumed. (/!\ The compiler options were not changed and could be sub optimal for some compilers, it is to get an idea of the gain without spending time on it) SAM / 4.8.3  : 114 kB Platform IO 7.2.1 : 118 kB stm32 8.2.1 / nano :  58 kB Damn !, the 8.2.1 is about half the size. It is pulled from  https://github.com/stm32duino/arm-none-eabi-gcc.git, and used in nano mode (--specs=nano.spec) A couple of gotcha though: The __always_inline_ macro is defined in a different way, which ends up with a "doubly define inline" error. The fix is easy  :  edit   ./arm-none-eabi/include/sys/cdefs.h,  go to line 380 and remove the __inline__ i.e. it should now be                 ...