Rafael Rodrigues Obelheiro (obelix@vetorialnet.com.br)
Fri, 25 Sep 1998 20:43:50 -0300
At 09:19 25/09/98 +0200, schreite@helena.physik.uni-stuttgart.de wrote:
>
>> ...
>> these ports' handshaking and I'm having trouble trying to design a
>> parallel cable that could do the job (establish a bidirectional data
>> channel) under either mode (it doesn't seem quite feasible without extra
>> circuitry, something I was trying to avoid).
>I don't know very much about the PLIP protokol. But I have to computers I
>also would like to connect via PLIP.
>
>(snip)
>
>Now to your actual problem, the PLIP driver and an appropriate parallel
cable:
>I assume you want on both computers a "host parallel port", not a
>"peripheral parallel port" and you know, that the i/o-directions are
>just switched on each port - except of the data pins for a bidirectional
>port, which is used by ECP and EPP. In the ECP (or EPP) handshake we
>find pairs of respective handshake signals, one of each data flow directions.
>Consequently the cable design should provide "crossed wires" according
>to those signal pairs. Do you have specs about ECP ... or should I send to
you
>a "map" of the preferable wiring of such a PLIP-ECP cable?
>
The problem here is that both modes require the host to actively read
the port in order to get any input. According to the docs I have (not the
actual IEEE spec), in EPP mode the data transfer direction (input/output)
is given by the nWrite signal, which is controlled by the "host" (so the
other end of the connection doesn't seem to be able to claim the channel
unless the host requests it). A similar thing happens with ECP, where the
host has to demand a reverse data transfer (actually, there's a
nPeriphRequest signal that the peripheral may assert to request this
reversal, but I read somewhere that the host is not required to reverse
the channel when nPeriphRequest is asserted -- it acts according to its
own will.) Since all this handshaking is done by the hardware, you can't
change it, so I'm afraid that
1. I'm stuck with EPP, and
2. I'll need to define "master" and "slave" hosts if I want to implement
ECP support for PLIP.
>Now to the software: ECP is a master-slave-protocal (host-peripheral).
>But I think I shouldn't be too difficult to modify the IEEE1284 code,
>I'm actual writing, to manage a ECP peer "as peripheral" - let me think
>about it during the week end! If so, you could concentrate on the PLIP
>protocol part and use the functions soon provided by parport_ieee1284.c.
>
Best regards,
-- Rafael Rodrigues Obelheiro obelix@vetorialnet.com.br-- 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 2.0b3 on Wed 30 Dec 1998 - 10:18:24 EST