[rtai] RTEMS RTAI module

[Erwin Rol]

On 02 Sep 2001 19:35:58 -0500, Joel Sherrill wrote:
> OK.  I am investigating this further.  I think that RTEMS can
> be "ported" to RTAI using option 1 described below.   This would
> be really cool since you would get RTEMS RTEID/pSOS+, ITRON, and
> pthreads interface in this environment.
> 
> To get a feel for how to approach the port technically, I am trying 
> to get things setup to test.  Here is where I would like to 
> go as a test environment and what I have done so far.
> 
> Want: 
> 
>   + simple RTAI environment under VMware, plex86, etc. for
>     testing and not crashing entire machine.

Hmmm never tried that, would be interesting to here if that works.


> 
> What I have tried;
> 
>   + Atomic RTAI floppy image fails to boot under plex86
>   + Atomic RTAI floppy image seems ok under vmware.
>   + Linux 2.4.9 kernel and rtai-24.1.6  on a Redhat 7.1 box.
>     This seemed to be working out OK  as I managed to reboot
>     the new kernel with RTAI patches but can't compile completely.
>     I get these warnings (they start at #1) .. 
> 
> arch/i386/rtai.c:298:45: warning: pasting "(" and "29" does not give a
> valid preprocessing token
> arch/i386/rtai.c:299:1: warning: pasting "(" and "30" does not give a
> valid preprocessing token
> arch/i386/rtai.c:299:23: warning: pasting "(" and "31" does not give a
> valid preprocessing token
> 
>   and the build fails later with this:
> 
> ../../include/rtai_lxrt.h:325: impossible register constraint in `asm'
> ../../include/rtai_lxrt.h:325: impossible register constraint in `asm'
> ../tasklets.h:190: confused by earlier errors, bailing out
> 
> This has to be a common problem.  DO I have a bad compiler version
> with Redhat 7.1 for using RTAI?
> 

yep gcc 2.96 or gcc 3.x give this error. use kgcc on RH 7.x or just
compile yer own gcc (which i am sure you can :-)


> Questions:
> 
>   + Recommendations on setting up a virtual test environment
>     using VMWare or plex86 as the target would be appreciated.
>   + Where are mailing list archives?  I know I have tripped a 
>     FAQ with this problem?

http://realtimelinux.org/archives/rtai/

CVS web in case you want to look at the CVS sources.
http://cvs.rtai.org/

>   + how do you debug the modules?
>   
> Thanks.
> 
> --joel

- Erwin

> 
> 
> Bernhard Kuhn wrote:
> > 
> > Erwin Rol schrieb:
> > >
> > > using RTEMS on Posix on RTAI on the RTHAL was not realy what i meant
> > 
> > Ah, you mean using RTEMS on LXRT on RTAI on the RTHAL? ... Just kidding
> > :-)
> > 
> > > What i meant was creating a BSP that reserves a block of memory and uses
> > > the RT-HAL so it thinks it is running on a real PC. The argument of not
> > > having a variable timer and just the periodic scheduler is kind of
> > > strange, i mean lots of ppl use RTEMS and seem to be happy with it.
> > 
> > Agreed: many people are quite satisfied with a periodic mode
> > scheduler (which resides in the cyclic nature of control loop
> > and data aquisition systems). But several "exotic" things
> > like the RC-Servo demo doesn't work if you can't do something
> > like a wait_ns() within few microseconds accuracy ...
> > 
> > > I most certainly didn't mean to replace RTAI with
> > > RTEMS, because it could just be a module like the
> > > different RTAI schedulers are modules.
> > 
> > When i was talking about "replacing" RTAI by RTEMS in
> > one of my former mails, then i was exactly thinking
> > about providing it as an alternative kernel module
> > to rtai_sched.c. To sum up all available options
> > recently discussed:
> > 
> > Option 0: RTEMS BSP for RTHAL
> > -----------------------------
> > 
> > I wouldn't recomend doing an RTEMS BSP for the RTHAL directly,
> > since rtai.c already provides a timer and interrupt
> > handling layer. Trying to put RTEMS directly on top
> > of the RTHAL would mean to re-implement most of the
> > stuff that was already done in rtai.c. If necessary at all,
> > rtai.c could be extended conditionaly (i.e. #ifdef RTEMS_BSP)
> > 
> > Option 1: RTEMS for rtai.c
> > --------------------------
> > 
> > As already mentioned, rtai.c provides a lot if things
> > you would have to re-implement in the BSP seperatly.
> > 
> > Option 2: RTEMS BSP partly integrated in rtai.c
> > -----------------------------------------------
> > 
> > You could enhance rtai.c so that it supports
> > two schedulers at the same time, allowing
> > the RTAI scheduler and the RTEMS scheduler
> > running at the same time.
> > 
> > Option 3: RTEMS BSP for rtai_sched.c
> > ------------------------------------
> > 
> > Would operate just like the POSIX scheduler on top
> > of the RTAI scheduler.
> > 
> > Option 4: RTEMS BSP for POSIX on top of rtai_sched
> > --------------------------------------------------
> > 
> > Adapting the existing Native Linux RTEMS BSP to
> > the posix module of the rtai distribution.
> > 
> > My personal favorite is Option 3, because this
> > architecture would easyly allow mixing code
> > of different worlds, using it at the same time.
> > The existing POSIX overlay module has proved
> > that the overhead is acceptable.
> > 
> > Option 4 is probably the most simple one to
> > implement, but has twice as much overhead
> > as Option 3.
> > 
> > As far as i got it, you are talking about the options 0
> > or 1: zero overhead, but an RTEMS API only solution.
> > 
> > Please forget about Option 2: it is
> > IMHO only of academical interest :-)
> > 
> > Comments?
> > 
> > Bernhard
> > 
> > --
> > Bernhard Kuhn, Software Engineer, Lineo Inc. (Where Open Meets Smart)