Back
[00:04:52] -!- i_tarzan has quit [Ping timeout: 250 seconds]
[00:05:29] -!- Nick001-shop has quit [Quit: ChatZilla 0.9.90.1 [Firefox 30.0/20140605174243]]
[00:06:34] -!- gonzo_nb has quit [Ping timeout: 264 seconds]
[00:07:47] -!- DaViruz has quit [Ping timeout: 245 seconds]
[00:21:06] -!- syyl has quit [Ping timeout: 260 seconds]
[00:22:51] <PCW> hardware registers?
[00:23:46] -!- kwallace1 [kwallace1!~kwallace@smb-23.sonnet.com] has parted #linuxcnc-devel
[00:29:03] -!- rosslyoung has quit [Ping timeout: 240 seconds]
[00:37:09] -!- FreezingCold has quit [Quit: Out]
[00:46:32] <jepler> PCW: yes, was starting to see if I can do pure userspace spi
[00:47:01] <jepler> pcw: must be the equivalent of MTRRs to poke, or at least that's one theory
[00:48:10] <jepler> others' examples didn't have anythingg like that, as far as I saw so far (for userspace gpio)
[00:48:25] <PCW> registers may well be "funny" (read only bits etc)
[00:54:08] -!- GJdan has quit [Quit: WeeChat 1.0-dev]
[00:55:32] -!- ries has quit [Quit: ries]
[01:03:46] -!- patrickarlt has quit [Remote host closed the connection]
[01:09:15] -!- patrickarlt has quit [Ping timeout: 272 seconds]
[01:10:28] -!- kb8wmc [kb8wmc!~chatzilla@64.25.194.29] has joined #linuxcnc-devel
[01:15:42] -!- kb8wmc has quit [Ping timeout: 260 seconds]
[01:15:42] -!- sumpfralle has quit [Ping timeout: 260 seconds]
[01:17:03] -!- kb8wmc [kb8wmc!~chatzilla@64.25.194.29] has joined #linuxcnc-devel
[01:19:38] -!- PetefromTn_ has quit [Quit: I'm Outta here!!]
[01:24:07] -!- Servos4ever has quit [Quit: ChatZilla 0.9.90.1 [SeaMonkey 2.26.1/20140612173529]]
[01:25:58] -!- kb8wmc has quit [Ping timeout: 260 seconds]
[01:31:05] -!- kb8wmc [kb8wmc!~chatzilla@64.25.194.29] has joined #linuxcnc-devel
[01:34:16] -!- LeelooMinai_ has quit []
[01:34:35] -!- LeelooMinai [LeelooMinai!~leeloo@184.175.46.197] has joined #linuxcnc-devel
[01:41:24] <jepler> PCW: my datasheet shows the bits I've tried to tickle as R/W
[01:42:17] <jepler> a few registers, like the TX fifo register, are denoted W, so I assume they're making the usual distinction
[01:45:22] -!- almccon has quit [Ping timeout: 240 seconds]
[01:49:46] -!- grummund has quit [Ping timeout: 264 seconds]
[01:50:15] -!- starno has quit [Ping timeout: 252 seconds]
[01:50:25] -!- skunkworks_ has quit [Ping timeout: 272 seconds]
[01:55:54] amnesic is now known as amnesic_away
[01:57:57] -!- asdfasd has quit [Ping timeout: 240 seconds]
[01:59:05] -!- patrickarlt has quit [Quit: Leaving...]
[02:00:49] -!- skunkworks_ [skunkworks_!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[02:20:58] -!- FreezingCold has quit [Ping timeout: 264 seconds]
[02:21:33] -!- tinkerer has quit [Quit: Leaving.]
[02:21:41] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[02:42:24] -!- valeech has quit [Quit: valeech]
[02:50:29] -!- PetefromTn_ has quit [Quit: I'm Outta here!!]
[02:55:06] -!- amiri has quit [Ping timeout: 260 seconds]
[02:56:38] -!- memleak [memleak!~memleak@unaffiliated/memfrob] has joined #linuxcnc-devel
[03:17:12] tronwzrd is now known as tronwizard
[03:18:02] -!- AR_ has quit [Ping timeout: 250 seconds]
[03:26:41] -!- FinboySlick has quit [Quit: Leaving.]
[03:31:58] -!- kb8wmc has quit [Ping timeout: 260 seconds]
[04:03:31] -!- anth0ny_ has quit [Quit: anth0ny_]
[04:27:34] -!- tronwizard has quit [Ping timeout: 264 seconds]
[04:29:52] -!- stephan48 has quit [Ping timeout: 240 seconds]
[04:36:22] -!- tronwizard has quit [Ping timeout: 240 seconds]
[04:51:03] -!- kwallace2 [kwallace2!~kwallace@smb-23.sonnet.com] has parted #linuxcnc-devel
[05:01:52] -!- stephan48 has quit [Ping timeout: 245 seconds]
[05:02:08] -!- Fox_Muldr has quit [Ping timeout: 250 seconds]
[05:11:06] -!- almccon_ has quit [Read error: Connection reset by peer]
[05:13:05] -!- almccon has quit [Ping timeout: 272 seconds]
[05:14:18] -!- almccon_ has quit [Read error: Connection reset by peer]
[05:24:28] -!- anth0ny_ has quit [Quit: anth0ny_]
[05:25:32] -!- chally_ has quit [Ping timeout: 250 seconds]
[05:39:04] -!- ve7it has quit [Remote host closed the connection]
[06:12:42] -!- sylphiae has quit [Ping timeout: 245 seconds]
[06:29:19] -!- Tecan has quit [Changing host]
[06:31:18] -!- herron_ has quit [Ping timeout: 250 seconds]
[06:37:22] -!- Tecan has quit [Ping timeout: 250 seconds]
[06:38:06] -!- Tecan has quit [Changing host]
[06:38:15] brad_ is now known as Guest29394
[06:46:10] -!- Tecan has quit [Ping timeout: 264 seconds]
[06:51:28] -!- FreezingCold has quit [Ping timeout: 260 seconds]
[06:58:10] -!- The_Ball has quit [Remote host closed the connection]
[07:50:12] -!- herron_ has quit [Ping timeout: 245 seconds]
[08:11:02] -!- The_Ball has quit [Ping timeout: 245 seconds]
[08:18:35] -!- RyanS has quit [Read error: No route to host]
[08:27:43] -!- b_b has quit [Changing host]
[08:47:59] amnesic_away is now known as amnesic
[08:56:54] -!- herron_ has quit [Ping timeout: 250 seconds]
[09:24:29] -!- Guest29394 has quit [Quit: Page closed]
[09:26:33] -!- anarchos2 has quit [Ping timeout: 240 seconds]
[09:38:40] amnesic is now known as amnesic_away
[09:40:45] -!- uwe_ has quit [Ping timeout: 240 seconds]
[09:41:12] -!- jthornton has quit [Ping timeout: 250 seconds]
[09:41:38] -!- JT-Shop has quit [Ping timeout: 250 seconds]
[10:09:31] -!- jthornton [jthornton!~john@162.72.174.234] has joined #linuxcnc-devel
[10:09:31] -!- JT-Shop [JT-Shop!~john@162.72.174.234] has joined #linuxcnc-devel
[10:34:37] -!- skunkworks_ has quit [Ping timeout: 260 seconds]
[10:38:13] -!- herron_ has quit [Ping timeout: 255 seconds]
[10:46:01] Cylly is now known as Loetmichel
[10:47:09] -!- tinkerer [tinkerer!~tinkerer@mail.play-pla.net] has joined #linuxcnc-devel
[10:55:34] -!- mhaberler has quit [Quit: mhaberler]
[10:56:03] -!- ries has quit [Ping timeout: 240 seconds]
[11:14:16] <tinkerer> @jepler: have a look @ this:
[11:14:16] <tinkerer> https://code.google.com/p/picnc/source/browse/#git%2FHAL
[11:14:16] <tinkerer> probably you know Gemis driver.
[11:14:16] <tinkerer> https://github.com/tinkercnc/spi-fpga-driver
[11:14:16] <tinkerer> here is the raspi-spi not based on the spidev driver
[11:14:16] <tinkerer> the spidev driver in linux is a shame.
[11:14:16] <tinkerer> in the 2. link: although the bbb has the better hardware due to the spidev-driver it works much worser then the raspi-version which is not based on spidev.
[11:14:17] <tinkerer> the raspi-version with server (encoder) works well.
[11:15:52] -!- shurshur has quit [Ping timeout: 240 seconds]
[11:22:42] -!- larryone has quit [Quit: This computer has gone to sleep]
[11:23:43] -!- Valen has quit [Quit: Leaving.]
[11:27:16] -!- shurshur has quit [Ping timeout: 260 seconds]
[11:30:22] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[11:31:47] -!- larryone has quit [Client Quit]
[11:34:21] -!- sirdancealot has quit [Ping timeout: 255 seconds]
[11:39:03] -!- anarchos2 has quit [Ping timeout: 240 seconds]
[11:40:18] -!- ktchk [ktchk!~eddie6929@n219073004231.netvigator.com] has joined #linuxcnc-devel
[11:48:07] -!- ktchk [ktchk!~eddie6929@n219073004231.netvigator.com] has parted #linuxcnc-devel
[11:48:07] -!- ktchk has quit [Remote host closed the connection]
[12:11:12] amnesic_away is now known as amnesic
[12:16:29] <jepler> tinkerer: thanks for the links, will look..
[12:19:10] <jepler> tinkerer: so your experience with bbb is that its /dev/spidev is also terrible for RT performance?
[12:19:30] <jepler> it makes me feel a little better if it's not "my fault" :)
[12:20:59] -!- md-2 has quit [Remote host closed the connection]
[12:21:27] <jepler> tinkerer:
https://github.com/tinkercnc/spi-fpga-driver/blob/master/RaspberryPi/pluto_servo_rpspi.comp#L137 looks a lot like
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/hal/drivers/pluto_servo.comp;h=1987783d6fd20e1de329bf7c11f2ca45a19675e0;hb=HEAD#l203
[12:21:44] <jepler> tinkerer: please credit me. 1 // Copyright (C) 2007 Jeff Epler
[12:21:52] -!- spatialbrew has quit [Ping timeout: 240 seconds]
[12:22:42] <jepler> gplv3+ is not a problem, but you should properly preserve copyright notices from the original code
[12:23:07] <jepler> thanks
[12:23:21] <memleak> heh, when i did all the heavy lifting for 64-bit 3.x kernel RTAI paolo left me out of the headers
[12:23:37] <memleak> preamble, whatever its called
[12:25:42] -!- md-2 has quit [Ping timeout: 245 seconds]
[12:25:50] <jepler> memleak: stuff like properly crediting authors is not the *fun* part, so I totally get thta it gets overlooked.
[12:28:12] <memleak> i need to go back in RTAI and readjust those scheduler changes because its actually a mix of 3 commits and im getting lost in it
[12:28:48] <memleak> whats the way to overwrite git history again?
[12:29:10] <jepler> it's git, there's more than one way :)
[12:29:59] <memleak> ah yes.. forgot about that
[12:30:05] <jepler> you can use git rebase and select to "edit" a commit
[12:30:27] <memleak> can you delete a commit?
[12:30:41] <memleak> i saw one of the xen kernel devs do that..
[12:30:46] <jepler> when editing the "git rebase" list of instructions, you can just delete a line
[12:31:13] <memleak> there was a change he made to the code then it didnt show up anymore in gitweb
[12:31:16] -!- SolarNRG has quit []
[12:31:33] <jepler> anyway, when "git rebase" returns you to the shell to edit a command, you pull up git gui, click "amend last commit", and you can add/remove parts from the commit, change the message, and commit again
[12:31:45] <jepler> do that until your commit is split up into 2, 3, ... parts and everything is committed
[12:31:48] <jepler> then git rebase --continue
[12:32:09] <memleak> that will merge the 3 commits into one?
[12:32:19] <jepler> you want to merge the three commits? I misunderstood.
[12:32:24] <jepler> to do that, you still want git rebase
[12:32:34] <memleak> well and make changes to the commits
[12:32:43] <jepler> but you want to "squash" the commits
[12:32:52] <memleak> yes, with modifications
[12:33:59] <jepler> to squash *and* edit, you'll have to go through the rebase process twice
[12:34:13] <memleak> oh dear..
[12:34:16] <jepler> though after any line you can also write "x bash" to drop into a shell at that point
[12:34:49] <jepler> at which point you could edit and amend the commit
[12:35:12] <memleak> after any line.. what do you mean by that?
[12:35:17] <jepler> I'm not trying to scare you off from doing sophisticated things with git ..
[12:35:27] <memleak> at which point would i run x bash?
[12:36:04] <jepler> when you run 'git rebase -i some-ref' it places you in your text editor with a series of lines that describe the commits after some-ref and before the commit where you were just now
[12:36:10] <jepler> with each line saying "pick"
[12:36:11] <jepler> pick ef8d52c interp: use strings to avoid buffer hell
[12:36:11] <jepler> pick 859e90b hostmot2: support boards on spi interface
[12:36:24] <jepler> you edit these instructions to make git rebase do what you want
[12:36:34] <jepler> -i ("interactive") is a part that I neglected to mention
[12:36:47] <memleak> ok thanks ill try and give that a shot
[12:37:16] <jepler> so for instance if you want to rewrite the last 3 commits, you may want to start with git rebase -i HEAD~3
[12:37:35] <jepler> you'll be able to see from the commit titles if you got the commits you intended to rebase
[12:37:42] <jepler> I need to head in to $DAY_JOB so afk...
[12:37:52] <memleak> ok see ya thanks!
[12:38:18] <jepler> just remember: (A) anything you've pushed to github will be really hard to destroy until you "git push -f", so be at ease as you learn how to use it
[12:38:41] <jepler> (B) even anything you've "git commited" will be recoverable after a mistake
[12:38:54] <jepler> and (C) you'll eventually become comfortable with git rebase, and then you'll have a very powerful tool
[12:39:18] <jepler> (but for B you have to learn some new git stuff before you can recover it -- the "reflog")
[12:39:23] <jepler> anyway, afk
[12:41:43] <memleak> NAILED IT
[12:41:46] <memleak> thanks jepler!!!
[12:47:40] <skunkworks> memleak, how does this compare to the rtai on the wheezy livecd?
[12:48:40] -!- mhaberler has quit [Quit: mhaberler]
[12:48:40] <tinkerer> jepler: are you contented?
https://github.com/tinkercnc/spi-fpga-driver/tree/master/RaspberryPi
[12:52:44] <tinkerer> jepler: the BBB has generally a problematic spi interface:
http://e2e.ti.com/support/arm/sitara_arm/f/791/t/212616.aspx
[12:55:37] -!- anarchos2 has quit [Ping timeout: 245 seconds]
[12:56:08] <memleak> wheezy uses old-master from august right?
[12:56:16] <memleak> one moment
[12:58:17] <skunkworks> I have a motherboard with terible latency with the wheezy rtai and one that usb's don't work. (wondering if I should give it a try)
[13:02:03] <jepler> tinkerer: thank you
[13:02:15] <memleak> im sure whatever your results are right now, you'll get different ones if you use 3.14 w/ my new tree
[13:02:50] <memleak> tree is in flux for the next few minutes, reworking scheduler commits
[13:03:10] <skunkworks> no rush
[13:03:20] <skunkworks> (and I don't know how to do that from source...)
[13:05:47] <memleak> ah.. yeah you need to build a kernel and whatnot
[13:06:04] <memleak> i can tar one up for you and you can throw it in /boot and run update-grub :P
[13:07:44] <jepler> that just breaks the linuxcnc packages
[13:08:53] <memleak> ah right..
[13:10:10] -!- archivist_herron has quit [Ping timeout: 260 seconds]
[13:11:56] amnesic is now known as amnesic_away
[13:15:07] -!- Gabriel_ has quit [Quit: Leaving]
[13:17:38] <memleak> sweet, now its clean!
https://github.com/NTULINUX/RTAI/commit/2df23cc0debb051c88bb9c87b8a93d041b34b34c
[13:17:52] -!- benjamin23 has quit [Remote host closed the connection]
[13:18:09] <memleak> present_mask vs active_mask affects whether i get a kernel panic when i close latency-test
[13:19:16] -!- Tecan has quit [Changing host]
[13:26:12] <jepler> how about fixing it so you don't get a panic when you close latency-test
[13:26:14] <jepler> I bet that would be best
[13:26:19] * jepler <--- experienced dev
[13:26:42] <memleak> i dont anymore
[13:26:55] <memleak> (because i changed it)
[13:27:05] <jepler> I figured, actually
[13:27:07] <memleak> XD
[13:27:11] <jepler> just a ltitle sarcasm on the internet
[13:27:24] <memleak> hahaa
[13:32:15] -!- anth0ny_ has quit [Quit: anth0ny_]
[13:36:55] <skunkworks> cradek, that pendon is cool! (jepler - great picture)
[13:37:00] <skunkworks> (s)
[13:37:16] <skunkworks> pendent
[13:37:22] <skunkworks> jeeze
[13:42:16] <memleak> ah my spurious APIC interrupts are gone now
[13:42:34] <memleak> https://github.com/NTULINUX/RTAI/commit/2f749c34ceef979ddcbc05ed04c790bd5022af05
[13:43:53] <memleak> skunkworks, it differs from wheezy in a lot of ways, one is 3.14 and 3.10 kernel support.
[13:44:25] <memleak> the other is 64-bit support which works flawlessly (for me) i still need to test 32-bit though...
[13:45:05] <memleak> it also has a new scheduler :)
[13:45:16] <memleak> along with a new timer setup
[13:48:59] <skunkworks> memleak - is there directions anywhere on how to build it from source?
[13:49:08] -!- gonzo_nb has quit [Ping timeout: 260 seconds]
[13:51:26] <memleak> README.INSTALL but youll need to make a kernel config
[13:51:40] <memleak> if you give me lspci -k and dmesg output i can make you one
[13:51:52] <memleak> do you know how to build linuxcnc?
[13:55:56] <skunkworks> yes
[13:56:32] -!- archivist_herron has quit [Ping timeout: 255 seconds]
[14:00:30] <memleak> ok :)
[14:07:21] <memleak> just slap them up on dpaste or something and ill make one
[14:07:30] <memleak> i make custom kernels all the time
[14:07:36] <memleak> at least twice a day :P
[14:10:12] -!- anth0ny_ has quit [Client Quit]
[14:12:22] -!- asheppard has quit [Ping timeout: 250 seconds]
[14:14:18] <skunkworks> heh - does it matter what kernel I boot to get the lspci and dmesg?
[14:15:19] <jepler> skunkworks: you want do get dmesg from a kernel which supports all your hardware
[14:16:13] <skunkworks> jepler, thanks
[14:16:21] -!- kwallace [kwallace!~kwallace@smb-31.sonnet.com] has joined #linuxcnc-devel
[14:26:37] <seb_kuzminsky> oh goodie, another neer-a-car update this morning :-)
[14:27:19] <skunkworks> link?
[14:27:59] <memleak> lspci -k reads directly from PCI bus, not kernel though
[14:28:01] <memleak> lspci is more important
[14:28:05] <memleak> dmesg is for fine tuning
[14:28:08] <skunkworks> did he create his own aluminum smelting plant to create the correct aluminum from the ore originally used to make the neer-a-car?
[14:30:28] <seb_kuzminsky> http://bodgesoc.blogspot.com/2014/08/Neracar8.html
[14:36:25] -!- sleepycat has quit [Quit: leaving]
[14:41:28] <skunkworks> wow
[14:44:00] -!- eFuchs has quit [Ping timeout: 250 seconds]
[14:47:22] -!- FreezingAlt has quit [Ping timeout: 245 seconds]
[14:58:44] -!- kwallace2 [kwallace2!~kwallace@smb-237.sonnet.com] has joined #linuxcnc-devel
[15:00:08] -!- kwallace has quit [Ping timeout: 250 seconds]
[15:09:14] -!- ries has quit [Read error: Connection reset by peer]
[15:09:48] <cradek> andy's amazing
[15:13:28] <skunkworks> isn't he? unreal
[15:15:57] tronwzrd is now known as tronwizard
[15:18:45] -!- jduhls has quit [Ping timeout: 240 seconds]
[15:19:40] -!- rosslyoung has quit [Ping timeout: 260 seconds]
[15:27:54] -!- eFuchs has quit [Quit: ping timeout]
[15:28:26] <memleak> skunkworks, if you're using debian or any kind of a distro that isnt custom built like gentoo or slackware you shouldnt have a problem
[15:28:40] <memleak> funtoo, etc
[15:31:52] -!- sudobangbang has quit [Ping timeout: 245 seconds]
[15:34:13] -!- anth0ny_ has quit [Quit: anth0ny_]
[15:35:42] -!- BellinganRoy has quit [Quit: Konversation terminated!]
[15:36:17] -!- ries has quit [Ping timeout: 272 seconds]
[15:36:18] ries_nicked is now known as ries
[15:36:27] -!- likevinyl has quit [Ping timeout: 255 seconds]
[16:11:52] <seb_kuzminsky> jepler: do you have an rtpreempt kernel for arm? i have a friend with a delta-robot 3d printer controlled by a beagle bone black....
[16:13:38] <jepler> seb_kuzminsky: odroid uses its own kernel repo (They aren't hip to things like devicetree), so I doubt my work is useful for someone with a bbb. anyway, it's
https://github.com/jepler/odroid-linux/tree/odroid-3.8.13-rt
[16:14:34] <seb_kuzminsky> thx
[16:15:37] <seb_kuzminsky> gods what a mess
[16:15:48] <seb_kuzminsky> (the arm situation, not jeff's repo)
[16:16:18] -!- mle has quit [Ping timeout: 250 seconds]
[16:16:22] <jepler> give it a dozen years and it'll be fine
[16:16:33] <jepler> or we'll all be living in a postapocalyptic wasteland
[16:16:57] -!- syyl_ws has quit [Remote host closed the connection]
[16:19:00] -!- rwlloyd has quit [Ping timeout: 250 seconds]
[16:19:51] <memleak> ive been using preempt_rt on my cubieboard2
[16:20:10] <memleak> 3.4.103 i believe.
[16:20:35] <memleak> going to probably switch over to xenomai though
[16:20:45] -!- sylphiae has quit [Ping timeout: 240 seconds]
[16:21:00] <memleak> i cant merge in the xenomai code as cleanly as i thought so i wont be the one to conquer that task
[16:21:05] -!- md-2 has quit [Quit: Leaving...]
[16:21:15] <memleak> for xenomai i just merge the whole branch with master locally
[16:21:23] <memleak> well.. 2.6 branch
[16:21:25] <seb_kuzminsky> jepler: ok, but i get to be tom waits,
http://movieclips.com/htFZb-the-book-of-eli-movie-ill-wait-here/
[16:22:09] <seb_kuzminsky> which kernel.org kernel added devicetree?
[16:25:32] <jepler> seb_kuzminsky: there's devicetree "stuff" in this 3.8 kernel, but the odroid configuration doesn't use it
[16:25:50] <jepler> also not sure how that movie clip fits in to the conversation
[16:28:11] <seb_kuzminsky> post-apocalyptic engineer? maybe it's a stretch
[16:28:19] <jepler> ah
[16:29:02] <pcw_home> pork lips now!
[16:40:59] -!- larryone has quit [Quit: This computer has gone to sleep]
[16:51:24] <jepler> sigh, ten years of blog posts in a markup that nobody else has heard of
[16:51:36] <jepler> makes it rough if you decide to convert to a new blogging framework
[16:51:56] -!- SpeedEvil has quit [Quit: Bitcoin donations - 1G4cmnNzHCXSy7jjT7drT9vgJWquduZTbL]
[16:52:10] <jepler> you might think you can convert the html back down to some modern markup format, but that's not working for me
[16:52:14] <jepler> /home/jepler/.gem/ruby/1.9.1/gems/kramdown-1.4.1/lib/kramdown/converter/kramdown.rb:288:in `convert_img': undefined method `gsub' for nil:NilClass (NoMethodError)
[16:52:34] -!- zeitue has quit [Remote host closed the connection]
[16:52:43] <jepler> http://i1.kym-cdn.com/photos/images/newsfeed/000/234/765/b7e.jpg
[16:56:57] -!- phantoxe has quit []
[16:58:05] <Tom_itx> that's the bush's baked beans dog. about to give away the company secret
[16:59:15] <jepler> [22772383.750792] Out of memory: Kill process 30426 (ruby) score 668 or sacrifice child
[16:59:25] <jepler> oh well, another day
[17:01:47] -!- mhaberler has quit [Quit: mhaberler]
[17:09:38] uwe__ is now known as uwe_
[17:11:06] <CaptHindsight> how many bytes are transferred from host cpu to HM2 in the fpga every servo thread period?
[17:11:16] -!- ravenlock has quit [Quit: Leaving]
[17:11:38] <jepler> CaptHindsight: pcw was saying yesterday that a 32 wide x 64 deep fifo would be enough for typical usage
[17:11:58] -!- skunkworks has quit [Ping timeout: 263 seconds]
[17:12:10] <jepler> CaptHindsight: but the answer depends on which resources are enabled -- more bytes have to be written for one stepgen than for one I/O port
[17:12:38] -!- LatheBuilder has quit [Ping timeout: 250 seconds]
[17:22:52] -!- sudobangbang has quit [Ping timeout: 240 seconds]
[17:24:20] <pcw_home> Yeah maybe 64 to 256 bytes would be a fairly normal range
[17:24:21] <pcw_home> (from a minimal 2/3 axis step/dir or servo system to say 6 axis and lots of I/O points)
[17:27:12] <pcw_home> a 32 wide by 64 FIFO would work for most any amount of hm2 I/O since a "run" (all encoder counters for example)
[17:27:13] <pcw_home> would allow almost 64 channels (with polling for FIFO space for the next run)
[17:28:43] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[17:32:13] <CaptHindsight> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?SPI_Sub-Driver_For_Hostmot2 I just noticed that Andy posted this
[17:34:46] <CaptHindsight> besides DMA from memory into the SPI controller FIFO isn't there also some overhead dealing with the SPI transfers?
[17:36:08] -!- sudobangbang has quit [Ping timeout: 250 seconds]
[17:37:10] <CaptHindsight> there only will be one slave and one master on the SPI bus bettween the ARM SOC and FPGA
[17:38:26] <pcw_home> There's overhead from the protocol ( you need to send address/command data first)
[17:38:27] <pcw_home> this can be reduced by doing "runs"
[17:38:29] <pcw_home> theres also the basic transfer bit rate
[17:39:02] <pcw_home> but all in all not a whole lot different than target mode PCI for example
[17:40:18] <CaptHindsight> I have to look at the SPI registers again but there was more than I expected done in software vs hardware
[17:41:27] <pcw_home> the software should do no more than read/write data once the hardware is setup
[17:42:01] <CaptHindsight> I agree, but is that the actual case with the exynos SPI controller?
[17:42:16] <CaptHindsight> the driver seemed to have much more going on
[17:43:16] <pcw_home> well thats probably why the driver is unusable for rt
[17:44:54] -!- kfoltman has quit [Read error: Connection reset by peer]
[17:44:58] <CaptHindsight> it should just be, init the hardware registers, configure for transfers and protocol then just DMA or PIO to the FIFO
[17:49:18] -!- MoserLabs has quit [Read error: Connection reset by peer]
[17:50:02] -!- acdha has quit [Remote host closed the connection]
[17:50:12] <pcw_home> Yep, that should be all thats needed (especially if you dont mess with setup stuff except once at the beginning)
[17:52:33] -!- txp has quit [Quit: Leaving]
[17:56:25] <CaptHindsight> Exynos 4412 "up to 100MHz Core-P, Global-P domain mainly for other system component, such as system peripherals, peripheral DMAs, connectivity IPs and Audio interfaces."
[17:58:30] <pcw_home> presumable 100 MHz I/O-bus clock
[18:02:27] <CaptHindsight> yes, function block PERI-L that SPI is on 100MHz
[18:03:34] <jepler> CaptHindsight: That wiki page is about mesa fpga cards acting as spi bus masters for other spi slaves
[18:03:45] <jepler> CaptHindsight: while I want to use the linux machine as the spi master for a mesa fpga card that's a spi slave
[18:04:14] <jepler> this works fine except for the 4ms+ latencies in the linux spi driver (ow)
[18:04:51] <jepler> I hacked out some obvous stuff (two memory allocations plus dma channel allocation on every spi transaction) but that didn't fix it
[18:05:13] <jepler> CaptHindsight: in a preempt-rt kernel, is there some tool I should be using to establish where the latency actually happens?
[18:05:19] <jepler> rather than guessing..
[18:05:56] <CaptHindsight> heh, well we were trying to use cyclictest but ...
[18:06:31] -!- James628 has quit [Quit: Page closed]
[18:06:56] <pcw_home> supposedly if you build the right hooks into the kernel you can trigger a trace when you get latency > threshold
[18:07:04] <jepler> right now I suspect that the latency comes in where the spi middle layer spins off the actual spi transaction into an async call and then waits for its completion
[18:07:10] <pcw_home> (with cyclictest)
[18:07:20] <jepler> (by design, the API's all async and they built a sync layer on top of it)
[18:07:29] <CaptHindsight> they broke something in the kernel so it wasn't getting accurate results, the fix is supposed to be in 3.16
[18:07:41] -!- kwallace [kwallace!~kwallace@smb-237.sonnet.com] has joined #linuxcnc-devel
[18:07:48] <jepler> I'm at 3.8 and too tired to try to port all the odroid stuff to newer kernels.
[18:08:01] <CaptHindsight> I understand
[18:08:26] <CaptHindsight> we have been battling on and off with the cubie2
[18:13:22] <CaptHindsight> https://www.osadl.org/Realtime-Preempt-Kernel.kernel-rt.0.html#externaltestingtool
[18:13:49] <CaptHindsight> http://git.kernel.org/cgit/linux/kernel/git/clrkwllms/rt-tests.git
[18:15:25] <CaptHindsight> it would constantly log the latency and trigger output whenever the set limit is exceeded
[18:18:59] <jepler> I'm not sure this is actually "a latency" if it occurs where I think it does
[18:19:15] <CaptHindsight> but the tracer is not currently accurate
[18:20:04] <jepler> CaptHindsight: is there some trick to doing userspace mmio on arm?
[18:20:22] <CaptHindsight> I don't know
[18:20:34] <jepler> I need to find somebody who knows :-/
[18:20:49] <CaptHindsight> I try to stay away from all this, I forget as soon as i walk away from it
[18:21:23] <CaptHindsight> http://git.kernel.org/cgit/linux/kernel/git/clrkwllms/rt-tests.git/tree/src/cyclictest
[18:34:07] -!- jasen_ has quit [Quit: Page closed]
[18:42:01] <memleak> has anyone confirmed that RTAI doesnt work on ARM? :p
[18:42:49] <memleak> i wonder how board specific it is..
[18:44:01] -!- PetefromTn_ has quit [Quit: I'm Outta here!!]
[18:46:22] * memleak takes his first peak at RTAI on arm really quick
[18:47:28] <memleak> theres timer.c code per board..
[18:48:28] <memleak> https://github.com/ShabbyX/RTAI/tree/master/base/arch/arm/hal
[18:50:11] <memleak> well imx and pxa are virtually identical..
[18:50:46] <memleak> :/ i dont know anything about ARM timers..
[18:51:31] <memleak> do we even need a cubieboard2_timer.c?
[18:51:46] -!- tthoren has quit [Quit: Page closed]
[18:53:40] -!- Loetmichel has quit [Ping timeout: 255 seconds]
[18:59:42] -!- karavanjo has quit [Remote host closed the connection]
[19:03:27] -!- Tecan has quit [Quit: Live Long And Phosphor!]
[19:08:27] -!- uwe_ has quit [Ping timeout: 272 seconds]
[19:09:18] -!- mle has quit [Ping timeout: 255 seconds]
[19:11:24] uwe__ is now known as uwe_
[19:12:45] <jepler> hm, reading the documentation more closely, I think the header is attached to spi1 which has a depth-16 fifo, not a depth-64 fifo
[19:13:22] <jepler> but still, trying to fondle any of the registers from userspace just doesn't do what I expect
[19:13:42] <jepler> (even though they're RW registers I never read back a changed register value)
[19:22:17] -!- onyedikilo has quit [Quit: Page closed]
[19:26:42] Guest2328 is now known as JSSKangas_Linux
[19:26:50] <jepler> huh, can it be this simple?
[19:27:14] <jepler> I set the affinity of the kernel processes related to the spi device to the same affinity as rtapi_app
[19:27:20] <jepler> and I have seconds and seconds of OK latency
[19:27:53] <CaptHindsight> \0/
[19:28:13] <skunkworks> Yay!?! ;)
[19:28:24] <jepler> I do not know how I'd do that in an automated fashion
[19:28:30] <jepler> root 32178 0.0 0.0 0 0 ? S 14:27 0:00 [irq/99-spi-s3c6]
[19:28:33] <jepler> root 32179 0.0 0.0 0 0 ? S 14:27 0:00 [spi1]
[19:28:37] <jepler> but surely I can figure it out
[19:30:35] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[19:32:42] -!- sudobangbang has quit [Ping timeout: 255 seconds]
[19:35:39] <jepler> A 17 word x 32 bit transaction (enough to trip into dma mode, I think) now has a tmax of 140ns over several minutes
[19:35:44] <jepler> instead of >4ms in a few seconds
[19:36:00] <jepler> \O/ indeed
[19:36:38] <jepler> spi is running at 30MHz, so it "should" need only 18us but who cares about a little factor of ten
[19:36:56] <pcw_home> Wow thats a lot better
[19:37:09] <jepler> errrr
[19:37:14] <jepler> a tmax of 140us over several minutes
[19:39:29] <jepler> 2 transfers = ~32k typical thread time
[19:39:47] <jepler> 16 transfers = ~57k typical thread time
[19:39:58] <jepler> 17 transfers = ~90k typical thread time
[19:40:23] <pcw_home> DMA setup overhead?
[19:40:27] <jepler> so bumping over the limit into needing dma is noticible
[19:40:31] <jepler> noticable
[19:44:23] <jepler> I'm back to thinking maybe this'll work out
[19:44:33] <jepler> and impatient to get my new board back from fabrication
[19:44:33] -!- eFuchs has quit [Ping timeout: 272 seconds]
[19:45:59] <jepler> 3 - 4 transfers that all hit a 140us worst case clearly means you can't do 500us servo period, but oh well
[19:46:15] <jepler> you'll do 2ms and be thankful!
[19:47:46] <pcw_home> it might be that end to end 140 usec delays are not possible
[19:52:07] <pcw_home> and it should be possible to do everything in single read and a single write
[19:54:03] <jepler> for some reason I had 4 transactions .. one of them being a zero-length transaction at address 0000
[19:54:09] <jepler> http://emergent.unpythonic.net/files/sandbox/spidev-latency-better.png
[19:54:30] <pcw_home> thats a bit odd
[19:54:42] <jepler> yeah I just need to debug it though
[19:55:25] <pcw_home> theres no reason you cant stack multiple commands in one SPI packet
[19:55:38] <jepler> yes, and I'm doing that with hm2-eth style queueing
[19:56:06] <jepler> so I expected 3 spi transactions, since the watchdog bug is still out there
[19:56:23] <pcw_home> well +- the watchdog problem (queing across hal function calls)
[19:56:28] <pcw_home> yep
[20:00:50] -!- FreezingAlt has quit [Ping timeout: 260 seconds]
[20:02:27] <seb_kuzminsky> could move watchdog petting to write (or read)
[20:02:58] -!- skunkworks has quit [Read error: Connection reset by peer]
[20:11:57] <pcw_home> unfortunately that would require eliminating the pet watchdog function in hal
[20:11:59] <pcw_home> or retaining it but moving it before read/write so it could be used to just set a "feed watchdog flag"
[20:14:18] <seb_kuzminsky> i wonder why i made it its own function, instead of just petting the watchdog in write?
[20:14:38] <seb_kuzminsky> maybe so that you could have a read-only setup with no write call?
[20:16:14] <pcw_home> if the function was not used it might be nice to have a feedwd hal pin
[20:17:10] -!- Tecan has quit [Changing host]
[20:17:33] <jepler> tmax up to 240k :-/
[20:18:11] <seb_kuzminsky> bummer
[20:18:38] <seb_kuzminsky> i bet it's that async craziness - try going all the way down to hardware in the write syscall
[20:18:45] <seb_kuzminsky> (says the guy not doing the work)
[20:19:22] <jepler> seb_kuzminsky: Yeah I suspect you're right
[20:19:39] <jepler> but that means tossing the whole kernel driver structure and writing my own, or writing my own in userspace
[20:19:48] <jepler> and as far as the latter goes I'm still way in flail-land
[20:21:13] <jepler> I can understand why, for typical usage, it makes total sense to design the base API as asynch and use a wait primitive for the synch version
[20:21:50] <seb_kuzminsky> it'd be nice if the driver honored O_SYNC
[20:22:09] -!- JesusAlos has quit [Quit: ChatZilla 0.9.90.1 [Firefox 31.0/20140716183446]]
[20:26:43] <jepler> turning off automatic power management of the spi module shaves off about 6us from the typical iteration
[20:26:46] <jepler> jepler@odroid:/sys/devices/platform/exynos4210-spi.1/power$ echo auto | sudo tee control
[20:26:49] <jepler> er, echo on |
[20:27:30] <jepler> turning off whatever resource after under 1ms seems pretty quick on the gun
[20:28:03] <seb_kuzminsky> might make sense for those embedded-type devices
[20:29:06] -!- larryone has quit [Quit: This computer has gone to sleep]
[20:30:38] <jepler> root@odroid:/sys/devices# find -wholename '*/power/control' | while read fn ; do echo on > "$fn"; done
[20:30:41] <jepler> I don't like it
[20:31:02] <seb_kuzminsky> did your fan spin up when you did that
[20:31:07] <jepler> curiously, just about at the same time as I ran that I got some unusual latencies
[20:31:15] <seb_kuzminsky> can you turn off PM stuff in your .config?
[20:32:18] <jepler> possibly I could
[20:33:56] -!- chally_ has quit [Read error: Connection reset by peer]
[20:42:55] <jepler> with all the power management I could find turned off, 80us tmax in 10 minutes (16x 32-bit transfers)
[20:46:25] <seb_kuzminsky> down to 1/3 of the previous tmax, nice
[20:46:35] -!- mle has quit [Remote host closed the connection]
[20:47:38] <jepler> man I had to open my big mouth
[20:47:46] <jepler> tmax went up to 375k shortly after I said something
[20:48:13] <seb_kuzminsky> hah
[20:48:23] <seb_kuzminsky> just shut up so we can get good latency wouldya
[20:51:33] -!- likevinyl has quit [Quit: likevinyl]
[20:51:34] -!- sudobangbang has quit [Ping timeout: 264 seconds]
[20:53:22] -!- skunkworks_ [skunkworks_!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[20:55:42] -!- motioncontrol has quit [Quit: Sto andando via]
[20:56:39] -!- Deejay has quit [Quit: bye]
[20:59:18] -!- eFuchs has quit [Quit: ping timeout]
[21:01:56] -!- FinboySlick has quit [Quit: Leaving.]
[21:02:22] -!- toner has quit [Ping timeout: 264 seconds]
[21:15:25] <seb_kuzminsky> coffee time
[21:18:09] -!- jsskangas has quit [Ping timeout: 260 seconds]
[21:19:25] <jepler> if that's one in a million and they're *not* correlated you might still luck out
[21:19:43] <jepler> (trying to do 3 transactions in 1 or 2ms)
[21:20:28] <jepler> I wish halscope could trigger on "increase"
[21:20:30] <jepler> oh well
[21:21:35] <jepler> fwiw the cpu is measuring at +-1C of the fan activation temperature 45C
[21:22:43] <PCW> I wonder how slow a thread rate would be OK for a step/dir system if the stegen hardware had accel built in
[21:25:11] <jepler> time was that linuxcnc 1.x ran with trajectory at 10ms and interpolated with some kind of spline to 1ms
[21:30:43] <PCW> currently the hardware (stepgen or velocity mode servo)
[21:30:45] <PCW> "extrapolates" from the current velocity, but the stepgen could do a bit better
[21:30:47] <PCW> if it was handed accel (and had the hardware to use it)
[21:34:58] <jepler> we had enough trouble defining what we meant when we said "position should be X at time T"
[21:35:56] <jepler> I imagine it would take us a decade to figure out what we mean when we say what velocity and acceleration must both be at time T as well
[21:48:38] <PCW> yeah, just saying that if the hardware was given the derivatives
[21:48:39] <PCW> for a good curve fit to the next waypoint, the thread rate could be decreased for a given accuracy
[21:48:41] <PCW> (though with side effects for sampling external events, homing, index detection etc)
[21:53:04] -!- FreezingAlt has quit [Ping timeout: 260 seconds]
[21:58:00] -!- uwe_ has quit [Ping timeout: 246 seconds]
[22:10:23] -!- mhaberler has quit [Quit: mhaberler]
[22:11:01] -!- The_Ball has quit [Remote host closed the connection]
[22:21:04] -!- jthornton_ [jthornton_!~john@162.72.174.234] has joined #linuxcnc-devel
[22:21:57] <jepler> someday cradek and I should try again with the probe latch of hm2 encoder
[22:22:12] -!- gonzo_ has quit [Read error: Connection reset by peer]
[22:22:26] <jepler> we quit for two reasons: first of all, we were hitting a bug in the realtime motion controller that we couldn't figure out but think predated our work
[22:22:40] <jepler> .. but second, we read his probe's manual (renshaw wireless) and saw that it has a 20ms delay anyway
[22:22:45] -!- jthornton has quit [Read error: Connection reset by peer]
[22:22:46] -!- anonimasu has quit [Read error: Connection reset by peer]
[22:22:50] -!- Groguard has quit [Ping timeout: 255 seconds]
[22:22:55] -!- balestrino has quit [Ping timeout: 255 seconds]
[22:22:55] -!- benjamin23 has quit [Ping timeout: 255 seconds]
[22:22:55] -!- Flipp___ has quit [Ping timeout: 255 seconds]
[22:23:30] -!- darthrak1 [darthrak1!~darthrake@yasit.net] has joined #linuxcnc-devel
[22:23:35] -!- darthrake has quit [Ping timeout: 255 seconds]
[22:23:50] -!- lexano has quit [Ping timeout: 255 seconds]
[22:23:51] -!- jst has quit [Ping timeout: 255 seconds]
[22:23:54] -!- dramz has quit [Ping timeout: 255 seconds]
[22:24:19] zz_Groguard is now known as Groguard
[22:25:57] z_ is now known as Guest88333
[22:32:56] -!- micges [micges!~captain_p@aehx148.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[22:32:59] -!- toastyde1th has quit [Read error: Connection reset by peer]
[22:33:27] <PCW> since theres only one probe input, its not too bad to compensate for the delay (with a FIFO)
[22:36:53] -!- seb_kuzm1nsky [seb_kuzm1nsky!~seb@174-29-171-252.hlrn.qwest.net] has joined #linuxcnc-devel
[22:36:53] -!- mode/#linuxcnc-devel [+v seb_kuzm1nsky] by ChanServ
[22:37:09] -!- toastyde1th has quit [Read error: Connection reset by peer]
[22:37:13] -!- almccon has quit [Read error: Connection reset by peer]
[22:37:18] -!- gonzo__ has quit [Read error: Connection reset by peer]
[22:37:25] -!- `Nerobro has quit [Ping timeout: 311 seconds]
[22:37:28] -!- Tom_shop [Tom_shop!~Tl@unaffiliated/toml/x-013812] has joined #linuxcnc-devel
[22:37:55] -!- Groguard has quit [*.net *.split]
[22:37:57] -!- Tecan has quit [*.net *.split]
[22:37:59] -!- zeitue has quit [*.net *.split]
[22:37:59] -!- LatheBuilder has quit [*.net *.split]
[22:38:10] -!- XXCoder has quit [*.net *.split]
[22:38:12] -!- copec has quit [*.net *.split]
[22:38:15] -!- bdon has quit [*.net *.split]
[22:38:15] -!- Meduza has quit [*.net *.split]
[22:38:18] -!- TekniQue has quit [*.net *.split]
[22:38:20] -!- racicot has quit [*.net *.split]
[22:38:21] -!- os1r1s has quit [*.net *.split]
[22:38:23] -!- postaL has quit [*.net *.split]
[22:38:23] -!- ChuangTzu_ has quit [*.net *.split]
[22:38:23] -!- inventor42 has quit [*.net *.split]
[22:38:24] p0staL is now known as postaL
[22:38:25] inventor42_ is now known as inventor42
[22:38:40] -!- Tom_itx has quit [Ping timeout: 261 seconds]
[22:38:57] -!- PetefromTn_ has quit [Ping timeout: 246 seconds]
[22:39:00] bdon_ is now known as bdon
[22:39:03] -!- asdfasd has quit [Ping timeout: 240 seconds]
[22:42:05] -!- Jeebiss has quit [Ping timeout: 240 seconds]
[22:42:08] -!- logger[psha] has quit [Ping timeout: 240 seconds]
[22:43:21] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc-devel
[22:43:33] -!- _1SheYode has quit [Ping timeout: 255 seconds]
[22:43:34] -!- `Nerobro_ has quit [Ping timeout: 246 seconds]
[22:43:37] -!- syyl has quit [Ping timeout: 255 seconds]
[22:43:40] racicot_ is now known as racicot
[22:44:02] -!- kfoltman has quit [Quit: Ex-Chat]
[22:44:05] -!- Meduza89 has quit [*.net *.split]
[22:44:07] -!- sumpfralle has quit [*.net *.split]
[22:44:11] -!- i_tarzan has quit [*.net *.split]
[22:44:14] -!- Rab has quit [*.net *.split]
[22:44:16] -!- CaptHindsight has quit [*.net *.split]
[22:44:16] -!- hm2-buildmaster has quit [*.net *.split]
[22:44:17] -!- schimmi has quit [*.net *.split]
[22:44:20] -!- KimK has quit [*.net *.split]
[22:44:24] -!- summatusmentis has quit [*.net *.split]
[22:44:25] -!- seb_kuzminsky has quit [*.net *.split]
[22:44:28] -!- pthorin has quit [*.net *.split]
[22:44:29] -!- cpresser has quit [*.net *.split]
[22:44:41] -!- asdfasd1 has quit [Ping timeout: 250 seconds]
[22:44:49] -!- toastyde1th has quit [Read error: Connection reset by peer]
[22:44:52] -!- hm2-buildmaster [hm2-buildmaster!~hm2-build@174-29-171-252.hlrn.qwest.net] has joined #linuxcnc-devel
[22:44:54] -!- Lathe_newbie has quit [Ping timeout: 260 seconds]
[22:44:57] -!- ries has quit [Ping timeout: 282 seconds]
[22:44:59] ries_nicked is now known as ries
[22:45:03] -!- _balestrino has quit [Ping timeout: 255 seconds]
[22:45:28] -!- KimK [KimK!~Kim__@ip68-102-30-143.ks.ok.cox.net] has joined #linuxcnc-devel
[22:45:36] -!- Flipp_ has quit [Ping timeout: 246 seconds]
[22:47:19] -!- CaptHindsight [CaptHindsight!~2020@adsl-75-57-146-7.dsl.emhril.sbcglobal.net] has joined #linuxcnc-devel
[22:47:24] schimmi_ is now known as schimmi
[22:49:24] -!- mhaberler has quit [Quit: mhaberler]
[22:50:33] seb_kuzm1nsky is now known as seb_kuzminsky
[22:50:46] <seb_kuzminsky> hm, someone should release the xhc udev rules fix
[22:50:49] <seb_kuzminsky> oh wait, that's me
[22:54:36] <PCW> what do you think of making the feed wd function just toggle a flag
[22:54:37] <PCW> (to simplify enqueuing the I/O )
[22:55:04] -!- bdon has quit [Changing host]
[22:55:45] <seb_kuzminsky> why not just make write always do it, automatically, and get rid of the special watchdog function entirely?
[22:56:03] -!- Jeebiss_ has quit [Changing host]
[22:56:03] -!- SkramX has quit [Changing host]
[22:56:07] <PCW> well i guess anything goes for 2.7
[22:56:49] <PCW> you might want a pin to feed the WD with in that case
[22:57:01] <seb_kuzminsky> yeah, i dont wanna monkey with it in 2.6, but 2.7 seems reasonable to me
[22:57:07] <seb_kuzminsky> what does the pin add?
[22:57:47] <PCW> I guess if JA(N) gets merged, halfiles will need to change anyway
[22:57:56] jthornton_ is now known as jthornton
[22:57:57] <seb_kuzminsky> yep
[22:58:32] <PCW> the pin gives hal access to the wd (say if there was a sanity check comp)
[22:58:32] <seb_kuzminsky> i donno about the rest of you fine people, but i'm starting to get the itch to branch 2.7 for stabilization...
[22:58:55] <seb_kuzminsky> the new tp makes it worth it
[22:59:12] <PCW> Yep
[22:59:24] <seb_kuzminsky> oh, and arm support, and rt-preempt, i almost forgot
[23:00:11] <PCW> a really large set of changes
[23:00:12] <seb_kuzminsky> PCW: there's a watchdog(9) component that people might use in their estop chain, i hadn't considered having it shut down the fpga too...
[23:01:33] <PCW> getting rid of the pet wd function would make both the Ethernet and SPI drivers better
[23:01:42] <seb_kuzminsky> problem with a watchdog bite is, the user needs to go into HAL and fiddle with the hm2*watchdog.has_bit, or restart linuxcnc all together
[23:02:20] <seb_kuzminsky> it's probably almost always better to make the "linuxcnc-level watchdog" stop things at a higher level, like an estop up in motion
[23:03:23] <seb_kuzminsky> maybe the hm2 watchdog state should be part of the estop chain, to signal "i lost communication with the fpga" up to motion
[23:03:44] <seb_kuzminsky> currently you get a lack of updates on feedback position, which triggers ferror
[23:04:10] <PCW> more sanity checking would be good
[23:04:49] <seb_kuzminsky> ok, moving pet_watchdog functionality into .write seems like a win, as long as no one uses hm2_read without hm2_write
[23:05:47] <PCW> seems fairly unlikely (DRO only app?)
[23:07:44] -!- patrickarlt has quit [Remote host closed the connection]
[23:08:37] <seb_kuzminsky> one can imagine some hal circuitry like: .has_bit -> not -> charge_pump -> watchdog -> emc-enable-in
[23:09:02] <seb_kuzminsky> err, or .has_bit -> not -> enable-in
[23:09:23] <seb_kuzminsky> (with an OR on the enable-in, so other things can estop the machine too)
[23:10:05] <seb_kuzminsky> that's the useful thing, right? to let the hm2 watchdog estop the machine? rather than let something else in hal cause an hm2 watchdog bite on the fpga
[23:10:19] <PCW> The hardware watchdog is mainly for really bad cases (host crashed)
[23:10:36] <seb_kuzminsky> yeah, or the parallel cable fell off
[23:19:27] <jepler> let me toss another item on the pile:
[23:19:33] <jepler> the very first watchdog write should clear the bite
[23:19:57] <jepler> that fixes interactively loading hm2_whatever and the human-scale time that elapses from there to "addf" and "start"
[23:21:15] <jepler> tmax up to 1ms
[23:21:22] -!- syyl_ has quit [Ping timeout: 240 seconds]
[23:22:08] <jepler> going back to my hacked spidev.ko which eliminated runtime memory allocations to see if that fares better
[23:22:26] <PCW> isn't the wd currently disabled until the timeout is set?
[23:23:01] <jepler> PCW: I have seen behavior I interpreted differently
[23:23:15] <jepler> let me do that thing now and say accurately what I see
[23:24:37] -!- Tecan has quit [Ping timeout: 260 seconds]
[23:25:03] -!- amiri_ has quit [Read error: Connection reset by peer]
[23:25:13] <jepler> well, "doctor doctor", here's what happens currently when I add other threads before pet-watchdog:
http://paste.debian.net/117760/
[23:26:19] <PCW> hmm maybe its just set for a "long" time at startup
[23:26:22] <jepler> apparently it's OK interactively as long as you remember to add pet_watchdog first
[23:27:22] <seb_kuzminsky> the watchdog should be disabled until the first pet, currently
[23:27:48] <seb_kuzminsky> there used to be a silly long timeout, to handle the gap between loadrt hm2_pci and start, but i fixed that way back when
[23:28:06] -!- Tecan has quit [Changing host]
[23:28:12] <jepler> seb_kuzminsky: if that's the case, why the result in my pastebin?
[23:28:36] <seb_kuzminsky> because you didn't add the pet_watchdog
[23:28:55] <jepler> <+seb_kuzminsky> the watchdog should be disabled until the first pet, currently
[23:29:09] <seb_kuzminsky> maybe i meant "until the first write"
[23:29:11] <seb_kuzminsky> hold on
[23:29:50] <seb_kuzminsky> yeah, hm2_write does watchdog_write, which sets the timeout and starts the watchdog
[23:30:21] <seb_kuzminsky> i bet i never considered that someone would have write without pet
[23:30:24] -!- amiri has quit [Ping timeout: 246 seconds]
[23:31:01] <jepler> this addf order at interactive speeds is OK:
[23:31:01] <jepler> halcmd: addf hm2_5i20.0.read thread1
[23:31:01] <jepler> halcmd: addf hm2_5i20.0.pet_watchdog thread1
[23:31:01] <jepler> halcmd: addf hm2_5i20.0.write thread1
[23:31:15] <jepler> so yes, it's the case where pet is added after write
[23:31:55] <jepler> so your idea to put pet watchdog in write makes even more sense
[23:32:00] <jepler> it doesn't matter to anyone who only reads
[23:32:12] <seb_kuzminsky> hm2_write() sets watchdog.enable to True, in a case of bogus data-hiding-violation
[23:32:13] <jepler> a biting watchdog has no effect on reads afaik
[23:32:23] <seb_kuzminsky> jepler: i think that's right
[23:32:30] <seb_kuzminsky> ok then
[23:32:36] <jepler> so yeah, roll pet_watchdog into write
[23:32:40] <PCW> nope not in the firmware
[23:32:52] <seb_kuzminsky> so say we all
[23:33:12] <PCW> all wd bite does is clear the DDR/OD registers
[23:33:20] <seb_kuzminsky> i'd planned to build a new hm2-based controller for the robot arm at the hackspace tonight, i
[23:33:30] <seb_kuzminsky> i'll try to fit this hm2 watchdog change in
[23:33:30] <PCW> (and set the bitten flag)
[23:34:24] <PCW> big plus for Ethernet (one whole packet/syscall saved)
[23:34:44] <seb_kuzminsky> lol, the pet_wathdog function *also* sets enable to True.
[23:34:51] <seb_kuzminsky> what kind of jerk wrote this garbage
[23:35:01] <jepler> just for grins I should try 7i80 on the odroid, even though I know its ethernet is on usb
[23:35:55] <PCW> i ran a 7I80 on a USB ethernet dongle for a couple hours (till a 10 ms delay)
[23:36:45] <jepler> seb_kuzminsky: I am toying with an idea. I think it would be nice if the board information were declarative instead of imperative.
http://paste.debian.net/117761/
[23:37:45] <jepler> seb_kuzminsky: it would be particularly nice for boards that don't have volatile firmware, so you can just start off with a read of the idrom id
[23:38:23] -!- kwallace [kwallace!~kwallace@smb-237.sonnet.com] has parted #linuxcnc-devel
[23:38:24] <jepler> but in hm2_pci all you'd have to do is case (pci id of 5i20): look up "MESA5I20" in table
[23:59:41] -!- Nick001-shop has quit [Quit: ChatZilla 0.9.90.1 [Firefox 30.0/20140605174243]]
