Boxed MCU with RS-232 Port

On 3/24/2023 8:08 AM, Rick C wrote:

>> Although for quantity 20 at these kind of price points, I might be tempted
>> to build something using dev boards, eg:
>> https://www.dfrobot.com/product-1030.html
>> and maybe a bit of 3D printing for an enclosure. For two of those boards
>> you might need to hand-patch one to use different pins, but it's not hard
>> and could be done.
> 
> This device is exactly what makes this difficult.  Which pin on the DB9 is the data output?

"Nominal" signal directions are specified from the standpoint of the *DTE*.
Remember that one rule and everything else falls into place.  I.e., a DCE
*receives* data on the "Transmit Data" pin and transmits on the "Receive
Data" pin.

[Null Modem cables came into being because DTEs wanted to talk to DTEs.
So, *both* want to transmit on the TxD signal -- and thus need a pin
swap in the cable to connect out-to-in and in-to-out... even though
both are TxD]

DTE, by convention, use *male* connectors.  That's the second thing to
remember.

Identify pin #1.  Count sideways to the next pin; that will be RxD -- the
INPUT for the DTE device.  The next pin will be TxD -- the OUTPUT for the
DTE device.  (This for a DB9; using a DB25 changes this relative order).

It's not that hard (though folks tend to confuse themselves by getting
the frame of reference wrong -- esp when looking at UART chipsets
that want to label their pins TxD and RxD -- even if they are wired to
RxD and TxD, respectively, on the DB9, as is the case when implementing
a DCE).

Folks have historically bastardized all of these conventions -- for
"good reasons" (or, so they thought).  But, a device (module) designed
for general use IN THE 21st CENTURY should have been designed with some
adherence to convention (i.e., male connector for DTE, female for DCE;
DTE transmits on TxD, DCE transmits on RxD).  It's highly unlikely
that you're going to find a device that handshakes using SRTS or RLSD!

The roles of the control signals can quickly become confused as older
kit uses them in the original *interlocked* fashion of RS232C while
newer interpretations of the standard(s) have altered that behavior
(because most devices aren't as pathetically slow as 103 modems!)

[But, I think TWX, TELEX, et al. are long dead and gone]

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> You didn't answer the question.  Which pin is the data output and
> which is the data input?

The transmit pin (TXD, pin 2 in that table) is the output and the
receive pin (RXD, pin 3) is the input.  Since it is a female connector,
by the standard, the box is considered data communications equipment
(DCE), rather than data terminal equipment (DTR).  If it was DTR, the
two pins would be switched around.  Is that what you are asking?  In any
case, one always has to test to be sure.

>> https://www.digikey.com/en/products/detail/dfrobot/DFR0258/6588574 
> Are you going to make the cable required? 

A splitter cable?  I thought I posted a url to order those from.

> Recycling is not a problem, as long as there is no branding on the box. 

There could be a label with your own branding, strategically placed to
cover up any existing branding, if that works for you.  

> Are you going to write the USB stack to run on the simple CPUs you
> have linked to?

It exists already on some of them.  I wouldn't write a new one.

>> TTL to RS232 (?): https://www.sparkfun.com/products/449 
>> Similar: https://www.waveshare.com/wiki/RS232_Board 
> I don't know why you are showing all these devices.  

There are tons of cpus with built in UARTs 

> I don't know.  Why does this matter?  You won't be visiting the
> customer's site.

Somebody at some point might have to do that.  I hope not, but the
saying is, hope for the best and plan for the worst.

Frankly the first thing I would try is taking one of your homebrew boxes
that is known to be failing, swapping out the homemade level shifter PCB
with one of the ones linked above, and seeing if that works.  Or at
least, use a scope to check the voltages coming out of the homemade PCB.

> You seem to be thrashing around in looking at every little board that
> might or might not do the job, rather than finding one that will.

It is a two step process: 1) identify possible candidates; 2) pick one.

Posting links to those boards is in part a demonstration that such
boards exist.

> The single port boards you've identified have the DB9 connector, but
> you don't indicate how you will split this into the two connectors
> required for the job.  Do you understand the requirements? 

I believe so.  There are premade splitter cables that separate pins 2
and 3 from a DB9 into two more DB9's, or such a thing can be made, or
(preferable) one can use a CPU with two serial ports (or USB split into
two ports).  The splitter cable can be inside the box since IIRC you
don't want it flopping around on the outside.  Then the two DB9's would
be on the rear panel.

