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.
Yes, the source code for both SYS and APP will be freely available on this forum, as will the build projects for the Keil Compiler. I will however wait to release the source until I have properly finished restructuring the code, and we have gotten on top of the most immediate issues and functionality. However, I do not want to wait to release the new binaries until all the source code is re-structured. A new user interface was a necessary stepping stone in the first instance for me to even face using the Quad (chuckle)
We are all looking forward to your first release. You are doing a good thing here! I for one understand that it is very time consuming and also very rewarding.
Hopefully you are big on code comments for those of us who will expand our “C” knowledge from this endeavor. Ease of code maintenance will be the essence of your success and it sounds like you are working that concept.
If one is going to rework the code for a different compiler, wouldn’t it be better to use an open source compiler such as gcc? Looking at the Kiel site it looks like their compiler is proprietary, costs money, and only runs on Windows. Using gcc would allow for the most developers to participate in improving the functionality and usability of the code.
However, switching compilers is not too difficult. Release whatever source code you want to release, and we can get it to run using gcc. (I’m not saying I will do it, but that it’s doable.)
There are no Keil specifics in the source. The source is ansi C, so you can use whatever tool chain you want to compile it. Usually only the the asm format varies from compiler to compiler, so this will need a little modification for gcc probably, along with link map to get the bios stubs in the right memory range for SYS. If I get time I will write a gcc makefile, or if anyone wants to do the gcc compilation then I can tell you what the optimisations and link map should be to make it work.
I agree with this fully, and was my main reason for getting involved with the endeavour. Hopefully, we can come out with something very good, quite besides the enjoyment that comes from developing it together.
I’m looking for the SYS_1.5 & APP_2.5 source code for analysis and experimentations. I’ll be using Rowley CrossWorks. Did anyone know if it’s already available and where to find it?
I would very much like some help , as I want this to be a team endeavour. Let’s just wait a little until I release the new source code version, and then we can look at what tasks we can each do .