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 that has to change to add a certain >>>>>>>>>>>>>> amount of certain >>>>>>>>>>>>>> >>>>> pin types, >>>>>>>>>>>>>> >>>>>>>>>>> but I didn't think it applied in this case and >>>>>>>>>>>>>> I'm not sure what >>>>>>>>>>>>>> >>>>> it is. >>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>> My current VHD with SS disabled attached >>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>> On Saturday, August 17, 2019 at 6:40:07 AM UTC-4, >>>>>>>>>>>>>> Michael Brown >>>>>>>>>>>>>> >>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> OK back to being able to be online with my >>>>>>>>>>>>>> workstation: >>>>>>>>>>>>>> >>>>>>>>>>>> I have allways had a fight setting up proper >>>>>>>>>>>>>> display >>>>>>>>>>>>>> >> resolutions >>>>>>>>>>>>>> >>>>> on >>>>>>>>>>>>>> >>>>>>>>>>>> the altera soc's however I can give you some key >>>>>>>>>>>>>> notes: >>>>>>>>>>>>>> >>>>>>>>>>>> In qsys there are 3 cores to consider: >>>>>>>>>>>>>> >>>>>>>>>>>> For display timing settings: >>>>>>>>>>>>>> >>>>>>>>>>>> alt_vip_vfr_hdmi (framereader) >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> alt_vip_itc_0 (Clocked video output) >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> The display core clock itself: >>>>>>>>>>>>>> >>>>>>>>>>>> pll_lcd --> lcd_clk >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> 1600x900 would allow me to test it out on my >>>>>>>>>>>>>> mill and I might >>>>>>>>>>>>>> >>>>> have a >>>>>>>>>>>>>> >>>>>>>>>>>>> use for 800x480. I didn't realize the >>>>>>>>>>>>>> resolution was fixed, my >>>>>>>>>>>>>> >>>>> 1080P >>>>>>>>>>>>>> >>>>>>>>>>>>> monitors don't have a problem displaying >>>>>>>>>>>>>> 1024x768, all my >>>>>>>>>>>>>> >> other >>>>>>>>>>>>>> >>>>> monitors >>>>>>>>>>>>>> >>>>>>>>>>>>> do. I suppose in a real usage scenario I'd h >>>>>>>>>>>>> >>>>>>>>>>>>> -- 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/a332f526-74bb-4b3f-b1a6-6b920fe94bbc%40googlegroups.com.
