Reply by Grant Edwards●February 13, 20042004-02-13
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
Reply by Hans-Bernhard Broeker●February 13, 20042004-02-13
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.
Reply by Grant Edwards●February 13, 20042004-02-13
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
Reply by Roberto Waltman●February 13, 20042004-02-13
"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.
Reply by Hans-Bernhard Broeker●February 13, 20042004-02-13
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.
Reply by Grant Edwards●February 12, 20042004-02-12
On 2004-02-12, Paul Keinanen <keinanen@sci.fi> 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 :-).
At high baud rates, it's no substitute for a UART that knows
how to control RTS in hardware.
> Does a standard Windows (without enabling multimedia timers)
> really have timer interrupts every millisecond.
That's what the Windows driver guys I know told me.
> 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.
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
visi.com sensation right now!!
Reply by Paul Keinanen●February 12, 20042004-02-12
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 :-).
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 by Grant Edwards●February 12, 20042004-02-12
On 2004-02-12, Paul Keinanen <keinanen@sci.fi> wrote:
>>Doesn't the "standard" windows serial port driver have an
>>RTS-toggle feature? I know the Windows serial drivers we did
>>at a previous employer did.
> 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.
[...]
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!!
visi.com
Reply by Paul Keinanen●February 12, 20042004-02-12
On 11 Feb 2004 14:41:26 GMT, Grant Edwards <grante@visi.com> wrote:
>Doesn't the "standard" windows serial port driver have an
>RTS-toggle feature? I know the Windows serial drivers we did
>at a previous employer did.
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 by David Brown●February 12, 20042004-02-12
"Johnny" <john_wr@NOSPAM.hotmail.com.> wrote in message
news:u2fm2058lf9h6a4endsblgnjtn34kg8c23@4ax.com...
> On Wed, 11 Feb 2004 09:25:08 +0100, "David Brown"
> <david@no.westcontrol.spam.com> wrote:
>
> >
> >"Johnny" <john_wr@NOSPAM.hotmail.com.> wrote in message
> >news:2mnj20hpmai46rg41j1d9ujentjpif0nur@4ax.com...
> >> On Wed, 11 Feb 2004 07:13:55 GMT, Tauno Voipio
> >> <tauno.voipio@iki.fi.NOSPAM.invalid> wrote:
> >>
> >> >RS-232 to RS-485 needs two simple chips back-to-back:
> >> >RS-232 to logic (e.g. MAX232) and logic to RS-485
> >> >(e.g. MAX485). The real problem comes from the control
> >> >of the RS-485 transmitter enable, if your interpretation
> >> >of two-wire RS-485 involves traffic in both directions
> >> >(which is 4-wire with transmit and receive bus lines
> >> >connected in parallel).
> >> >
> >> >There are simple boxes which contain the chips and
> >> >usually a simple power supply (e.g. a plug transformer,
> >> >'wall wart'). Usually, they are four-wire, but the
> >> >common bus two-wire is achieved by connecting the
> >> >RS-485 bus sides in parallel. The boxes often control
> >> >the transmit enable with the RS-232 RTS (request to
> >> >send) signal.
> >>
> >>
> >> I have found that the converters using RTS to enable are not very
> >> useful to me. It is not possible to use them with Hyperterminal in
> >> windows because when hardware handshaking is turned on, RTS is
> >> permenantly asserted, so bi-directional transfer is impossible.
> >>
> >
> >Personally, I have found Hyperterminal a real PITA, and highly
inconsistent.
> >There are a hundred and one free terminal programs for windows that are
far
> >better (and as many again commercial ones). At the risk of starting yet
> >another "my terminal program is better than your terminal program"
thread,
> >I'd recommend "Tera Term Pro" for most serial work (because it is small,
> >fast, neat, and does what enough for most jobs without doing too much)
and
> >"RealTerm" for more complex work (because it is big, powerful, with more
> >options than I could imagine needing). In particular, "RealTerm"
supports
> >RTS control of RS-485 lines as you want here.
> >
> >> It is also not possible to use them with windows application, because
> >> it is impossible to know when to reset the RTS line, because the
> >> application has no way to know exacltly when all data has been
> >> transmitted out the serial port.
> >>
> >
> >It is perfectly possible to do exactly that - when setting the DCB flags
in
> >a SetCommState api call, you can choose to have the RTS line permanently
> >high, or low, or hardware handshaking, or to have it active whenever
there
> >is something being sent out and deactivated when there is nothing being
> >transmitted. It is simply a matter of choosing that flag, and your
RS-485
> >communication should work perfectly. I haven't done any measurements as
to
> >the exact timings on the line, but I have found it far more reliable than
> >using so-called "intelligent" RS-485 adaptors.
>
>
>
> 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.
>
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.