Reading from parallel port

B

Bart T.

Guest
Hi,

I've built a simple circuit which sends data to the computer via a
single line (an output from a 74HC165 shift register connected to a
parallel port status pin.) It doesn't work correctly unless that
connection is broken (I've confirmed with a multimeter that the '165
output is correct.)

Here's what I noticed: If the most significant bits of the byte loaded
into the 165 are 1's, they will consistently be returned correctly to
the PC:

80 -> 80
C0 -> C0
E0 -> E0
....

But when a zero appears in the stream, it'll screw up the rest (even
if there are 1's later on, they still appear as 0):

90 -> 80
A0 -> 80
FA -> F8

If I load F9 into the shift register, I get FC out, which is really
strange. This only happens when the parallel port input line (pin 12,
to be specific) is connected to Q7 (the output) of the IC. If that
connection is not made, the IC actually outputs the correct sequence.

The parallel port connector is grounded to the rest of my circuit.
Does anyone know what I'm missing? The connection is direct (pull-up
and down resistors don't affect it) and my code simply reads the
status port (BASE_LPT_ADDRESS + 1.) Writing a 1 or 0 before each read
doesn't have any effect.

Thanks in advance...
 
On 20 Jul 2004 20:00:06 -0700, bart_trzynadlowski@yahoo.com (Bart
T.) wrote:

Hi,

I've built a simple circuit which sends data to the computer via a
single line (an output from a 74HC165 shift register connected to a
parallel port status pin.) It doesn't work correctly unless that
connection is broken (I've confirmed with a multimeter that the '165
output is correct.)
Click to expand...
I've got a little parallel port setup at the below page that
reads input on the parallel port. You may need to use a similar
setup to get data on the input pins.

http://www.geocities.com/zoomkat/status.htm
 
shb*NO*SPAM*@comporium.net (Si Ballenger) wrote in message news:<40fdf7ba.2974667@news.comporium.net>...
I've got a little parallel port setup at the below page that
reads input on the parallel port. You may need to use a similar
setup to get data on the input pins.

http://www.geocities.com/zoomkat/status.htm
Click to expand...
Hi, thanks for pointing me towards this. I don't really understand
what you're doing, though -- what purpose do the transistors serve?
Why not just make a direct connection?

In my case, I'm making a connection between the input pin and a CMOS
output. It's almost as if the connection causes interference elsewhere
in the circuit despite there not being any physical connection
problems.
 
"Bart T." <bart_trzynadlowski@yahoo.com> schreef in bericht
news:d41579c6.0407201900.18bd7a49@posting.google.com...
Hi,

I've built a simple circuit which sends data to the computer via a
single line (an output from a 74HC165 shift register connected to a
parallel port status pin.) It doesn't work correctly unless that
connection is broken (I've confirmed with a multimeter that the '165
output is correct.)

Here's what I noticed: If the most significant bits of the byte loaded
into the 165 are 1's, they will consistently be returned correctly to
the PC:

80 -> 80
C0 -> C0
E0 -> E0
...

But when a zero appears in the stream, it'll screw up the rest (even
if there are 1's later on, they still appear as 0):

90 -> 80
A0 -> 80
FA -> F8

If I load F9 into the shift register, I get FC out, which is really
strange. This only happens when the parallel port input line (pin 12,
to be specific) is connected to Q7 (the output) of the IC. If that
connection is not made, the IC actually outputs the correct sequence.

The parallel port connector is grounded to the rest of my circuit.
Does anyone know what I'm missing? The connection is direct (pull-up
and down resistors don't affect it) and my code simply reads the
status port (BASE_LPT_ADDRESS + 1.) Writing a 1 or 0 before each read
doesn't have any effect.

Thanks in advance...
Click to expand...
Check the power pins and the not connected inputs of your electronics. It
looks like your 165 gets no power, but floating input pins sometimes cause
the same effect. Less likely there is a short between the output of your 165
and an input.

petrus bitbyter


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.720 / Virus Database: 476 - Release Date: 15-7-2004
 
On 21 Jul 2004 14:01:20 -0700, bart_trzynadlowski@yahoo.com (Bart
T.) wrote:

