Ok, I think this is the right time to join the competition officially. Most of you probably know, that there is a firmware that was focused more on clear and simple user interface instead of reliable functionality. Last weeks I spent a lot of time improving this firmware. It is still not perfect, but it offers a nice set of features:
UART decoder - with automatic baudrate calculator
CANBUS decoder
MIDI message decoder
Mask tests - simple PASS/FAIL test, feature that is present mostly on very expensive devices!
Export to SVG - interactive graphs!
Export to WAV - open it and examine it in any sound editing program
Three operands mathematical operations
Precise chromatic tuner - frequency counter with 0.1Hz accurancy with nice visualization
Spectral analysis
Wireless connection with android device for remote control of DSO (with complete tutorial how to add serial port and attach bluetooth module) + including sample project for android in java
Snake game 
Serial port monitor
I was planning to add more features, but today I ran out of RAM memory, so I will focus more on fixing some bugs instead of new features from now. I would like to thank Petteri Aimonen (jpa) who found out that there is extra 32kB ROM in STM32F108 microcontroller, this allowed me to embed nice images and icons into the firmware
I would like to thank following guys for reporting bugs, ideas and improvements:
Frederic Borry - for implementing better navigation, and better oscilloscope grid functions
Jose Zapico
Dave Robinson
… and for everyone else who I forget to mention here
Here is a github page with screenshots of this project:
https://github.com/gabonator/DS203
Raw firmware can be downloaded here:
<LINK_TEXT text=“https://raw.github.com/gabonator/DS203/ … P_G251.hex”>https://raw.github.com/gabonator/DS203/master/Bin/APP_G251.hex</LINK_TEXT>
And merry christmas to everyone
Gabriel
It is my first Christmas gift…
Thank you and merry Christmas Gabonator
Hi
Thank you for the great job.
I do have a problem though.
I have download firmware from link
raw.github…
The hex file is 407KB. The uppgrade went OK
After that i have downloaded the hex from
github…master/Bin
the file is 1.118 KB
I can not tranfer it to DFU folder i get an error of not having enough space to make the transfer.
(My DFU is only 492KB)
You are probably at this address:
https://github.com/gabonator/DS203/tree/master/Bin
and you right-clicked the APP_G251.HEX to save it to your HDD. This file is over 1MB, and when you look inside it, you will see that it contains some HTML code. This is probably bug in github, because it offers you to save the file as “APP_G251.HEX”, while the file is actually a web page and not a real HEX file…
To download the HEX file from github, click on APP_G251.HEX with left mouse button and then click on “RAW” button on top right. Only after this step you can save it by clicking on File->Save as… or pressing CTRL+S
Loaded your firmware last night and started calibration. Excellent contribution, thank you.
I see there is a user app section. Is this based on jpa’s pawn? If so how do I load my apps?
Thanks, again.
No, I am sorry because the user apps are in object oriented C++
See the “Sierpinski triange” sample code for reference:
<LINK_TEXT text=“https://github.com/gabonator/DS203/blob … eenSaver.h”>https://github.com/gabonator/DS203/blob/master/Source/Gui/User/ScreenSaver.h</LINK_TEXT>
After making your own module, you need to include it in _Modules.h file (and in _Modules.cpp when your code has cpp file, but for simple experiments you can place your complete code inside single .h file)
I haven’t checked, but I have just a hunch that there may be 16kB of more RAM lurking in there also
Going by the discussion of memory constraints I assume there is no way to have both the alternative firmware and pawn at the same time?
Installed at the same time? Sure, should work without problem.
Running at the same time? Probably not, because RAM is so limited. Also I’m not sure if there would be that much benefit. Most of the applications I have made with Pawn so far are designed to run stand-alone. One might think about extending gabonator’s firmware with Pawn scripts, but then we would have to wrap all the C++ interfaces etc. Probably easier to extend it using C++ directly.
On another note, I have been thinking about the possibility of loading separately compiled C/C++ modules to RAM and running them. That would make it possible to have high-speed extension modules for the Pawn language, and also to load dynamically extensions for other firmwares.
I tried but could not get them installed at the same time. Have you tried? If you got it to work what order did you load it in?
I expected that they would not run at the same time. Just being able to switch back and forth is all I am looking to do. I have a few pawn scripts that read sensors that come in handy. I like very much the new firmware but hate to give up pawn for it.
That could be useful too.
Tonight I added bluetooth to my DSO quad but I used a bluetooth mate gold which is based on roving networks RN-41. Loaded the example android app and everything is working. Would like more info on the serial commands returns if possible.
c.wilt: Wow, great work!
Regarding jpa’s pawn & my firmware installed on the same device - this is not possible, initial idea was having multiple applications installed on DSO flash and by holding some button when turning on, you could choose which one you would like to boot. My firmware is so huge, that it occupies whole flash, even some part of the extended ROM So when you install my firmware, you should not install any other application to the slot 2, 3, or 4, because it would overwrite my firmwares code.
jpa: can you tell us some more details about the extra RAM ? I am very curious Anyway, I was looking on the ST webpage looking for pin compatible processor with bigger memory:
http://www.st.com/internet/mcu/subclass/1169.jsp
the package is LQFP 100, the microcontroller inside dso quad is STM32F103VC and the STM32F103VG has 1MB flash and 96 kB RAM
And also the very small EEPROM should be replaced with SD card, because 2MB is horribly small disk space in era of terabyte disk drives
If I had more memory and reliable disk drive (the FAT implementation in DSO is buggy) I would like to put some javascript or lua interpreter into DSO, this would open new world for user applications. Your PAWN implementation is nice, but the main disadvantage is that you need to compile your code at PC side.
I imagine, that I am editing user application file from the DSO drive written in javascript in any editor and after saving this file, the DSO would recognize that something was changed, its firmware would reload the application and start executing it.
And the bluetooth commands:
<LINK_TEXT text=“https://github.com/gabonator/DS203/blob … Sdk.h#L480”>https://github.com/gabonator/DS203/blob/master/Source/Core/Sdk.h#L480</LINK_TEXT>
Inside Sdk.h there is a function getTokens which returns all available commands. Some commands can be used with different set of parameters, for example:
GEN::Output(1024); - sets the WAVE OUT DA converter value to 1024
GEN::Output(2.2); - sets the WAVE OUT voltage to 2.2V (important to calibrate the DAC first)
Print(“Hello”);
Print(20, 20, “Hello”);
for getting CH1 resolution:
CH1::Resolution;
or
ENUM::Ampl(CH1::Resolution);
and for changing:
CH1::Resolution=4;
After this change you should setup the adc and trigger by calling “ALL::Setup();” and redraw the screen with “Update();”
Every command needs to be ended with ; and enter (\n)
Its not very pretty yet, but it does work.
I assumed as much. I would load your firmware and made sure it worked. Next I would load jpa’s pawn. Your firmware would not boot but I could hold button 4 and boot to pawn.
If your going to edit your app on on a PC anyway, you might as well have it compile the code and make it faster.
Maybe I can use these commands to recreate my pawn apps on my android tablet. Would it be hard to add commands?
Oh, I did not know this.
How large is it? The extra flash is 256kB. I’m using 32kB of it for AlterBIOS.
So if you can fit your firmware in:
0x800C000 to 0x801BFFF (APP1 & APP2, 64kB)
0x804C000 to 0x807FFFF (Extra flash, excluding BOOT & SYS shadow areas, 208 kB)
That would be total of 272 kB, and it would not conflict with my Pawn nor Logic Analyzer.
AlterBIOS fixes the bugs:
https://github.com/PetteriAimonen/AlterBIOS
It transparently patches the bios so it works (should work) for all apps. If you don’t mind requiring it, you can also use the fatfs interface directly instead of the crappy bios functions.
Yeah, a stand-alone implementation would be nice. But the RAM on the DSO Quad is very limiting in this regard. Anything dynamic like Lua or Squirrel seems to require atleast 100kB of RAM to do anything useful.
I have AlterBios loaded and the other firmware. Have not noticed anything wrong yet.
I went through the calibration process and I see that you had suggested an input of 4x the level being adjusted. Standard firmware suggests 5x and I used that. Seems to have worked ok but I keep noticing a common theme. It does not matter what firmware or calibration process is used Ch A is always less accurate than Ch B. Anyone else notice this?
New firmware is available - it occupies only APP1 slot and everything else is placed in the 200kB extra rom as jpa suggested. Now you can install my app together with jpa’s pawn & logic analyser. I did not test it yet, but I hope it will work
Sweet! 
I will test it shortly. Combined with the pawn apps I am working on the DSO is starting to become useful.
Edit:
I can confirm that it loads properly. Currently have your alternate firmware in slot 1, jpa’s logic analyzer in slot 3, and jpa’s pawn loaded in slot 4. Everything appears to be working normally.
I just noticed something odd in the signal generator. When I select DC output there is only offset adjustment and no direct voltage output control. If I change the offset it does vary change the output but there is a problem. At 95% the output voltage is 2.707vdc and at 100% it goes to 58.25mv dc which is the same as 0%. It may have been like that before but I did not look at it.
I would also like to see an off setting for the generator.
Along with the above I also found a bug in the RMS calculations that causes several volts drift over only a few minutes. I wonder if the same function is used during calibration process.
I have another suggestion. Make the voltage measurements auto ranging. Independent of the display range chosen. This would solve the complaints about voltage readings being different at different ranges and still allow the user to change the scale of the wave form being displayed.
You are probably already tired of hearing my suggestions.