DSO138mini compatibility?

[zxfr]

It is not an issue, but a question: is the firmware compatible with DSO138mini ?

If not, do you have an idea, what differs DSO138mini from DSO138? (from firmware development perspective)

[Quas7]

The mini features the same controller STM32F103C8T6. As the stock firmware is available as backup, flashing and testing should be no real issue. I will check this out in the coming days.

Sidenote Based on the JyeTech website [https://jyetech.com/dso138mini-oscilloscope-diy-kit/], the PC interface is already included in the stock mini firmware:

Serial output of waveform data. Captured data can be saved and displayed by PC. Here’s an example of a captured single byte (0x35) sent from a serial port at 115200bps and the same waveform displayed on PC using Gnuplot.

[zxfr]

The mini features the same controller STM32F103C8T6. As the stock firmware is available as backup, flashing and testing should be no real issue. I will check this out in the coming days.

Sidenote Based on the JyeTech website [https://jyetech.com/dso138mini-oscilloscope-diy-kit/], the PC interface is already included in the stock mini firmware:

Serial output of waveform data. Captured data can be saved and displayed by PC. Here’s an example of a captured single byte (0x35) sent from a serial port at 115200bps and the same waveform displayed on PC using Gnuplot.

Despite the same controller DSO138mini and DSO138 firmware is obviously not the same as the schematics/pin connections differ. In the meantime I found answers to my DSO138mini dev questions by the project https://www.hackster.io/phillowcompiler/dso138mini-diy-oscilloscope-kit-game-console-d9c93e

[morganflint]

It is not an issue, but a question: is the firmware compatible with DSO138mini ?

If not, do you have an idea, what differs DSO138mini from DSO138? (from firmware development perspective)

I see the answer is not needed now, but in case it helps others interested in adapting the code to DSO138-mini (something beyond my abilities :-( ), I'll try to explain the differences between both from a HW perspective.

Looking at the schematics, the main differences are related to the trigger circuits. In DSO138 there is a circuit around U2D which compares the voltage generated (PWM) from pin PB8 of the MCU with the analog signal and generates "HW trigger" to pin PA8, while in DSO138 mini this circuit is missing, as its function is done via FW.

But the same thing happened between the first and the latest version of DSO150 but, regardless of this, the former HW versions can run the newer FW versions (not the opposite), as the FW simply ignores the HW generated trigger. I'm not sure if in the latest official FW versions for DSO138 the same approach was taken (FW trigger generation instead of HW, ignoring signal at PA8).

So, to answer the question, it mainly depends on how DLO-138 handles the trigger, either via HW (pin PA8) or via FW. I haven't analyzed the code but, looking at the modded schematics on the first page, to implement external trigger, DLO-138 uses PA8, so we can deduct DLO-138 triggering wouldn't work on DSO138mini, unless we recreate the circuit around U2D (there's a "free" op-amp in the Mini, U1C) or feed an external trigger to PA8. The alternative would be to write code to produce triggering from the signal input, as in DSO150.

There are other differences: 1.- CPLSEL goes to PA3 in DSO138 and to PA5 in mini (this should be easy to correct in DLO-138 code) 2.- The buttons go to PB12-PB15 in DSO138 and to DB4-DB7 in the mini (this also should be easy to correct in DLO-138 code) 3.- The ports used to control the LCD are also different (this also should be easy to correct in DLO-138 code) 4.- PA8 is connected via a resistor to PA5 in DSO138-mini to modulate the test signal (PA7) amplitude and (as said before) as trigger input in DSO138 so, unless we lift R38 in DSO mini, we would have a signal related to v- generation (see next point) when using DLO-138 FW in SDO138 Mini. The test signal in DSO138-mini is generated al PA6, used as feedback to V- in DSO-138. This should be changed in the code of DLO-138 5.- DSO138 has a circuit around q1-q2 to generate a negative voltage (V-) FW controlled from PB9 and with feedback to PA6 (Mini does this with specific HW, so no FW is needed). As PA6 is used in mini for the test signal, this would have to be redirected to an unused pin in DLO-138 (or remove all the V- generation associated code)

To summarize, lots of differences in pinout (i think easily corrected in FW) but also HW differences in triggering that would need to modify the HW or write some new code to implement triggering via software.

[marius137]

I tried porting it to the DSO138mini and can confirm that DLO uses hardware triggering. Also, the Display seems flipped on the mini.

If anyone is more knowledgeable than me in that stuff, feel free to contribute over at my fork

[morganflint]

I tried porting it to the DSO138mini and can confirm that DLO uses hardware triggering. Also, the Display seems flipped on the mini.

I also had the "flipping issue" (and also color palette related issues) when trying to port "DSO138mini Space Invaders" to DSO138 old version (more or less the opposite that you're trying to do now).

I could solve it thanks to phillowcompiler's advice as you can see here: https://github.com/phillowcompiler/DSO138mini_Sketches/issues/2

As you can see there, this issue is related to the control registers of the display and should be easy to correct also in your case.

Hope you have luck with the rest of the issues!! (mainly, generating trigger via software, doesn't seem difficult but will require writing some new code)

[marius137]

I also saw that page in the datasheet, however I can't figure it out how to (un)set said bit. the Library used for the display is kinda hacked up and doesn't provide a function for changing the control Register and the lack of a debugger in the arduino IDE makes this frustratingly hard to implement.

A much bigger problem is that the Display shares some pins with the buttons, so you would need to either rewire the buttons or disable the display while reading buttons (which would also result in a lot of extra code).

[morganflint]

Ok. Curiously, I didn't find (or relate) any issues with the buttons sharing pins with the display when running the space invaders in DSO138 but, thinking of it now, maybe the flashing lines I mention here could be because of that