delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/09/27/07:14:32

From: Raul Kompass <kompass AT rz DOT uni-leipzig DOT de>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: fast access to parallel port
Date: Wed, 27 Sep 2000 11:53:51 +0200
Organization: Uni Leipzig
Lines: 48
Message-ID: <39D1C3AF.9301F233@rz.uni-leipzig.de>
References: <8qhoe0$6rt$1 AT nnrp1 DOT deja DOT com>
NNTP-Posting-Host: pmi18.isdn.uni-leipzig.de
Mime-Version: 1.0
X-Trace: news.uni-leipzig.de 970048589 554 139.18.110.83 (27 Sep 2000 09:56:29 GMT)
X-Complaints-To: usenet AT news DOT uni-leipzig DOT de
NNTP-Posting-Date: 27 Sep 2000 09:56:29 GMT
X-Mailer: Mozilla 4.6 [de] (Win98; I)
X-Accept-Language: de
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

In general the speed of parallel ports on different computers may vary.
The simplest thing would be to write out to the parrallel port, then to
a dummy I/O address then to the parallel port again, to dummy and so on,
until 4 us have passed, when you write out zero once. Use uclock to
determine the time for the sequential I/O accesses.
Do everything with interrupts disabled, otherwise sometimes the timer
interrupt will happen in the middle of your I/O cycle and you have a
signal about 50 us long.

The pentium processors have counters to read the time very fast and
accurately. If you have a pentium the best would be to use that.

Alternatively you may strip everything from the uclock function except
the CMOS timer readout as you only need times below some milliseconds.
This may still be too slow for you. Still you have to disable interrupts
for the whole process of writing your data , waiting and writing the
defoult again.

Raul

danspam2000 AT my-deja DOT com schrieb:
> 
> 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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019