Searching \ for 'More RS232 to PIC questions' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: piclist.com/techref/microchip/ios.htm?key=rs232
Search entire site for: 'More RS232 to PIC questions'.

Truncated match.
PICList Thread
'More RS232 to PIC questions'
1999\04\06@202113 by Eric Oliver

flavicon
face
Well, after input from this list, I have settled on a MAX213E for my RS232
interface.  I have to implement RTS/CTS handshaking so I began studying the
specifics and it turns out the RTS and CTS are both IO.  So I began
thinking . How can I implement both input and output using a single PIC pin
?  Can it be as simple as using diodes ? I doubt it although I'm sure
diodes come into play.


PIC IO pin ------------- MAX CMOS TX     MAX RS232 TX ----- TO PC RTS
                   |____MAX CMOS RX     MAX RS232 RX ___|

If I place a diode on the TX allowing current to flow only from PIC to PC
and on the RX allowing current to flow from PC to PIC, will that work ?
Also, specific diode recommendations and placement ?  Is it better to put
the diodes on the PC side or PIC side ? I'm thinking if I place the diodes
on the PC side, they will clip the negative voltages.  What about the
voltage drop across the diodes ?


Anyone been down this road before ?

Eric

1999\04\07@012518 by Madis Kaal

flavicon
face
>I have to implement RTS/CTS handshaking so I began studying the
>specifics and it turns out the RTS and CTS are both IO.  So I began
>thinking . How can I implement both input and output using a single
>PIC pin?  Can it be as simple as using diodes ? I doubt it although
>I'm sure diodes come into play.

CTS are RTS are _not_ bidirectional signals. Looking from PC side,
RTS is output and CTS is input.

>PIC IO pin ------------- MAX CMOS TX     MAX RS232 TX ----- TO PC RTS
>                    |____MAX CMOS RX     MAX RS232 RX ___|
>
>If I place a diode on the TX allowing current to flow only from PIC to PC
>and on the RX allowing current to flow from PC to PIC, will that work ?

Basically, you can use a single pin for input and output, if you only
need to check input from time to time, and can get away with not driving
the output all the time (in your case, you probably can't). what you
then do is something lke

IO pin ------------------- MAX CMOS TX     MAX RS232 TX ----- TO PC CTS
               |_<RRRR>___MAX CMOS RX     MAX RS232 RX _____ TO PC RTS

the value of <RRRR> should probably be couple of kOhms. However,
whenever
you turn your PIC pin aroud to read the input, CTS and RTS will be
effectively connected together, probably breaking your flow control
scheme unless the PC side software is written to expect it.

Cheers,

1999\04\07@083943 by TrionicIan

picon face
In a message dated 99-04-06 20:24:18 EDT, you write:

> Well, after input from this list, I have settled on a MAX213E for my RS232
>  interface.  I have to implement RTS/CTS handshaking so I began studying the
>  specifics and it turns out the RTS and CTS are both IO.  So I began
>  thinking . How can I implement both input and output using a single PIC pin
>  ?  Can it be as simple as using diodes ? I doubt it although I'm sure
>  diodes come into play.
>
Why do you think that RTS & CTS are bidirectional?
I have used RS232 for years and never noticed this ... I think that depending
on whether you are implementing a DTE or DCE, you might have different use
for the signals, but they do not change direction in any one connection setup.

Ian C.

1999\04\07@101602 by Mike Keitz

picon face
On Tue, 6 Apr 1999 17:39:44 -0500 Eric Oliver <spam_OUTericTakeThisOuTspamKEDCOENT.COM> writes:

>  I have to implement RTS/CTS handshaking so I began
>studying the
>specifics and it turns out the RTS and CTS are both IO.  So I began
>thinking . How can I implement both input and output

You are mistaken.  All RS-232 lines are one direction.  RTS is always out
of the PC and CTS is always in.  So connect the PC's RTS line to a
receiver in your circuit and the CTS line to a transmitter.



___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]

1999\04\07@122811 by Eric Oliver

flavicon
face
Ok,

The votes in and the unanimous opinion of the list is that RTS/CTS are not
bi-directional. I believe I can go forward armed with this information ( as
far as hardware design ).  On the software side, it's obvious that I need
to bone up on hardware handshaking before proceeding.  I think, as
mentioned by Ian, it will depend on whether the PIC is to be implemented as
DTE or DCE.

Thanks so much for your help,
Eric

{Original Message removed}

1999\04\07@142835 by TrionicIan

picon face
In a message dated 99-04-07 12:21:29 EDT, you write:

>  When using RTS/CTS handshaking, the sender raises RTS when it is ready to
>  send data.  When the receiver detects that RTS has gone high, it should
>  raise CTS when it is ready to receive data.  The receiver should lower CTS
>  to stop data transmission.
>

You are challenging me now!
OK. From "Horowitz & Hill" (a great electronics bible; p724-725) ...
A DTE asserts RTS and DTR when it is ready to receive, and a DCE asserts CTS
and DSR when it is ready to receive.
Note that the signal names make sense only as viewed by the DTE (eg: pin 2 is
called "TD" even though DTE asserts it and DCE receives it). Thus the name of
a pin isn't enough to tell you if its an input or output ... you also need to
know whether the device thinks its a DTE or DCE.


So.
In reality you need to build a circuit with one output handshake and one
input handshake. You will connect these two circuits to either pins 4 & 5 or
5 & 4 depending on whether the thing you are connected to is a DTE or a DCE
(maybe it is labelled; or use a voltmeter - a DTE transmits on pin 2 &
receives on pin 3; a DCE does the reverse).

This is very similar to the problem with RX & TX ... do you have to cross
pins 2 & 3 or not. In reality, the RS232 standard calls pin 2 "TX" whether it
actually transmits or receives.
Thus ... if your circuit receives on 2, then it will receive handshake on 4.
If it receives on 3, it will receive handshake on 5.

Hope that helps!

Ian C.

1999\04\07@204646 by Wagner Lipnharski

picon face
Dear Ian, excuse me if I am bold, but I worked 19 years at IBM and 14 at
teleprocessing dealing with all kinds of telecommunication systems and
modems in several different communication protocols, I also developed
some communication devices to IBM.  I am not challenging Horowitz, but,
DTE asserts RTS (Request to SEND) when it wants to "SEND", not a single
moment before, except if it is a full-duplex system, when the
transmission and reception can happens simultaneously, then RTS still
active all the time (can be programmed to be).  DTR means Data Terminal
Ready to the DCE (data communication equipment, modem), informing that
the DTE is ready, doesn't mean only ready to receive, just "ready", able
to work.  In any case, RTS is not used (never) to means DTE is ready to
receive.

By the other side, the DCE (modem or whatever) also needs to tell the
DTE that it is "ready", so it activate the "DSR" circuit (Data Set
Ready).  If the DCE (modem) is set to work in "half-duplex" mode,
(receive OR transmit), the RTS from DTE will only be answered with CTS
(Clear To Send) from DCE, IF the DCE is not receiving something, or when
the reception ends.  In the full-duplex case, RTS from DTE will always
be answered with CTS from DCE immediately after an internal delay
RTS-CTS defined at the modem. This delay is necessary in half-duplex
mode, to allow the phone line to get quiet without echoes from the
reception, so the modem can transmit without interference.

There are much more details about RS232, including "carrier" (DCD),
"ring" (RI), internal or external clock for synchronous communication,
secondary signals and so on, not relevant at this post.

If someone wants to get this in time chart just ask me via private
email.

I really don't know if Horowitz wrote the way you said, if yes, he is
wrong. Sometimes this happens.

I am just clarifying this point to avoid people to learn it wrong.

Wagner Lipnharski.
http://www.ustr.net

Ian Cull wrote:
> You are challenging me now!
> OK. From "Horowitz & Hill" (a great electronics bible; p724-725) ...
> A DTE asserts RTS and DTR when it is ready to receive, and a DCE asserts CTS
> and DSR when it is ready to receive.
> Note that the signal names make sense only as viewed by the DTE (eg: pin 2 is
> called "TD" even though DTE asserts it and DCE receives it). Thus the name of
> a pin isn't enough to tell you if its an input or output ... you also need to
> know whether the device thinks its a DTE or DCE.

1999\04\07@212512 by William Chops Westfield

face picon face
   Dear Ian, excuse me if I am bold, but I worked 19 years at IBM and 14 at
   teleprocessing dealing with all kinds of telecommunication systems and
   modems in several different communication protocols, I also developed
   some communication devices to IBM.  I am not challenging Horowitz, but,
   DTE asserts RTS (Request to SEND) when it wants to "SEND", not a single
   moment before, except if it is a full-duplex system, when the
   transmission and reception can happens simultaneously, then RTS still
   active all the time (can be programmed to be).

