Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #28502 > unrolled thread

Serial Port Emulation

Back to article view | Back to comp.arch.embedded

Contents

  Serial Port Emulation gnuarm.deletethisbit@gmail.com - 2019-02-17 02:08 -0800
    Re: Serial Port Emulation David Brown <david.brown@hesbynett.no> - 2019-02-17 13:42 +0100
      Re: Serial Port Emulation Chris <xxx.syseng.yyy@gfsys.co.uk> - 2019-02-17 15:49 +0000
    Re: Serial Port Emulation Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2019-02-17 18:54 +0200
      Re: Serial Port Emulation David Brown <david.brown@hesbynett.no> - 2019-02-17 21:16 +0100
        Re: Serial Port Emulation Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2019-02-18 10:38 +0200
          Re: Serial Port Emulation David Brown <david.brown@hesbynett.no> - 2019-02-18 10:49 +0100
            Re: Serial Port Emulation Richard Damon <Richard@Damon-Family.org> - 2019-02-18 07:25 -0500
              Re: Serial Port Emulation David Brown <david.brown@hesbynett.no> - 2019-02-18 14:31 +0100
                Re: Serial Port Emulation Andrew Smallshaw <andrews@sdf.org> - 2019-02-19 16:10 +0000
                  Re: Serial Port Emulation gnuarm.deletethisbit@gmail.com - 2019-02-19 09:12 -0800
                    Re: Serial Port Emulation upsidedown@downunder.com - 2019-02-19 19:58 +0200
                      Re: Serial Port Emulation Grant Edwards <invalid@invalid.invalid> - 2019-02-19 18:22 +0000
                    Re: Serial Port Emulation David Brown <david.brown@hesbynett.no> - 2019-02-19 22:50 +0100
                      Re: Serial Port Emulation Grant Edwards <invalid@invalid.invalid> - 2019-02-19 22:23 +0000
                        Re: Serial Port Emulation David Brown <david.brown@hesbynett.no> - 2019-02-20 08:53 +0100
                          Re: Serial Port Emulation upsidedown@downunder.com - 2019-02-20 10:17 +0200
                      Re: Serial Port Emulation Theo <theom+news@chiark.greenend.org.uk> - 2019-02-19 22:35 +0000
                        Re: Serial Port Emulation upsidedown@downunder.com - 2019-02-20 01:36 +0200
                        Re: Serial Port Emulation gnuarm.deletethisbit@gmail.com - 2019-02-19 19:40 -0800
                          Re: Serial Port Emulation David Brown <david.brown@hesbynett.no> - 2019-02-20 09:00 +0100
                  Re: Serial Port Emulation upsidedown@downunder.com - 2019-02-19 19:16 +0200
                  Re: Serial Port Emulation Theo <theom+news@chiark.greenend.org.uk> - 2019-02-19 22:28 +0000
                    Re: Serial Port Emulation David Brown <david.brown@hesbynett.no> - 2019-02-20 10:32 +0100
                  Re: Serial Port Emulation Robert Wessel <robertwessel2@yahoo.com> - 2019-02-19 18:44 -0600
                  Re: Serial Port Emulation Les Cargill <lcargill99@comcast.com> - 2019-02-23 14:48 -0600
                    Re: Serial Port Emulation Robert Wessel <robertwessel2@yahoo.com> - 2019-02-23 16:34 -0600
                      Re: Serial Port Emulation Les Cargill <lcargill99@comcast.com> - 2019-02-27 22:15 -0600
                        Re: Serial Port Emulation David Brown <david.brown@hesbynett.no> - 2019-02-28 08:41 +0100
                          Re: Serial Port Emulation gnuarm.deletethisbit@gmail.com - 2019-02-28 15:07 -0800
                            Re: Serial Port Emulation David Brown <david.brown@hesbynett.no> - 2019-03-01 10:04 +0100
                              Re: Serial Port Emulation gnuarm.deletethisbit@gmail.com - 2019-03-01 13:09 -0800
                              Re: Serial Port Emulation Les Cargill <lcargill99@comcast.com> - 2019-03-04 17:58 -0600
                            Re: Serial Port Emulation Paul Rubin <no.email@nospam.invalid> - 2019-03-01 02:25 -0800
                              Re: Serial Port Emulation gnuarm.deletethisbit@gmail.com - 2019-03-01 13:16 -0800
                                Re: Serial Port Emulation Paul Rubin <no.email@nospam.invalid> - 2019-03-01 16:45 -0800
                          Re: Serial Port Emulation Les Cargill <lcargill99@comcast.com> - 2019-03-04 17:44 -0600
                    Re: Serial Port Emulation Richard Damon <Richard@Damon-Family.org> - 2019-02-23 19:37 -0500
                      Re: Serial Port Emulation Les Cargill <lcargill99@comcast.com> - 2019-02-27 22:17 -0600
            Re: Serial Port Emulation gnuarm.deletethisbit@gmail.com - 2019-02-18 06:28 -0800
            Re: Serial Port Emulation Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2019-02-18 22:33 +0100
    Re: Serial Port Emulation "A.P.Richelieu" <aprichelieu@gmail.com> - 2019-02-17 21:06 +0100
    Re: Serial Port Emulation raimond.dragomir@gmail.com - 2019-02-17 21:56 -0800
      Re: Serial Port Emulation gnuarm.deletethisbit@gmail.com - 2019-02-17 22:37 -0800
    Re: Serial Port Emulation "Mat Nieuwenhoven" <mnieuw@zap.a2000.nl> - 2019-02-18 12:34 +0100

Page 1 of 3  [1] 2 3  Next page →

#28502 — Serial Port Emulation

I'm working to improve a test program for the hardware I use to test some boards I make.  These boards are tested using a test fixture controlled over an RS-232 port from the PC.  So I don't need to lug hardware around with me I emulate the test fixture on the same PC I run the test program.  I need comm port emulation software that will emulate a bridge between two serial ports to connect the test program and the test fixture emulator.  

One I've been using is called, oddly enough, "Free Virtual Serial Ports".  It is free to use, but only in a limited configuration which will do the job, but just barely.  I have also noticed that if my programs are not closed properly (or some other cause) this bridge software will hang one of the ports.  

I don't want to emulate the serial port connection in my test fixture emulator because if I take the program down a lot while testing, I will have to continually restart both the test program and the emulator program.  There are a few initialization steps that become tedious after doing them a few dozen times. 

Is there a serial port bridge program that works well and is not expensive?  

Rick C.

[toc] | [next] | [standalone]

#28503

On 17/02/2019 11:08, gnuarm.deletethisbit@gmail.com wrote:
> I'm working to improve a test program for the hardware I use to test some boards I make.  These boards are tested using a test fixture controlled over an RS-232 port from the PC.  So I don't need to lug hardware around with me I emulate the test fixture on the same PC I run the test program.  I need comm port emulation software that will emulate a bridge between two serial ports to connect the test program and the test fixture emulator.
> 
> One I've been using is called, oddly enough, "Free Virtual Serial Ports".  It is free to use, but only in a limited configuration which will do the job, but just barely.  I have also noticed that if my programs are not closed properly (or some other cause) this bridge software will hang one of the ports.
> 
> I don't want to emulate the serial port connection in my test fixture emulator because if I take the program down a lot while testing, I will have to continually restart both the test program and the emulator program.  There are a few initialization steps that become tedious after doing them a few dozen times.
> 
> Is there a serial port bridge program that works well and is not expensive?
> 
> Rick C.
> 

Have you considered simply having two serial ports and connecting them 
physically?  It might not be quite as elegant as a "virtual" solution, 
but it would be very realistic (regarding timing and such).  A couple of 
FTDI cables would cost something like $10.

If you are running Linux, a "virtual serial port" is just a pipe, if you 
don't need virtual baud rates and the like.  Windows is always more 
complicated - I am afraid I don't know of any suitable software as I've 
never had the need.

[toc] | [prev] | [next] | [standalone]

#28504

On 02/17/19 12:42, David Brown wrote:
> On 17/02/2019 11:08, gnuarm.deletethisbit@gmail.com wrote:
>> I'm working to improve a test program for the hardware I use to test
>> some boards I make. These boards are tested using a test fixture
>> controlled over an RS-232 port from the PC. So I don't need to lug
>> hardware around with me I emulate the test fixture on the same PC I
>> run the test program. I need comm port emulation software that will
>> emulate a bridge between two serial ports to connect the test program
>> and the test fixture emulator.
>>
>> One I've been using is called, oddly enough, "Free Virtual Serial
>> Ports". It is free to use, but only in a limited configuration which
>> will do the job, but just barely. I have also noticed that if my
>> programs are not closed properly (or some other cause) this bridge
>> software will hang one of the ports.
>>
>> I don't want to emulate the serial port connection in my test fixture
>> emulator because if I take the program down a lot while testing, I
>> will have to continually restart both the test program and the
>> emulator program. There are a few initialization steps that become
>> tedious after doing them a few dozen times.
>>
>> Is there a serial port bridge program that works well and is not
>> expensive?
>>
>> Rick C.
>>
>
> Have you considered simply having two serial ports and connecting them
> physically? It might not be quite as elegant as a "virtual" solution,
> but it would be very realistic (regarding timing and such). A couple of
> FTDI cables would cost something like $10.
>
> If you are running Linux, a "virtual serial port" is just a pipe, if you
> don't need virtual baud rates and the like. Windows is always more
> complicated - I am afraid I don't know of any suitable software as I've
> never had the need.
>

Hardware seems like the best route, since that includes modem control
lines, xon/xoff etc. Many laptops don't have serial ports these
days, but all Panasonic Toughbooks do. There are also usb to serial
and network based serial ports available and have used both in the
past with no issues, StarTech making some of the best "work out of
the box" examples...

Chris

[toc] | [prev] | [next] | [standalone]

#28505

On 17.2.19 12:08, gnuarm.deletethisbit@gmail.com wrote:
> I'm working to improve a test program for the hardware I use to test some boards I make.  These boards are tested using a test fixture controlled over an RS-232 port from the PC.  So I don't need to lug hardware around with me I emulate the test fixture on the same PC I run the test program.  I need comm port emulation software that will emulate a bridge between two serial ports to connect the test program and the test fixture emulator.
> 
> One I've been using is called, oddly enough, "Free Virtual Serial Ports".  It is free to use, but only in a limited configuration which will do the job, but just barely.  I have also noticed that if my programs are not closed properly (or some other cause) this bridge software will hang one of the ports.
> 
> I don't want to emulate the serial port connection in my test fixture emulator because if I take the program down a lot while testing, I will have to continually restart both the test program and the emulator program.  There are a few initialization steps that become tedious after doing them a few dozen times.
> 
> Is there a serial port bridge program that works well and is not expensive?
> 
> Rick C.
> 

Get a USB serial port adapter and a null modem cable,
so the test program does see any difference.

The virtual serial ports are probably more part of the
problem set than part of the solution set.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#28507

On 17/02/2019 17:54, Tauno Voipio wrote:
> On 17.2.19 12:08, gnuarm.deletethisbit@gmail.com wrote:
>> I'm working to improve a test program for the hardware I use to test 
>> some boards I make.  These boards are tested using a test fixture 
>> controlled over an RS-232 port from the PC.  So I don't need to lug 
>> hardware around with me I emulate the test fixture on the same PC I 
>> run the test program.  I need comm port emulation software that will 
>> emulate a bridge between two serial ports to connect the test program 
>> and the test fixture emulator.
>>
>> One I've been using is called, oddly enough, "Free Virtual Serial 
>> Ports".  It is free to use, but only in a limited configuration which 
>> will do the job, but just barely.  I have also noticed that if my 
>> programs are not closed properly (or some other cause) this bridge 
>> software will hang one of the ports.
>>
>> I don't want to emulate the serial port connection in my test fixture 
>> emulator because if I take the program down a lot while testing, I 
>> will have to continually restart both the test program and the 
>> emulator program.  There are a few initialization steps that become 
>> tedious after doing them a few dozen times.
>>
>> Is there a serial port bridge program that works well and is not 
>> expensive?
>>
>> Rick C.
>>
> 
> Get a USB serial port adapter and a null modem cable,
> so the test program does see any difference.
> 

"Null modem cable" ?  He doesn't need RS-232 converters and 9-pin DSUBs 
here.  A couple of USB to TTL Uart cables is what he needs, with the 
wires tied together.

<https://www.ftdichip.com/Products/Cables/USBTTLSerial.htm>

> The virtual serial ports are probably more part of the
> problem set than part of the solution set.
> 

[toc] | [prev] | [next] | [standalone]

#28510

On 17.2.19 22:16, David Brown wrote:
> On 17/02/2019 17:54, Tauno Voipio wrote:
>> On 17.2.19 12:08, gnuarm.deletethisbit@gmail.com wrote:
>>> I'm working to improve a test program for the hardware I use to test 
>>> some boards I make.  These boards are tested using a test fixture 
>>> controlled over an RS-232 port from the PC.  So I don't need to lug 
>>> hardware around with me I emulate the test fixture on the same PC I 
>>> run the test program.  I need comm port emulation software that will 
>>> emulate a bridge between two serial ports to connect the test program 
>>> and the test fixture emulator.
>>>
>>> One I've been using is called, oddly enough, "Free Virtual Serial 
>>> Ports".  It is free to use, but only in a limited configuration which 
>>> will do the job, but just barely.  I have also noticed that if my 
>>> programs are not closed properly (or some other cause) this bridge 
>>> software will hang one of the ports.
>>>
>>> I don't want to emulate the serial port connection in my test fixture 
>>> emulator because if I take the program down a lot while testing, I 
>>> will have to continually restart both the test program and the 
>>> emulator program.  There are a few initialization steps that become 
>>> tedious after doing them a few dozen times.
>>>
>>> Is there a serial port bridge program that works well and is not 
>>> expensive?
>>>
>>> Rick C.
>>>
>>
>> Get a USB serial port adapter and a null modem cable,
>> so the test program does see any difference.
>>
> 
> "Null modem cable" ?  He doesn't need RS-232 converters and 9-pin DSUBs 
> here.  A couple of USB to TTL Uart cables is what he needs, with the 
> wires tied together.
> 
> <https://www.ftdichip.com/Products/Cables/USBTTLSerial.htm>
> 
>> The virtual serial ports are probably more part of the
>> problem set than part of the solution set.
>>


Most of the off-the-shelf USB serial dongles have the 9 pin connectors
with RS-232 DTE signals, which do need null modem to connect together.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#28511

On 18/02/2019 09:38, Tauno Voipio wrote:
> On 17.2.19 22:16, David Brown wrote:
>> On 17/02/2019 17:54, Tauno Voipio wrote:
>>> On 17.2.19 12:08, gnuarm.deletethisbit@gmail.com wrote:
>>>> I'm working to improve a test program for the hardware I use to test
>>>> some boards I make.  These boards are tested using a test fixture
>>>> controlled over an RS-232 port from the PC.  So I don't need to lug
>>>> hardware around with me I emulate the test fixture on the same PC I
>>>> run the test program.  I need comm port emulation software that will
>>>> emulate a bridge between two serial ports to connect the test
>>>> program and the test fixture emulator.
>>>>
>>>> One I've been using is called, oddly enough, "Free Virtual Serial
>>>> Ports".  It is free to use, but only in a limited configuration
>>>> which will do the job, but just barely.  I have also noticed that if
>>>> my programs are not closed properly (or some other cause) this
>>>> bridge software will hang one of the ports.
>>>>
>>>> I don't want to emulate the serial port connection in my test
>>>> fixture emulator because if I take the program down a lot while
>>>> testing, I will have to continually restart both the test program
>>>> and the emulator program.  There are a few initialization steps that
>>>> become tedious after doing them a few dozen times.
>>>>
>>>> Is there a serial port bridge program that works well and is not
>>>> expensive?
>>>>
>>>> Rick C.
>>>>
>>>
>>> Get a USB serial port adapter and a null modem cable,
>>> so the test program does see any difference.
>>>
>>
>> "Null modem cable" ?  He doesn't need RS-232 converters and 9-pin
>> DSUBs here.  A couple of USB to TTL Uart cables is what he needs, with
>> the wires tied together.
>>
>> <https://www.ftdichip.com/Products/Cables/USBTTLSerial.htm>
>>
>>> The virtual serial ports are probably more part of the
>>> problem set than part of the solution set.
>>>
> 
> 
> Most of the off-the-shelf USB serial dongles have the 9 pin connectors
> with RS-232 DTE signals, which do need null modem to connect together.
> 

I guess it depends on which shelf you look on :-)

It is /many/ years since I have had need of an RS-232 serial dongle.
But TTL level UART to USB converters - we go through these at a high
rate.  Adding standard RS-232 to a board is big and expensive - you need
RS-232 drivers and a bulky DSUB connector, and then the cables.  Adding
a TTL level UART is practically free - you need the Tx and Rx pins on
the microcontroller (many of which have several UARTs - finding one
spare is not nearly the challenge it used to be), and you need a 3-pin
header.  For convenience, when we have the space, we use a 6-pin header
that matches the FTDI cables.

So /my/ shelf has lots of FTDI TTL-level UART cables - and a single
RS-232 dongle gathering dust in the corner.

[toc] | [prev] | [next] | [standalone]

#28513

