This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
few doubts related to delay_us implementation
- From: sandeep <shimple0 at yahoo dot com>
- To: ecos-discuss at ecos dot sourceware dot org
- Date: Mon, 27 Sep 2004 19:44:28 +0530
- Subject: [ECOS] few doubts related to delay_us implementation
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