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

Groups > comp.arch.embedded > #31629

Re: Half-duplex RS485: simple auto-direction solution

Show all headers | View raw

Il 06/03/2023 20:23, Rick C ha scritto:
> On Monday, March 6, 2023 at 4:41:20 AM UTC-5, pozz wrote:
>> Il 04/03/2023 12:06, David Brown ha scritto:
>>> On 03/03/2023 17:15, pozz wrote:
>>>> I think you already know this trick: connect DE/RE signals of RS485
>>>> half-duplex transceiver to TX *negated* signal from UART and connect
>>>> TX input of transceiver to GND.
>>>>
>>>> If the bus is not driven by anyone, A signal goes high and B signal
>>>> goes low thanks to the pull-up/down resistors.
>>>>
>>>> The trick uses the fact that the undriven bus and transmitting 1 is
>>>> the same thing: A is high and B is low. So, when transmitting 1 the
>>>> driver is disabled (DE=0), when transmitting 0 the driver is enabled
>>>> (DE=1). Because TX is set to 0, A goes low and B goes high.
>>>>
>>>
>>> This arrangement is also known as a "CAN bus driver".
>> CAN is a well-known and very reliable network. Does this mean I could
>> use RS485 in "CAN bus driver" arrangement without critical problems?
>>>> Of course this works in ideal and good conditions. When should I worry
>>>> of this trick? I suspect the edges of 0 to 1 transitions are slowed down.
>>>>
>>>> I don't use mega-baudrate, in this application I'm using 38400bps.
> 
> You have not explained why you would want to go to this trouble.  Are you concerned about multiple drivers on the bus at the same time doing damage???

I'm using a Linux embedded module based on a MX6ULL that isn't capable 
of driving the direction in hw. There's a bit in one UART register that 
must be set/reset by software.

I don't know any details (and I don't have knowledge to understand) 
about how the UART driver is implemented and what could be the worst 
case delay of disabling the driver after the stop bit of the last 
transmitted byte. I suppose there's a very big jitter on this time, but 
it could be impossible to calculate the worst case.

I'd like to reduce this time at the minimum so the other transmitters on 
the bus shouldn't introduce big delays before starting the transmission 
to avoid conflicts with the Linux-box that delayed in freeing the bus.

> 
> I can't see any reason for complicating the bus in this way.  You may think 38400 bps is not fast, but have you done any calculations on the resulting rise time of the resistor pullup?  That's the main disadvantage of resistor pullups with what amounts to open collector drivers, the slow rise time impacting the timing.  The slow rise time also opens the door wider for noise to impact the reception of double edges.
> 
> The method I've used is to use bias resistors on the bus to establish a level in the absence of drivers on the bus.  Then, the driver is enabled at all times the UART is transmitting, including some portion of the final stop bit.  That will force the bus to a '1' state with all due speed, and the bias resistors will maintain that state.  This is the bit that can be tricky to assure.  CPUs don't really respond all that fast, and the status bits from the UARTs are not always what you would like.
> 
> The only other requirement is for the receivers to provide adequate time before driving the bus, to assure the previous driver has stopped driving the bus.  Again, the hardware is not always optimal for knowing the timing of the end of the stop bit, but at least there's nothing to prevent adding sufficient padding to prevent collisions.
> 

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

Thread

Half-duplex RS485: simple auto-direction solution pozz <pozzugno@gmail.com> - 2023-03-03 17:15 +0100
  Re: Half-duplex RS485: simple auto-direction solution Richard Damon <Richard@Damon-Family.org> - 2023-03-03 11:26 -0500
  Re: Half-duplex RS485: simple auto-direction solution David Brown <david.brown@hesbynett.no> - 2023-03-04 12:06 +0100
    Re: Half-duplex RS485: simple auto-direction solution pozz <pozzugno@gmail.com> - 2023-03-06 10:41 +0100
      Re: Half-duplex RS485: simple auto-direction solution David Brown <david.brown@hesbynett.no> - 2023-03-06 12:48 +0100
      Re: Half-duplex RS485: simple auto-direction solution Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-06 11:23 -0800
        Re: Half-duplex RS485: simple auto-direction solution pozz <pozzugno@gmail.com> - 2023-03-06 22:20 +0100
          Re: Half-duplex RS485: simple auto-direction solution Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-06 16:47 -0800
  Re: Half-duplex RS485: simple auto-direction solution Don Y <blockedofcourse@foo.invalid> - 2023-03-06 14:23 -0700

csiph-web