OK found the flaw in that commit (leading to currupt io), and was able to fix it. Expect a new bit file in about 2 docker compile times.... :-), 1/2 hour or so...
On Friday, 23 August 2019 15:56:59 UTC+2, justin White wrote: > > lol thanks, I do appreciate it > > > On Fri, Aug 23, 2019 at 8:56 AM Michael Brown <mib.ho...@gmail.com > <javascript:>> 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 machi...@googlegroups.com <javascript:>. >> 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/347c29c1-5937-40df-a6b4-6860711931af%40googlegroups.com.
