worthy successor of Serial Port(RS-232)? - Page 1
Forum section: electronics / projects

author: han
author_rank: Frequent Contributor
timestamp: April 30, 2014, 02:34:53 pm
content: RS-232 Serial port is the basic communication protocol which die hardEven with USB, I2C, SPI, it's still used in simple controllerWhat do you think's the successor of the serial port?with same attribute: simple, and capable for quite long distance (i consider RS422 is the same thing)

author: elgonzo
author_rank: Unknown
timestamp: April 30, 2014, 03:18:35 pm
content: Your question is not very clear the way you worded it.Just take look at the examples you have provided: RS232, USB, I2C, SPI. While all of them employ serial transimission schemes, USB and I2C are buses with device addressing schemes, and RS232 and SPI are rather point-to-point connection schemes (a-ka links, although you can connect multiple devices by providing additional device select lines).Also, note where those technologies are being used. To actually make sense of your question you would need to look/specify at least the application scenarios and/or environments in which a communication/data transmission technology should be used. There are reasons why - regarding computer peripherals - USB has replaced a number of other I/O interfaces including RS232. There are reasons why for other applications I2C/CAN or other buses is used and not USB. And there are a multitude of applications where you just need a point-to-point connection without needing all the complexities and operational requirements of a fast bus.Ofcourse, you could always roll another serial interface in the hope of it becoming the "next best popular thing". But, the reason why you usually don't do that is because it is too expensive and too time-consuming to do so and existing technologies just does work fine. As long as they will satisfy your needs, you will stick with existing technologies, because they are readily and cheaply available. On the other hand, USB is a prime example where a new incompatible development was justified in an (successful) attempt at solving a host of problems with prior I/O interfaces and the nightmare of configuring them.Your question sounds like RS232/242 is not being feasible anymore for long distances, but i tend to disagree. I mean, there are plenty of RS232/422 repeaters and stuff, so long distances cannot really be your problem...

author: NiHaoMike
author_rank: Super Contributor
timestamp: April 30, 2014, 10:54:35 pm
content: What was traditionally called "RS232" is indeed becoming less and less used. Instead, we're seeing a lot more low voltage UART connections that just happen to work exactly like RS232 from a software perspective.UART is easily implemented in silicon and is unlikely to go away anytime soon. SPI is even easier to implement, but requires more pins.

author: han
author_rank: Frequent Contributor
timestamp: May 01, 2014, 03:17:54 am
content: My friend at one day say.. "so you still use serial". that make me question is there any successor of RS232(UART)?I'm just curious. what the next simple protocol that can be more popular than UART(RS-232) That have same superiority then UART?-SPI -> I never see SPI used in Long distance-USB -> Limited length-Ethernet -> to difficult to implementedIn 10 year ago, there is RS-232 in every PC/Laptop.It's easy to use with microelectronic/PLC and other stuff.But the USB is not easy to implement. Using USB to serial give more problem due the random COM addressing.Ethernet is more complicated. You have to know hardware stack, and other weird and funny stuffThe Low voltage UART is same like RS-232. so will the RS-232 or low voltage UART one day replace by the same simple protocol

author: miguelvp
author_rank: Super Contributor
timestamp: May 01, 2014, 03:41:30 am
content: Wi232 or is it WiFi232For example:http://www.tcp232.net/WIFI232-G-simple-evaluation-board-kitfound others all of them from china but I have no experience with these at allhttp://www.ebay.com/itm/WIFI232-B-RS232-To-WIFI-UART-Serial-To-Wireless-Control-Module-Adapter-Convertor-/251293811560