On Friday, March 24, 2023 at 6:35:39 PM UTC-4, Don Y wrote:
> On 3/24/2023 8:08 AM, Rick C wrote: 
> 
> >> Although for quantity 20 at these kind of price points, I might be tempted 
> >> to build something using dev boards, eg: 
> >> https://www.dfrobot.com/product-1030.html 
> >> and maybe a bit of 3D printing for an enclosure. For two of those boards 
> >> you might need to hand-patch one to use different pins, but it's not hard 
> >> and could be done. 
> > 
> > This device is exactly what makes this difficult. Which pin on the DB9 is the data output?
> "Nominal" signal directions are specified from the standpoint of the *DTE*. 
> Remember that one rule and everything else falls into place. I.e., a DCE 
> *receives* data on the "Transmit Data" pin and transmits on the "Receive 
> Data" pin. 
> 
> [Null Modem cables came into being because DTEs wanted to talk to DTEs. 
> So, *both* want to transmit on the TxD signal -- and thus need a pin 
> swap in the cable to connect out-to-in and in-to-out... even though 
> both are TxD] 
> 
> DTE, by convention, use *male* connectors. That's the second thing to 
> remember. 
> 
> Identify pin #1. Count sideways to the next pin; that will be RxD -- the 
> INPUT for the DTE device. The next pin will be TxD -- the OUTPUT for the 
> DTE device. (This for a DB9; using a DB25 changes this relative order). 
> 
> It's not that hard (though folks tend to confuse themselves by getting 
> the frame of reference wrong -- esp when looking at UART chipsets 
> that want to label their pins TxD and RxD -- even if they are wired to 
> RxD and TxD, respectively, on the DB9, as is the case when implementing 
> a DCE). 
> 
> Folks have historically bastardized all of these conventions -- for 
> "good reasons" (or, so they thought). But, a device (module) designed 
> for general use IN THE 21st CENTURY should have been designed with some 
> adherence to convention (i.e., male connector for DTE, female for DCE; 
> DTE transmits on TxD, DCE transmits on RxD). It's highly unlikely 
> that you're going to find a device that handshakes using SRTS or RLSD! 
> 
> The roles of the control signals can quickly become confused as older 
> kit uses them in the original *interlocked* fashion of RS232C while 
> newer interpretations of the standard(s) have altered that behavior 
> (because most devices aren't as pathetically slow as 103 modems!) 
> 
> [But, I think TWX, TELEX, et al. are long dead and gone]

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? 

-- 

Rick C.

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

Paul Rubin <no.email@nospam.invalid> writes:
> (DCE), rather than data terminal equipment (DTR).  If it was DTR, the
> two pins would be switched around.

Sorry I meant DTE, not DTR.  DTR is one of the signal pins.  I believe I
got the assignments right for DCE but maybe not.  Anyway there are only
two possibilities, and it's very easy to get stuff switched around
someplace, so one always has to check.  

On Friday, March 24, 2023 at 9:19:59 PM UTC-4, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes: 
> > You didn't answer the question. Which pin is the data output and 
> > which is the data input?
> The transmit pin (TXD, pin 2 in that table) is the output and the 
> receive pin (RXD, pin 3) is the input. Since it is a female connector, 
> by the standard, the box is considered data communications equipment 
> (DCE), rather than data terminal equipment (DTR). If it was DTR, the 
> two pins would be switched around. Is that what you are asking? In any 
> case, one always has to test to be sure.

You are providing links to hardware.  I'm asking you which pin is data out and which pin is data in?  This is a very simple question, no? 


> >> https://www.digikey.com/en/products/detail/dfrobot/DFR0258/6588574 
> > Are you going to make the cable required?
> A splitter cable? I thought I posted a url to order those from.

Do you know if that splitter will work for this application?  I don't see the link.  How many messages back, or how many days/weeks ago was that?  You posted a lot of links in the message I replied to. 


> > Recycling is not a problem, as long as there is no branding on the box.
> There could be a label with your own branding, strategically placed to 
> cover up any existing branding, if that works for you.
> > Are you going to write the USB stack to run on the simple CPUs you 
> > have linked to?
> It exists already on some of them. I wouldn't write a new one.

Can't use a USB dongle if there's no USB software. 


> >> TTL to RS232 (?): https://www.sparkfun.com/products/449 
> >> Similar: https://www.waveshare.com/wiki/RS232_Board 
> > I don't know why you are showing all these devices.
> There are tons of cpus with built in UARTs

Having a UART is not sufficient.  The interface needs to be a DB9 male, RS-232 voltage levels.  One connector for the input data, and one connector for the output data. 


> > I don't know. Why does this matter? You won't be visiting the 
> > customer's site.
> Somebody at some point might have to do that. I hope not, but the 
> saying is, hope for the best and plan for the worst. 

That is far outside your concern. 


> Frankly the first thing I would try is taking one of your homebrew boxes 
> that is known to be failing, swapping out the homemade level shifter PCB 
> with one of the ones linked above, and seeing if that works. Or at 
> least, use a scope to check the voltages coming out of the homemade PCB.
> > You seem to be thrashing around in looking at every little board that 
> > might or might not do the job, rather than finding one that will.
> It is a two step process: 1) identify possible candidates; 2) pick one. 

