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>; >>>>>>>>>> >>>>>>>>>>>> }; >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> -- 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/b49a0002-d3a3-4381-8f21-3fef269799e6%40googlegroups.com.
