[Xenomai] Question on rt_timer_tsc() vs rt_timer_read() semantics

I'm porting the LinuxCNC realtime support to Xenomai, and that has its own latency-test program. I observe: - the xenomai latency test is generally acceptable - with the LinuxCNC latency-test program I see occasional spikes up to maybe 80-100uS the only difference in the code I could discern

Re: [Xenomai] Question on rt_timer_tsc() vs rt_timer_read() semantics

-dev.git/blob/5979d84f31c0ef8e9dccdb26426732d0b83f3a87:/src/rtapi/xenomai_kernel_rtapi.c#l657 whew, I think I covered it. Is this still comprehensible ;-? best regards, Michael Am 03.11.2012 um 10:37 schrieb Gilles Chanteperdrix: Michael Haberler wrote: I'm porting the LinuxCNC realtime

Re: [Xenomai] Question on rt_timer_tsc() vs rt_timer_read() semantics

Gilles, Am 03.11.2012 um 10:37 schrieb Gilles Chanteperdrix: http://www.xenomai.org/index.php/I-pipe:Tracer thanks for the version hint - it was all in place, just needed to configure - building now. Also note that if LinuxCNC code runs in kernel-space, you should not be using the native

Re: [Xenomai] Question on rt_timer_tsc() vs rt_timer_read() semantics

sorry to be a pain.. that's all, and I'll be happy ever after even after the merge with RT_PREEMPT ;-? Yes, that is the point, the port of RTDM over the Linux kernel API already exists, though AFAIK it is not merged yet in the xenomai-forge tree. porting native-RTDM: mapping the task and

[Xenomai] RTDM shm design question - does this make sense?

