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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#28530

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.

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

#28519

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.

The problem with both TTL and RS-232 is the ground potential issues.
Any ground potential noise will directly deteriorate the noise
margins. High speed RS-232 is also problematic, since the impedance
levels are too high for typical cable impedances. 

No such problems with RS-422/485, but of course common mode voltage
range must be considered and galvanic isolation may be needed.

>I'm genuinely interested to hear people thoughts on this.  Personally
>if I anticipate a true long life interfacing requirement - 20, 30,
>40 years

Looking back, RS-232 and 20 mA was popular. The nice thing about
current loops was that you nearly always had galvanic isolation
(relays, optoisolators).

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


<Skipped about USB>

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

These days, many even small microcontrollers have Ethernet interface.
In a simplest cases just use raw MAC frames or UDP . Surprisingly
small micros have web servers, so they have at least a rudimentary TCP
stack.

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

The ARP (Address Resolution Protocol) program for mapping between MAC
and IPv4 addresses is less than one page long, the MAC to IPv6 mapping
shouldn't be much more complex.

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

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

#28524

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

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

#28532

On 19/02/2019 23:28, Theo wrote:
> Andrew Smallshaw <andrews@sdf.org> wrote:

<snip>

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

That's why I always use FTDI - when you only have one type of silicon,
you only need drivers from one place.  They are good at keeping their
Windows drivers up to date, which is nice when every version of Windows
changes things.  And there has been solid support in Linux forever, as
well as useful libraries (like pyftdi) for controlling them.

But HID is another possibility, especially if you have to connect to
Windows systems.

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

USB mass storage has some advantages.  Hosts already have the software
stack - you just need it on the device.  But it can be a handy way of
doing software updates (copy the file onto the device), and makes it
easy to distribute relevant software, PC applications, documentation,
etc., with the hardware.

Ethernet is always nice, flexible and fast - but you again need software
on the device.  And there is always the question of how you identify the
device - it is no longer "the thing plugged into your computer".

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

That sounds a good deal more effort, especially as it depends highly on
the virtual machine software on the computer.

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

#28527

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

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

#28548

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.  
<snip>
> 
> I don't pretend to have answers in the general case, just interested
> in what peoples thoughts are.
> 

Anything you can do with RS323 you can do with Ethernet. There are
pathological size/weight/power cases where Ethernet doesn't fit but
if it does...

-- 
Les Cargill

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

#28549

On Sat, 23 Feb 2019 14:48:40 -0600, Les Cargill
<lcargill99@comcast.com> wrote:

>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.  
><snip>
>> 
>> I don't pretend to have answers in the general case, just interested
>> in what peoples thoughts are.
>> 
>
>Anything you can do with RS323 you can do with Ethernet. There are
>pathological size/weight/power cases where Ethernet doesn't fit but
>if it does...


Ethernet does have a couple of annoying configuration issues, and
requires either a custom client on an attached PC, or requires enough
software to implement TCP and a TELNET or HTTP server (and TCP/IP
brings a couple of annoying configuration issues as well).

And, of course, as soon as you do have an Ethernet connection,
anything non-TCP/IP is ruled out because the customer and marketing
will immediately want to be able to do (whatever) from across the
campus, and then inevitably further than that.  And then you have
security issues.

Definitely the way to go if you can, but there are enough hurdles that
you can find yourself longing for async RS-232 and a terminal
emulator.

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

#28582

Robert Wessel wrote:
> On Sat, 23 Feb 2019 14:48:40 -0600, Les Cargill
> <lcargill99@comcast.com> wrote:
> 
>> 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.
>> <snip>
>>>
>>> I don't pretend to have answers in the general case, just interested
>>> in what peoples thoughts are.
>>>
>>
>> Anything you can do with RS323 you can do with Ethernet. There are
>> pathological size/weight/power cases where Ethernet doesn't fit but
>> if it does...
> 
> 
> Ethernet does have a couple of annoying configuration issues, and
> requires either a custom client on an attached PC, or requires enough
> software to implement TCP and a TELNET or HTTP server (and TCP/IP
> brings a couple of annoying configuration issues as well).
> 

There exist things like RasPi boards which can have FTDI USB
RS232 ports attached. So really? You should be able to use DynDNS and 
DHCP and that's about all the config you need. With the RasPi's I have 
seen, it's even 802.11 - just carry an AP and you're in.

You can do all the fiddly bits once, and offsite.

Generally, I'll have a custom TCP server running on the Pi, which
provides the option of encoding any twiddly parts about the device on 
the other end of the FTDI device, within the Pi.

> And, of course, as soon as you do have an Ethernet connection,
> anything non-TCP/IP is ruled out because the customer and marketing
> will immediately want to be able to do (whatever) from across the
> campus, and then inevitably further than that.  And then you have
> security issues.
> 

Almost everything has Ethernet now.

> Definitely the way to go if you can, but there are enough hurdles that
> you can find yourself longing for async RS-232 and a terminal
> emulator.
> 

Oh, not so much :) Well, sometimes :)

-- 
Les Cargill

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

#28585

On 28/02/2019 05:15, Les Cargill wrote:
> Robert Wessel wrote:
>> On Sat, 23 Feb 2019 14:48:40 -0600, Les Cargill
>> <lcargill99@comcast.com> wrote:
>>
>>> 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.
>>> <snip>
>>>>
>>>> I don't pretend to have answers in the general case, just interested
>>>> in what peoples thoughts are.
>>>>
>>>
>>> Anything you can do with RS323 you can do with Ethernet. There are
>>> pathological size/weight/power cases where Ethernet doesn't fit but
>>> if it does...
>>
>>
>> Ethernet does have a couple of annoying configuration issues, and
>> requires either a custom client on an attached PC, or requires enough
>> software to implement TCP and a TELNET or HTTP server (and TCP/IP
>> brings a couple of annoying configuration issues as well).
>>
> 
> There exist things like RasPi boards which can have FTDI USB
> RS232 ports attached. So really? You should be able to use DynDNS and
> DHCP and that's about all the config you need. With the RasPi's I have
> seen, it's even 802.11 - just carry an AP and you're in.
> 
> You can do all the fiddly bits once, and offsite.
> 
> Generally, I'll have a custom TCP server running on the Pi, which
> provides the option of encoding any twiddly parts about the device on
> the other end of the FTDI device, within the Pi.

I don't know what kind of systems you work with, but to me a Pi is
convenient for testing and developing, but is out of the question for
most delivered systems.  The same goes for jumbled mixups with dynamic
DNS - fine for test setups, not for deployment.

> 
>> And, of course, as soon as you do have an Ethernet connection,
>> anything non-TCP/IP is ruled out because the customer and marketing
>> will immediately want to be able to do (whatever) from across the
>> campus, and then inevitably further than that.  And then you have
>> security issues.
>>
> 
> Almost everything has Ethernet now.

Almost every microcontroller does /not/ have Ethernet.  Almost every
electronics board made does /not/ have Ethernet.

> 
>> Definitely the way to go if you can, but there are enough hurdles that
>> you can find yourself longing for async RS-232 and a terminal
>> emulator.
>>
> 
> Oh, not so much :) Well, sometimes :)
> 

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

#28588

On Thursday, February 28, 2019 at 1:41:36 AM UTC-6, David Brown wrote:
> On 28/02/2019 05:15, Les Cargill wrote:
> > 
> > Generally, I'll have a custom TCP server running on the Pi, which
> > provides the option of encoding any twiddly parts about the device on
> > the other end of the FTDI device, within the Pi.
> 
> I don't know what kind of systems you work with, but to me a Pi is
> convenient for testing and developing, but is out of the question for
> most delivered systems.  The same goes for jumbled mixups with dynamic
> DNS - fine for test setups, not for deployment.

It's nice to say you don't like using pis for delivered systems, but that's not useful to anyone else unless you explain why.  

The rPi foundation even makes boards specifically for embedded systems and I believe they have some level of assurance these units will continue to be available. 


> > Almost everything has Ethernet now.
> 
> Almost every microcontroller does /not/ have Ethernet.  Almost every
> electronics board made does /not/ have Ethernet.

I think both statements are exaggerations.  Plenty of MCUs are Ethernet capable.  If you want Ethernet it is easy to select a version with a network interface. 

Rick C. 

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

#28590

On 01/03/2019 00:07, gnuarm.deletethisbit@gmail.com wrote:
> On Thursday, February 28, 2019 at 1:41:36 AM UTC-6, David Brown wrote:
>> On 28/02/2019 05:15, Les Cargill wrote:
>>>
>>> Generally, I'll have a custom TCP server running on the Pi, which
>>> provides the option of encoding any twiddly parts about the device on
>>> the other end of the FTDI device, within the Pi.
>>
>> I don't know what kind of systems you work with, but to me a Pi is
>> convenient for testing and developing, but is out of the question for
>> most delivered systems.  The same goes for jumbled mixups with dynamic
>> DNS - fine for test setups, not for deployment.
> 
> It's nice to say you don't like using pis for delivered systems, but that's not useful to anyone else unless you explain why.  

Fair enough.

> 
> The rPi foundation even makes boards specifically for embedded systems and I believe they have some level of assurance these units will continue to be available. 

Normally when talking about a Pi without being specific, it is
reasonable to assume standard Pi boards.  These have no guaranteed
availability lifetime, no thoughts of MTBF or environmental limits, are
full of connectors without any locking or stability, are impractical for
any kind of solid mounting, and are not practically designed for
production, testing and integration with industrial systems that need to
be produced consistently, solidly, reliably, and cheaply.

These devices are made for the desktop - for education, experiments,
fun, prototypes, for cheap computers.  They are excellent for that.  But
not for later stages in most kinds of delivered embedded systems.  (Of
course there are some kinds of system where they are fine, but those are
in the minority.)  You buy you Pi boards one at a time, not in
deliveries of hundreds or thousands.

The embedded Pi cards /are/ more suited for production of finished
systems.  But they still suffer from the same disadvantage any embedded
Linux system has in comparison to using small microcontrollers - long
and complicated production programming, finer and more delicate
electronics, security, software auditing and control, software
licensing, timing jitter, boot times, large and complex updates,
unstable software, support, developer requirements, power requirements,
environmental limits.

Now, embedded Linux systems can give you enormous flexibility, and you
get a vast amount of software features and power for very little cost.
In many systems, this is what you want, and a Pi compute module (not a
normal Pi) may be a reasonable way to get that.  But in many more
systems, you don't need that - and the cost of having a much more
complex system is far too high.

> 
> 
>>> Almost everything has Ethernet now.
>>
>> Almost every microcontroller does /not/ have Ethernet.  Almost every
>> electronics board made does /not/ have Ethernet.
> 
> I think both statements are exaggerations.  Plenty of MCUs are Ethernet capable.  

I did a quick and unscientific test.  On Digikey, there are 78,510
microcontrollers.  4,498 have Ethernet.  (Yes, I know you get multiple
lines for essentially the same devices.)  I will admit that is a higher
proportion than I had expected.  But still, the great majority of
available types of microcontroller do not have Ethernet.  And while I
have no statistics here, I would expect the non-Ethernet
microcontrollers here to ship in several orders of magnitude higher
quantities than the the ones with Ethernet.  At what point can we say
that almost every microcontroller shipped does not have Ethernet?  99%
99.9%?  99.99%?


Certainly Ethernet is getting more common - there are more devices
available, and there are quality network stacks available freely.  There
is a much lower entry cost to using Ethernet now than there was 5 years
ago.  But still I stand by my statement that almost every board made
does not have Ethernet.

> If you want Ethernet it is easy to select a version with a network interface. 
> 

That is true, when you are at a certain size of microcontroller.  If you
are talking about a 32-bit device with 64 or more pins, 256K flash and
64K ram, running at 60+ MHz - yes, there is a high chance that you can
find a device in the same family that has Ethernet.  If you are using
8-bit or 16-bit microcontrollers, small or cheap devices (which may be
32-bit), low-power devices, high temperature devices, tiny package
devices - no, you probably won't find Ethernet alternatives without
changing family.

In my own designs, I am quite fond of Ethernet.  It gives a lot of
flexibility and convenience.  (I have a board plan which would have
Ethernet merely for development and debugging.)  But it is not for every
use.

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

#28593

On Friday, March 1, 2019 at 3:04:39 AM UTC-6, David Brown wrote:
> On 01/03/2019 00:07, gnuarm.deletethisbit@gmail.com wrote:
> > On Thursday, February 28, 2019 at 1:41:36 AM UTC-6, David Brown wrote:
> >> On 28/02/2019 05:15, Les Cargill wrote:
> >>>
> >>> Generally, I'll have a custom TCP server running on the Pi, which
> >>> provides the option of encoding any twiddly parts about the device on
> >>> the other end of the FTDI device, within the Pi.
> >>
> >> I don't know what kind of systems you work with, but to me a Pi is
> >> convenient for testing and developing, but is out of the question for
> >> most delivered systems.  The same goes for jumbled mixups with dynamic
> >> DNS - fine for test setups, not for deployment.
> > 
> > It's nice to say you don't like using pis for delivered systems, but that's not useful to anyone else unless you explain why.  
> 
> Fair enough.
> 
> > 
> > The rPi foundation even makes boards specifically for embedded systems and I believe they have some level of assurance these units will continue to be available. 
> 
> Normally when talking about a Pi without being specific, it is
> reasonable to assume standard Pi boards.  

That makes no sense to me.  If they make board intended for commercial use, then why not talk about those? 


> These have no guaranteed availability lifetime, 

Sure, if you limit your discussion to boards that are not intended for commercial use... they aren't likely going to be a perfect match to a commercial application.  


> no thoughts of MTBF or environmental limits, are
> full of connectors without any locking or stability, 

How is that different from most embedded, Linux CPU boards?  Beagle Bone is pretty much the same in this regard. 


> are impractical for any kind of solid mounting, 

That's not in evidence.  All but the first rPi have mounting holes.  


> and are not practically designed for
> production, testing and integration with industrial systems that need to
> be produced consistently, solidly, reliably, and cheaply.

Absolutely no evidence to support any of this... especially the "cheaply" part! 


> These devices are made for the desktop - for education, experiments,
> fun, prototypes, for cheap computers.  They are excellent for that.  But
> not for later stages in most kinds of delivered embedded systems.  (Of
> course there are some kinds of system where they are fine, but those are
> in the minority.)  You buy you Pi boards one at a time, not in
> deliveries of hundreds or thousands.

Simply not true.  I can buy 4600 of the rPi 3A+ off the shelf. 


> The embedded Pi cards /are/ more suited for production of finished
> systems.  But they still suffer from the same disadvantage any embedded
> Linux system has in comparison to using small microcontrollers - long
> and complicated production programming, 

I don't get why you think this is such a poor device for embedded work.  None of the above is valid.  


> finer and more delicate
> electronics, 

???  I don't think you work with electronics much. 


> security, software auditing and control, software
> licensing, timing jitter, boot times, large and complex updates,
> unstable software, support, developer requirements, power requirements,
> environmental limits.

You aren't talking about the rPi.  You are talking about Linux computers in general.  Yes, if you don't want a Linux computer, then a Linux computer is a bad choice. 


> Now, embedded Linux systems can give you enormous flexibility, and you
> get a vast amount of software features and power for very little cost.
> In many systems, this is what you want, and a Pi compute module (not a
> normal Pi) may be a reasonable way to get that.  But in many more
> systems, you don't need that - and the cost of having a much more
> complex system is far too high.

The only real difference between the rPi 3B+ or rPi 3A+ and the compute unit is that the compute unit needs more stuff on the mother board.  


