Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #30361

Re: Linux embedded and direction control of RS485 transceiver

Show all headers | View raw

On 24.3.21 17.49, upsidedown@downunder.com wrote:
> On Wed, 24 Mar 2021 06:17:46 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
> 
>> On 3/23/2021 10:28 PM, upsidedown@downunder.com wrote:
>>> On Wed, 24 Mar 2021 00:06:21 +0100, pozz <pozzugno@gmail.com> wrote:
>>>
>>>> I have an half-duplex RS485 bus with 10-20 different nodes. Some of them
>>>> are 8-bit MCU based, one of them could be Linux embedded.
>>>>
>>>> It's half-duplex, so it's important for the transmitter node to disable
>>>> the driver as soon as the last transmitted bit is shifted out.
>>>>
>>>> Many small low-cost MCU has interrupt on transmission complete, so the
>>>> delay of disabling the driver is usually on the order of microseconds.
>>>
>>> Look very carefully _when_ the interrupt occurs. Some UARTs generate
>>> an interrupt when the last character is moved from the FIFO into the
>>> shift register, some (also) generate an interrupt, when actually the
>>> (last) stop bit has completely shifted out from the shift register.
>>>
>>> If you turn off the Tx based of the FIFO to shift register interrupt,
>>> the Tx can be turned off, while the last character is actually being
>>> transmitted and the 'fail safe' termination will pull the line to "1"
>>> i.e. idle. The receiver often gets the last character as FF, FE,.. ,
>>> F0 etc. especially at low line speeds.
>>
>> As you likely have the line connected to the Rx input (to *receive*
>> replies), you can use the Rx IRQ to tell you when the character has
>> cleared the Tx shift register (and made it out onto the wire).
> 
> Yes, I have sometimes used this, but it requires that the Rx path is
> always active. Some RS-485 chips disable the Rx side when
> transmitting, so you do not hear your own transmission, thus no echo
> canceling is required in the software.
> 
> 
>> But, you also have to check the timing of that IRQ wrt the actual serial
>> data in.  Sometimes, the stop bits aren't checked.
>>
>> However, anomalies/faults on the line can prevent the Rx interrupt
>>from coinciding with the end of the Tx (e.g., if a voltage is effectively
>> impressed on the line).  The loopback will allow your code to detect that
>> transmissions are not happening as expected.  But, it will confuse the
>> timing of the disabling of the transceiver.
> 
> If he line is shorted or connected to Vcc, loosing timing is the
> smallest problem :-)  Even if the problem is at the remote end of the
> cable, the problem must be pretty severe, if you can't detect your own
> transmission on the PCB before entering the line.
> 
>>
>> A better solution is to route the Tx *pin* on the device to a spare
>> Rx pin (another UART) and use that for timing information as it
>> is entirely local to the board -- not impacted by faults on the
>> wire.
> 
> What is the point of doing loopbacK on TTL, if the RS-485 is bad ?
> 
>>
>>>> Some new Cortex-M MCUs have an automatic control of external RS485
>>>> transceiver, so the delay is really zero.
>>>
>>> This is the proper way of doing low latency half duplex. Otherwise,
>>> you have to add some extra delay, before the slave starts the
>>> response.
>>
>> That's often desirable to let the line "settle" (assuming the software
>> is incredibly responsive and the slave receiver was fortunate in how it
>> synchronized to the incoming datum).  In the real world, folks don't
>> always wire things the way they should (e.g., using crappy cable for
>> longer than intended runs -- "Wire is wire, right?"  :< )
> 
> In the Modbus RTU protocol specification it is required to turn on the
> transmitter (set to idle "1" state), wait 3.5 character times, then
> send the actual message, then keep the transmitter in active idle
> ("1") state for an other 3.5 character times, before turning off the
> transmitter, i.e. put the transmitter into tri-state.
> 
> When the transmitter is turned into rtri-state and there are 'fail
> safe' pull up/down resistors, the line remains in the idle "1" state
> until next transmitter takes over the bus. BTW, the quotes around
> 'fail safe' termination is in the actual standard text, at least in
> early versions.
> 
> If no passive pull up/down resistors are present on the bus, old
> signal reflections and external noise will cause some variable unknown
> noise voltages on the bus. However, when the next node turns the
> transmitter on for 3.5 character times in idle state, after it the
> first start bit of the first character is reliably detected.
> 
> In Modbus RTU, there is at least 3.5 character times idle period
> between actual data transmitter between two stations since it is
> perfectly legal for station A to have the trailing 3.5 trailing idle
> and station B sends 3.5 preamble on simultaneously. Actually there are
> 5 (1.5+3.5) character times to turn of the Tx transmitter, since the
> Rx uses a 1.5 character time idle period as end of frame marker.
> 
> In half duplex communication with short messages, the latencies
> between frames will reduce the throughput considerably. With long
> messages, the throughput loss is not significant.


