I tried to compile in linux and found some problems. The first problem is that I didn’t have instructions on how you expected to compile the code so I did this:
cd Build/arm_linux
make
which is not what I think you did, but anyway that is what I eventually got to work. Unfortunately I had to change quite a bit of stuff including:
mv Source/HwLayer/bios.h Source/HwLayer/Bios.h
mv Source/Core/design.h Source/Core/Design.h
mv Source/Gui/toolbar.h Source/Core/Toolbar.h
in Source/HwLayer/ArmM3/src/interrupt.c use interrupt.h not Interrupt.h
in Source/HwLayer/ArmM3/src/startup.c use interrupt.h not Interrupt.h
in Source/HwLayer/ArmM3/src/cbios.cpp use BIOS.h not bios.h (line 5)
You also need new versions of the common/build.mk and arm_linux/Makefile files. You can see I changed quite a bit of stuff especially in build.mk.
I prefer github mainly because I’m trying to learn to use git. I hate svn but like cvs.
UPDATE: I found a way to eliminate the need to change the .lds files. New updates2.zip file. updates2.zip (1.39 KB)
Hey all, I’m definitely interested in helping out where I can. I’m familiar with C/C++, but mostly for pc. I’ve never worked with ARM before, but am interested in learning.
@gabonator1, two things: First, GREAT WORK! It looks pretty sweet compared to stock, and secont: for what it’s worth, I vote Git, though as a newcomer I know my vote may not mean much.
I am really very happy that there are more people that would like to participate in this project. Here is a github repository where is a little improved version of the firmware: https://github.com/gabonator/DS203
I was having really hard time to configure everything - this was for me the first time to make a git repository, most problems I was having with rsa keys… But now it seems that it is working, so I hope you will enjoy it
unfortunatelly, I didn’t have time to implement new features, I spent all my time preparing for a medical conference that was in Boston (IEEE AMA), where I was demonstrating a wireless ECG system with visualization on android phone. For more informations see the last PDF link on this page http://ama-ieee.embs.org/program/final-program/. For demonstrating this device I have used the DS203 oscilloscope for generating ECG waveforms. Oscilloscope was connected through resistor divider to the ECG electrodes. Everyone on the conference liked this project very much Maybe I will later write some report to my blog
I downloaded APP_G251.hex from github to my new DSO QUAD. The DFU came back with an extension of .err, and it does not appear to have loaded. I tried booting each button on top.
I have the Frequency response application in the 4th button, and I have upgraded the official firmware. So it appears I can change the firmware’s. Can some one offer some insight into what went wrong?
I upgraded the default firmware first thing when I got it. I now have 1.52 and 2.52 released on 2011-11-15. Could there be an issue with this Oct 28th firmware being older than the latest firmware I have? I have upgrade firmware 3.10, which is what it came with. Perhaps that is a newer firmware. I just got the Quad yesterday evening.
HEX load SOLVED, I got it to install and boot. I did a git clone, instead of web page download. The file I got from the git clone was 76KB, while the web download claimed to be 227KB. Once I got the correct file, it worked just fine.
The 227KB download file is a web page. Thanks for finding this!
Even with the HEX load, I don’t get the error but I don’t get a change in the scope app either.
I tried both APP_G251.hex and copying it as APP.hex.
I tried Linux and Windows both. Do I need to downgrade the FPGA and SYS code for this?
Does it install as the default app or is it on another startup button? I tried buttons 2-3-4 and get no app.
I have the most recent FPGA according to the firmware wiki page. So that’s probably not the issue. I upload my firmware from an XP box, I couldn’t get it quite right with Ubuntu.
Did it come back with a file after you uploaded the firmware? Have you been successful in uploading another firmware? I used the name found in the git repo. Did you obtain your file via git, or by web page? Is your firmware about 76KB?
I just did a diff between the correctly downloaded hex file via web page raw, and via git download. The diff claimed the text for each line to be the same, however the line end character is not. I also noticed the file size as claimed by XP is 75KB for the web copy, and 76KB for the git copy.
The web page raw download produced an .err when I tried to load it. The git copy worked great. Perhaps a zip copy of the original source file would be handy, this would ensure data integrity, as it appears the github web page is modifying the files before sending them for download. Git was intended to be for source code, not binary files, I suspect that’s one reason why this didn’t work as one would expect.
I like it much much. I see the grey features, implying they are planned, but not implemented yet. Those look really interesting.
Things I like include,
– Better contract of the text, the flashing text and odd contract of the original gui was some times a bit hard to read for those with less than perfect eye sight.
– Not using the push button of the selector switch, I find them hard to press, especially if I have gloves on.
– I find the gui just plain easier and more intuitive to navigate. Options are near each other, the selector doesn’t jump around the screen, it flows from one selection to the next.
Things that would be really cool to see include,
– Save primary setting such that they are kept when I turn it off, then back on. Things like channel 1 amplitude, trigger setting, time base, ect.
– HEX file that can be loaded into slot 2 or 3 instead of 1. Perhaps noted in the name like APP_G251_slot1.hex APP_G251_slot2.hex, ect.
– Custom wave form uploaded via USB for generator.
All in all, it’s a great start, I wish I were a better programmer and could help. Keep up the good work, I’m eager to see what you come up with next.
I tried to compile under wine, but with out luck. I used “wine cmd” to get into a windows command prompt, but get this message. [code]C:\DS203\Build\arm_win32>makefile.bat
DS203 Build tool by valky.eu
Target slot: !APP!
DFU Drive: !TARGET!
Your current path contains spaces, it can cause some problems…
Press Return key to continue:
Compiler not found !
C:\DS203\Build\arm_win32>
[/code] I changed the makefile.bat like this
set CBASE=C:\arm-2011.03\bin\
I would guess there is a space in a step of the compile process that doesn’t match the wine expectations. I don’t know where that might be though. Any thoughts about how to find it or them?[code]C:\DS203\Build\arm_win32>cd C:\arm-2011.03\bin\
C:\arm-2011.03\bin>dir
Volume in drive C is
Volume Serial Number is 0000-0000
C:\arm-2011.03\bin>
[/code]
Also I plan to have a Doxygen file available shortly. I’m downloading and installing Doxygen now. That should make some nice call graphs and such things to make it a bit easier to study your code.
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.
It looks pretty sweet compared to stock, and secont: for what it’s worth, I vote Git, though as a newcomer I know my vote may not mean much.