Re: [PARPORT] parallel port grounding

From: David Hawkins (
Date: Fri Nov 17 2000 - 12:46:16 EST

  • Next message: Bruce C. Anderson: "[PARPORT] laptop to laptop"

    Hi Daniel,

    > >One thing to be careful of is trying to write one signal
    > >high while the other is driving low. If two CMOS outputs
    > >are connected together, then the one that is high
    > >provides a short to VCC, while the other that is low
    > >provides a short to GND - zap!!
    > Thanks for the warning! I just need to test a interrupt service
    > routine that reads the EPP data port (with read pin set in control
    > register) when a hardware interrupt is received on parport pin 10.
    > Would the following diagram represent a safer way to do this?
    > The mechanical switch is quickly closed and then reopened.
    > parport pin 25 -----------|------------------------ power supply gnd
    > |
    > |
    > / \
    > |5|
    > |K|
    > \ / mechanical switch
    > | /
    > | /
    > parport pin 2 ------------|------------/ -------- 5V power supply
    > |
    > parport pin 10 ------------|

    To test the ISR, why not consider just tying one of the data outputs
    to the interrupt pin (much as Rubini does in his book). You can
    still read from the port afterwards. I would suggest using a pull-up
    (5k) to 5V between the interrupt pin and the data pin you
    are using to set the interrupt. That way when you switch the port direction,
    data input is pulled to a valid logic level and the interrupt pin
    does not get set low again (causing another interrupt).

    Mechanical switches are notorious for 'bouncing', i.e., when you close
    the contact you end up getting multiple transitions on the signal.
    At a minimum I would consider using an RC circuit that gets
    charged up when you close the switch and run this signal
    through a Scmitt trigger to the parallel port. You want to
    use a clean edge at the input to your parallel port, as another
    problem with CMOS is that if you use a slow edge on an
    input, you can also cause problems (both push and pull drivers
    come on producing a short to ground). For testing you
    could get away with just the switch.

    If you have some logic lying around, a Set-Clear latch is also
    a popular switch debouncer. I have also used 74LS123's.
    They are a monoshot - they'll fire off a pulse to generate the

    So, for testing I'd use Rubini's approach with a pull-up.
    In your final design, whatever is doing the interrupting
    should have a well conditioned signal. The monoshot
    is nice, as you can set the pulse length and then know that
    you are not going to have to take care to be re-entrant
    in your ISR. Personally most of the devices I build have
    FPGAs or PALs at the device side. A register holds the
    state of the interrupt to the parallel port and the ISR
    writes to the register to clear the bit. That way I
    know the exact timing of the interrupt control.



    -- To unsubscribe, send mail to: --
    -- with the single word "unsubscribe" in the body of the message. --

    This archive was generated by hypermail 2b29 : Fri Nov 17 2000 - 12:49:31 EST