[ECOS] few doubts related to delay_us implementation

sandeep shimple0@yahoo.com
Mon Sep 27 15:22:00 GMT 2004


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



More information about the Ecos-discuss mailing list