[rtai] RTEMS RTAI module

[Joel Sherrill]

Bernhard Kuhn wrote:
> 
> Joel Sherrill schrieb:
> >
> > I think that RTEMS can
> > be "ported" to RTAI using option 1 described below.
> 
> Option 1 certainly offers minimum latencies, but
> probably takes more time to implement.

Definitely on minimum latencies but I don't know about 
time to implement.  It only takes a small handful of
services to port RTEMS.  If they need to touch real
hardware (say special CPU instructions), I can probably
leverage the other RTEMS ports.

> Another potential problem with option 1:
> if you have to modify rtai.c, then these
> changes have to be ported to the other
> supported architectures (ppc/m68k), as well. But the
> (unmodified) rtai_sched.c probably already offers
> all services you need to get RTEMS running
> on top of it (Option 3, architecture independent).

Yep.  But I am still investigating and designing so
I don't want to eliminate the most efficient version
jusy because it might be harder. 

I am considering everything from a close to metal RTEMS
to something more akin to how GNAT implements Ada tasks.
It maps each Ada task to an underlying OS entity thread/
task and implements its run-time with existing OS services.
This is definitely a viable option as well.  RTEMS then
would simply manage the RTAI tasks.

> But as you are the one who is willing to start
> the implementation, it's certainly up to you to
> make the decision :-)

:)  I have ported RTEMS about a half dozen times now
so expect that given the list of capabilities and a
way to play with them, I can quickly figure out how
to approach the problem.

> >   + simple RTAI environment under VMware, plex86, etc. for
> >     testing and not crashing entire machine.
> 
> I am not sure if VMware emulates all the hardware that
> is necessary ... never tried it myself along with
> RTAI - i'd like to hear your experiences :-)
> 
> At least, VMware certainly won't be hard real time capable.

Doesn't matter at first.  It is more than sufficient to
use printk and get a clock tick.  There is a lot of
debugging to get to that point.  And besides 99% of
RTEMS will work at that point.  The things that won't
be proven (e.g. networking) require special drivers.

> Instead of plex86, have a look at boochs (forrunner
> of plex86): this is a "real" PC-emulator, basicaly
> capable of doing cycle exact emulation, means
> you could even do hard real time stimuli emulation.
> But IMHO, boochs isn't prepared for doing such kind
> of development on top of it ...
> (also boochs development stopped after merging with
> freemware to plex86, and i don't know if it is still
> possible to do full CPU emulation with plex86)

As Erwin mentioned, he used bochs a while back.  Maybe
I should try it again.  

> My suggestion: get an old and cheap Pentium class PC with a few
> megabytes of RAM and set up a remote-boot/NFS-Root environment.

I will need a real target when it works but will stick with
emulation until then. Plus there will hopefully be multiple folks
working on this and I want us all to have unlimited HW. :)

> best regards
> 
> Bernhard
> 
> > > 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 3: RTEMS BSP for rtai_sched.c
> > > ------------------------------------
> > >
> > > Would operate just like the POSIX scheduler on top
> > > of the RTAI scheduler.
> 
> --
> 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