On 2/18/19 4:49 AM, David Brown wrote:
> On 18/02/2019 09:38, Tauno Voipio wrote:
>> On 17.2.19 22:16, David Brown wrote:
>>> On 17/02/2019 17:54, Tauno Voipio wrote:
>>>> On 17.2.19 12:08, gnuarm.deletethisbit@gmail.com wrote:
>>>>> I'm working to improve a test program for the hardware I use to test
>>>>> some boards I make.  These boards are tested using a test fixture
>>>>> controlled over an RS-232 port from the PC.  So I don't need to lug
>>>>> hardware around with me I emulate the test fixture on the same PC I
>>>>> run the test program.  I need comm port emulation software that will
>>>>> emulate a bridge between two serial ports to connect the test
>>>>> program and the test fixture emulator.
>>>>>
>>>>> One I've been using is called, oddly enough, "Free Virtual Serial
>>>>> Ports".  It is free to use, but only in a limited configuration
>>>>> which will do the job, but just barely.  I have also noticed that if
>>>>> my programs are not closed properly (or some other cause) this
>>>>> bridge software will hang one of the ports.
>>>>>
>>>>> I don't want to emulate the serial port connection in my test
>>>>> fixture emulator because if I take the program down a lot while
>>>>> testing, I will have to continually restart both the test program
>>>>> and the emulator program.  There are a few initialization steps that
>>>>> become tedious after doing them a few dozen times.
>>>>>
>>>>> Is there a serial port bridge program that works well and is not
>>>>> expensive?
>>>>>
>>>>> Rick C.
>>>>>
>>>>
>>>> Get a USB serial port adapter and a null modem cable,
>>>> so the test program does see any difference.
>>>>
>>>
>>> "Null modem cable" ?  He doesn't need RS-232 converters and 9-pin
>>> DSUBs here.  A couple of USB to TTL Uart cables is what he needs, with
>>> the wires tied together.
>>>
>>> <https://www.ftdichip.com/Products/Cables/USBTTLSerial.htm>
>>>
>>>> The virtual serial ports are probably more part of the
>>>> problem set than part of the solution set.
>>>>
>>
>>
>> Most of the off-the-shelf USB serial dongles have the 9 pin connectors
>> with RS-232 DTE signals, which do need null modem to connect together.
>>
> 
> I guess it depends on which shelf you look on :-)
> 
> It is /many/ years since I have had need of an RS-232 serial dongle.
> But TTL level UART to USB converters - we go through these at a high
> rate.  Adding standard RS-232 to a board is big and expensive - you need
> RS-232 drivers and a bulky DSUB connector, and then the cables.  Adding
> a TTL level UART is practically free - you need the Tx and Rx pins on
> the microcontroller (many of which have several UARTs - finding one
> spare is not nearly the challenge it used to be), and you need a 3-pin
> header.  For convenience, when we have the space, we use a 6-pin header
> that matches the FTDI cables.
> 
> So /my/ shelf has lots of FTDI TTL-level UART cables - and a single
> RS-232 dongle gathering dust in the corner.
> 
> 

I think if you look at what is commercially available, the most common
device is RS232 levels, not TTL, because most commercial devices you
want to talk to that have an external connector us RS232 levels, TTL is
mostly used internally or known very short distances.

With the advent of things like the Raspberry Pi, Arduino, and the like,
the TTL version is getting more common, but those still mostly show up
in electronic specialty shops, while the RS232 version show up many more
places (like the electronics department of office supply stores, or even
hardware stores).

[toc] | [prev] | [next] | [standalone]

#28514

On 18/02/2019 13:25, Richard Damon wrote:
> On 2/18/19 4:49 AM, David Brown wrote:
>> On 18/02/2019 09:38, Tauno Voipio wrote:
>>> On 17.2.19 22:16, David Brown wrote:
>>>> On 17/02/2019 17:54, Tauno Voipio wrote:
>>>>> On 17.2.19 12:08, gnuarm.deletethisbit@gmail.com wrote:
>>>>>> I'm working to improve a test program for the hardware I use to test
>>>>>> some boards I make.  These boards are tested using a test fixture
>>>>>> controlled over an RS-232 port from the PC.  So I don't need to lug
>>>>>> hardware around with me I emulate the test fixture on the same PC I
>>>>>> run the test program.  I need comm port emulation software that will
>>>>>> emulate a bridge between two serial ports to connect the test
>>>>>> program and the test fixture emulator.
>>>>>>
>>>>>> One I've been using is called, oddly enough, "Free Virtual Serial
>>>>>> Ports".  It is free to use, but only in a limited configuration
>>>>>> which will do the job, but just barely.  I have also noticed that if
>>>>>> my programs are not closed properly (or some other cause) this
>>>>>> bridge software will hang one of the ports.
>>>>>>
>>>>>> I don't want to emulate the serial port connection in my test
>>>>>> fixture emulator because if I take the program down a lot while
>>>>>> testing, I will have to continually restart both the test program
>>>>>> and the emulator program.  There are a few initialization steps that
>>>>>> become tedious after doing them a few dozen times.
>>>>>>
>>>>>> Is there a serial port bridge program that works well and is not
>>>>>> expensive?
>>>>>>
>>>>>> Rick C.
>>>>>>
>>>>>
>>>>> Get a USB serial port adapter and a null modem cable,
>>>>> so the test program does see any difference.
>>>>>
>>>>
>>>> "Null modem cable" ?  He doesn't need RS-232 converters and 9-pin
>>>> DSUBs here.  A couple of USB to TTL Uart cables is what he needs, with
>>>> the wires tied together.
>>>>
>>>> <https://www.ftdichip.com/Products/Cables/USBTTLSerial.htm>
>>>>
>>>>> The virtual serial ports are probably more part of the
>>>>> problem set than part of the solution set.
>>>>>
>>>
>>>
>>> Most of the off-the-shelf USB serial dongles have the 9 pin connectors
>>> with RS-232 DTE signals, which do need null modem to connect together.
>>>
>>
>> I guess it depends on which shelf you look on :-)
>>
>> It is /many/ years since I have had need of an RS-232 serial dongle.
>> But TTL level UART to USB converters - we go through these at a high
>> rate.  Adding standard RS-232 to a board is big and expensive - you need
>> RS-232 drivers and a bulky DSUB connector, and then the cables.  Adding
>> a TTL level UART is practically free - you need the Tx and Rx pins on
>> the microcontroller (many of which have several UARTs - finding one
>> spare is not nearly the challenge it used to be), and you need a 3-pin
>> header.  For convenience, when we have the space, we use a 6-pin header
>> that matches the FTDI cables.
>>
>> So /my/ shelf has lots of FTDI TTL-level UART cables - and a single
>> RS-232 dongle gathering dust in the corner.
>>
>>
> 
> I think if you look at what is commercially available, the most common
> device is RS232 levels, not TTL, because most commercial devices you
> want to talk to that have an external connector us RS232 levels, TTL is
> mostly used internally or known very short distances.

RS-232 is short distance too (though a bit longer than TTL) - for long
distances you use RS-485 or RS-422.  RS-232 is a legacy standard - there
is plenty of old stuff the still has it, but it would be a strange
choice for anything new.

> 
> With the advent of things like the Raspberry Pi, Arduino, and the like,
> the TTL version is getting more common, but those still mostly show up
> in electronic specialty shops, while the RS232 version show up many more
> places (like the electronics department of office supply stores, or even
> hardware stores).
> 

It is so many years since RS-232 has been in common use that I'd be
surprised to find many real shops stocking dongles.  But I agree that
you are more likely to find one in a big computer shop than to find a
TTL level UART dongle.  However, this is comp.arch.embedded, and people
here will already have shops, suppliers, webshops, etc., for which TTL
level cables are on stock.

[toc] | [prev] | [next] | [standalone]

#28517

On 2019-02-18, David Brown <david.brown@hesbynett.no> wrote:
>
> RS-232 is short distance too (though a bit longer than TTL) - for long
> distances you use RS-485 or RS-422.  RS-232 is a legacy standard - there
> is plenty of old stuff the still has it, but it would be a strange
> choice for anything new.

I'm genuinely interested to hear people thoughts on this.  Personally
if I anticipate a true long life interfacing requirement - 20, 30,
40 years - RS232 is my preferred option, ideally (if appropriate
to the use case) with a command line on it.  My rationale has always
been that RS232 isn't going anywhere, terminal emulators are always
going to be around, so that combination makes fewest assumptions
about hardware or software.  Even if serial ports are no longer
standard equipment they'll always be easy enough to add and at
moderate cost.  The relative simplicity of the technology and the
simplicity of the host software makes me feel sure of that.

It's also what's always made me feel slightly uneasy about USB.
In many ways it is a nice standard but it depends on quite a thick
layer of software on the host side.  If it falls out of favour and
support gets dropped over time re-adding that software layer is
problematic even if the hardware is to hand.  

It may seem difficult to imagine now but I can see it coming - try
reading the original USB spec and seeing what a big play it makes
of the single cable with just one upstream and one downstream
connector.  Now there are so many possible combinations of port
and cable it makes parallel SCSI look posivitely straightforward.
And yes, I do see this creating confusion among non-technical users:
the original B plug has been poorly recognised for years, and I've
heard a few people recently see an A plug and respond along the
lines of "No, that's a charger plug, I need a _USB_ plug...".  Full
size A sockets are already disappearing from laptops, in a few
years someone is bound to drop USB entirely in favour of something
else to "improve" things for the consumer.

The software issue is similar for the other hardware that I can't
see disappearing, namely ethernet.  Specific media may change in
popularity but you should be able to interface older stuff easy
enough, just as it still isn't _too_ difficult to track down a
10Mbit hub with AUI and/ BNC connectors if you need modern stuff
to connect to coax.  My concern there it that we'll be transitioning
to IPv6 any decade now.  Realistically when is imposssible to
predict but I feel sure once a certain critical mass develops IPv4
will seem obsolete in 5-10 years.  If we use that in our though
processes large amount of equipment and plant may well not be even
halfway through its expected life when that timespan elapses.  Dual
stack is one possibilty but I'll admit I don't understand IPv6 well
enough yet and I don't like the sound of the complexity.

I don't pretend to have answers in the general case, just interested
in what peoples thoughts are.

-- 
Andrew Smallshaw
andrews@sdf.org

[toc] | [prev] | [next] | [standalone]

#28518

On Tuesday, February 19, 2019 at 11:10:16 AM UTC-5, Andrew Smallshaw wrote:
> On 2019-02-18, David Brown <david.brown@hesbynett.no> wrote:
> >
> > RS-232 is short distance too (though a bit longer than TTL) - for long
> > distances you use RS-485 or RS-422.  RS-232 is a legacy standard - there
> > is plenty of old stuff the still has it, but it would be a strange
> > choice for anything new.
> 
> I'm genuinely interested to hear people thoughts on this.  Personally
> if I anticipate a true long life interfacing requirement - 20, 30,
> 40 years - RS232 is my preferred option, ideally (if appropriate
> to the use case) with a command line on it.  My rationale has always
> been that RS232 isn't going anywhere, terminal emulators are always
> going to be around, so that combination makes fewest assumptions
> about hardware or software.  Even if serial ports are no longer
> standard equipment they'll always be easy enough to add and at
> moderate cost.  The relative simplicity of the technology and the
> simplicity of the host software makes me feel sure of that.
> 
> It's also what's always made me feel slightly uneasy about USB.
> In many ways it is a nice standard but it depends on quite a thick
> layer of software on the host side.  If it falls out of favour and
> support gets dropped over time re-adding that software layer is
> problematic even if the hardware is to hand.  

You raise some interesting points.  I don't know how easy it is to add RS-232 to a PC other than through a USB interface which adds back all those layers of software even if you don't need to deal with them.  The last RS-232 board I've seen was for the PCI bus which is no longer used in PCs.  

Even so, desktops are waining and laptops are sold in much greater numbers.  I wouldn't design anything that required a desktop to work.  So I think you are stuck with USB either as the actual interface or an intermediate interface.  


> It may seem difficult to imagine now but I can see it coming - try
> reading the original USB spec and seeing what a big play it makes
> of the single cable with just one upstream and one downstream
> connector.  Now there are so many possible combinations of port
> and cable it makes parallel SCSI look posivitely straightforward.
> And yes, I do see this creating confusion among non-technical users:
> the original B plug has been poorly recognised for years, and I've
> heard a few people recently see an A plug and respond along the
> lines of "No, that's a charger plug, I need a _USB_ plug...".  Full
> size A sockets are already disappearing from laptops, in a few
> years someone is bound to drop USB entirely in favour of something
> else to "improve" things for the consumer.

I think there is nothing any other interface can do better than USB other than possibly wireless.  USB is fast and stable and here for the long haul.  Heck, it has ramped up from 1.0 to 1.1, 2.0, 3.0, 3.1... what is going to replace it?  The type C connector is a significant improvement and with enough time will become the dominant interface although I think displacing the type A connector will take a long time.  As you say, it's a charger defacto interface. 


