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:

    Oyvind> Q: As near as I can tell, HAL_DELAY_US() is not thread
    Oyvind> safe in at91_misc.c. Is this correctly observed?

    Oyvind> I can't tell by reading the eCos documentation whether or
    Oyvind> not hal_delay_us or HAL_DELAY_US is supposed to be thread
    Oyvind> safe.

    Oyvind> http://sources.redhat.com/ecos/docs-2.0/ref/hal-interrupt-handling.html

    Oyvind> The implementation of I2C uses hal_delay_us, but since I'm
    Oyvind> not currently using that code(our home rolled I2C code has
    Oyvind> not been phased out yet), I'm not sure whether or not
    Oyvind> interrupts are disabled while hal_delay_us() is invoked
    Oyvind> inside the I2C code.

The actual definition of HAL_DELAY_US() is in
http://ecos.sourceware.org/docs-latest/ref/hal-clocks-and-timers.html
It lists the macro as optional and does not address thread-safety.
There are still some architectures where it has not been implemented
including the synthetic target, sparc, sparclite and v85x.

There are two main ways of implementing HAL_DELAY_US(). The first is a
counting loop, typically written in inline assembler, using an outer
loop for the microseconds and an inner loop that consumes
approximately 1us. With a bit of experimenting it is usually
straightforward to get this to within a couple of percent of the
desired delay. The implementation is automatically thread-safe and
does not require manipulating any hardware, disabling interrupts, or
anything like that. If the thread happens to be timesliced or
preempted by a higher-priority thread in the middle of the busy loop
then the delay will be longer than intended, but that is always a
possibility anyway. This approach assumes the cpu clock speed is known
at compile-time and won't change. On the synthetic target it would
probably require reading /proc/cpuinfo during initialization,
extracting the bogomips rating, and using that to calibrate a busy
loop.

The second way is to use one of the hardware clocks, possibly the
system clock. Personally I do not like this approach, it adds a
dependency on the hardware and is vulnerable to other code
manipulating the clock. However currently this is the more common
implementation.

HAL_DELAY_US() is already used in various places, not just the I2C
bitbang code, for example the lan91cxx ethernet driver. It is
generally useful functionality. I would like to see the macro
definition upgraded to make it compulsory rather than optional, and
require the macro to be thread-safe. 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.

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