EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

RS232 or USB to RS485

Started by QBA February 11, 2004
Paul Keinanen <keinanen@sci.fi> wrote:
> On 12 Feb 2004 15:35:24 GMT, Grant Edwards <grante@visi.com> wrote:
> >That's what I've been told the Windows serial driver does: It > >checks the shfit-register empty status bit every millisecond > >until true, then drops RTS.
> If that is really true, then this is a nice feature if you are > operating at 1200 bit/s or below, in which case you are probing every > bit, but at 115k2, one milliseconds is more than 11 character times > and in the worst case the master (PC) transmitter is on, while the > slave is already sending the 11th byte of the response :-).
Well, that's what you get for trying to force a piece of hardware designed for one line discipline (like the 16550 is for RS232), driven by a system that isn't anywhere near usable as an RTOS, to talk an inherently incompatible language at its full native speed. That's a bit like handing a blacksmith a sledgehammer and expecting him to make you a wedding ring. If you're building an embedded system you can patch up the defects with some additional circuitry and sufficiently responsive pieces of software --- but that would invalidate the whole reason for putting a 16550 instead of a dumber kind of UART on the board: the luxury *not* to have to do all the nitty-gritty bit-fiddling of control lines in software, and *not* to have to reliably handle any interrupt request within on byte-time of the serial link. So, in a nutshell: yes, some UARTs can drive both RS232 and RS485, either by design or with a bit of glue logic in hardware and software. But no, your typical 16550 (or work-alike core) found in a PC running Windows is *not* in that category. -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
"QBA"  wrote:

>I need RS232 to RS485 converter or USB to RS485 converter, are there vendors >out there you recommend for these converters? More specifically, RS485 I am >using is 2-wire (ground, don't need 4-wire version) at 19200 baudrate.
See: http://www.antona.com/dta6090.htm http://www.antona.com/dta6091.htm http://www.antona.com/dta6185.htm http://www.robustdc.com/?model=rdc485ic#rdc485ic http://catalog.blackbox.com/BlackBox/Templates/blackbox/mainscreen.asp --> Converters --> Interface Converters --> RS-485 Converters Or roll your own ... Roberto Waltman
On 2004-02-13, Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote:
> Paul Keinanen <keinanen@sci.fi> wrote: >> On 12 Feb 2004 15:35:24 GMT, Grant Edwards <grante@visi.com> wrote: > >> >That's what I've been told the Windows serial driver does: It >> >checks the shfit-register empty status bit every millisecond >> >until true, then drops RTS. > >> If that is really true, then this is a nice feature if you are >> operating at 1200 bit/s or below, in which case you are probing every >> bit, but at 115k2, one milliseconds is more than 11 character times >> and in the worst case the master (PC) transmitter is on, while the >> slave is already sending the 11th byte of the response :-). > > Well, that's what you get for trying to force a piece of hardware > designed for one line discipline (like the 16550 is for RS232), driven > by a system that isn't anywhere near usable as an RTOS, to talk an > inherently incompatible language at its full native speed.
Huh? There's nothing incompatible about the RS-232 definition of the RTS line. RS-232 was designed to handle half-duplex communications (whether that be via an RS-485 converter or a Bell-202 modem). It's just that the designers of the 16550 decided not to impliment the standard.
> That's a bit like handing a blacksmith a sledgehammer and > expecting him to make you a wedding ring.
No, it isn't. -- Grant Edwards grante Yow! I feel like a wet at parking meter on Darvon! visi.com
Grant Edwards <grante@visi.com> wrote:
[...]

