OK I noticed: uartx8:\makeUARTTXs:0:auartx 25.9 (25.9) 28.7 (28.7) 2.8 (2.8) 0.0 (0.0) 0.0 (0.0) 46 (46) 47 (47) 0 (0) 0 0 0 0 0 SRL16E:\fifosrl:0:asr16e
Were Empty, so I'm currently compiling a correction to the uart tx wireing mishap. brb in 12 min or so... On Thursday, 22 August 2019 18:50:12 UTC+2, justin White wrote: > > I dropped my ADC component on git. This is still the version with the > problematic filter, but I figure this would make it easier for my friend or > anyone else with interest to fix that portion > https://github.com/blazini36/ST_DC1-configs/tree/master/ADC_component > > On Thursday, August 22, 2019 at 11:04:23 AM UTC-4, justin White wrote: >> >> The pin comments in the .vhd were a little messed up due to the changes I >> was making on board revs, copy/paste only goes so far lol. The actual pin >> assignments and "function" comments are all correct with the possible >> exception of the SS pins, can't speak on that until I actually see it work. >> I sorted the pins out based on convenient PCB layout rather than intuitive >> config files. You'll have to excuse me if I do something silly on Github, I >> haven't really hosted any projects before. >> >> Definitely getting somewhere with SS, I added your firmware and I can >> verify from the log file that it now instantiates as "version 43" which is >> the version that my Mesa boards on my standard LinuxCNC machines. I briefly >> tested it and I can't verify any communication though, No new 8i20 pins >> showed up in hal when I connected it to my 8i20. SS is kind of tough to >> debug on the user end, there's really not much visibility as to what is >> going on that I'm aware of. It could be a hardware issue yet, I don't have >> a convenient means of testing SS, right now I take the nano down to my >> mill, plug it in and hope for the best. Now that I have another nano on >> hand I can probably get something setup a little better when I get a >> chance. >> >> >> >> >> >> On Thursday, August 22, 2019 at 7:29:46 AM UTC-4, Michael Brown wrote: >>> >>> OK >>> Besides adding SSerial and your config, I have updated the GPIO pin >>> names from 1-36 to 0-35, >>> I noticed something odd with the pin naming of GPIO_0 in your pin file, >>> so I was unable to update that. >>> Could you explain/clean up those gpio and pin names/numbers ? >>> Is your pin config now final ? >>> >>> Lastly I will push the commits, >>> and create a pr for the SSerial and your config addition after your >>> sucessfull test reports. >>> After sucessfull online build your bitfile will show up in the >>> socfpga-rbf package for both De0 and DE10 board variants. >>> >>> Currently the (now hopefully) whole project is here: >>> https://github.com/the-snowwhite/mksocfpga/tree/sserial-work >>> >>> >>> On Thursday, 22 August 2019 12:52:29 UTC+2, Michael Brown wrote: >>>> >>>> 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>; >>>>>>>>>>> >> >>>>>>>>>> >>>>>>>>>> -- 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/0ec0fdf2-f896-4dde-b3f2-2b28d68b5558%40googlegroups.com.
