[rtai] RTEMS RTAI module

[Joel Sherrill]

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.

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?

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?
  + how do you debug the modules?
  
Thanks.

--joel


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)