Ah, RS232D. The new use for RTS does make things much easier. All
those other pins made everything much too complicated and were probably
only relevant when dealing with PC <-> Modem. If my memory is correct
(it's dynamic - needs a regular refresh :), didn't the BBC Micro use
this simpler RTS/CTS scheme? (I never had one of those but a friend
did.)
cheers to everyone helping to enlighten me on this topic!
Ian.
-----Original Message-----
From: Jonathan.Dent
Sent: 08 May 2001 12:49
To: ql-users
Cc: Jonathan.Dent
Subject: RE: Re: [ql-users] QL serial ports
Hi Ian
Up till RS232C your argument was right but since RS232D the function of
pin
RTS
is either Request To Send (CA) or Ready For Receiving (CJ). They left
the
name
of the pin RTS to confuse everybody (me included but not Tony ;) By
selecting RTS/CTS
handshaking you normally select the ready for receiving variation
unless the
equipment manufacturers are confused too, which I'm afraid they
sometimes
are :(
Jon.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 08 May 2001 12:37
To: [EMAIL PROTECTED]
Subject: RE: Re: [ql-users] QL serial ports
> 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.
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.
