Those are RS422 differential pairs. SS coming directly off of the FPGA is actually RS232, then it's split with an RS422 differential transceiver. If you ever worked with a Mesa card it's the same deal with the stepgens and encoders, everything on the card at the I/O connector is differential other that normal inputs and outputs, which is pretty much the way I do everything on my board.
This is my SS circuit, the Rx and Tx flags go back to the FPGA, then you'll see at the 6pin connector there is 4 total serial pins: [image: RS422.png] On Friday, August 23, 2019 at 7:35:22 AM UTC-4, 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 machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/9e3b4194-bb99-497b-9868-e5de845e4b75%40googlegroups.com.
