Does rtems have a portable, sort-of calibrated time-wastingloop?

[gregory.menke at gsfc.nasa.gov]

Joel Sherrill writes:
 > 
 > 
 > gregory.menke at gsfc.nasa.gov wrote:
 > > 
 > > Joel Sherrill writes:
 > >  >
 > >  >
 > >  > "Eugeny S. Mints" wrote:
 > >  > >
 > >  > > Hi,
 > >  > >
 > >  > > On Tue, 25 Mar 2003 gregory.menke at gsfc.nasa.gov wrote:
 > >  > >
 > >  > > >
 > >  > > > Perhaps something like Linux's udelay- it doesn't have to be fast, but
 > >  > > > should cause the program to spin for the supplied interval.  It should
 > >  > > > not itself reschedule, so rtems_wake_after is out- and should be
 > >  > > > callable from an isr.
 > >  > >
 > >  > > Yes, seems it is 'rtems_bsp_delay()' macro. Each bsp should
 > >  > > define it in a custom way (because it is very dependent on
 > >  > > the clock speed of the target). I'm not sure, wether it is
 > >  > > callable from an isr but don't see any restriction for this.
 > >  >
 > >  > Since this routine is BSP dependent, it could end up not being
 > >  > callable from an ISR but that is not the intent.  It is intended
 > >  > to be a tight assembly loop or poll a HW counter/timer but should
 > >  > be callable from an ISR.  The only issue is killing time
 > >  > in the ISR.
 > > 
 > > I'm porting the Linux 3com driver and in a couple places it waits on
 > > the hardware- usually a quick test with a fallback to longer and
 > > longer intervals with either eventual success or failure.  I've not
 > > found any of these waits in the rx/tx isr yet- but theres not
 > > telling.  Its pretty hairy code in there..
 > 
 > Standard warning about porting Linux code to RTEMS applies here.  It is
 > GPL with no exception so can't be included in the RTEMS source
 > distribution.
 > Please use a BSD driver as your starting point.

Now you tell me.

Gregm