Do you still use "RS232" or something else?

On 15-Jan-11 8:59 AM, Oliver Betz wrote:
> Supplement:
>
> Thanks for all replies.
>
> Since several people voted for USB - UART adapters, usually FTDI FT232
> flavour: That's also my preferred solution for people not being
> long-sighted enough to by a suitable computer with a real comm port.
>
> But I suggest this only as a solution separate from my device (not
> integrated), because the installation requires Administrator rights,
> IOW is much more intrusive than I want one of my designs to be.
>
> Oliver

For a selection of FTDI FT232 flavour devices, have a look at:
http://www.dontronics-shop.com/picaxe-ftdi-program.html

and have a read of the user feed back on FTDI devices on this page:
http://www.dontronics-shop.com/easysync-premium-gold-usb-rs232-adapter-cable-10cm-cable.html

Also Windows 7 Auto install the drivers when the device is detected, and drivers are available for ALL common O/S.

hope this helps.

Cheers Don...

==============



-- 
Don McKenzie

Site Map:            http://www.dontronics.com/sitemap
E-Mail Contact Page: http://www.dontronics.com/email
Web Camera Page:     http://www.dontronics.com/webcam
No More Damn Spam:   http://www.dontronics.com/spam

These products will reduce in price by 5% every month:
http://www.dontronics-shop.com/minus-5-every-month.html
http://www.dontronics-shop.com/ics.html

Bare Proto PCB for PIC or AVR projects?
"I'd buy that for a Dollar!".

