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 >>>>> >>>>> cha...@steinkuehler.net >>>>> >>>>> >>>>> >>>> >>>>> >>> >>>>> >> >>>>> >> >>>>> >> -- >>>>> >> Charles Steinkuehler >>>>> >> cha...@steinkuehler.net <javascript:> >>>>> >> >>>>> > >>>>> >>>>> >>>>> -- >>>>> Charles Steinkuehler >>>>> cha...@steinkuehler.net >>>>> >>>> -- 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/fa2d0a5e-8340-4e6e-95a4-91005880a990%40googlegroups.com.
