Two on board devices connected to the same RS485 bus

[elias]

Hello all,

I'm designing another automation gateway based on the Raspberry Pi Compute Module 4, where I'm looking to have an MCU that could do some work while the main SoC is too busy or sleeping.

In order to achieve that, I'm making it so they share some of the communication interfaces, like the RS485 and CAN Bus ports. The board only exposes one RS485 port and one CAN Bus port but, internally, I would like both devices, the MCU and the Raspberry Pi CM4, to be connected to the bus so either of them can take the master roll and leave the other as another slave at any point in time. The architecture would look something like this:

+-----------------------------------+
|                                   |          +-------+
|            Main board        +----+          |       |
|                              |  R +----+-----+ Dev 1 |
|                              |  S |    |     |       |
|   +--------------+     +-----+  4 |    |     +-------+
|   | Raspberry Pi |     |     |  8 |    |
|   |              +-----+     |  5 |    |     +-------+
|   |      CM4     |     |     +----+    |     |       |
|   +--------------+     |          |    +-----+ Dev 2 |
|                        |          |    |     |       |
|   +--------------+     |          |    |     +-------+
|   |              |     |          |    |
|   |      MCU     +-----+          |    |     +-------+
|   |              |                |    |     |       |
|   +--------------+                |    +-----+ Dev 3 |
|                                   |          |       |
+-----------------------------------+          +-------+

Here is the schematic I've come up with, but I'm not confident this design will work:

• Termination resistor may not be on the correct place
• Trace impedance and length (very short) may influence signal integrity

I'm also wondering how could I add isolation between the main board and the "external world" without messing up the bus impedance. I'm looking to use a MAX14850 for the isolation.

Any feedback and/or suggestions would be very welcome and credited, if the project reaches my GitHub account.

Thank you very much for taking the time read my post.

[oPossum]

Looks like Tx & Rx are reversed. Tx goes to the driver (D) and Rx to the receiver (R).

The unconventional driver enable may work if there is a bias circuit, but it would be better to use a GPIO. The UART shift register empty flag & interrupt can be used for proper driver control.

[Doctorandus_P]

I've designed some bus powered devices (one pair from a four pair ethernet cable).
I got bus corruption while hot plugging.  DE/~RE were connected directly to a microcontroller pin, and that pin was floating just after power up. (uC runs some initialization code).
I had to add a pull-down resistor to fix that issue.

What are you trying to achieve with Q1 and Q5?
Whatever it is, it probably does not work.

For example, you have to pull DE high at the moment you start shifting the first start bit out, and it has to remain high though the whole data byte (or packet), and it should only be released (to low) when the last stop bit is shifted out of the UART.
In Microcontrollers this is usually done by a "Transmission Complete" ISR that toggles an output bit.

I usually do not bother with termination resistors on the PCB. Instead I use a plug with a resistor as termination for the bus. The termination is for the bus, not for the IC's. If you have a bunch of these modules on the same bus, then only the two module's on the far ends of the bus should have these termination resistor. So if you add the resistors on the PCB, then you need some kind of switch or jumper to disable these resistors.

It's also better to put the TVS diodes on the other side of the 10 Ohm resistors. That way the resistors also protect the TVS diodes. You can move a single pair of these resistors to the output connector (That is where transients come from) and then connect A & B of the RS485 transceivers directly to each other.

You can also use PPTC's. This has the advantage of protecting against hard overvoltages. This is especially useful if you run multiple nodes from a 24V power supply and use an SMPS to generate the low voltages for the uC's. (A trick I learned from MikesElectricStuff).

Also, the GND wire is mandatory for RS485. RS485 has a common mode voltage range from around -7Vdc to +12Vdc. And that voltage is from a common reference (A.K.A GND wire).
Without this GND wire, the bus gets loaded by ground currents and these will distort your signals and cause intermittent and hard to debug faults.

Also search around for: "10 ways to bullet proof RS485". It's an old AN, but still a very good reference to getting RS485 reliable.

[elias]

D'oh! What a stupid mistake with the TX and RX!

I'll also take a look to the driver enable circuit, I can confirm it does work, as I've used it before, but it is certainly very unconventional.

Thank you oPossum!

[elias]

Hi Doctorandus_P,

First of all, thank you very much for the very detailed feedback, I'll incorporate it to the schematic and share the results here as soon as I have it.

What are you trying to achieve with Q1 and Q5?
Whatever it is, it probably does not work.

For example, you have to pull DE high at the moment you start shifting the first start bit out, and it has to remain high though the whole data byte (or packet), and it should only be released (to low) when the last stop bit is shifted out of the UART.

Q1 is implementing a very dirty and cheap auto direction for the driver. The way "it works" is explained here, even though I did take the idea from some other place I don't remember right now: https://www.programmersought.com/article/43706543/
But the more I read about it the less I like it, maybe I could implement something like this: https://www.ti.com/lit/ug/tidubw6/tidubw6.pdf

On the MCU side, there is no issue with having a GPIO selecting the direction, but my issue is that on the Linux side, most software has no ability to drive the direction pin. Making the direction to be selected automatically, makes the interface to look like any regular UART, with no need to worry about specifics of RS485.

[ajb]

In general it seems like there ought to be a more elegant solution to this problem than having two devices with two separate transceivers connected together like this.  One practical downside is that since you have two transceivers on the bus you have twice the unit load versus just using a single transceiver, which could be a problem if you need to support a lot of these devices on one bus.

Any reason to not have the pi hand off messages to the MCU for transmission? Depending on the protocol you might be able to handle that in a uart RX interrupt that receives bytes from the pi on one uart and relays them out on another uart, or the pi could send more structured commands that the MCU interprets.  Either way the overhead on the MCU should be minimal if all you're doing is relaying a message between uarts or whatever, and you have the benefit of being able to easily manage the transceiver's direction.  The pi could still directly receive inbound messages from the bus directly via the transceiver's receive output if you wanted

If you really want auto direction control on the transceiver you would need something amounting to a non-retriggerable one-shot timer that would assert the driver enable line with the first edge of the start bit and keep it asserted for the full character time, including stop bit(s), which means the timer has to be programmed to suit the baud rate.  At really fast baud rates, you need to make sure that the time from that first edge of the start bit to the driver being ready to transmit doesn't get too long, since it will shorten the start bit as presented to the bus, which could cause issues for other receivers if you don't have enough timing margin.

[elias]

Thanks ajb for your feedback.

I really like your idea of making the MCU act as "repeater" to avoid having to have a second driver, so I may go for it. The only downside is that I'm trying to come up with a design that would allow to boot Linux and start using all the interfaces without having the worry about any firmware for the MCU, leaving the latter free to be used (or not) for whatever purpose the user wants/needs.

This circuit is part of an automation gateway (yes, another one) I'm designing, so it is not expected to have multiple gateways on the same RS485 bus, even though it may be a possibility for some use cases I haven't think of.

I've been looking into the non-retriggerable one-shot timer approach for the direction but, as you are pointing out, it would limit the usable baud rates.