Welcome to the biggest challenge with half-duplex communications systems.

RS-485 is not a protocol, it's a standard which defines the electrical properties for a half-duplex differential link. There is nothing in the specification about how data is to be sent over that link, or in fact how the link is used.

As such RS-485 transceivers have no automatic "line is busy" signal/flag/whatever, nor will microcontrollers which have built in RS-485 drivers, nor ones which use a UART core connected to an external transceiver.

All implementation of flow control and direction control is left to whatever protocol you use. There exist several well known protocols which use RS-485 drivers, such as Modbus. You can also implement whatever protocol you can think of.

To help you along, these are a couple of ideas for protocols:

1. You have a master-slave type protocol. In this there is a master node which coordinates the bus, and slave nodes which each have some unique identifier.

The slave nodes are not allowed to send any data until the master node specifically sends commands addressed to them. Once a slave is addressed, it can then respond to any command in some predefined way - say a fixed length response packet.

In this case you avoid issues of multiple devices wanting to talk at the same time because the master is there to coordinate everything.

2. You could use some form of scheduling whereby each device on the bus has a fixed slot in which to send data to any other device. Once its slot runs out it must stop sending and allow the next device to talk.

The scheduling could be done by the devices themselves without external coordination. The first device talks, and then sends a message saying it is done. The next device (e.g. the one with next higher ID) would know then that it could go. In case a device is not responding you could then have some timeout whereby each subsequent device in the schedule would be able to say - well I haven't heard from the device before me for a while, so it must be my turn.

Welcome to the biggest challenge with half-duplex communications systems.

RS-485 is not a protocol, it's a standard which defines the electrical properties for a half-duplex(*) differential link. There is nothing in the specification about how data is to be sent over that link, or in fact how the link is used.

As such RS-485 transceivers have no automatic "line is busy" signal/flag/whatever, nor will microcontrollers which have built in RS-485 drivers, nor ones which use a UART core connected to an external transceiver.

All implementation of flow control and direction control is left to whatever protocol you use. There exist several well known protocols which use RS-485 drivers, such as Modbus. You can also implement whatever protocol you can think of.

To help you along, these are a couple of ideas for protocols:

1. You have a master-slave type protocol. In this there is a master node which coordinates the bus, and slave nodes which each have some unique identifier.

The slave nodes are not allowed to send any data until the master node specifically sends commands addressed to them. Once a slave is addressed, it can then respond to any command in some predefined way - say a fixed length response packet.

In this case you avoid issues of multiple devices wanting to talk at the same time because the master is there to coordinate everything.

2. You could use some form of scheduling whereby each device on the bus has a fixed slot in which to send data to any other device. Once its slot runs out it must stop sending and allow the next device to talk.

The scheduling could be done by the devices themselves without external coordination. The first device talks, and then sends a message saying it is done. The next device (e.g. the one with next higher ID) would know then that it could go. In case a device is not responding you could then have some timeout whereby each subsequent device in the schedule would be able to say - well I haven't heard from the device before me for a while, so it must be my turn.

(*) I believe it also defines a full-duplex version using two differential links.