From: "Edmund Horner" <ejrh AT paradise DOT net DOT nz>
Newsgroups: comp.os.msdos.djgpp
References: <8qhoe0$6rt$1 AT nnrp1 DOT deja DOT com>
Subject: Re: fast access to parallel port
Lines: 38
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Organization: Paradise Net
Message-ID: <969714523.473820@shelley.paradise.net.nz>
Cache-Post-Path: shelley.paradise.net.nz!unknown AT 203-79-93-177 DOT tnt11 DOT paradise DOT net DOT nz
X-Cache: nntpcache 2.4.0b5 (see http://www.nntpcache.org/)
Date: Sun, 24 Sep 2000 01:11:25 +1200
NNTP-Posting-Host: 203.96.152.26
X-Complaints-To: newsadmin AT xtra DOT co DOT nz
X-Trace: news.xtra.co.nz 969714524 203.96.152.26 (Sun, 24 Sep 2000 01:08:44 NZST)
NNTP-Posting-Date: Sun, 24 Sep 2000 01:08:44 NZST
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

do some test timing at the start of the program to determine how long it
takes.  then use that data to have your own super-optimised timing loop.
once you know how long it takes for one iteration, you can make the loop go
for x milliseconds without needing to call any clock functions.

does this make sense?

<danspam2000 AT my-deja DOT com> wrote in message
news:8qhoe0$6rt$1 AT nnrp1 DOT deja DOT com...
> I am working on a project that requires accessing
> the parallel port as a means to generating a data
> stream according to a pre defined standard. That
> standard dictates that the length of any one bit
> of data within the packet should be four micro
> seconds long. This means that i have to write to
> the parallel port and hold it high or low for
> four microseconds at a time. This is not a
> problem, as one cycle of the bus, running at 1.3
> MHz gives me plenty of time. Also, the uclock
> function in DJGPP is accurate to less than 1
> microsecond, so i should be able to use that for
> the timings. The problem is, that by the time
> i've called uclock, written to the port and
> called uclock again, even using register
> variables takes about eighteen uclock ticks,
> which is about three times longer than i can
> allow. Does anyone know of a way around this?
> Perhaps coding in assembler would speed the whole
> process up enough to work? Any help or pointers
> in the right direction would be appreciated.
> Thanks,
> Dan
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.