Re: [Emc-developers] Step generation in EMC...

[<jmk...@at...>]

Kim wrote:
> On Wed, 2003-11-26 at 10:21, jmk...@at... wrote:
> 
> > The GUI and the G-code interpreter and some other non-realtime stuff
> > are Linux user space processes.  They run using the CPU cycles that
> > the RTOS gives to Linux while the realtime stuff is sleeping.
> 
> OK.  Is the RTOS process running in kernel space or in user space ?

The RTOS and the realtime tasks are in kernel space.
 
> What command(s) is/are used to allow the RTOS process to give up
> processing time to the background tasks ?  Ie sleep() ? Or a variant
> thereof ?

It's an RTOS call.  You can't use sleep() or other Linux system calls
within realtime tasks.  Remember, they are running below Linux.  The
exact call depends on the RTOS you are using.  EMC uses RTAI or
RTlinuxux, and the calls are rt_task_wait_period() for RTAI and
pthread_wait_np() for RTLinux.
 
> What code module is this stuff implemented in ?

The realtime stuff is in emcmot.
 
> > > BTW: What sort of interrupt latency is associated with these RT OSes ?
> > 
> > >From less than a microsecond to a few tens of microseconds, depending
> > on the hardware and software mix.  Typically single digit microseconds.
> 
> Is the precision of the return to the RTOS better than this ?

Huh?  Latency is the time from when the hardware interrupt happens
until the first instruction of your realtime task executes.  Usually
your first instruction is the one immediately after your previous 
call to rt_task_wait_period().

The return to the RTOS happens whenever your code gets around to calling
rt_task_wait_period() again.  That may be very fast if your task has
nothing to do at this time, or many microseconds if the task has lots
of work to do.

John Kasunich
> On Wed, 2003-11-26 at 10:21, jmk...@at... wrote:
> 
> > The real time tasks run "below" linux - in other words, the RTOS is a
> > whole 'nother operating system that controls the CPU.  Realtime tasks
> > are managed by the RTOS, and Linux itself is the "idle task" of the
> > RTOS - Linux runs only when the real time tasks are idle.
> 
> OK.
> 
> > All the real time tasks are periodic - they never run for an extended
> > period of time.  Instead, the RTOS wakes them up at specific intervals,
> > they do whatever needs done at that time, then they go back to sleep
> > to allow lower priority tasks (including Linux) to run.
> 
> OK, understood. 
> 
> > The GUI and the G-code interpreter and some other non-realtime stuff
> > are Linux user space processes.  They run using the CPU cycles that
> > the RTOS gives to Linux while the realtime stuff is sleeping.
> 
> OK.  Is the RTOS process running in kernel space or in user space ?
> 
> What command(s) is/are used to allow the RTOS process to give up

> processing time to the background tasks ?  Ie sleep() ? Or a variant
> thereof ?
> 
> What code module is this stuff implemented in ?
> 
> > > BTW: What sort of interrupt latency is associated with these RT OSes ?
> > 
> > >From less than a microsecond to a few tens of microseconds, depending
> > on the hardware and software mix.  Typically single digit microseconds.
> 
> Is the precision of the return to the RTOS better than this ?
> 
> > John Kasunich
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program.
> > Does SourceForge.net help you be more productive?  Does it
> > help you create better code?  SHARE THE LOVE, and help us help
> > YOU!  Click Here: http://sourceforge.net/donate/
> > _______________________________________________
> > Emc-developers mailing list
> > Emc...@li...
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> -- 
> Kim Lux <lu...@di...>
> 
> 

> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers