Mail Archives: djgpp-workers/1996/10/08/02:30:22
On Mon, 7 Oct 1996, John M. Aldrich wrote:
> Well, I'm not entirely sure why it's necessary to wait between port
> calls in the first place, but is the timing that critical?
Yes, timing is important when accessing I/O ports. Most modern CPUs can
run circles around the slow peripherals, so if you don't wait a bit, you
might get garbled data (because the peripheral didn't yet assemble it).
My references suggest waiting about 1 microsecond between 2 accesses.
Usually you will find a small assembly function that just loops for a
while, but that immediately plunges you into CPU-dependency, and I didn't
want to mess with that in my small hack thrown together during a lunch
break.
> As I recall,
> sleep() works in millisecond increments, right?
I didn't want a function that requires a timer tick before it gets out of
`sleep' (`sleep' reads the BIOS timer). When I wrote the code, I was a
bit scared by the warning about disabling interrupts (which I can't from
a DPMI program), so I preferred something that will wait for much less
than 50 msec. Btw, `sleep' works with a second resolution; `usleep' uses
a microsecond resolution, but since both call `clock' (which reads the
BIOS timer), you cannot wait for less than 1/18.2 of a second, unless I
missed something.
> Actually, another
> program I have uses a routine for microsecond timing, using the
> functions in <sys/time.h>;
Well, what's wrong with `uclock' which I used? It does just that: read
the 1.19 MHz clock counter. That gives you 800 nsec resolution.
- Raw text -