What you say is true of IBM and other "true half duplex" rs232 systems or
others fully obeying the rs232 spec.  This represents approximately 0.05% of
existing asynchronous communications equipment, nearly all of which is full
duplex (removing the need for "spec" RTS/CTS behavior.)


   In any case, RTS is not used (never) to means DTE is ready to receive.

Sure.  Except for about 2 billion modems, printers, terminal servers and
other async serial devices that implement "hardware flow control" using
RTS/CTS.  Asserting RTS/CTS means "ready to receive" (buffers not full), and
this will typically stop transmission of the other side at the hardware
level.  Sorry spec writers, you were overruled by expedience.  There is
no "hardware flow control" in rs232.  It was needed, it was added. (and it's
just like IBM to claim it doesn't exist :-)

BillW
cisco

1999\04\07@214342 by Bob Drzyzgula

flavicon
face
Well, I pulled out my copy of H&H, and, while I don't
have Wagner's experience (It was but a mere fifteen
years ago that I built my first modem cable), I can
say that Wagner is right and <gasp> H&H is wrong
(although I must say that H&H to me never seemed the
place to go for a reference on comm protocols).
Doing a quick google search, I found the following
page, that seems to explain the signals pretty well:

  http://www.sangoma.com/signal.htm

The odd thing to me is that in Table 10.4, at the top of
page 724, H&H has it right. The table calls RTS "Request
to Send", while the text right below calls it "Ready to
Send". If you buy into how the text describes things,
then there is no functional difference either between RTS
and DTR or between CTS and DSR; the text claims that these
pairs are always asserted exactly in lock-step.  If this
was true it would be an enormous waste of a control line.

Still, there is the old aphorism, "The great thing about
the RS-232 standard is that there are so many of them".
People have been abusing RS-232 for as long as it has
existed, and probably before. My guess is that this is
because RS-232 is so over-engineered; there's all those
control lines that sound too much the same, and there's
this inexplicable *appearance* of symmetry where there
shouldn't be any (why on Earth, for example, is the
DTE given a CTS pin?). Look at I2C, RS-485 and LVD, for
example -- people have learned a great deal over the past
few decades about making interfaces. Perhaps if we are real
lucky, USB will finally kill off RS-232 once and for all,
with RS-422, RS-485 or LVD being used where USB is simply
not practical.

--Bob

On Wed, Apr 07, 1999 at 08:47:06PM -0400, Wagner Lipnharski wrote:
> Dear Ian, excuse me if I am bold, but I worked 19 years at IBM and 14 at
> teleprocessing dealing with all kinds of telecommunication systems and
> ...

--
============================================================
Bob Drzyzgula                             It's not a problem
.....bobKILLspamspam@spam@drzyzgula.org                until something bad happens
============================================================

1999\04\07@222428 by Bob Drzyzgula

flavicon
face
On Wed, Apr 07, 1999 at 09:42:12PM -0400, Bob Drzyzgula wrote:
>
> shouldn't be any (why on Earth, for example, is the
> DTE given a CTS pin?). Look at I2C, RS-485 and LVD, for
I meant here  ^^^ to say DSR.

--
============================================================
Bob Drzyzgula                             It's not a problem
bobspamKILLspamdrzyzgula.org                until something bad happens
============================================================

1999\04\07@230533 by Bob Drzyzgula

flavicon
face
On Wed, Apr 07, 1999 at 06:22:40PM -0700, William Chops Westfield wrote:
>
> What you say is true of IBM and other "true half duplex" rs232 systems or
> others fully obeying the rs232 spec.  This represents approximately 0.05% of
> existing asynchronous communications equipment, nearly all of which is full
> duplex (removing the need for "spec" RTS/CTS behavior.)
>
>     In any case, RTS is not used (never) to means DTE is ready to receive.
>
> Sure.  Except for about 2 billion modems, printers, terminal servers and
> other async serial devices that implement "hardware flow control" using
> RTS/CTS.  Asserting RTS/CTS means "ready to receive" (buffers not full), and
> this will typically stop transmission of the other side at the hardware
> level.  Sorry spec writers, you were overruled by expedience.  There is
> no "hardware flow control" in rs232.  It was needed, it was added. (and it's
> just like IBM to claim it doesn't exist :-)

Well, yes and no [he says somewhat timidly to someone who
works where they make terminal servers]. This is probably
true of many asynch applications, but often in those cases,
there is no DCE -- in the case of a system and a printer,
or a hardwired terminal attached to a terminal server,
one has DTE-DTE communications, not DTE-DCE communications
as the protocol is designed.  If one was using DTE-DCE
communciations, the CTS would be connected to CTS and RTS
to RTS. The DTE would be input on CTS and output on RTS,
and the DCE the other way around -- input on RTS and output
on CTS. Then, the terminal can tell the modem when it wants
to send, and the modem can tell the terminal when it *can*
send. This all works just fine and dandy.

But in DTE-DTE communications, both sides want to output
on RTS and input on CTS. So you connect RTS to CTS and
CTS to RTS. On the hardwired terminal, the terminal still
believes that it is talking to a modem. Thus, when it has
stuff to send, it asserts RTS. The terminal server also
believes that it is talking to a modem, and it sees what
it thinks is CTS asserted. This of course just doesn't
make any damned sense. "I want to send you something so
go ahead and send me something??" And the terminal server,
if it wants to be hard-nosed about the protocol, is going
to be a little annoyed about seeing a CTS when it never did
an RTS.  No, there really isn't any way to reconcile this
other than to hack at the protocol and make something up.
If we use modems on both ends, then we have DTE-DCE-DCE-DTE
communications and four pairs of signals to work with.
In straight DTE-DTE connections, there are only two pairs,
and there isn't really any good way to implement the
full, as-intended protocol. Thus, in some equipment you'll
have separate configuration settings for "use modem signals"
and "RTS/CTS flow control". They are different protocols.
Which, unfortunately, only serves to make more confusing
something that is already hellaciously confusing.

FWIW, I found another good description of RS-232, better
than the previous. This one is at CAMI research, which sells
automated cable test equipment:

 http://www.camiresearch.com/Data_Com_Basics/RS232_standard.html

--Bob

--
============================================================
Bob Drzyzgula                             It's not a problem
.....bobKILLspamspam.....drzyzgula.org                until something bad happens
============================================================

1999\04\08@005940 by Wagner Lipnharski

picon face
RTS as Request to Send or the trivial "Ready to Send" still the same
meaning, but it is a pain in the ear as "10K Ohms" is to the eye.

The analogy still valid, since in the Hardware Flow Control, RTS is more
related to signal that the DTE "has something to be sent" much more than
"requesting permission to send", and the DCE (or the fake dce or
whatever) would be the one to authorize it or to hold it for some
reason. In this case, the DCE would answer IF IT WANTS to receive, not
that IT NEEDS to accept it.

In the case of modem, RTS/CTS hardware control is more related to the
"transmission medium", it can be a buffer full or some "near overrun
situation" caused by different communication rates. In any case RTS
still signaling the availability of data to be send, and CTS to allow
the data transfer to go on.  It is a common situation to accommodate old
solutions to new problems, but it gets as much confused as it gets when
using a "null modem" cable.

In a cross cable (null modem), normally RTS returns wired as CTS,
sometimes it also goes to the other side as DCD. It can be used as
"hardware flow control" if RTS is wired as CTS to the other side, in
this situations RTS has its identity ripped off, and probably need its
name to be changed to the ridiculous of "Reception Temporarily
Stopped".  It would be easy to do it better with DSR and DTR, but
sometimes (if not always in some equipment) those circuits are purely a
hardware function from "power good" or something like that.

The main difference between the Hardware and Software Flow Control is
that the first one needs extra 2 circuits (RTS/CTS), while the second
just use Control Bytes (XON/XOFF), so just Ground, TX and RX circuits
are enough.

Unfortunately RS232 was used for long time for different situations,
people got afraid to change and the changes were not very well
accepted.  Sometimes I understand why, just take a look how many
physical communication layers we have right now around a personal
computer, including IrDA.  It took some time to get out of the ISA bus,
but then how many others were developed so fast...  somebody using the
TI-1394 yet?... USB-2 is already doomed by speed and multi-devices
needing a "hub"?

As another example, the DB9 accommodation for RS232 asynchronous is an
attempt to save space and pinout when just a small subset of the
original RS232 is used.

When using logic chips that use VCC=5V we can say "that logic is
TTL...". What is the logic's name when using CMOS at 8V or the low
voltage chips at 3.3V?  The TTL (Transistor Transistor Logic) is widely
used to means zero and +5V logic, but... it gets confused, isn't?

I wonder if when a microcontroller is using TX and RX circuits with
inverted voltage levels from <-4 to >+4 (or around) we can call it
RS232... in real? I guess not, the recommendation RS232 is much more
than that.

So you need to be careful when speaking about RS232, because you
probably would be asking "which one ?"
or you will end up saying "I do NOT want to learn NO rs232"... and
everyone accepts this two negatives gramatic, right?

1999\04\08@014628 by William Chops Westfield

face picon face
   In a cross cable (null modem), normally RTS returns wired as CTS,
   sometimes it also goes to the other side as DCD. It can be used as
   "hardware flow control" if RTS is wired as CTS to the other side, in
   this situations RTS has its identity ripped off, and probably need its
   name to be changed to the ridiculous of "Reception Temporarily
   Stopped".  It would be easy to do it better with DSR and DTR, but
   sometimes (if not always in some equipment) those circuits are purely a
   hardware function from "power good" or something like that.

Right, I think we're in "violent agreement."  While CTS/RTS originally
implemented "modem turnaround" for a half duplex setup where each end
had a clear DTE and DCE device, it is now (also) used for buffer
management between two "local" devices, even when one of them is a modem
(I guess you can argue that a modern modem isn't really a DCE device in
the same sense that an OLD modem was, but...)  You could pick a better
signal than RTS to do the receive flow control (and in fact one of the
uarts we use labels that pin DSR, causing no end of confusion between
the HW and SW developers, because we label it RTS externally!), but that
complicates things in the case of simultaneous HW flow control and modem
control.  Cisco nominally uses DTR/CD for modem control (it was DTR/DSR,
but you'd be surprised at the things you have to do to some modems to
get them to treat DSR the same way they treat CD.)  We use CTS/RTS for
"hw flow control", and we're compatible with most of the modern async
hardware out there, including modems and printers.  (Additional software
handles certain other types of devices.)  On RJ45 connectors, of course!
I don't think I've ever encountered an async device that uses the
"standard" definitions.  I don't think I've ever encountered ANY device
that uses ALL of the rs232 definition.  (in 12+ years writing terminal
server code for cisco, starting back with "well, we can do HW flow
control in ONE direction using CTS if we use the RI signal as carrier
detect instead...", when the HW only hand RD, TD, RI, CTS, and DTR.)

A terminal server has to:

1) talk to a terminal
2) talk to a dialin modem
3) talk to a printer
4) talk to a host that expects to be talking to a
5) talk to a host that expects to be talking to a terminal
6) talk to a dialout modem
7) allow 2 and 6 at the same time.
8) none of the above - use only three wires.

