Searching \ for 'Parallel port interfacing trouble' 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: 'Parallel port interfacing trouble'.

Truncated match.
PICList Thread
'Parallel port interfacing trouble'
1997\10\06@074406 by gerritse

flavicon
face
Hello everybody,

I am trying to interface a 16C84 to a parallel port, and sending data
from the pc to the pic works fine.

But when it comes from sending data from the pic to the pc things go
wrong horribly. I've written a small program that reads port 0x378 in
a loop and prints any data right on to the screen, but the parallel
does not recognize a high level signal ( 3.45 volt )

Any idea about what to do ? Am I forgetting something in the pic


      bsf     STATUS, RP0     ; select register bank 1

      movlw   0x07            ; Port A als input, bit 4 als output !
      movwf   TRISA

       bcf     STATUS, RP0     ; select register bank 0

      bsf      PORTA,  3       ; Pull up ofzo ?

Greetings, Gerard Gerritsen

ESD Electronics
Zwaansprengweg 20
7300 AE Apeldoorn, The Netherlands

email : spam_OUTgerritseTakeThisOuTspamesd1.esd.nl
tel   : ++31-55-5499499
fax   : ++31-55-5427288

1997\10\06@114327 by Alberto Smulders

flavicon
See:

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

for information on enhanced (bidirectional) parallel ports.

I haven't read the materials there, but I think you cannot simply read
0x378 for input; if I'm not wrong, reading 0x378 returns the last byte
written to that port.
I think you'll have to configure some other register for EPP - ECP parallel
ports, or perhaps to do some handshaking for input through the same.
If I've time enough, I'll read this night through the documentation and
post another mail with the conclusions (not much time though, a week with
lots of lightning storms = burnt equipment at clients factories =
trouble....)

Albert A.Smulders
InSAD - Encarnaci—n, Paraguay
.....insadKILLspamspam@spam@itacom.com.py

----------
{Quote hidden}

1997\10\06@134628 by Steven J Tucker

flavicon
face
On Mon, 6 Oct 1997, Gerard Gerritsen wrote:

> Hello everybody,
>
> I am trying to interface a 16C84 to a parallel port, and sending data
> from the pc to the pic works fine.
>
> But when it comes from sending data from the pic to the pc things go
> wrong horribly. I've written a small program that reads port 0x378 in
> a loop and prints any data right on to the screen, but the parallel
> does not recognize a high level signal ( 3.45 volt )
>
> Any idea about what to do ? Am I forgetting something in the pic

The i/o lines on the standard parallel port are all unidirectional, so make
sure your signal is connected to an input line.  Also, some of the lines
have inverted logic (low reads high, high reads low).

Steve

   * * *  Author of Imagic and APE - The Atari Peripheral Emulator!  * * *
   * * *      Turn your 8-bit Atari into a powerhouse with APE!      * * *
  *  *  *        Ape Homepage: http://www.nacs.net/~classics        *  *  *
*    *    *********************************************************    *    *
!! Request my *FOR SALE* LISTING OF CLASSIC VIDEO GAME STUFF -- 2000+ Items !!

1997\10\06@192403 by Harold Hallikainen

picon face
       With the discussion on printer port interface, I thought I'd pass
along my code for the PIC (16c74a) to write data to the printer port in
nybble mode.  In my application, the PC reads from the PIC in nybble mode
(slow, but always works) and writes to it just using the printer port
-strobe signal to drive the -write input of the PIC PSP.
       For more info on timing, etc., see http://www.dovesystems.com and
look under StarPort.

Harold



writeNybble
; This routine takes data from the RamPort and sends it to the host
processor.
; Called from main loop
 cblock
       wnState                 ; Write Nybble state
       wndata                  ; Byte from RamPort we're
transmitting
 endc
       movlw   high(writeNybble)
       movwf   pclath          ; Get ready for jump table
       movfw   wnState         ; Get state
       andlw   0x07            ; Prevent some invalid states
       addwf   pcl,1           ; Go into jump table
       goto    wn0             ; 0 - Waiting for -DataRq to go
