parallel port interrupt

This probably is not the best group to get computer people to answer but anyway.

I believe Widows XP (and maybe Windows 2000) does not give you direct access to the printer port hardware.

I cannot remember any details but given that you may be able to get a lead on your problem.

--
John G

Wot\'s Your Real Problem?

There are workarounds for the port-access problems (Google for 'PortTalk'), but I've never seen any code that uses the LPT port interrupt.

I'd say, if the event happens only a few times per second, latch it externally and use polling techniques to watch/reset the latch. If that's not adequate, use an actual data-acquisition rig. If you need hard realtime response, don't use Windows.

The PC parallel port is not long for this world.

-- jm

------------------------------------------------------

Note: My E-mail address has been altered to avoid spam

------------------------------------------------------

It's not implemented properly on many hardware platforms and the chances of getting actually to work are negligible.

Use a USB-connected ADC device like this:

for only $25. It can be programmed from VC++ or any other language for that matter.

Ironically I have a few 194s laying around here. Dataq is headquartered here in Akron. Thats not the problem. I actually have access to a lot of PCI data AQ cards. Ironically none of them have a direct IRQ line.

The problem is we are updating a system built many years ago and need to sync to a external cue that can come a few times per second but at random times. Sitting there watching a polled IO line in a loop is not going to meet our needs on timing jitter and has some other disadvantages. It needs to be Win 2K as the new spectrometer for the experiment only talks to Win 2K

Others have used the EPP port in older systems with good sucess, see

for a example of a par port based linear CCD driver with 2 megapixle throughput, but was using DOS mode under WIN 98.

Thanks, Steve

This problem likely won't find a good answer if the realtime component is required to run in Windows, you know. Win2K's latency is not well defined. Win XP Embedded comes closer to approximating an RTOS on paper, but of course falls well short of actual practicality. Problems with high-speed data acquisition in Windows tend to devolve to one of two solutions:

a) capture all possible parameters continuously at maximum speed using a high-speed buffered data acquisition card, and perform event analysis after the fact (not in realtime), or

b) use external hardware to synchronize external realtime events.

Having said all that:

What is the complexity of the external event to be sequenced - are you trying to start a sample operation at a given moment, or what?

How much jitter is acceptable?

If you are a masochist and you have the Win2K DDK (and appropriate build tools)

demonstrates how to acquire an IRQ in kernel mode. Passing this event up to the app layer is possible, there is a link on that same page to code that does it - not exactly the way I might have done it - try it and see if the latencies are acceptable.

This is assuming your port works as documented.

Highly variable. I was the software engineer many years ago on a parallel port audio device (similar to Covox Speech Thing or - in later incarnations - Disney Sound Source) and it was most educational dealing with the variety of technical support issues created by this fine piece of hardware. These days, with "intelligent" port controllers, life is harder.

Recall from the halcyon days of OS/2 that a large number of printing stability problems were caused by the fact that OS/2 actually USED the printer IRQ - since Windows didn't, people were shielded from the difficulties until they "upgraded".

Why not hook a small reed relay to one of the keyboard keys? I used that to have some response keys in an experiment.

I'm by no means a Windows expert, but I would guess you need to write a driver for that. Try asking in a windows programming newsgroup.

Kind regards,

Iwo

This should make the job easy:

You can also try it out free.

Paul Burke

I've spent several weeks investigating doing something similar. Many problems:

(1) Windows NT/2000/XP/Vista don't give you direct access to the parallel port hardware. You need something like "giveio.sys" add-on to get direct port access.

(2) Finding the port address can be very troublesome.

(3) There are at least three modes to the parallel port, all semi-compatible, and very incompatible in the low-level details.

(4) Almost every parallel port manufacturer adds a few helpful "features", which often confuse software expecting those bits to have different effects.

(5) Writing an interrupt-driven device driver is not for the faint of heart. They're hard to write and even harder to debug.

Wish I had some optimum solution but I don't.

