Back
[06:33:05] <tinkerer> @jepler: have a look @ this:
[06:33:05] <tinkerer> https://code.google.com/p/picnc/source/browse/#git%2FHAL
[06:33:05] <tinkerer> probably you know Gemis driver.
[06:33:05] <tinkerer> https://github.com/tinkercnc/spi-fpga-driver
[06:33:05] <tinkerer> here is the raspi-spi not based on the spidev driver
[06:33:05] <tinkerer> the spidev driver in linux is a shame.
[06:33:06] <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.
[06:33:06] <tinkerer> the raspi-version with server (encoder) works well.
[07:35:18] <jepler> tinkerer: thanks for the links, will look..
[07:37:59] <jepler> tinkerer: so your experience with bbb is that its /dev/spidev is also terrible for RT performance?
[07:38:19] <jepler> it makes me feel a little better if it's not "my fault" :)
[07:40:16] <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
[07:40:33] <jepler> tinkerer: please credit me. 1 // Copyright (C) 2007 Jeff Epler
[07:41:31] <jepler> gplv3+ is not a problem, but you should properly preserve copyright notices from the original code
[07:41:56] <jepler> thanks
[07:42:10] <memleak> heh, when i did all the heavy lifting for 64-bit 3.x kernel RTAI paolo left me out of the headers
[07:42:26] <memleak> preamble, whatever its called
[07:44:39] <jepler> memleak: stuff like properly crediting authors is not the *fun* part, so I totally get thta it gets overlooked.
[07:47:01] <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
[07:47:37] <memleak> whats the way to overwrite git history again?
[07:47:59] <jepler> it's git, there's more than one way :)
[07:48:48] <memleak> ah yes.. forgot about that
[07:48:54] <jepler> you can use git rebase and select to "edit" a commit
[07:49:16] <memleak> can you delete a commit?
[07:49:30] <memleak> i saw one of the xen kernel devs do that..
[07:49:35] <jepler> when editing the "git rebase" list of instructions, you can just delete a line
[07:50:02] <memleak> there was a change he made to the code then it didnt show up anymore in gitweb
[07:50:22] <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
[07:50:34] <jepler> do that until your commit is split up into 2, 3, ... parts and everything is committed
[07:50:37] <jepler> then git rebase --continue
[07:50:58] <memleak> that will merge the 3 commits into one?
[07:51:08] <jepler> you want to merge the three commits? I misunderstood.
[07:51:13] <jepler> to do that, you still want git rebase
[07:51:23] <memleak> well and make changes to the commits
[07:51:32] <jepler> but you want to "squash" the commits
[07:51:41] <memleak> yes, with modifications
[07:52:48] <jepler> to squash *and* edit, you'll have to go through the rebase process twice
[07:53:02] <memleak> oh dear..
[07:53:05] <jepler> though after any line you can also write "x bash" to drop into a shell at that point
[07:53:38] <jepler> at which point you could edit and amend the commit
[07:54:01] <memleak> after any line.. what do you mean by that?
[07:54:06] <jepler> I'm not trying to scare you off from doing sophisticated things with git ..
[07:54:17] <memleak> at which point would i run x bash?
[07:54:53] <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
[07:54:59] <jepler> with each line saying "pick"
[07:55:00] <jepler> pick ef8d52c interp: use strings to avoid buffer hell
[07:55:00] <jepler> pick 859e90b hostmot2: support boards on spi interface
[07:55:13] <jepler> you edit these instructions to make git rebase do what you want
[07:55:23] <jepler> -i ("interactive") is a part that I neglected to mention
[07:55:36] <memleak> ok thanks ill try and give that a shot
[07:56:05] <jepler> so for instance if you want to rewrite the last 3 commits, you may want to start with git rebase -i HEAD~3
[07:56:24] <jepler> you'll be able to see from the commit titles if you got the commits you intended to rebase
[07:56:31] <jepler> I need to head in to $DAY_JOB so afk...
[07:56:41] <memleak> ok see ya thanks!
[07:57:07] <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
[07:57:30] <jepler> (B) even anything you've "git commited" will be recoverable after a mistake
[07:57:43] <jepler> and (C) you'll eventually become comfortable with git rebase, and then you'll have a very powerful tool
[07:58:07] <jepler> (but for B you have to learn some new git stuff before you can recover it -- the "reflog")
[07:58:12] <jepler> anyway, afk
[08:00:32] <memleak> NAILED IT
[08:00:35] <memleak> thanks jepler!!!
[08:06:29] <skunkworks> memleak, how does this compare to the rtai on the wheezy livecd?
[08:07:29] <tinkerer> jepler: are you contented?
https://github.com/tinkercnc/spi-fpga-driver/tree/master/RaspberryPi
[08:11:33] <tinkerer> jepler: the BBB has generally a problematic spi interface:
http://e2e.ti.com/support/arm/sitara_arm/f/791/t/212616.aspx
[08:14:57] <memleak> wheezy uses old-master from august right?
[08:15:05] <memleak> one moment
[08:17:06] <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)
[08:20:52] <jepler> tinkerer: thank you
[08:21:04] <memleak> im sure whatever your results are right now, you'll get different ones if you use 3.14 w/ my new tree
[08:21:39] <memleak> tree is in flux for the next few minutes, reworking scheduler commits
[08:21:59] <skunkworks> no rush
[08:22:09] <skunkworks> (and I don't know how to do that from source...)
[08:24:36] <memleak> ah.. yeah you need to build a kernel and whatnot
[08:24:53] <memleak> i can tar one up for you and you can throw it in /boot and run update-grub :P
[08:26:33] <jepler> that just breaks the linuxcnc packages
[08:27:42] <memleak> ah right..
[08:36:27] <memleak> sweet, now its clean!
https://github.com/NTULINUX/RTAI/commit/2df23cc0debb051c88bb9c87b8a93d041b34b34c
[08:36:58] <memleak> present_mask vs active_mask affects whether i get a kernel panic when i close latency-test
[08:45:01] <jepler> how about fixing it so you don't get a panic when you close latency-test
[08:45:03] <jepler> I bet that would be best
[08:45:08] * jepler <--- experienced dev
[08:45:31] <memleak> i dont anymore
[08:45:44] <memleak> (because i changed it)
[08:45:54] <jepler> I figured, actually
[08:45:56] <memleak> XD
[08:46:00] <jepler> just a ltitle sarcasm on the internet
[08:46:13] <memleak> hahaa
[08:55:44] <skunkworks> cradek, that pendon is cool! (jepler - great picture)
[08:55:49] <skunkworks> (s)
[08:56:05] <skunkworks> pendent
[08:56:11] <skunkworks> jeeze
[09:01:05] <memleak> ah my spurious APIC interrupts are gone now
[09:01:23] <memleak> https://github.com/NTULINUX/RTAI/commit/2f749c34ceef979ddcbc05ed04c790bd5022af05
[09:02:42] <memleak> skunkworks, it differs from wheezy in a lot of ways, one is 3.14 and 3.10 kernel support.
[09:03:13] <memleak> the other is 64-bit support which works flawlessly (for me) i still need to test 32-bit though...
[09:03:54] <memleak> it also has a new scheduler :)
[09:04:05] <memleak> along with a new timer setup
[09:07:48] <skunkworks> memleak - is there directions anywhere on how to build it from source?
[09:10:15] <memleak> README.INSTALL but youll need to make a kernel config
[09:10:29] <memleak> if you give me lspci -k and dmesg output i can make you one
[09:10:42] <memleak> do you know how to build linuxcnc?
[09:14:45] <skunkworks> yes
[09:19:19] <memleak> ok :)
[09:26:10] <memleak> just slap them up on dpaste or something and ill make one
[09:26:19] <memleak> i make custom kernels all the time
[09:26:25] <memleak> at least twice a day :P
[09:33:07] <skunkworks> heh - does it matter what kernel I boot to get the lspci and dmesg?
[09:34:08] <jepler> skunkworks: you want do get dmesg from a kernel which supports all your hardware
[09:35:02] <skunkworks> jepler, thanks
[09:45:26] <seb_kuzminsky> oh goodie, another neer-a-car update this morning :-)
[09:46:08] <skunkworks> link?
[09:46:48] <memleak> lspci -k reads directly from PCI bus, not kernel though
[09:46:50] <memleak> lspci is more important
[09:46:55] <memleak> dmesg is for fine tuning
[09:46:57] <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?
[09:49:17] <seb_kuzminsky> http://bodgesoc.blogspot.com/2014/08/Neracar8.html
[10:00:17] <skunkworks> wow
[10:28:37] <cradek> andy's amazing
[10:32:17] <skunkworks> isn't he? unreal
[10:47:15] <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
[10:47:29] <memleak> funtoo, etc
[11:30:42] <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....
[11:32:27] <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
[11:33:23] <seb_kuzminsky> thx
[11:34:26] <seb_kuzminsky> gods what a mess
[11:34:37] <seb_kuzminsky> (the arm situation, not jeff's repo)
[11:35:11] <jepler> give it a dozen years and it'll be fine
[11:35:22] <jepler> or we'll all be living in a postapocalyptic wasteland
[11:38:40] <memleak> ive been using preempt_rt on my cubieboard2
[11:38:59] <memleak> 3.4.103 i believe.
[11:39:24] <memleak> going to probably switch over to xenomai though
[11:39:49] <memleak> i cant merge in the xenomai code as cleanly as i thought so i wont be the one to conquer that task
[11:40:04] <memleak> for xenomai i just merge the whole branch with master locally
[11:40:12] <memleak> well.. 2.6 branch
[11:40:14] <seb_kuzminsky> jepler: ok, but i get to be tom waits,
http://movieclips.com/htFZb-the-book-of-eli-movie-ill-wait-here/
[11:40:59] <seb_kuzminsky> which kernel.org kernel added devicetree?
[11:44:21] <jepler> seb_kuzminsky: there's devicetree "stuff" in this 3.8 kernel, but the odroid configuration doesn't use it
[11:44:39] <jepler> also not sure how that movie clip fits in to the conversation
[11:47:00] <seb_kuzminsky> post-apocalyptic engineer? maybe it's a stretch
[11:47:08] <jepler> ah
[11:47:51] <pcw_home> pork lips now!
[12:10:13] <jepler> sigh, ten years of blog posts in a markup that nobody else has heard of
[12:10:25] <jepler> makes it rough if you decide to convert to a new blogging framework
[12:10:59] <jepler> you might think you can convert the html back down to some modern markup format, but that's not working for me
[12:11:03] <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)
[12:11:32] <jepler> http://i1.kym-cdn.com/photos/images/newsfeed/000/234/765/b7e.jpg
[12:16:55] <Tom_itx> that's the bush's baked beans dog. about to give away the company secret
[12:18:04] <jepler> [22772383.750792] Out of memory: Kill process 30426 (ruby) score 668 or sacrifice child
[12:18:14] <jepler> oh well, another day
[12:29:55] <CaptHindsight> how many bytes are transferred from host cpu to HM2 in the fpga every servo thread period?
[12:30:27] <jepler> CaptHindsight: pcw was saying yesterday that a 32 wide x 64 deep fifo would be enough for typical usage
[12:30:59] <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
[12:43:09] <pcw_home> Yeah maybe 64 to 256 bytes would be a fairly normal range
[12:43:11] <pcw_home> (from a minimal 2/3 axis step/dir or servo system to say 6 axis and lots of I/O points)
[12:46:01] <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)
[12:46:02] <pcw_home> would allow almost 64 channels (with polling for FIFO space for the next run)
[12:51:02] <CaptHindsight> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?SPI_Sub-Driver_For_Hostmot2 I just noticed that Andy posted this
[12:53:35] <CaptHindsight> besides DMA from memory into the SPI controller FIFO isn't there also some overhead dealing with the SPI transfers?
[12:55:59] <CaptHindsight> there only will be one slave and one master on the SPI bus bettween the ARM SOC and FPGA
[12:57:15] <pcw_home> There's overhead from the protocol ( you need to send address/command data first)
[12:57:16] <pcw_home> this can be reduced by doing "runs"
[12:57:18] <pcw_home> theres also the basic transfer bit rate
[12:57:51] <pcw_home> but all in all not a whole lot different than target mode PCI for example
[12:59:07] <CaptHindsight> I have to look at the SPI registers again but there was more than I expected done in software vs hardware
[13:00:16] <pcw_home> the software should do no more than read/write data once the hardware is setup
[13:00:51] <CaptHindsight> I agree, but is that the actual case with the exynos SPI controller?
[13:01:04] <CaptHindsight> the driver seemed to have much more going on
[13:02:05] <pcw_home> well thats probably why the driver is unusable for rt
[13:03:48] <CaptHindsight> it should just be, init the hardware registers, configure for transfers and protocol then just DMA or PIO to the FIFO
[13:09:02] <pcw_home> Yep, that should be all thats needed (especially if you dont mess with setup stuff except once at the beginning)
[13:15:14] <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."
[13:17:20] <pcw_home> presumable 100 MHz I/O-bus clock
[13:21:16] <CaptHindsight> yes, function block PERI-L that SPI is on 100MHz
[13:22:23] <jepler> CaptHindsight: That wiki page is about mesa fpga cards acting as spi bus masters for other spi slaves
[13:22:34] <jepler> CaptHindsight: while I want to use the linux machine as the spi master for a mesa fpga card that's a spi slave
[13:23:03] <jepler> this works fine except for the 4ms+ latencies in the linux spi driver (ow)
[13:23:40] <jepler> I hacked out some obvous stuff (two memory allocations plus dma channel allocation on every spi transaction) but that didn't fix it
[13:24:02] <jepler> CaptHindsight: in a preempt-rt kernel, is there some tool I should be using to establish where the latency actually happens?
[13:24:08] <jepler> rather than guessing..
[13:24:45] <CaptHindsight> heh, well we were trying to use cyclictest but ...
[13:25:45] <pcw_home> supposedly if you build the right hooks into the kernel you can trigger a trace when you get latency > threshold
[13:25:54] <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
[13:26:00] <pcw_home> (with cyclictest)
[13:26:09] <jepler> (by design, the API's all async and they built a sync layer on top of it)
[13:26:18] <CaptHindsight> they broke something in the kernel so it wasn't getting accurate results, the fix is supposed to be in 3.16
[13:26:37] <jepler> I'm at 3.8 and too tired to try to port all the odroid stuff to newer kernels.
[13:26:50] <CaptHindsight> I understand
[13:27:15] <CaptHindsight> we have been battling on and off with the cubie2
[13:32:11] <CaptHindsight> https://www.osadl.org/Realtime-Preempt-Kernel.kernel-rt.0.html#externaltestingtool
[13:32:38] <CaptHindsight> http://git.kernel.org/cgit/linux/kernel/git/clrkwllms/rt-tests.git
[13:34:14] <CaptHindsight> it would constantly log the latency and trigger output whenever the set limit is exceeded
[13:37:48] <jepler> I'm not sure this is actually "a latency" if it occurs where I think it does
[13:38:04] <CaptHindsight> but the tracer is not currently accurate
[13:38:53] <jepler> CaptHindsight: is there some trick to doing userspace mmio on arm?
[13:39:11] <CaptHindsight> I don't know
[13:39:23] <jepler> I need to find somebody who knows :-/
[13:39:38] <CaptHindsight> I try to stay away from all this, I forget as soon as i walk away from it
[13:40:12] <CaptHindsight> http://git.kernel.org/cgit/linux/kernel/git/clrkwllms/rt-tests.git/tree/src/cyclictest
[14:00:50] <memleak> has anyone confirmed that RTAI doesnt work on ARM? :p
[14:01:38] <memleak> i wonder how board specific it is..
[14:05:11] * memleak takes his first peak at RTAI on arm really quick
[14:06:17] <memleak> theres timer.c code per board..
[14:07:17] <memleak> https://github.com/ShabbyX/RTAI/tree/master/base/arch/arm/hal
[14:09:00] <memleak> well imx and pxa are virtually identical..
[14:09:35] <memleak> :/ i dont know anything about ARM timers..
[14:10:20] <memleak> do we even need a cubieboard2_timer.c?
[14:31:34] <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
[14:32:11] <jepler> but still, trying to fondle any of the registers from userspace just doesn't do what I expect
[14:32:31] <jepler> (even though they're RW registers I never read back a changed register value)
[14:45:39] <jepler> huh, can it be this simple?
[14:46:03] <jepler> I set the affinity of the kernel processes related to the spi device to the same affinity as rtapi_app
[14:46:09] <jepler> and I have seconds and seconds of OK latency
[14:46:42] <CaptHindsight> \0/
[14:47:03] <skunkworks> Yay!?! ;)
[14:47:13] <jepler> I do not know how I'd do that in an automated fashion
[14:47:19] <jepler> root 32178 0.0 0.0 0 0 ? S 14:27 0:00 [irq/99-spi-s3c6]
[14:47:22] <jepler> root 32179 0.0 0.0 0 0 ? S 14:27 0:00 [spi1]
[14:47:26] <jepler> but surely I can figure it out
[14:54:29] <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
[14:54:33] <jepler> instead of >4ms in a few seconds
[14:54:49] <jepler> \O/ indeed
[14:55:27] <jepler> spi is running at 30MHz, so it "should" need only 18us but who cares about a little factor of ten
[14:55:45] <pcw_home> Wow thats a lot better
[14:55:58] <jepler> errrr
[14:56:03] <jepler> a tmax of 140us over several minutes
[14:58:18] <jepler> 2 transfers = ~32k typical thread time
[14:58:36] <jepler> 16 transfers = ~57k typical thread time
[14:58:47] <jepler> 17 transfers = ~90k typical thread time
[14:59:12] <pcw_home> DMA setup overhead?
[14:59:16] <jepler> so bumping over the limit into needing dma is noticible
[14:59:20] <jepler> noticable
[15:03:12] <jepler> I'm back to thinking maybe this'll work out
[15:03:22] <jepler> and impatient to get my new board back from fabrication
[15:04:49] <jepler> 3 - 4 transfers that all hit a 140us worst case clearly means you can't do 500us servo period, but oh well
[15:05:04] <jepler> you'll do 2ms and be thankful!
[15:06:35] <pcw_home> it might be that end to end 140 usec delays are not possible
[15:10:56] <pcw_home> and it should be possible to do everything in single read and a single write
[15:12:52] <jepler> for some reason I had 4 transactions .. one of them being a zero-length transaction at address 0000
[15:12:58] <jepler> http://emergent.unpythonic.net/files/sandbox/spidev-latency-better.png
[15:13:20] <pcw_home> thats a bit odd
[15:13:31] <jepler> yeah I just need to debug it though
[15:14:14] <pcw_home> theres no reason you cant stack multiple commands in one SPI packet
[15:14:27] <jepler> yes, and I'm doing that with hm2-eth style queueing
[15:14:55] <jepler> so I expected 3 spi transactions, since the watchdog bug is still out there
[15:15:12] <pcw_home> well +- the watchdog problem (queing across hal function calls)
[15:15:17] <pcw_home> yep
[15:21:16] <seb_kuzminsky> could move watchdog petting to write (or read)
[15:30:47] <pcw_home> unfortunately that would require eliminating the pet watchdog function in hal
[15:30:48] <pcw_home> or retaining it but moving it before read/write so it could be used to just set a "feed watchdog flag"
[15:33:07] <seb_kuzminsky> i wonder why i made it its own function, instead of just petting the watchdog in write?
[15:33:27] <seb_kuzminsky> maybe so that you could have a read-only setup with no write call?
[15:35:03] <pcw_home> if the function was not used it might be nice to have a feedwd hal pin
[15:36:22] <jepler> tmax up to 240k :-/
[15:37:00] <seb_kuzminsky> bummer
[15:37:27] <seb_kuzminsky> i bet it's that async craziness - try going all the way down to hardware in the write syscall
[15:37:34] <seb_kuzminsky> (says the guy not doing the work)
[15:38:12] <jepler> seb_kuzminsky: Yeah I suspect you're right
[15:38:28] <jepler> but that means tossing the whole kernel driver structure and writing my own, or writing my own in userspace
[15:38:37] <jepler> and as far as the latter goes I'm still way in flail-land
[15:40:02] <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
[15:40:39] <seb_kuzminsky> it'd be nice if the driver honored O_SYNC
[15:45:32] <jepler> turning off automatic power management of the spi module shaves off about 6us from the typical iteration
[15:45:35] <jepler> jepler@odroid:/sys/devices/platform/exynos4210-spi.1/power$ echo auto | sudo tee control
[15:45:38] <jepler> er, echo on |
[15:46:19] <jepler> turning off whatever resource after under 1ms seems pretty quick on the gun
[15:46:52] <seb_kuzminsky> might make sense for those embedded-type devices
[15:49:27] <jepler> root@odroid:/sys/devices# find -wholename '*/power/control' | while read fn ; do echo on > "$fn"; done
[15:49:31] <jepler> I don't like it
[15:49:51] <seb_kuzminsky> did your fan spin up when you did that
[15:49:56] <jepler> curiously, just about at the same time as I ran that I got some unusual latencies
[15:50:04] <seb_kuzminsky> can you turn off PM stuff in your .config?
[15:51:07] <jepler> possibly I could
[16:01:44] <jepler> with all the power management I could find turned off, 80us tmax in 10 minutes (16x 32-bit transfers)
[16:05:15] <seb_kuzminsky> down to 1/3 of the previous tmax, nice
[16:06:27] <jepler> man I had to open my big mouth
[16:06:35] <jepler> tmax went up to 375k shortly after I said something
[16:07:02] <seb_kuzminsky> hah
[16:07:12] <seb_kuzminsky> just shut up so we can get good latency wouldya
[16:34:15] <seb_kuzminsky> coffee time
[16:38:14] <jepler> if that's one in a million and they're *not* correlated you might still luck out
[16:38:32] <jepler> (trying to do 3 transactions in 1 or 2ms)
[16:39:17] <jepler> I wish halscope could trigger on "increase"
[16:39:19] <jepler> oh well
[16:40:24] <jepler> fwiw the cpu is measuring at +-1C of the fan activation temperature 45C
[16:41:33] <PCW> I wonder how slow a thread rate would be OK for a step/dir system if the stegen hardware had accel built in
[16:44:00] <jepler> time was that linuxcnc 1.x ran with trajectory at 10ms and interpolated with some kind of spline to 1ms
[16:49:33] <PCW> currently the hardware (stepgen or velocity mode servo)
[16:49:34] <PCW> "extrapolates" from the current velocity, but the stepgen could do a bit better
[16:49:36] <PCW> if it was handed accel (and had the hardware to use it)
[16:53:48] <jepler> we had enough trouble defining what we meant when we said "position should be X at time T"
[16:54:45] <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
[17:07:27] <PCW> yeah, just saying that if the hardware was given the derivatives
[17:07:29] <PCW> for a good curve fit to the next waypoint, the thread rate could be decreased for a given accuracy
[17:07:30] <PCW> (though with side effects for sampling external events, homing, index detection etc)
[17:40:46] <jepler> someday cradek and I should try again with the probe latch of hm2 encoder
[17:41:16] <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
[17:41:30] <jepler> .. but second, we read his probe's manual (renshaw wireless) and saw that it has a 20ms delay anyway
[17:52:16] <PCW> since theres only one probe input, its not too bad to compensate for the delay (with a FIFO)
[18:09:36] <seb_kuzminsky> hm, someone should release the xhc udev rules fix
[18:09:39] <seb_kuzminsky> oh wait, that's me
[18:13:25] <PCW> what do you think of making the feed wd function just toggle a flag
[18:13:27] <PCW> (to simplify enqueuing the I/O )
[18:14:34] <seb_kuzminsky> why not just make write always do it, automatically, and get rid of the special watchdog function entirely?
[18:14:56] <PCW> well i guess anything goes for 2.7
[18:15:38] <PCW> you might want a pin to feed the WD with in that case
[18:15:51] <seb_kuzminsky> yeah, i dont wanna monkey with it in 2.6, but 2.7 seems reasonable to me
[18:15:57] <seb_kuzminsky> what does the pin add?
[18:16:36] <PCW> I guess if JA(N) gets merged, halfiles will need to change anyway
[18:16:46] <seb_kuzminsky> yep
[18:17:21] <PCW> the pin gives hal access to the wd (say if there was a sanity check comp)
[18:17:22] <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...
[18:17:45] <seb_kuzminsky> the new tp makes it worth it
[18:18:01] <PCW> Yep
[18:18:14] <seb_kuzminsky> oh, and arm support, and rt-preempt, i almost forgot
[18:19:01] <PCW> a really large set of changes
[18:19:01] <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...
[18:20:22] <PCW> getting rid of the pet wd function would make both the Ethernet and SPI drivers better
[18:20:31] <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
[18:21:09] <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
[18:22:12] <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
[18:22:33] <seb_kuzminsky> currently you get a lack of updates on feedback position, which triggers ferror
[18:22:59] <PCW> more sanity checking would be good
[18:23:39] <seb_kuzminsky> ok, moving pet_watchdog functionality into .write seems like a win, as long as no one uses hm2_read without hm2_write
[18:24:36] <PCW> seems fairly unlikely (DRO only app?)
[18:27:27] <seb_kuzminsky> one can imagine some hal circuitry like: .has_bit -> not -> charge_pump -> watchdog -> emc-enable-in
[18:27:51] <seb_kuzminsky> err, or .has_bit -> not -> enable-in
[18:28:12] <seb_kuzminsky> (with an OR on the enable-in, so other things can estop the machine too)
[18:28:54] <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
[18:29:09] <PCW> The hardware watchdog is mainly for really bad cases (host crashed)
[18:29:25] <seb_kuzminsky> yeah, or the parallel cable fell off
[18:38:16] <jepler> let me toss another item on the pile:
[18:38:22] <jepler> the very first watchdog write should clear the bite
[18:38:47] <jepler> that fixes interactively loading hm2_whatever and the human-scale time that elapses from there to "addf" and "start"
[18:40:04] <jepler> tmax up to 1ms
[18:40:57] <jepler> going back to my hacked spidev.ko which eliminated runtime memory allocations to see if that fares better
[18:41:16] <PCW> isn't the wd currently disabled until the timeout is set?
[18:41:50] <jepler> PCW: I have seen behavior I interpreted differently
[18:42:04] <jepler> let me do that thing now and say accurately what I see
[18:44:02] <jepler> well, "doctor doctor", here's what happens currently when I add other threads before pet-watchdog:
http://paste.debian.net/117760/
[18:45:09] <PCW> hmm maybe its just set for a "long" time at startup
[18:45:11] <jepler> apparently it's OK interactively as long as you remember to add pet_watchdog first
[18:46:11] <seb_kuzminsky> the watchdog should be disabled until the first pet, currently
[18:46:38] <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
[18:47:01] <jepler> seb_kuzminsky: if that's the case, why the result in my pastebin?
[18:47:26] <seb_kuzminsky> because you didn't add the pet_watchdog
[18:47:45] <jepler> <+seb_kuzminsky> the watchdog should be disabled until the first pet, currently
[18:47:58] <seb_kuzminsky> maybe i meant "until the first write"
[18:48:00] <seb_kuzminsky> hold on
[18:48:40] <seb_kuzminsky> yeah, hm2_write does watchdog_write, which sets the timeout and starts the watchdog
[18:49:10] <seb_kuzminsky> i bet i never considered that someone would have write without pet
[18:49:50] <jepler> this addf order at interactive speeds is OK:
[18:49:50] <jepler> halcmd: addf hm2_5i20.0.read thread1
[18:49:50] <jepler> halcmd: addf hm2_5i20.0.pet_watchdog thread1
[18:49:50] <jepler> halcmd: addf hm2_5i20.0.write thread1
[18:50:04] <jepler> so yes, it's the case where pet is added after write
[18:50:44] <jepler> so your idea to put pet watchdog in write makes even more sense
[18:50:49] <jepler> it doesn't matter to anyone who only reads
[18:51:01] <seb_kuzminsky> hm2_write() sets watchdog.enable to True, in a case of bogus data-hiding-violation
[18:51:02] <jepler> a biting watchdog has no effect on reads afaik
[18:51:12] <seb_kuzminsky> jepler: i think that's right
[18:51:19] <seb_kuzminsky> ok then
[18:51:25] <jepler> so yeah, roll pet_watchdog into write
[18:51:29] <PCW> nope not in the firmware
[18:51:41] <seb_kuzminsky> so say we all
[18:52:02] <PCW> all wd bite does is clear the DDR/OD registers
[18:52:09] <seb_kuzminsky> i'd planned to build a new hm2-based controller for the robot arm at the hackspace tonight, i
[18:52:19] <seb_kuzminsky> i'll try to fit this hm2 watchdog change in
[18:52:20] <PCW> (and set the bitten flag)
[18:53:14] <PCW> big plus for Ethernet (one whole packet/syscall saved)
[18:53:33] <seb_kuzminsky> lol, the pet_wathdog function *also* sets enable to True.
[18:53:40] <seb_kuzminsky> what kind of jerk wrote this garbage
[18:53:50] <jepler> just for grins I should try 7i80 on the odroid, even though I know its ethernet is on usb
[18:54:44] <PCW> i ran a 7I80 on a USB ethernet dongle for a couple hours (till a 10 ms delay)
[18:55:34] <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/
[18:56:34] <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
[18:57:13] <jepler> but in hm2_pci all you'd have to do is case (pci id of 5i20): look up "MESA5I20" in table