> >>> Almost everything has Ethernet now.
> >>
> >> Almost every microcontroller does /not/ have Ethernet.  Almost every
> >> electronics board made does /not/ have Ethernet.
> > 
> > I think both statements are exaggerations.  Plenty of MCUs are Ethernet capable.  
> 
> I did a quick and unscientific test.  On Digikey, there are 78,510
> microcontrollers.  4,498 have Ethernet.  (Yes, I know you get multiple
> lines for essentially the same devices.)  I will admit that is a higher
> proportion than I had expected.  But still, the great majority of
> available types of microcontroller do not have Ethernet.  And while I
> have no statistics here, I would expect the non-Ethernet
> microcontrollers here to ship in several orders of magnitude higher
> quantities than the the ones with Ethernet.  At what point can we say
> that almost every microcontroller shipped does not have Ethernet?  99%
> 99.9%?  99.99%?

That is not a useful issue.  The issue is whether you can get Ethernet or not.  The answer is you can use Ethernet in pretty much any app you wish because you can buy a chip or board with networking across the range of sizes of MCUs/CPUs other than the smallest that get used in toasters and microwaves. 


> Certainly Ethernet is getting more common - there are more devices
> available, and there are quality network stacks available freely.  There
> is a much lower entry cost to using Ethernet now than there was 5 years
> ago.  But still I stand by my statement that almost every board made
> does not have Ethernet.

You can stand anywhere you want.  You just contradicted yourself.  


> > If you want Ethernet it is easy to select a version with a network interface. 
> > 
> 
> That is true, when you are at a certain size of microcontroller.  If you
> are talking about a 32-bit device with 64 or more pins, 256K flash and
> 64K ram, running at 60+ MHz - yes, there is a high chance that you can
> find a device in the same family that has Ethernet.  If you are using
> 8-bit or 16-bit microcontrollers, small or cheap devices (which may be
> 32-bit), low-power devices, high temperature devices, tiny package
> devices - no, you probably won't find Ethernet alternatives without
> changing family.

Ok, so what is your point? 


> In my own designs, I am quite fond of Ethernet.  It gives a lot of
> flexibility and convenience.  (I have a board plan which would have
> Ethernet merely for development and debugging.)  But it is not for every
> use.

No shoe fits every foot.  Of course. 

Rick C.

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

#28599

David Brown wrote:
> On 01/03/2019 00:07, gnuarm.deletethisbit@gmail.com wrote:
>> On Thursday, February 28, 2019 at 1:41:36 AM UTC-6, David Brown wrote:
>>> On 28/02/2019 05:15, Les Cargill wrote:
>>>>
>>>> Generally, I'll have a custom TCP server running on the Pi, which
>>>> provides the option of encoding any twiddly parts about the device on
>>>> the other end of the FTDI device, within the Pi.
>>>
>>> I don't know what kind of systems you work with, but to me a Pi is
>>> convenient for testing and developing, but is out of the question for
>>> most delivered systems.  The same goes for jumbled mixups with dynamic
>>> DNS - fine for test setups, not for deployment.
>>
>> It's nice to say you don't like using pis for delivered systems, but that's not useful to anyone else unless you explain why.
> 
> Fair enough.
> 
>>
>> The rPi foundation even makes boards specifically for embedded systems and I believe they have some level of assurance these units will continue to be available.
> 
> Normally when talking about a Pi without being specific, it is
> reasonable to assume standard Pi boards.  These have no guaranteed
> availability lifetime, no thoughts of MTBF or environmental limits, are
> full of connectors without any locking or stability, are impractical for
> any kind of solid mounting, and are not practically designed for
> production, testing and integration with industrial systems that need to
> be produced consistently, solidly, reliably, and cheaply.
> 
> These devices are made for the desktop - for education, experiments,
> fun, prototypes, for cheap computers.  They are excellent for that.  But
> not for later stages in most kinds of delivered embedded systems.  (Of
> course there are some kinds of system where they are fine, but those are
> in the minority.)  You buy you Pi boards one at a time, not in
> deliveries of hundreds or thousands.
> 


