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

[Joel Sherrill]

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.

> Gregm