shb*NO*SPAM*@comporium.net (Si Ballenger) wrote in message news:<40fdf7ba.2974667@news.comporium.net>...
I've got a little parallel port setup at the below page that
reads input on the parallel port. You may need to use a similar
setup to get data on the input pins.

http://www.geocities.com/zoomkat/status.htm

Hi, thanks for pointing me towards this. I don't really understand
what you're doing, though -- what purpose do the transistors serve?
Why not just make a direct connection?
Click to expand...
The status pins I use are normally at +5v indicating a 1 when
read. When they are connected to the computer ground via a
resistor they go to ~+2v condition which is indicated by a 0 when
read. The transistor just acts as a switch to connect the pin to
ground via the resistor. With no current supplied to the
transistor base, the switch is off, and the status pin is +5v.
With current supplied to the transistor base, the switch is on
and the pin voltage is reduced to ~+2v, which is read as an off.
Just a simple way to read on/off of external devices..

In my case, I'm making a connection between the input pin and a CMOS
output. It's almost as if the connection causes interference elsewhere
in the circuit despite there not being any physical connection
problems.
Click to expand...
You may need to have the CMOS output control a transistor
somewhat like I've done.
 
"petrus bitbyter" <p.kralt@reducespamforchello.nl> wrote in message
Check the power pins and the not connected inputs of your electronics. It
looks like your 165 gets no power, but floating input pins sometimes cause
the same effect. Less likely there is a short between the output of your 165
and an input.
Click to expand...
I've checked all connections, none are shorted, and none are left
floating. The device is powered. The only unconnected pin is the
inverted output (/Q7.) Grounding it has no effect.

Interestingly, if the Q7 output pin is not connected, the device
functions properly. But if it's connected to a parallel port input
pin, it no longer functions (it works as long as 1's are being shifted
out of the 165 but as soon as a 0 is hit, it behaves oddly.)

What's most telling is that with inputs like:

1101 1000

The output is:

1110 0000

The first 1 after the 0 is ignored, but the next 1 is pushed up to bit
5. It must be an issue internal to the 165, but it only occurs when
the Q7 output is hooked up to the pport, otherwise, it works as
expected. :/

Something about the status pins on the pport is capable of screwing
with the 165. I just don't know what's causing this interference and
how to work around it.
 
"Bart T." <bart_trzynadlowski@yahoo.com> schreef in bericht
news:d41579c6.0407212207.6e580d6e@posting.google.com...
"petrus bitbyter" <p.kralt@reducespamforchello.nl> wrote in message
Check the power pins and the not connected inputs of your electronics.
It
looks like your 165 gets no power, but floating input pins sometimes
cause
the same effect. Less likely there is a short between the output of your
165
and an input.

I've checked all connections, none are shorted, and none are left
floating. The device is powered. The only unconnected pin is the
inverted output (/Q7.) Grounding it has no effect.

Interestingly, if the Q7 output pin is not connected, the device
functions properly. But if it's connected to a parallel port input
pin, it no longer functions (it works as long as 1's are being shifted
out of the 165 but as soon as a 0 is hit, it behaves oddly.)

What's most telling is that with inputs like:

1101 1000

The output is:

1110 0000

The first 1 after the 0 is ignored, but the next 1 is pushed up to bit
5. It must be an issue internal to the 165, but it only occurs when
the Q7 output is hooked up to the pport, otherwise, it works as
expected. :/

Something about the status pins on the pport is capable of screwing
with the 165. I just don't know what's causing this interference and
how to work around it.
Click to expand...
Outputs that are not used should be left alone. Forcing them to GND, Vcc or
another output may destroy the chip.

Did you check the power pin during the error situation?

So your printerport becomes suspect. You did not write what status pin
you're using but that may cause the problem. Some of that pins are
bidirectional and may be put in output mode somehow. To make it sure,
reproduce the situation with an output of the 165 being 0 when it should be
1. Then disconnent it from the PC and see what happens. If the Q7 becomes
high again, the PC is definitively pulling the status pin low.

The behaviour of the printerport depends largely on its mode i.e. standard,
bidirectional, EPP, ECP or whatever. The mode is normally set in the BIOS.
You can check out the various possibilities on
http://www.beyondlogic.org/
All (or at least almost all) about programming the parallel printer port.

petrus bitbyter


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.720 / Virus Database: 476 - Release Date: 14-7-2004
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top