If a master has to manage all the slaves in his "domain," the available number of addresses must be limited in some way. 10 billion slaves is a bit too large, IMHO, for one 805x to manage. I'd be willing to be that it would, in fact, be quite a challenge to manage 127 slaves with only one 805x.

While it's not reasonable to poll for 10 billion slaves during initialization, it IS (marginally) reasonable to poll for 128 of them to determine who's out there and to set their "working" addresses. How the data structures that characterize each slave and their associated post-initialization addresses are managed is not known at this point, but, it matters not one iota how the pre-initialization address is set, aside from the fact it has to be manually settable by the end-user. If one uses polling, there's no risk of collisions, nor is multipathing the problem it would be if one tries to base the comm's on time slicing. One advantage of polling is that it allows, among other things, the measurement of response time between poll and response. That would be a handy parameter to have in the database.

Whether you use dip-switches, jumpers, or even an IAP procedure of some sort, the end-user has to be able, in some way, to do that. If they're not "smart enough" then they can't be helped.

There's probably a better way ... but this is where I'd start, based on what I know about the O/P's situation.

RE