Re: [PATCH 1/4] dt_bindings: rs485: Add binding for GPIO that controls Rx enable during Tx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Christoph,

let me first say, for an upcoming new product we are currently
developing, we tried different wirings, all related to that !RE pin of
the transceiver.

In a first hardware revision the engineer doing the schematic
connected !RE to GND (always on) and it took me a while to recognize
what was going on: everything send through TX was mirrored on RX,
which makes using lots of standard applications on that port just
fail.  (To be fair, we need exactly that behaviour on a different
board.)

In a second iteration !RE is directly connected to DE now, so RE is
now always the opposite of DE.  DE itself is always connected to the
RTS line of the UART, which allows the driver to switch direction.

More below.

Am Thu, Oct 27, 2022 at 12:06:56PM +0000 schrieb Christoph Niedermaier:
> From: Rob Herring [mailto:robh@xxxxxxxxxx]
> Sent: Wednesday, October 26, 2022 10:59 PM
> > On Wed, Oct 26, 2022 at 06:50:46PM +0200, Christoph Niedermaier wrote:
> >> Add the binding for a generic definition of a GPIO, that controls whether Rx
> >> is connected or disconnected by an electrical circuit to have the ability
> >> to receive the signals on the bus during sending or disable receiving during
> >> sending.
> >>
> >> Signed-off-by: Christoph Niedermaier <cniedermaier@xxxxxxxxxxxxxxxxxx>
> >> ---
> >> Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> >> Cc: Rob Herring <robh+dt@xxxxxxxxxx>
> >> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@xxxxxxxxxx>
> >> Cc: Marek Vasut <marex@xxxxxxx>
> >> Cc: devicetree@xxxxxxxxxxxxxxx
> >> To: linux-serial@xxxxxxxxxxxxxxx
> >> To: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> >> ---
> >>  Documentation/devicetree/bindings/serial/rs485.yaml | 4 ++++
> >>  1 file changed, 4 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/serial/rs485.yaml b/Documentation/devicetree/bindings/serial/rs485.yaml
> >> index 90a1bab40f05..0ebd7690f85d 100644
> >> --- a/Documentation/devicetree/bindings/serial/rs485.yaml
> >> +++ b/Documentation/devicetree/bindings/serial/rs485.yaml
> >> @@ -51,6 +51,10 @@ properties:
> >>      description: GPIO pin to enable RS485 bus termination.
> >>      maxItems: 1
> >>
> >> +  rs485-rx-during-tx-gpios:
> >> +    description: GPIO pin to control RS485 Rx enable during Tx.
> > 
> > Active state means do what? And inactive? This is an output gating the
> > RX signal or an input telling the receiver what to do during tx? The
> > description is not adequate.
> > 
> > How does this property relate to 'rs485-rx-during-tx' Any combination of
> > the 2 being present or not is okay? If not, you need some constraints.
> > 
> > Rob
> 
> 
> Hi Rob,
> 
> I have improved the message:
> 
> The standard RS485 is a half-duplex bus that in most cased is driven by an
> UART controller. The interface to the bus is controlled by a transceiver, that
> has a pin called RE (Rx enable) or similar, which connects the bus to Rx signal
> of the UART controller. This patch adds a binding for a generic definition of a
> GPIO that can switch between two states to control the RE pin via an electrical
> circuit:
> - Active:
>   The RE pin is always active. The UART Rx see everything on the bus and
>   therefore also what happens with the Tx signal on the bus.
> - Inactive:
>   The RE pin is always active, but during sending on the bus the pin RE is
>   inactive. So basically the receiving during sending is suppressed.
> 
> Is it now more understandable, or have I still not considered an aspect?

Better.  But what about the questions Rob asked?  There's already a
property 'rs485-rx-during-tx' which leads to setting the flag
SER_RS485_RX_DURING_TX in serial core.  As far as I understood from a
quick glance at core and drivers, this deals with half or full duplex
from the UART point of view (not the transceiver).

You need to explain, what's the difference to the new property.
I suspect you want to somehow switch behaviour with that GPIO line?
Which driver should switch that line in the end and when?

(For third iteration of our hardware we thought about a GPIO
controlling whether !RE is always on or connected to DE, but that's
probably not what you have in mind?)

Maybe a simple generic schematic could help explain or maybe you find
a better name for the property?

Greets
Alex

> 
> 
> Thanks and regards
> Christoph



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux