Alternative dso firmware [Application Software Design Entry]

True. He has created a bios class that bifurcates the system functions depending on target platform.

However, my curiosity stems from the enormous amount of labour that is needed to code a GUI bottom-up. Writing every class, widget etc, needs a lot of effort. I tried loading his VC++ project but could not see the screens. Maybe I am missing something because I use VC++ 2005. The event driven framework sure makes the entire project very responsive which is what I am trying to understand. I am an Ultimate++ (U++) coder and it too has the entire widget framework needed and is multi-platform. How does one target that GUI to an embedded system like the STM which it may not support directly? Things like fonts come into play too.

That is why the request.

I see nice lively discussion here :slight_smile: If you will find some bugs, keep posting them here. Unfortunatelly I do not have time right now for fixing them, nor for recording any screencast. So please be patient and wait for weekend :slight_smile: Besides my work as full time programmer I have also academic duties and if I will fail with my PhD. thesis, remember that it will be your fault! Fault of everyone of you who keep me motivated to work on this amazing project :slight_smile:

Hi Gabriel

Thanks for that sliver of hope to see a screencast sometime. Hey, good luck with your thesis and I hope I won’t be responsible as I am in far off India. :wink:



Good luck with everything.

I looked over your code and it looks like it would take a lot of rewriting to separate displayed range from the measurement display. Its something that I may attempt, as I feel that is the biggest design flaw that has been there since the DSO was released. I think it may be possible that the designer never used a scope before.

c.wilt, what exactly you mean by “separate displayed range from measurement display”? If you think it could be useful, please describe it more deeply, or post a image…

Every scope I have ever used has always auto ranged the measurements independently from the waveform display scale. For example we want a measurement of Vp-p but we want to zoom in on the rising edge to look for overshoot, ringing, etc. I can input a 30v p-p wave to my bench scope. Display the wave at 100mv per division to look for oddities. Push the the measure button and get a reading of 30v p-p even though it is off the scale of the display.

With the current DSO quad software everything is linked. If I feed it 30Vp-p and have the scale/resolution set to 100mv the measurements are wrong because the ADC scale is set to 100mv and therefore the measurement overflows the ADC.

Does what I am saying make sense?

I caught an implementation boo boo with this. Ch1 is measuring Baud and I change the setting by mistake to MATH.


The problem is now fixed. It was caused by setting the measurement input to Math while the Math calculation was turned off (oscilloscope/math/operator = off), now the application automatically adjusts the math operator to A+B+C mode when turned off.

Thank you very much

I know I promised not to add new modules, but I could not resist :slight_smile:

This time I was playing a little with GPIO. I wanted to make a simple application communicating with popular DS1820 thermometers. These devices are small integrated circuits in TO92 package and the protocol they use is called “one-wire” bus. You only need single pin to write&read from them. Because I already have a UART connector accessible from outside I wanted to share the TX pin for this purpose. I added few functions to my BIOS implementation to control and read from the GPIO pins. ARM M3 MCUs have internal pullup resistors, so you can directly attach the thermometer on the four pin UART connector (PIN1->GND, PIN2->TX, PIN3->VCC) and the application will show the device ID, scratchpad contents and also the temperature with 1/16 of C resolution.

The source code can be found here, there is a nice implementation of pin control in class CPin:

<LINK_TEXT text=“ … GpioTest.h”></LINK_TEXT>

Joined the forum specifically to thank you gabonator !

I received my DS203 the other day and was perplexed by the Factory firmware. After a quick bit of searching your name kept popping up, so I took a look here, liked the ‘lifestyle’ type of easy on the eye look to your firmware and the functions. Plus, that you obviously spend a heck of a lot of time on the project. Installed it, ran it and the DS203 was scoping away til I thought to charge the battery !

Again, thanks so much…brilliant work !

As a bug report and hopefully useful bit of info not crtiticsm…the Square wave in the generator seems to often start with a display of 36MHz, but then will drop down as though at the 9MHz top speed. It goes straight into the 8MHZ ranges from that errant 36MHz.

Also, I noticed a spelling mistake on one screen, will try to find again, but something small like ‘triger’ instead of ‘trigger’.

Hello gabanator,

I’m new to the DSO203/Quad, received one last week - but was reading this forum previously.

The improvements you, jpa and pmos69 made to this small piece of hardware are really great. This shifts the possibilities enormous.

I’m impressed by your newest modul, the connection of DS1820 one-wire thermometer chips.

Which steps are nessesary to have the UART connector accessible from outside? (my DSO have a aluminum alloy shell)

Many thanks, your work is very helpful!

Sorry for my bad english.

Hello Thomas,

here is a tutorial how to make the UART interface available by drilling a small hole to the plastic casing and placing there a 4-pin connector. I think there wont be much difference with the aluminium shell. Maybe you will find a less invasive method that does not require drilling, but I can’t help you with that since I have only the plastic version of DSO.

<LINK_TEXT text=“ … rialOutput”></LINK_TEXT>

Hello Gabriel,

thank you very much, that’s a fine documentation of the modification.

I’ll read it many times to understand it fully, and than give it a try.


Hello guys,

if you really like my work, please consider becoming a judge in the DSO QUAD competition and vote for my project :slight_smile: This competition ends in only 3 days!

Hello Gabriel

I am thinking aloud here.

Since we have a frequency generator, it would be possible to sweep the frequencies. This in turn could be used to build a module to check inductance / capacitance / LC. This will enable RLC functionality for the DSO.

The swept frequency could also be used to do frequency characterisation curves (response curves) for audio equipment.



ps: this pdf has some ideas to use the PC sound card.

<LINK_TEXT text=“ … ter_EN.pdf”></LINK_TEXT>

And some code from another source

<LINK_TEXT text=“ … asurement/”></LINK_TEXT>

Already done, twice actually. :slight_smile:

<LINK_TEXT text=“ … y-Response”></LINK_TEXT>

The result of DSO Application Software Competition has come out! :lol: <LINK_TEXT text=“ … -came-out/”></LINK_TEXT>

Congratulations gabonator1! I will email you for more detailed information soon:)

Congratulations Gabriel. You truly deserve the honour.

Congrats Gabriel !!

Looks like you’re gonna have a metal case DSO Quad after all :wink: