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,
the
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
interrupt.
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.
Regards,
Dave
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- 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