author: madshaman
author_rank: Frequent Contributor
timestamp: May 01, 2014, 03:54:11 am
content: Quote from: han on May 01, 2014, 03:17:54 amMy cell phone uses serial, so do my CDs; so does PS3 controller and the undersea cable and/or satellites which carry these characters to Mr. Jones' server.I'm just teasing a bit.They all have different data rates, distance limitations, modulation and/or encoding schemes, error correction policies, logical and physical protocols.I think you might be putting the cart before the horse; it does work, but the poor horse can't see, and that's no fun for it.Here's my thinking, take it for what it's worth:Design of a communications protocol is usually based on a need. In short, there are requirements, and the protocol is engineered to meet them."Standard" protocols can emerge either due to a standards body being formed for that purpose, or more commonly, due to a defacto standard where one company invents the protocol and others adopt it to make their wodgits compatible.For example, Motorola developed SPI for their products and Phillips developed I2C for theirs (someone please correct me if I got this wrong), however both companies also developed compatible implementations of each other's protocols as did many others.I could be misinterpreting this, but it seems to me that you're imagining a world where people are looking for the *best* protocol to adopt across the board; I think these things evolve much more organically and ease and cost of implementation and compatibility plays a much bigger role than maximising some metric like operating distance or throughput.

author: NiHaoMike
author_rank: Super Contributor
timestamp: May 01, 2014, 04:16:41 am
content: Quote from: han on May 01, 2014, 03:17:54 amYou can use a udev rule to give a unique name based on parameters like USB IDs and serial number.UART is about as simple as it gets for an interface that only needs one wire (plus ground) for each direction.

author: Everett_Tom
author_rank: Contributor
timestamp: May 01, 2014, 04:58:33 am
content: I'm fond of slapping in a FTDI USB to RS232 chip - mainly because they do a good job of providing reliable drivers (assuming you hook up the flow control lines). It lets me think in RS232, and the product hooks up to modern PCs, and I don't have to maintain a hellish list of USB serial drivers.

author: AndyC_772
author_rank: Super Contributor
timestamp: May 01, 2014, 07:09:00 am
content: Quote from: han on May 01, 2014, 03:17:54 amRS232 and similar interfaces haven't gone away. They're still easy to implement, inexpensive, and just as capable of transmitting the same data over the same distance that they've always been able to do.They've more or less disappeared from PCs because of the demand for greater bandwidth. USB and Ethernet are much more appropriate interfaces for that particular application.The nearest "modern" equivalent I can suggest is CAN bus, which does more or less the same thing but works at higher speeds with lower voltages. But it's quite revealing to see that a modern microcontroller may have, say, one CAN interface and five or six UARTs.

author: han
author_rank: Frequent Contributor
timestamp: May 01, 2014, 07:22:47 am
content: Quote from: Everett_Tom on May 01, 2014, 04:58:33 amIs there a way to fix COM port for each converter? since i'm having trouble setting correct COM port each time plug it to different USB port..

author: han
author_rank: Frequent Contributor
timestamp: May 01, 2014, 07:26:57 am
content: Hmm,..I'm have interest in CAN bus, but after finding USB to CAN converter, it's still use virtual UART(RS-232)

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 01, 2014, 11:09:15 am
content: Simple UARTs aren't going anywhere... industry will probably be using RS-485 for the next century. RS-422 is less common I think, but none the less important for industrial controls.RS-232 is relatively uncommon due to its poor distance and noise immunity. It was more common for simple commercial uses (like serial between PCs and peripherals) but has been largely displaced by USB due to sheer popularity.USB isn't as popular for industrial purposes, since it's a high level bus, and if you're going to go to that trouble, you might as well put it on Ethernet, which is quite popular.I'm not as familiar with all the Mod/Profi/Field/CAN/etc. buses but they are certainly in use as well, for much the same reasons as the others.They're all differential (422/485) style links and buses, because they're easy to wire, offer useful bandwidth, and are robust to noise. Most are either isolated directly (Ethernet, others?), or isolated transceivers are easy to find/make. USB isn't easy to wire (shielded cable, special connector) or isolate (high data rate, DC coupled), and if you're going to go to that trouble, you might as well go all out (Ethernet -- 8 wires, but the connectors are easy enough to crimp).Tim

