#linuxcnc-devel Logs

Feb 28 2018

10:25 AM andypugh_ is now known as andypugh
03:08 PM Tom_itx is now known as Tom_L
04:40 PM seb_kuzminsky: http://linuxgizmos.com/open-source-cape-opens-beaglebone-up-to-lattice-ice40-fpga/
04:40 PM seb_kuzminsky: that's the fpga supported by the open-source verilog compiler "yosys"
04:45 PM pcw_mesa: Nice to have an open source tool chain
04:46 PM seb_kuzminsky: i agree!
04:47 PM pcw_mesa: the ICE 40 chips are about equivalent to Spartan2 feature/architecture wise (though faster thsn Spartan2)
04:47 PM seb_kuzminsky: i've been thinking about trying to get linuxcnc into debian.org, and the non-free nature of the tools needed to build hostmot2 are definitely a friction point
04:48 PM seb_kuzminsky: i see, so maybe comparable to the 7i43? or a little less capable?
04:48 PM pcw_mesa: I think the biggest are about the same as the FPGA in a 7I43
04:49 PM pcw_mesa: no hardware multiply though
04:49 PM andypugh: seb_kuzminsky: But Hostmot2 is in no way an integral part of LinuxCNC. (And, in fact, the more modern boards don’t even need firmware, they come pre-flashed)
04:49 PM seb_kuzminsky: andypugh: good points
04:51 PM andypugh: “Linux can’t possibly be plugged into a closed-source router”
04:52 PM andypugh: Have you noticed that we are probably the only community in the world where if someone comes here with a problem with his “Router” we don’t know if he means a woodworking machine or network hardware?
04:53 PM seb_kuzminsky: isnt a router part of an electronics design package too? to run wires on a pcb?
04:54 PM pcw_mesa: yep
04:54 PM pcw_mesa: auto-router
05:08 PM andypugh: Hmm. That sounds unpleasantly like my problem to fix.
05:09 PM pcw_mesa: Not sure if this is in hm2_eth or sserial (just easier to see in hm2_eth)
05:10 PM pcw_mesa: I guess theres a debug option to look at all PCI read/writes to see if its there
05:11 PM seb_kuzminsky: bugs, bugs everywhere
05:11 PM pcw_mesa: this looks to be long standing
05:11 PM andypugh: Is this linked to the LCD issue do you think?
05:12 PM pcw_mesa: Could be but I also found 'f' characters in the LCD stream which I dont think belong
05:13 PM pcw_mesa: (found in the tcpdump log)
05:15 PM andypugh: Yes, that is very strange as there was no sign of them in the output of the lcd comp
05:15 PM pcw_mesa: the race condition may or may not cause an issue but it cannot really explain the 'f' when only A,B,C,D characters were supossedly sent
05:15 PM pcw_mesa: and the race condition is present in 2.7 which does not have the LCD issue
05:18 PM * pcw_mesa wishes he had a LBP16 protocol analyser
05:18 PM seb_kuzminsky: it's pretty straight-forward to write protocol analysers for wireshark/tshark
05:19 PM seb_kuzminsky: https://www.wireshark.org/docs/wsdg_html_chunked/ChDissectAdd.html
05:19 PM pcw_mesa: but its not terribly hard to find the LCD character stream since its byte aligned and always follows 81C2 045d
05:20 PM pcw_mesa: ( doublword write to sserial channel 1 USER0 reg )
05:21 PM seb_kuzminsky: oh wait, you mean to analyse the protocol between the fpga and the sserial remote, wireshark won't help much there
05:21 PM pcw_mesa: no, the ethernet stream
05:21 PM seb_kuzminsky: oh, ok that'll work then
05:22 PM pcw_mesa: thats the only reason I noticed the race bug
05:22 PM pcw_mesa: ( looking for funny characters sent to the LCD )
05:28 PM pcw_mesa: sed would be good enough for this I expect :-)
05:35 PM andypugh: I think I see what might be wrong, but I am not 100% sure.
05:35 PM andypugh: It seems too simple, and I am sure I understood this stuff a lot better in 2010 when I wrote the code than I do now.
05:36 PM andypugh: If it is this simple thing then it is amazing that smart-serial ever worked…
05:37 PM seb_kuzminsky: ah, the "disbelief that it ever worked" stage of debugging :-)
05:37 PM pcw_mesa: It may or may not be an issue depending on the relative interface and sslbp uproc speeds (and amount of data)
05:38 PM andypugh: https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/drivers/mesa-hostmot2/sserial.c#L802
05:39 PM pcw_mesa: the Ethernet interface is fast at the packet decode -->HM2 register level (about 250 ns per doubelword write)
05:39 PM pcw_mesa: so it may beat the 8 bit processor register fetches
05:39 PM andypugh: It sets up the channels with a bunch ot TRAM reads and then a TRAM write for the DoIt.
05:39 PM andypugh: It then sets up the tram reads and writes for the remotes.
05:40 PM andypugh: Which sounds to me like it will put the DoIt write higher in the TRAM list than the register writes.
05:40 PM pcw_mesa: higher meaning?
05:41 PM andypugh: Earlier
05:42 PM pcw_mesa: ahh not good
05:42 PM andypugh: Yes, so obviously wrong that I think I am missing something
05:43 PM pcw_mesa: 15:46:16.380775 IP 10.10.10.1.45380 > 10.10.10.10.27181: UDP, length 88
05:43 PM pcw_mesa: 0x0000: 4500 0074 29b6 4000 4011 e8a4 0a0a 0a01
05:43 PM pcw_mesa: 0x0010: 0a0a 0a0a b144 6a2d 0060 2890 83c2 0010
05:43 PM pcw_mesa: 0x0020: 0000 0000 0000 0000 0000 0000 81c2 000e
05:43 PM pcw_mesa: 0x0030: 0000 005a 85c2 0020 0000 0000 0000 0000
05:43 PM pcw_mesa: 0x0040: 0000 0000 0000 0000 0000 0000 81c2 005b
05:43 PM pcw_mesa: 0x0050: 0110 0000 81c2 005d 0000 0001 81c2 005e
05:43 PM pcw_mesa: 0x0060: 0000 0000 81c2 007d 0000 0000 82d1 1400
05:43 PM pcw_mesa: 0x0070: 479b b515
05:45 PM pcw_mesa: the 81c2 005b 0110 is the DoIt
05:45 PM pcw_mesa: the 81c2 005d 0000 0001 is a sserisl user 0 register write
05:48 PM andypugh: It might be as simple as switching the order of those two calls.
05:49 PM pcw_mesa: DoIt is write 0x00001001 to 5B00
05:49 PM pcw_mesa: 2 user register writes follow: 0x01000000 to User0 and 0x00000000 to User1
05:50 PM andypugh: If it has been wrong all this time, I wonder what the consequences would be of fixing it?
05:51 PM pcw_mesa: yeah surprised this didnt cause more pain&suffering on non-aligned or data wider than a byte
05:52 PM pcw_mesa: I cant see any down side (sslbp doesnt expect tha register data to changed out from under it until it completes a Xfer)
05:52 PM andypugh: I think it just means that the DoIt comes 1mS after the register writes, so the data is always one thread old
05:52 PM pcw_mesa: not guaranteed
05:54 PM pcw_mesa: because the internal processor doesnt read the registers for some small amout of time (couple usec)
05:54 PM pcw_mesa: so its a race
05:55 PM andypugh: Right, so it sees the DoIt, then starts processing registers at the same time as the driver is updating them.
05:55 PM andypugh: Yeah, that’s wrong.
05:55 PM pcw_mesa: Yes
05:55 PM andypugh: I can make a test branch for you tomorrow.
05:56 PM andypugh: I will make sure that the DoIt write ends up last in the TRAM list for each channel.
05:57 PM pcw_mesa: I know the SSLBP processor has about a 1-2 usec processing time per channel not sure of of the sequence but I would expect it to fetch data first
05:58 PM pcw_mesa: so the first channel might get stale data then the second might get fresh
05:59 PM pcw_mesa: worst case would be a bit of old and new...
05:59 PM pcw_mesa: Thanks for looking into this
06:00 PM andypugh: I should have looked into it 8 years ago. (Have I really been doing this that long?)
06:03 PM andypugh: Anyway, it will keep for a day, it’s time to sleep.
06:07 PM seb_kuzminsky: awesome, the smoking gun
06:43 PM pcw_mesa: incoming spamflood on the forum
06:46 PM mozmck: forum admin backend is really slow last couple of days.
07:03 PM pcw_mesa: thanks for cleaning that up
07:17 PM rene-dev: pcw_mesa I have a sigrok decoder for the sserial uart part, if that is of any help
07:18 PM rene-dev: I also have a lbp16 ethernet decoder :D
07:20 PM pcw_mesa: That is probably more intersting (since it possible to see by hand that Mike_Eitel SP?) has weird chars in the LCD stream at the Ethernet level
07:21 PM pcw_mesa: might make it easier to debug/illustrate the issue anyway
07:23 PM pcw_mesa: I dont know if you saw but he does have 'f's in the Ethernet data stream (LCD data bytes) so the problem appears to be a driver/component bug of some kind
07:24 PM rene-dev: ok, let me dig it out.
07:24 PM pcw_mesa: (there's a separate issue of a race condition but its present in 2.7 and the LCD issue is not)
07:25 PM rene-dev: its basically a bit of c code, that implements hm2_eth server side, and has a struct with idrom, and a few modules... even a whole smart serial state machine...
07:26 PM pcw_mesa: thanks!, you can just hand me a pointer or email it, about to take off (Dinner time here)