RS232 or USB to RS485

RS-232, RS-485 and RS-422 are not protcol definitions. Something like HDLC and Ethernet are protocols. If you add the 10base-T and 10base-2 to ethernet you get physical/electrical definition as well.

Regards Anton Erasmus

Reply to
Anton Erasmus
Loading thread data ...

have a look at:

formatting link
this may suit you.

--
Don McKenzie
E-Mail Contact Page:      http://www.e-dotcom.com/ecp.php?un=Dontronics
 Click to see the full signature
Reply to
Don McKenzie

Hi,

Johnny a écrit:

Yes!

have a look at our web site.

It's about almost 20 years ago that we are selling EIA232/EIA485 with microcontroler system to be RTS-Free !!!

--
Best regards.
Thierry Dubosse : be@.invalid.equiptrans.com
 Click to see the full signature
Reply to
Dubosse Thierry

David,

Is there any special setup for the UART hardware required to make this work?

As Paul K wrote below: " the 16550 family UARTs (as usually used in PC:s) are more or less useless for controlling the RTS/DTR".

Actaully I have never done any windows programming, but the windows programmer working on my project dosen't know anything about hardware, so I would like to design out these hardware problems if they are going to be an issue.

regards, Johnny.

Reply to
Johnny

It's not that simple, you can't do full-duplex on RS485. Nor can that simple circuit do multi-drop which requires s/w protocols to actively switch to/from tx/rx. Even in the simple version you need a timer to switch from tx>rx or vice-versa. RS485 is a single twisted pair that must be shared by both Transmit and Receive.

Are you thinking of RS422?

-- Regards, Albert

---------------------------------------------------------------------- AM Research, Inc. The Embedded Systems Experts

formatting link
916.780.7623

----------------------------------------------------------------------

Reply to
Albert Lee Mitchell

inconsistent.

far

thread,

and

supports

in

there

RS-485

to

I don't actually know how it is implemented by windows - but nothing more is needed that setting the right flags in the Windows API call to setup the comms port. There are various ways it could be implemented, such as waiting a character time after the final interrupt to give the last character a chance to get out, or sending an extra dummy character into the queue and switching off RTS before it gets sent.

Reply to
David Brown

At least in some old modem system (for which RS-232 was originally designed), the DTE (computer) raises the RTS signal to advertise that it has something to send. The DCE (modem) returns sooner or later this request by rising the CTS, which then enables the UART Tx shift register. Once enabled, the whole character is transmitted regardless of the CTS state.

Once the last character has started to be transmitted, there is no need to request for permission for more characters and the RTS can be dropped at any convenient time, even during the transmission of the last character.

This is quite sufficient for RTS/CTS handshaking, but not very usable for controlling the RS-485 transmitter, since the transmitter could be disabled too early, cutting out the last bits. My guess is (without checking with an oscilloscope) that the Windows driver simply drops the DTR when the last character has been transferred from the Tx register to the Tx shift register, which on

16550 style chips can generate an interrupt. I very much doubt that the driver would run in a busy loop constantly checking the UART status register to find out, when the last stop bit has actually been sent. Such busy looping might be acceptable in MS-DOS type single thread systems but not in multitasking operating systems.

Paul

Reply to
Paul Keinanen

[...]

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.

Sure, it sucks, but that's how you have to do it when you've got a crippled UART.

--
Grant Edwards                   grante             Yow!  Now, let's SEND OUT
                                  at               for QUICHE!!
 Click to see the full signature
Reply to
Grant Edwards

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

Does a standard Windows (without enabling multimedia timers) really have timer interrupts every millisecond. At least NT seems to have a timer interrupt every 10 ms (or every 15,625 ms with multiprocessor kernels), so the time between the checks could be this long, corresponding to more than 100 character times at 115k2.

There are at least two reliably ways to connect a Windows PC to the RS-485 bus:

1) using a dedicated PCI/ISA/PC-104 RS-485 card with a proper UART. 2) using an external RS-232/485 converter that correctly detects start and stop bits in the transmitted data line.

A less reliable method which works surprisingly well on short distances is to run it in a similar way as the CAN bus was originally used with RS-485 drivers before dedicated CAN drivers were available.

Only a jumper wire is required between the RS-232 Tx pin and the RS-485 transmit enable. When the RS-232 is in idle state, it transmits Mark ("1") and the RS-485 transmitter is off. When "0" Space is transmitted, the RS-485 transmitter is also enabled driving the 485 line actively to the "0" ("dominant") state. When a "1" (Mark) bit is transmitted, the 485 transmitter is switched off and the termination resistors pull the line to the "1" ("recessive") state. This works quite well for short lines (a few meters) at moderate speeds. Paul

Reply to
Paul Keinanen

At high baud rates, it's no substitute for a UART that knows how to control RTS in hardware.

That's what the Windows driver guys I know told me.

I thought the 1ms interrupt happened on NT as well, but I'm a Unix guy...

--
Grant Edwards                   grante             Yow!  ... I think I'm
                                  at               having an overnight
 Click to see the full signature
Reply to
Grant Edwards

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.
Reply to
Hans-Bernhard Broeker

See:

formatting link
formatting link
formatting link
formatting link

formatting link
--> Converters --> Interface Converters --> RS-485 Converters

Or roll your own ...

Roberto Waltman

Reply to
Roberto Waltman

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.

No, it isn't.

--
Grant Edwards                   grante             Yow!  I feel like a wet
                                  at               parking meter on Darvon!
 Click to see the full signature
Reply to
Grant Edwards

Grant Edwards wrote: [...]

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.

_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.
Reply to
Hans-Bernhard Broeker

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.

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

Right.

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.

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

The RS-232 standard that says what RTS and CTS are for.

IIRC, the RS-485 standard doesn't really address how the line driver is controlled via a UART.

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.

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.

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!
 Click to see the full signature
Reply to
Grant Edwards

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.