Alternative dso firmware [Application Software Design Entry]


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.

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=“https://github.com/gabonator/DS203/blob … GpioTest.h”>https://github.com/gabonator/DS203/blob/master/Source/Gui/User/GpioTest.h</LINK_TEXT>