I'd suggest

Unless you're completely replacing the PP driver, the best you can do is to use the Windows kernel to allow you to piggy back onto the normal driver. And yes, I've done exactly what you're asking about. But it's not easy and it requires kernel level programming because it's not something that Windows lets user-programs do. If you get the appropriate DDK (device driver kit) from Microsoft, you'll get enough samples of what you want to do to enable a competent kernel programmer to do it. But don't expect help from any part of VC's library.

Also, there are a few free installable device drivers available that allow a user-program to use the parallel port for any purpose whatever -- basically they've already done what you're trying to do at the data-level. It's possible that one of them might also allow you to piggy-back on the interrupt as well --- I've never investigated it because the requirements I had mandated kernel-level interactions with other parts of the system.

Norm

yes if you own a license for the DDK ( no it is not include with visualstudio) you will be able to freely build such an interface with interruption control, but of course buying microsoft DDK is (as all microsoft things ) very expensive .

If you find such a free driver with hook for the interuption, please post it here I'll be interested also :-)

Look at the URL I posted.

TVicLPT version 1.3 Worked, we compiled its IRQ Test demo today and hooked up a loopback plug from a data line on the port to pin 10, the interrupt. It only took 2 attempts at setting the bios and XP's device manager, and we saw it work with both the loopback and a external pulse generator. Probably would have gone smoother had I bothered to read the help file but we had it working inside of 30 minutes from download.

Now tomarrow's test is to see exactly how fast we can bang the IRQ on the 2.2 Ghz target machine. We will probably set up a pulse generator and a dual trace scope, and toggle a bit on the data lines every time we assert the IRQ, and see what the max truigger rate is. It might take us a while to code this, but the documentation looks good.

Thanks to all who replyed, including the naysayers :-)

Steve Roberts

TVicLPT version 1.3 Worked, we compiled its IRQ Test demo today and hooked up a loopback plug from a data line on the port to pin 10, the interrupt. It only took 2 attempts at setting the bios and XP's device manager, and we saw it work with both the loopback and a external pulse generator. Probably would have gone smoother had I bothered to read the help file but we had it working inside of 30 minutes from download.

Now tomarrow's test is to see exactly how fast we can bang the IRQ on the 2.2 Ghz target machine. We will probably set up a pulse generator and a dual trace scope, and toggle a bit on the data lines every time we assert the IRQ, and see what the max truigger rate is. It might take us a while to code this, but the documentation looks good.

Thanks to all who replyed, including the naysayers :-)

Steve Roberts

Google for "userport" ,the first one should do it. If you can add a little bit of electronics,like set/reset flipflop,you would not need interrupt. Set the printer port in the bios to SPP(Standard printer port),connect one ore more s/r outputs to one of the

5 inputs,and use one output to reset the FFs,after you read them. For a few per second,this needs only a small controller program keeping a wath on the port,and dispatch a task whenever it detects any of the FFs set, or to dump its results in a piece of shared memory or UDP package.

There are parallel port data loggers you can get for ~$30 in kit form. You can use a free application called userport to get hardware access on NT/2K/XP machines. I've got a page below that shows some simple parallel port stuff I set up on my XP pro machine. I've also done some tinkering with USB gamepad and joy stick adapters using just basic (free) and liberty basic (free trial) for getting data into a computer. Liberty basic also has easy acess to the parallel port. There is a lot of simple stuff you can do with the parallel port. I don't know about the visual C 6 as I just use simpler programming.

How about making the pulse bigger and applying it to the serial port? On older versions of Windows, the serial input would always get through the OS and to you code in under 47 days, if it was ever going to.

--
--
kensmith@rahul.net   forging knowledge

Really ?, i got it from MS for free, just had to pay the shipping etc.. of course you need the VC++ package to code the examples etc.. that you need to buy if you don't already have it.

--
Real Programmers Do things like this.
http://webpages.charter.net/jamie_5