bsp_delay.... Question

[Gedare Bloom]

On Tue, Apr 26, 2011 at 2:32 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> 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.
>
The current name (thus convention) is rtems_bsp_delay. My feeling is
that if this function is standardized across all bsps, it should be
named simply bsp_delay, bsp_delay_nanoseconds, bsp_spin, or
bsp_spin_nanoseconds.  Since "delay" is used in the kernels cited by
Sebastian, I don't see the name delay as much of an issue here.

bsp_xxx matches the other rtems-bsp interface functions that are
defined in libbsp/shared. I'm not sure any functions in libbsp should
even have rtems_bsp as leading names.

>>
>> 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.
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>