Products > Test Equipment
New bench scope - Fnirsi 1014D, 7", 1GSa/s
pcprogrammer:
--- Quote from: donwulff on January 06, 2023, 03:43:23 pm ---EDITn: Yes I also looked at how the Sipeed Lichee Nano with F1C100s has 16MB flash, so I guess the 1MB set aside for firmware on the SD-card is just a matter of choice and guessing it won't grow above that. It would also theoretically be possible to load different modules from SD into memory?
--- End quote ---
The 1MB is what most SD cards have with default formatting, and it still allows for growth of the firmware.
--- Quote from: donwulff on January 06, 2023, 03:43:23 pm ---It would also theoretically be possible to load different modules from SD into memory?
--- End quote ---
Yes, that is basically how linux does it. You could load some files on the SD card and have the basic part of the firmware read them into memory and jump into that code.
--- Quote from: donwulff on January 06, 2023, 03:43:23 pm ---Si5351A ClockBuilder Pro lets me choose 200MHz + 50MHz clock even though I guess it's way beyond spec. So this is something like what I should be looking for in the code. I wonder why there's so many functions & apparent dynamicity to the setting in FNIRSI, just stupid choice/ready-made library I guess? Also note you can write i2c in consequential manner, even according to the Chinese clone datasheet, no need to give write & register address for each.
--- End quote ---
Programming does not seem to be their forte :-DD
I have found many stupid things in the 1013D code, for which I doubt ready made libraries were used. Like you wrote it is possible to send data for sequential registers in a single write action. Would mean a bit of a speed up, but does not really matter here though.
My code is a bit of a mess due to the way it all came together and could do with cleanup, restructuring and some bug fixing though.
donwulff:
Edits galore in the above clock gen configuration post as I keep researching more. I still don't fully understand the register configuration, though I can at least see what the FNIRSI code is trying to do - although it seems at least for the scope part they could indeed do with just a couple of mostly sequential writes, for a code that'd be a pleasure to decompile with Ghidra ;) But I suppose I can just dump the ClockBuilder Pro register file into i2c and hope for the best. Meanwhile I'll have a look at the serial configuration, and see if I can't just print the bytes on display or something so I can simplify the in-system programming. But before that, some emergency work ;)
Number Start End Size Type File system Flags
1 32.3kB 7988MB 7988MB primary fat32 lba
Let's just blame FNIRSI shall we, what kind of flash alignment is that anyway? ;)
pcprogrammer:
--- Quote from: donwulff on January 06, 2023, 05:30:31 pm ---Meanwhile I'll have a look at the serial configuration, and see if I can't just print the bytes on display or something so I can simplify the in-system programming.
--- End quote ---
That is a good idea. Should have thought of it myself :)
I have used writing to file to capture al sorts of data during the reverse engineering and development, but also wrote stuff on the screen.
You can make a copy of the firmware backup project and use it to show the serial data. It has all but the serial part in it. Write to file can be done and the display lib is there to do the displaying on screen.
--- Quote from: donwulff on January 06, 2023, 05:30:31 pm ---But before that, some emergency work ;)
Number Start End Size Type File system Flags
1 32.3kB 7988MB 7988MB primary fat32 lba
Let's just blame FNIRSI shall we, what kind of flash alignment is that anyway? ;)
--- End quote ---
Is that how the original card was done? I have also had something like that before, that I had to reformat the card to make space for the firmware. Might well have been the one of the 1014D.
donwulff:
To the credit of pcprogrammer's original code (and schematics), configuring ClockGen over I2C using modified (8 bit address, different pins etc.) code worked fine first try. Only I did a classical copy & paste error, disabling the second clock output when I meant third, leading to some lengthy debugging... After finding that, there's now nice, almost flat scope traces (X1 20uS not so useful though!). The 200MHz is attenuated sine-wave even on my 2.5Gs/s Fluke Scopemeter 225C, but that's to be expected.
The clock generator configuration itself has a few oddities. The Chinese chip seems to be based on the Rev B chip, which goes up to 200MHz, and has datasheet and register description split apart: https://www.skyworksinc.com/-/media/Skyworks/SL/documents/public/application-notes/AN619.pdf
However, the ClockBuilder Pro generated register map writes to two registers marked as "Reserved" even in that. The generated dump names them "DIS_RESET_LOLB" (Disable something reset Loss of Lock PLL B? But this doesn't use PLL B) and I2C_ADDR_CTRL - I left both alone for now).
For the 50MHz out, the divider from 800MHz fVCO needs to be 32. That seems like an even integer to me, but the generated register map leaves MS1_INT as 0. Time to try what happens if I set it to 1. The ClockBuilder Pro logic seems indecipherable as it's even relying on the Reserved registers. There's the additional thing that I will most likely have to switch to use different PLL's for each clock, as it sounds the 200MHz clock may need more fine-tuning, which at >112.5 MHz can only be done by adjusting the PLL fVCO multiplier.
From what I can see, the original firmware leaves XTAL Crystal Load capacitance at default 10 pF. I have no idea which crystal the 1014D uses, but looking at available crystals, the vast majority of 25MHz crystals come with load capacitance of 8 pF, and the leads and pins will provide a bit of stray capacitance. AN619 specifies "crystal load capacitance" though, so maybe this should be 8 pF, but default 10 pF seems to just work.
And yes, the original 1014D SD-card had that wacky 32.3kB partition start. I guess making it small would make sense on a really small SD, the documents I think talk about 1G one, but you'd definitely want it aligned to some suitable power of two...
On towards the knob controller interface, though I'll probably stop updating on every small change. I'll stick them on GitHub when I have something useful, though I'm not using NetBeans (or some derived IDE?), and not sure how much it'd be worth it to combine the code. I'll see how much changes I'll have to do the the UI inputs; it might even be mostly just renaming the touchscreen functions to something interface-agnostic.
pcprogrammer:
Well that is good news.
Yep 200MHz square wave needs a scope with a very high bandwidth to show it as square. My 500MHz Yokogawa DL9705L shows a sine too.
About the crystal, if it works it works, I would say.
Netbeans is just the IDE I'm using. Has no impact on the code. Just add a new directory to your fork of the repository and stick your work in it as a backup. When you have something that is usable as new firmware, I would suggest to make a new repository for it and stick it in there. You can also design your own splash screen :) (Or make it work without it)
The touch handling in the firmware is based on detection of touch in one of the defined buttons or dedicated areas, and if it is a menu it will open that menu and use dedicated functions to handle the touch in that. It might not be easy to connect this to the input from the user interface controller. But everything for this is found in the "statemachine" and "scope_functions" files.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version