Back
[02:04:28] <memfrob> i heard jepler was working on ARM?
[02:36:20] <memfrob> heh i just realize the cubieboard2 is in the official uboot tree now..
[02:36:41] <memfrob> (as with AHCI support ive been digging for)
[06:05:09] <jthornton> nuked him!
[07:15:51] <KGB-linuxcnc> 03John Thornton 052.6 fab3679 06linuxcnc 10docs/src/gcode/overview.txt Docs: a more precise description of 5420-5428 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fab3679
[07:54:48] <jepler> jthornton: thanks and thanks
[07:56:21] <jepler> I wonder why hardkernel decided to use the SPI1 interface when SPI0 is the one with a nice deep pair of FIFOs
[07:56:24] <jepler> oh well
[07:57:12] <linuxcnc-build> build #1886 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/1886 blamelist: John Thornton <jthornton@gnipsel.com>
[07:58:12] <jepler> .. another overnight with good latency, so that's 12 hours at 2kHz
[08:09:44] <skunkworks> jepler, yay!
[08:09:54] <skunkworks> that was quite a lot of work
[08:10:26] <jepler> skunkworks: it gave me something to do in my spare time
[08:10:32] <skunkworks> heh
[08:10:52] <skunkworks> jepler, does that have onboard memory? or how are you installing the os?
[08:13:08] <skunkworks> it looks like it has emmc module socke or micorsd?
[08:13:26] <jepler> skunkworks: the hardkernel devices have a socket for a high-speed flash module (emmc) and a micro sd card slot
[08:13:40] <jepler> skunkworks: the emmc modules come with an adapter to microsd
[08:14:17] <jepler> it's pretty convenient right up until you hide it under an expansion board
[08:14:49] <skunkworks> heh
[08:36:43] <JT-Shop> jepler, your welcome
[09:20:12] <seb_kuzminsky> i thought i had fixed the apt permissions problem, guess not
[09:20:25] <seb_kuzminsky> btw, hi again, i'm back after another weekend of camping with hippies
[09:22:20] <jepler> seb_kuzminsky: welcome back. have a shower.
[09:27:47] <seb_kuzminsky> jepler: thanks! this place actually had hot showers. it was decadent
[09:34:46] <seb_kuzminsky> linuxcnc-build: force build --branch=2.6 0000.checkin
[09:34:48] <linuxcnc-build> build #2382 forced
[09:34:48] <linuxcnc-build> I'll give a shout when the build finishes
[09:35:29] <seb_kuzminsky> jepler:
http://highlab.com/~seb/monarch-lake.jpg
[09:36:36] <jepler> seb_kuzminsky: nice. I just spent the weekend cooped up watching halscope.
[09:38:35] <seb_kuzminsky> that sounds like a different kind of nice :-)
[09:39:19] <seb_kuzminsky> at one point i had to go hide from the hippies and flash an SD card for one of my little arm boards. it was therapeutic
[09:43:57] <jepler> hah
[10:18:34] <seb_kuzminsky> if there are no further issues with PR 6 i request that it be merged into master
[10:24:01] <jepler> seb_kuzminsky: I ran with it this weekend and saw that it was good
[10:31:28] <linuxcnc-build> Hey! build 0000.checkin #2382 is complete: Success [3build successful]
[10:31:28] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2382
[10:39:01] <seb_kuzminsky> jepler: cool
[10:39:11] <seb_kuzminsky> and you got spi working with good latency, that's awesome
[10:41:23] <seb_kuzminsky> maybe the rt-preempt people would be interested in your spi patchset, even if the up==mainline kernel folks are not (yet)?
[10:54:26] <jepler> seb_kuzminsky: yeah I've started a thread on linux-rt-users.
http://thread.gmane.org/gmane.linux.rt.user/12497
[10:57:36] <jepler> hm it looks like the SPI unit may be driven by a 96MHz clock, making the highest to rates available 24MHz and 48MHz
[10:57:50] <jepler> too bad I can't directly retrieve the clock actually used .. though I could instrument the kernel to print it, I think
[10:58:21] <jepler> if I unhooked the 7i90 I could scope the clock easily enough
[10:58:24] <jepler> tonight
[11:06:02] <jepler> and requesting 50MHz (probably getting 48MHz) doesn't work.. no big surprise, that's beyond the level translator's spec
[11:30:22] <KGB-linuxcnc> 03Jeff Epler 05master 9fa7053 06linuxcnc Merge branch 'seb/master/hm2-watchdog' of
https://github.com/SebKuzminsky/linuxcnc-mirror * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9fa7053
[11:48:11] <jepler> seb_kuzminsky: do you want to do any review of hm2_spi before I merge it to master?
[11:57:06] <seb_kuzminsky> i donno... does the PR come with a spi level translator board? ;-)
[11:57:56] <cradek> you two making github pull requests for each other seems a bit masturbatory
[12:02:24] <skunkworks> wow :)
[12:02:40] <memfrob> what skunkworks said
[12:04:15] <seb_kuzminsky> just trying to fit in with the cool kids
[12:04:52] <seb_kuzminsky> http://mrwgifs.com/wp-content/uploads/2013/06/How-Do-You-Do-Fellow-Kids-Reaction-Gif-Steve-Buscemi.gif
[12:18:44] <zq> is it just me or is that camera simply gorgeous
[12:29:57] <lair82_> Hello Guys, popped this question on the user chat, no feedback. I am getting this fault when trying to start from the comand line.
[12:30:04] <lair82_> "initialize: module '/home/cinci12mo/linuxcnc/python/toplevel.py' init failed: Traceback (most recent call last): File "/home/cinci12mo/linuxcnc/python/toplevel.py", line 1, in <module> import remap ImportError: No module named remap"
[12:32:31] <memfrob> does the hm2 driver work with rtnet or without it?
[12:32:36] <memfrob> i.e. does it work with preempt_rt
[12:33:41] <pcw_home> currently ist works with Preemt-rt and normal sockets
[12:33:57] <memfrob> oh ok perfect
[12:34:24] <CaptHindsight> are the 7i90's back in stock?
[12:35:09] <pcw_home> rt-net seems to have been abandoned
[12:35:36] <pcw_home> 7I90s', I think so
[12:39:38] <pcw_home> store shows 18 in stock
[12:45:50] <CaptHindsight> thanks
[13:26:14] <KGB-linuxcnc> 03Jeff Epler 05jepler/proposed-master 70bb120 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=70bb120
[13:30:27] <KGB-linuxcnc> 03Jeff Epler 05master fa91a4b 06linuxcnc Merge commit 'deb7aa4' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fa91a4b
[14:12:36] <CaptHindsight> jepler: how long is the boot up time on the odroid from power-on to boot prompt?
[14:12:52] <jepler> CaptHindsight: with the e-mmc running their ubuntu 14.04, it's something like 15s
[14:12:52] <CaptHindsight> sorry to login
[14:13:44] <CaptHindsight> memleak just got SATA going on the cubie2 \0/
[14:13:49] <jepler> oh nice
[14:14:33] <CaptHindsight> I though I already had a 7i90 but I didn't order one yet
[14:16:40] <jepler> seb_kuzminsky: so the 7i90 can connect via epp and spi. should the hal pin name reflect the connection method (hm2_7i90spi.0.xxx) or not (hm2_7i90.0.xxx)?
[14:17:01] <jepler> I think the chances of a machine with an EPP bus and an SPI bus are low, and the chances of putting a hm2_7i90 on both of them lower still
[14:25:36] <jepler> .. so a shorter name seems good
[14:25:47] <jepler> or I could call them hm2_spi.0 and not say the board's marketing name at all
[14:27:37] <jepler> that's what mesa products need: code names. The Mesa 7i90 "devourer of worlds" .. or maybe a naming theme like "cities between the 37th and 39 north parallels", giving us the Mesa 7i25 "Athens"
[14:28:28] <cradek> 5i20: "grumpy old man who thinks color tv is a fad"
[14:40:13] <seb_kuzminsky> jepler: i suppose it's *possible* to load hm2_7i90 and hm2_spi and have the last-to-load one fail to make the hal objects it wants because of name collissions
[14:59:13] <jepler> seb_kuzminsky: it seems pretty unlikely for this pair of drivers
[14:59:35] <seb_kuzminsky> mmmmaybe
[15:15:55] <jepler> anyone spot typos or have improvements to suggest?
http://paste.debian.net/118994/
[15:16:45] <seb_kuzminsky> i spot one: hm2_spi - LinuxCNC HAL driver for the Mesa Electronics Ethernet Any‐
[15:16:55] <jepler> ooh yup
[15:18:01] <seb_kuzminsky> hm2_spi doesn't run under rtai because there's no way to talk to spi stack from kernel space?
[15:18:08] <jepler> actually you could
[15:18:34] <seb_kuzminsky> "that's not what the docs say, buddy"
[15:18:51] <jepler> the docs say what you can do
[15:18:54] <jepler> for a user
[15:19:03] <seb_kuzminsky> we should probably put a u3 kernel deb on wlo
[15:19:17] <seb_kuzminsky> hm2_spi is only available when linuxcnc is configured with "uspace"
[15:19:20] <jepler> a developer who was skilled and read for 10 minutes could learn how to make it into a kernel driver
[15:19:32] <jepler> yes, that statement's accurate
[15:19:38] <jepler> the driver wouldn't work as-is in kernel space
[15:19:42] <seb_kuzminsky> ok i get it
[15:19:47] <jepler> but it could be made to work, by a developer
[15:19:55] <seb_kuzminsky> i've heard of them
[15:20:16] <jepler> "several chip select line"
[15:20:52] <jepler> not sure (A) how common multiple-CS SPI devices are or (B) whether that paragraph is clear
[15:44:58] <jepler> seb_kuzminsky: yes I would like to get a proper u3 kernel deb online somewhere. so far I think I'm building them the wrong way (cross-compiling from a kernel source tree with make-kpkg)
[15:45:39] <jepler> also I'm using ubuntu and would like to switch to debian
[15:46:00] <jepler> and I should figure out whether I can make opengl work well
[15:47:30] <jepler> (I use the odroid all via ssh, not from the console)
[15:55:55] <seb_kuzminsky> i'm running wheezy on mine
[15:56:16] <seb_kuzminsky> i also used make-kpkg because i'm a lazy bastard
[15:56:37] <seb_kuzminsky> but i wonder how much work it would be to make my rtai/linux/misc builder thingy work on arm
[15:58:45] <seb_kuzminsky> the u3 boots with uboot in flash, right? and it loads zImage and uInitrd from the vfat partition on /boot?
[15:58:49] <seb_kuzminsky> how is uInitrd made?
[15:59:13] <jepler> umm
[15:59:36] <jepler> I think that installing the kernel package makes a uInitrd
[16:00:01] <seb_kuzminsky> you made a linux-image.deb with make-kpkg and installed it and rebooted and everything just worked? neat...
[16:00:10] <jepler> nah I had to rebuild boot.scr by hand
[16:00:30] <jepler> hmm did I build uInitrd from initrd.img?
[16:00:32] <jepler> I may have
[16:01:16] <jepler> mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n initramfs -d ./initramfs-$kernelversion ./uInitrd
[16:01:19] <jepler> yeah something like this
[16:01:27] <jepler> so no, it's not automatic
[16:02:54] <jepler> biggest pain was, each time I got it wrong the only way I knew how to solve it was by pulling the emmc, mounting on a real linux machine, and putting back the old working boot.scr
[16:03:05] <jepler> I had mislaid the serial console cable so I couldn't talk to it pre-linux
[16:03:19] <jepler> I think if I had had the cable, I would have been able to interrupt uboot's automatic boot
[16:04:48] <jepler> This branch is 99956 commits ahead, 3981 commits behind hardkernel:odroid-3.0.y
[16:12:44] <jepler> I wonder if I should put out a call for maintainers of xlinuxcnc
[16:12:53] <jepler> I'm sure nobody would show up, and then we could delete it
[16:16:40] <cradek> I know it's missing some features, but is it broken?
[16:16:47] <jepler> no
[16:18:09] <jepler> it's just that, after deleting rtlinux and rtai 24.x I am all delete-happy
[16:18:25] <jepler> I can't stop thinking about where I'll score my next deletion
[16:18:30] <cradek> maybe you should sit down for a bit
[16:18:41] <jepler> party pooper
[17:01:18] <jepler> [95626.251480] [sched_delayed] sched: RT throttling activated
[17:01:22] <jepler> this is a new one
[17:02:27] <jepler> a series of weird things happened actually..
http://paste.debian.net/119013/
[17:03:26] <jepler> tmaxes didn't actually increase
[17:03:30] <jepler> or not by much
[17:06:18] <KGB-linuxcnc> 05seb/master/hm2-watchdog 47b3e95 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=47b3e95
[19:28:58] <jepler> I just booked my ticket to the houston fest! I'll be there saturday through tuesday (arriving friday / leaving wednesday)
[20:05:24] <Tom_itx> gawd i hate that airport
[20:05:49] <Tom_itx> but you won't be catching another flight there
[20:11:14] <jepler> yeah, glad not to be
[20:12:16] <Tom_itx> i swear we had to run from one end to the other to catch the next flight (same airline)!
[20:13:21] <Tom_itx> btw if they ever have it here again we have (will have) a brand new terminal by then
[20:44:44] <jepler> http://paste.debian.net/119038/
[20:44:52] <jepler> gonna disturb it to measure actual spi clocks, but that's a good run
[20:45:14] <jepler> whoops, times at
http://paste.debian.net/119039/
[20:45:21] <jepler> stepgen going at 1/s so that's 91k seconds run time
[20:45:37] <jepler> = 364 million spi transactions
[20:51:26] <jepler> hm I must be wrong about the SPI clock source. I measure the SPI clock as ~31MHz
[20:51:30] <jepler> .. and nearly sinusoidal
[20:52:12] <jepler> with a proper 100MHz scope probe on the 7i90 side of the 6"ish ribbon cable
[20:56:37] <jepler> signal swings to -.2V and +3.5v on a 3.3v supply
[21:00:08] <jepler> static int spidev_rate[MAX_BOARDS] = { [0 ... MAX_BOARDS-1] = 24000 };
[21:00:08] <jepler> RTAPI_MP_ARRAY_STRING(spidev_rate, MAX_BOARDS, "SPI clock rate in kHz");
[21:00:11] <jepler> hah, spot the error
[21:00:29] <jepler> it led to a wildly inappropriate spidev_rate
[21:06:52] <jepler> a value between 36.5MHz and 37.0MHz; and a value between 31MHz and 31.5MHz seem to be the two adjacent clocks available as simple divisors of a higher clock
[21:07:20] <jepler> those are odd values
[21:17:19] <skunkworks_> logger[
[21:17:24] <skunkworks_> logger[ps
[21:17:26] <skunkworks_> omg
[21:17:29] <skunkworks_> logger[psha]:
[21:17:29] <logger[psha]> skunkworks_: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-09-03.html
[21:20:28] <jepler> maybe it's the 880MHz "M" clock divided by 24 (36.7MHz) and 28 (31.43MHz)
[21:21:45] <jepler> if that's true, then either my scope calibration is terrible or the u3 clocksource is terrible. the scope measures 31.97MHz average
[21:22:23] <jepler> yes, a division point between two clocks is 31428 / 31429, so that must be it
[21:23:32] <jepler> yep, and 44MHz (which actually seems to work too)
[21:43:20] <jepler> pcw_home: so this is what the SPI CLK looks like at 8MHz-ish. did I fail at signal termination?
[21:43:45] <jepler> pcw_home: (the scope's own probe calibration output looks good and square-waved)
[21:45:18] <jepler> .. it seems to work fine, I was only looking at the waveform as the easiest way to find the actual SPI transmission rate
[21:50:00] <Tom_itx> do you have a logic analizer?
[21:50:16] <Tom_itx> those are quite handy for looking at data
[21:51:13] <jepler> Tom_itx: this is what I have; it's a piece of junk:
http://dangerousprototypes.com/docs/Open_Bench_Logic_Sniffer
[21:51:19] <jepler> someday I'll buy something better
[21:51:50] <Tom_itx> i'm waiting for saleae to come out with their new ones... i really like the old one i have
[21:52:14] <jepler> as infrequently as I actually do electronics it's hard to justify the expense
[21:52:35] <Tom_itx> if it was quicker i'd loan it
[21:52:49] <Tom_itx> https://www.saleae.com/
[21:53:01] <jepler> eh, don't sweat it
[21:53:09] <jepler> thanks though
[21:53:13] <Tom_itx> i forget the rate mine is but it's not up to the new standards
[21:53:22] <Tom_itx> it's just sitting in the drawer
[21:53:41] <Tom_itx> i used it to help get my programmer software working
[21:54:16] <jepler> the rate and storage specs of the open bench are not bad
[21:54:49] <Tom_itx> if it's the same one i'm thinking of, the software was the problem with it early on
[21:55:07] <Tom_itx> or lack of..
[21:55:07] <jepler> but it has no proper probes, and no control over voltage levels
[21:55:19] <jepler> the software's all java but that's life .. today it works OK
[21:55:24] <jepler> triggering is poor though
[21:55:53] <jepler> any unattached scope probes just record digital noise, rendering the "RLE" mode useless
[21:56:32] <jepler> .. noise that readily couples into adjacent channels, since they're unpaired, unshielded wire
[21:57:03] <pcw_home> To actually see the signal you probably need a passive resistor divider probe and a 50 Ohm input (a 1GHz scope would not hurt either)
[21:57:47] <Tom_itx> mine's an old analog 100Mhz
[21:58:18] <pcw_home> a 100/1 ~500 MHz probe can be done with a 4.99K 1% resistor at the end of some 50 Ohm coax
[21:58:47] <jepler> that trace is with a proper scope probe in 10x mode, not with the logic analyzer I was just busy dissing
[21:58:56] <pcw_home> _much_ better performance than any high impedance passive probe
[22:00:16] <pcw_home> a high impedance probe is not high impedance at high frequencies, a home made passive resistor divider probe is much better
[22:00:36] <jepler> ok, so the short answer is that what I'm measuring is probably not useful to measure
[22:01:05] <jepler> that's fine with me
[22:01:46] <pcw_home> a 15 pf probe has ~100 ohm reactance at 100 MHz
[22:03:55] <pcw_home> so the 50 Ohm 100/1 passive divide probe with a 5K input resistor beats the "high impedance" probe at anything more than 2 MHz
[22:04:51] <jepler> pcw_home: what's the theoretical max SPI clock of the 7i90?
[22:05:12] <jepler> ah there it is
[22:05:13] <jepler> 50?
[22:05:43] <pcw_home> depends on clock to output timing and whether the master can delay the data sampling 1/2 clock
[22:06:45] <pcw_home> I got to 50 with another spartan6 FPGA with DBSPI hm2 firmware as master
[22:07:02] <jepler> The odroid's spi module is also limited to 50MHz, and the highest clock under 50MHz that is achievable is 44MHz
[22:07:05] <jepler> .. which seems to work
[22:09:45] <pcw_home> If the SPI clock was free running and had all access control done with /CS you could go a lot faster
[22:10:26] <pcw_home> (since you could use a DCM and adjust the input and output clock phasing)
[22:10:55] <jepler> I just confirmed that the feedback clock has "180 degrees phase lagging"
[22:11:27] <pcw_home> Yeah that helps compensate for the delay
[22:11:36] <jepler> actually 270 could be selected
[22:12:13] <pcw_home> yeah skew removal...
[22:12:45] <jepler> (I mean, the choices are 0, 90, 180, 270. I'm confident it's 180 that's selected.)
[22:13:06] <pcw_home> too bad theres no standard for data dependent skew removal (sync to start bit on SPI data)
[22:13:30] <pcw_home> (MISO data)
[22:13:38] <jepler> yeah
[22:13:59] <jepler> and I haven't seen anything like the free running sclk mode you propose either
[22:14:29] <pcw_home> the BISS interface works like that (resync rx data clock on first bit)
[22:14:43] <jepler> I meant in the arm chip's datasheet
[22:15:32] <pcw_home> BISS is still a synchronous interface but the rx data is deskewed
[22:16:00] <pcw_home> since you may have along encoder cable and isolation delays
[22:19:03] <pcw_home> still dont have a DPLL stepgen config tested yet, had a fair amount of rototilling to do to include it
[22:19:04] <pcw_home> I wanted a global timer select register so had to add that and a bit to make the sample latch transparent
[22:19:06] <pcw_home> but do have a bitfile for testing tommorow
[22:20:43] <pcw_home> I dont think Ive seen any SPI hardware masters that have continuous clocks (though some A/Ds want that)
[22:22:39] <KGB-linuxcnc> 03Jeff Epler 05master ddbd05d 06linuxcnc Merge branch 'jepler/proposed-master' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ddbd05d
[22:22:47] <jepler> OK, hm2_spi in master branch. goodnight.
[22:23:01] <pcw_home> fantastic!
[22:23:26] <jepler> probably only one board in the world that can run it, until someone gets around to hacking all the SPI drivers :(
[22:23:33] <KGB-linuxcnc> 05jepler/proposed-master 70bb120 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=70bb120
[23:07:41] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 052052d 06linuxcnc 10docs/man/man9/motion.9 docs: update motion manpage with new tc.h location * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=052052d
[23:17:13] <seb_kuzminsky> jepler: here's your next fix:
[23:17:19] <seb_kuzminsky> 0 21:56:58 seb@steel /home/seb/linuxcnc.git> grep -ir RTSRCS *
[23:17:19] <seb_kuzminsky> src/Makefile:$(call ASSERT_EMPTY,$(filter-out %.c, $(RTSRCS)))