low
       goto    wn1             ; 1 - Low half sent to host,
waiting for -DataAck to go low
       goto    wn2             ; 2 - Waiting for -DataRq to go
high
       goto    wn3             ; 3 - Waiting for -DataRq to go
low for high half
       goto    wn4             ; 4 - High half sent to host,
waiting for -DataRq to go high
       goto    wn5             ; 5 - Invalid state, clear state
and return
       goto    wn6             ; 6 - Invalid state, clear state
and return
       goto    wn7             ; 7 - invalid state
wn0                             ; Waiting for -DataRq to go low
       btfsc   porta,4         ; test bit
       return                  ; if not yet low, return
       movfw   hostReadAddressHi ; Set up RamPort address
       disableIRQ              ; RamPort code not reentrant
       movwf   ReadAddressHi
       movfw   hostReadAddressLo
       movwf   ReadAddressLo
       call    ReadRamPort     ;read it
       movfw   ReadData        ; get results
       enableIRQ               ; irq ok now
       movwf   wnData          ; and save it
       iorlw   0xf0            ; Set high half so we don't make
-DataAck low right away
       movwf   porta           ; Output the data
       andlw   b'11011111'     ; Set bit 5 (-DataAck) low
       movwf   porta           ; and output the updated port
data, avoiding read-modify-write!
       incf    wnState,1       ; Go wait for -DataRq to go high
;       return
wn1                             ; Waiting for -dataRq to go high
       btfss   porta,4         ; test bit
       return                  ; Exit if host has not yet taken
nybble
       bsf     porta,5         ; Set the ack bit high
       incf    wnstate,1       ; and move on
;       return
wn2                             ; Waiting for -DataRq to go low again
       btfsc   porta,4         ; test bit
       return                  ; Exit if host has not yet
requested high half of nybble
       swapf   wndata,0        ; Put high half in low half of w
       iorlw   0xf0            ; Set high half high so we don't
make -DataAck low right away
       movwf   portA           ; output the data
       andlw   b'11011111'     ; Set bit 5 (-DataAck) low
       movwf   portA           ; and output it, avoiding
read-modify-write of bcf
       incf    wnState,1       ; move on to next state
;       return
wn3                             ; Waiting for -DataRq to go high
       btfss   porta,4         ; test bit
       return                  ; Exit if -DataRq has not yet gone
high
       bsf     porta,5         ; Set -DataAck back high
       movlw   1               ; Increment address after read
       addwf   hostReadAddressLo,1 ; Add 1 to lo half, setting
carry if needed
       btfsc   status,c        ; overflow?
       incf    hostReadAddressHi,1     ; Yes, add carry to high
half
wn4
wn5
wn6
wn7
       clrf    wnState         ; Invalid states, clear and
return
       return

1997\10\06@194007 by Ross McKenzie

flavicon
face
At 01:41 PM 10/6/97 -0400, you wrote:
>On Mon, 6 Oct 1997, Gerard Gerritsen wrote:
>The i/o lines on the standard parallel port are all unidirectional, so make
> sure your signal is connected to an input line.  Also, some of the lines
> have inverted logic (low reads high, high reads low).
>
>Steve

Are you sure? I have run FastWire on a 4.77MHz XT. FastWire is one of those
fast file transfer programs that uses the parallel port to talk between pcs.
It is definitely bidirectional.


Regards,

Ross McKenzie
Melbourne Australia

to reply by email remove the "nosp*m." text from my email address

1997\10\06@195045 by WF AUTOMA‚̀O

flavicon
face
Ross McKenzie wrote:
{Quote hidden}

Hummm, i think that the transfer used in the old PC was with the Pins Control
(strobe/Init/Error), not with Data Bus!

Miguel.

1997\10\07@082708 by Cliff Rogers

flavicon
face
> Are you sure? I have run FastWire on a 4.77MHz XT. FastWire is one of those
> fast file transfer programs that uses the parallel port to talk between pcs.
> It is definitely bidirectional.
>