On 1/14/2011 9:07 AM, Oliver Betz wrote:
> Didi wrote:
>
> [...]
>
>>> Therefore I'm reconsidering the best suited interface for device
>>> configuration and diagnosis.
>
> [...]
>
>> I am going Ethernet - tcp/ip, VNC (RFB) access to my stuff - this
>> leaves
>> the communication to whatever is at the other side to the pixel/mouse/
>> keyboard
>> level.
>> Latest thing to be proudly shown: http://tgi-sci.com/tgi/nmca3.htm
>> (board can be seen at http://tgi-sci.com/misc/nmc3top.gif )
>
> this uses Ethernet for the _main_ operation. That's different from
> what I wrote ("device configuration and diagnosis").

You would have to clarify what you *really* intend by that
statement.

E.g., if your device is "malfunctioning" (read that as "not functioning
as could be reasonably expected by a typical user") then you can be
implying that something is "FUBAR" and your network subsystem *isn't*
functioning.  Sort of like telnet'ing to a host because your GUI
login isn't configured properly (i.e., "effectively unavailable").

OTOH, if your device is robust enough to be operational *including*
the networking aspects, then you could still support "configuration
and diagnosis" over the wire.

E.g., my systems degrade gracefully, shedding more complex
functionality in stages.  Sort of like the layers in the human
brain (i.e., sight goes before smell).  At the lowest level,
a JTAG port lets *me* poke around to "diagnose" what might
be wrong -- but that would never be exposed to the user.
Above that, a (5V) serial port lets me talk to the kernel
debugger.  Above that, curses under telnet sessions.  Above
that, "pretty" HTTP sessions.

In my case, telnet and below are not intended for exposure to the
user.  If the user can't sort out what is wrong with the device
with the "stock" capabilities offered, its a "big problem".
I.e., that is *supposed* to work.

If you have faith in your codebase and just fear the user might
screw up the network configuration (etc.), then offer a *simple*
recovery mechanism:
- use a crossover cable to connect the device DIRECTLY to a PC
- set the PC's IP address to x.x.x.x, mask 0xffffff00
- push the reset button on the device for 23 seconds until the
   green light turns pink
- from the PC, ping z.z.z.z
- once this succeeds, browse to http://z.z.z.z and follow the directions
   on the screen

Note that this process need not alter any *other* settings in
your device -- nor interfere with its operation.  I.e., it just
gets the user interface working "predictably"

On 1/14/2011 3:20 PM, Andrew Smallshaw wrote:
> On 2011-01-14, Oliver Betz<obetz@despammed.com>  wrote:
>>
>> although most of our (industrial) clients still use to have computers
>> with a "real" serial port, I observe a small but increasing number
>> struggling with bad USB adapters and asking for other interfaces.
>>
>> Therefore I'm reconsidering the best suited interface for device
>> configuration and diagnosis.
>
> Others have made a fine job of considering the technical issues so
> I'll restrict myself to the user perspective here.
>
> RS232 runs can be fairly long - 100m easily enough over regular

Yes and no.  Ignoring the "specified" criteria, I find that
modern EIA232 ports often use devices that would be hard pressed
to drive a cable with lots of C at high rates.  The problem
with EIA232 is there are too many flavors and bastardizations.
I.e., getting connector sex correct, pinouts correct, handshaking
lines correct, etc.

One firm I worked at had a *box* (close to a cubic yard) of "RS232
cables".  You typically spent the better part of an hour sorting
through cables *hoping* to find one that worked to connect your
<whatever> to your <whatever_else>.  Cables are rarely documented.
Interfaces are rarely documented in a convenient place (like right
next to the connector!!).

I have standardized on 25 pin M-F cables, here.  And, have a box of
"widgets" (2" x 2" boxes with a pair of connectors) that do all of
the "personality" modifications to those "straight through" cables.
As a result, I can synthesize a particular cable type just by
stacking widgets; then look at the cascaded wiring to sort out
what the *actual* cable pinout (and connector types) needs to be
(in case I need to manufacture a cable like that).

I find having an indicator that gives the user some form of
feedback *while* he is attaching cables is invaluable.  I
stole this idea from Data I/O on their UniSite (which has
*no* "user interface" other than two LEDs).

[N.B. They also included buttons that would swap Tx/Rx pins
as they recognized users will possibly have the need for this
functionality -- easier (for the user) to just push a button
than to hunt for a cable that has the correct pinout]

If you use RS232, try to resort *only* to TxD/RxD as it just
minimizes the requirements you place on the user's end (and
the cable) -- though even that isn't foolproof as the user's
end might require signaling conductors.

And, be sure you can handle data as fast as it comes down the wire
(limit your bit rate, if necessary) so the user doesn't have
to deal with *any* sort of handshaking

> Cat5 cables.  USB is a complete non-starter over that kind of
> distance meaning the equipment and computer need to be located
> together.  That isn't always convenient.

You can also find short/long haul modems that act like VERY long
wires...

> RS232 with a CLI interface does not depend on anything special on
> the host computer - just a terminal emulator.  That means I can
> use any machine that comes to hand and I don't need to track down
> and install software first.  If it's a twenty year old bit of kit
> I am not dependant on the manufacturer still being in existence
> and providing new software for a modern OS.  Of course a CLI needs
> more space than something that simply downloads a new configuration
> in a fixed binary format but that may be a matter of a kilobyte -
> probably less than you need to implement USB or a TCP/IP stack
> before you even think of your application-level processing.
>
> RS232 is still ubiquitious in many applications and there are many
> methods of handling it.  A simple use may be direct connection to
> a PC but dial in use becomes a possibility for remote access, and
> at the high end there are the consoles servers from Cyclades and
> the like for those that have to manage dozens of devices in a
> robust, organised manner.
>
> As for the quality of USB-serial adapters, if you keep to a couple
> of simple rules you shouldn't have any issues.  First of all, if
> you use an RS232 port make sure you actually use RS232 - it is a
> serial interface, not a GPIO port. (Ab)using handshaking pins to
> do something they were not intended for is always going to be asking
> for trouble.
>
> The other potential gotcha is with break handling.  In my view it
> is unforgivable that there are adapters that can't send a break
> signal but they are out there - bear that in mind at the design
> phase so you never need a break and it simply won't be an issue.

If you deal with BREAKs, then you also have to deal with varying
interpretations of "BREAK".  This just puts one more thing on the
list of things a user has to verify/ensure.

Often, drivers don't recover gracefully from BREAKs so that
adds another issue to resolve.

> On a purely personal basis I'd much rather see an RS232 port that
> I know I'm likely to never have issues with, rather than a USB
> interface that depends on a vendor supplied app that may be useless

+42

> in five years time.  Network configuration is slightly better but
> that depends on how the initial network config is done (IP address
> and netmask).  A DHCP client depends on a network running DHCP in
> the first place, and anything that initially sets itself up as DHCP
> server (like most home routers) can't be connected to a production
> network until they are configured.

I favor the "fixed IP configuration" (I mentioned in another post).
It means taking the device off the "real" network and connecting it to
a "specific" host but it's a no brainer after that.

A more expensive solution is to put the NIC into promiscuous mode
and then respond to *anything* coming down the wire.  But, this can
be risky for some applications if the device remains on a "busy"
network.

Oliver Betz <obetz@despammed.com> wrote:

>Hello All,
>
>although most of our (industrial) clients still use to have computers
>with a "real" serial port, I observe a small but increasing number
>struggling with bad USB adapters and asking for other interfaces.
>
>Therefore I'm reconsidering the best suited interface for device
>configuration and diagnosis.

Serial over bluetooth offers some advantages.

 In an industrial environment the computer will probably be a notebook with
built in bluetooth. 

No drivers, no cables, no software changes, more secure. 

You can get bluetooth adapters which plug into a 9 way 'D' so it is easy
enough to try it.

On 01/14/11 23:13, Oliver Betz wrote:
> Do you still use EIA-232? Customers complaining?

Don't know, but I can tell you what I wished for, even 25 years
ago when I had almost daily fights with RS-232 cabling.

A symmetrical standard based on a hermaphrodite 8-wire connector.

My-ground, I'm-ready, my-data, my-power/my-inverted-data (if
differential), and the corresponding 4 inputs.

