I wanted to try it out (and maybe even help to improve it if I like it - I’m a programmer), but couldn’t.
First, I cloned the git repository. Then I copied .hex file to my DS203, it was renamed to .rdy. But nothing happened. That is, current firmware in the device was not overwritten: everything works like I did not try to update the device with completely different firmware. Very strange. I tried many times of course. With all other firmware (standard, marcosin’s, and my own) everything works correctly, and always updates perfectly.
Then I tried to compile:
% cd Build/arm_linux
% make
make: *** No rule to make target `BIOS.o', needed by `all'. Stop.
Obviously, I’m using Linux.
I also tried with linux, specifically ubuntu 11.10 64 bit. The original thread was “DS203 development on Win32 platform” under the tech support section. So I suspect the linux stuff is really just junk in the back ground, and probably won’t work with out some additional efforts. I have XP, but with a full HDD, so I tried using WINE on a Ubuntu box that did have space, but no dice.
Liss, can you try the WINE approach, I suspect it’s a minor config issue with WINE. It’s been a while, I forget how to step through bat files.
Liss, I did my firmware upgrade with a XP box, and it worked fine for me. You should have the same files I have, so perhaps there is a bug in the linux DFU process. Perhaps try again, even though it noted .rdy. I think it’s not fully ready unless you unmount the device before you pull it from the USB. I could not get the Linux DFU to work for me, but that’s largely because I got lazy and used the instructions for windows.
Can you post the file size of the firmware you tried to install and more notes about the install process? Do you know what FPGA firmware and such you have? I had successfully uploaded the 2011-11-15 found on this page seeedstudio.com/wiki/index.p … mware_List I had macrosin’s installed just before I installed this one.
Please see below how I do it, it should work for you too. It works perfectly for me for updating firmware (however, for updating FPGA you need traditional mount-cp-umount).
Could you please check, does sha256sum of my .hex match yours?
% cat /etc/mtools.conf | grep -B1 DFU
drive d:
file="/dev/disk/by-id/usb-Vertual_DFU_Disk_4ÿ_d2K88X__C-0:0"
[/code]
And, as I have said in the previous message, I tried many times. Since with any other firmware (compiled by me or others) it works in 100% of cases I guess there is something wrong with the .hex in the git tree, or my DS203 somehow different.
Today I have tried on Windows, when I copied the firmware in the DFU disk, Explorer automatically closed the window. Nothing happened, firmware did not update. Then I did the same for standard firmware AP1_B252.hex, Explorer automatically closed the window again, and it worked. So, this proves for sure OS is not the problem here. I get the same result in both Linux and Windows.
I also tried with traditional mount-cp-umount (and then mount-ls-umount to make sure I got .rdy). Nothing worked.
My FPGA version is 261. I’m sure it is 261 because it behaves differently than 222 (which I tried before updating to 261).
But inability to compile the firmware is another big problem. Even if update worked, I need to compile it to be able to improve it. And according to its README it definitely needs a lot of work. But standard firmware also needs a lot of work, so I thought maybe gabonator’s firmware is better place for a start? Its unfortunate that it does not work.
Yes, you are right. I examined provided Makefile and it looks useless because it expects .c (in both “.c.o” and “.cpp.o” rules) and .S files in its directory. But even if I copy all .cpp and .h files to its directory, and correct rule for “.cpp.o” (it should look for .cpp not .c files) - I still get the same output. So basically there is no Makefile. What’s the point to include in the git tree junk like Makefile which cannot work?..
Since I’m not familiar with the project, and never created Makefiles manually (because I use cmake for my projects), its not really obvious how to compile it.
Since it does not work, there is no point because I do not know how to debug .bat files (actually, its even worse: I do not know anything about .bat files except they are scripts interpreted by cmd). By the way, Wine’s cmd still needs a lot of work (I know because I’m subscribed to Wine’s mailing lists, and I contributed some patches to Wine, helped to fix some bugs), so it may not work at all no matter what you try.
And I need it to compile in Linux (without Wine, virtual machines, etc.) anyway, because this is where I develop the software. For now, I’m stuck, because even precompiled .hex does not work.
Yes I get the same check sum. Do you know how to get the boot loader firmware number? That’s about the only thing I think think if that might be different from the two. When I do it with explorer, it comes back as expected for me, so something certainly seems wrong.
I’m reasonably ignorant about how the boot loader works for the quad, but perhaps something crashed and is being held in that state. Perhaps pulling the battery and turning the power switch on, then off, such that it allows the bulk caps to discharge, might reset something. I doubt it, but might be worth a try. Does seem odd to me. Boot loaders don’t typically get effected like that but who knows, seems like a fairly easy and short to try as a stab in the dark.
It looks like there are several potential DFU boot loader options out there. I wonder if this DFU is the same or really close to one of those. Perhaps it’s a known bug of some sort, and has forum posts or such that might help shine some light.
I see the ISP header is there. I seem to recall that about any TTL 232 adapter can program via that port, so you could probably force it that way with flashmagic or equivalent. I’m guessing you wouldn’t want to do that any time soon.
Thanks for the script, I’ll try it the next time I upload a firmware.
First, Thanks so much for the UI. I was scared my quad was going to be totally unusable at first.
Is there a calibration procedure in this software though? I noticed mine was off quite a bit.
I’m getting the toolchain going on Linux, and I’ve found a few bugs in the summon-arm-toolchain code.
More specifically, some libraries need to be manually installed. In Fedora, they are (at a minimum):
gcc, c++, xforms, gmp, mpfr, mpc, libmpc2, termcap, ncurses, in their full (i.e. *-devel ) forms.
Note especially that mpc is in flux right now; the most recent version of mpc requires a version of
mpfr that is not yet in the standard Fedora repositories, so I had to drop back to mpc 8.2 (installed
from the mpc download site). At that point, you can give ./summon-arm-toolchain a try and see
where it complains.
Note also that I had to comment out the download of newlib via ftp from sources.redhat.com and
install it manually as ftp was broken on that file but http worked. Bizarre, I know.
So, what’s in SYS, and what’s in APP? Where should I start?
(also, I’m thinking that I want a UI that has only six dropdown tabs, one for each pushdown
switch on the 203 including the two under the rockers, and then the rockers always do the
same thing - left rocker scrolls down the options, right rocker selects a value for that option.
I’d say just four dropdowns, but that’s awfully limiting. Pushing a rocker always switches
to that dropdown tab. If no tab is down, the left rocker controls voltage scale, right rocker
controls timebase scale.
Or something like that. I’m still thinking. And wishing the DS203 had a touch screen.
Last I understood, the holidays and career were time constraints that made it hard for him to work on it.
Perhaps a VM of a windows machine would work out for one of you folks in Linux land. I just installed Win7 64bit on ubuntu with VMPlayer, it worked great. If there is interest, I might be able to allow remote access some how.
When you convert the line endings of the hex file to DOS style (CR/LF) it works.
Nice GUI by the way. It finally makes the scope usable. I think the project should keep things as simple as possible, not many features. But whatever is implemented, make it EASY to access.
I am impressed by your interface - I have used the quad in a classroom situation but the interface is not intuative - only problem is the single space available for additional programs and I love the freq response app - maybe i’ll have to get a second Quad
cheers
Don
Pros
-The controls and display are SO intuitive and easy to use. Just perfect.
Cons
-Can’t start the calibration script
-Measurements are not working
IMHO this is a great app for signal visualization as the controls are quick and easy. However I’d use Marcosin’s software suite for pure “measurement”. If the cons are sorted out, this would be the definitive app and I would even gladly pay for it. Let’s drop a donation to gabonator ^^
Any update on this work you’ve done? I absolutely love the code and use of C++. Makes it so much more intuitive. It still needs to add a few features like Calibration, Save/Recall waveforms, FFT maybe, Point/Line interpolation of waveform. But, the UI is smooth and responsive. There appear to be some issues like windows getting under the OscGraph window esp. when choosing analog settings and pressing Key1 again instead of Key2 to exit.
its hard to believe, but two weeks ago I started working on this project again. I have made some improvements, and also implemented remote control of DSO from PC. It is using javascript/html, so it should be simple to anyone to start experimenting with DSO remotely.
Currently I am working on the calibration process, but it is more complicated than I thought. At first I have used linear transformation for the ADC values, but it was not sufficient. Then I used calibration curve (6 points linear approximation), it worked perfectly, but when I changed the vertical position, it was messed up.
Is here anyone who has some idea how to calibrate the scope? In the original source codes, there is only linear transformation, but it produces big error…
It is really good news to see you back in the forums.
I have been making intensive use of your app/interface for many purposes and you made it: the device is useable, simple and neat. There other developers focused in measurement accuracy/reliability but IMHO the device has to be easy to use also.
There are BASIC features that need to work fine before thinking of things like X/Y mode or FFT analysis.
My priorities with this device are:
Ease of use -> DONE
Readings accuracy
Rest
So I am really pleased your next aim is to fix the calibration issue.
I cannot help with the code as I am not familiar with these devices, however I can help with beta testing (test on real devices, not just lab tests with signal generators).
Regarding the CALIBRATION.
Is there any way to access the calibration subtask from your app? If I could start the calibration task I could run some tests and get linearity curves and so.
If not, could you make an app release with that feature so we can give it a try?
It is clear that a single compensation point is a joke as the device is not linear at all.
Are you using 6 compensation points for each grid? (V scale)
If it is working fine without moving the Vpos I think it is a good achievement for now and it is worth a try.
and thank you for your posts, it is a big motivation for me to continue with this project, when I see more and more people involved in my project. Some posts were about the compilation on linux platform. I can’t remember exactly, but the script “arm_linux/Makefile” and necessary changes in “common/build.mk” were done by some guy here on this forum. When I am looking again to these files, it seems there are some errors like wrong slashes, and so on… Unfortunatelly I am not keeping the linux build scripts up to date, because I don’t have a linux machine to test it. It maybe needs some light changes, so if someone finds out what to change to get it working, please let me know, or push me a request on github with your changes.
About the line ending. I thought that github autmatically changes the line endings to linux style when committing the files to the server. Maybe it does not know what to do with “.hex” files. So again, if you have any idea how to fix this problem, let me know… Installing a windows virutal machine just for compiling the source codes is stupid (sorry for this word). After all gcc was initially developed for unix platform, not for windows
I am currently working on the calibration process, during the weekend I have made a lot of measurements to find out what will be the best approximation algorithm for correcting the ADC values. Yesterday I made some graphs to review these measurements, but something went wrong and for negative voltages I get incorrect values. If you are interested, here is a screenshot:
and here is an interactive view of this graph: http://pub.valky.eu/calibbad/meas9mage.html
Every curve represents different Vpos setting (from -20 to 280), on the horizontal axis there are voltages from -2.0 to +2.0 with step 0.1V. On the horizontal axis there is measured ADC value. These ADC values were calculated as average of full sampled waveform.
I am still having problems to understand, why the negative voltages are measured incorrectly. I used RIGOL signal generator as voltage source. I was changing the voltage offset of sine wave with amplitude set to minimum (it did not allow to set the amplitude to zero, but it was under 0.4mV or so). This DC voltage was measured accurately with UNI-T digital multimeter. And this voltage was connected with the A channel probe of DSO.
Maybe it has something with the ground loop…
To answer your question, no currently there isn’t any way to calibrate the oscilloscope from the application. After I finish initial measurements and I will find a good correction algorithm, I will prepare a calibration application. But this app will be implemented probably in html/javascript with the use of DSO SDK, due the lot of calculations in floating point arithmetics.
gabonator. If in your software you want to use lists and have functions like getPrev, getNext, getFirst, getLast, for this is a class DoubleLinkedList which has a structure -
class DListElement //element of double linked list
{
DListElement *_prev, *_next; //here are pointers to prev and next element
…//your data
DListElement *get_next(){return _next;};
DListElement *get_prev(){return _prev;};
}
class DLinkedList //the double linked list itself
{
DListElement *_first, *_last; //pointers to first and last elements of the list
DListElement *get_first(){return _first;};
DListElement *get_last(){return _last;};
}
so you do not need this iterations over single linked list, as you have in your windows.
do not invite bicycle data structures must be suitable for algorithms.
also why are you trying to implement MS Windows style of UI objects, messages and functions, if this processor has only 64k of ram. MS Windows style is a C-style of GUI implementation, but you are using C++