> The software issue is similar for the other hardware that I can't
> see disappearing, namely ethernet.  Specific media may change in
> popularity but you should be able to interface older stuff easy
> enough, just as it still isn't _too_ difficult to track down a
> 10Mbit hub with AUI and/ BNC connectors if you need modern stuff
> to connect to coax.  My concern there it that we'll be transitioning
> to IPv6 any decade now.  Realistically when is imposssible to
> predict but I feel sure once a certain critical mass develops IPv4
> will seem obsolete in 5-10 years.  If we use that in our though
> processes large amount of equipment and plant may well not be even
> halfway through its expected life when that timespan elapses.  Dual
> stack is one possibilty but I'll admit I don't understand IPv6 well
> enough yet and I don't like the sound of the complexity.

It's dual stack now.  There is nothing that will make IPv4 become inoperable.  Just as the routers hide the IP address of local devices, IPv6 can be used in the entire rest of the world and IPv4 can be used locally.  


> I don't pretend to have answers in the general case, just interested
> in what peoples thoughts are.

I expect USB will survive for decades more even if only to interface to mice and printers.  In fact, newer laptops seem to have more USB connectors with many having four while the typical number used to be three.  

I'm just glad the PCMCIA interface is gone. 

Rick C.

[toc] | [prev] | [next] | [standalone]

#28520

On Tue, 19 Feb 2019 09:12:14 -0800 (PST),
gnuarm.deletethisbit@gmail.com wrote:

>On Tuesday, February 19, 2019 at 11:10:16 AM UTC-5, Andrew Smallshaw wrote:
>> On 2019-02-18, David Brown <david.brown@hesbynett.no> wrote:
>> >
>> > RS-232 is short distance too (though a bit longer than TTL) - for long
>> > distances you use RS-485 or RS-422.  RS-232 is a legacy standard - there
>> > is plenty of old stuff the still has it, but it would be a strange
>> > choice for anything new.
>> 
>> I'm genuinely interested to hear people thoughts on this.  Personally
>> if I anticipate a true long life interfacing requirement - 20, 30,
>> 40 years - RS232 is my preferred option, ideally (if appropriate
>> to the use case) with a command line on it.  My rationale has always
>> been that RS232 isn't going anywhere, terminal emulators are always
>> going to be around, so that combination makes fewest assumptions
>> about hardware or software.  Even if serial ports are no longer
>> standard equipment they'll always be easy enough to add and at
>> moderate cost.  The relative simplicity of the technology and the
>> simplicity of the host software makes me feel sure of that.
>> 
>> It's also what's always made me feel slightly uneasy about USB.
>> In many ways it is a nice standard but it depends on quite a thick
>> layer of software on the host side.  If it falls out of favour and
>> support gets dropped over time re-adding that software layer is
>> problematic even if the hardware is to hand.  
>
>You raise some interesting points.  I don't know how easy it is to add RS-232 to a PC other than through a USB interface which adds back all those layers of software even if you don't need to deal with them.  The last RS-232 board I've seen was for the PCI bus which is no longer used in PCs.  

It is very easy with Ethernet to RS-232/422/485 converters. I have
used 1, 2, 4 and 8 line Moxa serial line converters and I think 16
line modules are also available. Just point Telnet to the converter
IP-address and use it as Hyperterminal :-). 

A large system had one Ethernet cable feeding seven 8 line Eth(RS-232
converters feeding 50 RS-232 to  current loop converters controlling
50 legacy devices. Early smaller systems used a few dozen serial
lines directly from two PCI RS.232 cards. That was a nasty bundle of
serial cables coming out of the PC :-), but the largest system had
only one additional Ethernet port.

>Even so, desktops are waining and laptops are sold in much greater numbers.  I wouldn't design anything that required a desktop to work.  So I think you are stuck with USB either as the actual interface or an intermediate interface.  

Better design for smart phone controllability. That would be wireless
and Ethernet.

[toc] | [prev] | [next] | [standalone]

#28521

On 2019-02-19, upsidedown@downunder.com <upsidedown@downunder.com> wrote:

>>You raise some interesting points.  I don't know how easy it is to
>>add RS-232 to a PC other than through a USB interface which adds
>>back all those layers of software even if you don't need to deal
>>with them.  The last RS-232 board I've seen was for the PCI bus
>>which is no longer used in PCs.

There are still plenty of choices for PCI-express serial boards (up to
32-ports per board):

    https://comtrol.com/products/rocketport-multi-port-serial-cards/rocketport-express

> It is very easy with Ethernet to RS-232/422/485 converters. I have
> used 1, 2, 4 and 8 line Moxa serial line converters and I think 16
> line modules are also available. Just point Telnet to the converter
> IP-address and use it as Hyperterminal :-).

They're generally available with up to 32 ports:

   https://comtrol.com/products/devicemaster-ethernet-device-servers

Disclaiming: my employer makes the PCI-express boards and Ethernet
attached serial ports linked to above, and I maintain Linux drivers
for them and the firmware for the Ethernet-attached products.  [The
Linux drivers all support up to 256 ports.]

That said, modern USB-attached serial ports all seem to work fine.  At
least under Linux, the kernel has had built-in drivers for all the
popular chipsets for decades.

-- 
Grant Edwards               grant.b.edwards        Yow! Like I always say
                                  at               -- nothing can beat
                              gmail.com            the BRATWURST here in
                                                   DUSSELDORF!!

[toc] | [prev] | [next] | [standalone]

#28522

On 19/02/2019 18:12, gnuarm.deletethisbit@gmail.com wrote:
> On Tuesday, February 19, 2019 at 11:10:16 AM UTC-5, Andrew Smallshaw wrote:
>> On 2019-02-18, David Brown <david.brown@hesbynett.no> wrote:
>>>
>>> RS-232 is short distance too (though a bit longer than TTL) - for long
>>> distances you use RS-485 or RS-422.  RS-232 is a legacy standard - there
>>> is plenty of old stuff the still has it, but it would be a strange
>>> choice for anything new.
>>
>> I'm genuinely interested to hear people thoughts on this.  Personally
>> if I anticipate a true long life interfacing requirement - 20, 30,
>> 40 years - RS232 is my preferred option, ideally (if appropriate
>> to the use case) with a command line on it.  My rationale has always
>> been that RS232 isn't going anywhere, terminal emulators are always
>> going to be around, so that combination makes fewest assumptions
>> about hardware or software.  Even if serial ports are no longer
>> standard equipment they'll always be easy enough to add and at
>> moderate cost.  The relative simplicity of the technology and the
>> simplicity of the host software makes me feel sure of that.
>>
>> It's also what's always made me feel slightly uneasy about USB.
>> In many ways it is a nice standard but it depends on quite a thick
>> layer of software on the host side.  If it falls out of favour and
>> support gets dropped over time re-adding that software layer is
>> problematic even if the hardware is to hand.
> 
> You raise some interesting points.  I don't know how easy it is to add RS-232 to a PC other than through a USB interface which adds back all those layers of software even if you don't need to deal with them.  The last RS-232 board I've seen was for the PCI bus which is no longer used in PCs.
> 

It is not hard to get RS-232 interface boards with PCI Express.  I have 
not seen one used, but they are reasonably easily available.  USB serial 
adapters are, however, the norm.

> Even so, desktops are waining and laptops are sold in much greater numbers.  I wouldn't design anything that required a desktop to work.  So I think you are stuck with USB either as the actual interface or an intermediate interface.
> 

By "USB" do you mean real USB, or using a USB-to-serial cable?  The 
challenge with a real USB connection is the software side - drivers and 
the like.  Even with software like libusb it is still a PITA.

> 
>> It may seem difficult to imagine now but I can see it coming - try
>> reading the original USB spec and seeing what a big play it makes
>> of the single cable with just one upstream and one downstream
>> connector.  Now there are so many possible combinations of port
>> and cable it makes parallel SCSI look posivitely straightforward.
>> And yes, I do see this creating confusion among non-technical users:
>> the original B plug has been poorly recognised for years, and I've
>> heard a few people recently see an A plug and respond along the
>> lines of "No, that's a charger plug, I need a _USB_ plug...".  Full
>> size A sockets are already disappearing from laptops, in a few
>> years someone is bound to drop USB entirely in favour of something
>> else to "improve" things for the consumer.
> 
> I think there is nothing any other interface can do better than USB other than possibly wireless.  USB is fast and stable and here for the long haul.  Heck, it has ramped up from 1.0 to 1.1, 2.0, 3.0, 3.1... what is going to replace it?  The type C connector is a significant improvement and with enough time will become the dominant interface although I think displacing the type A connector will take a long time.  As you say, it's a charger defacto interface.
> 

There are far too many "standard" USB connectors - especially when 
considering long-term systems.  Serial (be it TTL UART, RS-232, RS-485 
or RS-422) has a big advantage for connectors that it really doesn't 
matter.  You need three wires (5 for RS-422), and there are no issues 
with speed, impedance, or anything like that.  An RS-232 9-pin DSUB may 
be convenient, but any connector will work fine and can be jerry-rigged 
as needed.  And the various UART standards are simple, can be 
bit-banged, and just need a simple driver.  That is a big plus for 
long-lasting systems.

> 
>> The software issue is similar for the other hardware that I can't
>> see disappearing, namely ethernet.  Specific media may change in
>> popularity but you should be able to interface older stuff easy
>> enough, just as it still isn't _too_ difficult to track down a
>> 10Mbit hub with AUI and/ BNC connectors if you need modern stuff
>> to connect to coax.  My concern there it that we'll be transitioning
>> to IPv6 any decade now.  Realistically when is imposssible to
>> predict but I feel sure once a certain critical mass develops IPv4
>> will seem obsolete in 5-10 years.  If we use that in our though
>> processes large amount of equipment and plant may well not be even
>> halfway through its expected life when that timespan elapses.  Dual
>> stack is one possibilty but I'll admit I don't understand IPv6 well
>> enough yet and I don't like the sound of the complexity.
> 
> It's dual stack now.  There is nothing that will make IPv4 become inoperable.  Just as the routers hide the IP address of local devices, IPv6 can be used in the entire rest of the world and IPv4 can be used locally.
> 
> 
>> I don't pretend to have answers in the general case, just interested
>> in what peoples thoughts are.
> 
> I expect USB will survive for decades more even if only to interface to mice and printers.  In fact, newer laptops seem to have more USB connectors with many having four while the typical number used to be three.
> 

I too expect it to last for a good while yet.  But I expect UART 
connections to last a lot longer.

> I'm just glad the PCMCIA interface is gone.
> 

People Can't Memorize Computer Industry Acronyms?  I haven't seen one 
for a /long/ time.  But my usual computer parts supplier has a PCMCIA 
adapter with an RS-232 port on stock.


> Rick C.
> 

[toc] | [prev] | [next] | [standalone]

#28523

On 2019-02-19, David Brown <david.brown@hesbynett.no> wrote:

> I too expect it to last for a good while yet.  But I expect UART 
> connections to last a lot longer.

One great thing about "UART" connections, is that you don't even need
a UART.  If all you want is output for "printf" logging/debugging, a
single port pin and a few dozen lines of carefully crafted assembly
language can be suffice.  On an MSP430 running at 921KHz (yes, that's
a K), you can easily bit-bang a 57.6K baud output "UART" (if there are
no interrupts running during output).

-- 
Grant Edwards               grant.b.edwards        Yow! They collapsed
                                  at               ... like nuns in the
                              gmail.com            street ... they had no
                                                   teen appeal!

[toc] | [prev] | [next] | [standalone]

#28529

On 19/02/2019 23:23, Grant Edwards wrote:
> On 2019-02-19, David Brown <david.brown@hesbynett.no> wrote:
> 
>> I too expect it to last for a good while yet.  But I expect UART 
>> connections to last a lot longer.
> 
> One great thing about "UART" connections, is that you don't even need
> a UART.  If all you want is output for "printf" logging/debugging, a
> single port pin and a few dozen lines of carefully crafted assembly
> language can be suffice.  On an MSP430 running at 921KHz (yes, that's
> a K), you can easily bit-bang a 57.6K baud output "UART" (if there are
> no interrupts running during output).
> 

