Re: [ECOS] RedBoot network timer question

[Hugo Tyson <hmt@redhat.com>]

Grant Edwards <grante@visi.com> 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