G'day, FastWire does it by trickery. The special cable connects 5 of the data
out bits on one end to the 5 handshake inputs at the
other. It looks like bidirectional comms but it is realy a 5 bit full duplex
link. Interlink does the same thing.

The data bits on the origanal parallel printer port were unidirectional. Some of
the handshake lines were bidirectional. Some of
the later parallel printer ports have bidirectional data bits.

Cliff Rogers   (Computer Technician)  email  cliffrogersspamspam_OUTusa.net
Absolute Computers Pty. Ltd. Cairns, Queensland, Australia.

1997\10\07@082710 by Steven J Tucker

flavicon
face
On Tue, 7 Oct 1997, Ross McKenzie wrote:

> At 01:41 PM 10/6/97 -0400, you wrote:
> >On Mon, 6 Oct 1997, Gerard Gerritsen wrote:
> >The i/o lines on the standard parallel port are all unidirectional, so make
> > sure your signal is connected to an input line.  Also, some of the lines
> > have inverted logic (low reads high, high reads low).
> >
> >Steve
>
> Are you sure? I have run FastWire on a 4.77MHz XT. FastWire is one of those
> fast file transfer programs that uses the parallel port to talk between pcs.
> It is definitely bidirectional.

Yes, on the standard (non ecp/epp) parallel ports, all the lines are
either input, or output.  None are bi-directional.  W/ 4 or 5 outputs, and
over 10 inputs, you obviously CAN have 2 way communication, but that was
not what I posted.

Steve

   * * *  Author of Imagic and APE - The Atari Peripheral Emulator!  * * *
   * * *      Turn your 8-bit Atari into a powerhouse with APE!      * * *
  *  *  *        Ape Homepage: http://www.nacs.net/~classics        *  *  *
*    *    *********************************************************    *    *
!! Request my *FOR SALE* LISTING OF CLASSIC VIDEO GAME STUFF -- 2000+ Items !!

1997\10\07@082715 by Steven J Tucker

flavicon
face
On Mon, 6 Oct 1997, WF AUTOMA=?iso-8859-1?Q?=C7=C3O ?= wrote:

> Hummm, i think that the transfer used in the old PC was with the Pins Control
> (strobe/Init/Error), not with Data Bus!

Interesting trick, probably off topic. :)   The DATA outputs are
unidirectional, but reading that register actually reads the state of
the latches.

If you set the output latches of the port HIGH, then drag the
outputs low (most have current limiting resistors) and read the data latch,
it reads those lines as low.

I once needed just 1 more active low input on a project, this worked fine and
never damaged the port.  I had to boost the drain by using the 2 leftover
gates of an inverter, but it worked :)

Steve

   * * *  Author of Imagic and APE - The Atari Peripheral Emulator!  * * *
   * * *      Turn your 8-bit Atari into a powerhouse with APE!      * * *
  *  *  *        Ape Homepage: http://www.nacs.net/~classics        *  *  *
*    *    *********************************************************    *    *
!! Request my *FOR SALE* LISTING OF CLASSIC VIDEO GAME STUFF -- 2000+ Items !!

1997\10\07@082721 by ht

flavicon
face
At 09:28 07.10.97 +1000, you wrote:
{Quote hidden}

I would expext that it uses som kind of nibble mode.  I think one
implementation of nibble mode is described in some IEEE1284 document around.
Although some OLD documentation says that it *IS* possible to read the data
lines if they are driven by more than 20mA.  Has anyone actually tried this?
I have done some simple tests, and it semes to work, but I don't think that
the drivers likes to this kind of drive fight.  The port will probably blow
up sooner or later...

Havard

1997\10\07@093838 by Tom Handley

picon face
  Steve, most all PCs in recent years have bi-directional ports. They don't
have to be ECP/EPP. Bit 5 of the Control register controls the direction. Set
it to 1 for a read and 0 (default) for a write. I've designed all kinds of
projects that connect to the port using 8-Bit bi-directional transfers. One
is an FPGA that emulates uP signals. I use the control lines to control a
state machine in the FPGA. The 8 data Bits are buffered via 74xx245 to
provide a data bus.

  - Tom