I need to port RTAI code to RTDM, which uses rtai_kmalloc and rtai_malloc for usr/usr and usr/kernel shared memory segments they might be allocated by kernel or usermode first, and both kernel and userland should have an identical view; tracking between kernel and userland is in place (which

[Xenomai] RTDM API: no CPU binding, FPU setting for tasks available?

As suggested, I adapted the LinuxCNC kernel support from native to RTDM API; my remaining issues are: - how do I achieve CPU binding which is available in rt_task_create() (T_CPU(cpuid))? - do I need to tell an RTDM task that the thread might use the FPU (T_FPU in rt_task_create()) ? thanks

Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch

Am 30.11.2012 um 09:54 schrieb WONG Sheng Chao: On Thu, 29 Nov 2012 13:16:31 +0100, Stephan Kappertz wrote: The problem is that you are using the wrong timer. ... #endif - Stephan Thanks a lot Stephan and Gilles! The kernel is now able to boot with both CONFIG_XENOMAI and

Re: [Xenomai] Compiling I-pipe patched kernel on beaglebone from Angstrom branch

Am 30.11.2012 um 14:42 schrieb Gilles Chanteperdrix: On 11/30/2012 12:45 PM, Michael Haberler wrote: Am 30.11.2012 um 09:54 schrieb WONG Sheng Chao: On Thu, 29 Nov 2012 13:16:31 +0100, Stephan Kappertz wrote: The problem is that you are using the wrong timer. ... #endif

Re: [Xenomai] RT GPIO with Raspberry Pi

not strictly a Xenomai issue, but I'd completely bypass the kernel GPIO support and manipulate the GPIO registers directly - they are all memory mapped some inspiration here: http://git.mah.priv.at/gitweb/emc2-dev.git/blob/refs/heads/rtos-integration-preview1:/src/hal/drivers/hal_gpio.c this

Re: [Xenomai] RT GPIO with Raspberry Pi

Am 12.12.2012 um 10:09 schrieb Gilles Chanteperdrix: On 12/12/2012 09:30 AM, Michael Haberler wrote: ... just to make sure I understand your suggestion: in kernel mode you'd suggest to go through gpiolib and use gpio_get_value/gpio_set_value if possible ? in user mode you can

Re: [Xenomai] RT GPIO with Raspberry Pi

Am 12.12.2012 um 10:47 schrieb Andrey Nechypurenko: in that particular application, the GPIO's are used, among others, for generating stepper pulses, and the thread running this should be as fast as possible; in the RTAI/parport version of that code that's anywhere from 20-50uSec nothing

Re: [Xenomai] About the timer interrupt in beaglebone

Bao, I got Xenomai working fine, based on Henri Roosen's branch: https://github.com/roosen/linux/tree/v3.2.21_AM33xx_core-3.2 The current snapshot is here: http://git.mah.priv.at/gitweb/linuxcnc-kernel.git/shortlog/refs/heads/xenomai-3.2.21-bb-roosen-v3.2-staging-merged but there's no

Re: [Xenomai] About the timer interrupt in beaglebone

; just not for me. - Michael Am 31.12.2012 um 18:31 schrieb Gilles Chanteperdrix: On 12/31/2012 05:39 PM, Michael Haberler wrote: Bao, I got Xenomai working fine, based on Henri Roosen's branch: https://github.com/roosen/linux/tree/v3.2.21_AM33xx_core-3.2 Hi Michael, if you tell us

Re: [Xenomai] About the timer interrupt in beaglebone

Am 03.01.2013 um 09:53 schrieb Richard Cochran: On Wed, Jan 02, 2013 at 10:40:05AM +0100, Henri Roosen wrote: My decision to base the port on the Arago project was also that it looked 'most TI official' to me. TI ships an evaluation disk with the AM335x-evm board that is based on this

Re: [Xenomai] About the timer interrupt in beaglebone

Jack, Am 03.01.2013 um 23:00 schrieb Jack Mitchell: On 03/01/2013 09:18, Michael Haberler wrote: Am 03.01.2013 um 09:53 schrieb Richard Cochran: On Wed, Jan 02, 2013 at 10:40:05AM +0100, Henri Roosen wrote: My decision to base the port on the Arago project was also that it looked 'most TI

[Xenomai] universal application binary: how to auto-detect Xenomai/RT-PREEMPT/vanilla kernel

Hi, thanks to patience on this list we were able to build linuxcnc such that it runs on Xenomai, besides RT-PREEMPT, vanilla kernels (in a simulator/non-RT mode) and RTAI I'm planning to adapt linuxcnc such that a universal binary can be built which runs under Xenomai, RT-PREEMPT and vanilla

Re: [Xenomai] universal application binary: how to auto-detect Xenomai/RT-PREEMPT/vanilla kernel

Gilles, Am 14.01.2013 um 12:57 schrieb Gilles Chanteperdrix: On 01/14/2013 09:29 AM, Michael Haberler wrote: Hi, Hi, thanks to patience on this list we were able to build linuxcnc such that it runs on Xenomai, besides RT-PREEMPT, vanilla kernels (in a simulator/non-RT mode

Re: [Xenomai] universal application binary: how to auto-detect Xenomai/RT-PREEMPT/vanilla kernel

Am 14.01.2013 um 13:06 schrieb Jan Kiszka: Jan, On 2013-01-14 09:29, Michael Haberler wrote: Hi, thanks to patience on this list we were able to build linuxcnc such that it runs on Xenomai, besides RT-PREEMPT, vanilla kernels (in a simulator/non-RT mode) and RTAI I'm planning

Re: [Xenomai] [Emc-developers] new RTOS status: Scheduler (?) lockup on ARM

Am 19.01.2013 um 14:29 schrieb Gilles Chanteperdrix: On 01/17/2013 02:30 PM, Bas Laarhoven wrote: On 17-1-2013 9:53, Gilles Chanteperdrix wrote: On 01/17/2013 08:59 AM, Bas Laarhoven wrote: On 16-1-2013 20:36, Michael Haberler wrote: Am 16.01.2013 um 17:45 schrieb Bas Laarhoven

Re: [Xenomai] [Emc-developers] new RTOS status: Scheduler (?) lockup on ARM

Am 19.01.2013 um 15:10 schrieb Gilles Chanteperdrix: On 01/19/2013 03:09 PM, Michael Haberler wrote: Am 19.01.2013 um 14:29 schrieb Gilles Chanteperdrix: On 01/17/2013 02:30 PM, Bas Laarhoven wrote: On 17-1-2013 9:53, Gilles Chanteperdrix wrote: On 01/17/2013 08:59 AM, Bas Laarhoven

Re: [Xenomai] [Emc-developers] new RTOS status: Scheduler (?) lockup on ARM

the suspicion now turned to the DHCP lease setting and RTC time warp issues - the Beaglebone doesnt have an RTC so it starts up at 1-1-1970 the first DHCP lease still has 1970 timestamps, but eventually the RTC is set with ntpdate and it could be this causes confusion the thing which is hard

Re: [Xenomai] [Emc-developers] new RTOS status: Scheduler (?) lockup on ARM

Am 21.01.2013 um 12:56 schrieb Gilles Chanteperdrix: On 01/21/2013 12:43 PM, Michael Haberler wrote: the suspicion now turned to the DHCP lease setting and RTC time warp issues - the Beaglebone doesnt have an RTC so it starts up at 1-1-1970 the first DHCP lease still has 1970 timestamps

Re: [Xenomai] [Emc-developers] new RTOS status: Scheduler (?) lockup on ARM

Am 21.01.2013 um 20:10 schrieb Gilles Chanteperdrix: On 01/21/2013 02:32 PM, Michael Haberler wrote: Am 21.01.2013 um 12:56 schrieb Gilles Chanteperdrix: question: does a RTC time warp have any possible bearing on Xenomai operations? No, it should not, Xenomai uses its own clock

Re: [Xenomai] Ipipe pre and post patch for AM335x beagleBone/ koenkooi branch

Hi Stephan, Am 31.01.2013 um 15:17 schrieb Stephan Kappertz: Hi All, sorry for the long delay. As Gilles suggested I have prepared a pre and post patch for ipipe-core-3.2.21-arm-4 and the git repository supporting BeagleBone here:

[Xenomai] puzzled: running switchtest improves latency figures permanently

We have a report from 'the field' which we cannot make sense of. The situation: - an AMD board: http://www.asus.com/Motherboard/F1A75M_PRO - dmesg post boot: http://pastebin.com/38XrxNBy - xeno-regression-test runs well, max 32us jitter - John's Xenomai kernel packages: 3.5.7/2.6.2.1 [1] - a

Re: [Xenomai] puzzled: running switchtest improves latency figures permanently

Henri, Jan, Gilles thanks for the quick and profound answers results are just coming in from 'the field' (the problem cases are in the colonies and the folks over there are still working their coffee mugs ;-) Am 13.02.2013 um 12:53 schrieb Gilles Chanteperdrix: Do you get the same results

[Xenomai] packaging question: no kernel dependencies?

I'm working to debian-package linuxcnc with Xenomai userland RT threads. AFAICT building requires only the userland support package, but for instance not the kernel headers. The way I read http://www.xenomai.org/documentation/xenomai-2.6/html/README.INSTALL/#_feature_conflict_resolution it is

[Xenomai] shared memory compatibility - advice sought

I am building an RT application which is portable across RTAI, Xenomai/userland threads, Xenomai/kernel threads, RT-preempt and vanilla kernels (modulo timing restrictions). The xenomai kernel threads build is on a deprecation path but build for coverage reasons atm. The application already

Re: [Xenomai] shared memory compatibility - advice sought

schrieb Gilles Chanteperdrix: On 04/10/2013 11:24 PM, Michael Haberler wrote: I am building an RT application which is portable across RTAI, Xenomai/userland threads, Xenomai/kernel threads, RT-preempt and vanilla kernels (modulo timing restrictions). The xenomai kernel threads build

Re: [Xenomai] shared memory compatibility - advice sought

Gilles, I think I see the light although I'm not totally clear on all details yet: Am 11.04.2013 um 02:42 schrieb Gilles Chanteperdrix: On 04/11/2013 01:39 AM, Michael Haberler wrote: Gilles, thank you for your detailed answer. I'll concentrate on the RTDM suggestion because I'm after

Re: [Xenomai] shared memory compatibility - advice sought

Am 11.04.2013 um 09:05 schrieb Gilles Chanteperdrix: On 04/11/2013 09:00 AM, Michael Haberler wrote: Gilles, I think I see the light although I'm not totally clear on all details yet: There is a very simple solution, see my other mail: http://www.xenomai.org/pipermail/xenomai/2013

Re: [Xenomai] shared memory compatibility - advice sought

I've gotten the char shm driver to work flawlessly as suggested, and am now looking into dumping the rest of the SysV IPC legacy code in the linuxcnc code base and replace it by shm_open/mmap reading up on the Xenomai Posix skin a bit late (ahem) it occurs to me the best solution would have

Re: [Xenomai] shared memory compatibility - advice sought

Gilles, Am 16.04.2013 um 20:08 schrieb Gilles Chanteperdrix gilles.chanteperd...@xenomai.org: On 04/16/2013 02:59 PM, Michael Haberler wrote: ... reading up on ksrc/skins/posix/shm.c it occurs to me it isnt exactly a copy paste job getting that to run without the Xenomai environment

Re: [Xenomai] rtdm and rasberry-pi GPIO

Ross, any reason not to use just userland memory mapped port I/O like with this library: http://www.airspayce.com/mikem/bcm2835 ? that worked fine for me with a userland RT thread, no drivers needed - Michael Am 17.04.2013 um 22:12 schrieb Ross Williamson rwilliam...@astro.caltech.edu: I'm

Re: [Xenomai] Default options in the debian package

Am 19.04.2013 um 21:06 schrieb Gilles Chanteperdrix gilles.chanteperd...@xenomai.org: On 04/19/2013 01:46 PM, Leopold Palomo-Avellaneda wrote: [1] http://lists.mech.kuleuven.be/pipermail/orocos-users/2013-April/006986.html Hi, that link does not tell us why you need this option.

[Xenomai] 3.8.10 beaglebone failure: any clues I missed?

I've built a 3.8.10 beaglebone kernel using Stephane's patch and xenomai-2.6 master ; only config changes from default config were: disable frequency scaling, and disable smp (but same symptoms as below without these changes) - kernel boots fine - 'sudo xeno-regression-test -l

Re: [Xenomai] 3.8.10 beaglebone failure: any clues I missed?

schrieb Gilles Chanteperdrix gilles.chanteperd...@xenomai.org: On 05/03/2013 11:54 PM, Michael Haberler wrote: I've built a 3.8.10 beaglebone kernel using Stephane's patch and xenomai-2.6 master ; only config changes from default config were: disable frequency scaling, and disable smp (but same

Re: [Xenomai] 3.8.10 beaglebone failure: any clues I missed?

Am 04.05.2013 um 15:39 schrieb Gilles Chanteperdrix gilles.chanteperd...@xenomai.org: On 05/04/2013 08:04 AM, Michael Haberler wrote: Xenomai: native skin or CONFIG_XENO_OPT_PERVASIVE disabled. (modprobe xeno_native?) See: http://www.xenomai.org/documentation/xenomai-2.6/html

Re: [Xenomai] 3.8.10 beaglebone failure: any clues I missed?

Am 04.05.2013 um 20:07 schrieb Gilles Chanteperdrix gilles.chanteperd...@xenomai.org: On 05/04/2013 04:30 PM, Michael Haberler wrote: Am 04.05.2013 um 15:39 schrieb Gilles Chanteperdrix gilles.chanteperd...@xenomai.org: On 05/04/2013 08:04 AM, Michael Haberler wrote: Xenomai

[Xenomai] Beagleboard 3.8 regression results

using Stephan's 3.8 patch for the BeagleBoard and running arm:/usr/xenomai/bin# ./xeno-regression-test -l /usr/lib/xenomai/testsuite/dohell -m /tmp 100 -t 2 gives select service with posix message queues: success ++ start_load ++ echo start_load ++ check_alive /usr/xenomai/bin/switchtest ++

Re: [Xenomai] Beagleboard 3.8 regression results

Am 19.05.2013 um 01:30 schrieb Gilles Chanteperdrix gilles.chanteperd...@xenomai.org: On 05/18/2013 11:39 PM, Michael Haberler wrote: using Stephan's 3.8 patch for the BeagleBoard and running arm:/usr/xenomai/bin# ./xeno-regression-test -l /usr/lib/xenomai/testsuite/dohell -m /tmp 100

[Xenomai] kernel equivalent of SIGXCPU

I'm trying to trap scheduling violations through an exception handler in user RT it's straightforward - use the SIGXCPU handler is rthal_trap_catch() the way to go? or is it just evaluating the rt_task_wait_period() returns ? I'm a bit fuzzy as to the relation between these two - the manual

[Xenomai] q on rt_task_self() and mode switching

if a userland RT thread gets modeswitched, the SIGXCPU handler obviously still executes in the RT domain, at least rt_task_self() returns a valid task descriptor - fine. If a kernel RT thread misses the release point, it seems the thread is immediately switched to linux scheduling - or at

Re: [Xenomai] q on rt_task_self() and mode switching

Am 08.07.2013 um 15:37 schrieb Philippe Gerum r...@xenomai.org: On 07/08/2013 03:23 PM, Michael Haberler wrote: if a userland RT thread gets modeswitched, the SIGXCPU handler obviously still executes in the RT domain, Nope. All regular signal handlers are executed in the linux domain

Re: [Xenomai] Using hardware PWM generators with Xenomai

Sagar, you might want to study the LinuxCNC code, which does PWM - among other functions like a stepper generator - via the PRU

Re: [Xenomai] Building BeagleBone kernel from git

just noting I built a working BB kernel using https://github.com/cdsteinkuehler/linux-dev/tree/am33x-v3.8-bone26-xenomai as-is yesterday -Michael Am 24.08.2013 um 19:10 schrieb Ralf Roesch xeno...@cantastic.org: Hi Gilles, Hi Charles, I followed this thread highly interested and built my

[Xenomai] OT: Xenomai moving metal

Here's something haptic for a change: Xenomai master + linux3.8.13 under the hood of LinuxCNC driving an engraving machine: https://www.youtube.com/watch?v=6lMM-bSx6cc -Michael ___ Xenomai mailing list Xenomai@xenomai.org

[Xenomai] integrate event signaled by RT thread into non-RT event loops (poll, select, eventfd..)?

I'm looking for a simple method to post an event from an RT thread so a userland non-RT thread can wait for, and pick it up via a file descriptor (without switching the originating thread to primary domain, of course) event context can be minimal since the userland handler can figure; actual

Re: [Xenomai] integrate event signaled by RT thread into non-RT event loops (poll, select, eventfd..)?

Gilles, Am 20.11.2013 um 15:58 schrieb Gilles Chanteperdrix gilles.chanteperd...@xenomai.org: On 11/20/2013 03:33 PM, Michael Haberler wrote: I'm looking for a simple method to post an event from an RT thread so a userland non-RT thread can wait for, and pick it up via a file descriptor

[Xenomai] debian xenomai package

we're considering how to package LinuxCNC such that it can eventually be included in debian the core package will support RT-PREEMPT because an RT-PREEMPT kernel is available stock in debian; the other RT kernels will be covered by separate packages (Xenomai, RTAI). so far we've used the

[Xenomai] i-pipe tracer on in production kernels? (was Re: Altera Cyclone V)

http://www.xenomai.org/index.php/I-pipe:Tracer describes the trace API, which could be useful to track down issues Q: does enabling the tracer incur significant overhead if compiled in but unused, or is it reasonable to leave it on in a production kernel? if the former, we might have to

[Xenomai] packet_mmap raw socket usable from Xenomai?

I am looking into ethernet I/O from a RT thread, but am willing to tradeoff some latency against using stock linux drivers also I'd like to use a common method across RT-PREEMPT and Xenomai thread styles to keep the number of moving parts low One method which looks promising is the

Re: [Xenomai] RTDM: Ethernet driver

Am 22.04.2014 um 13:16 schrieb Anders Blomdell anders.blomd...@control.lth.se: On 04/22/2014 11:45 AM, yogesh garg wrote: I want to write Ethernet (NIC) driver on Xenomai using RTDM. I don't want to use RTnet. Why not? RTnet does not imply that you have to use the RTnet protocol, it's

[Xenomai] q: userland timestamps which match rt_timer_read()

I need to create ns-resolution timestamps from RT (using rt_timer_read() - no surprises) and from normal userland programs the latter binaries should be Xenomai-unaware if possible - is there a normal Linux API which reads the same timestamp source as rt_timer_read()? eg:

Re: [Xenomai] q: userland timestamps which match rt_timer_read()

Am 27.04.2014 um 19:28 schrieb Gilles Chanteperdrix gilles.chanteperd...@xenomai.org: On 04/27/2014 05:29 PM, Michael Haberler wrote: I need to create ns-resolution timestamps from RT (using rt_timer_read() - no surprises) and from normal userland programs the latter binaries should

Re: [Xenomai] New Xenomai kernels for testing

Gilles, Am 09.05.2014 um 19:52 schrieb Gilles Chanteperdrix gilles.chanteperd...@xenomai.org: Something completely unrelated, do LinuxCNC/MachineKit users use Comedi/Analogy? If yes, we would be interested in users willing to test ports of Comedi drivers to the Analogy framework. This has

Re: [Xenomai] gdb / threads on beaglebone black

Am 28.05.2014 um 16:24 schrieb Philippe Gerum r...@xenomai.org: On 05/28/2014 04:08 PM, Drew wrote: Yes, my guess was correct. The do - while loop in trampoline is exiting with error -38 (-ENOSYS?) If I change line 110 of skins/native/task.c: - while(err == -EINTR) + while(err == -EINTR

Re: [Xenomai] gdb / threads on beaglebone black

Am 28.05.2014 um 19:54 schrieb Gilles Chanteperdrix gilles.chanteperd...@xenomai.org: On 05/28/2014 04:45 PM, Michael Haberler wrote: Am 28.05.2014 um 16:24 schrieb Philippe Gerum r...@xenomai.org: On 05/28/2014 04:08 PM, Drew wrote: Yes, my guess was correct. The do - while loop

Re: [Xenomai] User Space Interrupt not working

Am 29.05.2014 um 14:11 schrieb matteo.semmol...@selex-es.com: Hi all, I've pached (succefullly...I hope so) linux kernel 3.8 with Xenomai 2.6.3. I've two issue about interrupt handled in userspace: the first one is related to asynchronous notifications from kernelspace to userspace,

[Xenomai] arm 64bit atomics

we found this: http://stackoverflow.com/questions/9857760/can-an-arm-interrupt-occur-in-mid-instruction and are considering which impact that has on machinekit, which uses doubles in memory shared between threads, relying on updates being atomic I wonder if this topic has come up in the

Re: [Xenomai] integrate event signaled by RT thread into non-RT event loops (poll, select, eventfd..)?

Am 20.11.2013 um 07:58 schrieb Gilles Chanteperdrix gilles.chanteperd...@xenomai.org: On 11/20/2013 03:33 PM, Michael Haberler wrote: I'm looking for a simple method to post an event from an RT thread so a userland non-RT thread can wait for, and pick it up via a file descriptor (without

Re: [Xenomai] Xenomai: binding failed: Operation not permitted.

http://xenomai.org/troubleshooting-a-dual-kernel-configuration/#binding_failed_Operation_not_permitted -m Am 30.09.2014 um 00:34 schrieb Hasret Sarıyer hsrts...@gmail.com: I installed xenomai using this guide http://xenomai.org/2014/06/building-debian-packages/. And there are some examples

[Xenomai] RT-CAN question (was: CAN bus on beaglebone black)

status: I have Steve Batazzo's driver running on the beaglebone, using a stock Xenomai kernel from Robert Nelson's repo (linux-image-3.8.13-xenomai-r71 from http://repos.rcn-ee.net/debian/), current driver out of tree at https://github.com/mhaberler/rtcan-bb branch mah I also have a preliminary

Re: [Xenomai] RT-CAN question (was: CAN bus on beaglebone black)

2015-03-19 19:44 GMT+01:00 Steve B sbatta...@gmail.com: On Thu, Mar 19, 2015 at 2:57 AM, Michael Haberler haberl...@gmail.com wrote: status: I have Steve Batazzo's driver running on the beaglebone, using a stock Xenomai kernel from Robert Nelson's repo (linux-image-3.8.13-xenomai-r71

Re: [Xenomai] RT-CAN question (was: CAN bus on beaglebone black)

2015-03-20 7:15 GMT+01:00 Michael Haberler haberl...@gmail.com: 2015-03-19 19:44 GMT+01:00 Steve B sbatta...@gmail.com: On Thu, Mar 19, 2015 at 2:57 AM, Michael Haberler haberl...@gmail.com wrote: status: I have Steve Batazzo's driver running on the beaglebone, using a stock Xenomai

Re: [Xenomai] RT-CAN question (was: CAN bus on beaglebone black)

2015-03-20 7:58 GMT+01:00 Michael Haberler haberl...@gmail.com: 2015-03-20 7:15 GMT+01:00 Michael Haberler haberl...@gmail.com: 2015-03-19 19:44 GMT+01:00 Steve B sbatta...@gmail.com: On Thu, Mar 19, 2015 at 2:57 AM, Michael Haberler haberl...@gmail.com wrote: status: I have Steve

Re: [Xenomai] Q: LTTNG xenomai status

2015-03-26 23:37 GMT+01:00 Michael Haberler haberl...@gmail.com: what is the status on using LTTNG tracepoints in an RT thread? the last discussion has been a while back, like 2010ish LTTNG 2.5.1 is in the debian jessie stream. Can I use that as-is? Any special precautions I need to take

Re: [Xenomai] Q: LTTNG xenomai status

2015-03-30 11:17 GMT+02:00 Philippe Gerum r...@xenomai.org: On 03/30/2015 10:58 AM, Michael Haberler wrote: 2015-03-26 23:37 GMT+01:00 Michael Haberler haberl...@gmail.com: what is the status on using LTTNG tracepoints in an RT thread? the last discussion has been a while back, like

Re: [Xenomai] Q: LTTNG xenomai status

2015-03-30 18:11 GMT+02:00 Jan Kiszka jan.kis...@web.de: On 2015-03-30 11:58, Philippe Gerum wrote: On 03/30/2015 11:51 AM, Michael Haberler wrote: 2015-03-30 11:17 GMT+02:00 Philippe Gerum r...@xenomai.org mailto:r...@xenomai.org: On 03/30/2015 10:58 AM, Michael Haberler wrote

[Xenomai] Xenomai 2 - point release schedules?

what's the timeline for a post-2.6.4 release? I'm trying to determine if we should work with an out-of-tree patch for the Xenomai RT-CAN driver in interim, or just wait to get this driver into the next release thanks! - Michael ___ Xenomai mailing

[Xenomai] RT-CAN driver for C_CAN,D_CAN cores ready

here is the RT-CAN driver by Steve Battazzo for (among others) the Beaglebone: https://github.com/mhaberler/xeno_d_can/commits/for-xenomai-2 I've reconstructed the history as Steve based this on the 3.8 c_can driver. The problems Steve originally noted are resolved. Please let me know if

Re: [Xenomai] RT-CAN driver for C_CAN,D_CAN cores ready

: 224496 bytes Desc: not available URL: http://www.xenomai.org/pipermail/xenomai/attachments/20150428/72323552/attachment.obj -- next part -- On 04/20/2015 01:01 AM, Michael Haberler wrote: here is the RT-CAN driver by Steve Battazzo for (among others) the Beaglebone

[Xenomai] Q on scheduling - rt_task_wait_period vs rtdm_wait_event

so far we had multiple periodic RT threads of different priority, so a lower-priority thread would not preempt a higher-priority one we are switching the scheduling of a low-priority thread from periodic to event-based - instead of rt_task_wait_period(), this task will now wait in an RTDM driver

Re: [Xenomai] Q on scheduling - rt_task_wait_period vs rtdm_wait_event

Am 07.06.2015 um 16:42 schrieb Philippe Gerum r...@xenomai.org: On 06/07/2015 02:39 PM, Michael Haberler wrote: so far we had multiple periodic RT threads of different priority, so a lower-priority thread would not preempt a higher-priority one we are switching the scheduling of a low

Re: [Xenomai] RTDM-native brushup

I now get all tests to pass (as far as I can tell), see below Has anybody ever gone beyond running rtdmtest with this, like building an actual driver? before I spend time on it - did the can and serial drivers actually work? - Michael --- Fixed by changing add_wait_queue_exclusive_locked()

Re: [Xenomai] RTDM-native brushup

Am 22.06.2015 um 17:50 schrieb Jan Kiszka jan.kis...@siemens.com: On 2015-06-22 17:34, Michael Haberler wrote: I now get all tests to pass (as far as I can tell), see below Nice! I _think_ the rtdm_task API is now functional as well: https://github.com/mhaberler/rtdm-native tested

Re: [Xenomai] RTDM-native brushup

Am 19.06.2015 um 14:14 schrieb Jan Kiszka jan.kis...@siemens.com: .. Serial logs preferred (the top of the error message is missing)... (wild guess: spinlocks around here:

Re: [Xenomai] RTDM-native brushup

Jan - thanks! I made minor progress. duh on the mknod.. I switched to a more recent kernel: http://static.mah.priv.at/public/3.18.13-rt10/ hardware=Gigabyte Technology Co., Ltd. To be filled by O.E.M./J1900N-D3V, BIOS F3 04/29/2014 mutated to the kthread API (approximate - no idea if correct,

Re: [Xenomai] Q on xenomai2/3 userland coexistence

Am 27.06.2015 um 15:14 schrieb Gilles Chanteperdrix gilles.chanteperd...@xenomai.org: On Sat, Jun 27, 2015 at 03:09:19PM +0200, Philippe Gerum wrote: On 06/27/2015 02:22 PM, Michael Haberler wrote: ATM we're sorting through the machinekit xenomai3 transition on debian I assume

[Xenomai] Q on xenomai2/3 userland coexistence

ATM we're sorting through the machinekit xenomai3 transition on debian I assume that users will continue to run xenomai2 kernels for a long time, so we work towards separate (but hopefully coexisting-in-peace) packages for Xenomai2 and Xenomai3 (startup is driven by kernel autodetection, so

Re: [Xenomai] RTDM-native brushup

rebuilt kernel with CONFIG_FRAME_POINTER; in fact different traceback: You probably want to enable frame pointers in order to make the backtraces more reliable. # ./rtdmtest -s -c 10 [ 47.872760] starting RTDM services. [ 52.376895] __rtdmtest_init: registering device rttest0, err=250 [

[Xenomai] RTDM-native brushup

ok, so tried to just get RTDM support and rtdmtest build as module and loadable without error, and that works I did not bother fixing the sk_alloc() etc proto related changes for now Kernel was 3.2.0-4-rt-686-pae #1 SMP PREEMPT RT Debian 3.2.68-1+deb7u1 i686 GNU/Linux (RT-PREEMPT kernel in

Re: [Xenomai] RTDM-native mainlining - status?

Am 14.06.2015 um 10:46 schrieb Gilles Chanteperdrix gilles.chanteperd...@xenomai.org: Michael Haberler wrote: Am 13.06.2015 um 09:19 schrieb Gilles Chanteperdrix gilles.chanteperd...@xenomai.org: Michael Haberler wrote: I hope I do not overlook some boundary condition

Re: [Xenomai] RTDM-native mainlining - status?

Am 13.06.2015 um 09:19 schrieb Gilles Chanteperdrix gilles.chanteperd...@xenomai.org: Michael Haberler wrote: I hope I do not overlook some boundary condition - but assuming that building out-of-tree RTDM support is significantly less invasive and version-dependent than patching

[Xenomai] RTDM-native mainlining - status?

Q - can I assume RTDM-native will be part of RT-PREEMPT if/when that goes mainline? or must I assume this will remain a Xenomai-specific way of doing things which will not be available via a torvalds kernel? - Michael background - since we have a portable RT application, investing into RTDM

[Xenomai] RTLWS 17 Call for Papers

, OpenTech EDV Research, Austria Joseph Wenninger, TU Wien, Austria Julia Lawall, Inria, France Michael Haberler, machinekit.io, Austria Nicholas Mc Guire, OpenTech EDV Research, Austria Paolo Mantegazza, Politecnico di Milano, Italy Paul McKenney, IBM Linux Technology Center, USA Roberto Bucher, SUPSI

Re: [Xenomai] RTDM-native mainlining - status?

Gilles - Am 13.06.2015 um 01:02 schrieb Gilles Chanteperdrix gilles.chanteperd...@xenomai.org: Michael Haberler wrote: Q - can I assume RTDM-native will be part of RT-PREEMPT if/when that goes mainline? or must I assume this will remain a Xenomai-specific way of doing things which

Re: [Xenomai] mutate/start RT_TASK a posix thread?

Am 31.07.2015 um 16:07 schrieb Philippe Gerum r...@xenomai.org: On 07/31/2015 11:21 AM, Michael Haberler wrote: Philippe, this is excellent news because this means the scheme would work _and_ improve versatility. I have only an optimization question left: Am 31.07.2015 um 10:22

Re: [Xenomai] mutate/start RT_TASK a posix thread?

Am 31.07.2015 um 17:53 schrieb Philippe Gerum r...@xenomai.org: On 07/31/2015 05:35 PM, Philippe Gerum wrote: On 07/31/2015 05:17 PM, Michael Haberler wrote: Am 31.07.2015 um 16:07 schrieb Philippe Gerum r...@xenomai.org: On 07/31/2015 11:21 AM, Michael Haberler wrote: Philippe

Re: [Xenomai] mutate/start RT_TASK a posix thread?

Philippe, Am 30.07.2015 um 18:25 schrieb Philippe Gerum r...@xenomai.org: On 07/30/2015 07:26 AM, Michael Haberler wrote: we're happily using RT threads using the Xenomai 2 thread API is it possible _using this API_ to create/mutate/relax such a thread intentionally into a Posix thread

[Xenomai] mutate/start RT_TASK a posix thread?

we're happily using RT threads using the Xenomai 2 thread API is it possible _using this API_ to create/mutate/relax such a thread intentionally into a Posix thread but retaining the API usage? I can do any conditional API usage through thread parameters to avoid calls which will not work for

Re: [Xenomai] mutate/start RT_TASK a posix thread?

Philippe, this is excellent news because this means the scheme would work _and_ improve versatility. I have only an optimization question left: Am 31.07.2015 um 10:22 schrieb Philippe Gerum r...@xenomai.org: On 07/31/2015 08:50 AM, Michael Haberler wrote: Philippe, Am 30.07.2015 um

[Xenomai] clock_gettime(CLOCK_HOST_REALTIME) equivalent using native skin?

We are planning to synchronize several nodes running machinekit with IEEE1588/Precision Time Protocol using the ptpd debian sid package ptp adjusts the tunable kernel clock through adjtimex(2) similar to ntpd Assuming Xenomai2, it seems the Posix skin's clock_gettime(CLOCK_HOST_REALTIME) is the

Re: [Xenomai] [PATCH] Added drivers for C_CAN ported from original Linux driver

Can I ask for review and merge of this work? - Michael > Am 21.07.2015 um 19:13 schrieb Steve Battazzo : > > From: SteveB > > --- > ksrc/drivers/can/Kconfig |7 + > ksrc/drivers/can/Makefile |6 +- >

Re: [Xenomai] [PATCH 1/1] rtcan_flexcan: with open firmware, use devm_clk_put instead of clk_put

Hi Thiery, could you give a bit of context about this patch? what problem does the patch resolve? what is 'open firmware' which kernel version did you apply this? which platform? - Michael > Am 25.09.2015 um 15:22 schrieb Thierry Bultel : > > Signed-off-by: