Alternative dso firmware [Application Software Design Entry]

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 :slight_smile: 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 :slight_smile: 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 :slight_smile:

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 :slight_smile:

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 :slight_smile:

Sweet! :smiley:

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.

Gabriel



A request - I’d like to see a video / screencast of your development platform. I am trying to understand how you did the GUI coding. Is this some canned framework that is pulled into your code, is it something you wrote bottom-up. I am very curious. Please consider this request positively as I am very eager to shift from coding the superloop style to event-driven / rtos driven type.



Best

Jerson

I agree that the structure of Gabriel’s system appears very neat. If I have understood correctly, he has a internal API for the hardware access. He can then compile the same C code on the desktop under Windows and test it there before testing on the DSO.



I have thought about doing the same for QuadPawn, but I don’t think I’ll bother to do it anytime soon. I have a simple script for quickly deploying code to the DSO, and some helpers for debugging it there.



As for the GUI system Gabriel is using, I haven’t had time to study it yet but it would be very interesting to hear more about it.

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:



Cheers.

Jerson

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.

[attachment=0]SDC10030.JPG[/attachment]

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.