Re: [ECOS] hal_delay_us() patch to at91_misc + multithreading

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Oyvind" == =?ISO-8859-1?Q?=D8yvind?= Harboe <ISO-8859-1> writes:

    >> I would like to see the macro definition upgraded to make it
    >> compulsory rather than optional, and require the macro to be
    >> thread-safe.

    Oyvind> Makes sense. I2C seems to be based upon these assumptions. 

    >> I am happy to do a synthetic target implementation, but that
    >> still leaves other architectures where the macro would need to
    >> be added or fixed.

    Oyvind> How about calibrating a CPU counter loop implementaiton
    Oyvind> upon startup using the default hardware timer in the HAL?

    Oyvind> - a couple of ms to the startup time is a small price to pay for
    Oyvind>   a default implementation of a HAL_DELAY_US()
    Oyvind> - The HAL_DELAY_US() definition should state that the the accuracy
    Oyvind>   is not very good, but that it is guaranteed to wait at least
    Oyvind>   n us.

Doesn't work for the synthetic target. The only easy way for the
synthetic target to read a clock is a gettimeofday() system call, i.e.
real time rather than process elapsed time. This would be fine if
there was nothing else running, but the synthetic target may get
preempted at any time including during this calibration loop. Hence
there is no guarantee the gettimeofday() values bear any resemblance
to the loop count. You could try doing the measurements several times
and picking the most sensible result, but at that level of complexity
you might as well read /proc/cpuinfo.

For embedded targets, often a couple of ms extra boot time is not
significant. But not always. There are systems which have a hard
requirement that some application code gets to run within a couple of
ms or less of power-up. Instead wherever possible the HAL_DELAY_US()
loop count should be determined during the porting process, not at
run-time.

    Oyvind> Is there a fundamental reason why HAL_DELAY_US() needs to
    Oyvind> be very accurate(i.e. say <20-30%)

It should not be less than the specified delay, give or take a couple
of percent. Device drivers can have fairly strict minimum intervals
between operations. Once interrupts are enabled HAL_DELAY_US() can
take arbitrary amounts of time longer than the specified delay, but it
is still a good idea to make it reasonably accurate. The usual
implementation is a polling loop during which no other work can get
done, making that loop use more cpu cycles than are absolutely
necessary is wasteful.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss