Do you still use "RS232" or something else?

For a selection of FTDI FT232 flavour devices, have a look at:

formatting link

and have a read of the user feed back on FTDI devices on this page:

formatting link

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
 Click to see the full signature
Reply to
Don McKenzie
Loading thread data ...

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"

Reply to
D Yuniskis

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

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

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.

+42

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.

Reply to
D Yuniskis

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.

Reply to
nospam

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.

Reply to
Clifford Heath

+42

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

Reply to
D Yuniskis

Hi Clifford

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

formatting link

-

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.

Reply to
Glenn

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

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)
Reply to
Oliver Betz

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
    PC Services
 Click to see the full signature
Reply to
Paul

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
Reply to
Grant Edwards

I was surprised too. The FTDI devices I use are class-compliant and stock Ubuntu connects them as /dev/ttyUSB0 , ..1 , ..2 , etc. (some others as /dev/ttyACM* .) The pain at the user end is to figure out which one is which. Thank you, PCI bus...

Mel.

Reply to
Mel

If you take the time to put in a device-name and serial number, it's not too bad, but many people don't, and then there's no way to tell apart two completely different devices that happen to use the same chip.

I assume it requires an additional I2C EEPROM or something like that, so I guess it would cost another $0.30 or so.

--
Grant
Reply to
Grant Edwards

I'm not sure that the recurring cost of 232 is significantly lower than a small MCU implementing a USB stack. I have yet to add USB to a product, but I would say 232 is on it's last legs. Development cost is a different matter. 232 is so simple, a college freshman can implement it... and I did as a freshman...

Rick

Reply to
rickman

If you go for inverted data as well that is 5 connections each way.

I'd consider two differentially driven circuits in each direction as adequate. One TX pair and a Ready or Sync pair.

If you are thinking like the LEMO half and half connectors, they are somewhat pricey.

Maybe the price.

--
********************************************************************
Paul E. Bennett...............
 Click to see the full signature
Reply to
Paul E. Bennett

One time, many years ago, I developed a standard pinout for an RJ-45 connector that allows every device to talk to every device. It had two grounds and the other pins were paired, TX-RX, RTS-CTS, DTR-DSR and the RJ-45 cable was wired as a crossover always. That part worked pretty well. But you still needed up to four adapters just for one size connector, the DB-25 still being the dominant size. By the time the DB-9 was adopted as an EIA standard, the DB-25 was getting to be rare and I found a lot less trouble getting things to pair up ok without the RJ-45. Now it seems like the male DB-9 connectors are all wired DTE while the female DB-9 connectors are all wired DCE so one cable with a null modem on one end if needed does the trick. If push comes to shove, and you find a DB-25 connector a DB-9 to DB-25 usually does the trick with the other stuff.

But I'm looking forward to the day when 232 is replaced by USB, not because laptop makers refuse to have them in the machine, but because USB is so easy to add there is no reason to use 232.

Rick

Reply to
rickman

RS-232 can (at low baud rates) tolerate a couple of orders of magnitude longer cables than USB. Of course we have Ethernet for that, but it adds a lot of complexity, both to the device and often for the user to set it up.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
 Click to see the full signature
Reply to
Spehro Pefhany
[...]

Even if you use a CDC USB device with the Windows drivers, you have to build a custom INF file, and you need admin rights to install them.

So the question is not only whether Windows has drivers (it has for CDC), but whether I need to "install" any drivers.

I didn't try it yet, but as far as I see, a HID doesn't need explicit installation, especially no admin rights under Windows.

But of course, you need custom software to make the data accessible, at least the equivalent to a terminal program.

Oliver

--
Oliver Betz, Muenchen (oliverbetz.de)
Reply to
Oliver Betz
[...]

Maybe I have a different understanding of "easy".

Using a terminal program (e.g the one supplied with the PC operating system) is easy. I can guide a customer's technician on the phone to do it. He doesn't even need Internet access there.

Providing software to access the USB HID data for every operating system is IMNSHO less easy. Windows X86, Windows 64 bit, Linux, Mac OS X, to be supported for more than ten years. I don't like to do it.

Oliver

--
Oliver Betz, Muenchen (oliverbetz.de)
Reply to
Oliver Betz
[...]

For the MCU side, USB can be cheaper then EIA-232.

Oliver

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

But you also need that to be some interface that the (typical) user will have ready access to. What distances are you concerned with?

And, how "interactive" does it have to be? E.g., entering the current date is more interactive than *picking* the day-of-week.

If you can live with the (short) distance limitations of USB, what if you made your device look like a mass storage device. I.e., damn near every USB host out there will recognize a USB "disk drive".

User can mount the drive (which is often automatic) and then access X:\index.html to interact with it. That *static* page (i.e., a "file" on your device) can have links to: X:\status.html, X:\log.html, X:\diagnostics.html, etc. You don't even need a "web server" in your device -- instead, you watch to see which "files" are accessed and in which order.

(I don't know what information you have to get from the user nor what you have to provide *to* him so I'm just suggesting a framework that you would have to evaluate)

Reply to
D Yuniskis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.