[rtai] RTEMS RTAI module

[Bernhard Kuhn]

Joel Sherrill schrieb:

> I have dug through the RTAI page and don't seem to be able to
> find the magic page to describe their HAL.

There is a description about how to basicaly implement
the RTHAL. You can find it at

http://www.aero.polimi.it/projects/rtai/dissect.htm

But the problem is that although this paper tries to
descibe all the magic in detail, you will have to
get more familiar by just reading the source code!



> I understand the basic structure but would like
> to see precisely what had to be glued together.

Trust me: reading the source code is more descriptive
then ten times more documentation about it - disliked fact,
but true :-)



> > You mean having RTEMS running as an application on top
> > of RTAI similar to RTEMS for Linux in user space?
> > Sounds interessting.
> 
> And I suspect not terribly difficult once you knew precisely
> what the mapping of a BSP to the RTAI was.

I once put my nose into the BSP-layer of RTEMS and when remembering
those days, i would admit: doing an RTEMS-BSP for RTAI
shouldn't be much more complex then doing an
Native Linux RTEMS-BSP ... but certainly would take some
little amount of time :-)

A cracy idea: iirc, the Native-Linux BSP is based on a
somewhat POSIX compliant interface. So it could basicaly
rather easy to get RTEMS running on top of the POSIX
module of RTAI. But then, you would have an API wrapper
on top of an API wrapper :-) I could imagine that
a lot of people would not like this architecture, but
when looking at the performance the CPUs are nowerdays
providing, this "double whopper^H^H^H^H^H^H^Hwrapper
architecture" wouldn't be a real problem.

Doing the port this is probably be much easier to
implements than placing RTEMS directly on top of RTAI,
giving this project a quick start. If it shows up
that a lot of ppl are interessted in that feature,
then doing the additional work (to get rid of the
POSIX layer) is only an optimisation task (which usualy
shouldn't be done according to the first rule of
optimisation :-)



> > My former thoughts were having
> > RTEMS as an alternative to RTAI on top if the RTHAL,
> 
> I think this would be quite interesting to do and
> offer a neat environment.

But is *much* more time consuming to implement and IMHO
wouldn't be widly adopted, because there are already
industry capable solutions out there for years
(namly RTAI and RTL).



> > BTW: i recently had contacts with developers at
> > OAR and it seems that they like to implement a
> > oneshot mode scheduler ...
> 
> You and I had some private email about this

I real apologise if i accidently published some business
secrets, but our discussion didn't gave me the impression
that this is something that has to be keept secret ...



> My first thought was that
> the existing rtems_clock_tick() would indicate
> the periodic amount and be a wrapper over something
> like rtems_clock_tick_variable( nanoseconds ).
> There would have to be some work in the Watchdog and
> probably clock tick handling code to handle the difference
> between counting ticks and counting nanoseconds.
> And there would have to be a callback to the clock tick
> driver to set the varying timer period.

IMHO, having RTEMS "as is" on top if RTAI would be
fine for most users: if somebody realy needs oneshot
mode tasks, then he can use them on RTAI level
(but the resulting code it is certainly not portable
to RTEMS-only platforms)

> I really don't think it would be that bad a task.
> Probably outside my unpaid free time right now. :)

Feel free to do so :-) :-)

(i'm also interessted in getting RTEMS running on top
of RTAI, but i cannot promise to assist doing the job)



> > BTW: at the research institute i worked for a while,
> > we started running RTEMS in parallel with Linux
> > on an SMP box, means: one CPU is fully dedicated
> > to RTEMS, (ab)using it's 512 KB Cache as RAM.
> > No TLB invalidation and no Cache flushing :-)
> 
> This is cool. Is there info on the web?  published papers?

I recently had contact with my former colleague Thomas Hopfner
(Project leader of the before mentioned project and
Ph.D. at the Institute for real time computer systems,
located at the Technical University of Munich).
He sent me an URL describing the current status:

http://www.rtcpu.org/

Here, as well: didn't had the impression that this
is secret information - otherwise, i apologise :-)

best regards

Bernhard Kuhn

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