[rtai] RTEMS RTAI module

[Joel Sherrill]

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 agree it is a sometimes useful capability and once I
(or someone else) figure out how to add it without 
destroying the existing stuff, it is doable. :)

> > 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)

You gotta love having options. :)
 
> 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.

This sounds like a maintenance nightmare.

> Option 3: RTEMS BSP for rtai_sched.c
> ------------------------------------
> 
> Would operate just like the POSIX scheduler on top
> of the RTAI scheduler.

I think this is the option I have been considering.
There is no point in writing to the bare metal when
that stuff is already abstracted.  

What types of services does this give you?  

The short version of my mental design notes so far:


clock tick -- based upon existing timer services
interrupts -- map to existing infrastructure with
              preemption issue below.
console    -- call printk and friends.

Questions/Issues:

1.  Do we use native gcc/kernel gcc?
2.  Potential naming conflicts.
3.  Compilation issues.
4.  What does RTEMS idle task need to do to make
    sure Linux can run? :)
5.  How do we preempt from ISRs?  POSIX uses
    signals/setjmp, raw HW does register/stack tricks.
    I can see having an RTEMS wrapper for ISRs still to
    do some scheduling. 
6.  Is C++ ok in this environment?  If so, we will need
    to call constructors.


> 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.

Option 4 requires effort and I don't see it being
orders easier than 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?

This is getting enough mental cycles where it might happen. :)

Is it possible to boot the floppy system in plex86 and use that as
a target?

> Bernhard
> 
> --
> Bernhard Kuhn, Software Engineer, Lineo Inc. (Where Open Meets Smart)

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985