lol thanks, I do appreciate it
On Fri, Aug 23, 2019 at 8:56 AM Michael Brown <[email protected]> wrote: > Ups Looked like I messed up testing one of my commits: (by copying the > wrong .rbf file) > And that that commit (the one for configuring CapSense pins) was faulty.... > > rebasing .. compiling ... and re-testing now .... AArrrghh > > > On Friday, 23 August 2019 13:35:22 UTC+2, Michael Brown wrote: >> >> Looked at the manual for the 8i20 you mentioned: >> http://www.mesanet.com/pdf/motion/8i20man.pdf >> >> Page 5 specifies 2 rx and 2 tx channels .... ? >> >> >> On Friday, 23 August 2019 13:16:41 UTC+2, Michael Brown wrote: >>> >>> You forgot the reply all so I repost here: >>> >>> I tried it with the first .rbf you posted and still didn't get it to >>>> communicate. I'll try the 2nd one tomorrow. >>>> The problem at the moment is that I haven't seen my setup work with a >>>> known good SS config and the DE10-Nano config hasn't worked with known good >>>> hardware. I can't think of an easy way to test the hardware other than to >>>> scope it which I'll do if you can't find the firmware issue easily. >>> >>> >>> I thought Charles Mentioned a working setup above so I looked thru the >>> thread: >>> (Thinking you could test with that DE10_..._DB25 config) >>> REcap: >>> >>> Charles >>>> Re: [Machinekit] Re: DE10 Nano suggested development environment? >>>> On 7/7/2019 4:29 AM, Michael Brown wrote: >>>> > Looking at a 7i76e manual it's differential RS422 while the >>>> > example configs suggest at the FPGA level it's a 2 pin RX/TX >>>> deal, >>>> > is that right? One example shows a TX enable pin, but I don't >>>> > think this is implemented on a board like the 7i76e which is all >>>> > I'm trying to duplicate. Any insight on this? >>>> > >>>> > I have no experience with rs422 or rs485, but i guess yes.... >>>> RS-422 is always differential. It may be full duplex (which only >>>> requires TX and RX) or half duplex (which adds a TX-Enable signal). >>>> The 7i76 daughtercard requires two SSERIAL channels, one for the 7i76 >>>> itself (for the Field I/O signals), and one which gets exported via >>>> the TB3 connector. >>>> Both buses are full duplex and do not require a TX-Enable signal. >>>> The SSERIAL communication between the FPGA and the 7i76 is via >>>> standard digital logic levels. The 7i76 provides an RS-422 >>>> transceiver for the SSERIAL bus on TB3. >>>> >>> >>> So seems like you are missing the 2'nd SSerial in your pin config / Hw >>> setup ? >>> >>> >>> >>> On Thursday, 22 August 2019 22:36:35 UTC+2, Michael Brown wrote: >>>> >>>> I just ran a docker compilation and attach that file >>>> here.(functionality should be the same as the former file,,,(but just in >>>> case) :-) >>>> >>>> On Thursday, 22 August 2019 21:05:16 UTC+2, Michael Brown wrote: >>>>> >>>>> OK copied the new .rbf file, renamed and attached it for testing >>>>> >>>>> uartx8:\makeUARTTXs:0:auartx 75.2 (56.5) 102.7 (56.8) 27.5 (0.3) 0.0 >>>>> (0.0) 0.0 (0.0) 95 (95) 197 (63) 0 (0) 0 0 0 0 0 >>>>> SRL16E:\fifosrl:0:asr16e 3.7 (0.0) 4.8 (0.0) 1.2 (0.0) 0.0 (0.0) 0.0 >>>>> (0.0) 0 (0) 16 (0) 0 (0) 0 0 0 0 0 >>>>> look fine now >>>>> >>>>> >>>>> On Thursday, 22 August 2019 20:52:04 UTC+2, Michael Brown wrote: >>>>>> >>>>>> 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 >>>>>>>>>>>>>>>>> >>>>>>>&g >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- > 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/13817729-ea40-4746-9e3d-95113d1639f2%40googlegroups.com > <https://groups.google.com/d/msgid/machinekit/13817729-ea40-4746-9e3d-95113d1639f2%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CA%2BQ02MNtQCMuUm_qaO4ng1-rWJNHYB89F3qzaUZWfELbfm6f2A%40mail.gmail.com.