author: digsys
author_rank: Unknown
timestamp: May 01, 2014, 12:21:52 pm
content: I still use a heck of a lot of RS232 - but before I start, we need to clear things up. SCI, is the Asynchronous comms protocol.It can be "delivered" on several hardware layers, RS232, RS485, RS422, Fiber (which is 98% of what I use), 4-20mA etc etcThere are NO restrictions over what hardware layer you can use. SAME applies to SPI, I2R, CAN, USB etc etcWhen I use one of the other protocols, again nearly always on a Fiber transport.SCIs advantage over SPI is that no sync clock is necessary, so it is very simple / easy interface. No masters, no slaves .. nuttin.On newer W7/W8 machines, where there is no UART port, and the USB <> UART converters don't work, I have several differentcardbus / expressbus / pcmcia adapters that have "true" 16550 ICs / drivers, not an emulation or extended IRQ / IO driver.MOST mother boards still have at least one chipset (usually mixed IO) with a "real" UART, but often no breakout connectors.In the past, I've just made up a breakout adapter, if I couldn't find one on ebay etc Forgot the popular chipset, I think it was Sunix.As far as CAN, to me it's a totally complicated / very inefficient / over-designed protocol that was fine for what it was intended for,in vehicles, but more and more people are porting it to the Instrumentation / industrial realm, where it's a PITA, IMO.I often have to make adapters to "provide" CAN compatibility, but always do the "real" work on UART.RS232 is not dead. "Should" read UART is not dead. After all, you can easily run CAN on an RS232 hardware layer IF you wanted to.Confused? :-)

author: Kjelt
author_rank: Super Contributor
timestamp: May 01, 2014, 12:40:29 pm
content: In my opinion it will probably in some years become ethernet and probably CoAP over UDP (IPv6) for resource restraint devices.At this moment it is still quite expensive in usage (Rx/Tx buffers and IP stack will cost 64K ROM and :40K RAM) and the Phy, transformers RJ45 jack will put you out for at least another $0,40 a piece but in years when uC's will become cheaper and standard be packed with goodies it will probably be all a hardware peripheral with a standard uC firm delivered stack with some configurability. The advantage is that you can use this peripheral for multiple applications at the same time and have multiple seperated data streams (different debug output ports for instance).

author: SeanB
author_rank: Super Contributor
timestamp: May 01, 2014, 12:55:39 pm
content: Even if the MCU had the capability to run Ethernet, you will still find applications where the smaller, lower cost chip, with less RAM, ROM and a simple serial pinout will do the job just as well. You can use a 3GHz i7 with 1G of Ram and 1G of ROM to blink a LED, but most of the time it will be classed as somewhat overkill.

author: Kjelt
author_rank: Super Contributor
timestamp: May 01, 2014, 05:34:21 pm
content: That was and is not the topic, the topic was the successor of RS232.

author: IanB
author_rank: Super Contributor
timestamp: May 01, 2014, 06:20:19 pm
content: Why do you need a successor?All a "successor" will do is break standards, break inter-operability, break backwards compatibility, increase complexity, and so on.In short, it would not have any purpose.There is a common saying, "If it ain't broke, don't fix it."It applies here as much as anywhere.

author: Richard Crowley
author_rank: Super Contributor
timestamp: May 01, 2014, 06:58:21 pm
content: The basic question is flawed and does not recognize the modern environment. It assumes a single "successor" which is just not realistic.There are so many more specialized interface situations than back in the mid 20th century. And that many more interface options to chose from.Indeed, some of the modern "successors" still use the same async encoding scheme, although maybe not the original voltage levels, speeds, etc.

