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.

- Raw text -