Half-duplex RS485: simple auto-direction solution

Yes, that trick "works" to the level that you can use an "open collector" signal with a pull up to act like a normal driven signal.

The 0 to 1 transition is weak and the 1 is typically not full strength, so noise immunity is compromised.

It isn't bad for an "in system" communication bus, but isn't really reliable for a system-to-system link due to the higher capacitance (and thus slower transition) that occurs.

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?

Yes, you certainly can do so - within limitations. Since the return to idle (logic 1) level is by terminating resistors, you don't have such clean edges and the rate is highly dependent on the bus load, capacitance, and termination resistance. Normal RS-485 is sometimes run over kilometres of cable - CAN is rarely more than a few tens of metres.

And while CAN bus drivers are derived from RS-485 drivers with the arrangement you describe, they are a bit more optimised for the task. So you might consider using real CAN drivers rather than RS-485 drivers, even if you have UART signalling rather than CAN controllers for the protocol. (I did this myself on a project, long ago.)

Another alternative, of course, is to use full CAN - microcontrollers with CAN controllers are no longer the premium they used to be.

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 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.

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.

You could use a simple interface device that drives the line low always, but only drives the line high, for say, 20% of a bit time. That will assure the solid rise time, then it will be off the bus before the end of the "1" bit. Such a device needs to know nothing about your protocol. It is a bit of hardware that does a simple task. The 20% will need to be tuned to your data rate, but it's not a critical number. It could be set at a few microseconds (a simple RC time constant) to work well at your bit rate and would also work for any slower rate. How short you can make this time out, depends on how long it takes a driver to drive the cable to the '1' level.

This could be as simple as an RS-485 enabled driver. Drive the data input with the appropriate output from your existing driver. Drive the enable line through a resistor, with a cap to ground so it turns off after being in the '1' state after the RC time. A diode across the resistor will assure the driver turns on quickly when the driving signal is in the '0' state.

Four parts and, Bob's your uncle!