Put them all in a symmetric 8 conductor socket that's half
male, half female, so if you can plug it in, and have the
right data-rate, it'll work. In differential mode, it would
be good for half-mile runs at decent data rates on CAT-5.

Center the data levels at 2.5V, with swings to 0 and 5V so you
don't need elevated supplies from a 5V system, and you can
easily transfer useful power, perhaps 100mA, for low-power
peripherals, even when using differential transmission.

I don't get why hermaphrodite connectors never took off, it
just seems like a no-brainer. They might be a little harder
to make, but in volume would surely be cheaper than DE-25s.

Clifford Heath.

On 1/14/2011 6:01 PM, Clifford Heath wrote:
> On 01/14/11 23:13, Oliver Betz wrote:
>> Do you still use EIA-232? Customers complaining?
>
> Don't know, but I can tell you what I wished for, even 25 years
> ago when I had almost daily fights with RS-232 cabling.

+42

> A symmetrical standard based on a hermaphrodite 8-wire connector.
>
> My-ground, I'm-ready, my-data, my-power/my-inverted-data (if
> differential), and the corresponding 4 inputs.
>
> Put them all in a symmetric 8 conductor socket that's half
> male, half female, so if you can plug it in, and have the
> right data-rate, it'll work. In differential mode, it would
> be good for half-mile runs at decent data rates on CAT-5.
>
> Center the data levels at 2.5V, with swings to 0 and 5V so you
> don't need elevated supplies from a 5V system, and you can
> easily transfer useful power, perhaps 100mA, for low-power
> peripherals, even when using differential transmission.

I'd add a desire for something that is "self-aligning"
(not just "keyed") -- so you could mate the connectors
with your eyes closed, hands behind the back of the
machine, etc.

And, something that takes a fair bit of effort to *un*plug
(i.e., so the connection can easily support the weight of a
cable when a significant length of cable "hangs" from the plug)

[and, of course, dirt cheap!  :> ]

> I don't get why hermaphrodite connectors never took off, it
> just seems like a no-brainer. They might be a little harder
> to make, but in volume would surely be cheaper than DE-25s.

I encounter them in selected applications.  Some automotive.
I note that APC UPS's battery connectors are symmetric
(not "obviously" half-male, half-female)

On 15 Jan., 02:01, Clifford Heath <n...@spam.please.net> wrote:
> On 01/14/11 23:13, Oliver Betz wrote:
>
> > Do you still use EIA-232? Customers complaining?
>
> Don't know, but I can tell you what I wished for, even 25 years
> ago when I had almost daily fights with RS-232 cabling.
>
> A symmetrical standard based on a hermaphrodite 8-wire connector.
>
> My-ground, I'm-ready, my-data, my-power/my-inverted-data (if
> differential), and the corresponding 4 inputs.
>
> Put them all in a symmetric 8 conductor socket that's half
> male, half female, so if you can plug it in, and have the
> right data-rate, it'll work. In differential mode, it would
> be good for half-mile runs at decent data rates on CAT-5.
>
> Center the data levels at 2.5V, with swings to 0 and 5V so you
> don't need elevated supplies from a 5V system, and you can
> easily transfer useful power, perhaps 100mA, for low-power
> peripherals, even when using differential transmission.
>
> I don't get why hermaphrodite connectors never took off, it
> just seems like a no-brainer. They might be a little harder
> to make, but in volume would surely be cheaper than DE-25s.
>
> Clifford Heath.

Hi Clifford

