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/a2222c7a-d38d-419c-a721-395aeb45e3bd%40googlegroups.com.
