But here’s as far as I can get on building the FPGA source code.
NOTE: These files do not have build instructions. So the following is still just my best guess.
1. Download the source code for FPGA_V2.5, and make a copy to work on. I called my copy FPGA.
2. Start up iCEcube2
3. Double-click New Project
4. Set the project parameters: [list=A]
[*]Project Name: FPGA (or whatever you called the directory)
[*][i]Project Directory:[/i] where you placed a copy of the source code. Keep the original git checkout separate.
[*][i]Device Family:[/i] iCE65
[*][i]Device:[/i] L04
[*][i]Device Package:[/i] VQ100
[*][i]Power Grade:[/i]L - I am assuming L, 1.2V operation. I don't know what the design voltage is for the other option, T
[*][i]Temperature Range:[/i] leave at Commercial (this also is a guess)
[*][i]Core Voltage Tolerance:[/i] leave at +/-5%
[*][i]Performance timing analysis:[/i] leave at Worst
[*][i]Start from Synthesis:[/i] leave selected
[/list]
5. Select Next
6. Add Files dialog: add all the .v files. Use the >> button to add the selected files. The >>> button adds all the files in the directory. I added: [list]
(continuing the instructions after a few screenshots)
9. Choose Add Files… (after right clicking)
10. Add Time.sdc using the >> button
11. Click OK
12. You should now have the following files in your project. If it doesn’t look like this, you should go back and remove files (right click on them) and add the correct files.
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.
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.
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.
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.
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)
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.
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_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.
. Looking forward to trying it out on the APP_245B source code