Writing Driver (and usleep)

[Mike Burg]

In article <1991Apr15.184618.16105 at beaver.cs.washington.edu>, pauld at stowe.cs.washington.edu (Paul Barton-Davis) writes:
[Text deleted about already known quality (bwahah!) of AT&T docs]

> Furthermore, as for the tenmicrosecond() function - I have to say that
> I know of only one way of coding this. You can't use the clock, since
> must V/386 systems set HZ to be 50 or 60, which means 16 milliseconds
> between ticks right there. All you can do is to block all interrupts,
> and then go into a loop that should last for about 10msecs. Move your
> code to a 486 or some other compatible system and it may break.

Well, AT&T 386/486 kernels have HZ set to 100. So, it's a 1 millsecond
resolution.

As far as coding of the tenmicrosec() functions goes.. What happens, is when
the system is being booted, some part of the PIT (programable interrupt timer)
code starts one of the hardware timers, and caculates how many `null' loops
it can perform in a given time period (in this case,  one microsecond).
This "loop" counter is stored in some variable and used latter on by
tenmicrosec to provide a execution delay that is ten microsecond long 
(give or take a few nanoseconds). The code will "sleep" (burn the cycles ;-))
for the same period of time whether it's running on a 486 at 33mhz or a
386SX at 16mhz.


The real purpose of the function is not provide to a "exact" microsecond delay,
but to provide a fairly constant delay time to allow various hardware pieces
(video boards, comm ports, I/O boards, etc) "to settle" or setup after
programming.

> System V timing, like most of the system, sucks. If anyone knows of
> any other way to do this, let me know.

Release 3 timing is the pits... Release 4 timing is somewhat decent.
-- 
----------------------------------
Michael Burg -  Unisys/Convergent Corp.  Unix Intel Platforms Division San Jose
Phone: (408) 456-5934 UUCP: uunet!pyramid!ctnews!unix386.Convergent.com!mburg