Serial Port Emulation

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.
> 

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!

Andrew Smallshaw <andrews@sdf.org> wrote:
> 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.

Looking at the past, it seems embedded interfaces fall out of use about a
decade or two behind the consumer space (assuming they ever reached).

For instance, parallel ports died out on consumer hardware somewhere between
2000-2008.  While a very few select motherboards still have them, and there
are some quite niche PCIe cards. by-and-large they're dead in the embedded
space too - you couldn't ship a product that expected a parallel port today
without people complaining.

Similarly GPIB's heyday was the 80s, and about 10 years ago it was still
popular to control test gear, but nowadays USB and ethernet are favoured. 
(The longevity of test gear means instruments are still shipping with GPIB,
but I suspect most people aren't using it unless they have legacy setups)

So the trick is to pick something that's current in the consumer space, and
hope that its decline will be slow and lingering.

One way to look at this is to think about the sunk costs.
For example, RJ45 cabling isn't going anywhere because there's a vast
investment in structured wiring.  So your chances are good if you speak some
form of ethernet.  Similarly there's a huge amount of IP out there.
It would be wise to support IPv4 and IPv6 (the legacy and
the new standard).  Where you go with protocols on top of that stack (HTTP,
HTTPS, SSH?) is a much more variable question.  And there are security
implications that aren't present in standards like RS232, which cause more
churn that you might want (eg in what current web browsers do).

I would be wary of extrapolating a current long-life standard (RS232) that
it will live for the same lifetime again.  What drove RS232 was serial
ports, printers and modems.  We don't have dialup modems and dot matrix
printers any more.  It's only the serial consoles on servers and embedded
boards that are really keeping RS232 alive at this point.  Although it's
sufficiently simple and sufficiently useful for software bringup that I
can't imagine a RS232 to <whatever> adaptor is going to be very complicated.

Although a TTL serial header on your motherboard (see every wifi router
ever) labelled with pinouts and voltage levels must be fairly
cockroach-friendly I'd imagine.  Maybe you can't buy a suitable cable in the
supermarket post-armageddon but somebody will still make something to read
it, even if it's extremely niche.  It's just so simple.

> 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.  

I'd say a basic USB 1 isn't likely to go anywhere because every keyboard and
mouse speaks it, and I can't see that changing.  If USB HID is an option for
you, might be worth considering.  Similarly USB 2.0 Mass Storage is fairly
ubiquitous.

USB serial is a bit messier - the protocol is less well specified, there's
already a wide range of silicon that needs its own special driver.

> 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 current mode seems to be convergence - a USB Type-C connector does
'everything', and if a new protocol comes along we just add an addiitonal
mode for that.  So I'd worry less about cabling, and more about UI
(how do we indicate that somebody plugged in an HDMI-over-Type-C cable and
we don't have a video output?)

I do worry that all this negotiation is going to go wrong later down the
track.

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

I think the wider question is: where do you want to be on the
simplicity/performance curve?  RS232 is very simple, and so implementations
are easy, but it's not performant.  If you want more performance, you might
have to go to ethernet or USB Mass Storage, but they depend on larger host
software stacks.

The other option is to distribute your own software stack - ie a virtual
machine image.  You're still relying on the host machine having an
ethernet/USB port, but you can pin down things like browser versions and
drivers.

Theo

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

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.

On Tue, 19 Feb 2019 16:10:12 -0000 (UTC), Andrew Smallshaw
<andrews@sdf.org> 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.  
>
>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.


One thing to watch out for, is slow control signal responses on
USB-to-serial port converters.  These mostly appear to have been
designed for devices with a decent amount of buffering built in.  So
if you keep it so that you depend little on the RS-232 control
signals, or that you can tolerate that sensing or changing them is
slow, you should be fine.

But I agree that RS-232, both in nominal and TTL voltages, will be
around a for considerable time.

The situation with USB connectors is unfortunate, of course, but
you're rather seriously understating the mess that was parallel SCSI.
At least with USB, if you manage to get both ends of the cable plugged
in, it'll likely work.  With SCSI you might have 8 and 16-bit wide
devices, with both single-ended and differential signaling, as well as
incompatible pinouts and genders all using the same (or different)
connectors, meaning not only that identical looking cables could be
incompatible, but devices with identical connectors could be, and
devices sometimes required certainly orderings on the bus (mixing 8
and 16-bit devices, for example).  And let's not forget termination
(and god help you if you had mixed 8 and 16-bit devices).

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.

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.

On 20/02/2019 04:40, gnuarm.deletethisbit@gmail.com wrote:
> 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. 
> 

Yes, the low speed USB is not too bad - at those speeds you don't have
to worry about connectors, impedances, length matching, etc.  And it is
possible to bit-bang it if you have to.  But it is still more effort
than handling a UART at that speed, especially on the software side.

5m USB cables are not uncommon, but beyond that you tend to have active
cables (with a USB hub in the middle).


> 
>> 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. 

Yes, I agree.

(But one of the requirements I put on most new designs is a 3-pin or
6-pin header for an FTDI TTL UART to USB cable for debugging output.)

> 
> 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. 
> 

If you make sure your pinning on the FTDI chip matches those supported
by OpenOCD (which can support a great variety of choices here), then
your board has a built-in debugger.  I did done something similar with a
Coldfire board many years ago - it was a great convenience in test and
programming.

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  :-).