Oh, to be sure - a straight Pi isn't fit for most uses. I did do an 
experiment where a vanilla Cubie board ran in an extremely harsh 
environment for over a year :) it wasn't a purely intentional
experiment - the Cubie was  placeholder while the "real board"
was being developed and somebody forgot to upgrade it. Indeed, it
should not have been deployed outside of test at all.

Even worse for the Pi is that the Ethernet hangs off the USB bus and 
eats a lot of USB bandwidth, if that's a consideration.

> The embedded Pi cards /are/ more suited for production of finished
> systems.  But they still suffer from the same disadvantage any embedded
> Linux system has in comparison to using small microcontrollers - long
> and complicated production programming, finer and more delicate
> electronics, security, software auditing and control, software
> licensing, timing jitter, boot times, large and complex updates,
> unstable software, support, developer requirements, power requirements,
> environmental limits.
> 
> Now, embedded Linux systems can give you enormous flexibility, and you
> get a vast amount of software features and power for very little cost.
> In many systems, this is what you want, and a Pi compute module (not a
> normal Pi) may be a reasonable way to get that.  But in many more
> systems, you don't need that - and the cost of having a much more
> complex system is far too high.
> 
>>
>>
>>>> Almost everything has Ethernet now.
>>>
>>> Almost every microcontroller does /not/ have Ethernet.  Almost every
>>> electronics board made does /not/ have Ethernet.
>>
>> I think both statements are exaggerations.  Plenty of MCUs are Ethernet capable.
> 
> I did a quick and unscientific test.  On Digikey, there are 78,510
> microcontrollers.  4,498 have Ethernet.  (Yes, I know you get multiple
> lines for essentially the same devices.)  I will admit that is a higher
> proportion than I had expected.  But still, the great majority of
> available types of microcontroller do not have Ethernet.  And while I
> have no statistics here, I would expect the non-Ethernet
> microcontrollers here to ship in several orders of magnitude higher
> quantities than the the ones with Ethernet.  At what point can we say
> that almost every microcontroller shipped does not have Ethernet?  99%
> 99.9%?  99.99%?
> 

What I mean by my statement is that there usually exists a comparable 
member of a family or another family close to the one without Ethernet
for a little additional monetary cost.

Ann it may be that a Pi makes a nice addition to field kit complete with 
specialized software. I had a long-term J1939 logger based on a Pi that
worked great - at the other end of a WiFi link was a PC that did all the 
actual logging.

> 
> Certainly Ethernet is getting more common - there are more devices
> available, and there are quality network stacks available freely.  There
> is a much lower entry cost to using Ethernet now than there was 5 years
> ago.  But still I stand by my statement that almost every board made
> does not have Ethernet.
> 

Far enough. We have to decide what the tradeoffs need to be.

>> If you want Ethernet it is easy to select a version with a network interface.
>>
> 
> That is true, when you are at a certain size of microcontroller.  If you
> are talking about a 32-bit device with 64 or more pins, 256K flash and
> 64K ram, running at 60+ MHz - yes, there is a high chance that you can
> find a device in the same family that has Ethernet.  If you are using
> 8-bit or 16-bit microcontrollers, small or cheap devices (which may be
> 32-bit), low-power devices, high temperature devices, tiny package
> devices - no, you probably won't find Ethernet alternatives without
> changing family.
>

IMO, 8 or 16 bit devices should have a lot smaller software footprint 
and darn near be fully testable ( if you have the schedule for it ).

That doesn't mean zero defects but it means greatly reduced defects.


> In my own designs, I am quite fond of Ethernet.  It gives a lot of
> flexibility and convenience.  (I have a board plan which would have
> Ethernet merely for development and debugging.)  But it is not for every
> use.
> 

Fair enough.

-- 
Les Cargill

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

#28592

gnuarm.deletethisbit@gmail.com writes:
> It's nice to say you don't like using pis for delivered systems, but
> that's not useful to anyone else unless you explain why.

I asked the grisp.org guy that same question, and he replied that:

1) most of the effort in developing an embedded dev environment was in
writing device drivers that are very hardware-specific, and in the case
of the pi, the hardware changes so fast that the drivers have to be
rewritten all the time.  So he wanted hardware with a longer lifecycle.

2) the rpi foundation doesn't allow changing the hardware design: you
can plop their boards into their product and that's it.  Note that the
Beaglebone doesn't have that restriction, and there are various
Beaglebone-derived boards available from seeedstudio and elsewhere.

The Grisp board is very nice but expensive enough that I can't imagine
using one in a hobby project.  Erlang on Grisp (basically Erlang runs on
the bare metal without an intermediary OS) may have some slight latency
advantages vs Erlang under Linux on an rpi, but if something is really
hard-real-time I'd like to hope it can be offloaded to a simpler mcu
(like the realtime coprocessors on the beaglebone) or to an FPGA.

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

#28594

On Friday, March 1, 2019 at 4:25:39 AM UTC-6, Paul Rubin wrote:
> gnuarm.deletethisbit@gmail.com writes:
> > It's nice to say you don't like using pis for delivered systems, but
> > that's not useful to anyone else unless you explain why.
> 
> I asked the grisp.org guy that same question, and he replied that:
> 
> 1) most of the effort in developing an embedded dev environment was in
> writing device drivers that are very hardware-specific, and in the case
> of the pi, the hardware changes so fast that the drivers have to be
> rewritten all the time.  So he wanted hardware with a longer lifecycle.

What "fast" changes???  They have stopped producing the earliest version, but you can still buy the Raspberry Pi 1 Model B+ and A+ along with pin compatible update units.  


> 2) the rpi foundation doesn't allow changing the hardware design: you
> can plop their boards into their product and that's it.  Note that the
> Beaglebone doesn't have that restriction, and there are various
> Beaglebone-derived boards available from seeedstudio and elsewhere.

Normally people don't worry about buying a standard configuration and adding I/O.  Needing to change the CPU board is not often needed and is very limiting for most commercial units, not just the rPi.  

Rick C. 

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

#28595

gnuarm.deletethisbit@gmail.com writes:
> What "fast" changes???  They have stopped producing the earliest
> version, but you can still buy the Raspberry Pi 1 Model B+ and A+
> along with pin compatible update units.

I think he mentioned 10+ years.  The usual retailers don't stock the
pi-1 any more but it's interesting that the Pi-1 if it's still
available someplace.

> Normally people don't worry about buying a standard configuration and
> adding I/O.  Needing to change the CPU board is not often needed and
> is very limiting for most commercial units, not just the rPi.

I can understand wanting to make a product with a single board (cpu and
any needed ports and peripherals on the same board) instead of multiple
boards or modules plugged together.

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

#28598

David Brown wrote:
> On 28/02/2019 05:15, Les Cargill wrote:
>> Robert Wessel wrote:
>>> On Sat, 23 Feb 2019 14:48:40 -0600, Les Cargill
>>> <lcargill99@comcast.com> wrote:
>>>
>>>> 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.
>>>> <snip>
>>>>>
>>>>> I don't pretend to have answers in the general case, just interested
>>>>> in what peoples thoughts are.
>>>>>
>>>>
>>>> Anything you can do with RS323 you can do with Ethernet. There are
>>>> pathological size/weight/power cases where Ethernet doesn't fit but
>>>> if it does...
>>>
>>>
>>> Ethernet does have a couple of annoying configuration issues, and
>>> requires either a custom client on an attached PC, or requires enough
>>> software to implement TCP and a TELNET or HTTP server (and TCP/IP
>>> brings a couple of annoying configuration issues as well).
>>>
>>
>> There exist things like RasPi boards which can have FTDI USB
>> RS232 ports attached. So really? You should be able to use DynDNS and
>> DHCP and that's about all the config you need. With the RasPi's I have
>> seen, it's even 802.11 - just carry an AP and you're in.
>>
>> You can do all the fiddly bits once, and offsite.
>>
>> Generally, I'll have a custom TCP server running on the Pi, which
>> provides the option of encoding any twiddly parts about the device on
>> the other end of the FTDI device, within the Pi.
> 
> I don't know what kind of systems you work with, but to me a Pi is
> convenient for testing and developing, but is out of the question for
> most delivered systems.  The same goes for jumbled mixups with dynamic
> DNS - fine for test setups, not for deployment.
> 

