Re: [ECOS] few doubts related to delay_us implementation

[Nick Garnett <nickg at ecoscentric dot com>]

sandeep <shimple0@yahoo.com> writes:

> packages/hal/common/current/src/hal_if.c
> ----------------------------------------
> 
> static void delay_us(cyg_int32 usecs)
> {
>      CYGARC_HAL_SAVE_GP();
> #ifdef CYGPKG_KERNEL
>      {
>          cyg_int32 start, elapsed, elapsed_usec;
>          cyg_int32 slice;
>          cyg_int32 usec_per_period =
> CYGNUM_HAL_RTC_NUMERATOR/CYGNUM_HAL_RTC_DENOMINATOR/1000;
>          cyg_int32 ticks_per_usec =
> CYGNUM_KERNEL_COUNTERS_RTC_PERIOD/usec_per_period;
> 
>          do {
> ...........
> ### In each iteration, we accumulate additional time that we would be delaying
> ### extra, courtesy other processing than delay loop. for a larger requested
> ### usecs delay this could be significant.
> 
> ### interrupts  coming in b/w add further delay than requested usecs.
> 
> ### since scheduling can not be disabled during this call, isn't it possible
> ### that the caller thread gets scheduled out. the existing logic doesn't
> ### compensate for this, rather it does't consider this fact. this can lead to
> ### much bigger delays than requested usecs.
> 
> ### am I missing something very trivial here?
> 

There is no pretence that these microsecond delays are particularly
accurate. For short delay periods, just calling and returning from the
routine probably takes longer than the actual delay. These delays are
mainly used in device drivers where hardware needs short delays to
settle, or where we need to timeout a state change. That it may
occasionally take longer than expected is not an issue.

The function already accounts for losses caused by interrupts.
Compared to the delay period, any loss caused by preemtion is massive,
and there seems little point in trying to cope with it. The only real
alternative is to block interrupts while handling the delay. Which is
not reasonable.

> ### (eg. indirect call of delay_us in packages/io/flash/current/tests/flash1.c).

There is no such test as far as I can see. This is probably one of yours.

> 
> ...........
>         } while (usecs > 0);
>      }
> #else // CYGPKG_KERNEL
> ...........
>       while (usecs-- > 0) {
>           int i;
> 
> ### above int should be declared as volatile to prevent compiler from wiping out
> ### the delay loop, during optimisation??
> 
>           for (i = 0; i < 10; i++);

GCC doesn't optimize such loops out. If it did then both Linux and BSD
would fall into a heap.

-- 
Nick Garnett                    eCos Kernel 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