author: retrolefty
author_rank: Super Contributor
timestamp: May 01, 2014, 07:44:29 pm
content: Let me respond by asking if there are any state of the art microcontrollers that don't still offer built in hardware UARTs.The voltage logic levels being implemented (serial TTL Vs true RS-232) is not the question to ask, but rather will the classic asynchronous (start bit, stop bit, configurable data bit lengths, optional parity bit, configurable baud rate, etc) ever not to a utilized communications option? I say it will never go away.

author: electr_peter
author_rank: Unknown
timestamp: May 01, 2014, 08:04:33 pm
content: Why would you want a new protocol?Current protocols seem to suit various applications very well (especially when protocols are implemented in hardware or simple SW packages). Pick one that suit your needs best - that what is engineering if for.New protocol (lowish speed) would be a nightmare with very high probability: no devices can communicate to it, no HW compatibility, no proven long term reliability in industrial systems. What gain newer protocol could bring?Such question is like asking why personal transportation vehicles are still around (e. g. cars). Cars has been with us for >100 years, we are so "modern" and "clever", but still use these "ancient" vehicles (hybrids and EVs are included, they are not new). Let me ask you, what is the "modern" alternative?

author: David Hess
author_rank: Super Contributor
timestamp: May 02, 2014, 12:06:30 am
content: The best replacement for RS-232 is another asynchronous serial port and preferably a galvanically isolated one.1. USB is very difficult to galvanically isolate and has atrocious latency compared to RS-232.2. Ethernet is better but even more complex and still has atrocious latency. At least it is isolated.

author: han
author_rank: Frequent Contributor
timestamp: May 02, 2014, 08:19:26 am
content: Quote from: electr_peter on May 01, 2014, 08:04:33 pmYou right..My question came after my friend say.. "so you still use serial". he say he only use Ethernet and WFI for his project..I just feel kind of old school, but hey. Using Ehernet/Wifi for just couple kb/s communication is indeed overkill

