[rtai] RTEMS RTAI module

[Bernhard Kuhn]

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.

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

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


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

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)

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.

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)