> Huh? There's nothing incompatible about the RS-232 definition > of the RTS line. RS-232 was designed to handle half-duplex > communications (whether that be via an RS-485 converter or a > Bell-202 modem).
Huh? One of us must be utterly confused here. So I'll lay out my position in more detail, and you can quote me some documents that say why this is wrong. Of the RS-something protocols discussed in this thread, RS232 is actually the single one that is *not* "designed for half-duplex". A RS232 link is full-duplex by definition --- you can build a unidirectional one by omitting some of the connections, but that's a side issue. The point is can't ever be half-duplex at the physical layer, since data flow direction on each physical wire is fixed. Note: a full-duplex line doesn't become half-duplex just because one of the nodes decides not use its Tx while the other one is talking on theirs. It's RS485 which is half-duplex, and that's actually the root of all this. To implement a full-duplex connection with RS485, you use *two* RS485 links, at two wires each, giving rise to that terminologically silly idea of a "4-wire RS485" link. AFAIK, RS232 standard doesn't offer half-duplex at all, not even as an optional feature. It doesn't have nor need any method of turning off its line driver to enable someone else to talk on the same physical wire, because it sports a separate physical wire for the reverse direction.
> It's just that the designers of the 16550 decided not to impliment > the standard.
_Which_ standard? The facts presented here so far seem to suggest rather strongly that the behaviour of the 16550 regarding interrupt generation vs. line discipline doesn't implement the RS485 standard. But that's okay, because this is not a chip designed for RS485 in the first place. OTOH, there seems to be agreement that it does implement RS232 quite correctly, including semi-automatic handling of RTS through the "last transmission started" IRQ. Which was obviously the key design goal of that chip. It would be possible to make a UART chip that supports both RS232 and RS485 in a single chipe. But that's not the chip you find in a PC. -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
On 2004-02-13, Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de> wrote:
> Grant Edwards <grante@visi.com> wrote: > [...] > >> Huh? There's nothing incompatible about the RS-232 definition >> of the RTS line. RS-232 was designed to handle half-duplex >> communications (whether that be via an RS-485 converter or a >> Bell-202 modem). > > Huh? One of us must be utterly confused here. So I'll lay out my > position in more detail, and you can quote me some documents that > say why this is wrong. > > Of the RS-something protocols discussed in this thread, RS232 is > actually the single one that is *not* "designed for half-duplex".
The RTS/CTS signals lines defined by RS-232 are intended to support half duplex communictions. RTS is used by the DTE to control the direction of the link, and CTS is used by the DCE to indicate the direction of the link.
> A RS232 link is full-duplex by definition --- you can build a > unidirectional one by omitting some of the connections, but > that's a side issue.
There are separate tx and rx data lines, yes. But the modem (remember, RS-232 was defined to connect a "terminal" to a "modem") was often half-duplex, and RS-232 defined signals (RTS/CTS) to support half-duplex operation.
> The point is can't ever be half-duplex at the physical layer, > since data flow direction on each physical wire is fixed. > Note: a full-duplex line doesn't become half-duplex just > because one of the nodes decides not use its Tx while the > other one is talking on theirs.
The link is logically half-duplex if only one side can transmit at a time. The fact that two different wires are used at one point in the link is pretty much irrelevent.
> It's RS485 which is half-duplex, and that's actually the root of all > this. To implement a full-duplex connection with RS485, you use *two* > RS485 links, at two wires each, giving rise to that terminologically > silly idea of a "4-wire RS485" link.
Right.
> AFAIK, RS232 standard doesn't offer half-duplex at all, not even as an > optional feature.
It offers half-duplex communictions using a half-duplex modem (or RS-485 converter if you want) with link direction controlled via the RTS/CTS pins.
> It doesn't have nor need any method of turning off > its line driver
The RTS line is used to control the link direction (turn the line driver on/off, turn the modem carrier on/off, turn the Laser on/off, whatever).
> to enable someone else to talk on the same physical > wire, because it sports a separate physical wire for the reverse > direction. > >> It's just that the designers of the 16550 decided not to impliment >> the standard. > > _Which_ standard?
The RS-232 standard that says what RTS and CTS are for.
> The facts presented here so far seem to suggest rather > strongly that the behaviour of the 16550 regarding interrupt > generation vs. line discipline doesn't implement the RS485 > standard.
IIRC, the RS-485 standard doesn't really address how the line driver is controlled via a UART.
> But that's okay, because this is not a chip designed > for RS485 in the first place.
Correct. It's not really designed for the RS-232 standard either, since it's usage of RTS and CTS is non-standard. It can use them for full-duplex flow control, but not for the original use intended by RS-232: control of a half-duplex link.
> OTOH, there seems to be agreement that it does implement RS232 > quite correctly,
No, there isn't agreement. RTS/CTS were defined by RS-232 for link direction control of half-duplex modems. An RS-232 <-> RS-485 converter with the RS-485 drivers controlled by RTS is equivalent to a half-duplex modem. The 16550 does not support that. It _does_ support use of RTS/CTS for full-duplex flow control: a hack that somebody came up with for using RTS/CTS in a direct-wired full-duplex link.
> including semi-automatic handling of RTS through the "last > transmission started" IRQ. Which was obviously the key design > goal of that chip. > > It would be possible to make a UART chip that supports both RS232 and > RS485 in a single chipe.
Yes. Presuming you mean by that that the UART supports both the original RS-232 RTS/CTS functionality (half-duplex link direction control) and the more recent RTS/CTS flow control hack. The 16850, for example supports both usages of RTS/CTS. -- Grant Edwards grante Yow! You were s'posed at to laugh! visi.com

The 2024 Embedded Online Conference