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 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
I will test it shortly. Combined with the pawn apps I am working on the DSO is starting to become useful.
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.
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.
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.
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.
I see nice lively discussion here 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 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
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.
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.
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.
I know I promised not to add new modules, but I could not resist
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:
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’.