At 12:26 AM 10/7/97 -0400, you wrote:
{Quote hidden}

1997\10\07@103828 by John Payson

picon face
> Yes, on the standard (non ecp/epp) parallel ports, all the lines are
>  either input, or output.  None are bi-directional.  W/ 4 or 5 outputs, and
>  over 10 inputs, you obviously CAN have 2 way communication, but that was
>  not what I posted.

On many standard printer ports (going back to the originals) the four
control outputs use open-collector drivers, and a read to the I/O port
will read the voltage on the pin (rather than the latch).  This gives
8 out, 4 in/out, and 5 in.  The only machines I'm specifically aware of
that violate this convention are Toshiba laptops (though I would not be
surprised if there are some more).

1997\10\07@103836 by Matt Bonner

flavicon
face
Ross McKenzie wrote:
>
> At 01:41 PM 10/6/97 -0400, you wrote:
> >On Mon, 6 Oct 1997, Gerard Gerritsen wrote:
> >The i/o lines on the standard parallel port are all unidirectional, so make
> > sure your signal is connected to an input line.  Also, some of the lines
> > have inverted logic (low reads high, high reads low).
> >
> >Steve
>
> Are you sure? I have run FastWire on a 4.77MHz XT. FastWire is one of those
> fast file transfer programs that uses the parallel port to talk between pcs.
> It is definitely bidirectional.
>
IBM originally spec'd (in the early 80s) the PC to have unidirectional
parallel ports.  Even back then, though, clones were a big seller
(remember the Corona?).  The only time I ran into a non-IBM PC/XT/AT
parallel port that _wasn't_ bidirectional was when I bought those
inexpensive multi-IO boards (IDE, serial, parallel, game).  In short,
you probably have a unidirection parallel port if your PC or XT or AT
was designed strictly to IBM specs.
--Matt

1997\10\07@122403 by ERIC SCHLAEPFER

flavicon
face
    Hi,

    >Ross McKenzie wrote:
    >>
    >> At 01:41 PM 10/6/97 -0400, you wrote:
    >> >On Mon, 6 Oct 1997, Gerard Gerritsen wrote:
    >> >The i/o lines on the standard parallel port are all
    >unidirectional, so make > > sure your signal is connected to an input
    >line.  Also, some of the lines
    >> > have inverted logic (low reads high, high reads low). > >
    >> >Steve
    >>
    >> Are you sure? I have run FastWire on a 4.77MHz XT. FastWire is one
    >of those > fast file transfer programs that uses the parallel port to
    >talk between pcs. > It is definitely bidirectional.
    >>
    >> Regards,
    >>
    >> Ross McKenzie
    >> Melbourne Australia
    >>
    >> to reply by email remove the "nosp*m." text from my email address


    >Hummm, i think that the transfer used in the old PC was with the Pins
    >Control (strobe/Init/Error), not with Data Bus!

    You are correct. In fact, I think the cables transferred data 4 bits
    at a time, so they used 5 data lines total. (One is for the clock.)
    BTW, the strobe line is an output.

    Later,

    Eric

1997\10\07@123817 by Jim Ham

flavicon
face
The four status lines that are read/written at base+2 of a parallel port
are open collector. You can arrange for these to be bi-directional without
too much trouble. The IBM spec on these is that there is a  4.7K resistor
in the printer adaptor to pull them to +5. Of course IBM in their
wonderfullness made all but one of these bits inverted.

I have a Compaq Aero where the port does not follow the IBM standard as
above. All other ports that I have tried do, however.

Jim Ham

At 08:32 AM 10/7/97 +0100, you wrote:
{Quote hidden}

Jim Ham, Porcine Associates
(415)326-2669 fax(415)326-1071
"http://www.porcine.com"

1997\10\07@132259 by Mike Keitz

