RS232 or USB to RS485

On 11 Feb 2004 14:34:00 GMT, Hans-Bernhard Broeker
<broeker@physik.rwth-aachen.de> wrote:

>Grant Edwards <grante@visi.com> wrote:
>> On 2004-02-11, Meindert Sprang <mhsprang@NOcustomSPAMware.nl> wrote:
>
>> > Lately I see people here talking about 2-wire and 4-wire
>> > RS485. Isn't RS-485 *always* 2 wire?
>
>> No.  If you use separate RS485 driver/receiver chips and two
>> pairs, then it's four wire.
>
>I don't agree this would mean "it" (RS485) is 4-wire, then.  
>
>It's really two independent RS485 links, using 2 wires each.  The fact
>you're not using full-fledged transceiver chips on your nodes is not a
>feature of the RS485 line protocol as such --- it's a detail of the
>particular application.
>
>You wouldn't call a bundle of ten classical coaxial Ethernet cables
>used to connect ten machines to ten other ones a "10-coax Ethernet"
>connection either, would you?

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

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.

have a look at:
http://www.dontronics.com/usb_485.html
this may suit you.


-- 
Don McKenzie
E-Mail Contact Page:      http://www.e-dotcom.com/ecp.php?un=Dontronics

USB to RS232 Converter that works http://www.dontronics.com/usb_232.html
Don's Free Guide To Spam Reduction  http://www.e-dotcom.com/spam_exp.php

Hi,

Johnny a �crit:

> 
> I think the only way to make a useful RS-232 to RS-485 adapter for
> windows is to use a hardware one-shot triggered by the start bit to
> control Transmit enable on RS-485 driver.  Please let me know if I am
> wrong.

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
http://www.equiptrans.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.

On Wed, 11 Feb 2004 07:13:55 +0000, Tauno Voipio wrote:

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

	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
http://www.amresearch.com          			  916.780.7623
----------------------------------------------------------------------

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

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
        

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            

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
 

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