Searching \ for '[EE]: Printer port control software' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/ios.htm?key=port
Search entire site for: 'Printer port control software'.

Exact match. Not showing close matches.
PICList Thread
'[EE]: Printer port control software'
2002\09\16@234525 by John Pearson

flavicon
face
I would like to control my printer port. Can anyone recommend a software for doing this. What I would like to do is to create text files that would look something like this:

00101001
00110001
01011100
10011001
10000100

Then be able to just send each byte to the printer port one at a time with a time delay between each byte. I will not be able to acknowledge each byte however. Just keep sending them.

Thanks

John

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\09\17@024642 by mpoulton

flavicon
face
QBASIC will do that...

---- Original message ----
>Date: Mon, 16 Sep 2002 20:36:47 -0700
>From: John Pearson <spam_OUTxeroTakeThisOuTspamCMC.NET>
>Subject: [EE]: Printer port control software
>To: .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU
>
>I would like to control my printer port. Can anyone
recommend a software for doing this. What I would like to do
is to create text files that would look something like this:
>
>00101001
>00110001
>01011100
>10011001
>10000100
>
>Then be able to just send each byte to the printer port one
at a time with a time delay between each byte. I will not be
able to acknowledge each byte however. Just keep sending
them.
>
>Thanks
>
>John
>
>--
>http://www.piclist.com hint: The PICList is archived three
different
>ways.  See http://www.piclist.com/#archives for details.
>
>
--
Mike P.
MTP Technologies
KC0LLX

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2002\09\17@095105 by Herbert Graf

flavicon
face
What OS, what development environment? TTYL

> I would like to control my printer port. Can anyone recommend a
> software for doing this. What I would like to do is to create
> text files that would look something like this:
>
> 00101001
> 00110001
> 01011100
> 10011001
> 10000100
>
> Then be able to just send each byte to the printer port one at a
> time with a time delay between each byte. I will not be able to
> acknowledge each byte however. Just keep sending them.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2002\09\17@162721 by Wagner R. Teixeira

flavicon
face
> I would like to control my printer port. Can anyone recommend a
> software for doing this. What I would like to do is to create
> text files that would look something like this:
>
> 00101001
> 00110001
> 01011100
> 10011001
> 10000100
>
> Then be able to just send each byte to the printer port one at a
> time with a time delay between each byte. I will not be able to
> acknowledge each byte however. Just keep sending them.
>
> Thanks
>
> John

Here's a little prototype. Call this way: PROGRAM.EXE < BITSFILE.TXT or
PROGRAM.EXE and type in the values (stop with ^Z).

Wagner

===
#include <windows.h>
#include <stdio.h>
#include <conio.h> // for VC

#define PARALLEL_PORT_ADDR      0x0378

void SendBase2String( char *szString )
{
  int nValue, nStrBit, nBitValue;

  for( nValue = 0, nStrBit = 0, nBitValue = 128; nStrBit < 8; ++nStrBit,
nBitValue /= 2 )
     nValue += ( szString[ nStrBit ] - '0' ) * nBitValue;

  _outp( PARALLEL_PORT_ADDR, nValue );
}

int main( int argc, char *argv[] )
{
  char szBase2String[ 16 ];

  while( fgets( szBase2String, sizeof( szBase2String ), stdin ) != NULL ) {
     SendBase2String( szBase2String );
     Sleep( 10 /* time_in_ms */ ); // Windows API
  }

  return( 0 );
}
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.386 / Virus Database: 218 - Release Date: 09/09/02

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2002\09\17@202358 by williams.engineering

picon face
I would use an external circuit which contects the nStrobe to a 555
timer to hold the nBusy signal high for a preset time.  Then just send
all you data it one Write() operation.  Then you don't have to worry
both OS system because it would work on any MS system including
NT4.0/2000 and XP.

Regards,

James


{Original Message removed}

2002\09\18@005927 by Mike Singer

picon face
  What development environment does so easily support
"Write() operation" under NT4.0/2000 and XP?

Mike.

James Williams wrote:
{Quote hidden}

