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

[gregory.menke at gsfc.nasa.gov]

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

Gregm