Have you picked one yet? 


> Posting links to those boards is in part a demonstration that such 
> boards exist.

I've never needed convincing that these boards exist.  


> > The single port boards you've identified have the DB9 connector, but 
> > you don't indicate how you will split this into the two connectors 
> > required for the job. Do you understand the requirements?
> I believe so. There are premade splitter cables that separate pins 2 
> and 3 from a DB9 into two more DB9's, or such a thing can be made, or 
> (preferable) one can use a CPU with two serial ports (or USB split into 
> two ports). The splitter cable can be inside the box since IIRC you 
> don't want it flopping around on the outside. Then the two DB9's would 
> be on the rear panel.

Does the splitter cable run a signal to pins 2 and 3 on both cables?  I've yet to find one that connects to pin 2 on one connector and pin 3 on the other connector, leaving the other pins 2 and 3 unconnected. 

I think you will find the splitter cable will need to be a custom design.  It's probably easier to just use a CPU without a DB9 and build a cable to run from the header to the two DB9s on the box.  But then you will need a CPU card with RS232 level shifters.  

This is why I don't want to do the design.  It's messy and far too much work for something so simple.  

-- 

Rick C.

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

On 3/24/2023 6:21 PM, Rick C wrote:
> On Friday, March 24, 2023 at 6:35:39 PM UTC-4, Don Y wrote:
>> On 3/24/2023 8:08 AM, Rick C wrote:
>>
>>>> Although for quantity 20 at these kind of price points, I might be tempted
>>>> to build something using dev boards, eg:
>>>> https://www.dfrobot.com/product-1030.html
>>>> and maybe a bit of 3D printing for an enclosure. For two of those boards
>>>> you might need to hand-patch one to use different pins, but it's not hard
>>>> and could be done.
>>>
>>> This device is exactly what makes this difficult. Which pin on the DB9 is the data output?
>> "Nominal" signal directions are specified from the standpoint of the *DTE*.
>> Remember that one rule and everything else falls into place. I.e., a DCE
>> *receives* data on the "Transmit Data" pin and transmits on the "Receive
>> Data" pin.
>>
>> [Null Modem cables came into being because DTEs wanted to talk to DTEs.
>> So, *both* want to transmit on the TxD signal -- and thus need a pin
>> swap in the cable to connect out-to-in and in-to-out... even though
>> both are TxD]
>>
>> DTE, by convention, use *male* connectors. That's the second thing to
>> remember.
>>
>> Identify pin #1. Count sideways to the next pin; that will be RxD -- the
>> INPUT for the DTE device. The next pin will be TxD -- the OUTPUT for the
>> DTE device. (This for a DB9; using a DB25 changes this relative order).
>>
>> It's not that hard (though folks tend to confuse themselves by getting
>> the frame of reference wrong -- esp when looking at UART chipsets
>> that want to label their pins TxD and RxD -- even if they are wired to
>> RxD and TxD, respectively, on the DB9, as is the case when implementing
>> a DCE).
>>
>> Folks have historically bastardized all of these conventions -- for
>> "good reasons" (or, so they thought). But, a device (module) designed
>> for general use IN THE 21st CENTURY should have been designed with some
>> adherence to convention (i.e., male connector for DTE, female for DCE;
>> DTE transmits on TxD, DCE transmits on RxD). It's highly unlikely
>> that you're going to find a device that handshakes using SRTS or RLSD!
>>
>> The roles of the control signals can quickly become confused as older
>> kit uses them in the original *interlocked* fashion of RS232C while
>> newer interpretations of the standard(s) have altered that behavior
>> (because most devices aren't as pathetically slow as 103 modems!)
>>
>> [But, I think TWX, TELEX, et al. are long dead and gone]
> 
> 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?

"Nominal" signal directions are specified from the standpoint of the *DTE*.
Remember that one rule and everything else falls into place. I.e., a DCE
*receives* data on the "Transmit Data" pin and transmits on the "Receive
Data" pin.

DTE, by convention, use *male* connectors. That's the second thing to remember.

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> You are providing links to hardware.  I'm asking you which pin is data
> out and which pin is data in?  This is a very simple question, no?

Didn't I answer?   I wrote:

>> The transmit pin (TXD, pin 2 in that table) is the output and the 
>> receive pin (RXD, pin 3) is the input.

Pin 2 = data out, pin 3 = data in.  Is something missing from that
answer?  There is a possibility that it is wrong and that the two are
switched, but that would show up immediately during testing.

>> A splitter cable? I thought I posted a url to order those from.
> Do you know if that splitter will work for this application?

It sounded to me like it should, but part of the task is to put the
stuff together and test it.  Anyway I think it is better to use a board
with two uarts.  I checked, and the Arduino Leonardo has two, so it
sounds like that is a suitable board if you want to use the Arduino
approach.  

> Can't use a USB dongle if there's no USB software. 
The USB software is present in the boards that have USB host ports.

>> >> TTL to RS232 (?): https://www.sparkfun.com/products/449 
>> >> Similar: https://www.waveshare.com/wiki/RS232_Board 
>> > I don't know why you are showing all these devices.
>> There are tons of cpus with built in UARTs
>
> Having a UART is not sufficient.  The interface needs to be a DB9
> male, RS-232 voltage levels.  One connector for the input data, and
> one connector for the output data.

Right, that is the purpose of those boards that I linked.  To convert
TTL levels to RS232 levels.  You connect the UART to the level converter
board.  That is pretty much the same thing that you already did with the
homemade MAX232(?) PCB, thus the idea of swapping in this other board
and seeing if it works where your existing one doesn't.

> That is far outside your concern. 

I am glad to hear this.  So what happens if I ship you boxes that I've
tested on my bench and that supply the right voltages as shown on a
scope, but only half of them work at the customer site, like with your
boards?  Who is responsible?

> Have you picked one yet? 

The Leonardo looks good to me but obviously I would want to test an
evaluation unit before settling on it.

> Does the splitter cable run a signal to pins 2 and 3 on both cables?
> I've yet to find one that connects to pin 2 on one connector and pin 3
> on the other connector, leaving the other pins 2 and 3 unconnected.

I would have to check that.  However, disconnecting pin 2 or 3 can in a
cable like that can be done with a wire cutter.

> I think you will find the splitter cable will need to be a custom
> design.  It's probably easier to just use a CPU without a DB9 and
> build a cable to run from the header to the two DB9s on the box.  But
> then you will need a CPU card with RS232 level shifters.

The suggestion further up is to use that level shifter card.

> This is why I don't want to do the design.  It's messy and far too
> much work for something so simple.

Yes, that's why nobody else wanted to do it either until you mentioned a
figure of $300 per box.  That is enough to cover the necessary amount of
derping around that always afflicts a project like this.  You've done a
lot more hardware stuff than I have, so I shouldn't be the one who has
to explain that.

On Friday, March 24, 2023 at 10:44:06 PM UTC-4, Paul Rubin wrote:
> Rick C <gnuarm.del...@gmail.com> writes: 
> > You are providing links to hardware. I'm asking you which pin is data 
> > out and which pin is data in? This is a very simple question, no?
> Didn't I answer? I wrote: 
> 
> >> The transmit pin (TXD, pin 2 in that table) is the output and the 
> >> receive pin (RXD, pin 3) is the input.
> Pin 2 = data out, pin 3 = data in. Is something missing from that 
> answer? There is a possibility that it is wrong and that the two are 
> switched, but that would show up immediately during testing.
> >> A splitter cable? I thought I posted a url to order those from. 
> > Do you know if that splitter will work for this application?
> It sounded to me like it should, but part of the task is to put the 
> stuff together and test it. 

Yeah, that's just what engineers do.  They throw some stuff together and test it, over and over, rather than actually understanding the requirements. 

I'm trying to get you to understand the issues, but you just aren't getting it.  I don't know how a cable I have no info on is wired.  But if pin 3 on the CPU connector goes to pin 2 on both of the cable connectors, then it's not likely to work properly is it?  Two drivers on the same pin sound like a bad idea to me. 


> Anyway I think it is better to use a board 
> with two uarts. I checked, and the Arduino Leonardo has two, so it 
> sounds like that is a suitable board if you want to use the Arduino 
> approach.

Does it have RS-232 driver chips? 


> > Can't use a USB dongle if there's no USB software.
> The USB software is present in the boards that have USB host ports.

I would hope so.  Do any of the boards you are talking about have USB host ports?  Typically the small CPU boards use a USB to serial port chip to support bootloading, with no drivers on the CPU to host USB. 


> >> >> TTL to RS232 (?): https://www.sparkfun.com/products/449 
> >> >> Similar: https://www.waveshare.com/wiki/RS232_Board 
> >> > I don't know why you are showing all these devices. 
> >> There are tons of cpus with built in UARTs 
> > 
> > Having a UART is not sufficient. The interface needs to be a DB9 
> > male, RS-232 voltage levels. One connector for the input data, and 
> > one connector for the output data.
> Right, that is the purpose of those boards that I linked. To convert 
> TTL levels to RS232 levels. You connect the UART to the level converter 
> board. That is pretty much the same thing that you already did with the 
> homemade MAX232(?) PCB, thus the idea of swapping in this other board 
> and seeing if it works where your existing one doesn't.
> > That is far outside your concern.
> I am glad to hear this. So what happens if I ship you boxes that I've 
> tested on my bench and that supply the right voltages as shown on a 
> scope, but only half of them work at the customer site, like with your 
> boards? Who is responsible?

I think that is something we can worry about later.  So far, I'm not sure you can produce any boxes. 


> > Have you picked one yet?
> The Leonardo looks good to me but obviously I would want to test an 
> evaluation unit before settling on it.
> > Does the splitter cable run a signal to pins 2 and 3 on both cables? 
> > I've yet to find one that connects to pin 2 on one connector and pin 3 
> > on the other connector, leaving the other pins 2 and 3 unconnected.
> I would have to check that. However, disconnecting pin 2 or 3 can in a 
> cable like that can be done with a wire cutter.
> > I think you will find the splitter cable will need to be a custom 
> > design. It's probably easier to just use a CPU without a DB9 and 
> > build a cable to run from the header to the two DB9s on the box. But 
> > then you will need a CPU card with RS232 level shifters.
> The suggestion further up is to use that level shifter card.
> > This is why I don't want to do the design. It's messy and far too 
> > much work for something so simple.
> Yes, that's why nobody else wanted to do it either until you mentioned a 
> figure of $300 per box. That is enough to cover the necessary amount of 
> derping around that always afflicts a project like this. You've done a 
> lot more hardware stuff than I have, so I shouldn't be the one who has 
> to explain that.

When you get the details worked out, and wish to discuss a price, let me know through email.  

Thanks

-- 

Rick C.

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

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> I'm trying to get you to understand the issues, but you just aren't
> getting it.  I don't know how a cable I have no info on is wired.  But
> if pin 3 on the CPU connector goes to pin 2 on both of the cable
> connectors, then it's not likely to work properly is it?  Two drivers
> on the same pin sound like a bad idea to me.

Again there is a 3 step process going on: 1) note that a product of this
sort exists, without remembering too much detail about it.  2) find the
product description page again, and this time study it carefully
including the pin diagrams, to develop a theory of whether it does the
right thing and which pins to connect or disconnect.  3) actually buy
the cable and test the theory.

Right now we are at step 1.  I think it is best to avoid the whole thing
though.  The approach of splitting the pins out from a single port is
too kludgy, if it is at all practical to use two ports.

> [Arduino Leonardo] Does it have RS-232 driver chips? 

No it does not.  That is why I linked those level shifter cards.

> I would hope so.  Do any of the boards you are talking about have USB
> host ports?

The ESP32-S2 has it.  Here are the API docs:

https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-reference/peripherals/usb_host.html

The CDC (communication device class) software is here:

https://github.com/espressif/esp-idf/tree/master/examples/peripherals/usb/host/cdc/cdc_acm_vcp

It looks like a potential pain in the neck to use.  I currently have an
Adafruit Feather board with that chip so maybe I will try it.

The chip also supports wifi and bluetooth, fwiw.  The software stacks
for both of those are way more complicated than USB.

> When you get the details worked out, and wish to discuss a price, let
> me know through email.

OK.

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.