The Modbus RTU is rotten - a protocol so badly designed that it
is difficult to exceed. Modbus on TCP is no better.

-- 

-TV

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Linux embedded and direction control of RS485 transceiver pozz <pozzugno@gmail.com> - 2021-03-24 00:06 +0100
  Re: Linux embedded and direction control of RS485 transceiver upsidedown@downunder.com - 2021-03-24 07:28 +0200
    Re: Linux embedded and direction control of RS485 transceiver Don Y <blockedofcourse@foo.invalid> - 2021-03-24 06:17 -0700
      Re: Linux embedded and direction control of RS485 transceiver upsidedown@downunder.com - 2021-03-24 17:49 +0200
        Re: Linux embedded and direction control of RS485 transceiver Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-03-24 18:32 +0200
          Re: Linux embedded and direction control of RS485 transceiver upsidedown@downunder.com - 2021-03-24 19:22 +0200
            Re: Linux embedded and direction control of RS485 transceiver David Brown <david.brown@hesbynett.no> - 2021-03-24 19:44 +0100
              Re: Linux embedded and direction control of RS485 transceiver upsidedown@downunder.com - 2021-03-25 07:34 +0200
              Re: Linux embedded and direction control of RS485 transceiver upsidedown@downunder.com - 2021-03-25 07:47 +0200
            Re: Linux embedded and direction control of RS485 transceiver Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-03-24 21:13 +0200
              Re: Linux embedded and direction control of RS485 transceiver upsidedown@downunder.com - 2021-03-25 07:39 +0200
              Re: Linux embedded and direction control of RS485 transceiver David Brown <david.brown@hesbynett.no> - 2021-03-25 10:48 +0100
                Re: Linux embedded and direction control of RS485 transceiver Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-03-25 16:33 +0200
                Re: Linux embedded and direction control of RS485 transceiver Grant Edwards <invalid@invalid.invalid> - 2021-03-25 14:49 +0000
                Re: Linux embedded and direction control of RS485 transceiver upsidedown@downunder.com - 2021-03-25 18:43 +0200
                Re: Linux embedded and direction control of RS485 transceiver David Brown <david.brown@hesbynett.no> - 2021-03-26 09:47 +0100
        Re: Linux embedded and direction control of RS485 transceiver Don Y <blockedofcourse@foo.invalid> - 2021-03-24 14:30 -0700
  Re: Linux embedded and direction control of RS485 transceiver dalai lamah <antonio12358@hotmail.com> - 2021-03-24 11:48 +0100
    Re: Linux embedded and direction control of RS485 transceiver pozz <pozzugno@gmail.com> - 2021-03-25 00:23 +0100
  Re: Linux embedded and direction control of RS485 transceiver "A.P.Richelieu" <aprichelieu@gmail.com> - 2021-05-09 13:24 +0200
    Re: Linux embedded and direction control of RS485 transceiver Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> - 2021-05-09 12:01 +0000
    Re: Linux embedded and direction control of RS485 transceiver pozz <pozzugno@gmail.com> - 2021-05-10 09:46 +0200

csiph-web