[ECOS] few doubts related to delay_us implementation

[sandeep <shimple0 at yahoo dot com>]

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?

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

...........
       } 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++);
...........
}

regards
sandeep


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