SSerial doesn't take any commands directly as far as I'm aware, the host card initiates a handshake then treats it as an extension of it's own hal instance once it's identified. Just needs a config line like this: CONFIG="num_encoders=6 num_stepgens=6 enable_adc=1 *sserial_port_0=00xx*"
The only thing you should see is on start of MK, the Tx line should throw a 0xDF with a cyclic redundancy check, then the remote will respond with whatever it's programmed to respond with, in this case you obviously won't get a response. Not 100% sure what that's supposed to look like but attempt at communication on the line should be obvious. Once the SSerial Remote is found it becomes part of the host instance i.e., there will be hal pins like "hm2_5i25.0.8i20.0.1.current-maxlim" On Saturday, August 24, 2019 at 4:17:14 AM UTC-4, Michael Brown wrote: > > Can you post the exact hal commands for probing the tx line here ? > I have a Pisoscope 3206D MSO, so I can test that on my (Dev) DE10_Nano > > > On Friday, 23 August 2019 23:53:58 UTC+2, justin White wrote: > > Still no go for SS on the 8i20. Can anyone confirm that SS actually works > in MK or any of these DExx configs, like has anyone been able to connect a > SS remote board? The only hal configuration I needed was a config line of > "sserial_port_0=00xxxx". Other than that I see that hm2 has to be brought > up with "newinst". I assume there's not much difference being compiled as > instcomp rather than legacy? > > From what I understand right now, the SS host is supposed to send a 0xDF > and recieve a 0xAA from the 8i20 in return for the handshake. If I could > get my scope going and see 11011111 directly on the Tx pin I could verify > that the SS host is doing it's job. > > On Fri, Aug 23, 2019 at 5:21 PM justin White <[email protected]> wrote: > > 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 > >>>> > > ... -- 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/400e3dc6-a2ba-4609-aa34-165ad5330cc1%40googlegroups.com.
