Post by George NeunerOn Fri, 24 Mar 2023 18:21:21 -0700 (PDT), Rick C
Post by Rick CExcellent Don. Now, please tell me which unit is the DCE and which is
the DTE? Or better yet, just answer the question asked, on this
device, which pin on the DB9 connector is the data output and which
is the data input?
"Terminal Equipment" (TE) vs "Communications Equipment" (CE).
DTE is the computer (terminal), DCE is the modem. To adhere to the
RS-232 conventions, your external device has to be "communications
equipment".
Don explained the cables and how the signaling works. DTE transmits on
TxD, and receives on RxD. DCE does the reverse. Which physical pins
these are on depends on the form factor: DB9 or DB25.
RS-232 pinout diagrams are very easy to find. Try Google.
Rick doesn't understand how the Standard is interpreted solely as
"guidance", in the real world. The idea that someone ELSE could
examine *his* choice of device from *his* chosen vendor and
comment, in any meaningful way, suggests a naivite that's
beyond laughable.
APC uses a DB9 that *seems* to implement RS232. Yet, if you
wire it to a nominal mate, you'll find the UPS will shutdown.
Because THEY have repurposed one of the modem control signals
as a "shutdown" signal. Ooops!
Is APC (Schneider Electric) a dubious little garage shop
selling products that likely have limited lifetimes? I.e.,
you want to talk to an APC UPS, you learn how APC expects
the port to be wired and used. If this is unacceptable
to you, you find another UPS vendor and hope for something
better.
Having a pinout tells you very little more than which
signals you can "safely" connect together; it tells you
nothing about the function of the signal, the protocol or
content. E.g., using RLSD as a pacing signal (WTF??)
The choice of UART gives a *hint* as to how responsive the
software (firmware, drivers, HAL, etc.) will be to signalling
conventions and message latency.
If I twiddle a "handshaking" (misnomer) signal, how quickly
will the other party stop transmitting? How many *more*
characters must I be prepared to receive as it's output
buffer, holding register and ISR empties and it reacts to
my notification? What's the worst-case latency on the ISR
being handled IN THAT BOX? How slow have *I* been to
recognize that I'm backlogged? Am I (ISR) reacting to a
character received many character-times earlier?
If I send an in-band signal to convey the same information,
how long before that reaches the wire? And, propagates
up the receiving stack to a point where the other device
can recognize my "signal"? Then, all of the above questions
repeat, again.
Will in-band signals be accepted if the link relies on hardware
handshaking (pacing) signals? Will they be elided if encountered
in messages EVEN WHEN NOT CONFIGURED AS SIGNALS? Which in-band
characters will be used (^S and ^Q may be the most common but they
are not immutable choices)? Will ANY received character (IXANY)
suffice to signal resumption of transmission is allowed?
What if a device misses a flow control signal? How can I
*reliably* restart it (given that I may not know what it's doing)
without contaminating the data stream?
Are they pacing signals or handshaking signals (most folks
have never had to deal with the original Standard's
implementation!)?
Does the device send two stop bits but only check for one?
Is parity generated? Is received parity *checked* (or just
an extra bit-time in the character frame)? Does the device
send/acknowledge long BREAKs? Does it use /n, /r, either,
or both as a line delimiter? Is the line buffered before
delivery to the application layer?
Does it expect additional delay at \r? \n? \t? \b? \f? \v?
Does it reliably support every data rate advertised? Who
chose the cable -- and how? What is the impact on the device's
overall functionality of increasing data rates? Of mismatched
rates?
Repeat all of this from the vantage point of the other device;
how will *it* expect ME to behave? And, how will it react if
I MISbehave? (will an input buffer overrun because it was naively
sized for fixed-length messages?) How will *I* react if *it* misbehaves?
PCs are ubiquitous. Yet, have you ever seen any of these issues
quantified and published in a form that you could rely on in a
design? If I use one of the modem control signals to turn around
a bidirectional transceiver, how do I know that the last character
has *cleared* it AT THE TIME THE SIGNAL ASSERTS? How do I guarantee
that the code runs on some other PC, equivalently??
If you are coding on bare metal, you can answer these questions from
YOUR end of the wire. If you are relying on a COTS device with
"drivers" in place, then good luck finding the information (unless
you can examine the schematics and source code and reverse engineer
the limits of their implementation -- or, replace it entirely).
People expecting to have an answer to these questions before
*touching* a COTS product are woefully naive. People expecting
others to do their work FOR them are just opportunistic cads.
(Or, profoundly incompetent)