New to RTAI

Currie Reid curriereid at nortelnetworks.com
Thu Oct 7 16:44:03 CEST 2004


Hello Philippe,

Thank you for your very detailed reply - I certainly do appreciate your
taking the time to address my very broad questions in such a very
informative manner.  It looks like ppc support in the 3.x stream is still
very dependent on the technology with which there may be a patent issue -
that being the case I've started to examine the Fusion option a little
more as it appears to have base ppc support while relying on Adeos.  I
thank you very much for the links.  I kind of take for granted that i386
development is going to be further along than ppc when it comes to
Linux as it was the original platform, so if I can get this working and am
able to provide anything back to the RTAI/Fusion, I look forward to doing
so.

Once again, thank very much for your time and patience,

Currie


On Thu, 7 Oct 2004, Philippe Gerum wrote:

> On Fri, 2004-10-01 at 18:24, Currie Reid wrote:
> > I am currently investigating real-time Linux solutions on a variety of
> > architectures, including ppc, i386, arm and mips, for a variety
> > of boards under each architecture.  Currently the best bet at this point
> > seems to be RTAI, but what flavour?  RTAI 3 seems to have support only for
> > i386 using ADEOS (trying to avoid RTLinux patent problems) but my first
> > board is ppc.  Does that mean I should go the Fusion route?  One of the
> > criteria that I've been asked to ensure is that whatever solution I come
> > up with works with a 2.6.x kernel.  Fusion seems to offer more in this
> > regard as it supports i386 and ppc under the 2.6 kernel without the sticky
> > RTLinux patent problems (again because of its ADEOS base).
> >
> > Please excuse the newbie questions - I've tried to find the answers to
> > these questions on the site, but the project seems to be moving so quickly
> > that the documentation that is there is out of date.
>
> If 2.6 is a prerequisite, then I'd say that choosing between 3.x and
> fusion is basically a matter of selecting a software architecture that
> fits your needs. Both provide kernel-based and user-space oriented
> real-time support, but do not implement them the same way, mainly
> because they had different initial goals.
>
> Historically, 3.x and its predecessors - i.e. the original RTAI
> technology - were primarily aimed at high performance, slicing
> nanoseconds to get as close as possible to the hardware limits with
> respect to latencies, and only relatively recently worked on a deeper
> integration/cooperation of the real-time core with the Linux kernel. For
> this reason, the 3.x core architecture has a monolithic design going
> straight to the performance issues, and still has a strong x86 bias.
>
> Ok, now the shameless plug. Meanwhile, the Xenomai technology which
> underlies fusion - and was merged into the RTAI project 18 months ago -
> has taken the exact opposite approach during its development: first, a
> seamless integration of the real-time core with Linux has been reached,
> then we have been working lately on the raw performance issues, granted
> that the core Xenomai software already provided for determinism. The
> reason for such approach is to be found in the initial goal of Xenomai,
> which was to provide a framework for porting applications from
> traditional RTOS like VRTX, pSOS+, VxWorks, ChorusRT (or even RTOS specs
> like Arinc653 and uITRON) to a GNU/Linux environment. We wanted at that
> time to be able to impersonate any kind of RTOS by emulating its API
> over a generic core, and have this RTOS abstraction level intimately
> integrate with the Linux kernel so that, like LXRT allowed before us, we
> could escape the "FIFO hemiplegia", i.e. the need for splitting
> real-time applications in two separate kernel and user spaces, only
> communicating through a sub-optimal and non-deterministic data channel.
>
> What fusion does better than LXRT though is preventing real-time tasks
> which issue Linux system calls from being perturbated by non RTAI
> activities. For achieving the whole thing, we went for a layered
> approach. Anyway, everything is better explained here:
> https://mail.rtai.org/pipermail/rtai/2004-April/007406.html
> http://www.enseirb.fr/~kadionik/rmll2004/presentation/philippe_gerum/philippe_gerum.html
>
> PPC-wise, 3.x continues the long time support of this architecture for
> kernel-based tasks which has been available since the early days of the
> RTAI project. fusion provides user-space support for PPC, but it has no
> track record since it has been made available only recently.
>
> To which extend fusion's layered approach is good or bad for
> performance, whilst 3.x's entangled implementation is good or bad for
> reliability remains one of our few but favourite trolls on the RTAI-dev
> list :o)
> This said, the way things work in this project causes improvements and
> fixes made on one side invariably go to the other one when applicable,
> which is largely made possible by the common base technology they share,
> i.e. Adeos.
>
> IOW, whatever path you go down to, you will certainly have to take a bet
> on the future :o)
>
> --
>
> Philippe.
>
>






More information about the Rtai mailing list