We have implemented this scheme in an RS485 network, with possibly randomly added and withdrawn nodes, based on guidelines of my friend who developed the master part of it (on PC).

While in theory it looks nice, in practice it has quite a couple of pitfalls, too. For example, only rarely you have a medium at hand which enables to distinguish multiple repsonses; and if it is a collision medium similar to Ethernet, the timeout to wait until the last slave within a subtree responds, might be too tricky to determine, and some cunning timeouting scheme has to be employed. On RS485, for example, it is virtually impossible to distinguish the multiple answer case, so you need to traverse down to the leaf of a node each time. Etc.etc.

I see what you are saying about Ethernet and the timeouts. That sounds very difficult. I also see the problem with a noisy RF link, where it would be hard to tell the difference between multiple responses and a single garbled response.

But for an RS485 implementation, what if each slave sends a big fat CRC along with its address? In that case, isn't it a very good bet that:

• Silence = no slaves responded
• Good CRC = one slave responded
• Bad CRC = multiple slaves responded

Without trying it, that seems to me like it would work pretty well.

The RS485 is often seen as a panacea or a bulletproof way how to "network" small embedded boards; however, it has its own set of quirks and problems. CRCs and the sort are good for assuring that a message gets accross uncorrupted. But, your conclusion, that a message gets inevitably corrupted when two nodes are "talking" at the same time, is false.

First of all, RS485 transmitters are push-pull, so it is not supposed that more than one will "talk" at the same time. Okay, each sane implementation incorporates a finite output impedance of a few ohms, and the output stages are dimensioned to withstand fighting on the bus. But, for example, if you will have one transmitter sitting next to the receiver, and an other beyond a long pair of wires (read: considerable resistance); although the voltage swing on the bus will not be as expected, the receiver might very well "hear" the local transmitter "clearly".

The consequence for the "discovery" algoritm is, that you should not trust that you have discovered all the nodes upon "hearing" one "good" answer; you should repeat the whole discovery as long as you are sure there are no more nodes to discover.

Wow! Thank you for the excellent explanation. I am sort of an amateur when it comes to hardware things like this. I have my EE degrees and all that, but I got sucked into programming early in my career, so I am sadly lacking in practical experience on some things.

So I suppose the algorithm would work better with a wired-or network using some sort of open-collector transmitters?

Maybe; but those tend to lean towards being multimaster (or peer-to-peer), with collisionless arbitration (see I2C and CAN). The trouble is that they are electrically inferior to the "balanced" ones.