I would go so far as to say that no one show write ANY asynch comm code
based on any "rs232 specification."  You have to find out what the
devices you'll actually talk to do and want...

BillW
cisco

1999\04\08@141831 by Bob Drzyzgula

flavicon
face
On Wed, Apr 07, 1999 at 10:44:19PM -0700, William Chops Westfield wrote:
>
> Right, I think we're in "violent agreement."

No argument there.

> I don't think I've ever encountered an async device that uses the
> "standard" definitions.  I don't think I've ever encountered ANY device
> that uses ALL of the rs232 definition.  (in 12+ years writing terminal
> server code for cisco, starting back with "well, we can do HW flow
> control in ONE direction using CTS if we use the RI signal as carrier
> detect instead...", when the HW only hand RD, TD, RI, CTS, and DTR.)

Pretty much about what I've seen as well, although I'll
add that I think synchronous devices are a little more
well-behaved. Still, going back to Wagner's original
point, Horowitz & Hill's discussion of the RS-232 protocol
is messed up no matter how you slice it; it is neither
correct as per the spec, nor internally consistent, nor
in line with any device that I've seen. Not that I've
seen every device; perhaps H&H had some really oddball
piece of gear laying around the lab, and that discussion
should just be taken as emperical results.

--Bob

--
============================================================
Bob Drzyzgula                             It's not a problem
EraseMEbobspam_OUTspamTakeThisOuTdrzyzgula.org                until something bad happens
============================================================

1999\04\08@171037 by Eric Oliver

flavicon
face
Well, I started this thread and I must say, the discussion has been most
illuminating.  Based upon what I have read, it seems that in all
probability, if I wire/program my PIC to act as a DTE and I am transferring
data to _and_ from another DTE, then I can probably use a crossover cable.
When sending data to the other DTE it will most likely use it's RTS to
signal buffer overruns ( or to stop transmission before an overrun ). So
it's RTS is wired to my CTS and I can monitor CTS to start and stop
transmission. Likewise, I will use my RTS to do the same when receiving
data.

I realize that experimentation is required, but think I can work off this
assumption when wiring my board ?

Eric

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...