Back
[00:04:45] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/deb-cleanup cd08a72 06linuxcnc 10debian/rules.in deb: remove unused variable in debian/rules * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cd08a72
[00:04:45] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/deb-cleanup 2d167bb 06linuxcnc 10debian/rules.in deb: debian/rules doesn't need to care about BUILD_SYS * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2d167bb
[00:04:45] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/deb-cleanup 95fdd52 06linuxcnc 10debian/.gitignore deb: dont .gitignore package-dirs we no longer build * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=95fdd52
[00:04:46] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/deb-cleanup 0d7457a 06linuxcnc 10debian/control.in deb: get rid of ancient Provides in control * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0d7457a
[00:06:51] <CaptHindsight> jepler: we are going to test /dev/cpu_dma_latency and see if it has any effect on RTAI
[00:15:02] <memleak> makes latency worse by several million
[00:15:15] <memleak> (ns)
[00:19:56] <memleak> well it did, now its not doing anything. one moment..
[00:26:09] <linuxcnc-build> build #2358 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2358 blamelist: Jeff Epler <jepler@unpythonic.net>, dummy
[01:08:32] <memleak> after futher testing, with radeon kms on northern islands it stays around 30 microseconds
[01:08:52] <memleak> without it, it stays around 50 or 60 microseconds
[01:09:00] <memleak> referring to /dev/cpu_dma_latency 1 vs 0
[01:09:16] <memleak> (writing 0 improves latency results)
[07:08:02] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 62f34ef 06linuxcnc 10src/Makefile 03src/hal/drivers/mesa-hostmot2/hm2_spi.c hostmot2: support boards on spi interface * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=62f34ef
[07:51:19] <jepler> weird, one of the SPI transactions is just the command 0000a800 with no payload
[07:51:22] <jepler> must be a bug
[07:53:52] <jepler> (I think that's 'read 0 words starting at 0000 with increment')
[08:26:59] <jepler> I wish I could find accurate info about what header to use to mate with the u3's 2mm-pitch headers
[08:27:36] <jepler> the part I chose does not stay snug on its own like .100 headers do
[08:28:20] <jepler> the odroid makers do not say what the part is on the u3 side, and they give inaccurate information about what it is on the side of their own i/o board
[08:28:45] <jepler> (bom gives a part number but the length of pins is obviously not what they show in the photos)
[08:29:13] <jepler> maybe they don't mate tightly anyway; they say you MUST use a metal spacer between the boards, which would also keep it from all just falling apart
[08:32:55] <jepler> pcw_home: so you think I should put 82ohm series termination resistors on all the outputs (cs/, clk, mosi) and no termination on miso?
[08:49:30] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 0d7457a 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0d7457a
[08:50:05] <KGB-linuxcnc> 05seb/master/deb-cleanup 0d7457a 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0d7457a
[09:30:42] <jepler> cradek: oshpark does do 4-layer boards but they're more expensive
[09:31:30] <jepler> $10/in2 instead of $5/in2
[09:33:07] <CaptHindsight> jepler: what length are the pins on the 2mm headers? I can search by parameters
[09:33:34] <jepler> (for 3 copies, so it's really $3.33 and $1.66/in2; for "medium runs" of at least 150in2 they go down to $2 and $1/in2)
[09:34:31] <jepler> CaptHindsight: I don't know :-/ I don't have their I/O board, just a photograph
[09:35:10] <jepler> CaptHindsight: I haven't done much with 2mm headers, is it typical that they are a much looser fit than the .100 headers I'm used to?
[09:36:02] <CaptHindsight> jepler: if they are square post then they are friction fit just like the .100 headers you are used to
[09:36:46] <jepler> I suspect that the posts on the male headers I ordered may just be too short
[09:37:01] <jepler> the ARM board has female 2mm headers but they don't publish a bom
[09:37:26] <jepler> the I/O board has male 2mm headers that they say are CON-A3B-8PA-2DSA
[09:38:19] <jepler> which has a 3.5mm height, .5x.5mm square post
[09:38:41] <jepler> but from the pictures, it can be seen that they're longer than 3.5mm
http://www.hardkernel.com/main/products/prdt_info.php?g_code=G138760240354&tab_idx=1
[09:39:07] <jepler> more on the order of 6mm, but that's just an estimate
[09:39:55] <CaptHindsight> yes, or longer
[09:40:32] <jepler> and of course we know that the spacer they use is 11mm
[09:41:38] <jepler> I assume the 11mm distance was driven by needing to clear any parts on the bottom side of the U3, and they bought the headers accordingly
[09:42:24] <jepler> (top side the way they assemble it with the I/O board)
[09:45:21] <memleak> any idea why latency-test and RTAI testsuite show two completely different latency results?
[09:45:48] <jepler> memleak: we've talked about various reasons, want me to review the ones I know about?
[09:45:59] <memleak> yes please!
[09:46:16] <jepler> * rtai kern/latency has a different CPU selection algorithm than LinuxCNC (rtai binds to CPU 1, LinuxCNC binds to last CPU)
[09:47:01] <jepler> * rtai kern/latency measures "actual time minus nominal time", while linuxcnc latency-test measures "(this time - last time) - nominal_time"
[09:47:25] <jepler> * rtai kern/latency has 1 thread, by default linuxcnc latency-test has two threads
[09:47:33] <jepler> those are the three main items I know of
[09:47:41] <memleak> ok thanks
[09:47:54] <jepler> for the rtai we ship, it might be worth changing the kern/latency CPU selection algorithm so it's the same as LinuxCNC
[09:48:27] <jepler> in linuxcnc, we should probably change our latency-test to use (actual - nominal) like kern/latency, except rtapi has no API for "get nominal time of this thread invocation"
[09:48:46] <jepler> (rtai does, and uspace could, but rtapi has never exposed this number)
[09:48:48] <memleak> or make linuxcnc use the RTAI cpu algorithm considering results are only bad in linuxcnc
[09:50:23] <memleak> (instead of vice versa)
[09:50:57] <CaptHindsight> jepler: what I could find in stock at Digikey was only 5mm length pins
http://tinyurl.com/kjpswpl
[09:50:58] <jepler> except for how it interacts with isolcpus=, why should any choice of CPU be different than another?
[09:51:43] <memleak> thats what im wondering. it shouldnt matter. maybe its one of the other two reasons.
[09:52:16] <memleak> how difficult would it be to make it measure latency the same way and run on two threads?
[09:52:21] <jepler> CaptHindsight: what I have is 951208-8622-AR (4.4mm)
[09:52:54] <jepler> CaptHindsight: thanks for looking
[09:55:07] <CaptHindsight> jepler: anything over that length is non-stock :(
[09:56:34] <CaptHindsight> you could just make some longer ones, cut square posts to length
[09:58:32] <jepler> fabricating my own pin headers doesn't sound like an enjoyable use of time
[10:01:16] <CaptHindsight> solder in the pins, snip to length
[10:05:02] <jepler> where do I get 0.5mm square stock?
[10:05:10] <CaptHindsight> place pins into female header, place pcb onto pins, set required spacing, solder backside, snip off excess pin from backside
[10:05:19] <CaptHindsight> checking on that
[10:09:06] <jepler> and of course going that route it wouldn't be nice gold and tin plating over the contact and solder areas
[10:09:30] <jepler> mouser has some hirose, harwin, and 3m headers in stock, but none with longer pins than I got the first time
[10:12:19] <CaptHindsight> do 0.64mm pins fit in to the sockets?
[10:13:18] <cradek> can you just use appropriate gauge copper wire cut to length?
[10:14:14] <CaptHindsight> what I would do for a proto and just want to test ^^
[10:14:55] <jepler> the prototype is OK, but you have to take care not to bump it
[10:15:32] <jepler> CaptHindsight: I don't know (is .64mm the typical post size of .100" headers?)
[10:15:40] <CaptHindsight> jepler: yes
[10:16:30] <jepler> I initially used these jumpers which are designed for .100 and they fit
https://www.sparkfun.com/products/12795
[10:16:46] <CaptHindsight> can you temp the board in place using hot melt?
[10:16:55] <jepler> don't want to!
[10:17:03] <CaptHindsight> keep it from vibrating loose
[10:18:29] <jepler> samtec.com will let me customize post height in .005" increments
[10:19:01] <CaptHindsight> if those fit then you can use pins from longer length pin .100 headers, it's hacky but it will work for a proto
[10:21:54] <jepler> bbl, thanks for the good ideas
[11:31:38] <pcw_home> jepler: yes: series termination on all cable driving pins is good but the clock is by far the fussiest
[11:31:39] <pcw_home> Pretty sure MMT Machrone has 2 mm headers in ~1 mm length steps from about 2 to 18 mm post heights
[11:33:06] <jepler> pcw_home: and I don't terminate MISO / 7i90's SPIOUT simply because I'm not the driving side?
[11:33:24] <pcw_home> Yes
[11:33:35] <pcw_home> thats done in the ucf file
[11:33:42] <jepler> aha
[11:33:58] <pcw_home> (setting the drive strength to 4 ma)
[11:37:01] <pcw_home> 4 ma drive ~= 100 ohm output impedance
[11:38:39] <jepler> how does that calculation work?
[11:38:58] <pcw_home> its obscure...
[11:39:09] <jepler> OK, I'll go into "taking word for it" mode
[11:40:19] <pcw_home> what 4 ma drive ~means is that it meets the standard TTL specs of 0.40v VOL with 4 mA pullup
[11:42:12] <pcw_home> so ~100 ohms max (I also looked at it driving cables with a scope)
[11:42:43] <pcw_home> note the the waveform on the driving end will be wonky with series termination
[11:43:29] <jepler> OK, I can fit that into my worldview, thanks
[11:43:41] <pcw_home> (1/2 amplitude until the echo from the fard enc of the cable comes back)
[11:43:49] <pcw_home> far end
[11:58:41] <jepler> pcw_home: I'd appreciate any comments on
http://emergent.unpythonic.net/files/sandbox/oddspi.pdf
[12:02:39] <pcw_home> looks good, you might want a option to get 5V from the 7I90 header pin 26 (ar an external source)
[12:03:11] <jepler> you mean to use 5V as the reference, or to power the regulator?
[12:03:28] <pcw_home> to power the regulator
[12:09:34] <jepler> if both rails aren't powered, the outputs are all disabled, so I'm not sure what the benefit would be
[12:11:08] <jepler> this is confusing: "During operation, ensure that VCCA <= VCCB at all times. During power-up sequencing, VCCA >= VCCB does not damage the device, so any power supply can be ramped up first.
[12:11:12] <jepler> "
[12:22:57] <pcw_home> probably just means that it wont work if VCCA>VCCB but wont damage the device
[12:24:54] <pcw_home> OK I didn't see the the Odriod can provide 5V
[12:29:28] <CaptHindsight> what is between the header pins on the 7i90 and the FPGA pads? just copper?
[12:30:54] <CaptHindsight> TXB0104 is designed to drive capacitive loads of up to 70 pF
[12:32:38] <CaptHindsight> http://www.ti.com/lit/ds/symlink/txb0104.pdf
[12:35:29] <pcw_home> Theres a quickswitch for 5V tolerance when use with EPP
[12:35:36] <pcw_home> used
[12:36:22] <pcw_home> should be no more than 15pf or so load
[12:39:23] <pcw_home> I think the quickswitch is about 5 pF, and FPGA inputs are about 8/10 pF
[13:26:14] <jepler> pcw_home: yeah, odroid is supplying 5V, not taking it as an input
[13:27:58] <pcw_home> you _could_ power the 7I90 from the adapter but one 28 ga wire is pretty spindly
[13:28:32] <jepler> pcw_home: best for any number of reasons to leave sv1.26 disconnected, I think
[13:29:43] <jepler> is there a more sensible way to draw the u3 connector's symbol so that it's understood as the source of the 5v and 1.8v supplies?
[13:30:58] <jepler> put it on the side instead of the top?
[13:33:00] <pcw_home> I dont know if there are conventions for power directions
[13:33:01] <pcw_home> (on multi sheet schematics ports can often have directions)
[13:33:23] <pcw_home> maybe just a note
[13:35:35] <jepler> I think it
[13:35:46] <jepler> 's possible, though inadvisable, to power the odroid via its 5V pin
[13:36:06] <jepler> inadvisable because you lose an overcurrent protection that exists at the power jack
[13:36:51] <pcw_home> yeah and a bit more current than you want going through a 2mm connection
[13:38:27] <jepler> so the last thing I need to do is put a pair of mounting holes on this, so I can secure the 2mm connector with some screws and spacers
[13:39:27] <cradek> 2mm connectors should be secured with #2 screws
[13:40:52] <jepler> I think you're making a joke
[13:45:33] <jepler> but the schematic says the mounting holes are 3mm diameter
[13:46:12] <jepler> which doesn't match the diameter of any of the circles on the board dxf I have
[13:46:57] <cradek> oh then use #4-40
[13:47:10] <cradek> much more common anyway
[13:47:36] <skunkworks> I tapped some 10-32 on the k&t last week
[13:47:46] <skunkworks> in cast - so that was cheating...
[13:47:57] <jepler> probably the required spacer will be some odd length
[13:51:05] <jepler> but cradek has his little lathe so he can make me some spacers to length
[13:56:13] <cradek> yes a lathe I have
[13:56:44] <cradek> but sadly I have to pull off the spindle encoder (and its mounting adapters and hardware) in order to use ww collets in it
[13:57:09] <cradek> or the 6-jaw chuck
[13:57:37] <cradek> I could fix that by making a new drawtube
[13:57:42] <cradek> but yuck
[14:07:32] <jepler> I bet I want to take care not to flex the board by tightening it down on a too-short spaer
[14:09:42] <jepler> spacer
[15:17:50] <jepler> I decided to get one of these. I hope the seller starts to make some headway on his back-orders!
https://www.tindie.com/products/gxti/laureline-gps-ntp-server/
[15:40:56] <cradek> looks cool
[15:49:07] <kwallace> Are the chips in digital (capacitive) calipers something common that could be hacked or replaced? I got a bunch of calipers with cracked LCD displays from eBay. Mine look a lot like :
https://www.flickr.com/photos/50241702@N04/5227386500/ and
https://www.flickr.com/photos/50241702@N04/5153277938/
[16:02:09] <jepler> I am not worried too much about the back-ordered status, tindie issues a refund if a backorder isn't fulfilled after 90 days
[16:02:37] <jepler> has anyone but me started having the experience that "internal" flickr links don't work the first time, but clicking them again works?
[16:02:44] <jepler> this happens to me routinely
[16:05:23] <jepler> kwallace: I had never thought about how those calipers work. It looks like it's a kind of vernier scale, with a lot of narrow capacitive sensors that move against the different scale fixed to the other jaw
[16:08:32] <PCW> I think they are kind of like a capacitive resolver
[16:09:06] <jepler> capacative touch sensor chips are cheap. this one has 12 channels.
https://www.sparkfun.com/products/9604
[16:09:36] <jepler> not sure how you could re-use the electronics package, converting the lines that drive the LCD into anything sensible would be harder than just making a custom board
[16:10:05] <PCW> I think they all have serial interfaces
[16:10:24] <jepler> these cheap digital calipers have?
[16:10:30] <PCW> yes
[16:10:39] <jepler> maybe it's easy then
[16:10:54] <kwallace> It looks like the narrow lines are grouped 1,5,9... 2,6,10... 3,7... and 4,8 so maybe quadrature sensing.
[16:10:59] <PCW> funny synchronous protocol
[16:11:16] <kwallace> http://www.shumatech.com/support/chinese_scales.htm
[16:11:38] <jepler> http://www.robotroom.com/Caliper-Digital-Data-Port/Pinout-of-imported-digital-caliper.png
[16:12:43] <jepler> I didn't spot anywhere on kwallace's board that looked like that set of 4 contacts
[16:13:57] <Tom_itx> jepler got in late.. what do you want to do with the data from the calipers?
[16:14:16] <jepler> Tom_itx: kwallace is just looking for a user for ones with broken LCDs
[16:14:29] <Tom_itx> ahh
[16:14:41] <kwallace> The link isn't to my board. I'll link it in a minute.
[16:15:29] <jepler> hm you only get about 3 samples per second
[16:15:34] <jepler> not great for positioning!
[16:16:52] <Tom_itx> i've always wanted to try to interface my fowlers but never have
[16:17:09] <Tom_itx> quite frankly, i don't wanna screw em up
[16:17:43] <PCW> one problem on some is that the battery+ is connected to the metal parts
[16:18:06] <Tom_itx> yeah i think mine may be
[16:18:27] <jepler> that will make for a surprise one day
[16:18:38] <PCW> so if you want to use the serial interface you need to expect that
[16:21:13] <kwallace> Here is the board:
http://www.wallacecompany.com/tmp/IMG_8388-1a.jpg
[16:22:23] <kwallace> The test pads at the top may be for serial, maybe. I'll have to check with an o'scope.
[16:27:36] <kwallace> http://www.ebay.com/itm/181490009318
[16:32:09] <kwallace> Unfortunately, they were shipped with all the calipers in one bunch without any padding between them, so the displays got damaged more.
[16:35:31] <kwallace> I did get three fairly good ones out of the bunch. I have some nice dial calipers I normally use but they are all in inch and I am using metric more these days.
[16:48:20] <jepler> but that's juts about the preempt-rt kernel, not really the driver's fault
[16:52:23] <PCW> well maybe the SPI drivers fault
[16:53:22] <jepler> point taken
[16:54:33] <PCW> (if the latency test is not that bad)
[16:55:06] <jepler> the mounting holes actually measured 3.35mm, I guess that's a clearance hole for an M3 screw.
[16:55:38] <jepler> I haven't let the latency test run for even 10% as long as I let hm2_spi; that's a good point.
[16:55:52] <jepler> it'll tell me if it's SPI or "just anything"
[16:56:26] <jepler> I notice in the kernel SPI driver source, it does things like turn a clock on or off in the CPU
[16:56:35] <jepler> god knows what it actually takes to do that
[16:56:47] <PCW> Yuck
[16:57:02] <jepler> I think it's a clock for an internal bus to the spi unit
[16:57:21] <jepler> but maybe it's the SPI clock itself
[16:57:52] <jepler> great if you want to add seconds and seconds to battery life .. a bad idea if you want lowest latency
[16:58:21] <PCW> yeah
[16:59:16] <PCW> well now to see if I can patch the resolver code so it runs in Spartan6 with twice the clock rate
[16:59:17] <PCW> I only vaguely remember how it works
[17:03:22] <jepler> it's sensitive to its clock, then?
[17:04:28] <PCW> well the wavegen, dacrate, spiclock rates etc are all proportional to ClockLow
[17:05:32] <jepler> another monstrosity in d8?
[17:05:34] <PCW> SSLBP read the Clocklow value from a register and calculates all its baudrate,timersettings etc but the resolver code is cruder
[17:05:58] <PCW> no its B32
[17:06:33] <PCW> 32 bit with DSP MAC
[17:07:02] <jepler> I suppose all those fpgas have got DSPs to spare
[17:07:11] <PCW> Yes
[17:07:47] <PCW> B32 is just a wider D8 really
[17:08:02] <jepler> still 16-bit instructions?
[17:08:11] <PCW> 24 bit
[17:08:20] <jepler> wider constants mostly
[17:08:21] <jepler> ?
[17:09:05] <jepler> (the design of ptasm is to store instrucions as integers, so it's just a matter of your rules whether they all happen to fit in 8, 16, or whatever number of bits)
[17:09:13] <jepler> (so that shouldn't pose a particular problem)
[17:09:34] <PCW> Yes basically
[17:10:14] <PCW> the Ethernet stuff uses a 16 bit processor with 24 bit instructions
[17:10:43] <PCW> all very similar
[17:11:16] <PCW> the resolver stuff uses no macros at all
[17:11:18] <PCW> (since I wrote it)
[17:12:00] <PCW> not even to cover up a glaring assembler limitation
[17:12:40] <jepler> I wonder why the one case they designed for the odroid allows absolutely no access to the I/O headers
[17:12:55] <jepler> grumble
[17:13:06] <PCW> (notice the funny jmpz somewhere/2 insts)
[17:13:33] <jepler> eew
[17:13:45] <PCW> cuz you'd be crazy to connect to that 1.8V stuff
[17:15:15] <jepler> well there's that
[17:15:37] <jepler> hey wait, did you just call me crazy?
[17:16:43] <jepler> I feel like I learned a lot, if only in a trite "now I know that I don't know much" sort of way :-P
[17:18:08] <PCW> how much I/O stuff is available on the Odroid?
[17:18:37] <PCW> maybe just not targeted to DIY types
[17:18:40] <jepler> PCW: not much. 3 GPIOs, 2 serial ports, and SPI.
[17:19:00] <jepler> oh the 3 GPIOs can be used as I2C too
[17:19:12] <PCW> is there decent documentation of the SPI hardware?
[17:19:20] <jepler> they have a daughterboard that has SPI EEPROM, an I2C port expander, and an AVR on the serial
[17:20:06] <jepler> (the port expander and avr are all running at more typical voltage, dunno whethre 3.3v or 5v)
[17:20:19] <jepler> PCW: I found a register-level document about it, but it's pretty opaque. and of course there's the kernel source itself.
[17:20:42] <CaptHindsight> the SPI connector wasn't even on the earlier rev board
[17:20:46] <PCW> not sure what a SPI EEPROM gets you if you already have a file system
[17:21:16] <jepler> PCW: it's an inexpensive device that lets you show that the SPI works?
[17:21:52] <PCW> thats true enough even our 16 Mbit chips are about $0.60 now
[17:22:02] <jepler> a 2mbit serial flash is just a waste of board space when you tend to have an 8GB+ main storage
[17:22:44] <jepler> hm, seb wanted one of these boards, but I think we established his u3 was the earlier revision without the spi header :(
[17:22:56] <PCW> oops
[17:23:07] <jepler> won't do him much good
[17:24:36] <PCW> what kind of numbers do you get with the latency test?
[17:25:20] <jepler> let me get this thing put back together and start one
[17:25:51] <jepler> here's when I was optimistic, but note it's only a 5-minute run:
http://media.unpythonic.net/emergent-files/01407410572/latency-odroid.png
[17:28:24] <PCW> that does look promising
[17:32:41] <jepler> well I'll let this go overnight
[17:32:50] <jepler> with spi, it was enough to just wait and the bad latencies would show up
[17:33:49] <jepler> from the point of view of trying to drive the SPI from userspace the clock activation/deactivation thing is a concern again
[17:34:13] <jepler> I think devices may share the clock, so the whole kernel would have to agree when the clock has to be running and when it may be stopped
[17:35:12] <PCW> is this all power related?
[17:35:29] <jepler> let me go look at the code and refresh my memory
[17:41:42] <jepler> it looks like the clock's status only changes when changing the transfer details (rate or width), or in response to PM events
[17:42:25] <jepler> CONFIG_PM=y
[17:42:31] <jepler> hm CONFIG_PM is on in my kernel though
[17:44:35] <jepler> yup it will runtime-suspend the spi
[17:44:36] <seb_kuzminsky> jepler: my current u3 is dedicated to the buildbot
[17:44:49] <seb_kuzminsky> i'd buy another for driving my little 3d printer with your board
[17:45:06] <jepler> supposedly I can touch files in /sys to disable that
[17:45:56] <jepler> seb_kuzminsky: aha. well, I dunno if that's a good idea yet or not
[17:46:03] <jepler> how well do you require that it work?
[17:46:17] <seb_kuzminsky> yeah i'll hold off until you show me the awesome
[17:47:40] <jepler> they'll probably stop manufacturing the u3 by then :-/
[17:48:37] <seb_kuzminsky> i won't lose any sleep over that possibility
[17:48:54] <CaptHindsight> anyone have an imx6 board with a PCIe slot?
[17:52:38] <jepler> wow if you really want your latency graph to look good, uncheck ylogscale
[17:54:37] <CaptHindsight> PCW: do you see any issues getting a
http://www.imx6rex.com/ with a PCIe-mini to PCIe adapter to the 6i25 to work?
[17:56:13] <PCW> probably not (Ive run PCIE over a short bit of cat5)
[17:57:02] <CaptHindsight> anything x86 specific in the drivers?
[17:58:01] <PCW> Not sure, I kind of doubt it though
[18:00:20] <PCW> ok resolver code patched, but will it blend?
[18:08:24] <jepler> this connection is getting extremely moody
[18:08:55] <jepler> I hope I haven't actually damaged the contacts in the u3's female header by having the connected pins waggling back and forth
[18:09:08] <jepler> last night it worked mostly, now it doesn't work unless I press down firmly all the time
[18:11:31] <CaptHindsight> jepler: longer pins will probably fix it, durability on headers is <100 cycles insertion removal until the contacts start losing their spring
[18:12:12] <jepler> I guess I should order some spare headers and be prepared to desolder these ones
[18:12:49] <PCW> 2mm female headers are pretty fragile
[18:13:27] * jepler thinks back to the "# insertions vs pins remaining" graph in the famous write-only-memory datasheet
[18:14:20] <jepler> anyway, after minutes and minutes of good latency-histogram output I switched to testing the spi driver again
[18:14:36] <jepler> and it immediately got a watchdog error followed by realtime error
[18:15:15] <jepler> so it's possible that the dodgy connection causes watchdog error causes relatime error
[18:15:26] <jepler> or that the kernel spi driver is not realtime
[18:15:44] <jepler> until I have a reliable physical connection I don't think I'll be making a determination about any of that
[18:16:03] <jepler> so this is on hold again at least until I get a new board and maybe replace the u3-side connectors
[18:16:19] <jepler> back to running latency-histogram
[18:16:24] <jepler> afk
[18:27:48] <seb_kuzminsky> still awesome progress jepler, it's been fun to read along with
[18:29:14] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master bc3ea43 06linuxcnc 10debian/configure 10debian/control.in deb: stop referring to the old "emc2" packages * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bc3ea43
[18:45:13] <memleak> jepler, your math redistributable commit has undefined references in RTAI
[18:45:51] <memleak> if you want when i get back i can look more into it and remove the references to the symbols entirely
[18:47:17] <memleak> fpmacros.c and rndint are a pain anyway to work with so i think its best to remove those
[19:03:21] <PCW> resolvers now work with Ethernet cards and 7I90, that were ugly
[19:15:39] <kwallace> BTW the top test pads on my caliper board have data on them.
http://www.wallacecompany.com/tmp/IMG_8388-1a.jpg
[19:17:36] <PCW> all the Chinese one may all use the same chip
[19:17:45] <PCW> ones
[19:27:13] <kwallace1> I would tend to agree and hope that the information on the net will save me time in getting them hooked up. I'll post my results, but it may take a week or two.
[21:00:38] <jepler> after 10ksec of latency-histogram, my odroid's latency is <40us
[21:00:59] <jepler> but as soon as I try to talk on the spi bus in realtime, the latency goes to hell, so it's not "useful" latency
[21:01:18] <jepler> this is actually better than my earlier test, probably due to using isolcpus=3 now
[21:01:58] <jepler> kwallace1: cool
[21:03:04] <jepler> memleak: hmph, you caught me: I didn't even bother to compile it that way
[21:03:16] <jepler> let alone load any modules
[21:30:29] <memleak> heh!
[21:44:13] <skunkworks> kwallace1: I think in the smithy configs there is an example of communicating to a digital caliper...
[21:57:07] <skunkworks> you may have to ask matt.. I am not seeing it but remember him talking about it\
[23:06:23] <memleak> jepler, this is as close as I could to get your commit to work:
https://github.com/NTULINUX/RTAI/commit/d2deb6292b258775b48469c58fb9d26a1cb73be0
[23:07:48] <memleak> you think its re-written enough?
[23:10:18] <memleak> also any idea why i keep getting "x.hex.high is used uninitialized in this function" ? what does x.hex.high mean so i can initialize it within the function its in?
[23:11:40] <memleak> it isnt defined anywhere, i assume its something that comes from somewhere in here:
https://github.com/NTULINUX/RTAI/blob/master/base/math/fp.h#L7
[23:11:51] <memleak> not much of a C expert as you can probably tell...
