Back
[04:44:33] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/hm2-watchdog 0be74b3 06linuxcnc 10(20 files in 2 dirs) hm2 sample config: set HOME_SEQUENCE * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0be74b3
[04:44:33] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/hm2-watchdog e475e70 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c hm2: don't enable the watchdog in hm2_read() and hm2_read_gpio() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e475e70
[04:44:33] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/hm2-watchdog e11f529 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c hm2: write the watchdog in hm2_write_gpio() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e11f529
[04:44:35] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/hm2-watchdog 3783e06 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h 10src/hal/drivers/mesa-hostmot2/watchdog.c hm2: simplify how "watchdog period is short" warning is printed * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3783e06
[04:44:41] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/hm2-watchdog 7f06e0a 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/watchdog.c hm2: simplify auto-enabling of the watchdog * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7f06e0a
[04:44:44] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/hm2-watchdog 2549bf5 06linuxcnc 10src/hal/drivers/mesa-hostmot2/watchdog.c hm2: reflow the hm2_write() function (no behavioral change) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2549bf5
[04:44:49] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/hm2-watchdog e28e8fa 06linuxcnc 10src/hal/drivers/mesa-hostmot2/watchdog.c hm2: move watchdog petting from pet_watchdog() to watchdog_write() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e28e8fa
[04:44:53] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/hm2-watchdog dc15ef3 06linuxcnc 10docs/man/man9/hostmot2.9 10src/hal/drivers/mesa-hostmot2/hostmot2.c hm2: remove pet_watchdog from the docs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dc15ef3
[04:44:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/hm2-watchdog 9d674f9 06linuxcnc 10configs/by_interface/mesa/hm2-servo/hm2-servo.hal 10configs/by_interface/mesa/hm2-stepper/hm2-stepper.hal 10configs/by_interface/mesa/plasma-5i20/plasma-5i20.hal hm2 sample configs: stop calling pet_watchdog * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9d674f9
[04:45:38] <linuxcnc-build> build #2370 of 0000.checkin is complete: Failure [4failed fetch branch to local git repo] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2370 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[05:27:01] <seb_kuzminsky> glo is down from here
[05:42:48] <skunkworks_> with cradek and jepler just disappearing - they must be having connection problems
[07:31:23] <jepler> still bad thread times with spi kernel driver affinity fixing and removal of kernelspace memory allocation
[07:31:45] <jepler> back to pessimism and expecting to eventually have to write a full spi driver
[07:34:46] <skunkworks> darn
[08:55:08] <seb_kuzminsky> linuxcnc-build: force build --branch=seb/master/hm2-watchdog 0000.checkin
[08:55:09] <linuxcnc-build> build forced [ETA 1h13m33s]
[08:55:09] <linuxcnc-build> I'll give a shout when the build finishes
[09:22:35] <jepler> so probably I should make an unholy mashup of spidev.c and spi_s3c64xx.c that presents the same userspace API as spidev but gets rid of all runtime resource/memory allocation and anything async
[09:28:38] <jepler> now I know what cradek meant when he said he "did what the e-mail said" to merge a github pull request
[09:28:47] <jepler> he means the instructions in the individual e-mail that github sends for a pull request
[09:28:50] <jepler> that's nice
[09:51:58] <linuxcnc-build> Hey! build 0000.checkin #2371 is complete: Success [3build successful]
[09:51:58] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2371
[09:54:32] <skunkworks_> jepler, where you able to rw registers?
[09:54:46] <skunkworks_> on the spi?
[09:55:12] <jepler> skunkworks_: no, I'm still scratching my head
[10:04:30] <brianmorel99> http://www.linux.com/news/enterprise/high-performance/147-high-performance/785558-99-parallella-supercomputer-has-successful-launch-after-18-months
[10:05:15] <brianmorel99> No idea if it might be usefully as the FPGA stuff is over my head, but it looks interesting.
[10:24:17] <mozmck> that parallella does look interesting - does anyone here have one?
[10:27:46] <brianmorel99> I don't I'm still playing with the Jetson TK1. Article says the basic unit is stock for general availability.
[10:28:08] <mozmck> Yes, they show to be in stock on amazon.
[10:42:18] <CaptHindsight> mozmck: I was waiting for them to be available again. ZYNQ + multicore DSP but no GPU
[10:44:49] <brianmorel99> Sounds like they should have the "Embedded" version available soon. That has the Zynq Z7020 with it's larger FPGA, but it still "sounds" smaller than what MESA uses although I really have no idea what that means.
[10:45:04] <CaptHindsight> I'll be pleasantly surprised if they become popular since the DSP requires everyone's software to be rewritten to make use of the DSP
[10:45:51] <CaptHindsight> the same way the GPU clusters were considered failures at Los Alamos and Sandia Labs
[10:46:51] <brianmorel99> I was just thinking about the combination ARM / FPGA on the Zync SOC, but I guess the DSP might be usefull also.
[10:47:28] <CaptHindsight> the ZYNQ prices never really came down
[10:48:14] <CaptHindsight> I have some ZED boards with the ZYNQ
[10:52:41] <CaptHindsight> https://www.osadl.org/Latency-plot-of-system-in-rack-b-slot.qa-latencyplot-rbs8.0.html ZYNQ with preempt_rt 3.12.24-rt38 latency histogram
[11:00:28] <mozmck> How do you find what chip that is?
[11:00:54] <mozmck> I'm also not sure how to read the histogram
[11:04:45] <kwallace2> If I had a few buckets of free time, I'd be looking at this
https://www.olimex.com/Products/DSP/Development/ http://www.ti.com/lit/an/spra327/spra327.pdf , but what I know about DSPs could fit on the head of a pin.
[11:06:07] <brianmorel99> I think 100us max would mean it's too high for soft-stepping, but if you could utilize the FPGA for a stepper it might work. Also, I'm pretty sure the Xenomai folks have a patch for the Zynq.
[11:06:13] <skunkworks_> mozmck, it looks like its maximum latenyc is around 80us... (at 1e+7 samples)
[11:07:39] <skunkworks_> brianmorel99, seems to be the trend.
[11:08:29] <pcw_home> even 300 or so usec latency is ok for hardware stepgens
[11:09:31] <mozmck> logger[psha]:
[11:09:31] <logger[psha]> mozmck: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2014-08-27.html
[11:11:10] <pcw_home> and even more could be accommodated by using a DPLL on the FPGA for sampling
[11:11:11] <pcw_home> or using the real sample time for doing PID error calculations
[11:14:20] <brianmorel99> pwc_home: How long before you throw an ARM SOC on a 5i25 for a single source solution for us :)
[11:15:43] <pcw_home> Problem with Arms SOCs is that they go out of style in about 2 years
[11:19:42] <seb_kuzminsky> http://opencores.org/project,core_arm
[11:21:42] <pcw_home> yeah...
[11:21:57] <seb_kuzminsky> ;-)
[11:22:12] * seb_kuzminsky <-- knows nothing about what he's suggesting
[11:23:15] <pcw_home> I wonder how long before they would be sued by ARM inc if their core worked...
[11:27:46] <pcw_home> looks like as soon as you have a MMU you are in lawsuit land...
[11:29:12] * skunkworks_ is waiting for his refurbished asus nexus 7...
[11:29:30] <skunkworks_> out for delivery...
[11:31:39] <jepler> brianmorel99: I have a parallela board. in terms of speed building linuxcnc, it's in the same realm of 'intolerably slow' as the bbb, over 50 minutes. that slow and I assume it's not going to *run* linuxcnc well either. (I didn't get as far as putting an RT kernel on it)
[11:37:14] <brianmorel99> jepler, that sucks. I have the Jetson TK1 and it's very quick, but I have to flash it to get U-Boot on it so I can try isolcpu to see if it improves the latency I'm seeing
[11:48:20] <jepler> zync z-7010 is "28k logic cells" (in "7-series", 1 cell = 4 luts & 8 flip-flops). by comparison, a recent mesa card is on xc6slx9 which has 9,152 logic cells (also for LUTs and 8 FFs in spartan6)
[11:48:25] <jepler> so it's plenty big for hostmot2
[11:48:56] <pcw_home> Yeah the Zynqs have very large FPGAs
[11:49:29] <pcw_home> I think its like a Artix part
[11:49:59] <kwallace2> Does anyone know the manufacturer of this?
http://www.ebay.com/itm/271455379375 I suspect Lapsun is a distributor. I'm looking for more details on what's inside.
[11:50:53] <jepler> kwallace2: that's an interesting looking device!
[11:51:53] <jepler> I didn't know a c-mount camera could be had for so relatively little money, I guess I never looked.
[11:52:42] <kwallace2> Yeah, kind of like a Hero without the water proof case and c-mount.
[11:55:52] <jepler> same item, same price on aliexpress
http://www.aliexpress.com/store/product/5MP-TV-HDMI-USB-Industry-Digital-C-mount-Microscope-Camera-TF-Video-Recoder-DVR-lens-for/205483_1836066761.html
[11:59:32] <kwallace2> I'm tempted to buy one so I can take it apart.
[12:03:45] <brianmorel99> jepler, what kind of latency are you seeing on the arm board you are working with?
[12:04:17] <jepler> brianmorel99: just running the linuxcnc latency-histogram I see +-40us over hours.
http://emergent.unpythonic.net/01407410572
[12:05:18] <jepler> brianmorel99: but using unmodified /dev/spidev1.0 (goal: talk to mesa 7i90) I see >5ms thread times almost immediately
[12:05:26] <brianmorel99> jepler: That's just Preempt-RT right? Did you have to isolate the cores and/or move irq's around?
[12:05:28] <jepler> and even with all the tweaks I've found, I get >500us thread times overnight
[12:06:03] <jepler> brianmorel99: yes, one of the things that improved spidev access was to isolate the kernel processes that correspond to the spi device onto the same CPU that linuxcnc uses for rtapi_app
[12:06:37] <jepler> somewhere I have a graph with isolcpus=3; I think it was a bit better than that graph you see which was without isolcpus
[12:07:14] <kwallace2> I'm wondering if I could use this:
http://www.edmundoptics.com/technical-resources-center/imaging/what-is-telecentricity and some SurplusShed lenses to make a telecentric lens?
[12:07:59] <brianmorel99> The Jetson was 100k+ us at first, but when I moved all the IRQ's to the first core it's down in the 40-50k range, but there are still a lot of schedular IRQ's on the last two cores.
[12:08:26] <brianmorel99> It ships with fastboot bootloader, so i can't try isolcpu until I flash it with U-Boot
[12:08:43] <jepler> brianmorel99: in my case, the very good latency overnight says that IRQs running on the linuxcnc rtapi_app core are not my problem
[12:08:59] <jepler> it's something specific to the spi driver stack
[12:09:53] <brianmorel99> That's what I've read. I assume the ethernet controller is on the USB bus so that's why you are trying SPI ?
[12:11:08] <jepler> yes
[12:11:09] <brianmorel99> FYI the uspace / master branch built perfectly on the Jetson
[12:11:18] <jepler> that's cool news!
[12:12:26] <brianmorel99> If I can get the latency in a reasonable area I want to try the ethernet (it's on the pcie bus) and / or use an adapter in the mini-pcie slot to a 6i25
[12:13:56] <jepler> either one would be cool
[12:21:28] <kwallace2> seb_kuzminsky, thanks for the glass machining link:
http://benkrasnow.blogspot.com/2011/08/cnc-milling-glass-plates-and-mirrors.html . I got some microscope slides and diamond burrs on order.
[12:27:33] <seb_kuzminsky> kwallace2: glad it was helpful! ben krasnow's got some crazy projects
[12:45:44] <seb_kuzminsky> whoops, the "splash gcode" for axis in lathe mode still says EMC2
[12:50:41] <seb_kuzminsky> i noticed this while trying to repro Janos Bujtar's bug report against the lathe-fanucy sample config (which works for me in rip)
[13:22:32] <jepler> seb_kuzminsky: isn't the "copy config" functionality only going to be invoked if it's a package version?
[13:22:39] <jepler> or maybe if the configs/ tree is not writable
[13:24:06] <jepler> confirmed with 2.6.0-pre5 running live from binary.hybrid.iso
[13:26:33] <jepler> this was discussed almost exactly a month ago here
[13:27:33] <jepler> http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-07-27.html#20:51:43
[13:28:13] <jepler> [21:12:32] <jepler> I think the use of "../" paths is not handled by the config picker's copy logic
[13:28:19] <jepler> [22:29:21] <jepler> or move the file that needs duplication into common and arrange for it to be copied
[13:28:26] <jepler> I think this is the cause and I think this is the best solution
[13:29:13] <jepler> lathe-fanucy is the only config with HALFILE = ../...
[14:07:00] <kwallace1> In case someone has five minutes to waste. (lathe board test - the movie)
http://www.wallacecompany.com/tmp/lbt_the_movie.ogv
[14:32:39] <skunkworks_> kwallace1, what does the auto/manual do?
[14:33:23] <skunkworks_> is there some sort of test 'script' that wiggles the bits?
[14:38:53] <kwallace2> Auto toggles each command button in sequence automatically. Each test checks the response bits and counts how many servo cycles the response(s) is high. Each test will have a high count range that is considered okay. The manual mode is available to to play with parts of the board individually.
[14:48:11] <kwallace2> The count values are shown by the show pins at the end. I haven't done the value check software yet. So far, it looks like I'll just have a Pass/Fail indicator added to the UI screen.
[15:24:00] <jepler> oh hey, apparently someone is working on upstreaming devicetree support for the odroid u3.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412-odroidu3.dts?id=refs/tags/v3.17-rc1 unfortunately, it reportedly has an unspecified issue.
http://forum.odroid.com/viewtopic.php?f=83&t=3174#p49979
[15:25:22] <seb_kuzminsky> that's nice to hear
[15:25:36] <jepler> I think 3.17 blows past where there are preempt-rt patches though
[15:25:51] <seb_kuzminsky> 3.17 isnt even out yet, is it?
[15:26:33] <jepler> no
[15:26:43] <seb_kuzminsky> 3.14 seems to be the newest rt-preempt patch
[15:27:03] <jepler> from git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git I have v3.12-rt as the newest
[15:27:27] <seb_kuzminsky> pfft, git? try tarballs:
https://www.kernel.org/pub/linux/kernel/projects/rt/
[15:27:45] <jepler> *frustrated dog whine*
[15:37:43] <jepler> - tx_dev = &master->dma_tx->dev->device;
[15:37:45] <jepler> + tx_dev = master->dma_tx->device->dev;
[15:38:55] <skunkworks_> as easy as that?
[15:39:30] <jepler> just looking at others' changes in spi-related files in linux
[15:39:41] <jepler> I have no clue what that does, except make me wish the variable names were more enlightening
[15:40:24] <jepler> ugh, they increased the tolerance for a late spi response from (calculated time + 10ms ) to (2*(calculated time) + 100ms)
[15:41:34] <seb_kuzminsky> lol
[15:41:44] <seb_kuzminsky> oops, that was inconsiderate of me
[15:42:02] <jepler> I'm never hitting a 10ms latency so I don't think it's anything that affects me
[15:47:22] <jepler> I don't see anything in the logs ..v3.17-rc2 or ..v3.12-rt that seems relevant to realtime performance of spi
[16:07:26] <MrHindsight> looks like RTAI works without the isolcpus=x needing to be set, we were seeing real time changing cores after restarting
[16:09:36] <MrHindsight> is it worth building debs for testing 3.14 RTAI yet?
[16:12:32] <MrHindsight> is there a howto for building kernel and RTAI debs?
[16:14:12] <seb_kuzminsky> i've got a bit of a rickety build system that i used for the wheezy & precise rtai kernels
[16:14:27] <seb_kuzminsky> i'll publish it on github so you can take it for a spin
[16:16:02] <MrHindsight> thanks, I'd like to try it
[16:16:48] <seb_kuzminsky> you wont say that after you see it - it's really terrible
[16:17:20] <MrHindsight> so it's possibly worse than nothing?
[16:17:54] <seb_kuzminsky> heh
[16:18:20] <seb_kuzminsky> well... it makes kernels that fit into the debian package ecosystem, i guess that's not nothing
[16:18:36] <seb_kuzminsky> but it's not simple, and it's not straightforward
[17:04:35] <PCW> micges: did you see seb got rid of the separate feed wd function?
[17:05:08] <micges> no
[17:05:46] <PCW> he bundled it with hm2_write
[17:06:38] <micges> ah I see it
[17:12:00] <micges> yeah great stuff
[17:13:10] <seb_kuzminsky> it's in a branch called seb/master/hm2-watchdog, it's not in master yet
[17:13:56] <seb_kuzminsky> micges: any feedback you have on it is welcome
[17:21:08] <micges> seb_kuzminsky: so now first write enables wd right?
[17:21:22] <micges> also write_gpio I see
[17:21:44] <seb_kuzminsky> yes, those are both right
[17:22:03] <seb_kuzminsky> in master (before this branch), write, write_gpio, and pet_watchdog would all enable the watchdog
[17:22:30] <seb_kuzminsky> err, maybe write_gpio didnt, but that was a bug
[17:22:50] <seb_kuzminsky> now (after this branch), pet_watchdog is gone (write does the petting now), and write and write_gpio both enable the watchdog
[17:24:07] <micges> I see it
[17:24:30] <micges> and you tested that 'too short wd time' is showing only once?
[17:24:35] <seb_kuzminsky> yep
[17:26:52] <jepler> http://emergent.unpythonic.net/files/sandbox/tmax-increased-trigger.png
[17:27:08] <jepler> this (.tmax-increased) was easy to add, and it seems like it might be handy
[17:27:48] <seb_kuzminsky> jepler: yeah, a handy debugging signal
[17:38:19] <skunkworks_> jepler: I was needing that recently...
[17:38:22] <skunkworks_> awesome
[17:39:00] <micges> seb_kuzminsky: maybe petting wd should be done by tram write?
[17:39:39] <seb_kuzminsky> i bet you're right
[17:40:12] <micges> then it will remove additional packet from hm2_eth and further packeted transport layers
[17:40:24] <seb_kuzminsky> the hm2-eth stuff doesn't use tram, does it? you've got your own batching system independent of tram?
[17:40:36] <PCW> maybe hm2_spi as well
[17:40:58] <seb_kuzminsky> i thought they both batched in a different way. am i mistaken?
[17:41:08] <seb_kuzminsky> i havent actually studied the new code...
[17:42:52] <micges> seb_kuzminsky: it's simply pack prepared eth packet in one
[17:44:56] <seb_kuzminsky> does it take the stuff that's been queued up in tram, or does it also capture things that get written directly via llio->write?
[17:45:37] <jepler> seb_kuzminsky: there are two new function pointers
[17:45:37] <micges> stuff from tram
[17:46:06] <jepler> seb_kuzminsky: the new function pointers (queue_read / queue_write) are allowed to gather up requests
[17:46:16] <jepler> until a request with length -1 is made, then they complete all the queued requests
[17:46:25] <jepler> hm2_eth has one read request queue and one write request queue
[17:46:35] <jepler> while I wrote hm2_spi with a single queue
[17:48:15] <jepler> for drivers which don't have the new calls (everything but hm2_eth and hm2_spi), a queue_read / queue_write is simply done immediately by turning around and calling the old read/write methods
[17:49:54] <seb_kuzminsky> so by havint hm2_watchdog_write() explicitly call hm2->llio->write() i goofed up and didn't actually save a packet after all?
[17:50:08] <jepler> you could call ->queue_write
[17:50:12] <jepler> .. I think
[17:50:31] <seb_kuzminsky> or use micges suggestion and put the watchdog reset in tram
[17:52:03] <jepler> yes, when the tram fairy comes along and actually implements tram in hostmot2.ko it'll be a big help
[17:52:46] <micges> I think queue_write will work but eventually it should go to tram
[17:52:55] <seb_kuzminsky> ok, i'll change it
[17:53:14] <PCW> Yeah the wd packet is still there
[17:53:38] <jepler> for eth and spi I'm not sure how important actually using tram is
[17:54:11] <jepler> the setup and turnaround time seem to dwarf the dozen or two bytes of packet size
[17:54:13] <seb_kuzminsky> it shrinks the payload quite a bit, no? not having to have all those addresses on the wire all the time
[17:54:16] <seb_kuzminsky> ah
[17:54:50] <PCW> mainly TRAM was done for DMA capability in the future
[17:55:16] <jepler> http://emergent.unpythonic.net/files/sandbox/tmax-surge.png
[17:55:24] <seb_kuzminsky> but for eth and spi, tram might be helpful to reduce packet count frmo non-queued writes
[17:55:30] <jepler> so when spi sucks, it sucks for a good quarter second
[17:55:34] <PCW> (and 7I43 configs actually have a unused hardware TRAM)
[17:55:54] <seb_kuzminsky> tram also would help on epp, where there is little overhead but each transaction takes ~1us
[17:56:00] <jepler> seb_kuzminsky: yes, that's true
[17:56:58] <seb_kuzminsky> wonder what your odroid is doing during that time
[17:57:14] <jepler> that seems harder to determine
[17:58:09] <seb_kuzminsky> just add some hal pins to the linux kernel and watch it in halscope
[17:58:14] <jepler> eeeeeeee
[17:58:34] <jepler> it's something that preempts(?) spidev's activities, because scope's tmax remains low
[17:59:31] <seb_kuzminsky> some other task is hogging the cpu, preventing the bottom half of the spi driver from getting scheduled when it wants
[17:59:35] <seb_kuzminsky> maybe
[17:59:46] <jepler> seb_kuzminsky: yeah I too think that's roughly the story
[17:59:57] <seb_kuzminsky> can you give the spi driver thread a higher rt-preempt priority somehow?
[18:00:13] <jepler> anyway, for "small" spikes, scope.sample.time and spidev.time actually are somewhat correlated
[18:00:22] <jepler> now to wait for another bigger spike in tmax
[18:00:43] <MrHindsight> open a browser :)
[18:01:07] <seb_kuzminsky> sched_setscheduler(SCHED_FUCKYOU)
[18:01:32] <jepler> seb_kuzminsky: that's one thing I've varied in this most recent test
[18:01:46] <seb_kuzminsky> the priority of the kernel thread?
[18:01:48] <seb_kuzminsky> cool
[18:01:51] <jepler> seb_kuzminsky: I found that putting the spi kernel tasks on the same cpu as rtapi_app helped; this time I also raised their priority with chrt
[18:02:16] <jepler> but it's hitting latencies of >120k still, and when it does that in minutes it tends to hit 800k after hours
[18:02:21] <jepler> so I feel like it's probably not the fix
[18:02:28] <seb_kuzminsky> hm, bummer
[18:02:38] <jepler> I'll let it run though
[18:04:38] <andypugh> I think I use a fixed tram write to poke some hostmot2 modules.
[18:05:49] <MrHindsight> andypugh: what was the combo on your ARM board imx6 + *duino (AVR)?
[18:05:50] <andypugh> TRAM is sort of a comfortable straightjacket, even though it isn’t used, having to code so that it could be if we wanted to imposes limits, but also makes some things simpler
[18:06:22] <andypugh> That was a Udoo. Not got it working yet (no need to) but it looks like a useful board still,
[18:06:41] <andypugh> #udoo exists
[18:07:27] <MrHindsight> memleak is back on the cubie2 since the RTAI for AMD is looking good
[18:07:54] <MrHindsight> lots of magic on that board
[18:08:40] <MrHindsight> imx6 has PCIe, I might look at that again
[18:23:23] <CaptHindsight> ethernet on the cubie2 is integrated into the ARM SOC, hm2_eth might just work :/
[18:24:03] <seb_kuzminsky> sweet
[19:05:43] <jepler> http://emergent.unpythonic.net/files/sandbox/tmax-surge2.png
[19:06:22] <jepler> so maybe something proportionally bad is going on in both functions
[19:06:45] <jepler> but the hugest spike is still reserved for spidev
[19:07:09] <jepler> (note different vertical scales of spidev.time and scope.sample.time)
[19:15:01] <jepler> nonvoluntary_ctxt_switches ~= 3 * voluntary_ctxt_switches when using spidev
[19:15:16] <jepler> not when not using it
[21:04:19] <jepler> who cares if whatever I decide to do is not upstreamable :-P
[21:12:46] <jepler> I think I managed to hack synchronous transfers back into the kernel SPI driver
[21:23:47] <memleak> is there an i2c parport driver for linuxcnc?
[21:24:34] <memleak> i dont remember but i think i saw something like that in there.
[21:30:35] <jepler> doesn't particularly ring a bell
[21:40:01] <jepler> there is something called drivers/i2c/busses/i2c-parport.c
[21:40:08] <jepler> * i2c-parport.c I2C bus over parallel port
[21:40:45] <jepler> https://www.kernel.org/doc/Documentation/i2c/busses/i2c-parport
[21:40:50] <jepler> it even has a documentation file
[21:47:17] <memleak> thats what i was talking about
[21:47:27] <memleak> for some reason i thought linuxcnc can communicate with that driver
[21:49:04] <jepler> some people have written i2c bitbanging as a linuxcnc realtime component too
https://github.com/cdsteinkuehler/LinuxCNC-RepRap/blob/master/components/I2C.comp
[21:49:58] <jepler> probably works with something like that first schematic
[21:52:18] <jepler> not fast, something like 1/3 i2c bit per hal period
[21:57:12] <memleak> oh cool!
[22:05:09] <Tom_itx> i used i2c on parport for some temp sensors
[22:05:15] <Tom_itx> lmsensors
