The last one I tested was still a no go, tried to get the USB scope working but having software issues in the new PC. I did yank the 8i20 out of the mill to make it easier to test.
I'll try this one and see how it goes On Fri, Aug 23, 2019 at 4:59 PM Michael Brown <[email protected]> wrote: > So ... Latest and great .. (for)test... > Everything tested (on all my current MK setups)and working here... :-) > > Hope This config gets the SSerial working @your end ..... > > > On Friday, 23 August 2019 17:06:21 UTC+2, Michael Brown wrote: >> >> Ok >> Here: >> Everything worked execpt the capsensot (tested on my ob-ox router running >> on a DE0_), so >> reverted the CapSense pin commit (seems like I have perhaps loaded the >> pin array backwards) >> >> On Friday, 23 August 2019 16:18:41 UTC+2, Michael Brown wrote: >> >> 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 <[email protected]> >> wrote: >> >> Ups Looked like I messed up testing one of my commits: (by copying the >> wrong .rbf file) >> And that that commit (the one for configuring CapSense pins) was >> faulty.... >> >> rebasing .. compiling ... and re-testing now .... AArrrghh >> >> >> On Friday, 23 August 2019 13:35:22 UTC+2, Michael Brown wrote: >> >> Looked at the manual for the 8i20 you mentioned: >> http://www.mesanet.com/pdf/motion/8i20man.pdf >> >> Page 5 specifies 2 rx and 2 tx channels .... ? >> >> >> On Friday, 23 August 2019 13:16:41 UTC+2, Michael Brown wrote: >> >> You forgot the reply all so I repost here: >> >> I tried it with the first .rbf you posted and still didn't get it to >> communicate. I'll try the 2nd one tomorrow. >> The problem at the moment is that I haven't seen my setup work with a >> known good SS config and the DE10-Nano config hasn't worked with known good >> hardware. I can't think of an easy way to test the hardware other than to >> scope it which I'll do if you can't find the firmware issue easily. >> >> >> I thought Charles Mentioned a working setup above so I looked thru the >> thread: >> (Thinking you could test with that DE10_..._DB25 config) >> REcap: >> >> Charles >> Re: [Machinekit] Re: DE10 Nano suggested development environment? >> On 7/7/2019 4:29 AM, Michael Brown wrote: >> > Looking at a 7i76e manual it's differential RS422 while the >> > example configs suggest at the FPGA level it's a 2 pin RX/TX deal, >> > is that right? One example shows a TX enable pin, but I don't >> > think this is implemented on a board like the 7i76e which is all >> > I'm trying to duplicate. Any insight on this? >> > >> > I have no experience with rs422 or rs485, but i guess yes.... >> RS-422 is always differential. It may be full duplex (which only >> requires TX and RX) or half duplex (which adds a TX-Enable signal). >> The 7i76 daughtercard requires two SSERIAL channels, one for the 7i76 >> itself (for the Field I/O signals), and one which gets exported via >> the TB3 connector. >> Both buses are full duplex and do not require a TX-Enable signal. >> The SSERIAL communication between the FPGA and the 7i76 is via >> standard digital logic levels. The 7i76 provides an RS-422 >> transceiver for the SSERIAL bus on TB3. >> >> >> So seems like you are missing the 2'nd SSerial in your pin config / Hw >> setup ? >> >> >> >> On Thursday, 22 August 2019 22:36:35 UTC+2, Michael Brown wrote: >> >> I just ran a docker compilation and attach that file here.(functionality >> should be the same as the former file,,,(but just in case) :-) >> >> On Thursday, 22 August 2019 21:05:16 UTC+2, Michael Brown wrote: >> >> OK copied the new .rbf file, renamed and attached it for testing >> >> uartx8:\makeUARTTXs:0:auartx 75.2 (56.5) 102.7 (56.8) 27.5 (0.3) 0.0 >> (0.0) 0.0 (0.0) 95 (95) 197 (63) 0 (0) 0 0 0 0 0 >> SRL16E:\fifosrl:0:asr16e 3.7 (0.0) 4.8 (0.0) 1.2 (0.0) 0.0 (0.0) 0.0 >> (0.0) 0 (0) 16 (0) 0 (0) 0 0 0 0 0 >> look fine now >> >> >> On Thursday, 22 August 2019 20:52:04 UTC+2, Michael Brown wrote: >> >> OK >> I noticed: >> uartx8:\makeUARTTXs:0:auartx 25.9 (25.9) 28.7 (28.7) 2.8 (2.8) 0.0 (0.0) 0.0 >> (0.0) 46 (46) 47 (47) 0 (0) 0 0 0 0 0 >> SRL16E:\fifosrl:0:asr16e >> >> Were Empty, so I'm currently compiling a correction to the uart tx >> wireing mishap. brb in 12 min or so... >> >> On Thursday, 22 August 2019 18:50:12 UTC+2, justin White wrote: >> >> I dropped my ADC component on git. This is still the version with the >> problematic filter, but I figure this would make it easier for my friend or >> anyone else with interest to fix that portion >> https://github.com/blazini36/ST_DC1-configs/tree/master/ADC_component >> >> On Thursday, August 22, 2019 at 11:04:23 AM UTC-4, justin White wrote: >> >> The pin comments in the .vhd were a little messed up due to the changes I >> was making on board revs, copy/paste only goes so far lol. The actual pin >> assignments and "function" comments are all correct with the possible >> exception of the SS pins, can't speak on that until I actually see it work. >> I sorted the pins out based on convenient PCB layout rather than intuitive >> config files. You'll have to excuse me if I do something silly on Github, I >> haven't really hosted any projects before. >> >> Definitely getting somewhere with SS, I added your firmware and I can >> verify from the log file that it now instantiates as "version 43" which is >> the version that my Mesa boards on my standard LinuxCNC machines. I briefly >> tested it and I can't verify any communication though, No new 8i20 pins >> showed up in hal when I connected it to my 8i20. SS is kind of tough to >> debug on the user end, there's really not much visibility as to what is >> going on that I'm aware of. It could be a hardware issue yet, I don't have >> a convenient means of testing SS, right now I take the nano down to my >> mill, plug it in and hope for the best. Now that I have another nano on >> hand I can probably get something setup a little better when I get a >> chance. >> >> >> >> >> >> On Thursday, August 22, 2019 at 7:29:46 AM UTC-4, Michael Brown wrote: >> >> OK >> Besides adding SSerial and your config, I have updated the GPIO pin names >> from 1-36 to 0-35, >> I noticed something odd with the pin naming of GPIO_0 in your pin file, >> so I was unable to update that. >> Could you explain/clean up those gpio and pin names/numbers ? >> Is your pin config now final ? >> >> Lastly I will push the commits, >> and create a pr for the SSerial and your config addition after your >> sucessfull test reports. >> After sucessfull online build your bitfile will show up in the >> socfpga-rbf package for both De0 and DE10 board variants. >> >> Currently the (now hopefully) whole project is here: >> https://github.com/the-snowwhite/mksocfpga/tree/sserial-work >> >> >> On Thursday, 22 August 2019 12:52:29 UTC+2, Michael Brown wrote: >> >> OK >> now: >> MakeSSerials:\GenMakeSSerials:MakeSSerials 649.0 (6.2) 805.6 (6.2) 159.6 >> (0.0) 3.0 (0.0) 0.0 (0.0) 748 (12) 1129 (0) 0 (0) 40960 5 0 0 0 >> Entity instance magicially appears in Quartus after full compile. >> >> next I'll run the docker compilation and post the bitfiles here >> >> On Thursday, 22 August 2019 10:26:57 UTC+2, Michael Brown wrote: >> >> Yeah comes to mind the DExx_Cramps projects run on a reduced >> configuration so only the needed cores are added/included (the one's in the >> current configs) so... >> SSerial core needs to be included. >> I'll do that asap. >> >> On Thursday, 22 August 2019 03:53:39 UTC+2, justin White wrote: >> >> I threw the new FW on the nano and the stepgens are all working now. >> Still no SS but I suppose that was to be expected. As PCW said, since the >> version prints as "0", the SS CPU must be broken. >> >> On Wednesday, August 21, 2019 at 3:25:53 PM UTC-4, justin White wrote: >> >> Well that makes sense, my SS pins were on GPIO1_00 and GPIO1_01, Stepgens >> start on GPIO1_02 so it might explain quite a bit. >> >> I would have tested it out a bit earlier but I went full nerd yesterday >> and built a 3900x/5700xt system I've been working on getting running. I got >> quatus installed and used the config files you attached and I see all of >> the stepgens are now full. Going to build the .rbf and set it back up to >> test SS again......hopefully it all just....works lol >> >> thanks fellas >> >> On Tuesday, August 20, 2019 at 2:06:34 PM UTC-4, Michael Brown wrote: >> >> Note: >> It did really help to have your full quartus project online to play with, >> that was probaly what immediately triggered my internal >> analyzer/debugger.... :-) >> >> On Tuesday, 20 August 2019 19:54:02 UTC+2, Michael Brown wrote: >> >> Valid Files Here: >> >> On Tuesday, 20 August 2019 19:50:53 UTC+2, Michael Brown wrote: >> >> Ups Sorry sorry sorry ... my BAD .... (Suddently my biain kicked in :-) ) >> I should have spotted it immediately. >> Culprit is due to my single experimental (verilog) added capasitive >> depth/touch sensor core. >> This is not a part of the "original mesa hm2 vhdl config system, and the >> pins are hardwired to: >> GPIO_1 pins 00 + num sense parameter. (if that exact core is enabled in >> config file) >> --- >> Solution is very simple: >> edit mksocfpga/HW/hm2/config/DExx_Nano_xxx_Cramps/ >> atlas_st_fpga_soc_dc1f_ss.sv >> --> parameter Capsense = 0; >> >> I have tested with: >> (StepGenTag, x"02", ClockLowTag, x"06", >> StepGenRateAddr&PadT, StepGenNumRegs, x"00", StepGenMPBitMask), >> >> and all >> SRL16E:\steptable:1:asr16e 4.2 (0.0) 8.5 (0.0) 4.3 (0.0) 0.0 (0.0) 0.0 >> (0.0) 5 (0) 17 (0) 0 (0) 0 0 0 0 0 >> entities show up populated. >> :-) >> once again excuse for my temporary brain paralysys.. >> ... >> >> On Tuesday, 20 August 2019 16:30:50 UTC+2, Charles Steinkuehler wrote: >> >> Dig through the synthesis log (*.map.rpt) a bit and look for warnings >> that indicate undriven nets. Sadly, most tool chains consider >> undriven signals a warning vs. an error, so they'll happily optimize >> away huge chunks of your design. A typical warning would look >> something like: >> >> Warning (10541): VHDL Signal Declaration warning at >> HD_Core_CycloneV_pipen1b.vhd(45): used implicit default value for >> signal "clk250_out" because signal was never assigned a value or an >> explicit default value. Use of implicit default value may introduce >> unintended design optimizations. >> >> In vim, I use the regex: ^Warning.*$ which highlights the whole line >> (if you're in GUI mode). >> >> Note you will see lots of other warnings, most of which are probably >> OK. In particular, the ever present: >> >> Warning (10036): Verilog HDL or VHDL warning at >> HD_Core_CycloneV.vhd(471): object "HDMI_clk" assigned a value but >> never read >> >> ...is (usually) perfectly OK, it's similar to an unused variable in >> "C". This _might_ be an actual error (if the signal was supposed to >> go somewhere) but is typically OK. >> >> On 8/20/2019 9:09 AM, justin White wrote: >> > Thanks for the advice Charles. Actually I use this project: >> > >> https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects/DE10_Nano_FB_Cramps >> > >> > Michael explained it has more functionallity than the DB25 project, so >> I've >> > never tried the DB25. >> > >> > Not really up on my git stuff, I forked master and slapped my config >> files >> > in, like I said these are modifications of the "3x24_cap_enc" config. >> > https://github.com/blazini36/mksocfpga >> > >> > The pin assignments are so different from anything else I can't imagine >> > it's looking at another pinfile, it's likely I just didn't modify >> something >> > I probably should have. I'll try to look into your suggestions a bit >> later. >> > >> > >> > On Tuesday, August 20, 2019 at 9:41:57 AM UTC-4, Charles Steinkuehler >> wrote: >> >> >> >> It sounds like the synthesis tools are optimizing away the stepgen >> >> logic, almost certainly because of an issue with signal connectivity >> >> to the top level I/O pins. The actual step accumulator is still >> >> generated because it's value gets read back via the register >> >> interface, but the steptables are only needed to generate the output >> >> signals so they're getting optimized away. >> >> >> >> Is your project checked into github somewhere I can grab it? I can >> >> try building in the desktop Quartus tools and see what's wrong. >> >> >> >> Otherwise, double-check the pin assignments the top-level I/O port >> >> definitions, and make sure the physical I/O pins are properly >> >> connected to the hm2 instance. >> >> >> >> I took a quick look at the project I think you're using: >> >> >> >> >> >> >> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/ >> >> >> >> ...and the top-level stuff looks OK at first glance. The important >> >> part is the use of the correct PIN_<config> library, which gets called >> >> out here: >> >> >> >> >> >> >> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/hostmot2_cfg.vhd.in#L74 >> >> >> >> Make sure in your working copy the hostmot2_cfg.vhd file is getting >> >> generated with the correct name in the "use" line, and make sure the >> >> pin file you're including in the project has proper values for IOWidth >> >> and IOPorts. >> >> >> >> You can dig through the first part of the compile log messages to >> >> verify the correct PIN file is _really_ getting analyzed and not some >> >> other file. >> >> >> >> I'm also not sure how mixing the system verilog config files with VHDL >> >> packages works (I know just enough Verilog to generally be able to >> >> transcode it to VHDL). If there's any problems with that, Michael B. >> >> will have to comment. >> >> >> >> On 8/20/2019 8:04 AM, justin White wrote: >> >>> I deleted my mksocfpga directory and re-pulled it and I get the same >> >>> results after building the .rbf. >> >>> >> >>> Still not quite sure what's going on, though I did catch something in >> >>> Quartus. Using "0A" for stepgens in the pinfile creates 10 stepgens, >> >> but >> >>> only the first 4 seem to be complete. #4 (the 5th stepgen) when >> expanded >> >>> shows blank resources for "SRL16E:\steptable:0:asr16e", but does show >> >>> resources for "SRL16E:\steptable:1:asr16e". On every stepgen after >> they >> >> are >> >>> both blank which looks like it mimics exactly the problem I'm having. >> If >> >> "steptable:1" >> >>> relates to the dir pin and "steptable:0" relates to the step pin, it >> >>> explains why I have a working direction pin on #4 but no step pin, >> and >> >> #5 >> >>> doesn't work at all. In this case I'd assume no later stepgens would >> >> work. >> >>> >> >>> I'm not really sure how Quartus works with the configs. I'm just >> >> dropping >> >>> the pinfile I made into the >> >>> '../mksocfpga/HW/hm2/config/DExx_Nano_xxx_Cramps' directory and >> renaming >> >>> the "atlas_3x24_cap_enc.sv" to match my pinfile, which is what I do >> >> with >> >>> the mksocfpga docker build. I don't specify a pinfile or anything >> when >> >>> running the analysis in Quartus, yet it does seem to catch the >> changes >> >> I've >> >>> made to that specific pinfile even though I don't specify anything in >> >>> Quartus, I just load the "DE10_Nano_FB_Cramps.qpf" file. >> >>> >> >>> Pics, QP1 shows all 10 stepgens, QP2 shows the difference between the >> >>> working #3 stepgen (0-3 all look the same) and #4 and #5 where the >> >> problem >> >>> starts. "combinational ALUTS" and every feild after is blank. >> >>> >> >>> [image: QP1.png] >> >>> >> >>> [image: QP2.png] >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> On Monday, August 19, 2019 at 5:00:11 PM UTC-4, Michael Brown wrote: >> >>>> >> >>>> Thanx for the clairifying Charles, I doublechecked tha line and it >> >> reads: >> >>>> (StepGenTag, x"02", ClockLowTag, x"06", >> >>>> StepGenRateAddr&PadT, StepGenNumRegs, x"00", >> >> StepGenMPBitMask), >> >>>> >> >>>> So that should be ok... >> >>>> >> >>>> On Monday, 19 August 2019 22:37:42 UTC+2, Charles Steinkuehler >> wrote: >> >>>>> >> >>>>> Actually, the NumInstances field of the ModuleRecord is defined as >> an >> >>>>> 8 bit std_logic_vector: >> >>>>> >> >>>>> >> >>>>> >> >> >> https://github.com/machinekit/mksocfpga/blob/master/HW/hm2/config/IDROMConst.vhd#L839 >> >>>>> >> >>>>> In VHDL, it should throw an error if you use 06 for this value >> (VHDL >> >>>>> won't convert an integer value into a std_logic_vector without some >> >>>>> sort of type conversion). >> >>>>> >> >>>>> If you meant that you are using x"06" (an 8-bit hexadecimal value), >> >>>>> that should work fine, but you will only get 6 stepgens instead of >> the >> >>>>> 10 you'd get with x"0A". >> >>>>> >> >>>>> On 8/19/2019 3:19 PM, Michael Brown wrote: >> >>>>>> No changing numinst should work just fine >> >>>>>> >> >>>>>> On Monday, 19 August 2019 18:05:28 UTC+2, justin White wrote: >> >>>>>>> >> >>>>>>> One thing I noticed, I recall seeing this the first time I >> started >> >>>>> messing >> >>>>>>> with the .vhd's. All of the pinfiles in the DExx_Nano_xxx_Cramps >> >>>>> config use >> >>>>>>> this line for stepgens >> >>>>>>> >> >>>>>>> (StepGenTag, x"02", ClockLowTag, x"0A", >> >>>>> StepGenRateAddr& >> >>>>>>> PadT, StepGenNumRegs, x"00", StepGenMPBitMask), >> >>>>>>> >> >>>>>>> The NumInst being "0A" looked a little strange to me so I changed >> it >> >>>>> to >> >>>>>>> the actual number (06) for every pinfile I've been working with. >> >> Could >> >>>>> that >> >>>>>>> be causing an issue? >> >>>>>>> >> >>>>>>> On Monday, August 19, 2019 at 11:33:29 AM UTC-4, justin White >> wrote: >> >>>>>>>> >> >>>>>>>> On Monday, 19 August 2019 13:24:22 UTC+2, Michael Brown wrote: >> >>>>>>>>>> >> >>>>>>>>>> I have an older config that has worked with 8 stepgens: >> >>>>>>>>>> hm2_soc_ol config line here: >> >>>>>>>>>> < >> >>>>> >> >> >> https://github.com/the-snowwhite/Hm2-soc_FDM/blob/master/Cramps/PY/Mibrap-X_hm3_fdm-soc/fdm/config/motion.py#L15> >> >> >> >> >>>>> >> >>>>>>>>>> Have you tried with: >> >>>>>>>>>> num_stepgens=6 in the hm2_soc_ol config line ? >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>> Yes, my config line is: >> >>>>>>>> [HOSTMOT2] >> >>>>>>>> DRIVER=hm2_soc_ol >> >>>>>>>> BOARD=5i25 >> >>>>>>>> CONFIG="num_encoders=6 num_stepgens=6" "enable_adc=1" >> >>>>>>>> DEVNAME=hm2-socfpga0 already_programmed=1 >> >>>>>>>> >> >>>>>>>> If the stepgens=6 wasn't there hm2 wouldn't instantiate them in >> >> HAL. >> >>>>> They >> >>>>>>>> are actually completely visible and HAL seems to think they're >> >>>>> working. I >> >>>>>>>> dug up one of my first test hal files and #4 did in fact work >> with >> >>>>> that but >> >>>>>>>> I had much less else going on. >> >>>>>>>> >> >>>>>>>> I'm not terribly familiar with Quartus. I usually just do as in >> the >> >>>>>>>> readme https://github.com/the-snowwhite/mksocfpga to build the >> >>>>> firmware. >> >>>>>>>> I did have an issue before where it was building firmware that >> >>>>> wouldn't >> >>>>>>>> boot, deleting mksocfpga and pulling it again fixed that. That >> may >> >>>>> even >> >>>>>>>> have had something to do with trying to open the project >> >> previously. >> >>>>> Ill >> >>>>>>>> try re-pulling it and see what happens. >> >>>>>>>> >> >>>>>>>> I ran the analysis in in QP and this is what I'm seeing with >> the >> >>>>>>>> stepgens: >> >>>>>>>> >> >>>>>>>> [image: QP.png] >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On Monday, August 19, 2019 at 7:46:58 AM UTC-4, Michael Brown >> >> wrote: >> >>>>>>>>> >> >>>>>>>>> Quartus Update: >> >>>>>>>>> After compiling (the default DE10_Nano_FB_Cramps project) >> Notice >> >>>>> that >> >>>>>>>>> all 9 (0-8) stepgens instansiated in the pin file have a (not >> >> null) >> >>>>> sized >> >>>>>>>>> SRL16E:\steptable:0:asr16e instance: >> >>>>>>>>> >> >>>>>>>>> [image: Quartus_DE10_Nano_FB_Default_Num-Stepgens_Compiled.png] >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> On Monday, 19 August 2019 13:24:22 UTC+2, Michael Brown wrote: >> >>>>>>>>>> >> >>>>>>>>>> I have an older config that has worked with 8 stepgens: >> >>>>>>>>>> hm2_soc_ol config line here: >> >>>>>>>>>> < >> >>>>> >> >> >> >> ... > > -- > 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/27f6ecd2-1bd9-43db-a479-2c4c926541a1%40googlegroups.com > <https://groups.google.com/d/msgid/machinekit/27f6ecd2-1bd9-43db-a479-2c4c926541a1%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/CA%2BQ02MP9Ozex6bjSRgAzQw%2BMX%3DyUQb8M8CLj%3DUzgJjgq_pXqhw%40mail.gmail.com.
