Solved

Device Driver for LPT1

Posted on 1997-07-31
4
236 Views
Last Modified: 2013-12-03
I have written a delphi code to access my parallel port. However, I could only get 200K bytes per second from my CCD camera. Will a device driver speed things up? The QuickCam camera seems to be doing at least 600K bytes per second.

If a device driver is the way to go, how hard is it to write one for my application? Can I convert my ASM code to a VxD code?

Kind Regards
Keith
0
Comment
Question by:keithcsl
  • 2
  • 2
4 Comments
 

Accepted Solution

by:
kkp earned 50 total points
ID: 1402588
If you aren't running it on win95, I don't know, but I have done some experiments on '95. (My app was a portable IDE drive).

The parallel port is one of the least-protected hardware devices in '95. No traps are generated when writing directly to the port.
My experiment, performed before writing this:
win95: REP OUTSB to the port:  820-1060KB/S, depending on ISA clock. Same result in clean DOS.
IF you are using the port in EPP mode, be aware that an external wait/busy signal is fed back into the port from the CCD control logic, and thus has control over the maximum data rate. (What mode ARE you running? SPP/bidirectional, EPP or ECP?)

From your 200K data rate, it sounds as if you are manging the
strobes manually, so that your code looks like this:
  Strobe high
  Strobe Low
  Get Data
Or, if the port isn't configured as bidirectional, you may be reading 4-bit chunks, dropping the data rate further.
On a PC with a fast ISA clock, the approximate-upper-limits
for data rate are (when using two clock edges pr. cycle):
STD. unidirectional, 4 bit readback: 200KB/S
PS/2 bidirectional, 8 bit readback: 400KB/S
EPP bidirectional, 8 bit, immediate acknowledge: 1MB/S
ECP parallel: ? 1MB/S (not personally tested)

Probably your CCD driver uses EPP access. If you aren't, get IBM technical reference and do so also. If you need to use ECP mode, THEN you need to write a VxD. Porting ASM is not difficult if you can find a skeleton.
0
 
LVL 1

Author Comment

by:keithcsl
ID: 1402589
I am running in Win95. And yes, you are right, the slow rate of data transfer is because of manual strobes:
Strobe high
Strobe low
Read Data

and the configuration is bi-directional mode, 8 bit.

According to you answer, I can use the EPP bidirectional, 8 bit immediate acknowledge with a transfer rate of 1M/S. I would like to use this mode on my CCD camera. Are the pin configurations for EPP the same as for the bi-directional pin config? Can I use my same instructions to get the data?

And no, my CCD camera does not have a driver. I have to communicate with it directly. The protocol to access the data is as described above,
Strobe high
Strobe low
Read Data

The CCD has a DSP to transmit data at a very very fast rate. i am writing the DSP code to transmit/receive data to/from the PC. This means that I have total control over the CCD camera to do what I want. If the EPP mode is different from the bi-directional mode, this means that I have to change the protocol in the DSP to suit the EPP mode. Do you know the difference between the 2 modes?

The only problem is the PC is too slow to get the data (in bi-directional mode). I think if I use the EPP mode, I should be able to get data at a much better rate.

OK, where should I go from here? Do I still need to write a device driver? Currently,
- data is accessed from the port directly in Delphi.
- the port is configured in bi-directional mode
- data rate of 200K/S

Ideally, I would still like to use my Delphi code to read/write to the CCD, but at a faster rate. What do I have to change in order to operate in the EPP mode?
0
 

Expert Comment

by:kkp
ID: 1402590
No problem! My EPP knowledge comes from the IEEE P1284/D2 september 1993 unapproved draft marked DS02709, but to my experience it is valid.

I'll try to explain how it works:
In EPP mode the port works like a bus port. it has two adresses, we'll name then DATA (base+3) and ADDR (base+4).
The physical pins are named nWrite (1), d0..d7 (2..9), Intr (10), nWait (11), nDstrb (14), nAstrb(17).

First, set all outputs (nWrite, nDstrb, nAstrb) high (electrically high measured at the physical pin). The DSP should respond with a low->nWait. This is the idle state.

Second, do a read of address [data]. nDstrb will go 0, and d0..d7 will go high impedance (simultaneously). Your DSP drives d0..d7, and responds high->nWait, WITHIN 10 uS of nDstrb-Low-edge. The data-setup-time-to-nWait-high is 0. The EPP will remove nAstrb, indicating that data has been fetched. (At this point, the ISA bus becomes 'ready' and data is returned to the x86) Your DSP floats its d0..d7 outputs and responds with low-nWait WITHIN 125* nS. (*My experience with my clone ports here is that the timing constraint is 10uS, meaning that the EPP also waits for nWait going active again. This makes sense, but I can't check it in the new spec before monday.)
The 10uS is a timer on the EPP which aborts 'never-ending-cycles', so that you can't hang the PC this way.

If the address used was ADDR instead, nAdstrb would have been set low instead.
If you WRITE to these two addresses, it will look like a read cycle, but data will be driven by the PC while nA/Dstrb is low, and the nWrite signal will be low from start (falling edge of nA/Dstrb) to finish (falling edge of nWait). Draw it on paper!

One last thing: Your DSP program should terminate a read if the EPP doesn't respond in 1 Sec (yes,10^6 uS!). This 1S comes from the spec. Otherwise a continous collision would occur, frying the weak end of the data bus. Also, BEWARE of capacitive wire-to-wire  capacitive coupling - use a 34 wire flat cable and 'fan' the cable at the PC connector. Otherwise you'll get bugged by glitches (I DID!).

Your delphi transfer code in asm will look like this:

MOV DX,portbase
ADD DX,3         //get to data port
MOV EDI, bufferpointer
MOV ECX, buffersize_in_byte
CLD
REP INSB         //get busy!
<end>

No manual strobes. Just speed. REP INSB does it all. And there's no reason to go VxD yet.
0
 
LVL 1

Author Comment

by:keithcsl
ID: 1402591
Thank you very much kkp. I feel very excited about using this EPP protocol. I have finished testing and debugging my bi-directional program and sadly, it could only run at a maximum rate of 2.6 frames per second. Very slow. If I follow according to your advise, I should be reaching near 15 frames per second!! I will start coding the software immediately.

Oh yes, I was wondering if I could reach you by e-mail if I bump into any problems with the EPP protocol. If possible, just mail me at:
 keithcsl@ihug.co.nz

If, not just tell me how I can contact you. Once again, thanks a million...

Kind Regards,
keith
0

Featured Post

MS Dynamics Made Instantly Simpler

Make Your Microsoft Dynamics Investment Count  & Drastically Decrease Training Time by Providing Intuitive Step-By-Step WalkThru Tutorials.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
Using MS Code on my Mac 6 72
Trouble with References... 5 62
SSRS Deployment problem 5 91
Starting to use Git with Visual  Studio Online 1 18
This article shows how to make a Windows 7 gadget that extends its U/I with a flyout panel -- a window that pops out next to the gadget.  The example gadget shows several additional techniques:  How to automatically resize a gadget or flyout panel t…
After several hours of googling I could not gather any information on this topic. There are several ways of controlling the USB port connected to any storage device. The best example of that is by changing the registry value of "HKEY_LOCAL_MACHINE\S…
This is Part 3 in a 3-part series on Experts Exchange to discuss error handling in VBA code written for Excel. Part 1 of this series discussed basic error handling code using VBA. http://www.experts-exchange.com/videos/1478/Excel-Error-Handlin…

713 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question