[Xenomai] Communication between RT-kernel to non-RT kernel
gilles.chanteperdrix at xenomai.org
Fri Apr 29 21:38:50 CEST 2016
On Thu, Apr 28, 2016 at 03:45:09PM +0300, Ran Shalit wrote:
> On Thu, Apr 28, 2016 at 1:52 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix at xenomai.org> wrote:
> > On Thu, Apr 28, 2016 at 08:37:17AM +0300, Ran Shalit wrote:
> >> On Thu, Apr 28, 2016 at 7:44 AM, Ran Shalit <ranshalit at gmail.com> wrote:
> >> > Hello,
> >> >
> >> > I am new with xenomai.
> >> >
> >> > I've made a lot of reading in the documentation which is very helpful.
> >> > But I haven't found how to communicate between rt kernel to non-rt
> >> > kernel on same machine,
> >> > Is there any example or documantation which explains this ?
> >> >
> >> > Best Regards,
> >> > Ran
> >> I guess that there is actually no need for such example or documentation.
> >> In userland 2 applications, one using xenomai kernel and the other
> >> linux kernel can commuicate
> >> in any method available in Linux between processes (pipes, shared
> >> memeory, etc) . Right?
> > Not quite. Accessing a pipe from a xenomai thread will cause it to
> > switch to secondary mode, IOW to migrate to the Linux kernel.
> > The IPC adapted to communicated between Xenomai threads and plain
> > Linux threads is XDDP, see the API documentation here:
> > https://xenomai.org/api-reference/
> Thank you for the feedback,
> I did eventually see that there is good introduction documentation for
> this "A tour of the native API ".
> 1. In this document I see that there are others mechanism which can be used :
> message Queues and shared memory.
Well, you misread, message queues are for communications between two
xenomai tasks (as opposed to communications between a xenomai task
and a Linux task), and shared memories are for sharing memories
between different processes, or between kernel and user-space (a use
that is no longer possible in 3.x, as having application code
running in kernel space has always been a bad design anyway). Linux
and Xenomai tasks can be threads running in the same address-space
(process), so no particular mechanism is needed to shared memory
between them. The problem, however, is protecting this data with a
mutual exclusion device working both for Xenomai and Linux tasks:
this was never implemented, so, sharing memory between Xenomai and
Linux tasks can only work for lockless access.
> 2. Other thing I've noticed is that it seems that in xenomai 3.x pdf
> folder this document is missing. Is the native api not relevant with
> xenomai 3.x anymore ?
The native API changed name in Xenomai 3, it is now called alchemy,
it still exists. However, we have almost abandoned the PDF documents
generation toolchain in Xenomai 3, and moved most of the content to
the web site, which is easier to maintain, and especially can be
updated more rapidly.
> 3. We do a kind of simple "Linux RT POC project", in order to
> understand how xenomai is RT (so that we can later choose between
> vxWorks or Linux according to the results),
> all we need to do is something simple as following:
> 3.1 application running on Zynq will get periodic interrupt from fpga.
> 3.2 on receiving interrupt it shall do some known mathematic
> calculation and continue to wait for next interrupt
> 3.3 we need to measure the time of received interrupt in application
> and to measure jitter if exist.
> 3.4 we also need to write simple standard Linux application which
> shall read the statistics from the RT application.
Ok, seeing how a beginner you are with Xenomai, this approach has
many pitfalls, which may result in getting the wrong results for
Xenomai. So, if you want to do a benchmark I suggest:
- either to use the "latency" tool provided by the Xenomai project,
which has been polished over a long time and is expected not to have
such issues, following for instance the procedure outlined on this
- or read Xenomai documentation more carefully, in order to
understand better what using a co-kernel implies (and by the way,
note that Xenomai 3 is also able to use Linux native preemption
patch, so it may make sense to benchmark this alternative too),
> 4. Can rtdm_clock_read be used for reading time of interrupt ?
> 5. If a userspace wait for interrupt on rt_intr_wait, which is
> synchronizaed on clock, is it better to CONFIG_HZ a larger number in
> order to get smaller lateny ?
CONFIG_HZ has meaning only for Linux, not for Xenomai. This question
shows that you have not really understood how Xenomai co-kernel
works (and not very much how Linux timing sub-system works either),
and I urge you to read more documentation.
More information about the Xenomai