bsp_delay.... Question

[Sebastian Huber]

On 04/25/2011 10:24 PM, Eric Norum wrote:
> Sure, but having a nanosecond resolution on the delay doesn't mean that you should actually expect to get this in all cases.  
> 
> I suspect that the man page for this routine would have to discourage its use and to specify that the actual delay could be -10 to +5000% of the requested value since some (many?) implementations might just use a busy loop and would be at the mercy of difference clock speeds, intervening interrupts, etc.
> 
> I think that rtems_bsp_delay_nanoseconds is the right resolution.  I'm not sure about the 'delay' part of the name, though.  Perhaps 'spin' or 'loop' might be a better indication of what the routine actually does.

In Linux it is called {m, u, n}delay().  In FreeBSD we have DELAY() which uses
micro seconds.  Why use an implementation detail for the name on RTEMS?
Constructs like rtems_bsp_*() make no sense.  Either it is available on all
BSPs and thus BSP independent or it is BSP specific.

> 
> On Apr 25, 2011, at 1:17 PM, Andrei Chichak wrote:
> 
>> Alright, I'm going to have to advocate for the little guy.
>>
>> At 16Mhz, I would have, at best, 16 instructions at a microsecond.
>>
>> A millisecond based delay would be doable using a timer. I could see crafting a loop for a microsecond delay, but nanosecond would be a summer fantasy. 
>>
>> Andrei
>>
>>
>> On 2011-April-25, at 12:49 PM, Joel Sherrill wrote:
>>
>>> On 04/25/2011 11:49 AM, Thomas Doerfler wrote:
>>>> Joel,
>>>>
>>>> without looking into the existing implementations: I would prefer to
>>>> have nanoseconds as a base unit. If we think about systems in the 1GHz
>>>> range, having a resolution of 1000 CPU clocks seems a bit outworn to me.
>>>>
>>>>
>>> I agree with you Thomas but the existing implementations appear
>>> to be in microseconds.  The common name is rtems_bsp_delay().
>>>
>>> I wouldn't be opposed to adding an rtems_bsp_delay_nanoseconds()
>>> to the set.
>>>
>>> Jennifer and I were just looking at this.  The non-uniform nature
>>> of this across the BSPs is confusing.
>>>
>>> --joel
>>>> wkr,
>>>>
>>>> Thomas.
>>>>
>>>> Am 25.04.2011 18:02, Joel Sherrill wrote:
>>>>> Hi,
>>>>>
>>>>> Some BSPs have a bsp_delay method.  This is
>>>>> a short duration spinner.  We think it is in
>>>>> microsecond units but have no idea for sure
>>>>> and it could vary by BSP.
>>>>>
>>>>> Jennifer and I would like to formalize the
>>>>> definition of this.  And standardize it across
>>>>> BSPs.  So if it is available, it is safer to
>>>>> use. Questions are
>>>>>
>>>>> + OK to make a standard BSP method?
>>>>> + Microseconds unit?
>>>>>
>>>>> If it is not available, what should the stub do?
>>>>>
>>>>> Should we have bsp_delay_usecs() and bsp_delay_nsecs?
>>>>>
>>>>> Comments appreciated!  Please
>>>>>
>>>>
>>>
>>>
>>> -- 
>>> Joel Sherrill, Ph.D.             Director of Research&  Development
>>> joel.sherrill at OARcorp.com        On-Line Applications Research
>>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>> Support Available             (256) 722-9985
>>>
>>>
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>>
>>
>>
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
> 


-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.