You will find here complete packages that can be built by single click (including hex file upload into device). No development environment is necessary, it uses GCC compiler (code sourcery gcc arm eabi, probably any other toolchain should be ok) which can be downloaded here:
Thank you for this!!! I was waiting for others to tackle the calibration problem because of my lack of knowledge setting up a GCC cross compiler on Windows (and not wanting to spend corporate compiler prices for a hobby project). This worked perfectly (after some minor tweaking of the CodeSourcery .Tar contents*) to build a hex file and put it on my Quad.
The newly built hex file runs, but it hangs when trying to save the calibration data. Do you have any suggestions for debugging the code from a Windows machine?
Again, thank you very much.
Jerry
(For others following this route:
*The CodeSourcery .Tar file seems to have some zero-length files, but the installer .exe seems to have all the required files. I replaced the missing files from the .Tar with ones from the Windows install, but you could just use the Windows installer files. I also played it safe and did not have any spaces in the paths used for the compiler and source files and changed the “/”'s in the bat file paths to '". The bat file seemed to have Unix-like line endings, which made it messy to look at in notepad, but is well formed when opened with something that understands those line endings.
*In the Makefile.Bat file from the gabo-dsoquad.zip file, the “APP=” controls which application section the program will be loaded into. I changed it to 3 since I haven’t really checked how large the V2.50 application really is and I did not want to chance overwriting part of that application during my testing)
Hi Jerry,
It hangs also when you try to save your settings, I didn’t try to calibrate the device, but it is calling the same functions. I don’t know why, but the device hangs when I call any <string.h> functions. So I wrote my own string.h/string.c that contains all neccessary functions. Probably someone who has more experience with gcc can help us with correct setting of compiler/linker flags, because this solution is a stupid workaround.
Debugging? Sad, but the only way how to debug this firmware is to put everywhere some debugging code like:
If I will get more experience with the STM32 processor, I will add to the USB interface a virtual serial port, it should make all the development much more easy with a console.
I was afraid that debugout() was the case, but was hoping for some way to connect DBG through the existing USB port connection for interactive debugging. However, thanks to you, I now have the ability to compile, upload and run new programs which I could not do yesterday.
Even thought there is not an interactive debugger, the DSO Qaud has a fully functional screen, so debugging should not be as painful on as some other platforms with just an LED or two (but I am not opposed to someone else stepping in and letting me know how to get interactive debugging operational ).
I’ll try out the modified version, but it probably will not be until sometime next week. Hopefully I’ll get a chance then to find out what is happening to keep my unit from calibrating correctly.
Gabonator1, thank you very much for this thread!
This makes really easy an fast to manipulate the code and use it “on board”.
I start using it yesterday, and as soon i find some more time to dedicate to study the code (the comments in (maybe) chinese doesn’t help a lot ), i’ll try to give my two cent to the development of our toy (first i’ll try to see if is possible to avoid the slower screen trace refresh when the time base increase…if it’s bigger then 10ms, the trace is refreshed only every second and became slower for bigger values…and of course during that period you lose a lot of signals!)
Google translate does a decent job of translating the comments from Chinese to English. You can have it translate the entire document, but some of the characters in source code upset the output. Even with the character problem, the translation gives useful information from the source code comments.
I have tried installing GCC and it will not run. The problem appears to be with the directory structure. Could you guys who have it running please give the full directory structure you used both for GCC and for the dsoQuad code. Thanks.
Unpack these packed files into the same folder.
Edit the “makefile.bat” and change the path to the compiler (the line highlighted in red)
You can doubleclick on makefie.bat, but the window will probably hide very quickly. To see the output of the makefile script, open the commandline prompt (start->run->cmd), go to the folder where is makefile.bat file (command “cd”) and execute the script (type “makefile.bat” [enter]).
The compiled .hex file you will find “bin” folder and is named “APP_G251.hex”
If you are still having problem compiling the project, please paste here the output from commandline prompt.
Thanks Gabonator1,
that explains it all very clearly and should help others who have difficulty. The mistake I made was to use the Windows install.exe version of the toolchain which creates a completely different directory structure from the .tar version and therefor doesn’t work with your Makefile.
I strongly recommend looking at this. It offers the best hope at present.
Thanks gabonator. What kind of help would you like? I am a hardware designer and assembly programmer so probably can’t offer much? How about a donation?
First i would like to thank u for your efforts to get me started programming on the DSO! For sure i want to participate in the development of a new ui and other improvements for the DSO.
Im just getting started programming on the ARM platform but i hope i can help in some way.
Just to know that this project is not abandoned, I have just switched to the “Opensource” subforum instead of “Tech Support”. The project is finally on github:
gabonator,
I am trying to compile the souce code from the marcosin .app using your makefile. I am getting a lot of errors. Where am I going wrong? The structure of his source code is very similar to your .app.
OK I got the .app version of marcosin’s source code to compile using the Makefile from gabonator. The many errors were due to differences in the toolchain used by marcosin (presumably IAR) mostly these differences were using “char” instead of “u8” when defining string variables. I had to search and replace all the .c and .h files to fix this. If anyone is interested I will post the modified 1.7 code here.
Gabonator do you have a makefile for creating the .sys on your setup?
Sorry, I spoke too soon. The marcosin v1.7 source code does compile and upload sucessfully but there are problems with the display. Possibly this is to do with optimisation settings so I tried removing the -Os flag and it still builds without errors but there are still problems on running the code.
marcosin.rar (263 KB)ok here is the marcosin 1.7 sourcecode modified so that it will compile using gabonators makefile.bat. This does complete the process with no errors and the file loads into the DSOQuad where it runs but there are some problems with waveform display. The source files are only changed in small ways to remove error reports and the makefile is identical to gabonators. Perhaps someone else can get it to behave ? (edit) the makefile is changed for slot 1 otherwise is identical