Re: Positional/physical addressing

Jun 25, 2025 Last reply: 1 year ago 8 Replies


I have a large group (hundreds) of switches and displays.


> Their state needs to be determined/updated rather slowly
> (a few hertz). Each has local smarts so it can retain
> some state information and processing capability.
>
> Their physical arrangement varies from one installation to
> the next. So, there is no economy of scale available by
> "settling" on a specific configuration or physical arrangement. >
> I would like to be able to address them (the entire *set*) -- and
> pass data to/fro -- with a small, fixed number of conductors /having
> built them all identically/.
The amount of data exchanged being
> traded off vs. update rate for a given interface bandwidth.
>
> The obvious "one wire" scheme would have a gazinta and cumzouta
> for each device so the device could modify a serial bit stream
> to account for its "position" in that stream.
>
> I can pipeline processing between devices so the overall access
> rate remains high (though latency obviously suffers).
>
> But, a single device failure renders all downwind devices
> inaccessible (or, possibly ALL devices, depending on implementation) >
> I'm looking at a two wire solution that piggybacks the data
> stream on power and ground (those "two wires"). But, it
> adds complexity to the devices (I want to keep them REALLY
> small and dirt cheap)
>
> Any existing schemes that allow this without the failure mode cited?

Philips I2c ?

[...]

I must admit this problem is a long way outside my comfort zone, but if we postulate that all the devices are truly identical then the contoller has no way of initially setting up the system. If it sends out a request for a response, all the devices will respond virtually simultaneously and there will be no way of sorting out the resulting 'pile-up'

Even if the controller is clever enough to detect the nearest device on the line, because its response arrives first, it has no way of telling that device to assume a particular identity because the same identity command will be picked up by all the other devices too. The problem isn't one of which system to use, but whether an overall strategy can be developed to solve a problem that appears to be logically insoluble.

Having said that, there is one feature that could be used to distinguish between the devices before any address allocation has taken place, they are all different distances from the controller.

If the controller sends out a pulse and every device responds instantaneously, the first response received back can trigger a second pulse from the controller. The first device on the line will receive the second pulse after a time which corresponds to twice its distance from the controller and this can generate a number which the device stores. The controller polls through the numbers sequentially from zero until the first device responds, the controller now tells the first device to shut up and repeats the entire sequence so that the second device is now the first one to respond.

This is repeated until each device along the line has a unique number and has been muted.. The controller sends out a command to re-activate all the devices and polls through the numbers again, listening for each device to respond individually. When a device responds it is allocated a proper address and the network is gradually set up in this manner.

A thought...

If you have a chain, you get the "downstream failure" issue.

If you have a bus, each device nees an address.

How about having both. Use the chain to assign addresses at power-up or whenever, then use the bus for real communication. If the devices have some NV storage, the address assignment can be a 1-off, so the whole chain only needs to work "once" (assuming a dead device just keeps quiet and doesn't kill the bus).

------ ----- ----- ----- ----- | | | | | | | | | ctrlr |--------->| Dev |-->| Dev |-->| Dev |-->| Dev |-----> Chain | | | | | | | | | | ----- ----- ----- ----- | ^ ^ ^ ^ | | | | | | v v v v |<---------------------------------------------------> Bus |

------

Sounds like Ethernet might work.

Like the one wire DS2401 digital serial number?

Actually the individual devices just need to store the time between two clear digital pulses as a number. If the devices are never closer than one yard apart, a 300 Mc/s clock speed will be sufficient to distinguish between them. (The twin identification pulses will be spaced by double the path length.)

That programs each device with an unique address and the rest can be done with normal digital handshaking and read/write. It is a way of overcoming the 'identicality' of the devices so you don't have to allocate individual serial numbers to them during manufacture, which could reduce the cost if a lot have to be made.

Then they can all be strung out along a two-wire bus (send and return) to allow individual devices to be removed or changed without a lot of re-wiring or bridging connectors, so installation and maintenance costs are reduced too..

I hadn't realised they were that close together. Obviously my suggestion fir timing is a non-starter.

You could tile 'em. A local bus north west south and east with the main IO bus on the perimeter.

Send outputs towards the edge using a greedy algorithm that only needs local state and if a tile has failed then route around it.

You could tile 'em. A local bus north west south and east with the main IO bus on the perimeter.

Send outputs towards the edge using a greedy algorithm that only needs local state and if a tile has failed then route around it.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required