2 wire rs485

Vasilis wrote:
> 
... snip ...
> 
> i know that rts/cts handshake must be performed manually. could
> you please tell me what actions must be performed? the only thing
> i do now is to raise the request to send signal, send data, then
> lower it and wait for response.

Raise rts, await cts, send data, lower rts.  You never send data
without cts being asserted by the receiver.  Those acronyms stand
for request/clear to send.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

CBFalconer wrote:
> Vasilis wrote:
> >
> ... snip ...
> >
> > i know that rts/cts handshake must be performed manually. could
> > you please tell me what actions must be performed? the only thing
> > i do now is to raise the request to send signal, send data, then
> > lower it and wait for response.
>
> Raise rts, await cts, send data, lower rts.  You never send data
> without cts being asserted by the receiver.  Those acronyms stand
> for request/clear to send.

I thought this was an RS-485 interface.  That only has tri-state data
signals between the two devices.  The RTS signal is used to enable the
driver for transmission.  I'm sure you know about this.  I expect you
just didn't get the context.

Rick

On Feb 12, 1:39 am, rickman <gnu...@gmail.com> wrote:
> CBFalconer wrote:
> > Vasilis wrote:
>
> > ... snip ...
>
> > > i know that rts/cts handshake must be performed manually. could
> > > you please tell me what actions must be performed? the only thing
> > > i do now is to raise the request to send signal, send data, then
> > > lower it and wait for response.
>
> > Raise rts, await cts, send data, lower rts.  You never send data
> > without cts being asserted by the receiver.  Those acronyms stand
> > for request/clear to send.
>
> I thought this was an RS-485 interface.  That only has tri-state data
> signals between the two devices.  The RTS signal is used to enable the
> driver for transmission.  I'm sure you know about this.  I expect you
> just didn't get the context.
>
> Rick

I guess I should mention to the OP that although the RTS signal is
typically used to enable the driver onto the RS-485 bus, but this does
nothing to make sure no one else is driving onto the bus.  That has to
be done in the protocol.  It is also important to allow some bus turn
around time in the protocol.  It can be hard to control the timing of
the RTS signal to perfectly bracket the character or message being
transmitted.  The status signals from typical UARTs are not sufficient
to use to control the driver enable and extra time must be added.

A typical protocol has one unit as the master and one or more as
slaves on the bus.  The master queries the slaves who respond.  Before
they respond, they must wait for the master to release the bus.
Likewise when the slave sends its reply, the master has to wait for
the bus to be released before sending another message.

Rick

On Wed, 11 Feb 2009 22:01:32 -0500, CBFalconer <cbfalconer@yahoo.com>
wrote:

>Vasilis wrote:
>> 
>... snip ...
>> 
>> i know that rts/cts handshake must be performed manually. could
>> you please tell me what actions must be performed? the only thing
>> i do now is to raise the request to send signal, send data, then
>> lower it and wait for response.
>
>Raise rts, await cts, send data, lower rts.  You never send data
>without cts being asserted by the receiver.  Those acronyms stand
>for request/clear to send.

On an RS-485 bus side, who is going to generate the ClearToSend signal
for the RS-232 port input ??

The proper way is to raise the RTS, send the data and then wait until
the last (stop) bit of the last byte has _actually_ been shifted out
of the Tx _shift_ register. Then drop RTS and receive the response. 

On ordinary PC style 14550 series UARTS it is hard to detect when the
last stop bit has been transmitted, either poll the proper UART status
bit (no interrupt available) or use RS-232/485 chip that allows
monitoring your own transmission and from the local echo, detect when
the last byte of message has been  transmitted and echoed, before
dropping the RTS.

Paul
 

On Wed, 11 Feb 2009 22:46:34 -0800 (PST), rickman <gnuarm@gmail.com>
wrote:

>It is also important to allow some bus turn
>around time in the protocol.  It can be hard to control the timing of
>the RTS signal to perfectly bracket the character or message being
>transmitted.  The status signals from typical UARTs are not sufficient
>to use to control the driver enable and extra time must be added.

Very few protocols actually specify any extra line turn around times,
the notable exception is Modbus, which specifies a 3.5+1.5 character
(end of frame gap+reply preamble) separation between request and reply
(but the reply preamble is often omitted). Other protocols may reply
immediately as the response has been processed.

IMHO, for properly driving RS-485 lines from a multitasking OS, a
proper UART with HW generated RTS should be used. The standard PC
style 14550 family is mainly usable for driving RS-485 lines in single
tasking MS-DOS at below 9600 bit/s with software data direction
control with the RTS signal :-).

Paul
 

On Wed, 11 Feb 2009 22:46:34 -0800 (PST), rickman <gnuarm@gmail.com>
wrote:

>I guess I should mention to the OP that although the RTS signal is
>typically used to enable the driver onto the RS-485 bus, but this does
>nothing to make sure no one else is driving onto the bus.  That has to
>be done in the protocol.  It is also important to allow some bus turn
>around time in the protocol.  It can be hard to control the timing of
>the RTS signal to perfectly bracket the character or message being
>transmitted.  The status signals from typical UARTs are not sufficient
>to use to control the driver enable and extra time must be added.

An other method is to operate the RS-485 bus as a CAN bus i.e. with
dominant and recessive states, which does not require active data
direction control. 

The RS-232 TD pin on the RS-232/485 converter is permanently connected
to the "0" state and the TxEnable pin is connected to the UART TX pin
so that when "0" bit needs to be transmitted, the transceiver chip is
enabled and the bus is driven actively to the "0" dominant state. When
the "1" bit needs to be transmitted, the transmitter is disabled and
the "fail-safe" bus termination will pull the bus to the "1" idle
(recessive) state. This may have some implications for the noise
margin.

