Boxed MCU with RS-232 Port

On Saturday, March 25, 2023 at 9:42:21 PM UTC-4, George Neuner wrote:
> On Fri, 24 Mar 2023 18:21:21 -0700 (PDT), Rick C 
> <gnuarm.del...@gmail.com> wrote: 
> 
> >Excellent 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.

You are confused.  I don't need any information about RS-232.  Everything you are talking about is irrelevant.  Virtually NO ONE uses RS-232 to connect DCE to DTE.  They simply are tying together two devices that wish to use asynch serial at RS-232 voltage levels. 

But neither you nor Don seem to understand that.  I was trying to lead Don to this conclusion by asking pointed questions, but that failed.  You, however, seem to have the same problem Don does.  

I often have this problem with people who don't actually understand how RS-232 is used.  There are people who view the world through data sheets and specification standards.  Then there's the real world, where you have to toss out some of that, and ask questions like, "Which pin is output and which pin is input?"  If the person you are talking to gives you anything other than a pin number, you are talking to the wrong person.  

Engineers design stuff.  Technicians figure out how to make it work. 

-- 

Rick C.

--++- Get 1,000 miles of free Supercharging
--++- Tesla referral code - https://ts.la/richard11209

On 2023-03-26, Rick C <gnuarm.deletethisbit@gmail.com> wrote:
>
> I often have this problem with people who don't actually understand 
> how RS-232 is used.  There are people who view the world through data 
> sheets and specification standards.  Then there's the real world, 
> where you have to toss out some of that, and ask questions like, 
> "Which pin is output and which pin is input?"  If the person you are 
> talking to gives you anything other than a pin number, you are talking 
> to the wrong person.

Many years ago I often had to connect up gear with RS232 interfaces, and 
it was a pain, as there was often no manual for the gear or the manual 
was badly written and the author used the RS232 "standard" terms in a 
cavalier way.

So I used an RS232 breakout box to try and identify RXD and TXD, and 
what the various pins did, and what had to be strapped to what to get 
either end to speak! Oh happy days - NOT!

Good luck with the project.

Hard to believe the long fossilized RS-232 horse can get all that
beating again...
Next thing let's beat the baud rate detection? :D

On 3/25/2023 6:42 PM, George Neuner wrote:
> On Fri, 24 Mar 2023 18:21:21 -0700 (PDT), Rick C
> <gnuarm.deletethisbit@gmail.com> wrote:
> 
>> Excellent 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)

On 3/26/2023 11:27 AM, Jim Jackson wrote:
> Many years ago I often had to connect up gear with RS232 interfaces, and
> it was a pain, as there was often no manual for the gear or the manual
> was badly written and the author used the RS232 "standard" terms in a
> cavalier way.

Folks who haven't designed communications equipment where RS232 (in its
various bastardized forms) don't understand that commenting on a product
chosen (seemingly) at random from a producer of unknown character is
pure folly.  Simply because the folks who design said pieces of
kit are operating often in ignorance -- trying to make a device that
mates with X instead of a device that conforms to a standard.

This is a common problem when folks try to "bottom feed".

> So I used an RS232 breakout box to try and identify RXD and TXD, and
> what the various pins did, and what had to be strapped to what to get
> either end to speak! Oh happy days - NOT!

There were "magic (active) cables" produced years ago that would,
automatically, adapt to common pinout incompatibilities.  But, "common"
is the operative word, here.  And, if you were in a market where
*many* of the pins on a DB25 were active, they were just toy solutions.

Just getting the pinout to *appear* correct is only part of the story.
You also need to know how they have implemented the signaling protocol
and the timing thereof (see my reply to George, upthread)

I have encountered devices made by "established companies" that use
all sorts of different signaling schemes as well as pinouts.  As
I mentioned in an earlier post, seeing SRTS used for flow control, or
RLSD, etc.  I'm sure there's a reason they made these bastardizations
but, regardless, I had to live with it as the vendor isn't going to
"fix" his implementation just to satisfy my beliefs.

As I have had to design many such devices, over the years, to interact
with many *other* devices (they having undisclosed design goals), I
quickly learned to accumulate a set of "widgets" that would allow me
to quickly make common signal swaps.  Then, once each end of the link
looked like a DCE or DTE, a straight-through cable solved the ELECTRICAL
problem.

[E.g., I can understand APC's bastardization, below.  Almost.  Yet,
feel they could have implemented the feature set in a more compatible
way...]

