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 >>>>>>>>>>>>>>> >>>>>>>>>>> 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 th >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- 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/685071b9-424b-47bb-ae68-4ec65c7c2f3b%40googlegroups.com.
