Back
[02:32:38] <memleak> i use 4.8.3 but will switch to 4.9.2 once released and major wrong-code bugs are fixed
[02:34:02] <memleak> http://linux.slashdot.org/story/14/07/27/1838219/linus-torvalds-gcc-490-seems-to-be-terminally-broken
[02:36:53] <memleak> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 that bug is the reason why im not switching to 4.9 yet
[07:11:21] <jthornton> wiki updated with 2.6.1 changes in the change log
[07:20:03] <jthornton> main page updated
[07:46:25] <jepler> ugh. hostmot2-firmware requires ghdl but for whatever reason that's not packaged in debian wheezy
[07:48:58] <Tom_itx> http://tom-itx.ddns01.com:81/~webpage/emc/xilinx/xilinx92_install_index.php
[07:49:05] <Tom_itx> maybe that'll do some good
[07:49:16] <skunkworks> jthornton, did you get wheezy installed?
[07:49:40] <Tom_itx> sudo add-apt-repository ppa:pgavin/ghdl
[07:49:41] <jepler> Tom_itx: thanks, but not really. ghdl is used for building the .pin and .xml files, not for building the bitfile
[07:49:57] <jepler> also ppas don't help, that's ubuntu magic that doesn't work with debian
[07:50:03] <Tom_itx> ahh
[07:50:06] <jepler> thank though!
[07:50:07] <jepler> +s
[07:50:09] <Tom_itx> well i'm no linux guru :)
[07:52:26] <skunkworks> at what point do you stop saying that I wonder... (I am not a linux guru either)
[07:56:49] <skunkworks> btw - I had been having a problem with mdadm not assembling an array on boot. would have to stop it and reassemble it. Found #mdadm and had talked asked on there. really helpful folks (well one guy) it ended up being at some point replacing a drive I managed to get a super block on sdj and sdj1. (sdj1 was where it should have been) on boot it would try to assemble with sdj.
[07:57:44] <jepler> yuck
[07:57:47] <jepler> glad you worked it out
[07:58:00] <skunkworks> this has been a problem for atleast a year... :)
[07:58:26] <skunkworks> and when you only reboot the sever once in a blue moon - it is hard to rembmer what you did last time..
[07:58:32] <jepler> yup
[07:59:31] <jepler> a few years ago something along these lines happened to my home system while I was on vacation. I had to have cradek go to my place and talk him through a process I didn't remember for myself
[08:00:15] <jepler> speaking of which, I need to reboot this system. I don't think there are any such surprises waiting for me though
[08:16:22] <skunkworks> yay! :)
[10:10:45] <jepler> ugh, looks like ghdl is going to be a bear to build on debian wheezy. it requires an out-of-date version of gnat, the ada compiler
[10:11:45] <jepler> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696548
[10:11:58] <cradek> you're trying to build hostmot2-firmware?
[10:12:02] <jepler> yes
[10:14:29] <kwallace> I briefly reviewed the Python Interface and G-code Overview and haven't found a way to pass a numbered or named parameter from a running g-code file to Python running in the UI. Can this be done?
[10:15:25] <cradek> I don't know of any way
[10:15:28] <cradek> what are you trying to do?
[10:25:47] <seb_kuzminsky> good morning fellas
[10:26:54] <cradek> hi!
[10:36:02] <seb_kuzminsky> jepler: the hm2 buildslave is running lucid, fwiw
[10:36:15] <seb_kuzminsky> precise, like wheezy, does not have ghdl
[10:37:14] <seb_kuzminsky> oh god, someone endorsed me for perl on linkedin, i hope no prospective employers notice
[10:58:45] <kwallace1> cradek, sorry I missed your reply. I am working on a routine to get tool heights from a tool setter. I call an O subroutine that calls for a probe move in -Z. While that is running, I have a check for a falling edge on is_probing in the UI periodic function. When the probe trips, I capture the position. I use the linuxcnc.status position, which is in machine or G53 space because the tool change messes up the .ngc probe capture G5x space.
[10:58:49] <ssi> seb_kuzminsky: +1 :D
[11:00:06] <jepler> hah, ghdl build-conflicts with itself
[11:00:51] <kwallace1> This works okay except I am now doing two probes, one on the down stroke a higher speed, then finish on the up stroke at low speed.
[11:01:45] <kwallace1> So I don't know which falling edge is the finish probe.
[11:01:57] <jepler> seb_kuzminsky: with any luck, if I get it to build on wheezy, it'd build on precise / trusty too
[11:02:56] <jepler> n'th time's the charm
[11:03:47] <cradek> kwallace1: can you recast your problem so you do it entirely in gcode? polling the probe with the gui has never been the intent of probing, and if you use probing's captured position it will be accurate to the exact servo cycle the probe tripped (or released)
[11:05:29] <cradek> G38.x -> use #5063 -> eventually do the appropriate G10 L10/L11
[11:05:57] <cradek> I also use two probes like you describe, for tool length sensing
[11:06:03] <jepler> # ghdl -r pinmaker_SVST4_4_48
[11:06:03] <jepler> /usr/lib/ghdl/bin/ghdl: compilation error
[11:06:07] <jepler> well that's unhelpful
[11:06:42] <cradek> kwallace1: here is the code from my desktop mill:
http://pastie.org/9450769
[11:07:32] <kwallace1> cradek, the problem is that the g-code position is in the active work and tool space, which changes when the tool length or anything else changes. I end up chasing my tail trying to compensate for the state changes.
[11:07:42] <jepler> yay, it works (it was non-executable $TMPDIR biting me again)
[11:08:29] <cradek> kwallace1: G10 L11 is the built-in way to deal with that
[11:09:19] <cradek> http://linuxcnc.org/docs/html/gcode/gcode.html#sec:G10-L11
[11:10:37] <cradek> kwallace1: notice my remap uses M73 then G20, so even if the program changes units it still works
[11:14:21] <kwallace1> I'll need to study this a while to get up to speed. Thank you for the help.
[11:14:37] <cradek> welcome
[11:20:10] <jepler> seb_kuzminsky: I now have ghdl working well enough on debian wheezy that it can make the .pin / .xml files for hostmot2
[11:22:05] <jepler> seb_kuzminsky: in case you get motivated to put ghdl in our deb repository, here's the source:
http://emergent.unpythonic.net/ghdl
[11:22:30] <jepler> looks like it's needed for wheezy, precise, and would be needed for feisty if we ever climbed on that bandwagon.
[11:25:24] <seb_kuzminsky> i dont think you meant feisty
[11:25:28] <seb_kuzminsky> trusty?
[11:25:31] <jepler> sure, that one
[11:25:45] <jepler> derpy duckbill
[11:26:59] <seb_kuzminsky> thanks for modernizing ghdl, but i'm pretty unmotivated to mess with the hm2 buildslave at this point
[11:27:35] <jepler> yes, and I'm not suggesting you should move it to wheezy
[11:29:00] <jepler> but on general principle, it's good to wear down the barriers we can to other people building hostmot2-firmware
[11:31:54] <seb_kuzminsky> for sure
[11:32:12] <cradek> I suspect udev's MODE="666" is read as decimal because there's no leading 0
[11:34:00] <jepler> oops, where'd we write that?
[11:34:14] <cradek> the xhc rule
[11:34:15] <seb_kuzminsky> lots of files in /lib/udev/ have MODE="660", so i dont think so
[11:34:31] <seb_kuzminsky> files shipped by people who would know better
[11:34:59] <cradek> not here
[11:35:13] <cradek> oh yes there are some
[11:35:21] <cradek> I suspect they're all broken
[11:35:25] <seb_kuzminsky> heh could be
[11:35:34] <seb_kuzminsky> i wish dgarr were here
[11:37:15] <cradek> I only see 3-digit MODEs in one file, 69-libmtp.rules, which is some usb soundcardy stuff
[11:39:13] <seb_kuzminsky> on precise i see non-0-starting MODEs in 40-flashrom.rules and 69-libmtp.rules
[11:39:22] <seb_kuzminsky> i bet you're right
[11:39:28] <cradek> laaaaame
[11:40:16] <jepler> udev manpage sure doesn't say what is required
[11:40:57] <jthornton> skunkworks, yes
[11:40:57] <cradek> nor does
http://www.freedesktop.org/software/systemd/man/udev.html
[11:42:07] <jepler> well, I have a udev entry here for my phone
[11:42:14] <jepler> MODE="0660" and MODE="660" both worked the same
[11:42:33] <jepler> assuming .. do I have to restart udev after editing one of those files?
[11:42:41] <cradek> the docs say maybe
[11:43:12] <jepler> though I didn't see the original report, maybe the reporting user is on some other version of linux
[11:43:19] <cradek> it's wheezy
[11:43:28] <cradek> but I think that T is a smoking gun
[11:43:55] <seb_kuzminsky> dont know what OP is running, but dewey reproduced the problem on wheezy
[11:44:06] <cradek> although he didn't get exactly 1232 so maybe it gets masked automagically
[11:44:34] <cradek> uh he got 1664
[11:44:47] <cradek> I probably didn't correctly guess the problem
[11:46:29] <jepler> I get mode crw-rw---T+ both ways
[11:46:45] <jepler> + indicates extended file access controls which can be shown with getfacl
[11:47:06] <jepler> this ties in with console user stuff
[11:47:30] <jepler> the meat in the seat gets special permissions
[11:47:39] <cradek> his doesn't show T+
[11:47:45] <jepler> huh
[11:48:13] <jepler> with no matching entry at all, I get crw-rw-r-T+ for my device
[11:48:18] <jepler> it may be that some other udev rules are matching it
[11:48:20] <cradek> maybe his rule isn't even firing at all
[11:49:21] <seb_kuzminsky> this all reminds me that the shuttlexpress driver needs a udev rule too
[11:49:28] <seb_kuzminsky> that's a piece of hardware i actually have, so i can test it
[11:50:09] <jepler> is the user in group "users"?
[11:50:31] <cradek> no
[11:50:53] <cradek> which is why it may have worked until now, with the wrong mode
[11:53:21] <jepler> sticky bit is udev's hint to itself not to remove the device node when the underlying module is unloaded (why?)
https://lists.debian.org/debian-user/2012/02/msg01273.html
[12:00:02] <jepler> To make things more confusing, apparently there is both ATTR{idProduct} and ATTRS{idProduct}
[12:01:57] <cradek> it's weird if MODE is just broken
[12:01:59] <dgarr> so i think 90-xhc.rules will work on both debian-wheezy and ubuntu if group is changed to plugdev, any contrary opinion?
[12:02:02] <seb_kuzminsky> hi dgarr
[12:02:26] <seb_kuzminsky> we were just talking about the xhc-hb04 problem
[12:02:27] <jepler> dgarr: so the group that is requested sticks and the mode that is requested doesn't ?
[12:02:48] <seb_kuzminsky> jepler: that's the case in my udev rules testing here, on wheezy
[12:03:01] <dgarr> yes: crw-rw-r-T 1 root plugdev 189, 769 Aug 6 09:34 002
[12:03:09] <seb_kuzminsky> i can control the group but not the mode, using a rules file for my phone
[12:03:17] <cradek> that's very weird
[12:03:24] <jepler> dgarr: try moving 90-xhc.rules to 99-xhc.rules
[12:03:27] <jepler> and test again
[12:04:14] <dgarr> jepler: test by unplugging , mv 90 99; plug again?
[12:04:19] <jepler> dgarr: yes
[12:04:34] <dgarr> few minutes and i'll report
[12:05:11] <jepler> wheezy has in 91-permissions.rules: # usbfs-like devices
[12:05:11] <jepler> SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", \
[12:05:12] <jepler> MODE="0664"
[12:05:36] <seb_kuzminsky> heh, i just arrived at the same conclusion as jepler
[12:05:52] <seb_kuzminsky> making the rule sort last fixed things on my test system
[12:06:05] <jepler> my file was named 99android.rules all along, so its "MODE" stuck
[12:06:37] <seb_kuzminsky> and just to make cradek happy, MODE="666" and MODE="0666" both yield rw-rw-rw-
[12:07:19] <cradek> oh good. all is not crazy.
[12:07:49] <cradek> fwiw, I could also add the install user to group users
[12:07:53] <cradek> if that makes compatibility easier
[12:08:38] <dgarr> after mv,works (still plugdev): crw-rw-rwT 1 root plugdev 189, 770 Aug 6 09:48 003
[12:08:56] <seb_kuzminsky> a normal user on precise is part of plugdev but not users
[12:08:56] <jepler> I wonder if our rules file should go in /lib/udev/rules.d .. it depends whether you take the view that it's a configuration file or not, I guess
[12:09:05] <cradek> debian adduser doesn't put new users in group users (or anything)
[12:09:10] <jepler> seb_kuzminsky: does precise have 91-permissions.rules?
[12:09:15] <cradek> maybe plugdev is more right, then
[12:09:38] <seb_kuzminsky> GROUP="plugdev" seems right
[12:09:56] <seb_kuzminsky> jepler: nope
[12:10:05] <cradek> so we'll belt and suspenders it
[12:10:34] <seb_kuzminsky> jepler: there's no '*perm*' file anywhere in /lib/udev
[12:10:59] <seb_kuzminsky> dgarr: thanks for your testing
[12:11:02] <memleak> what has been the recent problems in regards to glade? i recall a few days ago someone said something about it.
[12:11:27] <jepler> memleak: there are two different problems.
[12:11:48] <seb_kuzminsky> memleak: stepconf used gtk.Builder wrong and got different results on wheezy/precise and lucid
[12:11:51] <seb_kuzminsky> jepler fixed it
[12:12:16] <jepler> memleak: the other problem was that debian wheezy did not package a version of glade that could be used to modify the glade files in linuxcnc due to a version mismatch; we fixed that by packaging it
[12:13:02] <seb_kuzminsky> dgarr: would you rename the xhc rules file to 99- and fix the GROUP?
[12:13:07] <seb_kuzminsky> i'll make a 2.6.2 soon with the fix
[12:16:05] <dgarr> yes: mv and ATTR{idProduct}=="eb70", ATTR{idVendor}=="10ce", MODE="0666", OWNER="root", GROUP="plugdev"
[12:16:16] <jepler> dgarr: +1
[12:16:39] <seb_kuzminsky> (emoji for thumbs up)
[12:17:33] <jepler> 🖒
[12:18:06] <jepler> (unfortunately not in my irssi client's character set so I can't actually admire it)
[12:18:36] <jepler> logger[psha]: url
[12:18:36] <logger[psha]> jepler: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-08-06.html
[12:19:07] <jepler> 👍
[12:19:18] <jepler> hmm I typed the wrong thing the first time to boot
[12:19:34] <cradek> only squares
[12:20:05] <jepler> cradek: the log transported the UTF-8 properly though
[12:20:06] <cradek> I guess I need to learn to interpret \U0001f44d
[12:20:13] <jepler> your browser needs a better font
[12:20:33] <jepler> not to mention your irc client
[12:20:36] <cradek> meh
[12:20:53] <ssi> 💩
[12:21:28] <seb_kuzminsky> 7-bit ascii was enough for my grand-pappy, and it's enough for me
[12:21:41] <ssi> but how did he draw his BBS menus?!
[12:21:54] <seb_kuzminsky> +---+
[12:22:01] <seb_kuzminsky> | * |
[12:22:04] <seb_kuzminsky> +---+
[12:22:05] <ssi> :D
[12:22:08] <cradek> pretty sure mine used baudot
[12:22:37] <seb_kuzminsky> did you guys see #387? bug in the new TP maybe?
[12:22:47] <jepler> PETSCII > CP437
[12:24:23] <cradek> seb_kuzminsky: yep, sure is
[12:29:25] <seb_kuzminsky> i mailed rob ellenberg a link to the bug report
[12:30:45] <seb_kuzminsky> i totally didn't put in a snarky comment about how the new TP is not in 2.6
[12:30:48] <seb_kuzminsky> i'm so mature
[12:31:05] <jepler> you gotta break a few tools to make an omelet
[12:31:38] <cradek> putting it in master but not 2.6 was best, yay, no snark needed
[12:32:28] <cradek> "guess nobody tried lathe stuff yet" is a perfectly reasonable thing to discover on master
[12:33:14] <jepler> certainly while we don't have a basic lathe test in tests/
[12:33:24] <KGB-linuxcnc> 052.6-stepconf-multiple-builders cd9b306 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cd9b306
[12:34:05] <KGB-linuxcnc> 05seb/2.6/checkglade ada9d9d 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ada9d9d
[12:35:07] <jepler> cradek: though I don't remember what it did .. did it just not synchronize with the spindle at all?
[12:35:16] <KGB-linuxcnc> 03Dewey Garrett 052.6 d728606 06linuxcnc 04debian/extras/etc/udev/rules.d/90-xhc.rules 03debian/extras/etc/udev/rules.d/99-xhc.rules xhc-hb04: reorder rules name, use plugdev group * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d728606
[12:35:22] <cradek> which?
[12:35:32] <jepler> cradek: new TP on lathe
[12:35:51] <cradek> I think spindle-sync capped speed at the gcode's F word
[12:36:01] <cradek> this is a different bug, you can't pause a fpr move
[12:36:01] <jepler> yeah that sounds right
[12:37:06] <seb_kuzminsky> huh, i didnt know about the new tp vs lathe bug
[12:37:12] <seb_kuzminsky> thanks dgarr!
[12:38:00] <cradek> seb_kuzminsky: sam found that first one when we were there playing with it
[12:41:29] <jepler> http://www.cs.umanitoba.ca/~dwalton/ResearchDocs/p739_s_a.pdf [Three dimensional biarc approximation]
[13:33:29] <seb_kuzminsky> does rob ellenberg know about the problem with lathes?
[13:37:27] <seb_kuzminsky> dgarr, cradek: i think there's no need for the xhc.rules file to set OWNER or GROUP, all we need is a MODE with world-rw bits on
[13:37:39] <seb_kuzminsky> the OWNER and GROUP would be whatever the defaults on the system dictate
[13:37:52] <seb_kuzminsky> doesn't matter much one way or another
[13:53:07] <linuxcnc-build_> build #375 of 4016.deb-wheezy-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-amd64/builds/375 blamelist: Dewey Garrett <dgarrett@panix.com>
[13:53:22] <linuxcnc-build_> build #1811 of 4007.deb-precise-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/1811 blamelist: Dewey Garrett <dgarrett@panix.com>
[13:54:11] <linuxcnc-build_> build #375 of 4015.deb-wheezy-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4015.deb-wheezy-i386/builds/375 blamelist: Dewey Garrett <dgarrett@panix.com>
[13:54:28] <linuxcnc-build_> build #1811 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/1811 blamelist: Dewey Garrett <dgarrett@panix.com>
[13:54:48] <linuxcnc-build_> build #1805 of 4003.deb-lucid-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4003.deb-lucid-i386/builds/1805 blamelist: Dewey Garrett <dgarrett@panix.com>
[13:57:07] <linuxcnc-build_> build #78 of 4017.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-rtai-i386/builds/78 blamelist: Dewey Garrett <dgarrett@panix.com>
[13:57:40] <cradek> seb_kuzminsky: rob already fixed the first (ssm) one but not the second (fpr) that was just reported
[13:57:56] <linuxcnc-build_> build #644 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/644 blamelist: Dewey Garrett <dgarrett@panix.com>
[13:58:30] <jepler> dh_movefiles: debian/tmp/etc/udev/rules.d/90-xhc.rules not found (supposed to put it in linuxcnc-sim)
[13:58:33] <jepler> oops, one more file to edit :-/
[14:11:28] <linuxcnc-build_> build #1808 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/1808 blamelist: Dewey Garrett <dgarrett@panix.com>
[14:11:31] <linuxcnc-build_> build #1805 of 4004.deb-lucid-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4004.deb-lucid-amd64/builds/1805 blamelist: Dewey Garrett <dgarrett@panix.com>
[15:38:35] <jepler> dgarr: I haven't gotten around to fixing the buildbot errors .. not sure if you saw them by reading the irc log
[15:39:10] <jepler> dgarr: the file you renamed is named in another file, so it needs to be changed there too
[15:39:13] <jepler> debian/extras/linuxcnc.files:etc/udev/rules.d/90-xhc.rules
[15:43:46] <dgarr> oops, back from lunch
[15:43:49] <KGB-linuxcnc> 03Dewey Garrett 052.6 a99c345 06linuxcnc 10debian/extras/linuxcnc.files xhc-hb04: update linuxcnc.files too * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a99c345
[15:48:31] <jepler> dgarr: thank you
[16:29:24] <KGB-linuxcnc> 03Robert W. Ellenberg 05master e717992 06linuxcnc 10src/emc/tp/tp.c tp: fix for G95 pausing bug from Rick * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e717992
[16:29:53] <cradek> he's fast
[16:33:32] <skunkworks_> wow
[16:34:18] <cradek> I really should try master on my lathe, pausing, css, fpr, ssm
[16:34:21] <cradek> lathes are the worst things
[16:35:01] <cradek> uninterrupted ssm->ssm like the fusee code
[16:40:40] <seb_kuzminsky> wow!
[16:43:16] <JT-Shop> wow that was fast
[16:44:24] <seb_kuzminsky> JT-Shop: thanks for updating the website with the 2.6 downloads the other day
[17:13:23] <skunkworks_> from rob... Thanks! I got lucky because it was a stupid mistake :).
[17:13:59] <seb_kuzminsky> it's funny how often smart people get lucky
[17:14:09] <seb_kuzminsky> err, that didn't come out how i meant it
[17:14:18] * seb_kuzminsky goes back to lurking
[17:15:44] <PCW> skunkworks_ are you running the wheezy dist on your J1800/J1900?
[18:41:06] <skunkworks_> pcw: yes
[18:41:08] <skunkworks_> on both
[18:41:36] <skunkworks_> mainly what I have been testing
[18:41:41] <PCW> hmm i cant get the usb image to boot
[18:42:01] <skunkworks_> you wont.
[18:42:40] <skunkworks_> with the rtai - the usb don't work. so after a bit - the boot fails because the usb ports disapear in linux.
[18:43:09] <skunkworks_> I used a dvd for the inital install - then installed the rt_preempt which works with the usb's
[18:45:05] <PCW> well thats a bit awkward :-(
[18:45:37] <PCW> I guess normal wheezy would install
[18:45:56] <PCW> and the rest could done from source
[18:47:42] <PCW> I guess that how i did the ubuntu install (usb boot from 12.04 then install the rest)
[18:53:06] <skunkworks_> right - I was going to do that - but couldn't figure out what I needed to download.. ;)
[18:55:58] <PCW> yeah maybe I'll fight with this later
[18:56:04] <skunkworks_> huh - chromecast hdmi device is pretty neat
[18:56:34] <skunkworks_> you can boot off the linuxcnc wheezy dvd - you just need ps2 mouse and keyboard...
[18:56:49] <skunkworks_> (and the dvd drive hooked in sata...)
[18:57:47] <PCW> Yeah but I would have to pull a DVD drive from a working system so later
[19:00:46] <PCW> i guess I could put it on a CF
[19:07:10] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 6ec6995 06linuxcnc 10scripts/platform-is-supported master now supports rtpreempt * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6ec6995
[19:07:10] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 8b88a71 06linuxcnc 10scripts/platform-is-supported master now supports the armhf architecture * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8b88a71
[19:07:24] <seb_kuzminsky> we'll see how that goes
[19:08:05] <JT-Shop> skunkworks_, yes I got wheezy up and running, just a few little hiccups
[19:08:17] <jepler> PCW: the 7i90hd manual will have details on how spi communication works?
[19:08:19] <linuxcnc-build> build #639 of 1403.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed configure-debian-control configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-rtpreempt-amd64/builds/639 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:09:26] <PCW> Yes
[19:09:58] <jepler> PCW: I see it's also called "LBP16", I take it it's similar to the ethernet
[19:10:10] <linuxcnc-build> build #1389 of 1304.rip-precise-rtpreempt-i386 is complete: Failure [4failed configure-debian-control apt-get-update configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1304.rip-precise-rtpreempt-i386/builds/1389 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:11:01] <PCW> lbp16 is the hm2 over serial interface (basically the same as ethernet)
[19:11:12] <PCW> SPI is different
[19:11:19] <jepler> OK
[19:12:16] <PCW> (there are 4 possible 7I90 configs ATM, HM2_EPP,HM2_Serial,HM2_SPI and ssremote)
[19:12:25] <jepler> PCW: oh, a nit: 7i80hdman doesn't give the Y distance to pin 1 of the HD connectors. (I was reminded of this because 7i90hdman does)
[19:12:45] <PCW> ok thanks
[19:13:33] <PCW> (they are the same BTW)
[19:13:38] <jepler> PCW: I was guessing so
[19:14:46] <linuxcnc-build> build #1373 of 1305.rip-precise-rtpreempt-amd64 is complete: Failure [4failed configure-debian-control apt-get-update configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1305.rip-precise-rtpreempt-amd64/builds/1373 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:15:37] <PCW> hmm bitfiles work rather badly when the ucf file is not associated with the top level file
[19:15:58] <jepler> OK, found the SPI section. In a way, it feels a lot like epp mode
[19:17:15] <PCW> yeah pretty low level ( deliberately all 32 bit transfers so the SPI hardware doesn't need to be fiddled with in the middle of things )
[19:18:59] <jepler> so the first bit shifted out is the MSB of "A"?
[19:19:33] <PCW> I dont remember its whatever is standard for SPI
[19:20:00] <PCW> I think thats right MSB first
[19:20:58] <jepler> first picture I found on the internet depicts MSB first
[19:25:06] <jepler> once I have a firmware and a level translator I think I know what's next
[19:27:33] <PCW> beware the framing timeout if you are poking at it by hand
[19:30:05] <PCW> (since there's no reset and possibly N 32 bit data payloads there's a 50 usec framing timeout)
[19:30:48] <jepler> with the linux userspace API for "spidev" it's easy to say "do this many words of data"
[19:43:03] <jepler> so for instance with no device attached I get this when trying to transact a read of part of idrom:
[19:43:06] <jepler> > 040ca860 00000000 00000000 00000000 00000000 00000000 00000000
[19:43:09] <jepler> > xxxxxxxx ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
[19:43:27] <jepler> er, second line should say "<", received data
[19:46:39] <PCW> yeah looks about right
[19:49:09] <PCW> I tested it with a 7I80 with a BSPI config
[19:49:20] <PCW> (as the SPI master)
[19:56:38] <jepler> I'll keep in mind that it would be keen if this could work over BSPI as well as spidev
[19:57:25] <PCW> It was just a convenient SPI interface to use
[19:58:17] <PCW> not sure theres a actual use for hm2_hm2
[19:58:30] <jepler> I thought you had a customer doing that, though not with linuxcnc
[19:58:42] <jepler> how deep is the BSPI FIFO?
[19:58:56] <PCW> 16 deep
[19:59:01] <jepler> oh look it says it right there
[19:59:05] <PCW> 32 wide
[20:00:27] <PCW> Hmm theres still a windows test program (loopback) here
[20:01:37] <PCW> Yeah there is someone using 6 7I90s as a 384 channel scaler (frequency counter)
[20:02:00] <PCW> ( the 7I90s running hm2_serilal )
[20:02:34] <jepler> hum I wonder how much setup time Linux gives from asserting CS/ to starting to shift
[20:02:55] <jepler> there's a spot in the spi_ioc_transfer struct for time from end of shifting to deassertion of CS/, but not one for setup
[20:03:48] <jepler> * @delay_usecs: If nonzero, how long to delay after the last bit transfer
[20:03:51] <jepler> * before optionally deselecting the device before the next transfer.
[20:03:54] <jepler> * @cs_change: True to deselect device before starting the next transfer.
[20:07:45] <jepler> I also don't see anything like "late sample"
[20:09:47] <PCW> that may limit your speed
[20:10:07] <PCW> (reads are the issue)
[20:12:08] <jepler> particularly with a level translator in the way I imagine there's a phase shift
[20:12:18] <PCW> I got 50 Mb/s with BSPI host and no level translator (approx 8" flat cable)
[20:13:10] <PCW> (thats also 7I80 to 7I90 so SP6 on both ends)
[20:13:56] <PCW> (I still have the funky hdr50 --> hdr26 cable on my desk here)
[20:15:23] <PCW> The Allwinner chips do have the late sample option
[20:15:35] <jepler> t_pd = 7.1ns max B to A, 6.5ns max A to B (Vcc_A = 1.8V, V_ccB = 5V)
[20:16:20] <PCW> yeah thats going to hurt a bit
[20:16:21] <jepler> so 14ns phase shift between outgoing clock and incoming data from the slave
[20:16:45] <PCW> plus the clock to output delay on the FPGA
[20:17:04] <jepler> single-digit ns again?
[20:17:12] <PCW> yeah
[20:17:27] <jepler> I'll start at 1MHz and go from there
[20:18:05] <PCW> my guess is say 15 or 20 MHz
[20:18:25] <PCW> still quite a bit faster than EPP
[20:18:38] <skunkworks_> so it should work - shouldn't it?
[20:18:47] <skunkworks_> even at 1mhz?
[20:18:54] <PCW> sure
[20:19:53] <PCW> theres some improvements possible in the interface to deskew a bit
[20:21:30] <PCW> with a modified design and a constant clock (not sure if many SOCs can do this)
[20:21:31] <PCW> its possible to get really fast
[20:22:33] <PCW> (the DCM cay remove the input clock delays and phase shift the output clock ahead a bit)
[20:33:36] <jepler> hmph, even when you find a bootleg samsung datasheet you remain unenlightened
[20:34:01] <jepler> maybe this register has to do with delaying sample of the data from the slave
[20:34:15] <jepler> if so, 0/3/6/9ns delay can be selected
[20:34:20] <jepler> the register's called FB_CLK_SEL
[20:35:19] <jepler> /* Configure feedback delay */
[20:35:19] <jepler> writel(cs->fb_delay & 0x3, sdd->regs + S3C64XX_SPI_FB_CLK);
[20:51:38] <jepler> hm, the way to configure it is via devicetree, but odroid kernels don't have CONFIG_DTC. I wonder how much hell breaks loose if I turn that on.
[20:53:32] <jepler> .. easier just to hard code the highest delay instead of the lowest
[20:55:27] <seb_kuzminsky> Message from syslogd@wheezy-armhf-u3 at Aug 6 17:56:19 ... kernel:[964938.175000] thermal_sys: Critical temperature reached(111 C),shutting d
[20:55:54] <seb_kuzminsky> guess i should take that protective towel off my u3
[20:55:55] <jepler> seb_kuzminsky: uh oh, give it a glass of ice water
[21:16:25] <skunkworks_> you cover you computers up at night?
[21:16:36] <cradek> it keeps them calm
[21:17:09] <skunkworks_> makes sense
[21:19:34] <seb_kuzminsky> keeps the aluminum chips off
[21:19:43] <skunkworks_> that was my second guess
[21:19:49] <pcw_home> jepler. might be able to save some delay by just using a resistive divider for the FPGA data out
[21:41:31] <pcw_home> Spartan6 is nicer, you can chose LVCMOS18 input thresholds on a 3.3V VCCIO bank
[21:42:47] <pcw_home> so all doable with UCF file and a ~2/1 resistive divider for FPGA data out
[21:44:23] <jepler> someday when you think you'll sell a thousand of 'em :-P
[21:49:08] <pcw_home> It might be easier to test with the 7I80 though
[21:49:27] <jepler> > The application module Tektronix are selling is simply just a small EEPROM loaded up with an SKU
[21:52:06] <pcw_home> I didn't realize you could use 3.3V bank I/O as 1.2,1.5,1.8, and 2.5 v inputs
[21:54:28] <jepler> committed at bitfile generation time?
[22:03:47] <jepler> changing gears .. to efficiently do a full-duplex communication on bspi, I would write to TXFIFO 16 times, wait about 16x32 bit times, read RXFIFO count and read RXFIFO that many times?
[22:04:24] <jepler> and if I had more than 16 words to transact, I suppose I can now write however many words there were to read from RXFIFO(?)
[22:05:04] <jepler> and at the end, repeatedly poll RXFIFO count and read a word at a time until all words are reda
[22:05:34] <jepler> but in realtime instead of any delaying, one might as well just poll the count
[22:21:20] <pcw_home> Yeah just poll the count
[22:21:22] <pcw_home> or on Ethernet insert delays in the packet since polling is not efficient
[22:21:23] <pcw_home> or make a bigger(blockram) buffer on the SPI interface
[22:50:56] <linuxcnc-build> build #2297 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2297 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[22:57:26] <seb_kuzminsky> linuxcnc-build: force build --branch=master 0000.checkin
[22:57:27] <linuxcnc-build> build #2298 forced
[22:57:27] <linuxcnc-build> I'll give a shout when the build finishes
[22:58:01] <linuxcnc-build> build #640 of 1403.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed configure-debian-control configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-rtpreempt-amd64/builds/640
[23:31:17] <linuxcnc-build> build #2292 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/2292