[rtai] RTEMS RTAI module

[Erwin Rol]

What Bernhard mentioned of using RTEMS on Posix on RTAI on the RTHAL was
not realy what i meant, but could be usefull too cause it most certainly
be "harder" realtime than the standard linux posix soft realtime layer.

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. 
And the speed of the PC can surely put the tick rate up rather high.
So thats just a mather of how you look at it, you don't want to port
RTAI aplications to RTEMS, nor do you want to port RTEMS applications to
RTAI, you want to run your RTEMS BSP on the PC, and maybe like RTAI
RTEMS could have some way to talk with Linux , and could use Linux for
logging to disc (without the need to port all the filesystem stuff and
drivers to RTEMS). And 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. I think this migth be very interesting for 
a next RTAI release (when there even has to be done something to RTAI)
and for a next RTEMS release to have a BSP that can be loaded under
Linux(with RT-HAL) as a module, even if it is just for testing. 

I will look into it next week. 

- Erwin

On 28 Aug 2001 13:41:25 -0500, Joel Sherrill wrote:
> 
> 
> Bernhard Kuhn wrote:
> > 
> > Erwin Rol schrieb:
> > 
> > > Hi did anybody ever think about for example using
> > > a other OSS RTOS as a module to run under RTAI ?
> > 
> > Yes, me :-)
> 
> It sounds interesting to me as well. :)
> 
> I have dug through the RTAI page and don't seem to be able to
> find the magic page to describe their HAL.  I understand the
> basic structure but would like to see precisely what had to 
> be glued together.
>  
> > > In principle it should be possible to have a BSP for
> > > RTEMS that ends up being a linux kernel module under RTAI.
> > 
> > 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.
> 
> > 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 i abandoned the idea, because RTEMS only offers
> > a periodic mode scheduler.
> > 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 and I don't 
> think it is tough to implement once one works out
> the details of not breaking compatability with the 
> existing code base.  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.
> 
> I really don't think it would be that bad a task.
> Probably outside my unpaid free time right now. :)
> 
> > With your idea, it realy means only to have to
> > provide an RTAI-BSP for RTEMS and everything
> > should work fine. This would certainly make
> > RTAI more interessting to other ppl out there
> > using RTEMS for quite a while.
> > 
> > best regards
> > 
> > Bernhard
> > 
> > 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?
>  
> 
> 
> 
> > --
> > 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