Paul
 

On Feb 11, 1:21=A0pm, "Steve at fivetrees" <st...@NOSPAMTAfivetrees.com>
wrote:
then I'm puzzled ;).
> To the OP: be distrustful of A/B marking, or indeed Rx/Tx+/- marking. RS-=
485
> *is* defined in terms of A and B (and ground), but unfortunately all the
> major RS-485 transceivers have them reversed for bad historical reasons, =
and
> designers often don't spot this and mark incorrectly. (The Rx/Tx+/- syste=
m
> is unofficial and in any case subject to misinterpretation.)
>
> You say it works with an RS-232/RS-485 converter: are you controlling the
> driver with e.g. RTS? (Seems so from another post.) In principle, an
> external converter is no different from an internal transceiver, except t=
hat
> *some* external converters offer "auto-gating" - i.e. they figure it out =
for
> themselves (usually needing some help in the form of knowing the baud rat=
e
> via e.g. some DIP switches). If it works with an external converter, I'd
> suggest this is A Clue. Tell us more about the converter and the cabling =
-
> and ideally also the grounding.

ok, i'll try to be as precise as possible, but bear in mind i am a sw
engineer, i don't have much of an electronics knowledge.

when i use the converter (which by the way is a JaRa 2102E(chinese)) i
do this:
- plug the converter to the serial port RS232
- screw one end of each of two wires into, respectively, a hole marked
d+/A and a
hole d-/B on the converter side
- screw the other end of the wires to the holes of the meter i
mentioned before.(A and B)

the total length of the cable is approx 60cm.

the software i wrote does this:
- set the port parameters as needed to communicate with the meter(1200
baud, even parity, 8 data bits, 1 stop bit)
- send 16 bytes(a packet of the meter communication protocol with a
request enclosed)
- receive 20 bytes (the response packet)

no rts cts lowering or raising. no ground wire, even though there is a
hole on the converter
end marked as GND.(as i mentioned before, the meter doesn't have one)

i googled for the converter model but i found no electrical scheme,
just a few
pages in chinese.

also, about waiting for the clear to send signal, well, it is never
sent by the meter.

thank you all,
vasilis.

On 2009-02-12, Paul Keinanen <keinanen@sci.fi> wrote:
> On Wed, 11 Feb 2009 22:01:32 -0500, CBFalconer <cbfalconer@yahoo.com>
> wrote:
>
>>Vasilis wrote:
>>> 
>>... snip ...
>>> 
>>> i know that rts/cts handshake must be performed manually. could
>>> you please tell me what actions must be performed? the only thing
>>> i do now is to raise the request to send signal, send data, then
>>> lower it and wait for response.
>>
>>Raise rts, await cts, send data, lower rts.  You never send data
>>without cts being asserted by the receiver.  Those acronyms stand
>>for request/clear to send.
>
> On an RS-485 bus side, who is going to generate the
> ClearToSend signal for the RS-232 port input ??

The line-driver hardware.  Sometimes it contains a delay timer,
sometimes it's just RTS looped back.

> The proper way is to raise the RTS, send the data and then wait until
> the last (stop) bit of the last byte has _actually_ been shifted out
> of the Tx _shift_ register. Then drop RTS and receive the response. 

One presumes that was what was meant by "send data, then lower
RTS".

> On ordinary PC style 14550 series UARTS it is hard to detect
> when the last stop bit has been transmitted, either poll the
> proper UART status bit

I've seen chipsets where that bit wasn't implimented correctly
and went active before the last stop bit was sent.

> (no interrupt available) or use RS-232/485 chip that allows
> monitoring your own transmission and from the local echo,
> detect when the last byte of message has been transmitted and
> echoed, before dropping the RTS.

On faulty hardware (which you have to assume is the case on a
PC) the local echo method is the only reliable way to do it.

-- 
Grant Edwards                   grante             Yow! Hello.  Just walk
                                  at               along and try NOT to think
                               visi.com            about your INTESTINES being
                                                   almost FORTY YARDS LONG!!

"Grant Edwards" <grante@visi.com> wrote in message 
news:J9CdnVS6Y-YV3AnUnZ2dnUVZ_h4AAAAA@posted.visi...
>
>> On ordinary PC style 14550 series UARTS it is hard to detect
>> when the last stop bit has been transmitted, either poll the
>> proper UART status bit
>
> I've seen chipsets where that bit wasn't implimented correctly
> and went active before the last stop bit was sent.

The "transmit buffer empty" flag just says the data has been loaded into the 
Tx shift register, and hence the transmit buffer is ready to receive more 
data. It doesn't tell you anything about the Tx shift register, which 
typically (unsurprisingly) takes one more frame time to send that last stop 
bit.

So: use the flag to start a timer for e.g. 1.5 chr times, *then* disabled 
the transmitter. Or, as Paul says, monitor your own transmissions (closely: 
doing so periodically is nowhere near good enough).

Steve
--
http://www.fivetrees.com 

"Scott Newell" <newell@cei.net> wrote in message 
news:49936BF6.2830@cei.net...
> Paul Keinanen wrote:
>>
>> So the signal ground connection is not necessary nor desirable in
>> systems with large ground potential differences.
>
> It looks to me like both the converters you referenced are
> isolated converters, with no common ground between the power
> supply and RS-485.  In that case, I can see that the RS-485
> ground wire may be optional.

Ah - but if they're isolated (which is actually very common and desirable), 
then the ground wire *is* useful - on each side of the isolation barrier, 
but not across it ;).

Steve
--
http://www.fivetrees.com