Custom response time from slaves to avoid data collision

[free_electron]

9-bit UART, if supported (sadly, not all MCU peripherals do that), is indeed a lifesaver if you want to add easy and robust framing.

Though, that does not address (pun intended) the OP's question at all, which was about how to assign the addresses without collisions, not about framing, which, I assume, has been taken care of somehow already.

I prefer to use fixed, configurable addresses and just come up with some easy way to configure them. For example, a software tool which instructs the user to power up just one unit at a time, then program it with the ID of your choice using some special sequence recognized regardless of the configured ID - which would cause collisions if multiple units are powered on. And the user can attach a label.

One option is to change the topology from bus to a chain, still doable with UART. In a chain, automatic assignment of addresses is trivial and results in nice incrementing numbers if that is what you want. Then, a command would be relayed until it hits the target, after which the others relay the reply. A special "assign ID" message would contain an ID field, starting from 1 for example, and every node would increment this field and relay the command.

i believe that was one of the abilities of the intel uart. the byte going in would 'pass through' unless you had a prior matched address. so kind of a token ring .
slaves cannot talk unless addressed. so no risk of bus contention.

[fourfathom]

I just wanted to remind the OP of this post:

ANSI E1.20 has a nice way of dealing with this, allowing a controller to discover the unique fixed 48-bit unique ID of every device on a bus relatively quickly via binary search.  That unique ID can then be used to direct subsequent messages, and/or to assign an address.

- Controller broadcasts a discovery message asking every device with an address >= X and <= Y to send a response.  Responding devices send a message containing an encoded form of their unique ID and a checksum. 
- No response means no devices in that range and the controller will try the next range.
- A correct response means there is exactly one device in that range, and the controller now knows its ID.  So the controller can add that device to its internal list, and send a message to "mute" the device, so that it will not respond to further discovery messages.
- A garbled response means there is more than one device in the range (because their responses collided), so the controller will bisect the range and try again.

By the end of the process, the controller has a list of the unique IDs of all devices present.  The controller can periodically send discovery messages covering the entire address range to see if any new devices have joined the bus--because all of the previously discovered devices should be muted, only undiscovered devices or devices that have been power cycled or otherwise reset will respond.

This is a really nice way to discover random-but-unique addresses as you might get if you used the unique chip ID.  Once the devices are all discovered you can assign them a shorter "alias" address if you like.

And going to a single-wire open-collector TX+RX bus makes it easier to detect collisions and implement something like the old ethernet exponential backoff method.

[NorthGuy]

One option is to change the topology from bus to a chain, still doable with UART. In a chain, automatic assignment of addresses is trivial and results in nice incrementing numbers if that is what you want. Then, a command would be relayed until it hits the target, after which the others relay the reply. A special "assign ID" message would contain an ID field, starting from 1 for example, and every node would increment this field and relay the command.

Or you can make it a ring. This way you only need one wire and one UART module per device. Each node will receive from a neighbour left to it with RX and re-transmit to the neighbour right to it with TX. IF a node feels the command must be processed by the node, it'll transmit its response instead of the command - it'll go full circle and return to the master.

[Siwastaja]

One option is to change the topology from bus to a chain, still doable with UART. In a chain, automatic assignment of addresses is trivial and results in nice incrementing numbers if that is what you want. Then, a command would be relayed until it hits the target, after which the others relay the reply. A special "assign ID" message would contain an ID field, starting from 1 for example, and every node would increment this field and relay the command.

Or you can make it a ring. This way you only need one wire and one UART module per device. Each node will receive from a neighbour left to it with RX and re-transmit to the neighbour right to it with TX. IF a node feels the command must be processed by the node, it'll transmit its response instead of the command - it'll go full circle and return to the master.

Yes, this is exactly what I meant, ring is better term.

[Berni]

The ring idea is pretty good because you can have the wiring in the ring determine the address since the message can have a byte incremented at every node.

This same idea is used with some SPI devices that passtrough the leftover data from the MOSI to the MISO pin so you can have 4 of 16bit ADC chips that return there data in one 64bit transaction once chained together. But for communication over longer wires SPI is not that great.