Agreed.  I've done software UARTs on various devices, for several
purposes.  The first one I made was for use in an RS-485 bus system
where the installers regularly mixed up the A and B lines.  The solution
was a software UART that detected the level of the idle line, and
adjusted its polarity accordingly.  I've also used a software UART on an
AVR because I wanted a baud rate of 150 Hz (without a K), and that was
too slow for the microcontroller's baud rate divisor.

I had a 57.6Kbaud software UART on an AVR once, running at 9.6 MHz.  But
that UART was full duplex, interrupt-driven and with 4 times
oversampling on the receiver.

On more modern microcontrollers, you can do a bit-banged UART
transmitter easily enough in C with a timer interrupt for the timing.

[toc] | [prev] | [next] | [standalone]

#28531

On Wed, 20 Feb 2019 08:53:27 +0100, David Brown
<david.brown@hesbynett.no> wrote:

>I've done software UARTs on various devices, for several
>purposes.  The first one I made was for use in an RS-485 bus system
>where the installers regularly mixed up the A and B lines.  

The RS-422 is much worse. The local installers not only mixed A with B
but possibly also A' with B' or mixing A with A' and B with B'. 

The A, B, A' and B' notation is unambiguous but the meaning of the
Tx+, Tx-, Rx+ and Rx- notation varies from manufacturer to
manufacturer.

Some installers have managed to mix the signal ground (if present)
with A, B, A' or B  :-).

[toc] | [prev] | [next] | [standalone]

#28525

David Brown <david.brown@hesbynett.no> wrote:
> There are far too many "standard" USB connectors - especially when
> considering long-term systems.  Serial (be it TTL UART, RS-232, RS-485 or
> RS-422) has a big advantage for connectors that it really doesn't matter. 
> You need three wires (5 for RS-422), and there are no issues with speed,
> impedance, or anything like that.  An RS-232 9-pin DSUB may be convenient,
> but any connector will work fine and can be jerry-rigged as needed.  And
> the various UART standards are simple, can be bit-banged, and just need a
> simple driver.  That is a big plus for long-lasting systems.

I don't really see the problem with USB.  It's 4 wires: VCC, D-, D+, GND
Route that to a pin header, you can bodge something on to that just like
serial.  If you're running at USB 1.1 speeds then wire length isn't really
an issue (any more than it is with TTL UART anyway).  Bonus points if you use
the same pinout at PC motherboard headers so their standard cabling will
work.

If you choose to put a port on the back of a machine then people will need a
cable for that.  They might not have the right one, and their local
supermarket might not have the right one, but they can order one.  It's no
worse than TTL UART.

I agree that UART is so simple that any microcontroller ever should be able
to bit bang it, which helps.

Theo

[toc] | [prev] | [next] | [standalone]

#28526

On 19 Feb 2019 22:35:17 +0000 (GMT), Theo
<theom+news@chiark.greenend.org.uk> wrote:

>David Brown <david.brown@hesbynett.no> wrote:
>> There are far too many "standard" USB connectors - especially when
>> considering long-term systems.  Serial (be it TTL UART, RS-232, RS-485 or
>> RS-422) has a big advantage for connectors that it really doesn't matter. 
>> You need three wires (5 for RS-422), and there are no issues with speed,
>> impedance, or anything like that.  An RS-232 9-pin DSUB may be convenient,
>> but any connector will work fine and can be jerry-rigged as needed.  And
>> the various UART standards are simple, can be bit-banged, and just need a
>> simple driver.  That is a big plus for long-lasting systems.
>
>I don't really see the problem with USB.  It's 4 wires: VCC, D-, D+, GND
>Route that to a pin header, you can bodge something on to that just like
>serial.  If you're running at USB 1.1 speeds then wire length isn't really
>an issue (any more than it is with TTL UART anyway).  Bonus points if you use
>the same pinout at PC motherboard headers so their standard cabling will
>work.

Isn't USB specified for even shorter distances than RS-232 ?

The nice feature with USB, when bus powering small devices are used,
there are hardly going to be ground potential issues.

[toc] | [prev] | [next] | [standalone]

#28528

On Tuesday, February 19, 2019 at 5:35:22 PM UTC-5, Theo wrote:
> David Brown <david.brown@hesbynett.no> wrote:
> > There are far too many "standard" USB connectors - especially when
> > considering long-term systems.  Serial (be it TTL UART, RS-232, RS-485 or
> > RS-422) has a big advantage for connectors that it really doesn't matter. 
> > You need three wires (5 for RS-422), and there are no issues with speed,
> > impedance, or anything like that.  An RS-232 9-pin DSUB may be convenient,
> > but any connector will work fine and can be jerry-rigged as needed.  And
> > the various UART standards are simple, can be bit-banged, and just need a
> > simple driver.  That is a big plus for long-lasting systems.
> 
> I don't really see the problem with USB.  It's 4 wires: VCC, D-, D+, GND
> Route that to a pin header, you can bodge something on to that just like
> serial.  If you're running at USB 1.1 speeds then wire length isn't really
> an issue (any more than it is with TTL UART anyway).  Bonus points if you use
> the same pinout at PC motherboard headers so their standard cabling will
> work.

Low speed USB was designed for very simple implementations and is 1.5 Mbps raw data rate which is about as fast as UARTs are typically run.  However there are timing issues that limit cable length, at least for the higher speeds.  I think low speed is length limited to <10 feet to allow inexpensive drivers and cable. 


> If you choose to put a port on the back of a machine then people will need a
> cable for that.  They might not have the right one, and their local
> supermarket might not have the right one, but they can order one.  It's no
> worse than TTL UART.

Most USB stuff these days is micro-USB.  Type-C is gaining ground with phones and tablets, mostly because of the charging capabilities.  

Serial ports, either TTL or RS-232, have a plethora of connectors used.  I've seen, DB-25, DB-9, RJ-11, RJ-45 in multiple pinouts, 0.1" spaced 0.025" square posts in sum(n!) configurations where n ranges from 3 to 9.  


> I agree that UART is so simple that any microcontroller ever should be able
> to bit bang it, which helps.

That's why every design I do determines the interface by the requirements, not by a predefined choice of one size fits all. 

I'm currently looking at rolling a design that will use an FTDI chip for it's JTAG capabilities as well as providing a UART.  But the package is larger than the device I want to control. 

Rick C.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web