John Pearson wrote:
{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspam_OUTmitvma.mit.edu


2002\09\18@044329 by ruben

flavicon
face
> Here's a little prototype. Call this way: PROGRAM.EXE < BITSFILE.TXT
> or PROGRAM.EXE and type in the values (stop with ^Z).
>
> Wagner
>
> ===
> #include <windows.h>
> #include <stdio.h>
> #include <conio.h> // for VC

-- snip--

This will only work for W9X operating systems. For NT/2000/XP you will need a driver.

Check out http://www.lvr.com/parport.htm

Ruben==============================
Ruben Jönsson
AB Liros Elektronik
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
@spam@rubenKILLspamspampp.sbbs.se
==============================

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2002\09\18@112827 by Tim McDonough

flavicon
face
On Wed, 18 Sep 2002 09:44:50 +0200, Ruben Jönsson wrote:
>
>This will only work for W9X operating systems. For NT/2000/XP you
>will need a driver.
>
>Check out http://www.lvr.com/parport.htm
>

Another commercial driver that supports parallel port and serial ports on various versions of Windows is I/O Active X Control from http://www.jspayne.com/

They have a fully functional demo so you can be sure it will work for what you want before buying. Price and licensing terms are very reasonable for what you get. I'm just a satisfied customer.

Tim

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2002\09\18@141408 by James Williams

picon face
All windows 32bit versions are easy to write to the printer port.  It can be
done with two API calls.  One to open a handle to the device: CreateFile(..)
and the other to Write your data out to the port.  WriteFile(...).  This
does 100% work under windows 95/98/me and Windows NT3.51/4.0/2000 and XP.
No problems.  The only criteria for it to work is that your device attached
properly utilize the nStrobe,nAck and nBusy signals according to
Compatibility mode.

I have sever devices which I have made and wrote nice windows programs for
them without having to write a special VXD or device driver.

It is realy simple.  Problem is people think it is hard or are not versted
enough with Windows HAL (Hardward abstraction layer) to take advantage.  You
can even read the signals from the port using DeviceIOControl(...) API
function even in NT/2000/XP.

Again you don't have to have any special things for this other than your
hardware follow the compatibility handshake.

Regards,

James


{Original Message removed}

2002\09\18@155907 by Peter L. Peres

picon face
On Wed, 18 Sep 2002, James Williams wrote:

*>All windows 32bit versions are easy to write to the printer port.  It can be
*>done with two API calls.  One to open a handle to the device: CreateFile(..)
*>and the other to Write your data out to the port.  WriteFile(...).  This
*>does 100% work under windows 95/98/me and Windows NT3.51/4.0/2000 and XP.
*>No problems.  The only criteria for it to work is that your device attached
*>properly utilize the nStrobe,nAck and nBusy signals according to
*>Compatibility mode.

Except if the attached device is not EPP compatible, like most hardware
done by amateurs.

What you suggest works fine for 'rough' hardware if and only if it uses
stb/ack and ready properly and the interface is set to SPP mode in the
bios and/or windows properties.

Peter

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu


2002\09\18@222205 by Mike Singer

picon face
James Williams wrote:
.
> All windows 32bit versions are easy to write to the printer port.
> It can be done with two API calls.  One to open a handle to
> the device: CreateFile(..) and the other to Write your data out
> to the port.  WriteFile(...). This does 100% work under
> windows 95/98/me and Windows NT3.51/4.0/2000 and XP.
> No problems.
.
.

 May be I'm missing something, but what these LPT-programmer
guys were talking about, when they said that their LPT-programmers
need special LPT driver under NT-like systems?

Mike.

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu


2002\09\18@225603 by williams.engineering

picon face
No, you are wrong it does not have to be EPP compatible.  Only SPP which
is compatibility mode, nStrobe signal, nBusy and nAck signals for write.
You can also do nibble read.  The point is it DOES NOT HAVE TO BE A EPP
device.  As long as your device does the following:
1.  Responds to an nStrobe negative pulse.
2.  Bring nBusy high in response to step one.
3.  Finally pulse nAck and bring nBusy low.

This is all that is necessary.

Regards,

James


{Original Message removed}

2002\09\18@230152 by williams.engineering

picon face
No, the computer does not have to have the port configured as SPP in the
bios or windows.
All my computers are set up as ECP mode in both bios and windows.  And
again it works 100% of the time all the time.

I have been pumping data out of the port at rates up to 200Kbytes/sec in
compatibilty mode and when in EPP mode 1Mbyte.  With on problems at all.

Also,  If a hobbiest or ameture can put together a PIC project to begin
with, they should be able to hook up nStobe, nBusy and nAck properly
with ease and if not then they really shouldn't be messing with logic at
all.

It is easier that standard RS232.

Regards,

James

{Original Message removed}

2002\09\18@231258 by williams.engineering

picon face
There are only a couple of reasons you might want a special LPT drive.
If you what to take advantage of the interrupt instead of polling.  Or
you want to take advantage of some kernal mode processing, which I can't
image why you would want to.  But the biggest reason is interrupt
handling and DMA control or special control over the standard signals.
In which case the device is not using any standard IEEE 1284 interface.
In such a case you would need a driver.

I have written both NT/2000 device drivers and I only write then when it
is necessary, otherwise I use the generic windows LPT driver, that is
what it is for to begin with.  If fact, when writing printer drivers,
you just write a driver which processes standard GDI functions like
DrawText, LineTo, etc and process then to a format in which your device
uses, then pass that to the spooler which goes write through the
standard LPT driver.  Imagine that.

I think the problem is that most people have gotten mislead when
controlling the LPT port under windows using standard API functions.
You can even read the signal states of the status pins just by calling
DeviceIoControl.

Finally, this is not something that would only be for a rough hardware.
This is done quite regularly with printer drivers.  The only difference
between the two, besides using the spooler, is that a printer driver
uses provides a shared resource for all applications to write to the
device.  This would be exactly the same as writing the same processing
code in your application.

I suggest some people you download and read some of the DDK from
microsoft.  You will gain a better understanding of the hole HAL of
NT/2000 and XP.  As for 95/98/me, I never write VXD because most of the
code must be written in assemble.



Regards.

James

{Original Message removed}

2002\09\19@045013 by ISO-8859-1?Q?Ruben_J=F6nsson?=

flavicon
face
If you go for the driver approach (which are available for free, you don't have to write any) you get 12 outputs (D0-D7, strobe, autofdxt, init and slctin) and 5 inputs (ack, busy, pe, slct and error) without any special hardware or jumpers attached to the lpt.

With CreateFile()/WriteFile() I have been told (haven't tried it) that by only tying busy and pe to ground and slct to +5V through autofdxt, you get 8 outputs (D0-D7). This will leave 2 inputs (ack and error) - which may be fine for a lot of things. So - how do I use DeviceIOControl() to read these? Any example source?

Ruben
{Quote hidden}

Ruben Jönsson
AB Liros Elektronik
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
RemoveMErubenspamTakeThisOuTpp.sbbs.se
==============================

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\09\19@082453 by James Williams

picon face
There is one catch with most of the driver's that you are talking about,
they all require you to be logged in as an administrator, which is realy
what I call an adhack approach to a driver.  I have looked at the drivers
offerred for free and they just don't appeal to me do to above mentioned
things.

I will send you an example later this evening on how to use DeviceIoControl
to read the signals from the LPT PORT.

Regards,

James


{Original Message removed}

2002\09\19@162341 by Peter L. Peres

picon face
On Wed, 18 Sep 2002, James Williams wrote:

*>No, you are wrong it does not have to be EPP compatible.  Only SPP which
*>is compatibility mode, nStrobe signal, nBusy and nAck signals for write.
*>You can also do nibble read.  The point is it DOES NOT HAVE TO BE A EPP
*>device.  As long as your device does the following:
*>1.  Responds to an nStrobe negative pulse.
*>2.  Bring nBusy high in response to step one.
*>3.  Finally pulse nAck and bring nBusy low.

Okay, I will try it out next time. But I see it as three pins on the
interface, wasted. There are only 13 of them so this is a significant
loss. I have made several parallel controlled devices in the past, that
cannot dispense with these three pins.

Peter

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\09\19@174956 by williams.engineering

picon face
Why don't you use the nibble read to read the data?  Or you could even
do a byte read.  It is strange to find people still using the status
pins to read data from a device.  Especially when you can do byte read
and nibble reads without sacrificing no less that 4 input pins.

Also, a better interface with multiplexing is a solution around the 13
pin limit.  I have not seen this as a problem.

{Original Message removed}

2002\09\19@230553 by Mike Singer

picon face
James,
Thank you very much.

Mike.

James Williams wrote:
{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\09\20@032549 by Peter L. Peres

picon face
On Thu, 19 Sep 2002, James Williams wrote:

*>Why don't you use the nibble read to read the data?  Or you could even
*>do a byte read.  It is strange to find people still using the status
*>pins to read data from a device.  Especially when you can do byte read
*>and nibble reads without sacrificing no less that 4 input pins.
*>
*>Also, a better interface with multiplexing is a solution around the 13
*>pin limit.  I have not seen this as a problem.

Each project has its own requirements. One of them used a 688 comparator
to 'guess' a 8 bit input value on a port that could not read back. The
output of the 688 was wired to the paper empty status pin. This was a hack
but it works (slowly). Another version of the same device used a 257
multiplexer to read nybbles as you suggest. The nybbles were read through
four of the status lines, not the data lines.

The real problem is, that I often write the drivers myself for other OSes,
some just embedded kernels, make everything work fine, then someone comes
and says let's use this with a standard PC (by this he means
compatibility with the 1000 different kinds of PC parallel ports out
there). What they usually have in common (or had until recently):

- Made in China
- No specs
- Works with Windows or original BIOS and who knows what's inside
- Strange register set quirks that make programming 'fun'
- Sometimes missing features (like no readback from the data port).

Newer ports do not have this kind of problems.

Peter

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...