Please look here - the nearest EIA-232 wiring supporting some of your
wishes - via 8P8C aka "RJ-45":

http://www.lammertbies.nl/comm/cable/yost-serial-rj45.html

-

The USB standard ought to be with for a long time - why?:

It has only 1 twisted pair for bidirectional communication. It can not
get any simpler in hardware !

and 0V and to some extent optionally +5V.

D Yuniskis wrote:

>>> I am going Ethernet - tcp/ip, VNC (RFB) access to my stuff - this
>>> leaves
>>> the communication to whatever is at the other side to the pixel/mouse/
>>> keyboard
>>> level.
>>> Latest thing to be proudly shown: http://tgi-sci.com/tgi/nmca3.htm
>>> (board can be seen at http://tgi-sci.com/misc/nmc3top.gif )
>>
>> this uses Ethernet for the _main_ operation. That's different from
>> what I wrote ("device configuration and diagnosis").
>
>You would have to clarify what you *really* intend by that
>statement.
>
>E.g., if your device is "malfunctioning" (read that as "not functioning
>as could be reasonably expected by a typical user") then you can be
>implying that something is "FUBAR" and your network subsystem *isn't*
>functioning.  Sort of like telnet'ing to a host because your GUI
>login isn't configured properly (i.e., "effectively unavailable").

_My_ devices usually have no main "network" connection suitable for
"free form" diagnosis. They are offered without any "Network" (just
24V digital I/O) or with CAN (-open) or the He-Who-Must-Not-Be-Named
industrial bus from Big S.

"Free form" diagnosis means for example that the user can start some
self tests and gets results in human readable form. That's easy with a
terminal program.

With CANopen or Profibus, I had to get access to this bus from the PC
and to supply host software to achive a similar result. That's
impossible in most cases.

Therefore I need a simple "interactive" access to the device.
Currently EIA-232 if possible. Or UART data over 24V I/O with a
primitive (even passive) level converter for small sensors. We did
this long before IO-Link became popular.

>OTOH, if your device is robust enough to be operational *including*
>the networking aspects, then you could still support "configuration
>and diagnosis" over the wire.

If I had Ethernet anyway as Didi's spectrometer has, I would of course
offer configuration and diags there.

But I'm afraid our users won't use plain/clean Ethernet but switch to
"Screwed-Up-Profibus" which I won't implement unless I'm forced to.

Oliver
-- 
Oliver Betz, Muenchen (oliverbetz.de)

In article <igqlrk$d2c$1@speranza.aioe.org>, not.going.to.be@seen.com 
says...
> 
> On 1/14/2011 3:20 PM, Andrew Smallshaw wrote:
> > On 2011-01-14, Oliver Betz<obetz@despammed.com>  wrote:
> >>
> >> although most of our (industrial) clients still use to have computers
> >> with a "real" serial port, I observe a small but increasing number
> >> struggling with bad USB adapters and asking for other interfaces.
> >>
> >> Therefore I'm reconsidering the best suited interface for device
> >> configuration and diagnosis.
> >
> > Others have made a fine job of considering the technical issues so
> > I'll restrict myself to the user perspective here.
> >
> > RS232 runs can be fairly long - 100m easily enough over regular
> 
> Yes and no.  Ignoring the "specified" criteria, I find that
> modern EIA232 ports often use devices that would be hard pressed
> to drive a cable with lots of C at high rates.  The problem
> with EIA232 is there are too many flavors and bastardizations.
> I.e., getting connector sex correct, pinouts correct, handshaking
> lines correct, etc.

USB and connectors or length of leads can be a right pain, when dealing
with OTHER people's equipment

	Is it USB A M of F
	IS it USB B or Mini B or Micro B the M/F (or even 4 or 5 pin)

Now we have the USB 3 variants as well

You always have a lead around not quite long enough
-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/>  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

On 2011-01-14, Oliver Betz <OBetz@despammed.com> wrote:
> Supplement:
>
> Thanks for all replies.
>
> Since several people voted for USB - UART adapters, usually FTDI FT232
> flavour: That's also my preferred solution for people not being
> long-sighted enough to by a suitable computer with a real comm port.
>
> But I suggest this only as a solution separate from my device (not
> integrated), because the installation requires Administrator rights,
> IOW is much more intrusive than I want one of my designs to be.

Windows doesn't support the common USB-serial chips (FTDI, PL2303,
etc.) right out of the box?!?!?  Good grief, those chips have been
around for ages.

-- 
Grant