[rtai] RTEMS RTAI module

[Bernhard Kuhn]

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)