Back
[06:39:34] <skunkworks> interesting read... from simpson36 on..
http://www.machsupport.com/forum/index.php/topic,27120.msg204601.html#msg204601
[06:40:25] <skunkworks> They sure would like mesa hardware... (I wish for peter - that they would get something working...)
[06:46:23] <skunkworks> 'Now, somehow someone decided to slap the GPL license on it at a later date. How they could "re-license" something that had already been in the public domain is a point to ponder!!! Personally, I don't think it was legal. I have the original sources from NIST and it is clearly stated in the code that anyone can use it and that it is public domain. This has been stripped and replaced with the GPL in the "new" zip
[06:46:23] <skunkworks> file of the code. The NIST code, not the LinuxCNC code.'
[06:53:47] <archivist> could a some effort with a diff program fix that so parts are public domain and parts gpl
[06:54:09] <archivist> but mach did that trick too :)
[06:54:17] <skunkworks> heh
[08:27:14] <alex_joni> skunkworks: someone didn't decide to slap the GPL license on _it_
[08:27:37] <skunkworks> alex_joni, I am sure.. (I remember some of it.) :)
[08:27:48] <alex_joni> the GPL license is on derived work, the original zip from NIST is still PD (public domain), and anyone can take it and do with it as they please
[08:32:02] <archivist> well adding gpl to any of the pd source may be dodgy legally
[08:34:54] <archivist> mixed is ok probably then
http://www.gnu.org/licenses/gpl-faq.html#CombinePublicDomainWithGPL applies
[08:36:14] <cradek> yes you can get the pd code back by reversing out all changes including the license change - you could probably even do this with git - and you'll end up with pure PD code - but as alex says that code is already available in the emc1.0 tars
[08:38:24] <cradek> you can absolutely incorporate PD code into a system with a more restrictive license (much more restrictive, like mach, or only a bit more restrictive, like linuxcnc)
[08:38:37] <archivist> our statements should just state all code from x is gpl which is mixed with what pd is left rather than a blanket gpl
[08:38:38] <cradek> I don't understand why that's controversial
[08:39:19] <cradek> you can only convey/distribute under the more restrictive license, which in our case is gplv2
[08:39:39] <archivist> it is mixed not pure
[08:39:49] <cradek> it is "combined"
[08:46:51] <cradek> did this come up for some important reason or is someone just trolling us? if trolling, the answer is don't feed them
[08:50:25] <mozmck> I think it came up because skunkworks mentioned this post:
http://www.machsupport.com/forum/index.php/topic,27120.msg204641.html#msg204641
[08:51:16] <cradek> > the heart of Mach 3 was the parallel port code
[08:51:28] <cradek> then the (much better) heart of linuxcnc is hal
[08:53:17] <cradek> what an inconsistent argument
[08:53:23] <mozmck> heh!
[08:53:46] <cradek> > Oh and let's not forget about the user interface, which was 100% Art. And let me tell you that is the hardest part.
[08:54:02] <mozmck> Not
[08:54:03] <cradek> we've made more than a few user interfaces since the PD ones, too
[08:54:17] <cradek> > We don't use any of the NIST code anymore in Mach 4.
[08:54:25] <cradek> hard to know for sure, isn't it
[08:55:03] <cradek> the three interfaces in the PD days were keystick, xemc, and tkemc
[08:55:44] <cradek> sorry, I have no time for machsupport.com
[08:56:29] <skunkworks> I like his comment about mesa getting 'free' support from the linuxcnc devels. that is far far from the truth...
[08:56:49] <cradek> oh is this a mach developer mad about tormach ditching mach?
[08:57:07] <skunkworks> That is what started it..
[08:57:19] <cradek> eh
[08:57:28] <cradek> I'm off to find coffee and not worry about that
[08:57:59] <skunkworks> (the running issue with mach4 is that people are feeling that you have to be a programmer to use/modify it. And the developers are slow to add things..) sound familliar? ;)
[09:08:58] <archivist> I think unrealistic expectations from many :)
[09:43:05] <cradek> I'm not a plasterer but I sure have a lot of walls I want fixed - also the ceilings. I don't understand why nobody has fixed the ceilings. You have to be a plasterer to fix the ceilings and I'm not a plasterer and so you should do it and also I'm mad about it.
[09:44:13] <cradek> (although it's silly in our world, it's not silly to complain when a vendor selling you closed software is unresponsive)
[09:44:14] <mozmck> me too!
[09:44:20] <archivist> you need a carpenter
http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa6506e2f35eaac
[09:52:53] <cradek> > Sourceforge downloads come with non-optional nagware
[09:52:56] <cradek> orly!?
[09:55:14] <cradek> I don't see any crazyness in the win32diskimager zip
[09:55:57] <cradek> talking about
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?action=browse&diff=1&id=Hybrid_Iso
[09:58:18] <skunkworks> wow
[09:58:50] <archivist> hmm I wonder if that person writing that has an infection on his machine
[09:58:59] <skunkworks> maybe
[09:59:02] <archivist> from somewhere else
[09:59:19] <skunkworks> or - they downloaded it from a page that has lots of other bad downloads...
[09:59:24] <cradek> I'd hesitate to guess unless I tried it on windows myself, which I can't
[09:59:55] <cradek> I wouldn't be all that surprised to find sourceforge is stupid in a new way
[09:59:58] <archivist> I have seen some clever "helper" crap when cleaning peoples machines
[10:00:24] <archivist> often entered via IE
[10:04:29] <archivist> I spotted one on a users machine by viewing my own site, they were adding links into the page text for their advertising search terms
[10:06:37] <cradek> that's horrible
[10:07:19] <archivist> I thought I had been hacked for a few seconds till I found the users IE helper app
[10:07:45] <cradek> "helper"
[10:08:36] <archivist> spamware virus would be a better name
[10:24:04] <pcw_home> I dont see any funny behaviour with win32diskimager
[10:24:52] <archivist> I think its a user PC problem having seen bad stuff on users PCs
[10:27:38] <pcw_home> or included with PC: superfish
[10:28:21] <archivist> yes saw that mentioned on the BBC website the other day
[11:44:38] <jthornton> hmmm, axis-remote tacks on the config location to the path passed :(
[11:46:13] <jthornton> I think I can work around that...
[12:04:27] <seb_kuzminsky> any reason not to accept a patch like Jason Penn's (to increase tool table size)
[12:16:39] <cradek> old (2.4 or earlier?) configs have the .nml file copied into the config directory. a change like this will break those configs. the solution is to remove the .nml files. anyone reasonably up to date has already done this.
[12:17:32] <cradek> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?UPDATING#emc_nml_changes
[12:27:25] <cradek> it would be interesting to figure out whether there's currently some maximum reasonable size, and set it to that instead of making another small increase
[12:34:52] <seb_kuzminsky> is it true that the tool table is shared by IO and Task, and not accessed by Motion?
[12:40:05] <seb_kuzminsky> the tool table lives in the emcioStatus struct, which is shared between IO and Task
[12:42:23] <seb_kuzminsky> looks like that's it
[12:45:46] <skunkworks> make sense?
http://linuxcnc.org/index.php/english/forum/16-stepconf-wizard/28891-stepgeneration-266-vs-280#56248
[12:46:08] <skunkworks> bbl
[12:49:57] <seb_kuzminsky> skunkwork's scope:
http://tinyurl.com/l59qze9
[12:59:06] <pcw_home> Thats just mean
[13:01:12] <seb_kuzminsky> just poking fun
[13:46:19] <skunkworks> zlog
[14:10:17] <seb_kuzminsky> skunkworks: i'm glad we didnt break step generation....
[14:15:32] <cradek> or fpr
[14:16:39] <seb_kuzminsky> fpr will be testable with standalone-motion :-)
[14:20:51] <skunkworks> well he says if he creates a config with stepconf in 2.6 he gets the short step pusle.. (must be using -reset and doublestep) but in master it doesn't
[14:21:43] <seb_kuzminsky> but his config made with the 2.6 stepconf produces the correct short step pulses when run on 2.7/master, right?
[14:21:48] <seb_kuzminsky> so it's just a stepconf bug?
[14:22:38] <skunkworks> he says the config doesn't run..
[14:22:41] <cradek> it's not clear what the bug is from his report, if there is a bug
[14:23:10] <skunkworks> I have not gotten far enough to ask why his config doesn't run in master.. (generated in 2.6)
[14:23:24] <skunkworks> right..
[14:23:42] <cradek> his expectation about the length of the step pulse may be wrong; steps happen at the rising or falling edge (depending on your driver)
[14:23:50] <skunkworks> the better question probably is why does he think he needs that short of a pulse if step config is making the base thread that big...
[14:23:57] <seb_kuzminsky> maytbe the 2.6 config tries to load probe_parport, which we removed
[14:24:10] <cradek> skunkworks: you're right
[14:27:36] <skunkworks> looks like stepconfg has stopped adding the setp parport.0.pin-XX-out-reset 1 lines
[14:28:53] <seb_kuzminsky> oops!
[14:29:16] <seb_kuzminsky> cmorley was experimenting with sim configs from stepconf lately, maybe something got dropped
[14:30:27] <skunkworks> well i guess if stepconf is calculating thing assuming doublestep - I guess it probably is creating a bogus config
[14:30:41] <skunkworks> -thing
[14:30:57] <seb_kuzminsky> i dont see where the doublestep (reset) got dropped in 2.7
[14:31:46] <skunkworks> (I have not tried it here. - he just posted his 2 configs supposidly created by stepconf.. 2.8 is missing the pin reset lines)
[14:32:23] <cradek> I can't immediately spot what decides whether to enable doublestep
[14:32:28] <skunkworks> it has the setp parport.0.reset-time 1000 and addf parport.0.reset base-thread
[14:32:44] <skunkworks> just not the pin reset lines
[14:33:59] <seb_kuzminsky> it doublesteps if steptime < 5000, looks like
[14:38:27] <seb_kuzminsky> i think the bug is in build_HAL.py, the function sim_hardware_halfile only adds the reset hal line (and a bunch of others) is it's building a sim config
[14:39:08] <skunkworks> he must be trying for 1000us as that is the reset line.
[14:39:34] <skunkworks> ns..
[14:40:07] <seb_kuzminsky> the pin reset ended up in sim_hardware_halfile(), but probably belongs in write_halfile() instead
[14:41:23] <skunkworks> http://linuxcnc.org/index.php/english/forum/16-stepconf-wizard/28891-stepgeneration-266-vs-280#56259
[14:42:34] <seb_kuzminsky> awesome, sam
[14:43:35] <skunkworks> it was a reason to break out the B&K
[14:43:52] <skunkworks> I would really like a small digital some day\
[14:44:52] <cradek> in connect_output I wonder if the new format stuff breaks the "if p in" stuff
[14:45:15] <cradek> d4434642
[15:07:25] <seb_kuzminsky> i dont understand what you mean
[15:35:32] <PCW> Wow ASRock H97/G3258 has rather stunningly good latency
[15:37:01] <PCW> RTAI ~3700 ns base thread, 2200 ns servo thread while running youtube videos
[15:37:25] <seb_kuzminsky> wow, that's great
[15:38:04] <PCW> ~11 usec on Preemt-RT
[15:38:32] <seb_kuzminsky> that's that's fantastic
[15:38:58] <seb_kuzminsky> i'm starting a project with a guy from the local hackerspace to start playing with rt-preempt on arm (beagle bone, u3, etc)
[15:40:01] <PCW> I know Jepler had uspace running on the Odroid not sure what all is involved
[15:41:00] <PCW> unfortunately I bought the H97 to try the built in Intel MAC with hm2-eth and it sucks
[15:41:13] <seb_kuzminsky> he's got an rt-preempt kernel for the u3 on github,
https://github.com/jepler/odroid-linux
[15:41:37] <seb_kuzminsky> what sucks about it?
[15:41:50] <CaptHindsight> anyone recall the latency with the odroid and preempt_rt?
[15:42:05] <skunkworks> so rt-preempt doesn't play well with the h97 nic?
[15:42:14] <PCW> something about the intel driver mucks up the ping times
[15:42:16] <seb_kuzminsky> CaptHindsight: i do not, but i wish i did :-/
[15:42:37] <CaptHindsight> no problem, it's in the history somewhere
[15:42:52] <PCW> where I would expect ~80 usec I get 250 usec
[15:43:34] <PCW> probably some clever driver optimization for throughput (irq aggregation maybe)
[15:43:45] <seb_kuzminsky> one of the things jepler fixed in the u3 rt-preempt kernel was making the spi driver write all the way out to hardware from the userspace process, rather than queueing the transfer and waking a spi thread
[15:43:49] <skunkworks> CaptHindsight:
http://emergent.unpythonic.net/01407410572
[15:46:12] <CaptHindsight> nice
[15:46:23] <seb_kuzminsky> skunkworks: sweet
[15:51:19] <PCW> ahh Ethenet fixed
[15:51:55] <skunkworks> what did it?
[15:52:46] <seb_kuzminsky> PCW's taken us on a wild ride this afternoon
[15:52:56] <PCW> sudo /sbin/ethtool -C rx-usecs 0
[15:53:44] <seb_kuzminsky> yikes
[15:54:00] <seb_kuzminsky> maybe we should add a note to the hm2_eth manpage? i wonder what other settings might be relevant
[15:54:35] <skunkworks> how the heck did you find that?
[15:55:26] <PCW> intel paper
[15:55:54] <seb_kuzminsky> PCW put on his wizard robe and hat
[15:56:02] <skunkworks> I wonder some times...
[15:56:24] <skunkworks> pcw, did you see the mach4 thread I had posted earlier?
[15:56:27] <PCW> desperate googling more like
[15:56:41] <skunkworks> users would really like to use your hardware...
[15:57:22] <seb_kuzminsky> tell them to come in to the linuxcnc pool, the water is fine! :-)
[15:57:50] <skunkworks> pcw, what is that line doing exactley? looks like it is turning something off.
[15:57:59] <PCW> At my advanced age I'm not sure I really want to support any more things that run on windows
[15:58:07] <skunkworks> he
[15:58:09] <skunkworks> heh
[15:59:04] <seb_kuzminsky> skunkworks: i bet it switches the net rx path to faster polling, instead of batched processing
[15:59:07] <seb_kuzminsky> just guessing
[15:59:08] <PCW> receive coalescing i think
[15:59:14] <skunkworks> it sucks that they think you get 'free' support from linuxcnc. You certainly have given till it hurts.
[15:59:29] <cradek> massage interluding
[15:59:52] <skunkworks> pcw, so then - what kind of read/write times now?
[16:00:16] <PCW> 78 usec
[16:00:38] <skunkworks> wow - read time?
[16:00:41] <micges> nice
[16:01:27] <PCW> looks better than the RTK 8111
[16:01:42] <PCW> trying linuxcnc now
[16:02:17] <micges> can you paste link to this mb?
[16:02:40] <seb_kuzminsky> heh, i tried to find it on the asrock website and got all kinds of lost
[16:02:50] <seb_kuzminsky> it's like stumbling in to a marketing brochure
[16:03:00] <micges> yep, same here
[16:03:23] <skunkworks> this?
http://www.newegg.com/Product/Product.aspx?Item=N82E16813157526
[16:04:03] <seb_kuzminsky> ooh shiny
[16:04:40] <skunkworks> wonder if you can get a motherboard+processor
[16:05:19] <seb_kuzminsky> wifi on the motherboard? that's a new one to me
[16:07:12] <PCW> the one I'm testing is a H97M pro4
[16:07:54] <seb_kuzminsky> http://www.newegg.com/Product/Product.aspx?Item=N82E16813157512&cm_re=asrock_h97m_pro4-_-13-157-512-_-Product
[16:08:35] <skunkworks> but that won't fit under my rep-rap...
[16:08:41] <skunkworks> ;)
[16:08:45] <cradek> yay actual slots
[16:09:15] <PCW> LPT/COM ports also
[16:09:55] <seb_kuzminsky> but no wifi on the motherboard
[16:10:16] <PCW> :-(
[16:10:46] <seb_kuzminsky> we'll live ;-)
[16:11:09] <cradek> get a horse^Wwire
[16:11:30] <cradek> I never did spot where those antennae plug in. are you sure it was on the motherboard?
[16:14:20] <seb_kuzminsky> hm, maybe it comes with a little half pcie wifi module
[16:14:38] <seb_kuzminsky> that's what the 4th pic on newegg's page suggests
[16:14:50] <seb_kuzminsky> ok never mind, then i'm not impressed
[16:14:55] <cradek> ha
[16:15:02] <PCW> Like the Gigabyte H81-D3, the ASRock H97M seems quite happy running hm2-eth at 4 KHz
[16:16:47] <skunkworks> seb_kuzminsky: it comes with a mini-pcie card...
[16:16:58] <wortley_> Any feel up to answering a question about protecting a critical section of code from preemption?
[16:17:24] <cradek> didn't this happen already?
[16:19:22] <cradek> 18 21:48 <cradek> your questions make me wonder whether you've chosen the right way to split your task into multiple threads, including whether it should be split at all
[16:20:06] <cradek> you can't have the slow thread tell the fast thread NOT to interrupt it, because then realtime doesn't work anymore
[16:20:23] <seb_kuzminsky> wortley_: are you assembling a buffer of bytes in a slow thread, and clocking the bytes out the serial port in a fast thread?
[16:20:23] <cradek> so you've maybe got a structural problem you have to consider differently
[16:20:37] <wortley_> I am just trying to keep my if (!bufflock) { bufflock=1 ... from getting split up.
[16:21:02] <PCW> if this is for the SPI drives, why do you want a base thread anyway?
[16:21:04] <cradek> I have no idea what that means
[16:21:11] <seb_kuzminsky> you're looking for "atomic test and set"
[16:21:20] <wortley_> Yes - slow thread fills the buffer, fast thread clocks it out.
[16:21:22] <seb_kuzminsky> PCW: he's writing his own spi-over-parport-pins driver
[16:21:45] <PCW> sill not convinced a base thread makes sense
[16:21:51] <PCW> still
[16:22:27] <seb_kuzminsky> without a base thread you only get one bit-twiddle per millisecond (or 4/ms, if you're pcw ;-)
[16:23:15] <wortley_> Atomic test and set... Thank you
[16:23:53] <PCW> umm I would twiddle as fast as I could every servo thread (why slow the SPI clock down further)
[16:24:10] <wortley_> SPI clock will be rockin' it in the base thread.
[16:24:41] <cradek> ok, maybe I'm all wet
[16:24:42] <seb_kuzminsky> PCW: aha, i see, that sounds like a good way to do it, and much faster than the "one twiddle per base thread" way
[16:24:47] <PCW> why not drop the base thread at twiddle as fast as you can
[16:24:49] <wortley_> Servo thread would be 60-80ms for my 4 byte transaction with drives.
[16:25:09] <seb_kuzminsky> hmm
[16:25:17] <seb_kuzminsky> what's your spi clock?
[16:25:37] <PCW> (bit banging should be about 100-200 KHz)
[16:25:57] <wortley_> Base clock is probably going to be around 15us or 20.
[16:26:14] <wortley_> Maybe 10
[16:26:42] <wortley_> It's slow for SPI, but no one on the bus will care.
[16:26:51] <wortley_> They can handle the 50kHz spi.
[16:27:07] <PCW> so bit banged as fast as you can go a 32 bit packet is ~160 to 320 usec which is livable at 1 KHz servo thread
[16:27:27] <wortley_> Yes.
[16:27:34] <seb_kuzminsky> are you planning to clock out one bit each base period?
[16:27:34] <wortley_> At least, that is the plan.
[16:27:47] <wortley_> It takes 2 base periods.
[16:27:50] <PCW> but no need for base thread
[16:28:18] <PCW> just added complexity/lower performance
[16:28:49] <seb_kuzminsky> PCW: would you call rtapi_sleep() or whatever it is in the servo thread to generate the spi clock freq you want?
[16:29:21] <seb_kuzminsky> rtapi_delay(()
[16:29:50] <wortley_> I do not plan to control the IO pins directly, I plan to use the nets and parallel port drive to do it, so I don't think I get to play any tricks like pounding the pins in rapid succession, right?
[16:30:43] <seb_kuzminsky> if you're controlling the parallel port pins via hal, then yes you're limited to the frequency you're running hal_parport at
[16:30:45] <wortley_> I had thought about asking the OS for rights to the port and toggling them directly in rapid succession, but I thought it would greatly decrease the flexibility of the component.
[16:31:13] <seb_kuzminsky> wortley_: that's pretty similar to what the hm2_7i43 driver does (but it uses a different protocol than spi)
[16:31:35] <wortley_> Can 1 IO address have more than one owner?
[16:32:18] <seb_kuzminsky> no
[16:33:28] <wortley_> Another thing that I have been thinking about, is that SD Card adapters talk SPI to the card. And there are some that plug right into SATA ports. I think that could be a cheap/fast way to get a lot of data into and out of the os.
[16:33:41] <PCW> pretty sure you dont need any delay (the 1-4 usec PP interface delay is probably slow enough for almost any SPI device)
[16:34:07] <seb_kuzminsky> PCW: makes sense
[16:35:05] <wortley_> PCW: I'm confused about how I could write PP pins if I don't take ownership away from the hal_parport driver.
[16:35:53] <wortley_> Could I schedule the parport driver and my spi drive to execute more than 1 time per base period?
[16:36:21] <skunkworks> you wouldn't use the parport driver...
[16:36:21] <seb_kuzminsky> wortley_: are you trying to do spi on just a few of the parport pins, and other things on the other parport pins (like step/dir signals or similar)
[16:36:46] <wortley_> seb: Yes, I'm trying to stay IO agnostic.
[16:37:33] <wortley_> seb: I plant to allow the use of the parport for other things too.
[16:38:22] <wortley_> seb: Otherwise, I could go totally nuts with the driver on the port and get up to that 100-250# that we were kicking around.
[16:39:16] <PCW> maybe a hack on hal -parport is a possibility (embed the SPI parts)
[16:39:21] <wortley_> But if I could get my function and the driver scheduled a few times per base period, that would rock.
[16:40:38] <seb_kuzminsky> wortley_: you can run your base thread as fast as your hardware supports, or add a faster thread
[16:41:16] <wortley_> PCW: I had given that some thought - but I am such a hack I didn't want to ruin a good, proven driver :)
[16:41:29] <seb_kuzminsky> heh
[16:42:42] <wortley_> I was a little scared of bumping down the base thread because it might mess up step generation. If I set the step generator timing conservatively would the jitter not be a problem?
[16:43:26] <wortley_> I was afraid if my base thread was too fast and I had a jitter >= base thread time, the universe would implode. Is that an unfounded fear?
[16:43:49] <PCW> skunkworks: J1800 seems fine at 2 KHz with Preemt-RT 3.18.7
[16:44:01] <seb_kuzminsky> no that could well generate a gravitational singularity and suck all of spacetime into it
[16:44:04] <skunkworks> I think I ran it at that for a while..
[16:44:40] <seb_kuzminsky> where is the rt-preempt patch for 3.18? the latest on the kernel.org git is 3.14 i think
[16:44:43] <PCW> this is with youtube videos and kernel compilations
[16:45:17] <seb_kuzminsky> http://git.kernel.org/cgit/linux/kernel/git/rt/linux-stable-rt.git/
[16:45:22] <seb_kuzminsky> i must be looking in the wrong place
[16:46:01] <seb_kuzminsky> ah, here:
https://www.kernel.org/pub/linux/kernel/projects/rt/
[16:46:14] <PCW> Yah
[16:46:42] <PCW> Heh its up to rt2 now
[16:50:13] <seb_kuzminsky> i wonder why there's no 3.18 branch in the kernel.org rt-preempt git repo
[17:17:55] <PCW> not sure, after all their troubles, I was a bit surprised when 3.18 showed up. Though I guess they got some funding through OSADL
[17:53:32] <Tom_itx> PCW is the J1800 the replacement for the D510 & D525?
[17:53:40] <Tom_itx> does it have parport?
[17:58:21] <skunkworks> header - I think yes.
[18:01:52] <Tom_itx> skunkworks do you have one?
[18:02:37] <skunkworks> yes - 1800 and 1900
[18:02:57] <Tom_itx> how many sata plugs?
[18:03:01] <Tom_itx> 4?
[18:03:15] <skunkworks> 2 I think
[18:03:31] <Tom_itx> seems i'm always coming up one short on the d525
[18:05:09] <skunkworks> http://www.newegg.com/Product/Product.aspx?Item=N82E16813128688
[18:15:08] <kb1kdw> seb/PCW/cradek: I did about 20 minutes of hunting for atomic operations and all I could find was stuf that only allowed working on type atomic_t. I haven't tried building code based on that yet. Is the "atomic_t" tree the right one to bark up, or does LinuxCNC/HAL provide it's own atomic operation goodness?
[18:21:21] <Tom_itx> skunkworks out of stock too :(
[18:21:29] <kb1kdw> Is rtapi_mutex_try() and rtapi_mutex_give() what I want to use?
[18:33:25] <PCW> intel ethernet latency pdf
[18:33:27] <PCW> http://www.intel.com/content/dam/doc/application-note/82575-82576-82598-82599-ethernet-controllers-latency-appl-note.pdf
[18:34:14] <PCW> http://www.newegg.com/Product/Product.aspx?Item=N82E16813157565&cm_re=asrock_j1900-_-13-157-565-_-Product
[18:34:16] <PCW> is nice if you dont need mini-itx
[18:35:47] <PCW> http://www.newegg.com/Product/Product.aspx?Item=N82E16813157497&cm_re=asrock_j1900-_-13-157-497-_-Product
[18:35:49] <PCW> is good if you dont need PCI
[20:20:51] <seb_kuzminsky> zlog:
[20:26:35] <seb_kuzminsky> c_morley: do you have any input on this?
https://sourceforge.net/p/emc/bugs/419/
[21:50:18] <wortley> Anyone: I don't understand what is wrong with this code, other than it panics the kernel and I have to reboot :)
[21:50:29] <wortley> unsigned long *mymutex=0;
[21:50:42] <wortley> if (!rtapi_mutex_try(mymutex))
[21:50:44] <wortley> {
[21:50:46] <wortley> rtapi_mutex_give(mymutex);
[21:50:47] <wortley> }
[21:53:29] <wortley> This was just a test, but in the future I wanted to prevent preemption while i check and lock a buffer. (seb, I couldn't find an atomic get & set) but I found this in the docs. )
[21:57:50] <kb1bdw> .
[22:15:04] <wortley> I have posted an example client and the infant spi driver. Suggestions welcome.
http://linuxcnc.org/index.php/english/forum/24-hal-components/28851-spi-bus-generic-driver-and-st-l6480#56262
[22:18:49] <KGB-linuxcnc> 03Dewey Garrett 052.7 20337dd 06linuxcnc 10src/hal/utils/halcmd_commands.c halcmd_commands.c: uspace return err if fail * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=20337dd
[22:18:49] <KGB-linuxcnc> 03Dewey Garrett 052.7 1ba2efa 06linuxcnc 10configs/sim/axis/histogram_demo.ini 10docs/src/hal/tools.txt 10scripts/hal-histogram 10src/hal/components/histobins.comp hal-histogram: guard for startup race * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1ba2efa
[22:51:25] <linuxcnc-build> build #3009 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/3009 blamelist: Dewey Garrett <dgarrett@panix.com>
[22:55:57] <linuxcnc-build> build #3019 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3019 blamelist: Dewey Garrett <dgarrett@panix.com>