All I can say is that a Pi makes a fine terminal server. Whether it's
appropriate for deployed systems is up to you. I'd much rather use a
Pi for field debugging rather than be tied to a serial cable's length 
from the DUT.

>>
>>> And, of course, as soon as you do have an Ethernet connection,
>>> anything non-TCP/IP is ruled out because the customer and marketing
>>> will immediately want to be able to do (whatever) from across the
>>> campus, and then inevitably further than that.  And then you have
>>> security issues.
>>>
>>
>> Almost everything has Ethernet now.
> 
> Almost every microcontroller does /not/ have Ethernet.  Almost every
> electronics board made does /not/ have Ethernet.
> 

Then you have to do something else, and it'll probably have to be a
fully supported, costed and tracked set of circuit packs along with the 
associated soft deliverables.

And it'll rot like beef in the summer sun as soon as the budget gets cut.

Underspeccing the I/O capability of a target made a lot more sense 30 
years ago than it does now.


>>
>>> Definitely the way to go if you can, but there are enough hurdles that
>>> you can find yourself longing for async RS-232 and a terminal
>>> emulator.
>>>
>>
>> Oh, not so much :) Well, sometimes :)
>>
> 

-- 
Les Cargill

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

#28550

On 2/23/19 3:48 PM, Les Cargill wrote:
> 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.  
> <snip>
>>
>> I don't pretend to have answers in the general case, just interested
>> in what peoples thoughts are.
>>
> 
> Anything you can do with RS323 you can do with Ethernet. There are
> pathological size/weight/power cases where Ethernet doesn't fit but
> if it does...
> 

Not sure I would consider it pathological to not have Ethernet as a
likely option. Almost every small processor today has serial ports built
in, and most of the ones that don't can fake it with bit banging pretty
easy. You need a processor with much more significant resources before
you get an Ethernet port on the processor, and then you need the
resources for the Ethernet stack.

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

#28583

Richard Damon wrote:
> On 2/23/19 3:48 PM, Les Cargill wrote:
>> 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.
>> <snip>
>>>
>>> I don't pretend to have answers in the general case, just interested
>>> in what peoples thoughts are.
>>>
>>
>> Anything you can do with RS323 you can do with Ethernet. There are
>> pathological size/weight/power cases where Ethernet doesn't fit but
>> if it does...
>>
> 
> Not sure I would consider it pathological to not have Ethernet as a
> likely option. Almost every small processor today has serial ports built
> in, and most of the ones that don't can fake it with bit banging pretty
> easy. You need a processor with much more significant resources before
> you get an Ethernet port on the processor, and then you need the
> resources for the Ethernet stack.
> 

Dunno; there are Arduino-class devices that fake having an Ethernet
port pretty well...

So that's when you use a RasPi as a serial port server.

-- 
Les Cargill

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

#28515

On Monday, February 18, 2019 at 4:49:07 AM UTC-5, 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.

The RS-232 adapters are much easier to locate.  RS-232 is not hard to add to any circuit, it's just one chip and a very common chip at that.  Adding yet another special connector that has to be documented and shown to an operator is even more work.  The DB-9 serial port connector is still very common and not used for much else so hard to mix up with anything else.  

My only regret is not using a right angle connector on the board so the cable didn't stick up in the air, but rather laid flat. 

But none of that is important at this point.  I found the com0com software that lets me use the test fixture emulator without any hardware at all, including the USB serial port adapters.  Yea! 

Rick C.

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web