Newsgroups: comp.robotics
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!europa.eng.gtefsd.com!library.ucla.edu!csulb.edu!csus.edu!netcom.com!jonk
From: jonk@netcom.com (Jonathan Dale Kirwan)
Subject: Re: Parallel Port Transfer Speed?
Message-ID: <jonkCvLopH.GD5@netcom.com>
Organization: New World Computing Services
X-Newsreader: TIN [version 1.2 PL1]
References: <3490v9$ob6@news.doit.wisc.edu>
Distribution: na
Date: Sun, 4 Sep 1994 10:20:05 GMT
Lines: 80

Jim Vannes (jvannes@vms.macc.wisc.edu) wrote:
: I am interested in using the parallel port for digital input, and 
:   .
:   .
:   .
: This routine works fine, but the data transfer rate is still only 
: 400 KHz. What is going on here?  

: Does QuickC do such a great job of optimizing that the assembly 
: code is not faster? I am not aware of a way to get QuickC to make 
: an .asm file to show me what it did.

: Is something limiting the transfer rate?  Should I turn off 
: interrupts?  Does the parallel card hardware limit speed? Are 
: some better than others?

: I am measuring the transfer rate by feeding one of the status 
: bits with a 100 KHz. clock, plotting the waveform, and counting 
: the samples per cycle.  I am reasonably sure of my speed 
: measurements.

: I have read the excellent Parallel Port FAQ by Zhahai Stewart, 
: however there is no discussion of speed.  This strikes me as a 
: fairly important limitation to be understood.

: I have reviewed some of the commercial digital I/O cards, and the 
: fastest (Metrabyte) is 400 KHz., and this only with DMA!

: Has anyone relevant experience?  What are the tricks of getting 
: 800 KHz?   

The INSB instruction uses a 6-cycle bus transfer mechanism, since all 
8-bit I/O transfers take place using the same method, with IOCS16 in the 
high state throughout the transfer.  On the secondary ISA bus running at 
8 MHz, typically, the transfer takes 6/8 uS or 750 nS.  That is certainly 
one of the limitations for transfer rates, even using the fastest 
available instruction, which is INSB.

There are _no_ wait-state delays in the parallel port circuit that I am 
aware of (and I have most of the circuit diagrams for the discrete 
designs from IBM.)  That should not be the problem.

This leaves the interrupt system in the PC as a possible source of 
interference, though I'd expect you to get spotty results, rather than a 
smooth 400 kSps, if this was the problem.  But it must cause you some 
problems anyway, so....

The PC will develop timing events via an active timer that interrupts 
every 18.2 ms (about) and from a CMOS interval timer when it is active.  
The keyboard, disks, video adapters, and just about anything else can 
also generate interrupts.  Any one of which will obliterate one 
assumption you may be making about the data you collect -- namely, that 
the time period between adjacent samples is a constant.  It is most 
definitely not true if you leave the interrupts enabled while you take 
data.

So, try shutting of the interrupt system, use your INSB instruction to 
gather the data, then re-enable the interrupts (to heck with the time-of-
day) and check the results again.

Another place is to check your BIOS's advanced CMOS setup parameters.  
Many motherboards permit the bus speed to be set to several different 
values.  Some of them are quite slow.  If your ISA bus is operating at a 
slow clock rate and the I/O cycles take 6 of them, you might actually 
find yourself with 400 KHz, although I admit that does seem to be 
stretching it a bit, trying to explain 400 KHz that way.

Overall, though, your time-of-day interrupt should be using less than a 
few percent of the total CPU time available.  I wouldn't expect to be 
able to explain your slow rates that way.

If you still have problems, E-Mail me and I'll develop a test routine here
to prove out the limitations.  I suspect, though, that you'll find the
real culprit in your coding.  The bus rates alone cannot explain your
results, the timer events and other latencies alone cannot explain them,
the parallel port hardware cannot explain them, so that leaves your code,
I believe. 

Jon K

