Hi,
As far as I know a half duplex RS485 bus is used in master/slave type networks where a slave never initiates communications on its own, it only responds to queries from a master. That way there's no risk for collision because the master is "in control" of the bus, it sends and it knows when to expect a response.
With that said making sure the bus is silent and then simply start sending is about all you can do. There will always be that slight possibillity of two devices doing the same thing at exactly the same time but hey, what can you do.
Checking if there is a byte in the receive buffer doesn't really say anything because even if the buffer is empty there might be a byte on its way in. And even if you wait x amount of time and again check the receive buffer there's NO guarantee that there's not a byte on its way in THIS time.
I think you need to poll the actual reciever output and make sure it's idle for at least one bit time and then just take your chanses and fire off the message. If the overall load on the bus low (ie it's silent most of the time), the hardware is designed to survive bus contention and you have some form of error checking (CRC etc) then it might work by implementing some sort of "message received reply" of some sort.
I've never worked with it but for this sort of application CAN might be a good fit.
Another way, which I haven't really thought thru yet, might be to have a master continously quering each node in sequence, allowing each one a window of time within which it's allowed to respond. Ie, when a node wants to speak it buffers the message and waits for its turn. Node 1, you've got 2ms of "airtime" - go, Node 2, you've got 2ms of "airtime" - go.
/Henrik.
Bookmarks