Hi folks-

Well, a couple of months ago, I finally upgraded to XP.
Usually I use linux or other 'nix for most of the stuff that
I play with.  I've heard horror stories on how the XP OS's
"take over" the I/O subsystem and really keep the APIs removed from the hardware.

However, I'm faced with a bit of a challenge and would like
to poll this group for any suggestions that you might have.

I'd like to "bit diddle" the parallel port on systems running XP. Further, since I've written other parts of the application in Perl, I'd like to write this little ap in Perl too.

Since I'm changing bits (and not printing), I'm posting to this group rather than tek-tips since I'm actually trying to  control hardware via the parallel port.  I'm hoping this group will be a better fit.

I've wandered through the net and found this particular perl module:
Device::ParallelPort::drv::win32

Those familiar with perl modules will hopefully recognize the format.  One can find it referenced at cpan.org.

My questions to the group:

1. Has anyone used this module (and how successfully) with
   XP and varients?

2. Does anyone have an alternative perl module that they
   might recommend (preferrably one that is already
   compiled for ActivePerl)?

3. Alternative APIs and other languages.  DJGPP version of
   C?

Thanks!

  Cheers,

    Rich S.

 

Is this a specific version of perl for NT/2K/XP? or was it brought over from some 9x/ME system?  The problem with NT/2K/XP is that direct access to all hardware ports is blocked and you have to go through drivers.  The API for it can be found in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/file_management_functions.asp

This has been around since the NT days so DJGPP should have support for it.  I use MingW which is similar - they both go through the GNU compiler.

You have to attach to the device using CreateFile.  It supports asynchronous I/O if you play around with the overlapped stuff.  It is painful to say the least.

My advice, if you want to experiment with hardware through the parallel port, get a cheap 2nd hand PC/laptop and put windows 95/98 on it and you can fire directly into the I/O ports.  I'm using a 10 year old 120MHz laptop for such things.  Absolutely brilliant - if I screw the OS, I just wipe it and start again.  If it has a network card, you can transfer the compiled stuff over the network.  Alternatively, if you still have DOS6.22, get MSWGCN.exe from Microsoft (free download).  That will enable DOS to talk to XP.

Hi xwb-

Thank you for the good advice and the link.  The perl version that I've been using was downloaded fresh from the active perl site.  I think (don't have the laptop handy) that it's 5.8.3 or thereabouts.  In any event, it was the latest stable version on the website.  I've used that particular "brand" of perl for a couple of years now when I've needed to do perl on the 98 systems that I play with.  Seems to work fine for me, and I've had not trouble with it on XP.  As a freebie, the price is right.

Yep.  I've peeked and poked with 98 for years myself.  I stopped at 98 for quite awhile and normally I'm quite "happy" with it.  

The app that I'm whomping up is not just for me, I'm hoping that others will find the app useful as well.  Since I can't assume that all the users will desire to "downgrade" or go to linux (even Knoppix), I painfully decided to bite the bullet (I almost typed byte....).  

A buddy of mine at a client uses DJGPP (darn, I *STILL* have  trouble spelling that), but we/they have already found that the peeking and poking had trouble with it.  When I was faced with doing the same thing there, I said screw it and went to linux and inb() and outb() 'ed the calls and had a very easy migration path for the little app that I was using. Don't get me 2rong.  I think that DJGPP is a fine package and is part of my toolkit.  I'd like to stay with perl for this portion of the stuff however, as the other parts of the app are written in perl and if other users want to do it, it would be easier for them NOT to have to download BOTH perl and DJGPP.  I'm planning on open source.

I too concur that it's nice to have a couple of old machines  kicking around.  I think I've got a dozen or so...... Many already dual boot linux and 98.  Here in the silly cone valley, my friends pass me their old systems (some of them as fast as 500MHz!) and these usually get wiped and a Fedora distro of some version gets put on them.  Usually it's NOT the techies, but the "normals" who are upgrading and don't know what to do with their old machines.......

My problem is that I'm pretty much a newbie when it comes to  XP.  I will certianly try your suggestions. I'm just a little timid when it comes to doing something with my one and only version of XP on my machines.  I've heard other horror stories of folks trying to wipe and re-install their XP systems with unfortunately, mixed results.

I'll look at MSWGCN.  Thanks!

  Cheers,

   Rich S.

Hi Folks-

Well, I answered my own question.  I originally did a google search on "XP parallel perl" and didn't get much of anything.

Then "Doh!" thought try: "XP inpout.dll parallel" and got the hits that I needed.  The Device::ParallelPort module references the inpout.dll driver.  Doesn't mention XP in the description.

inpout.dll however DOES mention that it runs with 98/NT/XP machines.

So, bit the bullet and installed it on my XP machine and it seems to diddle the bits as hoped.

Sorry for wasting space on the board, but hopefully this might help others.

  Cheers,

   Rich S.

Thanks for letting us know

Hi-

In the google search, there is a cute little tutorial from
a guy using perl to light up some leds.  Might be a hand
for others interested in doing the same.

http://ham.zonzorp.net:8080/tpm/slides/2006_01/index.html

as he points out: It's 100% geeky fun!

I am in no way affiliated with this guy.  Just ran across his link via google search.

Seriously, port writing and reading on PC's *IS* something that a lot of folks want to do.  Since I normally use linux, it wasn't an issue.

Anyway, if you do decide to look at the link above, and if you want to wire up a connector with a couple of LEDs, here's a little perl script that will rotate a lit LED through the first 4 data bit locations of the parallel port.

Enjoy.

  Cheers,

   Rich S.
--------------------------------------------------------
#!/usr/bin/perl
#################################################
# walk a one through a 4 bit field <0-3> on the
# data byte of the parallel port.
#################################################
use Device::ParallelPort;
my $port = Device::ParallelPort->new();
while (1){
    for($i=0;$i<4;$i++){
        $port->set_bit($i,1); #LED on
        select( undef, undef, undef, 0.05); #delay
        $port->set_bit($i,0); #LED off
        select( undef, undef, undef, 0.05); #delay
    };
}

An other -- related -- question:

working with an 800 MHz Pentium I measured the widths of
the IORW and IORD and both were about 1 microsec.

800 Tclk is a lot... What controls it? could I shoorten it ? How ?

Plesae read FAQ240-1032
WEB: <http://geocities.com/nbucska/>

Is that on PCI or ISA bus?

Hiya-

I'm guessing that with an 800MHz machine, that there might not
be an ISA bus on the motherboard.  Could be a PC104 bus,
though (PC104 is an ISA bus with a different form factor).

Certianly one could shorten the pulse with of the IOWR IORD
lines by gating against the 8MHz clock of the ISA bus. It
would be tough to shorten the duty cycle of the reads and
writes of the ISA bus however.  

You could certianly double the data rate by using the 16 bit
reads and writes specified by the ISA bus.

And I'm not too sure about the specs for doing a DMA
transaction with the ISA bus, sorry.

Hope that this helps.

  Cheers,

    Rich S.

Timegeist:
I have to check it.

Plesae read FAQ240-1032
WEB: <http://geocities.com/nbucska/>

Hi-

Well, here's the reference that I used (or another clone of it).  There isn't much free info on the ISA bus on the internet.  There are books on the subject, but they cost.

So, if you can settle with this information:
http://www.techfest.com/hardware/bus/isa.htm
http://www.techfest.com/hardware/bus/isa.htm#4.0

Was the best of the free bits of information.  

It would be wise to hook up a scope and get a ballpark feel
for the timing of your particular system.  For worst case design, assume a clock of 10MHz and double it..........

My experience with it was with PC104 as mentioned earlier. I  had only to deal with one particular interface and board design, so I didn't persue worst case timing analysis.  Just  made sure that I had a lot of overhead with my design for the particular motherboard (well, that's not really a motherboard in PC104 speak) I was dealing with.

Also, I was only worried about 8 bit reads and writes, no DMA, so the task was easier.

Hope that this information and the links above helps.

   Cheers,

   Rich S.

To quote from "Interfacing to the IBM PC", 2nd Ed. by Lewis C. Eggebrecht, Sams, 1990, (!)...

"The bus cycle is normally 4 clks in length, but the PC design automatically inserts an extra wait state clock called a TW clock.

Thus, in the PC, all I/O port write bus cycles are a minimum of 5 clocks, or approx 1.05us in a 4.77MHz machine.

In higher clock rate PCs or XTs, additional wait states are added  to maintain the approximately 1us cycle."

Seems like nothing much has changed in the last 20 odd years then...