From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hugo Tyson To: ecos-discuss@sourceware.cygnus.com Subject: Re: [ECOS] RedBoot network timer question Date: Fri, 19 Jan 2001 10:45:00 -0000 Message-id: References: <20010118170204.A10344@visi.com> <20010119102739.B10765@visi.com> X-SW-Source: 2001-01/msg00348.html Grant Edwards writes: > On Thu, Jan 18, 2001 at 04:35:42PM -0700, Gary Thomas wrote: > Right. That's how my hal_delay_us() routine works: it monitors > a hardware timer. But, it doesn't return until the timer times Which is a good implementation. > out, so no other code is running during delays. (unless it is preempted by a clock or timer interrupt, I assume) > Do some implementations of hal_delay_us() call some sort of > "idle task" routine that does tcp_polling or other useful stuff > while waiting for the timer to time out? I looked at most of > the other ARM hal sources before I did mine, and all of the > hal_delay_us() routines just sat in a loop until the requested > amount of time had passed -- none of them called anything. AFAIK they all just loop. They're intended for use only with small numbers, y'know? Ie. where lame device hardware documents that valid status will only be available 8uS after the select register is diddled. Or for doing the timing pulses for driving-by-hand a nasty serial EEPROM that holds a MAC address for an ethernet interface. That sort of thing. Where the busy-wait doesn't matter for such short times. I suppose one could argue that there's a functionality gap in that we don't support an efficient (ie. yields the CPU) wait in the 100uS-1mS range. But OTOH, is there a need? Usually it's either retry timeouts that are in the RFC as whole seconds, or dodgy hardware that needs its hand holding very closely in the few uS scale, in my experience. - Huge