> Simple - you need a crossover lead.
> TX -> RX
> RX <- TX
> RTS -> CTS
> CTS <- RTS
> and that is it.
> No complications with DSR and DTR - forget them.
Phew, I was hoping it would be something as simple as that but as the
above example doesn't really conform to the RS232 standard for RTS (in
which it is defined as Request To Send, i.e. asking permission to send,
not granting permission to be sent to), I didn't think it would be that
simple. I used X & Y where the book uses various combinations of DCD,
DSR, DTR, RI in the different models. In one example each side loops
RTS back to its own CTS, so when it requests to send it automatically
grants itself, i.e. no flow control! I can't remember the exact name
of the book - something like "The Indispensable PC Hardware Book" or
words to that effect.
Thanks for your help.
Ian.
-----Original Message-----
From: tony
Sent: 08 May 2001 11:14
To: ql-users
Cc: tony
Subject: Re: [ql-users] QL serial ports
On Tue, 8 May 2001 at 10:16:05, you wrote:
(ref: <H0000b5f107f99fa.0989313362.ln4p1327.ldn.swissbank.com@MHS>)
>> It is all down to handshaking and how fast the QL can accept and
>process
>> the data. If the QL invoked the handshake line, and DTR was
connected
>> to RTS .....
>
>Just to throw in my two pen'orth (by the way hello, I'm a new Q40
>user), how exactly is RTS/CTS handshaking implemented on the [Linux] PC
>side?
Exactly the same as a PC - it is a std ISA serial card.
> I have a hardware book that shows several complicated ways of
>connecting two PCs via serial ports, but taking the following scheme as
>an example:
>
> PC 'A' PC 'B'
> TD ----------> RD
> RD <---------- TD
> RTS ----------> Input X
> CTS <---------- Output Y
>Input X <---------- RTS
>Output Y ----------> CTS
>
>Then if, for example, PC A wants to transmit to PC B, A would signal
>its intention on its RTS output driving an input pin on PC B. PC B then
>uses an output pin driving PC A's CTS to control the flow of data from
>PC A. The question is, when the Linux PC is the receiver,
Doesn't matter which is set as receiver - the data and handshake
direction is always the same.
>which pin
>does it expect the sender's RTS to come in on and which output pin does
>it use to drive the sender's CTS?
Simple - you need a crossover lead.
TX -> RX
RX <- TX
RTS -> CTS
CTS <- RTS
and that is it.
No complications with DSR and DTR - forget them.
A standard Laplink serial cable works fine.
Goodness knows why your hardware manual complicates matters by adding
'input x' etc - just confuses. What do they mean I wonder?
This applies to QL ser2 as well ('DTR' is actually RTS on the QL).
QL ser2 is identical to Q40 port. ser1 includes a crossover internally.
--
QBBS (QL fido BBS 2:257/67) +44(0)1442-828255
mailto:[EMAIL PROTECTED] http://www.firshman.demon.co.uk
Voice: +44(0)1442-828254 Fax: +44(0)1442-828255
TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
