OK now: MakeSSerials:\GenMakeSSerials:MakeSSerials 649.0 (6.2) 805.6 (6.2) 159.6 (0.0) 3.0 (0.0) 0.0 (0.0) 748 (12) 1129 (0) 0 (0) 40960 5 0 0 0 Entity instance magicially appears in Quartus after full compile.
next I'll run the docker compilation and post the bitfiles here On Thursday, 22 August 2019 10:26:57 UTC+2, Michael Brown wrote: > > Yeah comes to mind the DExx_Cramps projects run on a reduced configuration > so only the needed cores are added/included (the one's in the current > configs) so... > SSerial core needs to be included. > I'll do that asap. > > On Thursday, 22 August 2019 03:53:39 UTC+2, justin White wrote: >> >> I threw the new FW on the nano and the stepgens are all working now. >> Still no SS but I suppose that was to be expected. As PCW said, since the >> version prints as "0", the SS CPU must be broken. >> >> On Wednesday, August 21, 2019 at 3:25:53 PM UTC-4, justin White wrote: >>> >>> Well that makes sense, my SS pins were on GPIO1_00 and GPIO1_01, >>> Stepgens start on GPIO1_02 so it might explain quite a bit. >>> >>> I would have tested it out a bit earlier but I went full nerd yesterday >>> and built a 3900x/5700xt system I've been working on getting running. I got >>> quatus installed and used the config files you attached and I see all of >>> the stepgens are now full. Going to build the .rbf and set it back up to >>> test SS again......hopefully it all just....works lol >>> >>> thanks fellas >>> >>> On Tuesday, August 20, 2019 at 2:06:34 PM UTC-4, Michael Brown wrote: >>>> >>>> Note: >>>> It did really help to have your full quartus project online to play >>>> with, that was probaly what immediately triggered my internal >>>> analyzer/debugger.... :-) >>>> >>>> On Tuesday, 20 August 2019 19:54:02 UTC+2, Michael Brown wrote: >>>>> >>>>> Valid Files Here: >>>>> >>>>> On Tuesday, 20 August 2019 19:50:53 UTC+2, Michael Brown wrote: >>>>>> >>>>>> Ups Sorry sorry sorry ... my BAD .... (Suddently my biain kicked in >>>>>> :-) ) >>>>>> I should have spotted it immediately. >>>>>> Culprit is due to my single experimental (verilog) added capasitive >>>>>> depth/touch sensor core. >>>>>> This is not a part of the "original mesa hm2 vhdl config system, and >>>>>> the pins are hardwired to: >>>>>> GPIO_1 pins 00 + num sense parameter. (if that exact core is enabled >>>>>> in config file) >>>>>> --- >>>>>> Solution is very simple: >>>>>> edit mksocfpga/HW/hm2/config/DExx_Nano_xxx_Cramps/ >>>>>> atlas_st_fpga_soc_dc1f_ss.sv >>>>>> --> parameter Capsense = 0; >>>>>> >>>>>> I have tested with: >>>>>> (StepGenTag, x"02", ClockLowTag, x"06", >>>>>> StepGenRateAddr&PadT, StepGenNumRegs, x"00", >>>>>> StepGenMPBitMask), >>>>>> >>>>>> and all >>>>>> SRL16E:\steptable:1:asr16e 4.2 (0.0) 8.5 (0.0) 4.3 (0.0) 0.0 (0.0) 0.0 >>>>>> (0.0) 5 (0) 17 (0) 0 (0) 0 0 0 0 0 >>>>>> entities show up populated. >>>>>> :-) >>>>>> once again excuse for my temporary brain paralysys.. >>>>>> ... >>>>>> >>>>>> On Tuesday, 20 August 2019 16:30:50 UTC+2, Charles Steinkuehler wrote: >>>>>>> >>>>>>> Dig through the synthesis log (*.map.rpt) a bit and look for >>>>>>> warnings >>>>>>> that indicate undriven nets. Sadly, most tool chains consider >>>>>>> undriven signals a warning vs. an error, so they'll happily optimize >>>>>>> away huge chunks of your design. A typical warning would look >>>>>>> something like: >>>>>>> >>>>>>> Warning (10541): VHDL Signal Declaration warning at >>>>>>> HD_Core_CycloneV_pipen1b.vhd(45): used implicit default value for >>>>>>> signal "clk250_out" because signal was never assigned a value or an >>>>>>> explicit default value. Use of implicit default value may introduce >>>>>>> unintended design optimizations. >>>>>>> >>>>>>> In vim, I use the regex: ^Warning.*$ which highlights the whole line >>>>>>> (if you're in GUI mode). >>>>>>> >>>>>>> Note you will see lots of other warnings, most of which are probably >>>>>>> OK. In particular, the ever present: >>>>>>> >>>>>>> Warning (10036): Verilog HDL or VHDL warning at >>>>>>> HD_Core_CycloneV.vhd(471): object "HDMI_clk" assigned a value but >>>>>>> never read >>>>>>> >>>>>>> ...is (usually) perfectly OK, it's similar to an unused variable in >>>>>>> "C". This _might_ be an actual error (if the signal was supposed to >>>>>>> go somewhere) but is typically OK. >>>>>>> >>>>>>> On 8/20/2019 9:09 AM, justin White wrote: >>>>>>> > Thanks for the advice Charles. Actually I use this project: >>>>>>> > >>>>>>> https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects/DE10_Nano_FB_Cramps >>>>>>> >>>>>>> > >>>>>>> > Michael explained it has more functionallity than the DB25 >>>>>>> project, so I've >>>>>>> > never tried the DB25. >>>>>>> > >>>>>>> > Not really up on my git stuff, I forked master and slapped my >>>>>>> config files >>>>>>> > in, like I said these are modifications of the "3x24_cap_enc" >>>>>>> config. >>>>>>> > https://github.com/blazini36/mksocfpga >>>>>>> > >>>>>>> > The pin assignments are so different from anything else I can't >>>>>>> imagine >>>>>>> > it's looking at another pinfile, it's likely I just didn't modify >>>>>>> something >>>>>>> > I probably should have. I'll try to look into your suggestions a >>>>>>> bit later. >>>>>>> > >>>>>>> > >>>>>>> > On Tuesday, August 20, 2019 at 9:41:57 AM UTC-4, Charles >>>>>>> Steinkuehler wrote: >>>>>>> >> >>>>>>> >> It sounds like the synthesis tools are optimizing away the >>>>>>> stepgen >>>>>>> >> logic, almost certainly because of an issue with signal >>>>>>> connectivity >>>>>>> >> to the top level I/O pins. The actual step accumulator is still >>>>>>> >> generated because it's value gets read back via the register >>>>>>> >> interface, but the steptables are only needed to generate the >>>>>>> output >>>>>>> >> signals so they're getting optimized away. >>>>>>> >> >>>>>>> >> Is your project checked into github somewhere I can grab it? I >>>>>>> can >>>>>>> >> try building in the desktop Quartus tools and see what's wrong. >>>>>>> >> >>>>>>> >> Otherwise, double-check the pin assignments the top-level I/O >>>>>>> port >>>>>>> >> definitions, and make sure the physical I/O pins are properly >>>>>>> >> connected to the hm2 instance. >>>>>>> >> >>>>>>> >> I took a quick look at the project I think you're using: >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/ >>>>>>> >>>>>>> >> >>>>>>> >> ...and the top-level stuff looks OK at first glance. The >>>>>>> important >>>>>>> >> part is the use of the correct PIN_<config> library, which gets >>>>>>> called >>>>>>> >> out here: >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/hostmot2_cfg.vhd.in#L74 >>>>>>> >>>>>>> >> >>>>>>> >> Make sure in your working copy the hostmot2_cfg.vhd file is >>>>>>> getting >>>>>>> >> generated with the correct name in the "use" line, and make sure >>>>>>> the >>>>>>> >> pin file you're including in the project has proper values for >>>>>>> IOWidth >>>>>>> >> and IOPorts. >>>>>>> >> >>>>>>> >> You can dig through the first part of the compile log messages to >>>>>>> >> verify the correct PIN file is _really_ getting analyzed and not >>>>>>> some >>>>>>> >> other file. >>>>>>> >> >>>>>>> >> I'm also not sure how mixing the system verilog config files with >>>>>>> VHDL >>>>>>> >> packages works (I know just enough Verilog to generally be able >>>>>>> to >>>>>>> >> transcode it to VHDL). If there's any problems with that, >>>>>>> Michael B. >>>>>>> >> will have to comment. >>>>>>> >> >>>>>>> >> On 8/20/2019 8:04 AM, justin White wrote: >>>>>>> >>> I deleted my mksocfpga directory and re-pulled it and I get the >>>>>>> same >>>>>>> >>> results after building the .rbf. >>>>>>> >>> >>>>>>> >>> Still not quite sure what's going on, though I did catch >>>>>>> something in >>>>>>> >>> Quartus. Using "0A" for stepgens in the pinfile creates 10 >>>>>>> stepgens, >>>>>>> >> but >>>>>>> >>> only the first 4 seem to be complete. #4 (the 5th stepgen) when >>>>>>> expanded >>>>>>> >>> shows blank resources for "SRL16E:\steptable:0:asr16e", but does >>>>>>> show >>>>>>> >>> resources for "SRL16E:\steptable:1:asr16e". On every stepgen >>>>>>> after they >>>>>>> >> are >>>>>>> >>> both blank which looks like it mimics exactly the problem I'm >>>>>>> having. If >>>>>>> >> "steptable:1" >>>>>>> >>> relates to the dir pin and "steptable:0" relates to the step >>>>>>> pin, it >>>>>>> >>> explains why I have a working direction pin on #4 but no step >>>>>>> pin, and >>>>>>> >> #5 >>>>>>> >>> doesn't work at all. In this case I'd assume no later stepgens >>>>>>> would >>>>>>> >> work. >>>>>>> >>> >>>>>>> >>> I'm not really sure how Quartus works with the configs. I'm just >>>>>>> >> dropping >>>>>>> >>> the pinfile I made into the >>>>>>> >>> '../mksocfpga/HW/hm2/config/DExx_Nano_xxx_Cramps' directory and >>>>>>> renaming >>>>>>> >>> the "atlas_3x24_cap_enc.sv" to match my pinfile, which is what >>>>>>> I do >>>>>>> >> with >>>>>>> >>> the mksocfpga docker build. I don't specify a pinfile or >>>>>>> anything when >>>>>>> >>> running the analysis in Quartus, yet it does seem to catch the >>>>>>> changes >>>>>>> >> I've >>>>>>> >>> made to that specific pinfile even though I don't specify >>>>>>> anything in >>>>>>> >>> Quartus, I just load the "DE10_Nano_FB_Cramps.qpf" file. >>>>>>> >>> >>>>>>> >>> Pics, QP1 shows all 10 stepgens, QP2 shows the difference >>>>>>> between the >>>>>>> >>> working #3 stepgen (0-3 all look the same) and #4 and #5 where >>>>>>> the >>>>>>> >> problem >>>>>>> >>> starts. "combinational ALUTS" and every feild after is blank. >>>>>>> >>> >>>>>>> >>> [image: QP1.png] >>>>>>> >>> >>>>>>> >>> [image: QP2.png] >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> On Monday, August 19, 2019 at 5:00:11 PM UTC-4, Michael Brown >>>>>>> wrote: >>>>>>> >>>> >>>>>>> >>>> Thanx for the clairifying Charles, I doublechecked tha line and >>>>>>> it >>>>>>> >> reads: >>>>>>> >>>> (StepGenTag, x"02", ClockLowTag, x"06", >>>>>>> >>>> StepGenRateAddr&PadT, StepGenNumRegs, x"00", >>>>>>> >> StepGenMPBitMask), >>>>>>> >>>> >>>>>>> >>>> So that should be ok... >>>>>>> >>>> >>>>>>> >>>> On Monday, 19 August 2019 22:37:42 UTC+2, Charles Steinkuehler >>>>>>> wrote: >>>>>>> >>>>> >>>>>>> >>>>> Actually, the NumInstances field of the ModuleRecord is >>>>>>> defined as an >>>>>>> >>>>> 8 bit std_logic_vector: >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >> >>>>>>> https://github.com/machinekit/mksocfpga/blob/master/HW/hm2/config/IDROMConst.vhd#L839 >>>>>>> >>>>>>> >>>>> >>>>>>> >>>>> In VHDL, it should throw an error if you use 06 for this value >>>>>>> (VHDL >>>>>>> >>>>> won't convert an integer value into a std_logic_vector without >>>>>>> some >>>>>>> >>>>> sort of type conversion). >>>>>>> >>>>> >>>>>>> >>>>> If you meant that you are using x"06" (an 8-bit hexadecimal >>>>>>> value), >>>>>>> >>>>> that should work fine, but you will only get 6 stepgens >>>>>>> instead of the >>>>>>> >>>>> 10 you'd get with x"0A". >>>>>>> >>>>> >>>>>>> >>>>> On 8/19/2019 3:19 PM, Michael Brown wrote: >>>>>>> >>>>>> No changing numinst should work just fine >>>>>>> >>>>>> >>>>>>> >>>>>> On Monday, 19 August 2019 18:05:28 UTC+2, justin White wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> One thing I noticed, I recall seeing this the first time I >>>>>>> started >>>>>>> >>>>> messing >>>>>>> >>>>>>> with the .vhd's. All of the pinfiles in the >>>>>>> DExx_Nano_xxx_Cramps >>>>>>> >>>>> config use >>>>>>> >>>>>>> this line for stepgens >>>>>>> >>>>>>> >>>>>>> >>>>>>> (StepGenTag, x"02", ClockLowTag, x"0A", >>>>>>> >>>>> StepGenRateAddr& >>>>>>> >>>>>>> PadT, StepGenNumRegs, x"00", StepGenMPBitMask), >>>>>>> >>>>>>> >>>>>>> >>>>>>> The NumInst being "0A" looked a little strange to me so I >>>>>>> changed it >>>>>>> >>>>> to >>>>>>> >>>>>>> the actual number (06) for every pinfile I've been working >>>>>>> with. >>>>>>> >> Could >>>>>>> >>>>> that >>>>>>> >>>>>>> be causing an issue? >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Monday, August 19, 2019 at 11:33:29 AM UTC-4, justin >>>>>>> White wrote: >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> On Monday, 19 August 2019 13:24:22 UTC+2, Michael Brown >>>>>>> wrote: >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> I have an older config that has worked with 8 stepgens: >>>>>>> >>>>>>>>>> hm2_soc_ol config line here: >>>>>>> >>>>>>>>>> < >>>>>>> >>>>> >>>>>>> >> >>>>>>> https://github.com/the-snowwhite/Hm2-soc_FDM/blob/master/Cramps/PY/Mibrap-X_hm3_fdm-soc/fdm/config/motion.py#L15> >>>>>>> >>>>>>> >>>>>>> >> >>>>>>> >>>>> >>>>>>> >>>>>>>>>> Have you tried with: >>>>>>> >>>>>>>>>> num_stepgens=6 in the hm2_soc_ol config line ? >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>> Yes, my config line is: >>>>>>> >>>>>>>> [HOSTMOT2] >>>>>>> >>>>>>>> DRIVER=hm2_soc_ol >>>>>>> >>>>>>>> BOARD=5i25 >>>>>>> >>>>>>>> CONFIG="num_encoders=6 num_stepgens=6" "enable_adc=1" >>>>>>> >>>>>>>> DEVNAME=hm2-socfpga0 already_programmed=1 >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> If the stepgens=6 wasn't there hm2 wouldn't instantiate >>>>>>> them in >>>>>>> >> HAL. >>>>>>> >>>>> They >>>>>>> >>>>>>>> are actually completely visible and HAL seems to think >>>>>>> they're >>>>>>> >>>>> working. I >>>>>>> >>>>>>>> dug up one of my first test hal files and #4 did in fact >>>>>>> work with >>>>>>> >>>>> that but >>>>>>> >>>>>>>> I had much less else going on. >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> I'm not terribly familiar with Quartus. I usually just do >>>>>>> as in the >>>>>>> >>>>>>>> readme https://github.com/the-snowwhite/mksocfpga to build >>>>>>> the >>>>>>> >>>>> firmware. >>>>>>> >>>>>>>> I did have an issue before where it was building firmware >>>>>>> that >>>>>>> >>>>> wouldn't >>>>>>> >>>>>>>> boot, deleting mksocfpga and pulling it again fixed that. >>>>>>> That may >>>>>>> >>>>> even >>>>>>> >>>>>>>> have had something to do with trying to open the project >>>>>>> >> previously. >>>>>>> >>>>> Ill >>>>>>> >>>>>>>> try re-pulling it and see what happens. >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> I ran the analysis in in QP and this is what I'm seeing >>>>>>> with the >>>>>>> >>>>>>>> stepgens: >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> [image: QP.png] >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> On Monday, August 19, 2019 at 7:46:58 AM UTC-4, Michael >>>>>>> Brown >>>>>>> >> wrote: >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> Quartus Update: >>>>>>> >>>>>>>>> After compiling (the default DE10_Nano_FB_Cramps project) >>>>>>> Notice >>>>>>> >>>>> that >>>>>>> >>>>>>>>> all 9 (0-8) stepgens instansiated in the pin file have a >>>>>>> (not >>>>>>> >> null) >>>>>>> >>>>> sized >>>>>>> >>>>>>>>> SRL16E:\steptable:0:asr16e instance: >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> [image: >>>>>>> Quartus_DE10_Nano_FB_Default_Num-Stepgens_Compiled.png] >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> On Monday, 19 August 2019 13:24:22 UTC+2, Michael Brown >>>>>>> wrote: >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> I have an older config that has worked with 8 stepgens: >>>>>>> >>>>>>>>>> hm2_soc_ol config line here: >>>>>>> >>>>>>>>>> < >>>>>>> >>>>> >>>>>>> >> >>>>>>> https://github.com/the-snowwhite/Hm2-soc_FDM/blob/master/Cramps/PY/Mibrap-X_hm3_fdm-soc/fdm/config/motion.py#L15> >>>>>>> >>>>>>> >>>>>>> >> >>>>>>> >>>>> >>>>>>> >>>>>>>>>> Have you tried with: >>>>>>> >>>>>>>>>> num_stepgens=6 in the hm2_soc_ol config line ? >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> Also You can look in the Compiled (Or after analysis & >>>>>>> >> elaboration) >>>>>>> >>>>>>>>>> Quartus project and see how many stepgens are elaborated >>>>>>> like in >>>>>>> >>>>> below pic: >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> [image: Quartus_Num_Stepgens.png] >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> On Monday, 19 August 2019 00:31:53 UTC+2, justin White >>>>>>> wrote: >>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>>>>> The hal component did work fine then my friend "cleaned >>>>>>> it up" >>>>>>> >> and >>>>>>> >>>>> it >>>>>>> >>>>>>>>>>> acts weird when you enable the filter. Could just remove >>>>>>> the >>>>>>> >>>>> filter pin and >>>>>>> >>>>>>>>>>> post it but it is rather handy. >>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>>>>> I've been tracking down an issue with the stepgens and >>>>>>> depending >>>>>>> >>>>> on >>>>>>> >>>>>>>>>>> what the issue is it may be part of the smart serial >>>>>>> issue. I >>>>>>> >> have >>>>>>> >>>>> 4 out of >>>>>>> >>>>>>>>>>> 6 stepgens that work, on my 5th stepgen only the >>>>>>> direction pin >>>>>>> >>>>> works, not >>>>>>> >>>>>>>>>>> the step pin. Neither work on the 6th stepgen. I >>>>>>> disabled SS >>>>>>> >> for >>>>>>> >>>>> the time >>>>>>> >>>>>>>>>>> being but it was using consecutive pins with the 5th and >>>>>>> 6th >>>>>>> >>>>> stepgens. It >>>>>>> >>>>>>>>>>> was difficult to see what was going on until I got my >>>>>>> GUI setup. >>>>>>> >>>>> Now I can >>>>>>> >>>>>>>>>>> see that in hal it is actually working and I'm getting >>>>>>> feedback >>>>>>> >> to >>>>>>> >>>>> the PID >>>>>>> >>>>>>>>>>> loop but the pins of the Nano itself do not electrically >>>>>>> do >>>>>>> >>>>> anything, I can >>>>>>> >>>>>>>>>>> verify that with my scope. Thinking maybe I damaged the >>>>>>> GPIO >>>>>>> >> pins >>>>>>> >>>>> from all >>>>>>> >>>>>>>>>>> the hardware swapping I've been doing, I picked up >>>>>>> another DE10 >>>>>>> >>>>> Nano and >>>>>>> >>>>>>>>>>> the same thing happens. I tried swapping stepgen >>>>>>> instance 0,1 >>>>>>> >> for >>>>>>> >>>>> 4,5 in >>>>>>> >>>>>>>>>>> the .vhd and rebuilt the firmware without changing any >>>>>>> hal >>>>>>> >>>>> configuration >>>>>>> >>>>>>>>>>> and stepgens 4 and 5 work fine if they are controlling >>>>>>> different >>>>>>> >>>>> GPIO pins >>>>>>> >>>>>>>>>>> without making any hal changes. I jumped the GPIO pins >>>>>>> for a >>>>>>> >>>>> working >>>>>>> >>>>>>>>>>> stepgen to the PCB pins I use for 4 and 5 and the >>>>>>> interface >>>>>>> >>>>> hardware works >>>>>>> >>>>>>>>>>> fine that way. >>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>>>>> So the conclusion I'm drawing is that there's an issue >>>>>>> with the >>>>>>> >>>>>>>>>>> firmware that's getting built. hm2 thinks all 6 stepgens >>>>>>> are >>>>>>> >> there >>>>>>> >>>>> but >>>>>>> >>>>>>>>>>> there is only 4 1/2 stepgens actually working. I seem to >>>>>>> recall >>>>>>> >>>>> there is a >>>>>>> >>>>>>>>>>> parameter that has to change to add a certain amount of >>>>>>> certain >>>>>>> >>>>> pin types, >>>>>>> >>>>>>>>>>> but I didn't think it applied in this case and I'm not >>>>>>> sure what >>>>>>> >>>>> it is. >>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>>>>> My current VHD with SS disabled attached >>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>>>>> On Saturday, August 17, 2019 at 6:40:07 AM UTC-4, >>>>>>> Michael Brown >>>>>>> >>>>> wrote: >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> OK back to being able to be online with my workstation: >>>>>>> >>>>>>>>>>>> I have allways had a fight setting up proper display >>>>>>> >> resolutions >>>>>>> >>>>> on >>>>>>> >>>>>>>>>>>> the altera soc's however I can give you some key notes: >>>>>>> >>>>>>>>>>>> In qsys there are 3 cores to consider: >>>>>>> >>>>>>>>>>>> For display timing settings: >>>>>>> >>>>>>>>>>>> alt_vip_vfr_hdmi (framereader) >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> alt_vip_itc_0 (Clocked video output) >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> The display core clock itself: >>>>>>> >>>>>>>>>>>> pll_lcd --> lcd_clk >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> 1600x900 would allow me to test it out on my mill and >>>>>>> I might >>>>>>> >>>>> have a >>>>>>> >>>>>>>>>>>>> use for 800x480. I didn't realize the resolution was >>>>>>> fixed, my >>>>>>> >>>>> 1080P >>>>>>> >>>>>>>>>>>>> monitors don't have a problem displaying 1024x768, all >>>>>>> my >>>>>>> >> other >>>>>>> >>>>> monitors >>>>>>> >>>>>>>>>>>>> do. I suppose in a real usage scenario I'd have to >>>>>>> look >>>>>>> >> further >>>>>>> >>>>> into your >>>>>>> >>>>>>>>>>>>> previous reply and try to figure out how to set a >>>>>>> resolution >>>>>>> >> for >>>>>>> >>>>> whatever >>>>>>> >>>>>>>>>>>>> monitor I intended to use. >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> Sadly there are currently no presets for these 2 >>>>>>> resolutions >>>>>>> >> for >>>>>>> >>>>> the >>>>>>> >>>>>>>>>>>> framebuffer related cores (presets are found in qsys >>>>>>> view >>>>>>> >> menu), >>>>>>> >>>>> as I >>>>>>> >>>>>>>>>>>> havent had use of these resolutions myself (in newer >>>>>>> time). >>>>>>> >>>>>>>>>>>> And I also have no (qsys) formula other than intuitive >>>>>>> guess >>>>>>> >>>>> work..... >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> Last there is the Devicetree entry this is the current >>>>>>> one: >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>> >>>>>>> >> >>>>>>> https://github.com/the-snowwhite/soc-image-buildscripts/blob/master/SD-Image-Gen/patches/4.9.76-ltsi-rt/current/0012-Added-DE-10-Nano-with-uio-with-without-framebuffer-1.patch#L291 >>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> This entry: >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> vip@0x100031000 { >>>>>>> >>>>>>>>>>>> compatible = "altr,vip-frame-reader-1.0", >>>>>>> >>>>> "ALTR,vip-frame-reader-9.1"; >>>>>>> >>>>>>>>>>>> reg = <0x00000001 0x00031000 0x00000080>; >>>>>>> >>>>>>>>>>>> max-width = <1024>; >>>>>>> >>>>>>>>>>>> max-height = <768>; >>>>>>> >>>>>>>>>>>> bits-per-color = <0x8>; >>>>>>> >>>>>>>>>>>> colors-per-beat = <0x4>; >>>>>>> >>>>>>>>>>>> beats-per-pixel = <0x1>; >>>>>>> >>>>>>>>>>>> mem-word-width = <0x80>; >>>>>>> >>>>>>>>>>>> }; >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> On Friday, 9 August 2019 03:55:13 UTC+2, justin White >>>>>>> wrote: >>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> On Tuesday, August 6, 2019 at 1:07:38 PM UTC-4, >>>>>>> Michael Brown >>>>>>> >>>>> wrote: >>>>>>> >>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>> Not very easy from my cell phone here however: >>>>>>> >>>>>>>>>>>>>> In qsys there are 2 instances where you set up the >>>>>>> timings >>>>>>> >> for >>>>>>> >>>>> the >>>>>>> >>>>>>>>>>>>>> screen monitor. There should be some saved setups HD >>>>>>> etc. >>>>>>> >>>>> Lastly you need >>>>>>> >>>>>>>>>>>>>> to place the correct screen settings in the device >>>>>>> tree there >>>>>>> >>>>> is a HD >>>>>>> >>>>>>>>>>>>>> example there too. 1920 x1080. Sorry for not being >>>>>>> online >>>>>>> >>>>> atm... >>>>>>> >>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> Gonna Give this a try soon as I get a chance. Waiting >>>>>>> for my >>>>>>> >>>>> friend >>>>>>> >>>>>>>>>>>>> to correct a minor issue with the time based filter in >>>>>>> the RT >>>>>>> >>>>> hal component >>>>>>> >>>>>>>>>>>>> he whipped up for me for the ADC then I'll post it up >>>>>>> here. >>>>>>> >>>>> Maybe you can >>>>>>> >>>>>>>>>>>>> include it in your project if you think it's useful. >>>>>>> It >>>>>>> >>>>> certainly is for >>>>>>> >>>>>>>>>>>>> someone like me who only works with hal. >>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> Well It would be nice with a hal rt component for >>>>>>> calculating >>>>>>> >>>>>>>>>>>> temperature readings based on ntc probes instead of the >>>>>>> python >>>>>>> >>>>> user >>>>>>> >>>>>>>>>>>> component hal_temp_atlas I derived from the >>>>>>> hal_temp_bbb .... >>>>>>> >> :-) >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>> >>>>>>> >>>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> -- >>>>>>> >>>>> Charles Steinkuehler >>>>>>> >>>>> [email protected] >>>>>>> >>>>> >>>>>>> >>>> >>>>>>> >>> >>>>>>> >> >>>>>>> >> >>>>>>> >> -- >>>>>>> >> Charles Steinkuehler >>>>>>> >> [email protected] <javascript:> >>>>>>> >> >>>>>>> > >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Charles Steinkuehler >>>>>>> [email protected] >>>>>>> >>>>>> -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/b7022444-091b-460b-bdff-1b2366e6b03a%40googlegroups.com.
