Re: Positional/physical addressing

Liste des GroupesRevenir à e design 
Sujet : Re: Positional/physical addressing
De : blockedofcourse (at) *nospam* foo.invalid (Don Y)
Groupes : sci.electronics.design
Date : 25. Jun 2025, 18:04:58
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <103ha8d$2t06h$1@dont-email.me>
References : 1 2 3 4
User-Agent : Mozilla Thunderbird
On 6/25/2025 3:14 AM, Liz Tuddenham wrote:
Don Y <blockedofcourse@foo.invalid> wrote:
 [...]
  My goal
is just to "run wires" between devices and let the devices sort
it all out.
 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'
That assumes each device sits on a "bus" AND that there is no other
information available /to the device/ from the interconnect wiring.
E.g., if each device DID sit on a "bus", but a second "pin" uniquely
available to each device/socket/slot had a serial memory connected
ad the memory had a unique serial number within, the device could
query the serial number and use that information to make itself
"unique" wrt the other devices watching that same bus.
The controller can then "poll" the identifier address space, one
bit at a time.  I.e., "Anyone out there with an address having
the first bit being a '0', please respond"; "Anyone with a 0 followed
by another '0'?", etc.
Note that the discovery phase need only happen once (or, infrequently).
Thereafter, the controller knows which identifiers are in use and
what they connect with (assuming the application layers in each are
different)

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.
You have to challenge assumptions.  E.g., the original solution I proposed
required a two-pin connector for each device:  one wired to the "previous"
device "socket" and the other to the "next" device socket.  The connection
to the previous feeding the serial input of a deserializer (UART Rx channel)
on the device; the connection to the next being fed BY the serial output
of a serializer (UART Tx channel) on the device.
The flaw with this is that the removal of a device renders all downstream
devices inaccessible.  (Likewise, the failure of a device!)

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 too "high tech".  You're effectively trying to build a TDR into
each device.  Recall, I want these to be dirt cheap because I use so many of
them in a system.

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.
 

Date Sujet#  Auteur
24 Jun 25 * Positional/physical addressing25Don Y
24 Jun 25 +* Re: Positional/physical addressing8Martin Rid
24 Jun 25 i`* Re: Positional/physical addressing7Don Y
24 Jun 25 i `* Re: Positional/physical addressing6Don Y
24 Jun 25 i  +* Re: Positional/physical addressing4Jeroen Belleman
25 Jun 25 i  i`* Re: Positional/physical addressing3Ian
25 Jun 25 i  i +- Re: Positional/physical addressing1Don Y
25 Jun 25 i  i `- Re: Positional/physical addressing1Jeroen Belleman
24 Jun 25 i  `- Re: Positional/physical addressing1Don Y
25 Jun 25 +* Re: Positional/physical addressing11Liz Tuddenham
25 Jun 25 i`* Re: Positional/physical addressing10Don Y
25 Jun 25 i `* Re: Positional/physical addressing9Liz Tuddenham
25 Jun 25 i  `* Re: Positional/physical addressing8Don Y
26 Jun 25 i   +* Re: Positional/physical addressing4Liz Tuddenham
26 Jun10:46 i   i`* Re: Positional/physical addressing3Don Y
26 Jun17:53 i   i `* Re: Positional/physical addressing2Liz Tuddenham
26 Jun21:48 i   i  `- Re: Positional/physical addressing1Don Y
26 Jun20:58 i   +* Re: Positional/physical addressing2bitrex
26 Jun21:50 i   i`- Re: Positional/physical addressing1Don Y
26 Jun21:00 i   `- Re: Positional/physical addressing1bitrex
25 Jun 25 +* Re: Positional/physical addressing4Ian
25 Jun 25 i`* Re: Positional/physical addressing3Don Y
25 Jun 25 i `* Re: Positional/physical addressing2Dennis
25 Jun 25 i  `- Re: Positional/physical addressing1Don Y
25 Jun 25 `- Re: Positional/physical addressing1john larkin

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal