In theory the next step is to synthesize the verilog files.
However, a commercial license of iCEcube2 costs way more than I currently care to pay for this tutorial, so this is where it stops.
dear tgo,
i have incorporate these version to the github.
but it makes mess up the rep for some reason, so, i make a new rep :https://github.com/Seeed-Studio/DSOQuad_SourceCode
Dear HugeMan,
Ok, thanks!
Hi HugeMan,
Can we please get source code for SYS_V1.41 and APP_V2.43?
Thank you,
tgo
The designer bure told please wait a few days because the firmware are upgrading frequently these days. The soucecode will be released as it get a more stable state.
Cool! This is much appreciated!
The “Memory layout” at http://garden.seeedstudio.com/index.php?title=DSO_Quad shows 32K sections for each of SYS, APP_1, APP_2, APP_3, and APP_4. (With a small typo that C0000 should say 0C000.)
But App versions 2.43 and 2.45 are larger than 32K, such as 39K! I found this out when compiling a modified version of APP2.35 and installing my version as APP_2. It worked OK (hold down button 2, 3, 4 at power-on to run application 2, 3, or 4).
But then a normal power-up to run APP_1 failed (drawing noise over most of the screen), because I had accidentally replaced the last ~7K of APP_1.
For now I switched to using APP_4 instead for my experiments, but is there a plan to keep the “open source” APP_1 small enough to compile using the 32K-limited versions of IAR Embedded Workbench? Perhaps Calibration could be split into a separate application, for example.
Hi there,
I got my DSO quad a few days ago and I really hope that the source for the latest version will be released soon. I find a bit odd the way the git repository is used. Wouldn’t it be nice to have it fully synced and tag versions as they are released? This way we could have a larger developer community and take full advantage of the firmware being open source.
I found the comment by DaveLyons very interesting. I was willing to perform some fixes and add some functionality, and was somehow disappointed to see that there is no easy way to build the projects using an open source toolchain. I guess there is a way to do that, but after having a look at the DSO Nano firmware (which is already GCC-friendly) I found it a bit difficult to perform the same operation on the quad firmware… so I guess IAR is the only way to go for now.
Besides the 39k issue with App 2.45 are there any known gotchas when building custom applications?
I’ve posted instructions at the start of the thread on building the FPGA source code (incomplete). Please vote, I’d like to know how it goes for those who try it out.
- tgo
Is there any news yet on when the APP_245b and SYS_141 source code will become available? I have some custom interface changes I’d like to make, but I would prefer to start from the latest source code versions if possible, even if there are to be some more official changes and releases coming soon.
fmp00,
I have a Keil uVision build of the APP_235 sourcecode which compiles no problem, and then runs fine on the DSO Quad. I haven’t tried yet the other source files for SYS_134 etc. I like Keil better than other IDEs as it is very straight-forward and easy to use. The other nice thing is that the Keil runtime lib for the STM32F10x is nicely and tightly optimised so the APP_235 comes out at around 23k, and without needing to compile the STM32F10x firmware files 
. Looking forward to trying it out on the APP_245B source code .
In order to start studying the Quad’s APP235 and SYS134, I have identified the functions of each source file in the attached text files. It will help me and may help others. Most likely new updates will remain quite similar. If new updates change, then I will attach new zips here.
app235_sys134.zip (2.14 KB)
Nice.
I noticed already there’s some support for a microSD card. I’ve been meaning to find the traces and solder one in…
My original assumption (true or false) was that the microSD is a virtual microSD card via the SPI flash memory chip. I will have to look again for supporting hardware ports. Have you found any supporting hardware ports for the microSD?
I am not an experienced “C” programmer but I can read most of the code and look up what I don’t understand, so I will give this more focus.
Thanks
The STM32F103VC microcontroller has microSD hardware built in (SDIO in the datasheet). Looking at those pins, it’s apparent that they are too deeply buried by the current design.
According to the datasheet and the DSO Quad v2.6 schematic, the pins are: (LQFP100 package)
SDIO_CMD - pin 83 (PD2) - Vusb (input from 11K/(11K+11K) voltage divider, R49 and R48, to measure Vusb)
SDIO_CK - pin 80 (PC12) - K6 (K1-K10 are key inputs from the buttons)
SDIO_D0 - pin 65 (PC8) - K3
SDIO_D1 - pin 66 (PC9) - K4
SDIO_D2 - pin 78 (PC10) - K2
SDIO_D3 - pin 79 (PC11) - K7
SDIO_D4 - pin 95 (PB8) - CHRG (input signal from U14 LTC4054)
SDIO_D5 - pin 96 (PB9) - Ax1 (controls input stage scaling)
SDIO_D6 - pin 63 (PC6) - BL (drives backlight by controlling U10 QX5239B enable - EN)
SDIO_D7 - pin 64 (PC7) - BZ (drives Q1 to control the speaker buzzer)
It’s really too bad, since there are at least 20 unused I/O pins on the FPGA that could have handled these misc I/O functions. Surely it could have been designed so that these pins were available for a microSD slot – but the current design really blocks me from rerouting these signals where I want them.
I don’t know if I’ll ever have the time, but a mini DSO like this needs a lot of work. It needs a re-worked front end. It needs a more powerful microcontroller. And it needs more than 2 MB of disk space – it really needs that microSD slot so the user has more control over storage. (I’d keep the SPI flash for firmware updates.)
Bad as it is, I’m sticking around to see if the source code shows up, but time is running out in my opinion. I don’t resent that I bought two of these units, because they’re fun toys, but I still want a “real” scope in such a portable package and will buy one if I can find one.
(In case anyone cares to know, I bought two because the first ones have a small lipo battery, around 500mAh. So I got another one just to see what bure changed that isn’t being publicly announced. The lipo battery is now 1000mAh for one thing.)
I have re-written and restructured large portions of the current source code in SYS and APP, and binned everything else (chuckle). Some of the real-time display coding I have already optimised and a completely new user interface, based on a typical professional scope-meter. I am about 2-3 weeks away from releasing the first trial of the new interface to you for testing. Not all functions will be there by any means yet, but I had to get it to the stage of being able to face using it . Once the user interface is completely re-worked, I will look at the multitude of other problems and reported issues with SYS and APP, along with tgo’s current work.
Very nice, very nice…
Go Adrian, go
I hope however, you will post the source code and build instructions