author: TerraHertz
author_rank: Super Contributor
timestamp: May 02, 2014, 08:43:03 am
content: Quote from: David Hess on May 02, 2014, 12:06:30 amIt's interesting that there isn't yet a popular replacement for nice simple old RS232. All the contenders seem to be over-complicated, dependent on custom silicon (as opposed to say, a smallish VHDL chunk), and have one drawback or another. USB - point to point only, latency, not peer to peer, complexity...Ethernet - complexity, stupid connectors, either point to point (multiple twisted pairs) or multidrop (coax, but low bandwidth), power transmission is a klunky add-on (for which the connectors are crap), Firewire (sorry, who?), optical fiber (can't do multidrop), etc.A better question the OP could have asked, would be "What features would you hope to see, in a future general purpose interconnection bus standard?"I'll second galvanically isolated. Also few others:- Both point to point and multidrop configurations.- Two wire only, with both power and data on the same pair (DC power and HF carrier?)- A peer to peer protocol.- Protocol providing for negotiated allocation of persisting time slots to processes that need continual bandwidth and low latency.- Simple, solid, reliable connectors, that have both locking and non-locking forms.It's interesting to see the way it's done in avionics. Planes use 2-wire multi-drop buses, with transformer coupling at all nodes. Some references:goog: flight control bus magnetic coupling connectorhttp://www.davi.ws/index.php?link=avionics&link2=http://www.davi.ws/avionics/TheAvionicsHandbook_Cap_11.pdfBoeing B-777 Fly by wire flight controlshttp://www.axon-cable.com/publications/bus1553-products.pdfhttp://microsat.sm.bmstu.ru/e-library/military%20standatds/MIL-STD-1553Tut.pdf

author: han
author_rank: Frequent Contributor
timestamp: May 02, 2014, 08:58:04 am
content: Quote from: TerraHertz on May 02, 2014, 08:43:03 amYes, that the best sentenceSo we discuss it another thread or continuous this one?

author: T3sl4co1l
author_rank: Super Contributor
timestamp: May 02, 2014, 10:06:55 am
content: I was thinking of designing an LED light circuit with a controller and a couple power LEDs; the catch is, 24V two wire system, including communication.Isolated power would be difficult to implement, but common DC with an HF carrier or something like that would be pretty robust. What'll be interesting is how sensitive the HF end can be, in the presence of switching noise both local and remote.Tim

author: digsys
author_rank: Unknown
timestamp: May 02, 2014, 10:52:58 am
content: Quote from: T3sl4co1lJust use/hack a power line modem IC. Those suckers are used to tremendous noise/RFI.

author: David Hess
author_rank: Super Contributor
timestamp: May 02, 2014, 11:37:11 am
content: Quote from: TerraHertz on May 02, 2014, 08:43:03 amGalvanic isolation may be optional but it needs to be easy. USB fails this test miserably. I occasionally duplicate the old MIDI standard which is essentially RS-232 with optical isolation at both ends. It adds to the wire count though (from 3 to 4 for bidirectional communications) but maybe that is acceptable. A 5 wire variation is possible which essentially duplicates full duplex RS-422 while allowing optional but easy optical isolation (with 4 wires) and the differential pairs may be reversed without affecting operation (differential coding) so there is just a transmit pair and a receive pair and + and - within each pair may be swapped.RS-485 and CAN show how multidrop can be accomplished but I think this conflicts with easy galvanic isolation.I think power if included needs to be separate from the data because it adds too much complexity and makes galvanic isolation difficult when POE, USB, and Firewire already handle this case.You reminded me of SATA connections. What idiot thought a non-captive design was appropriate for something that is never exposed anyway?

author: tszaboo
author_rank: Super Contributor
timestamp: May 02, 2014, 12:05:50 pm
content: I think we can return to this issue when we reach the communication speeds which prohibits the usage of CMOS on standard microcontrollers. Until that this is not an issue.I believe if we need a future interface, it needs to be a differential, 8b/10b interface, with separate TX/RX lines, no clock. It can be capacitive or transformer coupled, and it doesn't have a ground. The interface needs to be small footprint, robust, with optional power pins. SATA is actually really close to it. And we need to keep the software people away from it, meaning that only low level protocols must exist.But for that, we need more capable microcontrollers. On the data converter field, JESD204 is already gaining popularity.

author: han
author_rank: Frequent Contributor
timestamp: May 02, 2014, 12:15:44 pm
content: Is there any one implement differential UART?for new protocol feature wanted:1. Isolated connection easy to implement2. Easy PC interfacing3. Simple protocol4. Can be configure as P to P or multidrop5. Can be configure as HS or Long reach6. Open source?

author: tszaboo
author_rank: Super Contributor
timestamp: May 02, 2014, 12:19:22 pm
content: Quote from: han on May 02, 2014, 12:15:44 pmIt is called RS-422, RS-485 if it is multidrop. Very capable interface.I dont see a reason why an interface needs to be open-source or vendor independent. I'm happy to pay royality fees, if it is built into the IC's price, and it is reasonable.

author: han
author_rank: Frequent Contributor
timestamp: May 02, 2014, 12:33:38 pm
content: Quote from: NANDBlog on May 02, 2014, 12:19:22 pmI missed that one, RS-485 , i missremember RS-485 and modbus things..

author: madshaman
author_rank: Frequent Contributor
timestamp: May 02, 2014, 01:14:29 pm
content: Quote from: NANDBlog on May 02, 2014, 12:05:50 pmSomething similar to DDR/2/3 SDRAM you mean?

author: David Hess
author_rank: Super Contributor
timestamp: May 02, 2014, 01:27:39 pm
content: Quote from: han on May 02, 2014, 12:15:44 pmDifferential signalling happens outside of the UART and is part of the line driver or receiver. RS-422 is essentially the differential version of RS-232 and they use the same UARTs.Differential coding happens inside the UART and it allows signal inversion so it does not matter which direction the differential pair is wired.

author: NiHaoMike
author_rank: Super Contributor
timestamp: May 02, 2014, 02:14:52 pm
content: What I would like to see is a USB to UART adapter that supports 9 bit mode, which is supported by many microcontrollers.

author: TerraHertz
author_rank: Super Contributor
timestamp: May 02, 2014, 02:50:05 pm
content: Quote from: NiHaoMike on May 02, 2014, 02:14:52 pmI'm curious why you'd want that? If for error detection and correction, what's wrong with CRCs and stuff on packet formats?It doesn't seem reasonable to want to do error detection and resends on individual characters.Or did you just want 512 numeric range instead of 256?

author: retrolefty
author_rank: Super Contributor
timestamp: May 02, 2014, 03:37:17 pm
content: Does the USB serial converter even care what the ninth bit represents if utilized by the two end node UARTS?One can of course configure the uC UART to send a ninth bit that commonly represents a parity bit, but the USB converter doesn't know that it represents parity, It's just a variable value 9th bit, only the PC com port configuration determines what the 9th bit represents if configured. The USB would seem to be transparent to that and just passes on the serial bit stream in both directions?So i would state on first consideration that a USB based serial converter chip doesn't prevent the usage of a 9th data bit, but I could of course be wrong. If there is a restriction of using a 9th data bit i would think it's with the PC com port driver software, not the USB serial converter.Brings to mind the rarely used but RS-232 standards defined function of being allowed to send a 'break condition', of those old enough to remember RS-232 links that utilized at 'break detection ', do you think it can be actually utilized in modern PCs, I suspect it probably can by the various error codes a PC COM port driver can report.

author: ajb
author_rank: Super Contributor
timestamp: May 02, 2014, 03:45:33 pm
content: Quote from: TerraHertz on May 02, 2014, 02:50:05 pmIt can be handy for multidrop systems to indicate address or data bytes. AVRs even have a UART mode where they ignore everything that comes in and only generate an interrupt when an address byte (indicated by bit 9) is received. Even without hardware support, though, having that extra bit can substantially reduce processor overhead.I wasn't aware that USB to UART bridges were limited in that respect, that seems problematic.

author: NiHaoMike
author_rank: Super Contributor
timestamp: May 02, 2014, 04:20:29 pm
content: Quote from: TerraHertz on May 02, 2014, 02:50:05 pmOut of band sync and control frames. When sending binary data on an 8 bit UART link, you'll have to reserve some values for sync and control purposes (in band signaling) and then escape data bytes that happen to fall into the conflicting values.Of which, out of band hardware flow control without having to add additional wires would be very useful at very high baud rates.

author: TerraHertz
author_rank: Super Contributor
timestamp: May 03, 2014, 06:03:24 am
content: Oh I see. Using a 9th bit to provide out of band signalling, that doesn't exist by other means because of trying to use just a simple UART and NRZ bit transmission on the physical layer.But I think, any scheme that can provide decent bandwidth, range and electrical isolation, won't be using NRZ or any such simple bit coding, and won't be using simple UARTs. It will be using a packet format, and a bit encoding scheme that provides intrinsic flagging of packet heads, etc. And that implies some kind of PHY chip, with more versatile software control and sensing of the line state.Now you've reminded me, I do recall systems that used that scheme of 9th bit for address flag, etc.The trouble with such schemes is the poor error recovery. One bad bit on the line, and the software can think it's received an address byte, or vice versa.TCP may be complicated, but at least it provides reliable operation even with flaky links. And bear in mind that the higher the data rate, the higher the bit error rate. It's unrealistic to expect any link to never have any errors.It would be interesting to see how simple a protocol could be, and still provide guaranteed reliable transport.

author: Marco
author_rank: Super Contributor
timestamp: May 03, 2014, 11:34:57 am
content: If M-LVDS had a standardized protocol 10 years ago it might have become a true successor ... I think it's too late now though, I think we'll just keep muddling along without any clearly dominating standard until we all go optical.