Re: [Emc-developers] Unified Binary Branch, BeagleBone PRU, and paths

2013-09-02 Thread Michael Haberler
Am 02.09.2013 um 05:36 schrieb Charles Steinkuehler char...@steinkuehler.net: I'm trying to make an updated MachineKit image for the BeagleBone using the unified-build-candidate-2 branch as a base. One issue I'm running into is the pru binary image has apparently moved from rtlib/ to

Re: [Emc-developers] Unified Binary Branch, BeagleBone PRU, and paths

2013-09-02 Thread Charles Steinkuehler
On 9/2/2013 4:23 AM, Michael Haberler wrote: Am 02.09.2013 um 05:36 schrieb Charles Steinkuehler char...@steinkuehler.net: I'm trying to make an updated MachineKit image for the BeagleBone using the unified-build-candidate-2 branch as a base. One issue I'm running into is the pru binary

[Emc-developers] 2.6-pre and git

2013-09-02 Thread Charles Steinkuehler
What is the git status for what is going to become 2.6? I'm switching away from the older xenomai builds in favor of the new unified-build-candidate-2 branch. It looks like development on this is mostly in MAH's github repo, but the branch appears in git.linuxcnc.org as well. I'm wondering what

Re: [Emc-developers] Unified Binary Branch, BeagleBone PRU, and paths

2013-09-02 Thread John Morris
On 09/02/2013 04:23 AM, Michael Haberler wrote: Am 02.09.2013 um 05:36 schrieb Charles Steinkuehler char...@steinkuehler.net: One issue I'm running into is the pru binary image has apparently moved from rtlib/ to rtlib/xenomai. the reason was the intent to package all binaries for a

Re: [Emc-developers] BeagleBone Kernels

2013-09-02 Thread Charles Steinkuehler
On 9/2/2013 10:48 AM, John Morris wrote: Somewhat OT for this thread, do we have both Xenomai and RT_PREEMPT kernels for the BeagleBone? That would be pretty neat! There are obviously xenomai kernels available. I have not tried to make an RT_PREEMPT kernel for the 'Bone for a while, but the

Re: [Emc-developers] Unlisted dependency

2013-09-02 Thread Jeff Epler
On Sun, Sep 01, 2013 at 04:18:24PM -0500, Charles Steinkuehler wrote: On 9/1/2013 3:51 PM, Charles Steinkuehler wrote: I'm not sure if bc should really be a dependency, but it seems like it ought to at least be recommended. Never mind...looks like this has already been fixed since the last

Re: [Emc-developers] Latency Test

2013-09-02 Thread Jeff Epler
On Sun, Sep 01, 2013 at 03:55:44PM -0500, Charles Steinkuehler wrote: I'm hacking a bit on the latency-test script because the default 25 uS base thread causes the BeagleBone to hang (typical IRQ latency is 20-80 uS, so a 25 uS thread is really pushing things). Yuck. Should the default base

Re: [Emc-developers] proposal for capability of external interrupts to trigger HAL threads

2013-09-02 Thread Gene Heskett
On Monday 02 September 2013 23:18:36 Jon Elson did opine: I'm not sure theis is the right method to bring this up, but... I have had some discussions with Michael Haberler about having the capability for making HAL threads triggerable via an external interrupt. Apparently, there was a

Re: [Emc-developers] proposal for capability of external interrupts totrigger HAL threads

2013-09-02 Thread Steve Stallings
I have always believed that a much better system would result if the real time interrupts were driven from the actual hardware that was collecting the feedback and applying the driving functions. Yes, this means that the real time system cannot run if the drivers for the hardware don't correctly

Re: [Emc-developers] proposal for capability of external interrupts to trigger HAL threads

2013-09-02 Thread Michael Haberler
Am 03.09.2013 um 05:41 schrieb Gene Heskett ghesk...@wdtv.com: On Monday 02 September 2013 23:18:36 Jon Elson did opine: I'm not sure theis is the right method to bring this up, but... I have had some discussions with Michael Haberler about having the capability for making HAL threads

Re: [Emc-developers] proposal for capability of external interrupts totrigger HAL threads

2013-09-02 Thread Michael Haberler
Am 03.09.2013 um 05:43 schrieb Steve Stallings steve...@newsguy.com: I have always believed that a much better system would result if the real time interrupts were driven from the actual hardware that was collecting the feedback and applying the driving functions. Yes, this means that the