I build these into connector shells that are designed to support a
pair of back-to-back connectors (DB9 or 25) and then affix a label
telling me the device that it is intended to normalize (e.g., I have
one at my feet that "fixes" APC's UPS serial port) *or* the function
it is intended to perform (gender change, NULL modem, NULL 'terminal'!,
etc.)

An early employer (specializing in comms kit!) had a huge box
full of assorted (and undocumented) cables.  One of the first
chores on any project was finding a suitable cable to mate
to the device in question.  This involved untangling dozens of
cords and *trying* each, in turn, until some signs of life
appeared.  Then, refining the selection.

I pitched the idea of the small (2"x2") widgets paired with
a straight-through cable.  Discard the box of random wire
and keep a shoebox full of the little widgets -- and ONLY
straight through, M-F cables.  Sometimes I have to stack
a few "widgets" to get the requisite signal pairing.
But, then know how to make a new widget that is tailored
to THIS device (and labeled as such)

> Good luck with the project.

On 3/26/2023 1:23 PM, Don Y wrote:
> I build these into connector shells that are designed to support a
> pair of back-to-back connectors (DB9 or 25) and then affix a label
> telling me the device that it is intended to normalize (e.g., I have
> one at my feet that "fixes" APC's UPS serial port) *or* the function
> it is intended to perform (gender change, NULL modem, NULL 'terminal'!,
> etc.)

This is the APC widget mentioned:
<https://mega.nz/file/J35SBBob#FtQznCDovhBZHJdA5OspHdMo6_DiDMjQwtCqnh3Oa54>

By (my) convention, the named device ("UPS") is located at the
connector from which the label can be read (i.e., the connector
to the right).

The jack screws -- in the context of that device -- act as a further
hint.

If I want to know what's inside, I have to look up the schematic
for the widget -- unless the function is obvious (e.g., gender
change).

On 3/25/2023 7:26 PM, Rick C wrote:
> Engineers design stuff.  Technicians figure out how to make it work.

And you apparently do neither.  <frown>

On 3/26/2023 1:32 PM, Don Y wrote:
> On 3/26/2023 1:23 PM, Don Y wrote:
>> I build these into connector shells that are designed to support a
>> pair of back-to-back connectors (DB9 or 25) and then affix a label
>> telling me the device that it is intended to normalize (e.g., I have
>> one at my feet that "fixes" APC's UPS serial port) *or* the function
>> it is intended to perform (gender change, NULL modem, NULL 'terminal'!,
>> etc.)
> 
> This is the APC widget mentioned:
> <https://mega.nz/file/J35SBBob#FtQznCDovhBZHJdA5OspHdMo6_DiDMjQwtCqnh3Oa54>

And this is the COTS *PC* that I use as a name server:
   <https://mega.nz/file/Fi4hEACJ#YgVZ5tdZBjTcwW76gXC2vdgv5M6u4lTpUDAwu53Z9n8>

Note the *two* serial ports (DTE as the standard dictates), 100BaseT
network connection (it's just a name server, it doesn't need to
have high throughput), PS/2 keyboard and VGA (cuz it's a PC!),
wifi and USB.  The four mounting holes visible are the VESA standard
(I have these mounted between my monitor and support arm)

As an ISA PC, it will run damn near any OS intended for such
a platform (I run NetBSD on this box).  So, all of the PC hosted
AND TARGETED tools are available (I have a LFC monitor wired to
one of the serial ports to discipline my time service as that
was easier/cheaper to implement than any other solution!).

On Sunday, March 26, 2023 at 2:27:14 PM UTC-4, Jim Jackson wrote:
> On 2023-03-26, Rick C <gnuarm.del...@gmail.com> wrote: 
> > 
> > I often have this problem with people who don't actually understand 
> > how RS-232 is used. There are people who view the world through data 
> > sheets and specification standards. Then there's the real world, 
> > where you have to toss out some of that, and ask questions like, 
> > "Which pin is output and which pin is input?" If the person you are 
> > talking to gives you anything other than a pin number, you are talking 
> > to the wrong person.
> Many years ago I often had to connect up gear with RS232 interfaces, and 
> it was a pain, as there was often no manual for the gear or the manual 
> was badly written and the author used the RS232 "standard" terms in a 
> cavalier way. 
> 
> So I used an RS232 breakout box to try and identify RXD and TXD, and 
> what the various pins did, and what had to be strapped to what to get 
> either end to speak! Oh happy days - NOT! 
> 
> Good luck with the project.

Fortunately, this effort only uses TX and GND on one port and RX and GND on the other port.  I don't care what the TX and RX pins are called, one is input, the other output and we just need to connect the input to the device that is sending the data and connect the output to the device that is receiving data.  All this has already been worked out and a prototype was built.  Unfortunately there is some problem that results in a hung unit from time to time.  That developer doesn't have the time to mess with it, so we are looking elsewhere.  But the pin assignments are not a problem, just people's perspective on the issue. 

-- 

Rick C.

--+++ Get 1,000 miles of free Supercharging
--+++ Tesla referral code - https://ts.la/richard11209

On Sunday, March 26, 2023 at 4:25:49 PM UTC-4, Don Y wrote:
> On 3/26/2023 11:27 AM, Jim Jackson wrote: 
> > Many years ago I often had to connect up gear with RS232 interfaces, and 
> > it was a pain, as there was often no manual for the gear or the manual 
> > was badly written and the author used the RS232 "standard" terms in a 
> > cavalier way.
> Folks who haven't designed communications equipment where RS232 (in its 
> various bastardized forms) don't understand that commenting on a product 
> chosen (seemingly) at random from a producer of unknown character is 
> pure folly. Simply because the folks who design said pieces of 
> kit are operating often in ignorance -- trying to make a device that 
> mates with X instead of a device that conforms to a standard. 

And there is the problem.  The RS-232 standard defines the interface between data terminal equipment and data communication equipment, at the data communication equipment interface.  It says nothing about anything else.  However, people use these voltages and so these level shifting devices, often along with the same type of connectors for many *other* applications.  At that point, the RS-232 standard does not apply in a consistent way.  So people are free to pick and choose the parts they want, and the parts they don't want. 

The RS-232 moniker is often used, when even the voltage levels are not the same.  At that point, there is nothing RS-232 about it.  People are just using the term as a synonym for an async serial port. 

-- 

Rick C.

-+--- Get 1,000 miles of free Supercharging
-+--- Tesla referral code - https://ts.la/richard11209