picon face
On Tue, 7 Oct 1997 00:34:46 -0400 Steven J Tucker <@spam@classicsKILLspamspamNACS.NET>
writes:
>On Mon, 6 Oct 1997, WF AUTOMA=?iso-8859-1?Q?=C7=C3O ?= wrote:
>
>> Hummm, i think that the transfer used in the old PC was with the
>Pins Control
>> (strobe/Init/Error), not with Data Bus!
>
>Interesting trick, probably off topic. :)   The DATA outputs are
> unidirectional, but reading that register actually reads the state of
> the latches.
>
>If you set the output latches of the port HIGH, then drag the
> outputs low (most have current limiting resistors) and read the data
>latch,
> it reads those lines as low.

The old ones used a 74LS373 to drive the outputs, this chip has
heavy-duty outputs of 24 mA source and 48 mA sink.  Any "current limiting
resistor" is on the order of 30 ohms and intended to damp ringing on the
line rather than limit the DC current.  Newer cards amy not have as much
drive, so if your project was tested on one of those it may not work with
an old one.  Forcing all 8 lines low may overheat the driver chip, though
you could get away with one or 2 there's really no need to.

On "bi-directional" ports, writing a 1 to bit 5 of X7A will turn off the
drivers on the data bus and allow external data to be read in from X78.
Nearly all new cards have at least this "advanced" feature, though there
may be a jumper to disable it and force the old mode of operation.

>
>I once needed just 1 more active low input on a project, this worked
>fine and
> never damaged the port.  I had to boost the drain by using the 2
>leftover
> gates of an inverter, but it worked :)

The 4 control lines driven by X7A are open-collector with pullup
resistors on the printer card, so they can be set high, but will read low
if an external device pulls them low.  The value of the pull-up resistor
varies between 1 and 4.7K depending on the card.  These are useful for
I2C devices.  The 5 status lines on X79 are input only.  Some of the
lines in both ports are logically inverted between the register bits and
the pin, but this is entirely standard between different cards.

1997\10\07@172115 by William Chops Westfield

face picon face
Note that a parallel port with less than 8 bits is still much faster and
easier to do reliabale transfers with than the average serial port.  The
venerable BBN1822 interface used to connect computers to the (original)
arpanet was essentially a 1 bit parallel interface (gives you word-length
independence, don't ya know.)  More recently, there are I2C, SPI, etc, etc
ad nauseum that are also more or less one-bit parallel ports (at least,
you can certainly think of them that way!)  I forget the original question,
but if all you want is a fast link using a PC's parallel port, you can do
somewhere between 2 and 4 bits without "cheating" at all...

BillW

1997\10\07@194835 by jorgegf

flavicon
face
Hi folks


Ross McKenzie wrote:
{Quote hidden}

I think you are wrong, the printer port on a PC (standard port not EEP
or ECP, i don't know these ones in detail) is an output port. Programs
that tranfers data both ways like, for instance, LapLink, MD-DOS
interlink/interserver, iomega Zip100 drives and so on, do it in the so
called nibble mode (4 bits at a time) using the status lines for input.
The so called laplink cable (I made a couple of those myself) is a
crossed line cable that connects 4 data lines (OUT) on one side to 4
status lines (IN) on the other and the same on the oposite direction.


       best regards

       Jorge F

1997\10\07@211059 by dieser

flavicon
face
Jorge Ferreira wrote:
>
> Hi folks
>
> Ross McKenzie wrote:
> >
> > At 01:41 PM 10/6/97 -0400, you wrote:
> > >On Mon, 6 Oct 1997, Gerard Gerritsen wrote:
> > >The i/o lines on the standard parallel port are all unidirectional, so make
> > > sure your signal is connected to an input line.  Also, some of the lines
> > > have inverted logic (low reads high, high reads low).
> > >

[snip]

Here is some good places for general information about the parallel port

http://shell.rmi.net/~hisys/parport.html
www.geocities.com/SiliconValley/Bay/8302/parallel.htm#2
http://et.nmsu.edu/~etti/fall96/computer/printer/printer.html

Regards,

Dave Dieser

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